This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23536 - figure out if "mixed clipboard content" is testable, write tests if it is
Summary: figure out if "mixed clipboard content" is testable, write tests if it is
Status: NEW
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Clipboard API and events (show other bugs)
Version: unspecified
Hardware: PC Linux
: P3 normal
Target Milestone: ---
Assignee: Hallvord R. M. Steen
QA Contact: public-webapps-bugzilla
URL: http://dev.w3.org/2006/webapi/clipops...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-16 21:14 UTC by Hallvord R. M. Steen
Modified: 2014-01-23 23:56 UTC (History)
2 users (show)

See Also:


Attachments

Description Hallvord R. M. Steen 2013-10-16 21:14:22 UTC
The spec assumes that a clipboard can have mixed, self-referencing content - like an HTML fragment + an image, stored as separate parts in the system clipboard, where the HTML fragment references the image in a way that should be preserved when pasted.

Hence the spec's processing model contains a section detailing how to use the cid: URL scheme for referencing other DataTransferItemList entries.

This is actually somewhat speculative. I have not yet been able to verify that 

a) System clipboards sometimes store different parts that reference each other
b) HTML fragments in the system clipboards are sometimes saved in a way that references other parts
c) References survive roundtripping/pasting

If these assumptions are true, we need a test that writes such content to clipboard on at least one OS to assert that the spec's algorithm is implemented.
Comment 1 James M. Greene 2014-01-23 23:36:49 UTC
Would it be feasible for implementors to inline the images with `data:` URLs instead of `cid:` URLs?  I'm not that familiar with the `cid:` URL standards, so I may be off base.

Seems like this may be the strategy being employed elsewhere (e.g. for pasting images)?

https://bugzilla.mozilla.org/show_bug.cgi?id=665341
Comment 2 Hallvord R. M. Steen 2014-01-23 23:56:51 UTC
I think data: URLs have some drawbacks, memory usage is one. Imagine pasting a snippet of text from a Word document that has an embedded video..

The idea here is that once implementations have mangled the markup to add cid: URLs, the script can parse the markup (or, better yet, use event.clipboardData.documentFragment if we give the API a link to the parsed DOM..), rummage through the DOM to find cid: references, start file uploads for those clipboard parts and add placeholders to the pasted data that the script later can rewrite to reference the eventual server location(s) when file upload(s) finish. The cid: scheme avoids exposing any local paths or structures (which we're worrying about in https://bugzilla.mozilla.org/show_bug.cgi?id=665341 and similar bugs - thanks for making me aware of it BTW).

(I'll have to ask implementors about this stuff though. They may well feel like it's too late to introduce this cid: concept - although AFAIK we don't really have any better concepts for those use cases yet..)