Should queryCommandEnabled(cut|copy|paste) trigger onbefore* events? about clipboard-apis HOT 9 CLOSED

For some reason, I thought the beforecopy/beforecut/beforepaste events were used as signals for whether or not to enable the corresponding context menu items. However, in my experiments, Chrome never fired beforecopy/beforecut/beforepaste events before showing a context menu, even with a selected range. So this either changed at some point, or my memory is faulty.

What actually seems to happen in Chrome when you call queryCommandEnabled('copy') is this:

1. First, check if copy is supported. If copy is not supported, return false. Note that queryCommandSupported('copy') only returns true with an active user gesture (!!) so much of the time, queryCommandEnabled('copy') returns false immediately here.
2. If the current selection is in a password field, return false.
3. Fire a beforecopy event. The event target is determined the same way as the event target for firing a copy event: it's based on the current selection, or the element if there is no selection. If preventDefault() is called, return true.
4. If there is a selected range, return true.
5. Otherwise, return false.

So it actually seems pretty close to what you're proposing. In Chrome, I'm planning on taking the user gesture check out of step 1 so it always returns true. Then the rest follows pretty closely to what you proposed. Two questions:

1. What do IE/FF do with the beforecopy/beforecut/beforepaste events today?
2. Is it OK for queryCommandEnabled('copy') to return true when execCommand('copy') might not work, due to lack of a user gesture?

from clipboard-apis.

Apologies - I'm struggling to follow the user case for this, when / how would these events be used?

Gut instinct says than preventingDefault / returning false in an event should result in the enabledness check to return false, not true?

Regarding 2.) - I would prefer that queryCommandEnabled returns true when execCommand is going to work. Otherwise, if it returns true when execCommand fails, whats the point of the developer ever checking it? Just check queryCommandSupported and try execCommand and see what happens.

from clipboard-apis.

@gauntface well, these events are a bit .. weird. But think of it this way (or read the spec): the "default action" of the event is to run the UA's built-in logic for enabling/disabling copy/cut/paste commands. The built-in logic will likely conclude for example that "copy" should not be enabled if there is no selection. (It will also conclude that the copy action is not available to document.execCommand() if the JS thread is not user-initiated). When you override this built-in logic (by preventing the "default" outcome) the command will end up being considered enabled.

As for the use case, say you have a complex web app where one UI library handles copy/cut/DnD and another component is responsible for rendering some buttons. Rather than having a tight coupling between those components, the library handling buttons could call queryCommandEnabled('copy') and the DnD library could listen to 'beforecopy' and call preventDefault() if it wanted the button to be enabled.

from clipboard-apis.

@zetafunction

For some reason, I thought the beforecopy/beforecut/beforepaste
events were used as signals for whether or not to enable the
corresponding context menu items.

Well, that's how they were intended to work (but AFAIK even in IE which invented these events, support has left much to be desired..).

queryCommandSupported('copy') only returns true with an active user gesture (!!)

Well, that sounds wrong :) But IMO it would be useful to just move that check to the queryCommandEnabled() code - say, instead of the "is there a selection" check. So the question "is this supported" responds true and the question "is this enabled" returns false if execCommand() would indeed fail?

(Now, while I've been pushing for this as a way to feature-detect user-initiated execCommand(copy|cut) support, I admit that it's a bit inconsistent with how queryCommandEnabled() works with other commands. Maybe the perfect API would have a tri-state return value from queryCommandEnabled() - for example false,true,'user initiated'..)

So it actually seems pretty close to what you're proposing.

Indeed.

from clipboard-apis.

+1 being able to call queryCommandSupported() and get true where is it supported and then use queryCommandEnabled() to check whether execCommand will succeed or not.

from clipboard-apis.

Well, I am just wondering how all the other browsers are returning true when queryCommandSupported() is used but Chrome always returns false. I just started trying to implement this into our CMS today, as FF announced support for it this month, only to find out that Chrome has a weird behavior that it always returns false so my copy button is never displayed in chrome, when chrome does support it, plus it has been almost 3 months since this was last commented on, is anything being done with it?

from clipboard-apis.

+1 for queryCommandSupported() to return true where is it supported

from clipboard-apis.

btw, I had to write a polyfill for document.queryCommandSupported to get this right on Chrome and Firefox

from clipboard-apis.

before(cut|copy|paste) events are now killed. Goodbye to this bug too. See #25 for details.

from clipboard-apis.