1374096 - (e10s) Implemented auxclick - but event.preventDefault() does not work properly when used with e10s ON

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect, P2)

Description

[janekptacijarabaci]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:45.9) Gecko/20100101 Goanna/3.2 Firefox/45.9 PaleMoon/27.3.0
Build ID: 20170422220104

Steps to reproduce:

Ad:
https://bugzilla.mozilla.org/show_bug.cgi?id=1304044

Implemented auxclick - but event.preventDefault() does not work properly when used with e10s ON

An example:
https://wicg.github.io/auxclick/

See also:
https://bugzilla.mozilla.org/show_bug.cgi?id=1327933#c7



Actual results:

The context menu appears.



Expected results:

The context menu is blocked and not displayed.

Comment 1

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

Kevin, could you take a look?

Comment 2

[janekptacijarabaci]

Correcting the above example:
https://mdn.github.io/dom-examples/auxclick/

Comment 3

[Kevin Wern]

Sure, I can have a look in the next day or so.

Comment 4

[Kevin Wern]

This isn't a bug. From the W3C draft:

> In the case of right button, the auxclick event is dispatched after any contextmenu event.
> Note that some user agents swallow all input events while a context menu is being displayed,
> so auxclick may not be available to applications in such scenarios. 

https://w3c.github.io/uievents/#example-auxclick-right

contextmenu fires before auxclick, so it's impossible to disable the context menu via preventDefault for an auxclick event. In the example from STR, you would have to call preventDefault in a separate handler for contextmenu.

Comment 5

[janekptacijarabaci]

IMHO: In that case, it is bug for e10s off.

Comment 6

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

Yeah, we should behave the same way in e10s  and non-e10s. And I think we could show contextmenu in response to auxclick. If contextmenu event or auxclick is canceled, then don't show the menu.

How do other browsers behave?

Comment 7

[Kevin Wern]

(In reply to janekptacijarabaci from comment #5)
> IMHO: In that case, it is bug for e10s off.

Ok yeah, I tested it on Windows and got the same behavior as you. I was on OS X and got the context menu for both e10s and non-e10s. So I'm on the same page as you guys now :).

(In reply to Olli Pettay [:smaug] from comment #6)
> Yeah, we should behave the same way in e10s  and non-e10s. And I think we
> could show contextmenu in response to auxclick. If contextmenu event or
> auxclick is canceled, then don't show the menu.
> 
> How do other browsers behave?

Did a bit of testing with the auxclick demo:

Windows:
    Chrome:
        Demo: shows context menu, correct color behavior.
        Normal event order: auxclick, contextmenu
    FF (non-e10s):
        Demo: doesn’t show context menu (contextmenu never fired), correct color behavior
        Normal event order: auxclick, contextmenu
    FF (e10s):
        Demo: shows context menu, correct color behavior
        Normal event order: auxclick, contextmenu

OS X:
    Chrome:
        Demo: shows context menu, which suppresses auxclick--so no color change unless clicking in the same spot.
        Normal event order: contextmenu, auxclick
    FF  Nightly (non-e10s):
        Demo: shows context menu, correct color behavior
        Normal event order: contextmenu, auxclick
    FF Nightly (e10s):
        Demo: shows context menu, correct color behavior
        Normal event order: contextmenu, auxclick

Webkit is still in the process of implementing auxclick.

The core problem with respect to cancelling the context menu through auxclick is that different OSs display the context menu at different times. On OS X, the menu is displayed when the secondary mouse press bottoms out; on windows, it is shown after the button is pressed and released. So in the first scenario, if you hold down the mouse button, the context menu will display, firing contextmenu, and auxclick won't even happen until the mouse is released.

So IMO, the issue is contextmenu being cancelled with auxclick in this one case (Windows non-e10s). I'll look into fixing that when I get a chance.

Let me know what you think.

Comment 8

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

Hmm, I wonder how this should work.

Rick, any preferences? Looks like Chrome is also rather inconsistent.

Comment 9

[Rick Byers]

Yeah the difference in host-OS convention here (show on down or up) is annoying and (I think) an unavoidable behavior difference exposed to web pages (unless we want context menus to behave differently in the browser than host OS convention).  But I think all that pre-dates auxclick (we're not talking here about changing the timing of contextmenu relative to mousedown/mouseup, right?).  

auxclick follows the same timing rules as 'click' so occurs after mouseup.  Given that I think we just need to be consistent in ensuring that cancelation of auxclick is entirely independent from context menu behavior.

+nzolghadr in case there are any details / context I've missed.

Comment 10

[sitedeveloper1]

Let me contribute to bug cases of auxclick.

Description
Auxclick event.preventDefault() does not work.

Steps to reproduce:
0. Visit https://jsfiddle.net/L35z6Lsa/1/ 
OR
1. Have a link with an href  
2. Assign click and auxclick events
3. Make event.preventDefault() in both cases
4. Save the JS code
-----------
5. Try to click the link
6. Try to Ctrl+click the link
7. Try to middle click the link


Actual results:
Step 5: [OK] Link navigation is prevented as expected.
Step 6: [OK] Link navigation is prevented as expected.
Step 7: [BUG] Link navigation is NOT prevented in Firefox and is prevented in Chrome as expected.


Expected results:
Link navigation should be also prevented at step 7 in Firefox.

Comment 11

[sitedeveloper1]

Some missing details:

Firefox version: 54.0.1
buildID: 20170628075643

I don't know whether it is related to e10s features but here it is.

about:config
browser.tabs.remote.autostart = false (default)
browser.tabs.remote.autostart.2 = true (user set)

Comment 12

[Navid Zolghadr]

Yeah. I don't have much to add beside the cases that are already mentioned in the comments.

Just one note that Firefox should stop sending click for the non-primary buttons even at the document level:
https://bugzilla.mozilla.org/show_bug.cgi?id=184051

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:hsinyi, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 14

[Hsin-Yi Tsai (she/her) [:hsinyi]]

I couldn't reproduce it anymore.
Comment 10 works well for me as well as the MDN example