Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
On Fri, May 23, 2014 at 5:13 PM, Glenn Maynard gl...@zewt.org wrote: Hallvord: By the way, please add the editor of the HTML spec to the beginning of the list in your references. It's strange to list a bunch of author names, but not the person who actually writes the spec. Is anything incorrect here? https://w3c.github.io/clipboard-apis/#references I think these are from ReSpec.js 's bibliographic database actually. On Fri, May 23, 2014 at 8:21 AM, James Greene james.m.gre...@gmail.com wrote: This kind of copy does not implicitly have anything to do with Selection, unless we continue to have its default action be copying the currently selected text. It is substantially more likely to be used for custom text insertion. I'd assume something like: // Copy text: window.copyToClipboard(hello); // Copy HTML text: span = document.createElement(span); span.innerHTML = bhello/b; window.copyToClipboard(span); // Copy an image from a CanvasImageSource: window.copyToClipboard(canvas); window.copyToClipboard(img); // Copy the selection: window.copyToClipboard(window.getSelection()); // Copy HTML text with plaintext alternative: dt = new DataTransferItemList(); dt.add(hello, text/plain); dt.add(span.innerHTML, text/html); window.copyToClipboard(dt); This looks like a pretty usable API to me. One of the main simplifications is that it drops certain limitations that we've added to lock down the API - for example the way clipboardData and its methods is only available to an event listener's thread. So .. it depends on whether that's what we want. -Hallvord
Re: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data
In addition, from a security perspective, what stops a malicious website from embedding something like img src=file:///etc/passwd style=display:none/img in the markup? We disallow this on copy by stripping such references. Hi Ben, picking up this old thread.. So we need to add a sanitize local references step/algorithm somewhere when JS writes data to clipboard? It would be great if you could have a look at https://w3c.github.io/clipboard-apis/#dfn-writing-contents-to-the-clipboard and suggest some text - maybe even in the form of a GitHub pull request? :) (I assume you strip *all* local references, not just specific blacklisted stuff like /etc/passwd - this probably needs testing with various types of slashes etc..) Do you have any other safety measures when data is written to the clipboard? -Hallvord
Re: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data
So, the E-mail to Ben Peters bounced - he's no longer at Microsoft? Is there anyone on the IE team present on the list who is able to comment on this? -Hallvord R On Mon, Apr 20, 2015 at 10:38 PM, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: In addition, from a security perspective, what stops a malicious website from embedding something like img src=file:///etc/passwd style=display:none/img in the markup? We disallow this on copy by stripping such references. Hi Ben, picking up this old thread.. So we need to add a sanitize local references step/algorithm somewhere when JS writes data to clipboard? It would be great if you could have a look at https://w3c.github.io/clipboard-apis/#dfn-writing-contents-to-the-clipboard and suggest some text - maybe even in the form of a GitHub pull request? :) (I assume you strip *all* local references, not just specific blacklisted stuff like /etc/passwd - this probably needs testing with various types of slashes etc..) Do you have any other safety measures when data is written to the clipboard? -Hallvord
Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
On Wed, May 21, 2014 at 2:01 AM, Glenn Maynard gl...@zewt.org wrote: I think I'd suggest avoiding the mess of execCommand altogether, and add new methods, eg. window.copy() and window.cut() (or maybe just one method, with a cut option). execCommand is such a nonsensical way to expose an API that trying to stay consistent with its commands is probably not much of a win. I'm inclined to agree, FWIW. If the command is really strictly editor-related, and makes sense only in conjunction with an editor based on existing commands, I would add it to execCommand for consistency (like defaultParagraphSeparator or fontSizePt). But anything else should stay far away. (Actually, if contenteditable wasn't an unsalvageable trainwreck, I would rather write a new API that actually follows JS norms, like window.editor.bold() or similar, but it is, so there's no point in doing anything beyond *maybe* trying to get it a bit more interoperable.)
Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
I'm all in favor of a new API as well. Sincerely, James Greene On Fri, May 23, 2014 at 5:53 AM, Aryeh Gregor a...@aryeh.name wrote: On Wed, May 21, 2014 at 2:01 AM, Glenn Maynard gl...@zewt.org wrote: I think I'd suggest avoiding the mess of execCommand altogether, and add new methods, eg. window.copy() and window.cut() (or maybe just one method, with a cut option). execCommand is such a nonsensical way to expose an API that trying to stay consistent with its commands is probably not much of a win. I'm inclined to agree, FWIW. If the command is really strictly editor-related, and makes sense only in conjunction with an editor based on existing commands, I would add it to execCommand for consistency (like defaultParagraphSeparator or fontSizePt). But anything else should stay far away. (Actually, if contenteditable wasn't an unsalvageable trainwreck, I would rather write a new API that actually follows JS norms, like window.editor.bold() or similar, but it is, so there's no point in doing anything beyond *maybe* trying to get it a bit more interoperable.)
Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
On 23/05/2014 14:33 , James Greene wrote: I'm all in favor of a new API as well. Me too, as discussed in http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0550.html. I wouldn't put this on window though; why not put it on Selection? -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
I wouldn't put this on window though; why not put it on Selection? This kind of copy does not implicitly have anything to do with Selection, unless we continue to have its default action be copying the currently selected text. It is substantially more likely to be used for custom text insertion. Sincerely, James Greene On Fri, May 23, 2014 at 7:43 AM, Robin Berjon ro...@w3.org wrote: On 23/05/2014 14:33 , James Greene wrote: I'm all in favor of a new API as well. Me too, as discussed in http://lists.w3.org/Archives/ Public/public-webapps/2014JanMar/0550.html. I wouldn't put this on window though; why not put it on Selection? -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
Moreover, the clipboard is systemwide, when selection exists per document. So in my opinion window is a better choice. On Fri, May 23, 2014 at 3:21 PM, James Greene james.m.gre...@gmail.comwrote: I wouldn't put this on window though; why not put it on Selection? This kind of copy does not implicitly have anything to do with Selection, unless we continue to have its default action be copying the currently selected text. It is substantially more likely to be used for custom text insertion. -- Piotrek Koszuliński CKEditor JavaScript Lead Developer
Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
Hallvord: By the way, please add the editor of the HTML spec to the beginning of the list in your references. It's strange to list a bunch of author names, but not the person who actually writes the spec. On Fri, May 23, 2014 at 8:21 AM, James Greene james.m.gre...@gmail.comwrote: This kind of copy does not implicitly have anything to do with Selection, unless we continue to have its default action be copying the currently selected text. It is substantially more likely to be used for custom text insertion. I'd assume something like: // Copy text: window.copyToClipboard(hello); // Copy HTML text: span = document.createElement(span); span.innerHTML = bhello/b; window.copyToClipboard(span); // Copy an image from a CanvasImageSource: window.copyToClipboard(canvas); window.copyToClipboard(img); // Copy the selection: window.copyToClipboard(window.getSelection()); // Copy HTML text with plaintext alternative: dt = new DataTransferItemList(); dt.add(hello, text/plain); dt.add(span.innerHTML, text/html); window.copyToClipboard(dt); This avoids the busywork of creating a DataTransfer in common cases, but allows using DataTransfer when you want to do something more advanced, like provide alternatives or explicitly specify a MIME type. Note that DataTransferItemList isn't actually constructable right now. Note that I used DataTransferItemList in the example and not DataTransfer, since DataTransfer is only relevant to drag-and-drop. I wonder what the right way to handle images is. Native Windows applications can copy pixel data to the clipboard, then paste it back out. DataTransferItem wants things to act like strings, though, so you'd have to encode the image to a file format. If that's PNG, that's an expensive conversion. Maybe DataTransferItem should be able to return an ImageSource. (As an aside, why is the paste event's .clipboardData not set to the text being pasted? I wanted to see what pasting images did in current browsers, but at least in Chrome there's nothing in there, even if I just paste plain text.) -- Glenn Maynard
Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
Maybe it's just me but... I would personally never want the browser to
automatically assume what I wanted copied and into which clipboard
segments, with the possible exception of a Selection.
I would prefer something very explicit, e.g.:
```js
window.clipboard.copy({
text/plain: BLAH,
text/html: bBlah/b,
application/rtf: {\\rtf1\\ansi\n{\\b Blah}},
text/x-markdown: **Blah**
});
```
Also, Hallvord et al: switching to a standalone API would also mean that we
can drop all of the `cut`-specific parts of the spec since `cut` requires
an active Selection, right?
Sincerely,
James Greene
On Fri, May 23, 2014 at 10:13 AM, Glenn Maynard gl...@zewt.org wrote:
Hallvord: By the way, please add the editor of the HTML spec to the
beginning of the list in your references. It's strange to list a bunch of
author names, but not the person who actually writes the spec.
On Fri, May 23, 2014 at 8:21 AM, James Greene james.m.gre...@gmail.comwrote:
This kind of copy does not implicitly have anything to do with Selection,
unless we continue to have its default action be copying the currently
selected text. It is substantially more likely to be used for custom text
insertion.
I'd assume something like:
// Copy text:
window.copyToClipboard(hello);
// Copy HTML text:
span = document.createElement(span);
span.innerHTML = bhello/b;
window.copyToClipboard(span);
// Copy an image from a CanvasImageSource:
window.copyToClipboard(canvas);
window.copyToClipboard(img);
// Copy the selection:
window.copyToClipboard(window.getSelection());
// Copy HTML text with plaintext alternative:
dt = new DataTransferItemList();
dt.add(hello, text/plain);
dt.add(span.innerHTML, text/html);
window.copyToClipboard(dt);
This avoids the busywork of creating a DataTransfer in common cases, but
allows using DataTransfer when you want to do something more advanced, like
provide alternatives or explicitly specify a MIME type. Note
that DataTransferItemList isn't actually constructable right now. Note
that I used DataTransferItemList in the example and not DataTransfer, since
DataTransfer is only relevant to drag-and-drop.
I wonder what the right way to handle images is. Native Windows
applications can copy pixel data to the clipboard, then paste it back out.
DataTransferItem wants things to act like strings, though, so you'd have
to encode the image to a file format. If that's PNG, that's an expensive
conversion. Maybe DataTransferItem should be able to return an ImageSource.
(As an aside, why is the paste event's .clipboardData not set to the text
being pasted? I wanted to see what pasting images did in current browsers,
but at least in Chrome there's nothing in there, even if I just paste plain
text.)
--
Glenn Maynard
Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
On Mon, May 19, 2014 at 9:21 PM, Hallvord R. M. Steen
hst...@mozilla.com wrote:
button.onclick = function(){
button.dispatchEvent(new ClipboardEvent('copy', {dataType:'text/plain',
data:'Hello world'});
// did that succeed or not? We don't have event.clipboardData on a clip
event object
That should never work as per the other thread. execCommand should
maybe work. And with the various queryCommand* APIs you can do
detection.
--
http://annevankesteren.nl/
Re: [clipboard events] implicitly prevent default event action?
On Tue, May 20, 2014 at 12:01 PM, Hallvord R. M. Steen hst...@mozilla.com wrote: On the other hand, perhaps we could just observe the clipboardData.items list? If this list is not empty, the payload must have been changed during processing. So if the default is prevented OR clipboardData.items.length 0 we place the clipboardData payload on the system clipboard. Can I get away with that, or would an explicit flag be better? Maybe. It seems some refactoring is needed either way. The underlying data model for .items is drag data store item list which is a term that's somewhat different from what we have here. -- http://annevankesteren.nl/
Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
On Mon, May 19, 2014 at 9:21 PM, Hallvord R. M. Steen
hst...@mozilla.com wrote:
button.onclick = function(){
button.dispatchEvent(new ClipboardEvent('copy', {dataType:'text/plain',
data:'Hello world'});
// did that succeed or not? We don't have event.clipboardData on a clip
event object
That should never work as per the other thread.
Per the other thread I accept that a copy event should not cause a default
action in the UA - for example, if you've selected 'hi world' in the web page,
calling
document.body.dispatchEvent(new ClipboardEvent('copy'))
will not place 'hi world' on the clipboard - because scripted events do not
have default actions.
However, if a scripted copy event can't take a payload and have it placed on
the clipboard, what's the point of making script-generated copy events possible
in the first place? If there's no point I'd rather disallow them.
execCommand should maybe work. And with the various queryCommand*
APIs you can do detection.
Detection is still tricky. Are you suggesting that
document.queryCommandEnabled('copy')
should return true when called from a trusted click event but false when called
inline in a script, to indicate that this command is only available in
semi-trusted events?
-Hallvord
Re: [clipboard events] implicitly prevent default event action?
Maybe. It seems some refactoring is needed either way. The underlying data model for .items is drag data store item list which is a term that's somewhat different from what we have here. I think that's a feature, not a bug - for example, many operating systems let you 'copy' and 'paste' files from the file explorer. When clipboardData is an instance of DataTransfer, we have the infrastructure to make copying files from the file manager and pasting them into a web page work just like drag-and-drop would. It should be a good thing for accessibility and consistency with OS file manager conventions. The way HTML5 specs setData() and the other parts of the API shouldn't cause any problems for our use case, no? -Hallvord
Re: [clipboard events] implicitly prevent default event action?
On Tue, May 20, 2014 at 12:16 PM, Hallvord R. M. Steen hst...@mozilla.com wrote: The way HTML5 specs setData() and the other parts of the API shouldn't cause any problems for our use case, no? I guess. In any event, you should refer to the underlying concepts, not the API side of things. If the underlying concepts expose enough for what you need, no need to introduce more. -- http://annevankesteren.nl/
Re: [clipboard events] implicitly prevent default event action?
On Tue, May 20, 2014 at 3:42 AM, Hallvord R. M. Steen hst...@mozilla.comwrote:
a) The event is script-generated and has a data payload (new
ClipboardEvent('copy', {dataType:'text/plain', data:'Hi World'}))
I'm a little confused. Script-generated events never have a default
action, except for a couple isolated web-compatibility hacks where
dispatching an event in script has side-effects, like click.
Hm.. I didn't really know that was a rule. I basically want
I think two reasons people get confused over this are the use of the term
default action, which makes it sound like the action is part of
dispatching the event, and that there are a couple events which break this
rule (onclick; I think there are one or two others). Reading
http://dom.spec.whatwg.org/#dispatching-events helps make this clear--it
never talks about a default action, it just tells the caller if
preventDefault() was called.
Anne: Something else that might help is speccing how the weird click-like
events work. Those really do need a default action (though it should
probably be called something else, too much confusion over that phrase),
and there could be a big bold for web-compatibility use only warning next
to it. I don't know if it'll help, but it seems like the event model needs
a hook for this anyway.
Is there any way for the .clipboardData object to get reused (eg. where
the
.changed flag would be set to true from a previous event)?
Well, I guess it's always possible to have an event listener call
dispatchEvent() on some other element, passing the same event object.. Not
sure if that matters?
As long as the implicit default behavior is removed this will have no
effect, since the only place this flag would be checked is after a real
event dispatch.
Checking whether the DataTransfer has data in it could work, too. I
assumed that it would be pre-filled with the user's selection, and calling
setData() would just replace it. By the way, what's the reason for not
doing it that way? It seems to make everything simpler: it's always the
contents of .clipboardData that's being copied, .clipboardData is initially
set to the selection (resulting in no change to behavior if you don't touch
.clipboardData), and you never have to preventDefault() to change what's
copied. I guess it assumes that any selection that the UA can support for
copy can be represented in DataTransfer, but that seems like it could be
dealt with (not every detail of the selection necessarily needs to be
script-visible in the DataTransfer).
--
Glenn Maynard
Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
I think I'd suggest avoiding the mess of execCommand altogether, and add new methods, eg. window.copy() and window.cut() (or maybe just one method, with a cut option). execCommand is such a nonsensical way to expose an API that trying to stay consistent with its commands is probably not much of a win. On Tue, May 20, 2014 at 5:11 AM, Hallvord R. M. Steen hst...@mozilla.com wrote: However, if a scripted copy event can't take a payload and have it placed on the clipboard, what's the point of making script-generated copy events possible in the first place? If there's no point I'd rather disallow them. This seems like you don't like an aspect of the DOM event model, so you want it to behave differently when used with your API. :) There's nothing special about copy for it to behave differently from other events, and the other events on the platform can be generated by script. On Tue, May 20, 2014 at 5:48 AM, Anne van Kesteren ann...@annevk.nl wrote: How is it true for click? (We clarified this out of band. Dispatching click does cause navigation, but you have to use new MouseEvent. This is a weird exceptional case and should be ignored when designing new features.) -- Glenn Maynard
[clipboard events] click-to-copy support could be hasFeature discoverable?
Hi,
I'm about to file a bug on implementing click-to-copy and click-to-cut per
latest clipboard events spec in Gecko / Firefox, and this reminds me we haven't
yet answered the question about discoverability. This functionality has a
fallback story (Flash shims for platforms with Flash support, creating a dialog
to tell the user to ctrl-c or ctrl-x manually otherwise) but there's not much
point in fallback possibilities if support isn't discoverable.
What about hasFeature()? It's sort of not popular these days - because
discovering APIs and methods directly is a much better way to do it. But if, as
in this case, there is no special method or object to detect, I guess
hasFeature() is acceptable as a fallback?
It would be nice if we could just do
if(document.implementation.hasFeature('click-to-copy'))
or alternatively
if('ClipboardEvent' in window
document.implementation.hasFeature('click-to-copy'))
to make sure both constructor and security permission is implemented.
(I know hasFeature() usually takes a version number argument too, would be nice
if it can be omitted when not necessary..)
Questions:
1) Is this a good idea?
2) What's the spec supposed to say to invoke hasFeature() and define a
feature string for its argument list?
-Hallvord
Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
On Mon, May 19, 2014 at 3:09 PM, Hallvord R. M. Steen hst...@mozilla.com wrote: Questions: 1) Is this a good idea? 2) What's the spec supposed to say to invoke hasFeature() and define a feature string for its argument list? hasFeature() is pretty much killed (always returns true). Why can't this feature be discovered? The clipboard cannot be made readable when you just copied to it using this technique? -- http://annevankesteren.nl/
[clipboard events] implicitly prevent default event action?
Hi,
there's a very annoying gotcha in the clipboard events spec: the default
action of for example the copy event is to copy any selected text in the page
(and do nothing if there is no selection). This remains the default action even
if you use event.clipboardData.setData() and friends to modify the payload -
it's a requirement to also call event.preventDefault() to make what you want to
happen actually happen.
This extra event.preventDefault() is something I've personally forgotten to
do several times - which is a bit embarrassing as I should be expected to know
:-p. But worse than that is that regular web developers are likely to run into
this pretty often too. I guess lots of people will struggle a bit here, and few
of them will understand why it is even necessary.
So, is it necessary? IMO we can't change this basic
default-action-of-event-is-copying-content approach, for backwards
compatibility. But I guess we could say that the implementation itself cancels
the default event if
a) The event is script-generated and has a data payload (new
ClipboardEvent('copy', {dataType:'text/plain', data:'Hi World'}))
b) Any event listener calls setData() or modifies the DataTransfer payload some
other way
Thoughts?
-Hallvord
Re: [clipboard events] implicitly prevent default event action?
On Mon, May 19, 2014 at 3:50 PM, Hallvord R. M. Steen
hst...@mozilla.com wrote:
a) The event is script-generated and has a data payload (new
ClipboardEvent('copy', {dataType:'text/plain', data:'Hi World'}))
b) Any event listener calls setData() or modifies the DataTransfer payload
some other way
Thoughts?
Can you sanely explain those using a JavaScript implementation or
would that be some kind of weird stack-inspecting feature?
The current model is something like
if(node.dispatchEvent(obj))
defaultAction()
I guess you could put another check before defaultAction() so that
would probably work...
--
http://annevankesteren.nl/
RE: [clipboard events] implicitly prevent default event action?
From: annevankeste...@gmail.com annevankeste...@gmail.com on behalf of Anne
van Kesteren ann...@annevk.nl
Can you sanely explain those using a JavaScript implementation or would that
be some kind of weird stack-inspecting feature?
My impression was that it would be something like:
if (data) {
this.preventDefault();
}
in the constructor, and
this.[[parentEvent]].preventDefault();
inside the definition of DataTransfer.prototype.setData (which thus has to
retain a private reference to its parent event).
The latter might be tricky to monkey-patch into HTML, but the former at least
seems straightforward.
Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
Why can't this feature be discovered? The clipboard cannot be made readable when you just copied to it using this technique? How would that be discoverable? The feature would have to be supported and triggered by a user before the status would be known. If the feature wasn't supported, we would never know. Sincerely, James Greene On Mon, May 19, 2014 at 8:18 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, May 19, 2014 at 3:09 PM, Hallvord R. M. Steen hst...@mozilla.com wrote: Questions: 1) Is this a good idea? 2) What's the spec supposed to say to invoke hasFeature() and define a feature string for its argument list? hasFeature() is pretty much killed (always returns true). Why can't this feature be discovered? The clipboard cannot be made readable when you just copied to it using this technique? -- http://annevankesteren.nl/
Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
hasFeature() is pretty much killed (always returns true).
That sort of sucks .. I know the argument against it but the question I'm
looking at now shows that not all features are suitable for feature detection -
in this particular case because the whole point of the feature is about user
interaction, and without user interaction you can't detect it.
Is the always returns true part also widely implemented now? If the default
were false it could still be useful in odd cases like this one.
Why can't this feature be discovered? The clipboard cannot be made
readable when you just copied to it using this technique?
Hm.. How would that work? You would end up with something like this:
button.onclick = function(){
button.dispatchEvent(new ClipboardEvent('copy', {dataType:'text/plain',
data:'Hello world'});
// did that succeed or not? We don't have event.clipboardData on a clip
event object
button.addEventListener('paste', function(e){
if(e.clipboardData.getData('text/plain') !== 'Hello world'){
makeFlashFallbackButton();
alert('Sorry, copy failed - please click the button again');
}
button.removeEventListener('paste', arguments.callee, false);
}, false);
button.dispatchEvent(new ClipboardEvent('paste'));
}
and you'd still have issues because
1) Synthetic paste events are not covered by click-to- logic, but by a real
preference the user must toggle. And no, you can't discover if the preference
is set, and that's by design. Isn't it totally weird even for users who have
some understanding of what's going on if the UA pops up a do you want to allow
paste dialog when you try to click a button to copy something?
2) The UI for copy/cut would totally suck with this approach - Sorry, first
time you clicked the copy button it failed - please click it again..?
3) You might have both false positives (the data on the clipboard just happened
to be the same string you tried to copy) and false negatives (another app
happened to overwrite the clipboard between your copy event and your paste
event). Granted both are extreme corner cases..
It's almost more elegant to add a dedicated discoverability property on the
ClipboardEvent constructor.
if(window.ClipboardEvent ClipboardEvent.clickToCutAndCopyEnabled)
but it's not exactly beautiful and there's no precedence for this in the
platform AFAIK.
Any better idea?
-Hallvord
Re: [clipboard events] implicitly prevent default event action?
Can you sanely explain those using a JavaScript implementation or would that
be some kind of weird stack-inspecting feature?
My impression was that it would be something like:
if (data) {
this.preventDefault();
}
Domenic: thanks for explaining, that's pretty much exactly what I'm thinking of.
It's annoying and/or ugly that the code would have to be a bit scattered -
given that we've grown the DataTransfer API beyond the setData() approach,
there are several methods that could modify what goes on the clipboard, and to
do this right calling any of them would have to trigger a preventDefault() at
some point before the dispatch. So from the implementation point of view, it's
a clumsy thing to do - but it would significantly simplify usage of the API..
-Hallvord
Re: [clipboard events] implicitly prevent default event action?
On Mon, May 19, 2014 at 8:50 AM, Hallvord R. M. Steen hst...@mozilla.comwrote:
a) The event is script-generated and has a data payload (new
ClipboardEvent('copy', {dataType:'text/plain', data:'Hi World'}))
I'm a little confused. Script-generated events never have a default
action, except for a couple isolated web-compatibility hacks where
dispatching an event in script has side-effects, like click. As far as I
can tell, clipboard events (tested copy and paste) aren't in that category
in Firefox, at least (Chrome doesn't have ClipboardEvent). Can you clarify?
(Unless we're talking about events like click, I don't think we should use
the term default action at all, since it leads to a lot of confusion
about how the event model works. The canceled flag makes this clearer:
http://dom.spec.whatwg.org/#canceled-flag)
b) Any event listener calls setData() or modifies the DataTransfer payload
some other way
Put a changed flag on clipboardData, which is set to true by
setData. (This flag doesn't have to be visible to script.) When the event
handler returns, copy the selected text if both preventDefault was not
called and the changed flag on clipboardData isn't set. That is, the UA
behavior looks like this:
var dataTransfer = new DataTransfer(selectedText);
var clipboardEvent = new ClipboardEvent(copy, { clipboardData:
dataTransfer });
if(element.dispatchEvent(clipboardEvent) || dataTransfer.changed)
copyTextToClipboard(dataTransfer);
This avoids having any weird interactions between DataTransfer and the
event system, and it's trivial to explain in terms of JS.
Is there any way for the .clipboardData object to get reused (eg. where the
.changed flag would be set to true from a previous event)?
--
Glenn Maynard
Re: [clipboard events] click-to-copy support could be hasFeature discoverable?
On Mon, May 19, 2014 at 9:21 PM, Hallvord R. M. Steen hst...@mozilla.com wrote: (...) Any better idea? -Hallvord Well, since you need might a new API (because the fallback is just so nasty and detection is not trivial), dump it somewhere like in the navigator object: navigator.myClipboardFeatureEnabled
RE: [clipboard events] Pasting scenarios and the shape of clipboardData.getData(‘text/html’) return value
Also on Mac, there is no !--StartFragment-- and !--EndFragment-- and the serialized markup copied into the clipboard (called pasteboard on Mac) needs to contain the precisely the markup that got copied by the user. Good point. Perhaps we should make sure any OS specific items like !--StartFragment-- are not visible in developer APIs. It has a few implications but one of which is that we need to serialize some semantic elements such as a and h1 when a part of content inside such an element is selected because we don't want to simply copy the content with blue text and underline for a for example. User expects the pasted content to be a functional hyperlink if it looks like an anchor. Even elements such as b may need to be treated special because inside a contenteditable region where styleWithCSS is false, we don't want copying and pasting the content already in the contenteditable to introduce inline styles or a new style element. There are other problems with more exotic features of HTML and CSS. Another problem we recently found is that when the copied content contains position: fixed or position: sticky, we need to convert them to position: absolute and wrap the whole copied content with a position: relative box in order to prevent the pasted content to populate the paste destination. In general, it is my opinion that copy algorithm should be spec'ed at the same time as paste algorithm in the HTML Editing API, and both of them are extremely challenging task. I would say we should start by defining the shape of the html DataTransferItem rather than the way browsers should handle specific markup. So to be clearer on that, on copy, the DataTransferItem should have this shape: html head style List of styles that apply to the markup. Classes are named copiedStyle_uniqueID /style body Copied markup /body /html Then on paste, the DataTransferItem should contain everything on the clipboard, possibly minus OS specific things like !--StartFragment--. This way developers can generally count on being able to expect a full html page being available on paste, with hard styles (inline styles) in the markup, and theme styles (from the cascade) being available in the head. Implementations that don't have extra styling information in the head or inline the styles in the body don't break the model, they just don't allow the same level of control on paste.
Re: [clipboard events] Pasting scenarios and the shape of clipboardData.getData(‘text/html’) return value
On Apr 7, 2014, at 3:37 PM, Ben Peters ben.pet...@microsoft.com wrote:
After working with developers inside and outside Microsoft, it seems
there are several types of paste that make sense in various scenarios.
For instance,
1- if pasting into a rich document, it could be important to maintain
source styling information.
2- When pasting into a wiki from an external source, it might make more
sense to maintain destination styling instead.
3- When copying from a wiki and pasting back into that same wiki, it
makes sense to maintain any special formatting on that text (inline
styles) but otherwise to use the theme (style sheets).
There is one other scenario here, which is to maintain the html shape, but
not any styles.
4- When seeking to maintain lists and tables, but format them with
destination styles, it makes sense to remove style elements and style rules,
but keep other html ( li and table for instance ).
Right, that's an important use case to address.
One possibility would be to do something similar to Firefox, but also
include a text/css clipboard item, which contains styles relevant to
what is copied
How hard do you think this is to implement?
Thanks for the code sample and thoughts! I'll run it by a few more
developers to get deeper insight and get back to you.
Great! Note that the code samples are just to get us started thinking about
the issues we'll have to tackle if we're going to do this - if some other
behaviour (say,
creating new class names and making up a new style sheet with
generated/computed styles) is easier to implement or seems to make more
sense by all means
suggest that other behaviour instead.
In order to support the 4 scenarios I mentioned above, we need to be able to
distinguish inline css from style sheets. Your idea here about creating a new
style sheet seems like a good way to go since it helps solve the selectors
problem where css doesn't work the same once you remove the context by
copying a section out, and it keeps the inline styles separate from the style
sheets. We could include this styles in the head of the document or in a new
text/css item.
On copy, we would take something like Chrome's algorithm to get relevant css
for each element. For top-level elements, this would mean several rules by
default to 'reset' the style, and anything other relevant styles. We would
create a new class for each unique set of computed styles and give it a name
that can be recognized and unique, maybe copiedStyle_randomid where
randomid is a guid or similar. We would also remove any inline style
elements like Chrome/Firefox already do. So on copy you would get something
like this on the clipboard:
Version:0.9
StartHTML:000157
EndHTML:03
StartFragment:01
EndFragment:02
SourceURL:http://en.wikipedia.org/wiki/Darth_vader
html
head
style
.copiedStyle_12345 {
color: black; background-image: none; font-weight: normal; margin: 0px
0px 0.25em; overflow: hidden; padding: 0px; border-bottom-width: 1px;
border-bottom-style: solid; border-bottom-color: rgb(170, 170, 170);
font-size: 1.8em; line-height: 1.3; font-family: 'Linux Libertine', Georgia,
Times, serif; font-style: normal; font-variant: normal; letter-spacing:
normal; orphans: auto; text-align: start; text-indent: 0px; text-transform:
none; white-space: normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px; background-position: initial initial;
background-repeat: initial initial;
}
/style
/head
body
!--StartFragment--h1 id=firstHeading class=copiedStyle_12345
firstHeading lang=enspan dir=autoDarth
Vader/span/h1!--EndFragment--
/body
/html
Somewhat tricky issue here is that when this content is pasted into some page,
that page may also have other CSS rules defined. Depending on selectors they
use, they might have a higher precedence than the single class name we use in
the copied content. We could add !important to each property but that could
cause an issue if the pasted content is later edited, say, inside a
contenteditable region.
Then during copy, the text/html element would return all of this data (or the
style would be in text/css instead). My devs believe having one text/html
item (instead of text/css) would make it easier to get an element (by
document.write for instance) that could be used with querySelector etc. Then
javascript could handle scenarios 2-4 above easily by keeping or removing
inline styles and elements, and 1 above could be done by calling
querySelectorAll for each copiedStyle_* class and inlining those styles like
Chrome does by default. Other style classes (like 'firstHeading' here) can be
kept so that if you paste back into the same page, they apply again and you
don't need to inline anything.
This means copy works like firefox + new classes to track styles that Chrome
would currently inline. Paste works
RE: [clipboard events] Pasting scenarios and the shape of clipboardData.getData(‘text/html’) return value
After working with developers inside and outside Microsoft, it seems there
are several types of paste that make sense in various scenarios. For
instance,
1- if pasting into a rich document, it could be important to maintain
source styling information.
2- When pasting into a wiki from an external source, it might make more
sense to maintain destination styling instead.
3- When copying from a wiki and pasting back into that same wiki, it makes
sense to maintain any special formatting on that text (inline styles) but
otherwise to use the theme (style sheets).
There is one other scenario here, which is to maintain the html shape, but not
any styles.
4- When seeking to maintain lists and tables, but format them with destination
styles, it makes sense to remove style elements and style rules, but keep other
html ( li and table for instance ).
One possibility would be to do something similar to Firefox, but also
include a text/css clipboard item, which contains styles relevant to
what is copied
How hard do you think this is to implement?
Thanks for the code sample and thoughts! I'll run it by a few more
developers to get deeper insight and get back to you.
Great! Note that the code samples are just to get us started thinking about
the issues we'll have to tackle if we're going to do this - if some other
behaviour (say,
creating new class names and making up a new style sheet with
generated/computed styles) is easier to implement or seems to make more sense
by all means
suggest that other behaviour instead.
In order to support the 4 scenarios I mentioned above, we need to be able to
distinguish inline css from style sheets. Your idea here about creating a new
style sheet seems like a good way to go since it helps solve the selectors
problem where css doesn't work the same once you remove the context by copying
a section out, and it keeps the inline styles separate from the style sheets.
We could include this styles in the head of the document or in a new text/css
item.
On copy, we would take something like Chrome's algorithm to get relevant css
for each element. For top-level elements, this would mean several rules by
default to 'reset' the style, and anything other relevant styles. We would
create a new class for each unique set of computed styles and give it a name
that can be recognized and unique, maybe copiedStyle_randomid where
randomid is a guid or similar. We would also remove any inline style elements
like Chrome/Firefox already do. So on copy you would get something like this on
the clipboard:
Version:0.9
StartHTML:000157
EndHTML:03
StartFragment:01
EndFragment:02
SourceURL:http://en.wikipedia.org/wiki/Darth_vader
html
head
style
.copiedStyle_12345 {
color: black; background-image: none; font-weight: normal; margin: 0px
0px 0.25em; overflow: hidden; padding: 0px; border-bottom-width: 1px;
border-bottom-style: solid; border-bottom-color: rgb(170, 170, 170); font-size:
1.8em; line-height: 1.3; font-family: 'Linux Libertine', Georgia, Times, serif;
font-style: normal; font-variant: normal; letter-spacing: normal; orphans:
auto; text-align: start; text-indent: 0px; text-transform: none; white-space:
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-position: initial initial; background-repeat: initial initial;
}
/style
/head
body
!--StartFragment--h1 id=firstHeading class=copiedStyle_12345
firstHeading lang=enspan dir=autoDarth
Vader/span/h1!--EndFragment--
/body
/html
Then during copy, the text/html element would return all of this data (or the
style would be in text/css instead). My devs believe having one text/html item
(instead of text/css) would make it easier to get an element (by document.write
for instance) that could be used with querySelector etc. Then javascript could
handle scenarios 2-4 above easily by keeping or removing inline styles and
elements, and 1 above could be done by calling querySelectorAll for each
copiedStyle_* class and inlining those styles like Chrome does by default.
Other style classes (like 'firstHeading' here) can be kept so that if you paste
back into the same page, they apply again and you don't need to inline anything.
This means copy works like firefox + new classes to track styles that Chrome
would currently inline. Paste works like Chrome (the text/html item returns all
of the clipboard's html text). End to end, we enable the major scenarios we
have identified of for copy/paste.
Ultimately I believe the goal of this feature is just to enable functionality
in an interoperable way. To make it easier to use, js frameworks could make a
document object available (instead of plain text), or provide functions to
accomplish 1-4 (and other paste types). Thoughts?
Re: [clipboard events] Pasting scenarios and the shape of clipboardData.getData(‘text/html’) return value
How hard do you think this is to implement? Thanks for the code sample and thoughts! I'll run it by a few more developers to get deeper insight and get back to you. Great! Note that the code samples are just to get us started thinking about the issues we'll have to tackle if we're going to do this - if some other behaviour (say, creating new class names and making up a new style sheet with generated/computed styles) is easier to implement or seems to make more sense by all means suggest that other behaviour instead. -Hallvord
RE: [clipboard events] Pasting scenarios and the shape of clipboardData.getData(‘text/html’) return value
One possibility would be to do something similar to Firefox, but also include a text/css clipboard item, which contains styles relevant to what is copied This seems like an excellent idea! I'm not sure how hard it is to implement, but it might be doable without too much effort. Some examples to make sure we're in general agreement: ... How hard do you think this is to implement? Thanks for the code sample and thoughts! I'll run it by a few more developers to get deeper insight and get back to you.
Re: [clipboard events] Pasting scenarios and the shape of clipboardData.getData(‘text/html’) return value
After working with developers inside and outside Microsoft, it seems there are
several types of paste that make sense in various scenarios. For instance,
1- if pasting into a rich document, it could be important to maintain source
styling information.
2- When pasting into a wiki from an external source, it might make more sense
to maintain destination styling instead.
3- When copying from a wiki and pasting back into that same wiki, it makes
sense
to maintain any special formatting on that text (inline styles) but otherwise
to
use the theme (style sheets).
Good summary, thanks!
One possibility would be to do something similar to Firefox, but also include
a
text/css clipboard item, which contains styles relevant to what is copied
This seems like an excellent idea! I'm not sure how hard it is to implement,
but it might be doable without too much effort. Some examples to make sure
we're in general agreement:
## Copy paragraph with class name and styling:
Document:
style.foo{border: thin solid green}.bar{border: thin solid blue}/style
p class=fooHello world/p
The text Hello world is selected and copied. Data types on the clipboard (as
seen through the clipboard API on paste):
text/html: p class=fooHello world/p
text/css: .foo{border: thin solid green}
## Copy part of paragraph with class name and styling:
Same document, the word Hello is copied. Clipboard contents:
text/html: p class=fooHello/p
text/css: .foo{border: thin solid green}
## When some styles are overridden by more specific ones, all matching
selectors' declarations will still be copied
Document:
style.foo{border: thin solid green}#bar{border: thin solid blue}/style
p class=foo id=barHello world/p
Copy Hello world, clipboard:
text/html: p class=foo id=barHello world/p
text/css: .foo{border: thin solid green}#bar{border: thin solid blue}
## Inline style attributes are kept
Document:
style.foo{border: thin solid green}#bar{border: thin solid blue}/style
p class=foo id=bar style=border: 5px solid redHello world/p
Copy Hello world, clipboard:
text/html: p class=foo id=bar style=border: 5px solid redHello world/p
text/css: .foo{border: thin solid green}#bar{border: thin solid blue}
How hard do you think this is to implement?
-Hallvord
[clipboard events] Pasting scenarios and the shape of clipboardData.getData(‘text/html’) return value
After working with developers inside and outside Microsoft, it seems there are
several types of paste that make sense in various scenarios. For instance,
1- if pasting into a rich document, it could be important to maintain source
styling information.
2- When pasting into a wiki from an external source, it might make more sense
to maintain destination styling instead.
3- When copying from a wiki and pasting back into that same wiki, it makes
sense to maintain any special formatting on that text (inline styles) but
otherwise to use the theme (style sheets).
So this is a complex problem to solve. From what I can tell, Firefox removes
the document's head (and therefore style sheets) on copy, so 2 and 3 work, but
1 doesn't. Chrome inlines a certain set of styles on copy, and removes the
head, so 1 and 2 work, but 3 doesn't. IE maintains the head on copy, so all 3
can work, only by using non-standard paste APIs that require the user to allow
clipboard access. We have 3 execCommand args available- paste (for 1),
ms-PasteTextOnly (for 2), and ms-PasteContentOnly (which maintains the shape of
html markup but not styles, somewhat like 3).
In addition, the return value of getData('text/html') also varies. In Firefox,
it returns only the data between startfragment and endfragment. This again
makes sense for 2 and 3 above. In Chrome, it returns everything in the
clipboard item, which includes the head, body, and the startfragment and
endfragment, which means cleanup is required to actually put it in the DOM.
IE doesn't support this at all yet, so whenever a developer wants to change the
pasted text before it shows up in the DOM, they can't*.
We need a unified story.
One possibility would be to do something similar to Firefox, but also include a
text/css clipboard item, which contains styles relevant to what is copied and
is available on paste via getData('text/css'). Another solution might be to
build a document fragment during paste and make that available as a clipboard
item that contains styles and is easier to insert into the DOM. Thoughts?
Ben Peters
* there is actually a way to do this, but it's a hack and we're trying to solve
it. Currently several implementations actually move the focus to a hidden
iframe, allow the paste to run, clean up the new DOM, and then move it to where
the paste happened. This causes issues because the focus is moving around, and
it's generally ugly.
RE: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data
Hi Daniel, I'm trying to make sure I correctly understand how the IE11 version of this works. From the sample (http://msdn.microsoft.com/en-us/library/ie/dn254935(v=vs.85).aspx), it looks like if a user pastes in some HTML that references local images, IE11 automatically captures the referenced files into the clipboard. Then the page uses msConvertUrl() rewrites references to the src attributes in the text/html DataTransferItem to reference the blob URLs, right? Given that the drag data store is in read only mode at this point, it seems weird to allow mutations at this point. My understanding was that read only was intended to keep sites from changing the system clipboard outside of cut/copy events. We don’t change the system clipboard, only the pasted html. Sites could easily change it right after the paste happens, so we're saving them a step. In addition, from a security perspective, what stops a malicious website from embedding something like img src=file:///etc/passwd style=display:none/img in the markup? We disallow this on copy by stripping such references.
Re: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data
On Wed, Feb 12, 2014 at 1:25 AM, Hallvord R. M. Steen hst...@mozilla.comwrote:
Hi Hallvord!
Hi Ben! Thanks for responding to my request for feedback - especially
since the IE team has done some interesting work in this area and is
arguably ahead of the rest! :-)
The IE11 API you mentioned is msConvertURL [1] (also on the IE blog
[2]), and it was designed as a
simple way for sites to choose DataURI or Blob for otherwise
inaccessible images.
X
As you mention, it is not possible to tell which file/image corresponds
to which img because it’s
really designed as a simple approach for cases where a site wants to
always use blob or dataURI for
images that they couldn’t otherwise access.
That's more or less what I thought, based on the blog post, so thanks for
describing it in detail.
We are considering doing the CID approach as well in the future. It is
nice to have the additional
control of seeing which img src you are changing, and it will likely
work better for copy, not just
paste like convertURL.
Actually, I haven't truly considered the copy case here yet. I've sort of
assumed that given that you can put multiple bits of data on a clipboard,
the various clipboard implementations should already have a way one piece
of data can reference one specific other piece of data - I haven't really
found the technical details here.
I don't actually know of any native clipboard formats that allow data
associated with one format to reference other data in the same operation,
so browsers would have to roll their own implementation/figure out how to
get it to work well with native apps.
Of course it would be nice to support a script that wants to generate
random HTML with embedded files to place on the clipboard (although I think
most of those use cases can already be met by using URLs and assuming that
any software reading HTML from the clipboard can understand URLs..).
However, one can imagine a use case for example with a CANVAS app where the
script wants to copy the state of the CANVAS as an image inside HTML it
places on the clipboard - having the script create src=cid:n type markup,
append files, and make the UA translate that to the platform's native
clipboard implementation's way of referencing one part on the clipboard
from another part..
We believe that convertURL does not block using the CIDs you have in the
current spec.
I suppose not, but perhaps the more relevant question is: should we
standardise convertURL? Would it still have a use case if we take the cid:
route? (And I guess a related question is: given that we've done data: URLs
for a while, how much content will we break if, say, Firefox moves from
data: to cid:? Do we need to make cid: opt-in somehow, like you're doing
with convertURL?)
I'm trying to make sure I correctly understand how the IE11 version of this
works. From the sample (
http://msdn.microsoft.com/en-us/library/ie/dn254935(v=vs.85).aspx), it
looks like if a user pastes in some HTML that references local images, IE11
automatically captures the referenced files into the clipboard. Then the
page uses msConvertUrl() rewrites references to the src attributes in the
text/html DataTransferItem to reference the blob URLs, right?
Given that the drag data store is in read only mode at this point, it
seems weird to allow mutations at this point.
In addition, from a security perspective, what stops a malicious website
from embedding something like img src=file:///etc/passwd
style=display:none/img in the markup?
To better understand your approach and allow us to help move it forward,
can you give us sample
javascript that a site would use to set the DataTransferItems for HTML
and the related images during copy?
As I said, I have not really considered this use case - so the spec
doesn't actually cover this. If we want to make this work, I suppose the JS
would look somewhat like this?
document.addEventListener('copy', function(e){
// So, you want to copy the current status of your game? No
problem.
// Let's say this game generates a number of PNG graphics from
CANVAS tags
// and keeps them in memory in ArrayBuffers or something
var html = 'divbplayer/b\'s medals: img src=cid:1img
src=cid:2/div';
e.clipboardData.items.add(html, 'text/html');
e.clipboardData.items.add(new File(medals[0], 'medal.png',
{type:'image/png'}));
e.clipboardData.items.add(new File(medals[1], 'medal.png',
{type:'image/png'}));
e.preventDefault();
}, false);
Second, can you provide the javascript for how a site would put them
into the pasted markup during paste?
The way I thought this would work, would be that the site starts XHR
uploads from the paste processing, and shows some intermediate 'loading'
animation or something before it gets the final URLs back from the server.
A bit like this (although some things could be more elegant, like the
insertion of
RE: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data
Second, can you provide the javascript for how a site would put them into the pasted markup during paste? The way I thought this would work, would be that the site starts XHR uploads from the paste processing, and shows some intermediate 'loading' animation or something before it gets the final URLs back from the server. This generally makes sense. If sites prefer to use local dataURI or blob, they can use the blob URL, and then upload the file later (like in an email scenario). This means they don't have to wait for them to be on the server before displaying them. If they want to upload them first and use the server's new URL for them, they would need to do what you're saying. Sounds good, but this requires standardising something similar to msConvertURL(), right? I don't believe so. Couldn't the site just get the HTML DataTransferItem (which contains the CIDs), replace the CIDs with Blobs or DataURIs, and then insert the HTML where the paste was going to happen? Personally I think msConvertURL is a convenient way to do this. But it's not the only way. -Ben
RE: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data
Of course it would be nice to support a script that wants to generate random
HTML with embedded files to place on the clipboard (although I think most of
those use cases can already be met by using URLs and assuming that any
software reading HTML from the clipboard can understand URLs..). However, one
can imagine a use case for example with a CANVAS app where the script wants
to copy the state of the CANVAS as an image inside HTML it places on the
clipboard - having the script create src=cid:n type markup, append files,
and make the UA translate that to the platform's native clipboard
implementation's way of referencing one part on the clipboard from another
part..
I was thinking about images that aren't available cross-domain, like Facebook
pictures. If you copy them, Facebook could use CID to place them on the
clipboard since a Facebook URL wouldn’t be accessible to an email client that
receives the pasted content.
document.addEventListener('copy', function(e){
// So, you want to copy the current status of your game? No problem.
// Let's say this game generates a number of PNG graphics from CANVAS
tags
// and keeps them in memory in ArrayBuffers or something
var html = 'divbplayer/b\'s medals: img src=cid:1img
src=cid:2/div';
e.clipboardData.items.add(html, 'text/html');
e.clipboardData.items.add(new File(medals[0], 'medal.png',
{type:'image/png'}));
e.clipboardData.items.add(new File(medals[1], 'medal.png',
{type:'image/png'}));
e.preventDefault();
}, false);
This seems like we're depending on add() working in a precise order, which
seems vulnerable to code changes or other issues. Maybe add() should return the
location in the list where the item was added, and then it can be used with CID
more safely? I know this is part of HTML5 not ClipboardAPI though. Thoughts?
Second, can you provide the javascript for how a site would put them into the
pasted markup during paste?
The way I thought this would work, would be that the site starts XHR uploads
from the paste processing, and shows some intermediate 'loading' animation or
something before it gets the final URLs back from the server. A bit like this
(although some things could be more elegant, like the insertion of the data
which needs to take cursors and selections into account):
http://jsfiddle.net/2Qqrp/
Thinking about it, it may be considered somewhat wasteful (or exceedingly
slow - if for example the embedded data is a video) to do it this way - but
it quickly gets complex and/or confusing if we have a some show this local
file until it's uploaded, then reference the online file instead magic..?
This generally makes sense. If sites prefer to use local dataURI or blob, they
can use the blob URL, and then upload the file later (like in an email
scenario). This means they don't have to wait for them to be on the server
before displaying them. If they want to upload them first and use the server's
new URL for them, they would need to do what you're saying.
-Ben
Re: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data
Of course it would be nice to support a script that wants to generate random
HTML with embedded files
X
use case for example with a CANVAS app where the script wants to copy the
state of the CANVAS
I was thinking about images that aren't available cross-domain
Indeed, that's another use case which is pretty important.
document.addEventListener('copy', function(e){
// So, you want to copy the current status of your game? No problem.
// Let's say this game generates a number of PNG graphics from CANVAS
tags
// and keeps them in memory in ArrayBuffers or something
var html = 'divbplayer/b\'s medals: img src=cid:1img
src=cid:2/div';
e.clipboardData.items.add(html, 'text/html');
e.clipboardData.items.add(new File(medals[0], 'medal.png',
{type:'image/png'}));
e.clipboardData.items.add(new File(medals[1], 'medal.png',
{type:'image/png'}));
e.preventDefault();
}, false);
This seems like we're depending on add() working in a precise order, which
seems vulnerable
to code changes or other issues. Maybe add() should return the location in
the list where
the item was added, and then it can be used with CID more safely?
That is a good observation and a very good suggestion! We should suggest a
change to the HTML spec.
Second, can you provide the javascript for how a site would put them into
the pasted markup during paste?
The way I thought this would work, would be that the site starts XHR uploads
from the paste processing,
and shows some intermediate 'loading' animation or something before it gets
the final URLs back from the server.
This generally makes sense. If sites prefer to use local dataURI or blob,
they can use the blob URL, and then
upload the file later (like in an email scenario). This means they don't have
to wait for them to be on the
server before displaying them. If they want to upload them first and use the
server's new URL for them,
they would need to do what you're saying.
Sounds good, but this requires standardising something similar to
msConvertURL(), right?
-Hallvord
Re: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data
Hi Hallvord!
Hi Ben! Thanks for responding to my request for feedback - especially since the
IE team has done some interesting work in this area and is arguably ahead of
the rest! :-)
The IE11 API you mentioned is msConvertURL [1] (also on the IE blog [2]), and
it was designed as a
simple way for sites to choose DataURI or Blob for otherwise inaccessible
images.
X
As you mention, it is not possible to tell which file/image corresponds to
which img because it’s
really designed as a simple approach for cases where a site wants to always
use blob or dataURI for
images that they couldn’t otherwise access.
That's more or less what I thought, based on the blog post, so thanks for
describing it in detail.
We are considering doing the CID approach as well in the future. It is nice
to have the additional
control of seeing which img src you are changing, and it will likely work
better for copy, not just
paste like convertURL.
Actually, I haven't truly considered the copy case here yet. I've sort of
assumed that given that you can put multiple bits of data on a clipboard, the
various clipboard implementations should already have a way one piece of data
can reference one specific other piece of data - I haven't really found the
technical details here.
Of course it would be nice to support a script that wants to generate random
HTML with embedded files to place on the clipboard (although I think most of
those use cases can already be met by using URLs and assuming that any software
reading HTML from the clipboard can understand URLs..). However, one can
imagine a use case for example with a CANVAS app where the script wants to copy
the state of the CANVAS as an image inside HTML it places on the clipboard -
having the script create src=cid:n type markup, append files, and make the UA
translate that to the platform's native clipboard implementation's way of
referencing one part on the clipboard from another part..
We believe that convertURL does not block using the CIDs you have in the
current spec.
I suppose not, but perhaps the more relevant question is: should we standardise
convertURL? Would it still have a use case if we take the cid: route? (And I
guess a related question is: given that we've done data: URLs for a while, how
much content will we break if, say, Firefox moves from data: to cid:? Do we
need to make cid: opt-in somehow, like you're doing with convertURL?)
To better understand your approach and allow us to help move it forward, can
you give us sample
javascript that a site would use to set the DataTransferItems for HTML and
the related images during copy?
As I said, I have not really considered this use case - so the spec doesn't
actually cover this. If we want to make this work, I suppose the JS would look
somewhat like this?
document.addEventListener('copy', function(e){
// So, you want to copy the current status of your game? No problem.
// Let's say this game generates a number of PNG graphics from CANVAS
tags
// and keeps them in memory in ArrayBuffers or something
var html = 'divbplayer/b\'s medals: img src=cid:1img
src=cid:2/div';
e.clipboardData.items.add(html, 'text/html');
e.clipboardData.items.add(new File(medals[0], 'medal.png',
{type:'image/png'}));
e.clipboardData.items.add(new File(medals[1], 'medal.png',
{type:'image/png'}));
e.preventDefault();
}, false);
Second, can you provide the javascript for how a site would put them into the
pasted markup during paste?
The way I thought this would work, would be that the site starts XHR uploads
from the paste processing, and shows some intermediate 'loading' animation or
something before it gets the final URLs back from the server. A bit like this
(although some things could be more elegant, like the insertion of the data
which needs to take cursors and selections into account):
http://jsfiddle.net/2Qqrp/
Thinking about it, it may be considered somewhat wasteful (or exceedingly slow
- if for example the embedded data is a video) to do it this way - but it
quickly gets complex and/or confusing if we have a some show this local file
until it's uploaded, then reference the online file instead magic..?
-Hallvord
RE: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data
Hi Hallvord!
The IE11 API you mentioned is msConvertURL [1] (also on the IE blog [2]), and
it was designed as a simple way for sites to choose DataURI or Blob for
otherwise inaccessible images. We default to DataURI to be interoperable with
Firefox’s current design of always doing DataURI for local images on the
clipboard. With a little bit of code, blobs can be used instead. Our
clipboardData.files implementation contains only images at the moment because
we have only partial support of the current version of the Clipboard API spec.
This means that with a quick ‘for’ loop over those images, javascript can
choose to create blobs, manage the blob’s memory, and upload the blobs to a
server. As you mention, it is not possible to tell which file/image corresponds
to which img because it’s really designed as a simple approach for cases
where a site wants to always use blob or dataURI for images that they couldn’t
otherwise access.
We are considering doing the CID approach as well in the future. It is nice to
have the additional control of seeing which img src you are changing, and it
will likely work better for copy, not just paste like convertURL. We believe
that convertURL does not block using the CIDs you have in the current spec. To
better understand your approach and allow us to help move it forward, can you
give us sample javascript that a site would use to set the DataTransferItems
for HTML and the related images during copy? Second, can you provide the
javascript for how a site would put them into the pasted markup during paste?
Regarding a couple other questions you ask:
* As far as I’ve seen, WebKit/Blink do not yet support images with local-system
sources. They do support binary images on the clipboard using
ClipboardData.items like in the example I found online [3].
* Some sites prefer DataURI to Blob because it’s all inline and doesn’t require
sending separate objects or managing memory, so I don’t think DataURI is
something we should discount.
Looking forward to seeing your sample code!
Ben Peters
[1] http://msdn.microsoft.com/en-us/library/ie/dn254951(v=vs.85).aspx
[2]
http://blogs.msdn.com/b/ie/archive/2013/10/24/enhanced-rich-editing-experiences-in-ie11.aspx
[3] http://strd6.com/2011/09/html5-javascript-pasting-image-data-in-chrome/
-Original Message-
From: Hallvord R. M. Steen [mailto:hst...@mozilla.com]
Sent: Thursday, January 23, 2014 5:30 PM
To: public-webapps
Subject: [clipboard events] seeking implementor feedback on using CID: URI
scheme for pasting embedded binary data
Hi,
pasting HTML that contains embeds (images, video) into a rich text editor is
a use case we should cover. It's currently handled in different ways -
* IE11 supports pasting images as either data: URLs or blobs [1] (and has a
non-standard method to fill in a gap in the blob approach). I don't
understand from this blog post how/if it supports referencing the binary
parts from the HTML. If for example you paste a snippet from a Word page that
contains two images, the DataTransferItemList is presumably populated with
two image files, which can be processed/uploaded using the blob method - but
how is the script processing the data supposed to know what IMG tag in the
pasted HTML each image file belongs to?
* Pasting stuff as data: URLs seems like a hack, wasting memory and requiring
quite some extra processing if there is a lot of data.
* Firefox apparently happily passes on file:/// URLs with local paths and all
[2], this is of course a bug.
* Right now I'm not sure what WebKit/Blink - based implementations do. Test
results welcome!
As the editor of the Clipboard Events spec, I'm proposing a somewhat
different take on this: cid:-URIs for embeds. See
http://dev.w3.org/2006/webapi/clipops/clipops.html (search for cid:).
The idea is that rather than embedding potentially very huge data: URLs or
reference local files in the embedded markup, we add a reference to the
DataTransferItemList, and use the index of this reference to construct a cid:
URI in the markup that clipboardEvent.getData('text/html') will see. The
script processing this data can then pull out the cid: URIs, do drag-and-drop
style file uploads for referenced clipboard parts, and update the data to
refer to the locations on the server eventually (maybe first using an
intermediate placeholder image or something like that.)
AFAIK, outside of the used in HTML intended for E-mail, this would be the
first usage of CID: URIs in web platform specs. I'm looking for feedback
regarding whether this is implementable and a good solution. I haven't had
much (if any) feedback from implementors on this issue yet, so thank you all
in advance for your ideas and input.
-Hallvord
[1]
http://blogs.msdn.com/b/ie/archive/2013/10/24/enhanced-rich-editing-experiences-in-ie11.aspx
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=665341
[clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data
Hi,
pasting HTML that contains embeds (images, video) into a rich text editor is a
use case we should cover. It's currently handled in different ways -
* IE11 supports pasting images as either data: URLs or blobs [1] (and has a
non-standard method to fill in a gap in the blob approach). I don't understand
from this blog post how/if it supports referencing the binary parts from the
HTML. If for example you paste a snippet from a Word page that contains two
images, the DataTransferItemList is presumably populated with two image files,
which can be processed/uploaded using the blob method - but how is the script
processing the data supposed to know what IMG tag in the pasted HTML each image
file belongs to?
* Pasting stuff as data: URLs seems like a hack, wasting memory and requiring
quite some extra processing if there is a lot of data.
* Firefox apparently happily passes on file:/// URLs with local paths and all
[2], this is of course a bug.
* Right now I'm not sure what WebKit/Blink - based implementations do. Test
results welcome!
As the editor of the Clipboard Events spec, I'm proposing a somewhat different
take on this: cid:-URIs for embeds. See
http://dev.w3.org/2006/webapi/clipops/clipops.html (search for cid:).
The idea is that rather than embedding potentially very huge data: URLs or
reference local files in the embedded markup, we add a reference to the
DataTransferItemList, and use the index of this reference to construct a cid:
URI in the markup that clipboardEvent.getData('text/html') will see. The script
processing this data can then pull out the cid: URIs, do drag-and-drop style
file uploads for referenced clipboard parts, and update the data to refer to
the locations on the server eventually (maybe first using an intermediate
placeholder image or something like that.)
AFAIK, outside of the used in HTML intended for E-mail, this would be the first
usage of CID: URIs in web platform specs. I'm looking for feedback regarding
whether this is implementable and a good solution. I haven't had much (if any)
feedback from implementors on this issue yet, so thank you all in advance for
your ideas and input.
-Hallvord
[1]
http://blogs.msdn.com/b/ie/archive/2013/10/24/enhanced-rich-editing-experiences-in-ie11.aspx
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=665341
[clipboard events] Spec update
I've just comitted a spec update with some significant changes. Please review
and discuss..
Change #1: click-to-copy and click-to-cut
Yesterdays edits introduced a concept called semi-trusted events - in order
to make script-initiated copy and cut operations just work if the script that
initiates them is run in response to user input. See
http://dev.w3.org/2006/webapi/clipops/clipops.html#semi-trusted-event
Discussion that caused this change happened on the list and in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23235
Change #2: more details (and tests for) the beforecopy, beforecut and
beforepaste events.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21696
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21697
Implementations that follow the spec will end up with a better implementation
of before* events that what Internet Explorer has, thus exceeding the (low)
expectations of web developers ;-)
Related note: the spec (and tests) already expects that the firing of
copy/cut/paste events occurs irrespectable of any cursor/selection/editable
context. So if a page with no cursor or selected text is open, and the user
presses ctrl-c, a copy event is expected to fire. If user presses ctrl-x, a cut
is expected to fire. The before* events are all about the state of UI controls,
and have no impact or whether or not actual events fire. (AFAIK both Firefox
and other teams have some work to do to make that happen as expected. We don't
have the thought reading capability to fire beforecopy if the user thinks about
pressing ctrl-c, so there's no way around that.)
Change #3 - no prior discussion, might be a bit controversial?
Synthetic (script-generated) paste events are now defined as causing paste
actions. document.execCommand('copy'|'cut'|'paste') is now from the spec's
point of view just a shortcut for generating and firing synthetic events.
There are two possible ways this works:
1) When creating synthetic clipboard events, the script can specify a data
payload. For example, the default outcome of this script:
var evt = new ClipboardEvent({data:'EHLO WORDL', dataType:'text/plain'})
document.getElementsByTagName('textarea')[0].dispatchEvent(evt)
would be to insert the text 'EHLO WORDL', as if pasted from the clipboard, into
the textarea.
2) UAs may be configured to allow scripted paste operations. In this case,
dispatching a paste event targeted at some element where data can be inserted
(input/textarea/contenteditable etc.) will by default insert the clipboard
data. However, if a data payload was specified for the event (as in the example
above), that data will be used instead of clipboard data.
Is this a good change or a bad idea? Please discuss :-)
Known issue: the Editor's draft is not currently properly cross-linked with
other specs, because I don't have a computer with Anolis set up handy right
now. I'll fix this later. For the same reason, the ED doesn't have a proper
inline table of contents.
-Hallvord
Re: [clipboard events] Spec update
I'm eager to replace our flash clipboard bridge with this native api.
Would this be the correct code to write a string to the clipboard on a
button click?
document.getElementById(copytoclipboard).addEventListener(click,
function() {
var event = new ClipboardEvent('paste', {data: 'COPIED!',
dataType: 'text/plain'});
document.dispatchEvent(event);
});
On Mon, Jan 20, 2014 at 7:55 PM, Hallvord R. M. Steen
hst...@mozilla.com wrote:
I've just comitted a spec update with some significant changes. Please review
and discuss..
Change #1: click-to-copy and click-to-cut
Yesterdays edits introduced a concept called semi-trusted events - in order
to make script-initiated copy and cut operations just work if the script
that initiates them is run in response to user input. See
http://dev.w3.org/2006/webapi/clipops/clipops.html#semi-trusted-event
Discussion that caused this change happened on the list and in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23235
Change #2: more details (and tests for) the beforecopy, beforecut and
beforepaste events.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21696
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21697
Implementations that follow the spec will end up with a better implementation
of before* events that what Internet Explorer has, thus exceeding the (low)
expectations of web developers ;-)
Related note: the spec (and tests) already expects that the firing of
copy/cut/paste events occurs irrespectable of any cursor/selection/editable
context. So if a page with no cursor or selected text is open, and the user
presses ctrl-c, a copy event is expected to fire. If user presses ctrl-x, a
cut is expected to fire. The before* events are all about the state of UI
controls, and have no impact or whether or not actual events fire. (AFAIK
both Firefox and other teams have some work to do to make that happen as
expected. We don't have the thought reading capability to fire beforecopy if
the user thinks about pressing ctrl-c, so there's no way around that.)
Change #3 - no prior discussion, might be a bit controversial?
Synthetic (script-generated) paste events are now defined as causing paste
actions. document.execCommand('copy'|'cut'|'paste') is now from the spec's
point of view just a shortcut for generating and firing synthetic events.
There are two possible ways this works:
1) When creating synthetic clipboard events, the script can specify a data
payload. For example, the default outcome of this script:
var evt = new ClipboardEvent({data:'EHLO WORDL', dataType:'text/plain'})
document.getElementsByTagName('textarea')[0].dispatchEvent(evt)
would be to insert the text 'EHLO WORDL', as if pasted from the clipboard,
into the textarea.
2) UAs may be configured to allow scripted paste operations. In this case,
dispatching a paste event targeted at some element where data can be inserted
(input/textarea/contenteditable etc.) will by default insert the clipboard
data. However, if a data payload was specified for the event (as in the
example above), that data will be used instead of clipboard data.
Is this a good change or a bad idea? Please discuss :-)
Known issue: the Editor's draft is not currently properly cross-linked with
other specs, because I don't have a computer with Anolis set up handy right
now. I'll fix this later. For the same reason, the ED doesn't have a proper
inline table of contents.
-Hallvord
Re: [clipboard events] Spec update
I'm eager to replace our flash clipboard bridge with this native api.
Uh, I'm glad you like it but I wouldn't hold my breath.. I hope implementors
will like it too but I have no way to tell when implementations will actually
be available.
Would this be the correct code to write a string to the clipboard on a
button click?
Almost, just create a copy event rather than a paste one ;-)
document.getElementById(copytoclipboard).addEventListener(click,
function() {
var event = new ClipboardEvent('paste', {data: 'COPIED!',
This is where 'paste' ought to be 'copy'. Then it should just work.
dataType: 'text/plain'});
document.dispatchEvent(event);
});
-Hallvord
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Fri, 10 Feb 2012 01:24:05 +0100, Ian Hickson i...@hixie.ch wrote: We're going out of our way to do lots of special processing for HTML in a paste. Why doesn't a drop of HTML get the same treatment? This is a good question. Presumably the scenario is that hostile page A provides some content and gets the user to select and copy or drag it to page B's contentEditable region, including any script in the selection, which once pasted becomes a cross-site scripting vulnerability. That might be one threat model, but it's one that UAs are already handling. Most UAs remove or plan to remove SCRIPT tags from pasted HTML data. I've mentioned this in the drag-and-drop spec. Goo idea. Now, I don't think that was the question Daniel Cheng was asking. If you look at the HTML/XHTML specific instructions for the paste event (in the processing model section: http://dev.w3.org/2006/webapi/clipops/#processing-model ) you'll see that it specifies quite a bit of parsing and such. The goals are: * Resolve URLs and links - the page script won't know the base URI to resolve against (on Windows this is in the CF_HTML format's meta data and the page script doesn't get access to it) * Make it possible to paste HTML from a local application that embeds local resources (img src=file://..) and enable page scripts to process and upload said resources * Optionally do extra privacy or security-related filtering if the UA implementor considers it useful So, I think the question Daniel is asking, is: why don't we process URLs and local resources this way if HTML data is drag-and-dropped to a page? Should this processing be moved to the DnD spec? Finally, regarding the topic this E-mail's subject is dealing with, I've spec'ed this: implementation should use clipboard content sequence number on platforms where this is available, creativity elsewhere, to make sure script can only access one single clipboard entry. I've also added a test for this. -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Fri, 10 Feb 2012, Hallvord R. M. Steen wrote: Now, I don't think that was the question Daniel Cheng was asking. If you look at the HTML/XHTML specific instructions for the paste event (in the processing model section: http://dev.w3.org/2006/webapi/clipops/#processing-model ) you'll see that it specifies quite a bit of parsing and such. The goals are: * Resolve URLs and links - the page script won't know the base URI to resolve against (on Windows this is in the CF_HTML format's meta data and the page script doesn't get access to it) Well presumably all the URLs should be made absolute in the copy/drag code, not the paste/drop code. The paste/drop code has no context. No parsing needed for that though, the URLs are already resolved in the DOM so it's just a matter of serialising them. * Make it possible to paste HTML from a local application that embeds local resources (img src=file://..) and enable page scripts to process and upload said resources How would you distinguish this case from a hostile app tricking the user into copying HTML that has pointers to sensitive local files? * Optionally do extra privacy or security-related filtering if the UA implementor considers it useful I wouldn't do this via parsing, but DOM filtering. That's the semantic layer. A whitelist DOM filter will ensure that only the stuff the browser thinks is safe can get through. So, I think the question Daniel is asking, is: why don't we process URLs and local resources this way if HTML data is drag-and-dropped to a page? Should this processing be moved to the DnD spec? I guess we could say that HTML dragged from the page could have URLs absoluted in the serialisation. The other stuff doesn't seem necessary. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
This discussion seems to raise the issue of what happens to URLs to images (or other embedded objects) that are unresolved but become resolved when pasted. E.g. file:///Users/anton/Library/AddressBook (if that ever made sense) Should these also be sanitized away so that they do not, suddenly become attempted? Paul Le 10 févr. 2012 à 22:36, Ian Hickson a écrit : On Fri, 10 Feb 2012, Hallvord R. M. Steen wrote: Now, I don't think that was the question Daniel Cheng was asking. If you look at the HTML/XHTML specific instructions for the paste event (in the processing model section: http://dev.w3.org/2006/webapi/clipops/#processing-model ) you'll see that it specifies quite a bit of parsing and such. The goals are: * Resolve URLs and links - the page script won't know the base URI to resolve against (on Windows this is in the CF_HTML format's meta data and the page script doesn't get access to it) Well presumably all the URLs should be made absolute in the copy/drag code, not the paste/drop code. The paste/drop code has no context. No parsing needed for that though, the URLs are already resolved in the DOM so it's just a matter of serialising them. * Make it possible to paste HTML from a local application that embeds local resources (img src=file://..) and enable page scripts to process and upload said resources How would you distinguish this case from a hostile app tricking the user into copying HTML that has pointers to sensitive local files? * Optionally do extra privacy or security-related filtering if the UA implementor considers it useful I wouldn't do this via parsing, but DOM filtering. That's the semantic layer. A whitelist DOM filter will ensure that only the stuff the browser thinks is safe can get through. So, I think the question Daniel is asking, is: why don't we process URLs and local resources this way if HTML data is drag-and-dropped to a page? Should this processing be moved to the DnD spec? I guess we could say that HTML dragged from the page could have URLs absoluted in the serialisation. The other stuff doesn't seem necessary. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Wed, 18 May 2011, Daniel Cheng wrote: On Wed, May 18, 2011 at 16:54, Hallvord R. M. Steen hallv...@opera.comwrote: Not 100% sure what you mean by concerns - do you mean for example if I drag a selection that embeds local images from my local word processing application to an online editor? I don't know how/if DnD handles this use case. CCing Ian. We're going out of our way to do lots of special processing for HTML in a paste. Why doesn't a drop of HTML get the same treatment? Presumably the scenario is that hostile page A provides some content and gets the user to select and copy or drag it to page B's contentEditable region, including any script in the selection, which once pasted becomes a cross-site scripting vulnerability. As far as I see it, the right way to solve this is for dragging, copying, dropping, and pasting of HTML to filter the DOM using a whitelist. It's not clear to me that this needs to be done in an interoperable way. I've mentioned this in the drag-and-drop spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
clipboard events draft updated
http://dev.w3.org/2006/webapi/clipops/clipops.html Feedback especially welcome on the processing model: http://dev.w3.org/2006/webapi/clipops/clipops.html#processing-model and the new list of data types an implementation must be aware of: http://dev.w3.org/2006/webapi/clipops/clipops.html#mandatory-data-types-1 (Aware basically means being able to find the right Native OS clipboard format for a given MIME type) -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Thu, 19 May 2011 09:43:33 +0900, João Eiras joao.ei...@gmail.com
wrote:
getData and setData must work outside clipboard events, like when
clicking paste/copy/cut buttons on a toolbar.
I think this is covered by execCommand('Paste') etc.
But there is no way to access the clipboard contents. Or does
execCommand dispatch a synchronous event ?
Yes, it does. See
http://dev.w3.org/2006/webapi/clipops/clipops.html#integration-with-other-scripts-and-events
I expect implementations to let users configure if a site/app is allowed
to use execCommand for cut/copy/paste, perhaps with a prompt on first use.
What if the event is prevented ? Does execCommand return false ?
I don't know much about what execCommand is meant to return, but e.g.
doing execCommand('copy') and then event.preventDefault() from a 'copy'
event listener is intended to prevent copying.
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
Le 19 mai 2011 à 02:11, João Eiras a écrit : getData and setData must work outside clipboard events, like when clicking paste/copy/cut buttons on a toolbar. The clipboardData object needs to be exposed on the window, like in IE. I fully disagree here. This is exactly what has made the CnP API of MSIE a plague with a very bad press coverage. getData and setData can only be used within the event processing which must be triggered by the user-agent at a user-recognizable invocation of the copy/cut or paste command. That some browsers allow differently for trusted sites is ok to me but should not be an essential focus of this spec I find. To handle the getData case, I've thought of adding a proxy clipboard per browsing context. Read operations read from the proxy clipboard, write operations write to the proxy and system clipboards. User initiated actions like dropping, or pasting would update the proxy clipboard with the system clipboard contents, prior to the event being dispatched on the webpage. I *think* that is a good strategy. paul
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Thu, May 19, 2011 at 7:43 AM, Paul Libbrecht p...@hoplahup.net wrote: Le 19 mai 2011 à 02:11, João Eiras a écrit : getData and setData must work outside clipboard events, like when clicking paste/copy/cut buttons on a toolbar. The clipboardData object needs to be exposed on the window, like in IE. I fully disagree here. This is exactly what has made the CnP API of MSIE a plague with a very bad press coverage. getData and setData can only be used within the event processing which must be triggered by the user-agent at a user-recognizable invocation of the copy/cut or paste command. That some browsers allow differently for trusted sites is ok to me but should not be an essential focus of this spec I find. There are too many web apps with a Copy this to clipboard button, like dropbox. If a proxy clipboard is implemented, as I explained, then the privacy concerns are mostly handled.
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Wed, May 18, 2011 at 8:41 PM, João Eiras joao.ei...@gmail.com wrote: More generic - text/* (I've see in too many places mime-types like text/x-c-src, and text is text.) - application/*+xml +1 - application/*script (ecmascript, javascript) Well, unlike the two above, there's no guarantee that all (future) matching media types will be text based scripting languages. Mark.
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Wed, May 18, 2011 at 5:41 PM, João Eiras joao.ei...@gmail.com wrote: More generic - text/* (I've see in too many places mime-types like text/x-c-src, and text is text.) - application/*+xml - application/*script (ecmascript, javascript) How do we know that these types don't contain invisible sensitive data? - Ryosuke
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Wed, May 18, 2011 at 17:41, João Eiras joao.ei...@gmail.com wrote:
On , Paul Libbrecht p...@hoplahup.net wrote:
Le 17 mai 2011 à 06:23, Hallvord R. M. Steen a écrit :
To get a table started in the spec, could you give me a small list of
(MIME) types one should mandate the UA to be aware of and be able to
roundtrip to/from native clipboard types? Just off the top of your head?
The typical Web MIME types would of course be something along the lines of
text/plain
text/html
image/jpg
image/gif
image/png
application/xhtml+xml
image/svg+xml
I would like to add all of the 3 MathML flavors:
- application/mathml-presentation+xml
- application/mathml-content+xml
- application/mathml+xml
More generic
- text/* (I've see in too many places mime-types like text/x-c-src, and
text is text.)
- application/*+xml
- application/*script (ecmascript, javascript)
e.clipboardData.setData('text/x-c-src', 'Foo');
e.clipboardData.setData('text/plain', 'Bar');
e.clipboardData.setData('text/xml', 'Baz');
e.clipboardData.setData('application/xhtml+xml', 'Blah');
Which one should get placed into the native plain text type? Which one gets
to be the definitive XML on the native clipboard?
Daniel
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Thu, May 19, 2011 at 04:01, João Eiras joao.ei...@gmail.com wrote: On Thu, May 19, 2011 at 7:43 AM, Paul Libbrecht p...@hoplahup.net wrote: Le 19 mai 2011 à 02:11, João Eiras a écrit : getData and setData must work outside clipboard events, like when clicking paste/copy/cut buttons on a toolbar. The clipboardData object needs to be exposed on the window, like in IE. I fully disagree here. This is exactly what has made the CnP API of MSIE a plague with a very bad press coverage. getData and setData can only be used within the event processing which must be triggered by the user-agent at a user-recognizable invocation of the copy/cut or paste command. That some browsers allow differently for trusted sites is ok to me but should not be an essential focus of this spec I find. There are too many web apps with a Copy this to clipboard button, like dropbox. If a proxy clipboard is implemented, as I explained, then the privacy concerns are mostly handled. To me, this sounds like an implementation detail. There are reasons why a UA wouldn't want to pull the contents of the system clipboard into the proxy clipboard. Daniel
Re: clipboard events
On Tue, 10 May 2011 05:34:17 +0900, Ian Hickson i...@hixie.ch wrote: (Sorry for the long delay in responding to this.) No problem, I know what you've been up to :-p I'm re-ordering this reply a bit to get to the main questions first. There's no processing model. IMHO we need a list of steps somewhere that defines how the events fire with respect to the event loop, which task source is used, what mode the drag data store is in, what the default actions are, how they interact with mutation events, etc. I've tried adding something: http://dev.w3.org/2006/webapi/clipops/clipops.html#processing-model I'm however still not quite sure how to fit it into the event loop. The task source will usually be the user interaction task source (but might also be occurring due to a fully scripted execCommand() call in implementations that allow this). So, to sum up: the events might fire * as the default action of a keypress event * because of a script passing 'cut', 'copy' or 'paste' as an argument to execCommand() * because of user selections from a menu or UI button that causes no preceeding event in the document or environment How/where would you recommend I say something about event loops and task sources to cover all three cases? As you see, the processing model is still full of Issues and Todos, the main problem(s) are probably what types we should mandate support for and what to do about other ones.. But there is a new section on processing HTML that might be a model for how other types should be handled, depending on what (and how much) processing they need. I.e. spec for copy event would be * default action: copy any document selection * if default action is prevented: push data in drag data store (as manipulated by setData() or items.add()) to clipboard, probably mapping certain known values to native clipboard formats while doing so. Ian - would that make sense? I think you'd want to push the script-added data regardless of whether the event is canceled or not. Why would the script add the data otherwise? What you're saying is that we should not use the normal event default action model in this case? IMO adding data from the script even though there is a selection and the default action would have been to copy it, is inconsistent with how events work otherwise. Suggesting that we add the data from the script even if the default action is not cancelled when there is no selection (and thus basically no default action) would be even worse: we'd end up with scripts that work as intended only when the user didn't happen to select some text. I would just model the 'copy' (and 'cut') events exactly as a 'dragstart' event, ideally so much so that you can literally use the same function for both. (Canceling 'cut' would prevent the default deletion of the selection, canceling 'copy' has no effect.) If there is a selection, should not cancelling copy prevent copying it? Or are you intentionally arguing against that because of the nuisance potential? However, what about items.add() called during a paste event listener? Currently I do not allow paste event listeners to update the clipboard with setData(), it seems strange. Should we just disallow this too? I'd model 'paste' on 'drop', including having the drag data store in read-only mode, yes. It now is in read-only mode for paste. I'm not trying to decide how the implementation should figure out what DOM nodes to remove when the user selects something and cuts.) We probably should define that. Probably, but excuse me for not volunteering to do so at this point ;-) Assuming RFC2119 semantics, the spec is lacking detail. For example, nothing normatively says whether the events bubble or not, it's just left up to the reader to assume that the table implies that it does. I've tried to sharpen the use of must, must not and the like. I'm not entirely sure why 'Bubbles: yes' in a table isn't normative or explicit enough though. Nothing seems to define whether those tables are normative or informative or what they mean if they're normative. AFAIK, something that is not explicitly marked as informative is normative - no? And given that we're relying on the DOM Events spec, saying that an event bubbles should be pretty well understood? The drag data store is a UA-specific concept that is just used to define the processing model. You'd want to define how and when it is transferred to and from the system clipboard. Does the CCnP spec need to say explicitly how to expose OS clipboard content as a drag data store? It needs to say everything explicitly. It's a spec. :-) Fair point :-) Started fleshing this out. I'll probably try not to spend time on spec editing more often than once a month or so, so I'll get back to this in June or July. -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Tue, 17 May 2011 16:12:50 +0900, Paul Libbrecht p...@hoplahup.net wrote: I would like to add all of the 3 MathML flavors: - application/mathml-presentation+xml - application/mathml-content+xml - application/mathml+xml Would any special processing be required for any of them? If not, if we have a section that covers any XML-based format, that should be enough - right? Relevant for this thread (though not to MathML specifically), here's a link on what Flash supports: http://help.adobe.com/en_US/as3/dev/WS0579B9EE-CF1E-434e-A386-A04DC7786FC9.html -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Tue, May 17, 2011 at 22:07, Hallvord R. M. Steen hallv...@opera.comwrote:
Should our implementation work harder to keep what we promise in
clipboardData.items, or should we be content that such timing issues will be
so rare that throwing is fine? After all, most applications manipulate the
clipboard only in response to user input, which is a pretty modal source of
events, and by definition the paste event will fire in response to user
input within the document..
I think it's fine to simply throw as this typically happens in response to a
user action.
Also, I'm not sure if we should process any HTML data on the clipboard
(including possibly adding images and embedded content to
clipboardData.items) before firing the paste event, or do so only if the
script calls getData('text/html') within the paste event thread. Implementor
feedback welcome!
Ideally we shouldn't manipulate any data until it's been requested by the
page, since reading data off the clipboard is a potentially slow operation.
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Wed, 18 May 2011 15:49:33 +0900, Daniel Cheng dch...@chromium.org
wrote:
Also, I'm not sure if we should process any HTML data on the clipboard
(including possibly adding images and embedded content to
clipboardData.items) before firing the paste event, or do so only if
the script calls getData('text/html') within the paste event thread.
Implementor feedback welcome!
Ideally we shouldn't manipulate any data until it's been requested by
the page, since reading data off the clipboard is a potentially slow
operation.
What do you think about the current spec text? I've moved the section
http://dev.w3.org/2006/webapi/clipops/clipops.html#processing-model-for-pasting-html-data
to where we prepare the paste event, because integrating this into the
HTML5 DataTransfer stuff becomes much easier this way. (Previously I
spec'ed it so that this work would happen on a script calling
getData('text/html') but that would require some hacking around with the
getData() definition in HTML5.) This means we read and process the HTML
part from the clipboard before firing paste, but any binary/embedded data
will only be read on demand.
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Wed, May 18, 2011 at 02:16, Hallvord R. M. Steen hallv...@opera.comwrote:
What do you think about the current spec text? I've moved the section
http://dev.w3.org/2006/webapi/clipops/clipops.html#processing-model-for-pasting-html-datato
where we prepare the paste event, because integrating this into the HTML5
DataTransfer stuff becomes much easier this way. (Previously I spec'ed it so
that this work would happen on a script calling getData('text/html') but
that would require some hacking around with the getData() definition in
HTML5.) This means we read and process the HTML part from the clipboard
before firing paste, but any binary/embedded data will only be read on
demand.
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
Shouldn't we have similar concerns about the text/html content of a drop?
Daniel
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Thu, 19 May 2011 03:12:41 +0900, Daniel Cheng dch...@chromium.org
wrote:
[Added back a bit more context since I add Ian to CC]
Also, I'm not sure if we should process any HTML data on the clipboard
(including possibly adding images and embedded content to
clipboardData.items) before firing the paste event, or do so only if
the
script calls getData('text/html') within the paste event thread.
Ideally we shouldn't manipulate any data until it's been requested by
the
page, since reading data off the clipboard is a potentially slow
operation.
What do you think about the current spec text? I've moved the section
http://dev.w3.org/2006/webapi/clipops/clipops.html#processing-model-for-pasting-html-datato
where we prepare the paste event, because integrating this into the
HTML5
DataTransfer stuff becomes much easier this way. (Previously I spec'ed
it so
that this work would happen on a script calling getData('text/html') but
that would require some hacking around with the getData() definition in
HTML5.) This means we read and process the HTML part from the clipboard
before firing paste, but any binary/embedded data will only be read on
demand.
Shouldn't we have similar concerns about the text/html content of a drop?
Not 100% sure what you mean by concerns - do you mean for example if I
drag a selection that embeds local images from my local word processing
application to an online editor? I don't know how/if DnD handles this use
case. CCing Ian.
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
Re: clipboard events
On Mon, May 9, 2011 at 4:34 PM, Ian Hickson i...@hixie.ch wrote: On Sat, 08 Jan 2011 05:02:02 +0900, Ian Hickson i...@hixie.ch wrote: Is it intended to also cover cut, copy and paste? Sorry, I don't understand the question. Well, for example, the 'cut' operation involves removing or mutating DOM nodes (for contentEditable) or editing the control value (for input) or raw value (for textarea), and modifying the selection accordingly. The timing is in scope, how to do the actual modifications is not (i.e. I'm not trying to decide how the implementation should figure out what DOM nodes to remove when the user selects something and cuts.) We probably should define that. Why isn't it just Selection.deleteFromDocument()? http://html5.org/specs/dom-range.html#dom-selection-deletefromdocument
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On , Hallvord R. M. Steen hallv...@opera.com wrote:
On Thu, 19 May 2011 03:12:41 +0900, Daniel Cheng dch...@chromium.org
wrote:
[Added back a bit more context since I add Ian to CC]
Also, I'm not sure if we should process any HTML data on the clipboard
(including possibly adding images and embedded content to
clipboardData.items) before firing the paste event, or do so only if
the
script calls getData('text/html') within the paste event thread.
getData and setData must work outside clipboard events, like when clicking
paste/copy/cut buttons on a toolbar. The clipboardData object needs to be
exposed on the window, like in IE.
To handle the getData case, I've thought of adding a proxy clipboard per
browsing context. Read operations read from the proxy clipboard, write
operations write to the proxy and system clipboards. User initiated actions
like dropping, or pasting would update the proxy clipboard with the system
clipboard contents, prior to the event being dispatched on the webpage.
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Thu, 19 May 2011 09:11:56 +0900, João Eiras joao.ei...@gmail.com
wrote:
getData and setData must work outside clipboard events, like when
clicking paste/copy/cut buttons on a toolbar.
I think this is covered by execCommand('Paste') etc.
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On , Paul Libbrecht p...@hoplahup.net wrote: Le 17 mai 2011 à 06:23, Hallvord R. M. Steen a écrit : To get a table started in the spec, could you give me a small list of (MIME) types one should mandate the UA to be aware of and be able to roundtrip to/from native clipboard types? Just off the top of your head? The typical Web MIME types would of course be something along the lines of text/plain text/html image/jpg image/gif image/png application/xhtml+xml image/svg+xml I would like to add all of the 3 MathML flavors: - application/mathml-presentation+xml - application/mathml-content+xml - application/mathml+xml More generic - text/* (I've see in too many places mime-types like text/x-c-src, and text is text.) - application/*+xml - application/*script (ecmascript, javascript)
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On , Hallvord R. M. Steen hallv...@opera.com wrote:
On Thu, 19 May 2011 09:11:56 +0900, João Eiras joao.ei...@gmail.com
wrote:
getData and setData must work outside clipboard events, like when
clicking paste/copy/cut buttons on a toolbar.
I think this is covered by execCommand('Paste') etc.
But there is no way to access the clipboard contents. Or does execCommand
dispatch a synchronous event ? What if the event is prevented ? Does
execCommand return false ?
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Wed, May 18, 2011 at 5:43 PM, João Eiras joao.ei...@gmail.com wrote: But there is no way to access the clipboard contents. Or does execCommand dispatch a synchronous event ? It fires copy/paste events. - Ryosuke
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Wed, May 18, 2011 at 16:54, Hallvord R. M. Steen hallv...@opera.comwrote: Not 100% sure what you mean by concerns - do you mean for example if I drag a selection that embeds local images from my local word processing application to an online editor? I don't know how/if DnD handles this use case. CCing Ian. -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/ We're going out of our way to do lots of special processing for HTML in a paste. Why doesn't a drop of HTML get the same treatment? Daniel
Re: request for custom clipboard types (Re: clipboard events)
On Mon, May 16, 2011 at 9:34 PM, Hallvord R. M. Steen hallv...@opera.comwrote: On Mon, 31 Jan 2011 20:25:20 +0900, Paul Libbrecht p...@activemath.org wrote: A website maker for, say, a shop for furnitures that knows they can go into my home plan maker through the clipboard will want to be able to produce and export a clipboard flavor that is unknown to both browser implementors and spec makers now. Provided the user may say that the format is safe (safe as a picture for example), he would be able to drag-and-drop the furniture and get a 3D view inside my home plan maker. I can see there are some really nice and tempting use cases. The problem is the serious downsides.. I would however assume that if we support placing a main XML (or JSON) payload plus alternate- or sub-parts on the clipboard, many custom formats and applications would be able to do their custom business in XML or JSON plus binary blobs. What do you think? I'm also concerned that website may access sensitive information such as local file path and user name via clipboard if we allow arbitrary format. - Ryosuke
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Mon, May 16, 2011 at 21:23, Hallvord R. M. Steen hallv...@opera.comwrote: On Mon, 31 Jan 2011 19:39:13 +0900, Daniel Cheng dch...@chromium.org wrote: I'd go one step further and say that there should be some agreement on what MIME types ought to be supported to try to insure somewhat consistent behavior across different platforms. To get a table started in the spec, could you give me a small list of (MIME) types one should mandate the UA to be aware of and be able to roundtrip to/from native clipboard types? Just off the top of your head? The typical Web MIME types would of course be something along the lines of text/plain text/html image/jpg image/gif image/png application/xhtml+xml image/svg+xml What about e.g. RTF? The way I'm working on implementing it (for drag and drop, though it applies to copy and paste as well), arbitrary strings would not be accessible from a non-DOM application, e.g. a native app like Word or Photoshop. Only a set of known MIME types would be automatically converted to the corresponding native type. That's dragging from UA to another app, right? So the way to spec it would be during copy/cut processing, the UA should support placing content of these MIME types on the clipboard and translate the type to the OS native equivalent where applicable or something like that? When pulling data from the clipboard X I'm choosing to restrict the number of native types to a smaller, defined set that are visible to webpages. Any paths in this set can be filtered as necessary when a file drag is detected. Again the specific list of types for this would be great :-) -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/ http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-October/028926.htmlis a set of types I proposed originally. I omitted GIF/JPG because platform support for GIFs/JPGs isn't as strong, nor is it widely used. Daniel
Re: request for custom clipboard types (Re: clipboard events)
On Mon, May 16, 2011 at 22:57, Ryosuke Niwa rn...@webkit.org wrote: On Mon, May 16, 2011 at 9:34 PM, Hallvord R. M. Steen hallv...@opera.comwrote: On Mon, 31 Jan 2011 20:25:20 +0900, Paul Libbrecht p...@activemath.org wrote: A website maker for, say, a shop for furnitures that knows they can go into my home plan maker through the clipboard will want to be able to produce and export a clipboard flavor that is unknown to both browser implementors and spec makers now. Provided the user may say that the format is safe (safe as a picture for example), he would be able to drag-and-drop the furniture and get a 3D view inside my home plan maker. I can see there are some really nice and tempting use cases. The problem is the serious downsides.. I would however assume that if we support placing a main XML (or JSON) payload plus alternate- or sub-parts on the clipboard, many custom formats and applications would be able to do their custom business in XML or JSON plus binary blobs. What do you think? I'm also concerned that website may access sensitive information such as local file path and user name via clipboard if we allow arbitrary format. - Ryosuke An XML + JSON payload seems reasonable, but I wonder how long it would take for native apps to interop with web apps. My original plan for adding custom MIME type support to Chromium was to avoid security issues by confining the custom types inside Chromium--they'd work when dragging/dropping or copying/pasting within the browser, but wouldn't be visible to, say, Photoshop. Ideally, there'd be cooperation about the browser vendors so it'd even work across different browsers. Daniel
Re: Filtering clipboard MIME types (was: Re: clipboard events)
Le 17 mai 2011 à 06:23, Hallvord R. M. Steen a écrit : To get a table started in the spec, could you give me a small list of (MIME) types one should mandate the UA to be aware of and be able to roundtrip to/from native clipboard types? Just off the top of your head? The typical Web MIME types would of course be something along the lines of text/plain text/html image/jpg image/gif image/png application/xhtml+xml image/svg+xml I would like to add all of the 3 MathML flavors: - application/mathml-presentation+xml - application/mathml-content+xml - application/mathml+xml What about e.g. RTF? I feel it fits. paul
Re: clipboard events
On 01/31/2011 11:02 AM, Ryosuke Niwa wrote: On Tue, Jan 25, 2011 at 9:26 PM, Hallvord R. M. Steen hallv...@opera.com mailto:hallv...@opera.com wrote: On Thu, 06 Jan 2011 07:41:01 +0900, Ryosuke Niwa rn...@webkit.org mailto:rn...@webkit.org wrote: In an editable context, the paste event's target property refers to the element that contains the start of the selection. In a non-editable document, the event is targeted at a node focused by clicking or by an interactive cursor. If the node that has focus is not a text node, the event is targeted at the BODY element. I'm not sure if it makes sense for the element to be the start of selection. It's simply spec'ed that way because both Firefox and WebKit agree on doing so ;) Why not just pass the root editable element? That's what IE does. I think IE's behavior makes more sense. I think Webkit's and Gecko's behavior makes more sense. You paste to some location in the editable area, not to root of it. -Olli Mentioning of clicking or cursor is unnecessary. One can use keyboard to move focus selection and copy / paste should still work. Yes, it's meant to be an example - I added the words 'for example'. Okay. compatible with http://msdn.microsoft.com/en-us/library/ms535220(v=vs.85).aspx but I guess getData and setData's return type prevent this. I guess at least setData() and clearData() could easily return a boolean in HTML5 too. Ian? (I assume it indicates whether the clipboard operation succeeded or not). Right. Internet Explorer already implements most of this spec but ClipboardData is implemented as a property of window object. Why deviate? To me it seems to express much more clearly that this stuff is only available as a consequence of those events being triggered by the user. As such, event.clipboardData seems nicer than window.clipboardData. (Besides, both WebKit and Gecko already made this decision and it seems a useful way to let developers object-detect HTML5's stuff versus legacy IE stuff.) I'm not sure we should allow access to clipboard only when those events are fired. I can see browsers that support application stores might want to allow purchased apps to be able to access clipboard access. Also, browser vendors can permit users to grant clipboard access permissions to certain websites that act more like natives apps. And for those apps, event.clipboardData isn't sufficient. And I don't think we should be limiting such use cases by the spec. This sounds quite reasonable things to do but I'm not sure if we should spec it. Vendors can decide what to do by themselves. For example, I'd imagine browsers can implement some interactive UI that lets user decide whether or not he/she wants to paste / copy certain content on demand. Allowing access only within the event handler might be too restrictive. I think we should spec the most common and safest case. Vendors are free to do what they like anyway. For the above reason, I'm strongly against such security mechanism / policy woven into the spec. On Thu, 06 Jan 2011 16:27:33 +0900, Ryosuke Niwa rn...@webkit.org mailto:rn...@webkit.org wrote: If getData() is not called from within a paste event handler, or if the type is not available, the method returns undefined What should we do if getData is called within a copy event handler? We have an outstanding bug that requests that getData returns the content that's about to be copied into the clipboard ( https://bugs.webkit.org/show_bug.cgi?id=22017). Should we consider such a behavior? Thanks for the bug reference, an interesting and very relevant issue. I don't think it really makes sense to do what the bug reporter requests, because the copy event fires *before* the copy operation takes place. At the time, whatever data was on the clipboard previously will still be there, returning that in getData() doesn't seem to have much of a use case. Returning the new data you're about to copy seems a bit confusing since it's not actually the data that is on the clipboard. It also seems a bit redundant, given that the event listener has access to the selection, can read data from there and do whatever fixes are required, then use setData(). So I'd personally prefer the currently spec'ed text, but if others want to chime in and vote for the show what we'll place on the clipboard option I'd like to hear any arguments.. Another thing. Should getData guarantee to return the same result each time called within the same event handler?
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Tue, May 17, 2011 at 7:23 AM, Hallvord R. M. Steen hallv...@opera.com wrote: to/from native clipboard types? Just off the top of your head? The typical Web MIME types would of course be something along the lines of text/plain text/html image/jpg image/gif image/png application/xhtml+xml image/svg+xml i'd suggest ATOM [application/atom+xml] as a type to support. Browsers generally support it. This is somewhat to the exclusion of RDF and RSS. This provides a way to serve listings and enclosures and things Should application/octet-stream be supported for cases when authors want to pass along binary data?
Re: clipboard events
On Tue, May 17, 2011 at 1:16 AM, Olli Pettay olli.pet...@helsinki.fiwrote: I think Webkit's and Gecko's behavior makes more sense. You paste to some location in the editable area, not to root of it. But selection could be a range. Why would you arbitrarily pick one end point? - Ryosuke
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Tue, May 17, 2011 at 00:12, Paul Libbrecht p...@hoplahup.net wrote: Le 17 mai 2011 à 06:23, Hallvord R. M. Steen a écrit : To get a table started in the spec, could you give me a small list of (MIME) types one should mandate the UA to be aware of and be able to roundtrip to/from native clipboard types? Just off the top of your head? The typical Web MIME types would of course be something along the lines of text/plain text/html image/jpg image/gif image/png application/xhtml+xml image/svg+xml I would like to add all of the 3 MathML flavors: - application/mathml-presentation+xml - application/mathml-content+xml - application/mathml+xml What about e.g. RTF? I feel it fits. paul I don't think we need all 3. Why not just application/mathml+xml? On Tue, May 17, 2011 at 07:03, timeless timel...@gmail.com wrote: On Tue, May 17, 2011 at 7:23 AM, Hallvord R. M. Steen hallv...@opera.com wrote: to/from native clipboard types? Just off the top of your head? The typical Web MIME types would of course be something along the lines of text/plain text/html image/jpg image/gif image/png application/xhtml+xml image/svg+xml i'd suggest ATOM [application/atom+xml] as a type to support. Browsers generally support it. This is somewhat to the exclusion of RDF and RSS. This provides a way to serve listings and enclosures and things Should application/octet-stream be supported for cases when authors want to pass along binary data? This really doesn't have corresponding native equivalent other than files. The problem with files is the MIME type doesn't really mean anything when you're transferring data out of the browser, so it's difficult to guarantee round tripping. Also, what about vCard? Daniel
Re: Filtering clipboard MIME types (was: Re: clipboard events)
Le 17 mai 2011 à 19:06, Daniel Cheng a écrit : I would like to add all of the 3 MathML flavors: - application/mathml-presentation+xml - application/mathml-content+xml - application/mathml+xml paul I don't think we need all 3. Why not just application/mathml+xml? Daniel, you do mean all three MathML flavors, right? The reason they are each useful is that: some applications can do MathML-presentation and not content (example: MS Word) some applications can do MathML-content and would loose information by receiving presentation (example: Maple, with a limit expression, I think a spreadsheet could also) some applications just do not know or care, for them the generic flavor is ok some applications will do a conversion content-to-presentation in a way better than others, in particular if the language context is properly considered (e.g. considering the varying numbers' syntax) paul
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Tue, 17 May 2011 15:30:08 +0900, Daniel Cheng dch...@chromium.org wrote: I believe this problem is solvable without a spec change. OK. I'd like to put in some non-normative warning or note about this problem though. On Windows and Mac, implementations can use a native clipboard sequence number to determine the contents of the clipboard have changed. Interesting. What, in your view, should the implementation do if it discovers the contents has changed while a paste event thread is running? -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Tue, May 17, 2011 at 14:03, Hallvord R. M. Steen hallv...@opera.comwrote: On Tue, 17 May 2011 15:30:08 +0900, Daniel Cheng dch...@chromium.org wrote: I believe this problem is solvable without a spec change. OK. I'd like to put in some non-normative warning or note about this problem though. On Windows and Mac, implementations can use a native clipboard sequence number to determine the contents of the clipboard have changed. Interesting. What, in your view, should the implementation do if it discovers the contents has changed while a paste event thread is running? -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/ Safari returns an empty string from getData() if this happens. If the caller is using event.clipboardData.items, maybe throw a DOM exception when getAs*() is called. Daniel
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Tue, May 17, 2011 at 2:23 PM, Hallvord R. M. Steen hallv...@opera.comwrote: text/plain text/html image/jpg image/gif image/png application/xhtml+xml image/svg+xml What about image/webp? +1 for being able to copy/paste binary data either through application/octet-stream or perhaps using blobs with the BlobBuilder API? -Ryan Seddon
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Tue, May 17, 2011 at 16:26, Ryan Seddon seddon.r...@gmail.com wrote: What about image/webp? I'd suggest that if we want to support image formats in the spec, we should try to support the same set that Canvas::toDataURL() does. +1 for being able to copy/paste binary data either through application/octet-stream or perhaps using blobs with the BlobBuilder API? -Ryan Seddon I don't understand what problem you're trying to solve with application/octet-stream. My bigger concern is that this list of things to support seems to be growing quite rapidly. It'd be nice if we had some sort of criteria to run proposals by, though I have no idea what they'd be. Daniel
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Wed, 18 May 2011 09:13:19 +0900, Daniel Cheng dch...@chromium.org wrote: I'd suggest that if we want to support image formats in the spec, we should try to support the same set that Canvas::toDataURL() does. I'll have a look at image formats, thanks for pointing me to toDataURL() :) +1 for being able to copy/paste binary data either through application/octet-stream or perhaps using blobs with the BlobBuilder API? I don't understand what problem you're trying to solve with application/octet-stream. Do native OS clipboards generally tend to have a data type saying this is some random binary data? That's more or less what I think application/octet-stream indicates on the web. If there isn't a common format to map it to on the OS clipboard side, I don't understand what's being proposed either. (If I had to define common I guess I really mean that the same concept exists in Desktop Win/Mac/*nix clipboard implementations.) My bigger concern is that this list of things to support seems to be growing quite rapidly. It'd be nice if we had some sort of criteria to run proposals by, though I have no idea what they'd be. Is it a good idea at this point to let the spec say these types are mandatory, those are optional? Or just proceed carefully and try to avoid the feature creep? ;-) -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Tue, May 17, 2011 at 20:44, Hallvord R. M. Steen hallv...@opera.comwrote: Do native OS clipboards generally tend to have a data type saying this is some random binary data? That's more or less what I think application/octet-stream indicates on the web. If there isn't a common format to map it to on the OS clipboard side, I don't understand what's being proposed either. (If I had to define common I guess I really mean that the same concept exists in Desktop Win/Mac/*nix clipboard implementations.) -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/ If I had to map it to something, it'd represent a native file in a clipboard/drag-and-drop operation. Daniel
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Wed, 18 May 2011 08:14:42 +0900, Daniel Cheng dch...@chromium.org
wrote:
Interesting. What, in your view, should the implementation do if it
discovers the contents has changed while a paste event thread is
running?
Safari returns an empty string from getData() if this happens. If the
caller
is using event.clipboardData.items, maybe throw a DOM exception when
getAs*() is called.
We have a problem indeed if we neither want to copy the data from the
clipboard nor lock it while the script is processing the paste event: If
we give the script a nicely prepared DataTransferItems list and the stuff
we've promised is no longer on the clipboard when the script tries to use
it, because another application overwrote it..
Should our implementation work harder to keep what we promise in
clipboardData.items, or should we be content that such timing issues will
be so rare that throwing is fine? After all, most applications manipulate
the clipboard only in response to user input, which is a pretty modal
source of events, and by definition the paste event will fire in response
to user input within the document..
Also, I'm not sure if we should process any HTML data on the clipboard
(including possibly adding images and embedded content to
clipboardData.items) before firing the paste event, or do so only if the
script calls getData('text/html') within the paste event thread.
Implementor feedback welcome!
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
IMO getData() should be 'live' - i.e. return what's on the clipboard. I think having it return live data could result in potential security issues. Couldn't a script loop inside the paste event to keep sniffing out live data? What should we do about this? Should the spec mandate a timeout or a limit on how many times a script may call getData() for the same event? -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Filtering clipboard MIME types (was: Re: clipboard events)
On Mon, 31 Jan 2011 19:39:13 +0900, Daniel Cheng dch...@chromium.org wrote: I'd go one step further and say that there should be some agreement on what MIME types ought to be supported to try to insure somewhat consistent behavior across different platforms. To get a table started in the spec, could you give me a small list of (MIME) types one should mandate the UA to be aware of and be able to roundtrip to/from native clipboard types? Just off the top of your head? The typical Web MIME types would of course be something along the lines of text/plain text/html image/jpg image/gif image/png application/xhtml+xml image/svg+xml What about e.g. RTF? The way I'm working on implementing it (for drag and drop, though it applies to copy and paste as well), arbitrary strings would not be accessible from a non-DOM application, e.g. a native app like Word or Photoshop. Only a set of known MIME types would be automatically converted to the corresponding native type. That's dragging from UA to another app, right? So the way to spec it would be during copy/cut processing, the UA should support placing content of these MIME types on the clipboard and translate the type to the OS native equivalent where applicable or something like that? When pulling data from the clipboard X I'm choosing to restrict the number of native types to a smaller, defined set that are visible to webpages. Any paths in this set can be filtered as necessary when a file drag is detected. Again the specific list of types for this would be great :-) -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
request for custom clipboard types (Re: clipboard events)
On Mon, 31 Jan 2011 20:25:20 +0900, Paul Libbrecht p...@activemath.org wrote: there should be some agreement on what MIME types ought to be supported Some types will be predefined but the door should stay opened for others. I think what you are asking implies that the UA should get out of the way and just pass the arbitrary string the script gives it to the OS. Then you risk that script authors need to a) start writing platform-detection and OS-specific code b) be forced to handle cases like a Windows OS whose list of possible clipboard types is full I think in particular a) is a very bad consequence. Browser sniffing is an awful failure, holding the web back, preventing compatibility and competition. We should certainly avoid specifying something that will be even worse if we can. (I see scripts detecting Windows and Macs only and not fall back to anything but broken clipboard support for other platforms if we go down this route). A website maker for, say, a shop for furnitures that knows they can go into my home plan maker through the clipboard will want to be able to produce and export a clipboard flavor that is unknown to both browser implementors and spec makers now. Provided the user may say that the format is safe (safe as a picture for example), he would be able to drag-and-drop the furniture and get a 3D view inside my home plan maker. I can see there are some really nice and tempting use cases. The problem is the serious downsides.. I would however assume that if we support placing a main XML (or JSON) payload plus alternate- or sub-parts on the clipboard, many custom formats and applications would be able to do their custom business in XML or JSON plus binary blobs. What do you think? -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Re: clipboard events
Le 10 mai 2011 à 00:18, João Eiras a écrit : I would just model the 'copy' (and 'cut') events exactly as a 'dragstart' event, ideally so much so that you can literally use the same function for both. (Canceling 'cut' would prevent the default deletion of the selection, canceling 'copy' has no effect.) Shouldn't canceling 'copy' prevent the data from being placed in the clipboard ? I am not sure of the above. I feel it should either be: A- this (stop the copy, triggering an error) B- or remove all of the script's modifications of the clipboard data and leaves it to the native copy The advantage with B is that it prevents scripts that would try to prevent a copy which is important I feel. That way a script can instead explicitly set the contents of the clipboard, if some sanitization needs to be done. I do not think this should be possible since writing to clipboard should only be doable with a copy event triggered by the environment (typically at the invocation of the standard gesture). paul
Re: clipboard events
On Mon, May 9, 2011 at 23:31, Paul Libbrecht p...@hoplahup.net wrote: Le 10 mai 2011 à 00:18, João Eiras a écrit : I would just model the 'copy' (and 'cut') events exactly as a 'dragstart' event, ideally so much so that you can literally use the same function for both. (Canceling 'cut' would prevent the default deletion of the selection, canceling 'copy' has no effect.) Shouldn't canceling 'copy' prevent the data from being placed in the clipboard ? I am not sure of the above. I feel it should either be: A- this (stop the copy, triggering an error) B- or remove all of the script's modifications of the clipboard data and leaves it to the native copy The advantage with B is that it prevents scripts that would try to prevent a copy which is important I feel. That way a script can instead explicitly set the contents of the clipboard, if some sanitization needs to be done. I do not think this should be possible since writing to clipboard should only be doable with a copy event triggered by the environment (typically at the invocation of the standard gesture). paul I would expect scripts to want one of two things when they're preventing the default action: 1. They want to set their own data in the clipboard instead of what the browser would normally provide by default--for example, a document editor that does its own layout instead of using contenteditable. 2. They don't want to allow someone to copy data--perhaps it's data on a sensitive page. I think it's important to enable both. Originally, I wanted to rewrite the copy/cut events to work like this in WebKit: 1. Fire a copy event at the DOM. 2. If the default action was cancelled and event.clipboardData was not mutated, simply return without doing anything. 3. If the default action was cancelled and event.clipboardData was mutated, replace the contents of the system clipboard with the contents of event.clipboardData. 4. Otherwise, if the default action is not cancelled, proceed with the default clipboard population behavior. I'm not sure if a 'dirty' bit on clipboardData is a great signal to use though. Daniel
Re: clipboard events
Le 10 mai 2011 à 09:13, Daniel Cheng a écrit : I would expect scripts to want one of two things when they're preventing the default action: 1. They want to set their own data in the clipboard instead of what the browser would normally provide by default--for example, a document editor that does its own layout instead of using contenteditable. That sure is desirable. I am not clear between instead or on top of (or both). 2. They don't want to allow someone to copy data--perhaps it's data on a sensitive page. I think it's important to enable both. I would be fierciely opposed to allow this and I remember Jonas Sicking was so as well. This would certainly be a loss of freedom from users which I believe is not really nice. But I realize that allowing 1 simply allows 2 as a special case. We should make it more clear that sites that do that should ponder twice the loss of freedom thus removed. paul
Re: clipboard events
I'm not really excited by the return of the attack on context menus. Allowing web sites to hold user's browsers hostage is a bad starting point. It might be ok if the user had to first opt into rich editing - maybe. Note that we only recently added protection for users against 'what you see is not what you copy' (serializers are now fairly css aware). On 5/10/11, Daniel Cheng dch...@chromium.org wrote: On Mon, May 9, 2011 at 23:31, Paul Libbrecht p...@hoplahup.net wrote: Le 10 mai 2011 à 00:18, João Eiras a écrit : I would just model the 'copy' (and 'cut') events exactly as a 'dragstart' event, ideally so much so that you can literally use the same function for both. (Canceling 'cut' would prevent the default deletion of the selection, canceling 'copy' has no effect.) Shouldn't canceling 'copy' prevent the data from being placed in the clipboard ? I am not sure of the above. I feel it should either be: A- this (stop the copy, triggering an error) B- or remove all of the script's modifications of the clipboard data and leaves it to the native copy The advantage with B is that it prevents scripts that would try to prevent a copy which is important I feel. That way a script can instead explicitly set the contents of the clipboard, if some sanitization needs to be done. I do not think this should be possible since writing to clipboard should only be doable with a copy event triggered by the environment (typically at the invocation of the standard gesture). paul I would expect scripts to want one of two things when they're preventing the default action: 1. They want to set their own data in the clipboard instead of what the browser would normally provide by default--for example, a document editor that does its own layout instead of using contenteditable. 2. They don't want to allow someone to copy data--perhaps it's data on a sensitive page. I think it's important to enable both. Originally, I wanted to rewrite the copy/cut events to work like this in WebKit: 1. Fire a copy event at the DOM. 2. If the default action was cancelled and event.clipboardData was not mutated, simply return without doing anything. 3. If the default action was cancelled and event.clipboardData was mutated, replace the contents of the system clipboard with the contents of event.clipboardData. 4. Otherwise, if the default action is not cancelled, proceed with the default clipboard population behavior. I'm not sure if a 'dirty' bit on clipboardData is a great signal to use though. Daniel -- Sent from my mobile device
Re: clipboard events
The alternative is sites that attempt to implement this functionality by preventing the default and clearing all the data on the clipboard instead. I'm not really sure that's any better. Daniel On Tue, May 10, 2011 at 00:41, timeless timel...@gmail.com wrote: I'm not really excited by the return of the attack on context menus. Allowing web sites to hold user's browsers hostage is a bad starting point. It might be ok if the user had to first opt into rich editing - maybe. Note that we only recently added protection for users against 'what you see is not what you copy' (serializers are now fairly css aware). On 5/10/11, Daniel Cheng dch...@chromium.org wrote: On Mon, May 9, 2011 at 23:31, Paul Libbrecht p...@hoplahup.net wrote: Le 10 mai 2011 à 00:18, João Eiras a écrit : I would just model the 'copy' (and 'cut') events exactly as a 'dragstart' event, ideally so much so that you can literally use the same function for both. (Canceling 'cut' would prevent the default deletion of the selection, canceling 'copy' has no effect.) Shouldn't canceling 'copy' prevent the data from being placed in the clipboard ? I am not sure of the above. I feel it should either be: A- this (stop the copy, triggering an error) B- or remove all of the script's modifications of the clipboard data and leaves it to the native copy The advantage with B is that it prevents scripts that would try to prevent a copy which is important I feel. That way a script can instead explicitly set the contents of the clipboard, if some sanitization needs to be done. I do not think this should be possible since writing to clipboard should only be doable with a copy event triggered by the environment (typically at the invocation of the standard gesture). paul I would expect scripts to want one of two things when they're preventing the default action: 1. They want to set their own data in the clipboard instead of what the browser would normally provide by default--for example, a document editor that does its own layout instead of using contenteditable. 2. They don't want to allow someone to copy data--perhaps it's data on a sensitive page. I think it's important to enable both. Originally, I wanted to rewrite the copy/cut events to work like this in WebKit: 1. Fire a copy event at the DOM. 2. If the default action was cancelled and event.clipboardData was not mutated, simply return without doing anything. 3. If the default action was cancelled and event.clipboardData was mutated, replace the contents of the system clipboard with the contents of event.clipboardData. 4. Otherwise, if the default action is not cancelled, proceed with the default clipboard population behavior. I'm not sure if a 'dirty' bit on clipboardData is a great signal to use though. Daniel -- Sent from my mobile device
Re: clipboard events
Can you expand on what kind of protection this was? Isn't it simply the same as a copy static content, copy text, or really copy kind of command? paul Le 10 mai 2011 à 09:41, timeless a écrit : Note that we only recently added protection for users against 'what you see is not what you copy' (serializers are now fairly css aware).
Re: clipboard events
On Tue, May 10, 2011 at 8:41 AM, timeless timel...@gmail.com wrote: I'm not really excited by the return of the attack on context menus. Allowing web sites to hold user's browsers hostage is a bad starting point. It might be ok if the user had to first opt into rich editing - maybe. Note that we only recently added protection for users against 'what you see is not what you copy' (serializers are now fairly css aware). Neither do I but it's a user agent issue to provide ways to override sites using this feature in a way that affects user negatively, because the feature and the use case is legitimate. Anyway, it would not introduce a new problem given that overriding clipboard contents is done already, although by a select few, using plugins, or if copy events are supported, after the copy event, using setData. So ignoring the use case just gives a false sense of security.
Re: clipboard events
(Sorry for the long delay in responding to this.) On Wed, 26 Jan 2011, Hallvord R. M. Steen wrote: On Fri, 24 Dec 2010 07:21:35 +0900, Paul Libbrecht p...@hoplahup.net wrote: - this seems to support the insertion in the clipboard's data of other types than what is currently commonly supported by browsers and the minimum quoted there; this is good and important. I think, for example, that such data as the iCal format would fit very well and be very useful here. It intends to, but this has two open issues: * I assume that many OS clipboard implementations have an enumerated list of known formats, I'm not sure if all OSes can handle a request to push text/foobar data to the clipboard. Does anyone know if we can rely on such functionality being truly cross-platform? * There is not yet a clear way to push multi-part or alternate formats to the OS clipboard from JS. To use something like iCal, I guess best practise would be to push one human-readable text/plain string for target software without iCal support, and one alternate entry in iCal format. I guess that can be done with DataTransferItem add(in DOMString data, in DOMString type); I.e. spec for copy event would be * default action: copy any document selection * if default action is prevented: push data in drag data store (as manipulated by setData() or items.add()) to clipboard, probably mapping certain known values to native clipboard formats while doing so. Ian - would that make sense? I think you'd want to push the script-added data regardless of whether the event is canceled or not. Why would the script add the data otherwise? I would just model the 'copy' (and 'cut') events exactly as a 'dragstart' event, ideally so much so that you can literally use the same function for both. (Canceling 'cut' would prevent the default deletion of the selection, canceling 'copy' has no effect.) However, what about items.add() called during a paste event listener? Currently I do not allow paste event listeners to update the clipboard with setData(), it seems strange. Should we just disallow this too? I'd model 'paste' on 'drop', including having the drag data store in read-only mode, yes. On Fri, 07 Jan 2011 04:31:01 +0900, Ian Hickson i...@hixie.ch wrote: Is it intended to also cover cut, copy and paste? The current spec draft seems very vague about when the events fire and what their default actions are, but I can't tell if that's intentional or not. Better now? Not really. There's no processing model. IMHO we need a list of steps somewhere that defines how the events fire with respect to the event loop, which task source is used, what mode the drag data store is in, what the default actions are, how they interact with mutation events, etc. Basically, the cut/copy/paste equivalent of: http://www.whatwg.org/specs/web-apps/current-work/complete.html#drag-and-drop-processing-model On Sat, 08 Jan 2011 05:02:02 +0900, Ian Hickson i...@hixie.ch wrote: Is it intended to also cover cut, copy and paste? Sorry, I don't understand the question. Well, for example, the 'cut' operation involves removing or mutating DOM nodes (for contentEditable) or editing the control value (for input) or raw value (for textarea), and modifying the selection accordingly. The timing is in scope, how to do the actual modifications is not (i.e. I'm not trying to decide how the implementation should figure out what DOM nodes to remove when the user selects something and cuts.) We probably should define that. Sure. For example, when should the paste event fire relative to when keydown/keyup events fire? When should the paste event fire relative to when the 'input' event fires? Fixed. Not really. It says it's asynchronous, but what event source should it use? Should it be queued on the event loop, or should it fire at some other step? Should it fire as part of the same task that mutates the DOM? Should it fire as part of the same task that fires the keydown event, or some different task? This would define, e.g., the relative order of tasks queued during handlers of the keydown event and those queued during the cut/copy/paste events. Where do these events fire relative to mutation events, for contentEditable? What should the default action of 'paste' be, in terms of DOM mutations when the cursor is in a contentEditable section? It is fixed to the extent that I consider these things in scope.. I'm trying to keep this spec short and sweet :) I think it'd be better to keep it precise. :-) Assuming RFC2119 semantics, the spec is lacking detail. For example, nothing normatively says whether the events bubble or not, it's just left up to the reader to assume that the table implies that it does. I've tried to sharpen the use of must, must not and the like. I'm not entirely sure why 'Bubbles: yes' in a table isn't normative or
Re: clipboard events
I think you'd want to push the script-added data regardless of whether the event is canceled or not. Why would the script add the data otherwise? I would just model the 'copy' (and 'cut') events exactly as a 'dragstart' event, ideally so much so that you can literally use the same function for both. (Canceling 'cut' would prevent the default deletion of the selection, canceling 'copy' has no effect.) Shouldn't canceling 'copy' prevent the data from being placed in the clipboard ? That way a script can instead explicitly set the contents of the clipboard, if some sanitization needs to be done.
Re: clipboard events
On Mon, Jan 31, 2011 at 01:31, Hallvord R. M. Steen hallv...@opera.com wrote: On Mon, 31 Jan 2011 18:02:34 +0900, Ryosuke Niwa rn...@webkit.org wrote: Another thing. Should getData guarantee to return the same result each time called within the same event handler? i.e. if some external applications overrode clipboard's data between two calls to getData, what should happen? IMO getData() should be 'live' - i.e. return what's on the clipboard. Do you think that is harder to implement or less performant than the other possible behaviour? I guess it might give less performance, but I doubt repeated calls to getData() is a use case worth optimising for. Thanks again for your feedback :) -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/ I think having it return live data could result in potential security issues. Couldn't a script loop inside the paste event to keep sniffing out live data? On Mon, Jan 31, 2011 at 01:59, Hallvord R. M. Steen hallv...@opera.comwrote: On Thu, 27 Jan 2011 05:12:58 +0900, Daniel Cheng dch...@chromium.org wrote: Platform capabilities vary. - Windows will be unhappy if you use up all the custom clipboard formats (~65535 or so). There is no way to release formats once registered. - Mac uses UTIs which are strings but not MIME types. - GTK+ seems to support arbitrary MIME types. So for push support, Windows will be unable to natively support arbitrary string types. Thanks. Do you think it is OK to say that we allow arbitrary strings but it may not be available on all platforms, and recommend that script authors stick to known MIME types? I'd go one step further and say that there should be some agreement on what MIME types ought to be supported to try to insure somewhat consistent behavior across different platforms. The way I'm working on implementing it (for drag and drop, though it applies to copy and paste as well), arbitrary strings would not be accessible from a non-DOM application, e.g. a native app like Word or Photoshop. Only a set of known MIME types would be automatically converted to the corresponding native type. When pulling data from the clipboard, I wonder if it may also be a bad idea to expose all the native types. I was working on a patch to do this in WebKit, and it turns out some of the native types leak information about filesystem paths when files are involved in the dragging/paste operation. Do you remember any further details? Seems like something we should mention but I don't know how. Since Linux uses MIME types in its clipboard, I changed the Clipboard implementation in WebKit to directly mirror the contents of the native clipboard. As a result though, pages could access a bunch of random types that included full filesystem paths as part of their data when dragging a file. I suspect that the list of types that happens to leak filesystem paths will vary based on the window manager in use. Because of this, I'm choosing to restrict the number of native types to a smaller, defined set that are visible to webpages. Any paths in this set can be filtered as necessary when a file drag is detected. * There is not yet a clear way to push multi-part or alternate formats to the OS clipboard from JS. To use something like iCal, I guess best practise would be to push one human-readable text/plain string for target software without iCal support, and one alternate entry in iCal format. I guess that can be done with DataTransferItem add(in DOMString data, in DOMString type); I.e. spec for copy event would be * default action: copy any document selection * if default action is prevented: push data in drag data store (as manipulated by setData() or items.add()) to clipboard, probably mapping certain known values to native clipboard formats while doing so. If the default action is prevented and no data was added to the drag data store, does that imply the clipboard should be cleared? No, that sounds like it should be a no-op to me. Does the spec now imply otherwise? -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/ From a strict interpretation, preventing the default event should push an empty drag data store onto the clipboard--e.g. erasing it. I believe it should be a no-op instead. Daniel
Re: clipboard events
Hello, sorry to be slow. Le 31 janv. 2011 à 11:39, Daniel Cheng a écrit : Platform capabilities vary. - Windows will be unhappy if you use up all the custom clipboard formats (~65535 or so). There is no way to release formats once registered. - Mac uses UTIs which are strings but not MIME types. - GTK+ seems to support arbitrary MIME types. So for push support, Windows will be unable to natively support arbitrary string types. Thanks. Do you think it is OK to say that we allow arbitrary strings but it may not be available on all platforms, and recommend that script authors stick to known MIME types? I'd go one step further and say that there should be some agreement on what MIME types ought to be supported to try to insure somewhat consistent behavior across different platforms. Some types will be predefined but the door should stay opened for others. The way I'm working on implementing it (for drag and drop, though it applies to copy and paste as well), arbitrary strings would not be accessible from a non-DOM application, e.g. a native app like Word or Photoshop. Only a set of known MIME types would be automatically converted to the corresponding native type. This is really really a hard task that I wish neither the spec nor browsers implement. Here's a use case that I would find usefully implemented by this spec. A website maker for, say, a shop for furnitures that knows they can go into my home plan maker through the clipboard will want to be able to produce and export a clipboard flavor that is unknown to both browser implementors and spec makers now. Provided the user may say that the format is safe (safe as a picture for example), he would be able to drag-and-drop the furniture and get a 3D view inside my home plan maker. Such a scenario (there are zillions such) requires: - arbitrary flavor strings - knowledge of the flavor strings only from the web-site makers and other software vendor - agreement on safety (that may be the hard part) And unfortunately, arbitrary flavor strings cannot be MIME-types only. Le 26 janv. 2011 à 06:26, Hallvord R. M. Steen a écrit : It intends to, but this has two open issues: * I assume that many OS clipboard implementations have an enumerated list of known formats, Just a few of them. (I'm trying to maintain pointers to that here: http://eds.activemath.org/transfers-literature ) I'm not sure if all OSes can handle a request to push text/foobar data to the clipboard. Not an arbitrary mime-type, an arbitrary flavour conforming to the platform's specifics. Does anyone know if we can rely on such functionality being truly cross-platform? Do you mean a mapping from mime-type? No they are unfortunately extremely platform specific. * There is not yet a clear way to push multi-part or alternate formats to the OS clipboard from JS. I don't think this should be needed. To use something like iCal, I guess best practise would be to push one human-readable text/plain string for target software without iCal support, and one alternate entry in iCal format. Absolutely. I guess that can be done with DataTransferItem add(in DOMString data, in DOMString type); I.e. spec for copy event would be * default action: copy any document selection * if default action is prevented: push data in drag data store (as manipulated by setData() or items.add()) to clipboard, probably mapping certain known values to native clipboard formats while doing so. I think that this is good. paul
