Bug 52174

Summary: Control-click on Mac should trigger a mouse event with event.button == 2
Product: WebKit Reporter: Nick Santos <nicksantos>
Component: UI EventsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Normal CC: ahmad.saleem792, akeerthi, ap, arv, bfulgham, darin, hyatt, mjs, rniwa, simon.fraser, wenson_hsieh
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.6   

Description Nick Santos 2011-01-10 15:52:17 PST
Description: On Mac, control-click brings up a contextmenu, but webkit fires a mouse event with button == 0.

Repro steps:
1) Execute the following JS on any page.
document.body.addEventListener('mousedown', function(e) { alert(e.button); }, false);
2) Ctrl-click on the page.

Expected behavior:
alert(2);
like on Gecko, or when doing 2-finger clicks on certain Mac touchpads

Actual behavior:
alert(0);

For what it's worth, here's the relevant spec:
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-click
which is ambiguous, but seems to slightly tilt in favor of the gecko behavior.

Also, because two-finger click on touchpads have event.button == 2, it seems like the ctrl-click behavior should be consistent.
Comment 1 Erik Arvidsson 2011-01-10 15:55:08 PST
Also, Opera 11 reports button as 2 when Ctrl-left clicking on Mac OS X.
Comment 2 Ojan Vafai 2011-01-11 12:07:11 PST
CCing some people who might care. Matching gecko here seems best to me.
Comment 3 Darin Adler 2011-01-11 15:04:53 PST
Those other browsers are browsers whose highest market share is on Windows, ported to Mac. I’m sure that in that context it seems the best way to express a control-click is to pretend it’s a right-click.

Keep in mind that you might have a multiple button mouse and to send a click on the left button with the control key held down through as a click on the right button is a lie, and will make distinct events (control click on left button vs. control click on right button) look identical to the web page.

The primary web browser on Mac with the largest market share has told the truth about these events to webpages for 8 years without major incompatibilities arising.

I’m not sure it’s urgent to change WebKit and Safari to tell this lie, just because ported Windows browsers are doing so.
Comment 4 Darin Adler 2011-01-11 15:05:37 PST
This bug doesn’t mention any actual website compatibility problems. Are there some?
Comment 5 Nick Santos 2011-01-11 15:24:27 PST
Sure, log in to
http://www.gmail.com/
ctrl-left-click on any of the dropdowns ("Move to" and "Label" are both good candidates)

Expected behavior:
You should get a context menu

Actual behavior:
You get a context menu and the dropdown opens.

I can see reasonable arguments for both button == 0 and button == 2.

Two tangential thoughts:
1) Is there ever a reason why a web developer would want different handlers for Ctrl-LeftClick and RightClick?
2) It would be nice if the HTML5 spec was clearer about what the behavior should be.
Comment 6 Ojan Vafai 2011-01-11 15:37:54 PST
(In reply to comment #3)
> Keep in mind that you might have a multiple button mouse and to send a click on the left button with the control key held down through as a click on the right button is a lie, and will make distinct events (control click on left button vs. control click on right button) look identical to the web page.

I hadn't thought about that case. Does that case actually matter? Safari and Chrome pull up the context menu for both of those? Is there a use-case for developers to treat those differently?

> I’m not sure it’s urgent to change WebKit and Safari to tell this lie, just because ported Windows browsers are doing so.

Matching Windows expected behavior is not the motivation. Compatibility with other browsers is. It's more that web developers wanting to capture right-click need to write extra code for WebKit.

(In reply to comment #4)
> This bug doesn’t mention any actual website compatibility problems. Are there some?

In Google's Closure library the right-click handling code doesn't handle this case (causing the gmail bug). Closure can certainly just be fixed. In fact, this bug was filed as a result of a codereview attempting to fix it. But it seems likely that other sites that try to handle right-click will hit this issue. 

Darin, if you still disagree, we can close the bug and fix Closure instead. We should probably also file a Mozilla bug to try to get them to change to match WebKit in that case.
Comment 7 Darin Adler 2011-01-11 15:45:49 PST
(In reply to comment #6)
> In Google's Closure library the right-click handling code doesn't handle this case (causing the gmail bug). Closure can certainly just be fixed. In fact, this bug was filed as a result of a codereview attempting to fix it.

OK. Please do fix that in Closure. There are millions of Safari users out there who could probably benefit from that change, regardless of what we do in future versions of WebKit.

> But it seems likely that other sites that try to handle right-click will hit this issue.

Do we have even one bug report about even one? Lets not assume.

> We should probably also file a Mozilla bug to try to get them to change to match WebKit in that case.

Sure, that would be OK.
Comment 8 Ahmad Saleem 2022-07-21 16:25:05 PDT
I am not wrong and not doing it incorrectly, I get same behavior across all browsers using test case from Description / Comment 0. I performed following on Safari 15.6, Chrome Canary 105 and Firefox 104 using macOS 12.5:

1) Webkit Link
2) Open Console and typed:
document.body.addEventListener('mousedown', function(e) { alert(e.button); }, false);
3) Pressed Control and then left click on trackpad (verified left clicking by MDN following test:

https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/button

All browsers reported '0' and then opened Context Menu of page.

Is it expected behavior or there is something else needed. Just wanted to share what I was able to perform and share the results. Please ignore, if my testing is incorrect or results are incorrect. Thanks!
Comment 9 Darin Adler 2022-07-22 15:10:06 PDT
I don’t agree with the resolution here. It seems that we, and the teams working on the other web browsers, decided *not* to make the change requested here. So the resolution would be INVALID.
Comment 10 Brent Fulgham 2022-07-22 15:26:27 PDT
That sounds reasonable. Switching to RESOLVED | INVALID.