djunicorn420@ Thanks for the issue.

Could you please provide us the sample test file or URL to triage the issue from test team end.

Thanks,

Open the file in current Chrome stable 51 and Chrome beta 52, click the link using the mousewheel button.

In Chrome 51 the click is detected, in Chrome 52 the click is no longer detected.

Firefox and IE also detect the click.

In fact, just clicking anywhere in the document using the mousewheel should trigger the click event, it does not actually need to be on a link exclusively.

Deleted: test.html 328 bytes

test.html 328 bytes View Download

This is a regression, it works as expected in Chrome Version 51.0.2704.79.

Side effect of #255, I believe.

There should be more tests to make sure Blink matches Gecko behavior.

For example preventing click event when middle-clicking. Should it prevent opening of the link? It does in Gecko.

Thank you for providing more feedback. Adding requester "kavvaru@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This change was indeed intentional as per  Issue 255 . Note that the spec changed to dedicate click event to only primary key. Gecko sends the click event for middle button only to the document and window and not to any elements inside the document which nobody remembered why that is the case. Edge also has a bug tracking this issue to remove click for middle button like Chrome. Beside the fact that we don't send click for middle button can you tell us if you have any particular website that is broken right now?

Can't speak for original reporter but me and chrisk had our internal Opera pages in mind which broke after fix for  Issue 255 . I don't have examples of any normal pages being affected.

BTW. Currently it's still possible to cancel middle click on a link in Firefox (even if you are saying they don't know why it's like that). If the goal is to make that impossible in Chromium, this will be a problem for our internal pages where we want to redirect middle-click on links to an extension API and open tabs from there. Whatever is decided, please consider being interoperability with other browsers for the time being.

Absolutely. We wanted to do the change to see what is the interop side effects of it. We also had a few internal pages that were broken but I'm going through them and fix them somehow. I believe following the spec at some point we need to remove click from non-primary buttons. Note that this default behavior of opening a new tab for middle click is not in any spec as far as I found. So I started this proposal to maybe make this more formal. Let me know what you think about that:

https://discourse.wicg.io/t/new-event-for-non-primary-button-click/1527

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4d9d9183fe8c1a4dbfac9f4a6ef8a337b05c1a40

commit 4d9d9183fe8c1a4dbfac9f4a6ef8a337b05c1a40
Author: nzolghadr <nzolghadr@chromium.org>
Date: Fri Jul 01 19:02:51 2016

Revert middle click related changes

This is the CL to revert the related middle button click changes. We
decided to revert those changes because the issues that were caused by
suppressing click event for middle button was hard to fix without having
that event. Particularly the ability to prevent opening a new tab which
can be done by "preventDefault"ing the click event of middle button was
removed as the result of the original change. For now we revert these
changes and we pursue the line of adding a new event for non-primary
button click to be able to fix these problem in a more clean way.

Revert "Prevent sending click event for non primary button"

This reverts commit 76fea00a18f75886ea649414393228180306e13d.

Revert "Dispatch middle click manually by tracking mouse"

This reverts commit 88eb1110baafcba070e750866a343e81b6bcc524.

Revert "Fix history page middle click action"

This reverts commit a154aed1a3813cf28c6f477579ed7974a2528570.

