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] 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
[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] 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
