Can you provide an example of such a link? I ran your snippet in the console for this page, middle-clicked on the " Issue 611972 " link and the message is printed just as expected.

I guess that the page uses event.stopPropagation() when it is "not working". Try setting the useCapture parameter to true, i.e. use

document.addEventListener("click", function(e) {
	if (e.button === 1 ) {
		console.log("hello");
	}
}, true); // <---- true

youtube.com - works great with stable version of Chrome, but not with Canary

Which link? If it's difficult to explain in words, take a screenshot and mark the link that should be clicked.

https://www.youtube.com/watch?v=FrG4TEcSuRg
http://postimg.org/image/98c9qanch/

It is not specific to links, the following minimal test case also shows the problem.

1. Open data:text/html,<script>document.addEventListener('click',function(e){alert(e.button)})</script>
2. Use the scroll wheel to click.
3. Expect a dialog that shows "1" (on Canary nothing is shown).

I did a bisect (https://www.chromium.org/developers/bisect-builds-py) and got:

You are probably looking for a change made after 390188 (known good), but no later than 390199 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/5433e667fc2a2a1e62e969a8d7539081c4dde9c3..94d5fad34f0351e61fd658ca4ed93648c415620d

Suspect: 76fea00a18f75886ea649414393228180306e13d ( bug 255 ).

This change seems intentional...

Yes. The change was technically intentional to make Chrome inline with the spec and other browsers like FF. Regarding the websites posted, can you explain a little more where to middle click and what to expect that it doesn't work in Canary?

#6 I added steps to reproduce in #5.

Open the following URLs and use the mouse wheel to click on the link.

data:text/html,<a onclick="event.preventDefault()" href="javascript:alert(1)">Test</a>
data:text/html,<a onmousedown="event.preventDefault()" href="javascript:alert(1)">Test</a>
data:text/html,<a onmouseup="event.preventDefault()" href="javascript:alert(1)">Test</a>

In the last two cases, the dialog always pops up (before and after your fix to  issue 255 ).
In the first example, the dialog does not show up in Chrome stable (M-50) (as expected), but the dialog unexpectedly shows up in Canary (M-52) (i.e. the default click action was not blocked).

What the reporter actually wants is to prevent the link from being opened in a new tab when the mousewheel is used for clicking.

How does he do that right now in FireFox?

Afaik not; He built a Chrome extension which used to work until  bug 255  was fixed. It might be a good idea to check with other vendors on how they intend to solve this issue.

Is the extension now published? Do you know the name of the extension?

"How does he do that right now in FireFox? - It actually works in Firefox. I've developed the same extension also for Firefox

#11 Then it'd be nice if you share how you did it, since none of the above three test cases (comment 7) work.

It's same as in first comment:

addEventListener("click", function(e) {
    if (e.button === 1 && e.target.closest("a") != null) {
            e.preventDefault();
            e.stopPropagation();
});

How come? I just tested that and they were not firing click event for button == 1.

Here is my example:
https://output.jsbin.com/porezi


I tested with FF 45.0 on Mac. Can you elaborate a bit more and what you see?

This works, indeed:

data:text/html,<a href="javascript:alert(1)">Test</a><script>addEventListener("click", function(e) {e.preventDefault();})</script>

It appears that in Firefox, the click event is dispatched on document and bubbles up to window:

data:text/html,<script>window.onclick = function(e){alert(e.button);}</script>Alert
data:text/html,<script>document.onclick = function(e){alert(e.button);}</script>Alert
data:text/html,<script>document.body.onclick = function(e){alert(e.button);}</script>No alert

Yeah. But it doesn't dispatch it to the elements inside.
I need to investigate a bit more with other vendors and see why they do that.
I'll probably revert the original change of suppressing click event for button==1 for now.

#16 "I'll probably revert the original change of suppressing click event"
Please answer when you decide what you are going to do with it.
And if you not going to revert it, I'd like to know why? Because as we found out it works in FF - "The change was technically intentional to make Chrome inline with the spec and other browsers like FF" - and why the spec requires its removing?

Reposting #18 with the correct links:

I forgot to update this issue. We talked about this and decided not to revert it for now. We would like this to hit beta and see if it causes any more issues like this. 
Regarding the spec, here is the link to the spec:
https://www.w3.org/TR/DOM-Level-3-Events/#event-type-click

as it's stated the click event should only be fired for primary button of the mouse. Regarding the history of it you can have a look at  issue 255 . I understand that the change will remove the functionality to prevent the browser to open a new tab and we are working on a workaround for that. But in the meantime if you only need the actual event I believe you can use the following workaround:

var middleButtonMouseDownTarget = null;

document.addEventListener('mousedown', function(e) {
  if (e.button == 1) {
    middleButtonMouseDownTarget = e.target;
  }
}, true);
document.addEventListener('mouseup', function(e) {
  if (e.button == 1) {
    if (e.target == middleButtonMouseDownTarget)
      e.target.dispatchEvent(new MouseEvent('click', e));
    middleButtonMouseDownTarget = null;
  }
}, true);

Also is it possible for you to use another control instead of (Ctrl/Shift + middle click) which I believe is not reliable as you see from the spec anymore.

#19 "if you only need the actual event"
yeah I know it's not a problem if I don't need "prevent default"

"we are working on a workaround for"
ok, thank you for the info

Moving this nonessential bug to the next milestone.

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

I'm going to close this for now.

Hopefully we can work on this soon:
https://discourse.wicg.io/t/new-event-for-non-primary-button-click/1527

Hi Navid,

It has been two weeks since the last message on that thread. Can you try to ensure that there is a good alternative to catching and blocking middle-click events before the 'click' event disappears?

I predict that if Chrome lands in its current state, that you will receive bug reports for a few months. At least, that is what happened when I fixed Chrome's behavior of the :focus pseudo-class on anchor tags ( bug 388666 ). In my case, developers and users are able to fix their websites to get the desired effect.
But in your case, devs/users currently have no way to get their desired (=previous) behavior. The new click behavior is indeed standards-compliant (and like IE / Edge), but inconsistent with Firefox and Safari. Safari is like the old Chrome, and Firefox fires the click event for listeners on document and window (this allows pages and add-ons to change the behavior for middle-click).


PS. I've changed the status from Fixed to WontFix because the reported issue was not fixed, but deemed "working as intended".

Hi Rob,

I'll wait until the end of June and then I will discuss with others what the best course of action is in this case based on the number of reports we will get. I'll have a close eye on this issue.

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/

Great, thanks for this information.
Will it be integrated successively Canary->Beta->Stable or at once for all?

It is targeted for Chrome 55. So right now it is in Canary. It should be in dev by the end of the week or early next week. The beta 55 will come out on sometime around October and will hit stable around November. Until then we can fix any other issues that may come up and also give the website enough time to adapt I believe.

If you want to listen to only non-primary clicks then yes. But if you like to listen to both primary click and non-primary ones then you need to have your handler to handler both of the events.

Yeah, works in Canary (but had to update it first)