1356309 - Chrome compatability - WebExtensions should be able to create "real" mouse events

Status: RESOLVED DUPLICATE of bug 1348213

(WebExtensions :: Compatibility, defect)

Description

[mrmr1993]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170329150444

Steps to reproduce:

Use a content script in a WebExtension to simulate clicking a link, with a modifier key pressed. For example:

  var mouseEvent = document.createEvent("MouseEvents");
  mouseEvent.initMouseEvent("click", true, true, window, 1, 0, 0, 0, 0,
    true /* ctrl */,
    false /* alt */,
    false /* shift */,
    false /* meta */,
    0, null);
  link.dispatchEvent(mouseEvent);


Actual results:

The simulated event doesn't trigger the default action.


Expected results:

The event should be treated the same as a real mouse event. (In the example above, the link should open in a new background tab.)

Chrome currently supports this behaviour, and it is used by the Vimium extension (which we would like to port to Firefox).

The following Chromium issue might provide some further context:
https://bugs.chromium.org/p/chromium/issues/detail?id=454222

My comment #42 on the issue also gives a test-case.
https://bugs.chromium.org/p/chromium/issues/detail?id=454222#


This is related to bug 1348213
https://bugzilla.mozilla.org/show_bug.cgi?id=1348213

Comment 1

[Caitlin Neiman [:caitmuenster]]

Hi mrmr1993, this has been added to the agenda for the June 13 WebExtension APIs triage meeting. Would you be able to join us? 

Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Next_Meeting

Agenda: https://docs.google.com/document/d/1A_M0YD86Plcs6eHyM2KXkDXY074BHZ3fZvaWXCljQLI/edit#heading=h.34n4lirhljve

Comment 2

[Luca Greco [:rpl] [:luca] [:lgreco]]

There are some concerns about how this kind of feature could be abused by some extensions,
in the meantime it is reasonable to make this a dupe of Bug 1348213. 

(as also stated by Comment 0, both these issues are pretty related to each other, e.g. if these concerns end to block Bug 1348213, they will block this one as well, or if on the contrary Bug 1348213 proceeds, the new API is likely to be able to cover both keyboard and mouse events)

Comment 3

[mrmr1993]

Sorry I didn't make the meeting, I missed your message in my inbox.

Does this mean that the intention is not to match the Chrome behaviour, ie. exempting WebExtensions from the popup-blocker?

> There are some concerns about how this kind of feature could be abused by some extensions

Is there somewhere I could find a record of the meeting? Certainly, for clicking anything (except maybe an <input type=file>), an extension can already do everything that a privileged click can, except for knowing whether the default action should be triggered.

Comment 4

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to mrmr1993 from comment #3)
> Sorry I didn't make the meeting, I missed your message in my inbox.
> 
> Does this mean that the intention is not to match the Chrome behaviour, ie.
> exempting WebExtensions from the popup-blocker?

There are other areas where we don't always match the Chrome behavior,  that is especially for the content scripts that are implemented differently in Firefox (as an example, in a Firefox content script you need to use the Firefox specific "cloneInto" method to make an object created in the content script context available to the webpage javascript code, e.g. through the details of a DOM custom event),.

I would also make it sure that is clear that by marking this a duplicate of Bug 1348213 I was not saying that "we have no intention of doing something about it", but that these two bugs share the same concerns and they are likely to share the same final decision (in other words if we are going to solve it for the keyboard events, then we will need to solve it for the mouse events as well). 

About "exempting a WebExtensions from a popup blocker", it would be probably better to discuss it in a separate bugzilla issue
(e.g. because is probably not an issue specific to the mouse events).

> 
> > There are some concerns about how this kind of feature could be abused by some extensions
> 
> Is there somewhere I could find a record of the meeting? 

I'm not sure if these meetings are recorded (Caitlin will know for sure).

> Certainly, for clicking anything (except maybe an <input type=file>), an extension can
> already do everything that a privileged click can, except for knowing
> whether the default action should be triggered.

My feeling is that the concerns are not related to the content script "acting as the webpage",
but mostly about making it able to "act as the user" (and they are currently concerns and not a final decision, Bug 1348213 has not been denied or approved yet).
 
(e.g. one reason can be that in Firefox that behavior is achievable by dispatching the events through a privileged feature that would make these event mostly "indistinguishable" from the one that the user creates
by clicking with the mouse).