1455479 - Non-editable elements with onpaste handlers should get a "Paste" command in their context menu

Status: RESOLVED WONTFIX

(Firefox :: Menus, enhancement, P5)

Description

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Web applications can create non-editable elements with onpaste handlers. For example I have an element representing a terminal emulator which is focusable, responds to keypresses, and has a "paste" handler that processes pasted text. Pasting works in Firefox and Chrome using Ctrl-V to paste into the focused element. However, in Firefox Nightly and Chrome Dev, right-clicking on the element produces a context menu without a paste command.

This is annoying and there doesn't seem to be any good way to work around it. I tried working around it by turning "contenteditable" on on right-mouse-down and removing it on right-mouse-up; this crazy hack works in Chrome, but not Firefox.

I think a context menu whose initial target is an element with an ancestor with a "paste" event handler should have a "Paste" menu item as if it was editable. (The event bubbles so we can expect "Paste" to do something if any ancestor has a handler.)

Comment 1

[Jared Wein [:jaws] (please needinfo? me)]

This could be a good mentored bug if someone wanted to put some steps on how to check if an element or an ancestor has a "paste" event listener. Once that is figured out, https://searchfox.org/mozilla-central/rev/fcd5cb3515d0e06592bba42e378f1b9518497e3d/browser/base/content/nsContextMenu.js#621 and "context-sep-paste" would need to be updated to show the paste item.

Comment 2

[:Gijs (he/him)]

(In reply to (slow to respond 4/23 to 4/27) Jared Wein [:jaws] (please needinfo? me) from comment #1)
> This could be a good mentored bug if someone wanted to put some steps on how
> to check if an element or an ancestor has a "paste" event listener. Once
> that is figured out,
> https://searchfox.org/mozilla-central/rev/
> fcd5cb3515d0e06592bba42e378f1b9518497e3d/browser/base/content/nsContextMenu.
> js#621 and "context-sep-paste" would need to be updated to show the paste
> item.

You can ask the event listener service for listeners on an element ( https://dxr.mozilla.org/mozilla-central/rev/8d4cf28964f6956cd22d8710b316456e2c7c848d/dom/events/nsIEventListenerService.idl#65-72 ), but I think you might need to walk up the tree manually (and repeat the call) to find ancestor listeners, which seems like a pain... Olli, is there a better API? Should we make one?

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

What is painful there? First you would call getEventTargetChainFor and then for each item in the array hasListenersFor.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1455479 - Show paste context menu item when there are paste event listeners. r=Gijs

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/73181c2aa309
Show paste context menu item when there are paste event listeners. r=Gijs

Comment 6

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/73181c2aa309

Comment 7

[Emilio Cobos Álvarez [:emilio]]

So, this caused a bunch of false positives on huge sites like Facebook / Google / etc (and our homepage too). See bug 1679050 comment 4.

Turns out people love to have event handlers that do nothing... I thought of ignoring event handlers on the root or what not, but even that's not enough (Google homepage has a bunch of handlers on a random div that contains most of the page for example).

So given that when that happens we show the paste menu, but it does nothing and it's super-confusing for users, I think this is unfortunately wontfix, unless we somehow want to expose an opt-in into doing it, somehow.

For now, backed out in https://hg.mozilla.org/integration/autoland/rev/59216bd2227a