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

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[(no longer active)]

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.

Comment 1

[Nika Layzell [:nika] (ni? for response)]

Attachment: Allow cut/copy event dispatch unconditionally in HTML documents

Comment 2

[(no longer active)]

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.

Comment 3

[Nika Layzell [:nika] (ni? for response)]

Attachment: Allow cut/copy event dispatch unconditionally in HTML documents

Fixed indentation

Comment 4

[Nika Layzell [:nika] (ni? for response)]

Please check in after Bug 1162952

Comment 5

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1921222e708e

Comment 6

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1921222e708e

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/1921222e708e

Comment 8

[Neil Deakin]

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.

Comment 9

[Neil Deakin]

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.

Comment 10

[Duan Yao]

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.

Comment 11

[Nika Layzell [:nika] (ni? for response)]

(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.