BUG= 255 , 618593 , 617444 , 611019 , 617875 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2107093003
Cr-Commit-Position: refs/heads/master@{#403496}

[modify] https://crrev.com/4d9d9183fe8c1a4dbfac9f4a6ef8a337b05c1a40/chrome/browser/resources/history/history.js
[modify] https://crrev.com/4d9d9183fe8c1a4dbfac9f4a6ef8a337b05c1a40/chrome/browser/resources/ntp4/new_tab.html
[delete] https://crrev.com/afd007a5a072039641b7b81eddd9aa488cec4996/chrome/browser/resources/synthetic_middleclick.js
[modify] https://crrev.com/4d9d9183fe8c1a4dbfac9f4a6ef8a337b05c1a40/chrome/browser/ui/browser_browsertest.cc
[modify] https://crrev.com/4d9d9183fe8c1a4dbfac9f4a6ef8a337b05c1a40/testing/buildbot/filters/browser-side-navigation.linux.browser_tests.filter
[modify] https://crrev.com/4d9d9183fe8c1a4dbfac9f4a6ef8a337b05c1a40/third_party/WebKit/LayoutTests/fast/events/mouse-click-events-expected.txt
[modify] https://crrev.com/4d9d9183fe8c1a4dbfac9f4a6ef8a337b05c1a40/third_party/WebKit/LayoutTests/fast/events/script-tests/mouse-click-events.js
[modify] https://crrev.com/4d9d9183fe8c1a4dbfac9f4a6ef8a337b05c1a40/third_party/WebKit/Source/core/events/MouseEvent.cpp
[modify] https://crrev.com/4d9d9183fe8c1a4dbfac9f4a6ef8a337b05c1a40/third_party/WebKit/Source/core/input/EventHandler.cpp

The idea behind limiting the click event just to one mouse button is flawed and should not be pursued.

A click is intuitively related to a button press from a pointer equipment and these equipments can have more than one button. There are already sufficient methods to distinguish which button was used behind the click event, but there are none if this event becomes strictly related to one button only.

Mouseup events are not a solution for the problems such change brings, first and foremost there is the problem between differentiating a click from a non-primary button via mouseup event and a dragging action followed by mouseup. The workaround these problems is inconceivable, it would cause extreme strain on the developers trying to make use of clicks originated by non-primary pointer buttons as it would make almost impossible to handle click events originated by touch/touchscreen interfaces.

As it stands any justification behind this action has no merit and should not be pursued, there is no logical reason that can justify limiting the click event just for one button while removing the ability to work with any other button instead of just filtering the click event via event.which or event.buttons, which will not sacrifice anything.

I personally agree with you djunicorn420@ and totally understand there is enough information in cthe lick event to decide what button was causing this. However, it seems most of the existing use cases of this event just assume click event is only for left (primary) button and their handlers don't check for the button. This causes lot of websites behave not as expected particularly while middle-clicking on the links. To be able to recover that (as per  Issue 255  and the "UI Event" spec) we need to pursue removing click for non-primary buttons just like what FF did before. However, we are adding the "auxclick" as per this proposal in this quarter which enables us to remove that non-primary button click event with less friction.

https://discourse.wicg.io/t/new-event-for-non-primary-button-click/1527

Please have a look at it and let us know your concerns there and also what you think about the proposal.

Thank you for the proposal. It sounds reasonable, but again it is more of a hack than a solution. The only problem behind all of this concern is, as it was said, developers not handling the click event properly. This is not a design flaw, or a rushed standard, it is developer ignorance (not meant as an offense, but as a fact).

From that perspective the reasoning behind these change attempts is still not logical because it caters even more to developer ignorance instead of letting them learn correctly by the error of their ways, and will cause more code overhead uncompensated by the benefit these changes bring.

For any other developer that wishes to listen to click events from any button, he will be forced to have two event handlers, always: one for the primary click and another for all the other clicks. Even if the auxclick event also includes the primary button click then what is the point of making these changes in the first place? If such is the case then a lot more developers will be forced to learn and adapt to the new changes instead of the few that did not learn to handle click events properly, which ends up contradicting the reasoning behind the changes in the first place.

As far as I can see, all of this does not make enough sense to justify changing the click event. Right now, the click event provides everything developers need to handle an interface click while the alternative will incur lots of confusion and possibly introduce code overhead.

And all of this is ignoring cases where users remap their equipment to make their non-primary buttons behave as primary button (ie: left-handed users with right-hand mice). Such changes would bring a lot more problems for cases like this than the ones that currently exist due to improper click event handler.

In my opinion the benefit of this change is not worth the problems it will bring.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f0dfcc7e4b98d8c891bb3a8bf03900403aab0637

commit f0dfcc7e4b98d8c891bb3a8bf03900403aab0637
Author: Dave Tapuska <dtapuska@chromium.org>
Date: Mon Jul 04 14:25:31 2016

Revert middle click related changes

This is the CL to revert the related middle button click changes. We
decided to revert those changes because the issues that were caused by
suppressing click event for middle button was hard to fix without having
that event. Particularly the ability to prevent opening a new tab which
can be done by "preventDefault"ing the click event of middle button was
removed as the result of the original change. For now we revert these
changes and we pursue the line of adding a new event for non-primary
button click to be able to fix these problem in a more clean way.

Revert "Prevent sending click event for non primary button"

This reverts commit 76fea00a18f75886ea649414393228180306e13d.

Revert "Dispatch middle click manually by tracking mouse"

This reverts commit 88eb1110baafcba070e750866a343e81b6bcc524.

Revert "Fix history page middle click action"

This reverts commit a154aed1a3813cf28c6f477579ed7974a2528570.

BUG= 255 , 618593 , 617444 , 611019 , 617875 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2107093003
Cr-Commit-Position: refs/heads/master@{#403496}
(cherry picked from commit 4d9d9183fe8c1a4dbfac9f4a6ef8a337b05c1a40)

Review URL: https://codereview.chromium.org/2121003002 .

Cr-Commit-Position: refs/branch-heads/2785@{#12}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/f0dfcc7e4b98d8c891bb3a8bf03900403aab0637/chrome/browser/resources/history/history.js
[modify] https://crrev.com/f0dfcc7e4b98d8c891bb3a8bf03900403aab0637/chrome/browser/resources/ntp4/new_tab.html
[delete] https://crrev.com/aaad16cd6a623d566e75f072db80264e4a5836ac/chrome/browser/resources/synthetic_middleclick.js
[modify] https://crrev.com/f0dfcc7e4b98d8c891bb3a8bf03900403aab0637/chrome/browser/ui/browser_browsertest.cc
[modify] https://crrev.com/f0dfcc7e4b98d8c891bb3a8bf03900403aab0637/testing/buildbot/filters/browser-side-navigation.linux.browser_tests.filter
[modify] https://crrev.com/f0dfcc7e4b98d8c891bb3a8bf03900403aab0637/third_party/WebKit/LayoutTests/fast/events/mouse-click-events-expected.txt
[modify] https://crrev.com/f0dfcc7e4b98d8c891bb3a8bf03900403aab0637/third_party/WebKit/LayoutTests/fast/events/script-tests/mouse-click-events.js
[modify] https://crrev.com/f0dfcc7e4b98d8c891bb3a8bf03900403aab0637/third_party/WebKit/Source/core/events/MouseEvent.cpp
[modify] https://crrev.com/f0dfcc7e4b98d8c891bb3a8bf03900403aab0637/third_party/WebKit/Source/core/input/EventHandler.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/eaaefc24ebb90ea1586f1ce7aee411da3da9d16e

commit eaaefc24ebb90ea1586f1ce7aee411da3da9d16e
Author: Dave Tapuska <dtapuska@chromium.org>
Date: Mon Jul 04 14:43:01 2016

Revert middle click related changes

This is the CL to revert the related middle button click changes. We
decided to revert those changes because the issues that were caused by
suppressing click event for middle button was hard to fix without having
that event. Particularly the ability to prevent opening a new tab which
can be done by "preventDefault"ing the click event of middle button was
removed as the result of the original change. For now we revert these
changes and we pursue the line of adding a new event for non-primary
button click to be able to fix these problem in a more clean way.

Revert "Prevent sending click event for non primary button"

This reverts commit 76fea00a18f75886ea649414393228180306e13d.

Revert "Dispatch middle click manually by tracking mouse"

This reverts commit 88eb1110baafcba070e750866a343e81b6bcc524.

Revert "Fix history page middle click action"

This reverts commit a154aed1a3813cf28c6f477579ed7974a2528570.

BUG= 255 , 618593 , 617444 , 611019 , 617875 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2107093003
Cr-Commit-Position: refs/heads/master@{#403496}
(cherry picked from commit 4d9d9183fe8c1a4dbfac9f4a6ef8a337b05c1a40)

Review URL: https://codereview.chromium.org/2124533002 .

Cr-Commit-Position: refs/branch-heads/2743@{#580}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/eaaefc24ebb90ea1586f1ce7aee411da3da9d16e/chrome/browser/resources/history/history.js
[modify] https://crrev.com/eaaefc24ebb90ea1586f1ce7aee411da3da9d16e/chrome/browser/resources/ntp4/new_tab.html
[delete] https://crrev.com/5f87571138ba5e85759984e956efcb6691cf3770/chrome/browser/resources/synthetic_middleclick.js
[modify] https://crrev.com/eaaefc24ebb90ea1586f1ce7aee411da3da9d16e/chrome/browser/ui/browser_browsertest.cc
[modify] https://crrev.com/eaaefc24ebb90ea1586f1ce7aee411da3da9d16e/testing/buildbot/filters/browser-side-navigation.linux.browser_tests.filter
[modify] https://crrev.com/eaaefc24ebb90ea1586f1ce7aee411da3da9d16e/third_party/WebKit/LayoutTests/fast/events/mouse-click-events-expected.txt
[modify] https://crrev.com/eaaefc24ebb90ea1586f1ce7aee411da3da9d16e/third_party/WebKit/LayoutTests/fast/events/script-tests/mouse-click-events.js
[modify] https://crrev.com/eaaefc24ebb90ea1586f1ce7aee411da3da9d16e/third_party/WebKit/Source/core/events/MouseEvent.cpp
[modify] https://crrev.com/eaaefc24ebb90ea1586f1ce7aee411da3da9d16e/third_party/WebKit/Source/core/input/EventHandler.cpp

Tested the issue on windows 7 using chrome version 53.0.2785.8 with the html attached in comment #2.Able to click on link using mouse middle click.new tab opened successfully.
Please find the attached screen cast for the same.

Adding TE-Verified labels.

Thanks,

Deleted: 617444.mp4 359 KB

	617444.mp4 359 KB View Download

Verified the issue on Latest Beta# 52.0.2743.75 on Windows and is working as intended.
Hence adding TE-Verified labels.
Note: Video is already attached in Comment# 17. The same behavior is displayed on the Chrome Beta mentioned.
Thank You.

The "click" event is no longer dispatched for non-primary buttons as per UI events spec. This will ensure the pages that don't check the buttons attribute on their click handlers don't show unexpected behaviors when middle clicking for example.
Instead there will be new event "auxclick" event for non-primary buttons that will be useful for some apps that truly care about click action for non-primary buttons. For example in case someone wants to prevent opening a new tab when middle clicking a link or adobt any other actions on click behavior of any non-primary button. Here is the spec for the event and some examples:
https://navidz.github.io/auxclick/

This is retarded, sorry but there is no better word.

Now every time we want to listen to any click events we are forced to listen to two different events instead of just one. Instead of letting ignorant developers learn how to handle the click event correctly through their mistakes, now all the developers that knew how to do things correctly will find their scripts broken and will have to learn again new things. In the end the ignorant developers will remain ignorant and we have to swallow yet another change and update everything click dependent retroactively on top of increasing script sizes.

The logic behind this change is unjustifiable. Following the same logic there should also be a unique event for right-clicks, middle-clicks, and any other type of clicks. The fact that there are no intentions of doing that should already be enough to understand why this change is absolutely retarded. A click is a click, it shouldn't be handled differently according to which button was used.

Are keypresses going to have different event handlers as well? Maybe we should change those too for when users just want to listen to the single event when a user presses the Enter key. Or a event just for the Escape keypress, or a unique event for any of the 100+ different keys available on a keyboard.

I am against this change, it should never go forward.

djuincorn420@ I have some justifications about some of the points you mentioned. But it might be better to mention the issues and also the justifications somewhere that more people are looking and we can discuss there.
Can you mention your points here:
https://github.com/w3c/uievents/issues/107