Closed Bug 1159490 Opened 5 years ago Closed 4 years ago

Dispatch the clipboard events unconditionally when the user presses Ctrl+C/X/V even if the commands are disabled

Categories

(Core :: DOM: Events, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla41
Tracking Status
firefox41 --- fixed

People

(Reporter: ehsan, Assigned: Nika)

References

(Depends on 2 open bugs)

Details

Attachments

(1 file, 1 obsolete file)

This was discussed in <https://groups.google.com/forum/#!searchin/mozilla.dev.webapi/execcommand$20copy$20paste/mozilla.dev.webapi/Bvb-S152azI/APi3o1XoSsgJ>.

I think we need to fix goDoCommand to not check whether these commands are enabled before invoking them, and fix the command controllers to say they are always enabled in order for things such as menu items and toolbar buttons to remain enabled...

There's probably some details missing from this brief description.
Assignee: nobody → michael
See Also: → 596764
Blocks: 1162952
Blocks: 1012662
Comment on attachment 8604215 [details] [diff] [review]
Allow cut/copy event dispatch unconditionally in HTML documents

Review of attachment 8604215 [details] [diff] [review]:
-----------------------------------------------------------------

This looks fine to me, but I would like Neil to take a look at it as well.

::: toolkit/content/tests/chrome/bug366992_window.xul
@@ +47,1 @@
>                                   .getAttribute("disabled") == "true";

Nit: please fix the indentation.
Attachment #8604215 - Flags: review?(neil)
Attachment #8604215 - Flags: review?(ehsan)
Attachment #8604215 - Flags: review+
Fixed indentation
Attachment #8604215 - Attachment is obsolete: true
Attachment #8604215 - Flags: review?(neil)
Attachment #8605301 - Flags: review?(neil)
Attachment #8605301 - Flags: review?(neil) → review+
Please check in after Bug 1162952
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/1921222e708e
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Depends on: 1170531
Er, isn't this meant to apply only when focus is in an html document? I am very strongly opposed to change if not. This (or the other bug) has made the cut/copy command enabled all the time, even if, for example, a button in the preference window is focused, which is certainly wrong.

I filed bug 1170531 on this.
Yeah, looking at the patch, this isn't the right way to fix this. There's a controller in nsGlobalWindowCommands.cpp for each window that handles whether the command should be enabled when something non-editable is focused. For editable contexts such as <input> there's a different one in nsEditorCommands.cpp

What I think you actually want is just make nsClipboardCommand::IsCommandEnabled return true unconditionally for html documents. (or perhaps for things that are not xul documents). This gets called whenever something happens that could affect the clipboard command state.
Unfortunately, paste event is still not fired in Firefox 41 if the page has no editable element.

Test case:

open https://bugzilla.mozilla.org/attachment.cgi?id=8605301 , and open dev tools;
run this code `addEventListener('paste', function() {console.log('paste')})`;
copy something and press Ctrl+V in the page.

Expected:

console shows 'paste'.

Actually:

nothing is shown.
Blocks: 1208217
(In reply to Duan Yao from comment #10)
> Unfortunately, paste event is still not fired in Firefox 41 if the page has
> no editable element.
> 
> Test case:
> 
> open https://bugzilla.mozilla.org/attachment.cgi?id=8605301 , and open dev
> tools;
> run this code `addEventListener('paste', function() {console.log('paste')})`;
> copy something and press Ctrl+V in the page.
> 
> Expected:
> 
> console shows 'paste'.
> 
> Actually:
> 
> nothing is shown.

It appears as though at some point when fixing the menu items I regressed addEventListener('paste') on documents without an editor - if there is a `<div contenteditable>` on the page, everything seems to work correctly...

I filed bug 1208217 about it.
Depends on: 1271897
Depends on: 1327385
Depends on: 1327828
Depends on: 1328027
Depends on: 1328028
Depends on: 1328029
You need to log in before you can comment on or make changes to this bug.