I have seen the same problem on different websites and links. I'm using Vista 32Bit

Interestingly, right click->open in new tab works as expected. Surely these should 
have the same functionality?

i am experiencing the same problem as the other 2 guys. i'm using chromium 0.3.155.0 
build 4393 on vista home premium 32-bit. i'm experiencing this on this page: http://www.sratim.co.il/movies/whatsnew.aspx

Taking these to triage.

Hmm, I tried http://www.sratim.co.il/movies/whatsnew.asp with my Logitech mouse.  
Clicking the scroll wheel (I don't have a middle mouse button besides the scoll wheel 
button) and everything worked.  However, I am using XP.

Perhaps this is related to the mouse you are using?  What mouse is it?

It could also be that I am clicking on the wrong links (given I don't read hebrew).  
Can you provide us with a very small HTML page that demonstrates the problem?

Go to the link in the original post and click the 'announcements' forum link. I am 
using XP with a logitech mouse.

1) it's not vista and it's not my mouse - i just tested the same site on my second 
computer, using a different mouse, running Chrome beta 0.3.154 on XP pro sp3
2) i checked the source of the page, and the only javascript for that the problematic links that i could find is: document.location='/movies/view.aspx?id=####' which is 
triggered onClick, where #### is the id number of the target page.

this also happens with the links in english on the page (next to each picture in the 
central table on the page are 2 links - 1 in hebrew and 1 in english).

The thing is...
You have a tag A with href and onclick (i.e. <a href="blabla.jsp" 
onclick="showLoadingScreen()">blabla</a>). When you click it with middle-mouse 
button, chrome calls the onclick event and opens href on a new tab.

I think it should not call the onclick event when you use middle-mouse button.

Our website seems to crash Chrome tabs sometimes when using middle-mouse click.

Lars, could you have someone look at this?

This is a WebKit issue.  I have just tested this on Windows in Safari 3.1.2 (525.21) 
and in a WebKit nightly build and they behave the same.  The issue is that middle 
clicking fires an onclick event which it does not seem to do in Firefox and IE.

I have filed this issue at webkit:

https://bugs.webkit.org/show_bug.cgi?id=22382

Issue 5447 has been merged into this issue.

Issue 1687 has been merged into this issue.

Area-UI-Features label replaces Area-BrowserUI label

experiencing this problem on http://www.metal-archives.com/board/index.php as well as a 
few other sites

"Area-UI-Features" sounds like a weird choice to me, WebKit?

I have the same problem on www.isohunt.com

I use one of those pages as well and wrote a small content script to work around the 
problem. Basicly what I do is this:

var links = document.getElementsByTagName("a");
for (i=0; i<links.length; i++) { links[i].onclick = function() { } }

I'm not certain, but I think the triggering mistake for the problem is sites binding 
to all clicks or binding to "anything but right-click" rather than "only left-click".

I remember specifically binding to left-click on one of my sites because a "collapse 
expander" behaviour was running on right-click and finding that it also prevented 
Chrome from screwing up on middle-click.

The problem AFAICT is that the onclick event is interpreted by most browsers only to 
apply to left-click, but WebKit takes it to include middle-click too.  The first 
interpretation seems like the right one.  (Maybe it wasn't an issue when WebKit was 
mostly used on Macs, which conventionally have fewer than three mouse buttons?)

Is this related to the issue I'm having on http://bit.ly/7gtRWh (Apple store 
accessories) where I cannot open any of the hardware links in a new tab, either by 
middle click OR right-click open in new tab?  This same approach works perfectly fine 
in Firefox on those same links.

Issue 18814 has been merged into this issue.

Is there something difficult with this bug? 

Isn't a simple code like this enough to reproduce it? Try it with Firefox, Opera or IE, 
they all work differently than Chrome/Safari.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
 <HEAD>
  <TITLE> </TITLE>
 </HEAD>
 <BODY>
  <a href="http://www.google.com" onclick="alert('hi there!'); return false">Click me 
with the mouse's middle button.</a>
 </BODY>
</HTML>

test11.html 262 bytes View Download

I am experiencing the same issue. Youtube links open in the same tab when middle-
clicking. Very annoying.

This bug also occurs when middle-clicking on links on www.allmusic.com... for instance 
go to this page http://www.allmusic.com/cg/amg.dll?p=amg&sql=11:jjfpxqtgldae~T2 and try 
middle clicking on any of the album names in the list. In IE and Firefox they open in a 
new tab; in Chrome they open in a new tab AND in the current tab. Very annoying!

How I can fix it?? I like Chrome very much but this bug drives me insane...I have to
use a different browser just because of that..I kinda used to klick the mouse wheel
for the new tab...it happens in facebook also.

Having this exact same issue on Facebook.  Middle clicking links is opening it in the 
current tab and a new tab.  Highly annoying.

The upstream bug this depends on looks like a duplicate of 
https://bugs.webkit.org/show_bug.cgi?id=15173 , which was closed "RESOLVED FIXED" in 
2008 because they decided to make a workaround in Safari rather than fixing it in 
webkit, and they seem content to leave it at that.

So I think this bug is waiting for an upstream change that's never going to happen, and 
until Chrome gets its own fix, it will continue to be the only major browser with 
broken anchor middle click handling.

dtfinch, this bug still exists in Safari (4.0.5 on Windows) too.  I don't think it's 
been fixed in webkit.  I just tried it right now to re-verify this.

Yeah, every time I try to open a Facebook notification in a new tab, this happens. 
Rather annoying.

is this bug being worked on?  It's very annoying and is preventing chrome from being my 
default browser.

Fixed for me...Facebook works normally now! Try updating to the newest version of 
Chrome.

Issue in WebKit still exists - Facebook's mechanism of opening links has just changed 
to be compatible with Chrome.

Until this is fixed, extensions like this will continue to pop...
https://chrome.google.com/extensions/detail/cieomlbfomepkhebmoeddnmkhfbplmgi?hl=en

(at time of writing: "2,219 users - Weekly installs: 257", and 4 and half stars and 
description like "extension also fixes the middle-click"... Nobody can pretend this is 
a small and niche issue.)

Thanks for the extension link.

This is tracked upstream at https://bugs.webkit.org/show_bug.cgi?id=22382 .

Issue 21402 has been merged into this issue.

+1 This is getting extremely annoying to have to right click and open in new tab. Far too many websites contain 
onclick handlers. It's impossible to write extensions to fix all of them. Please get this bug fixed (even if just in 
Chrome until Webkit resolves the issue).

Issue 19066 has been merged into this issue.

Issue 34433 has been merged into this issue.

Issue 46784 has been merged into this issue.

the same is the case on mail.yahoo.com, i made myself a content script that listens to click events on the document in the capture phase and stop propagation if it was fired by the middle button and on a link.

my thought was that maybe these pages use the convention that middle button means event.button == 4 instead of the less logical chrome version event.button == 1? (cause i recently read this: http://www.quirksmode.org/js/events_properties.html)

as for firing click events: i find it correct to do it for any button, the script can then decide if/how to handle it. i dont know what the w3c standard has to say about this though.

reading all this i spontaneously decided to try my solution on all the links here, and found that it works. i now publish my extension for this very problem:
https://chrome.google.com/extensions/detail/ikbkhpkapkmhaoiabhlkmicpeakhhpip

i looked at a few other extensions before, they usually run through all links or event listeners and do something to them, like remove the listeners. i only register one click handler to the document and have it react only if middle button is clicked and only on links. that's all. every feedback is appreciated. have fun.

Thank you very much, the extension works like a charm for me so far.

Every extension page has its own comments section,
This isn't the place to discuss it and actually there is nothing relevant for anyone to add here anymore - please refrain form doing so.

btw, if you take a look at the upstream issue (linked in comment 41) you will find that the development on this issue is ongoing.

Issue 47834 has been merged into this issue.

Issue 48207 has been merged into this issue.

Issue 48206 has been merged into this issue.

I never had the problem until I tried to use www.cuil.com
every time I middle a ersult search link it opens in the same tab instead of a new tab.

this one works on cuil too:
https://chrome.google.com/extensions/detail/ikbkhpkapkmhaoiabhlkmicpeakhhpip

This has been fixed upstream and will be fixed in Chromium once we merge the appropriate WebKit version (r67261).

Issue 56770 has been merged into this issue.

"will be fixed" - has it been fixed yet?

The fix is in the Dev builds, but won't make it into 7 Stable due to causing Issue 56150.

there seems to be another issue with this fix. since i dont use dev builds i didnt experience it myself but was told about it. apparently sometimes when a page wants to prevent clicks from opening pages but assigns some other behavior to links (like opening a small dialog), this fix causes these pages from working correctly with the middle button (a new tab is opened anyway). an example are the remove buttons on this page: http://www.facebook.com/profile.php (you need a facebook account and must have items on your wall).

in my mind that's not the bug that's the feature of this fix!
why do you click with the middle mousebutton if you should use the left and don't want any special? :)

because there might be different special non-standard behavior assigned to left and middle button.

Issue 59183 has been merged into this issue.

Issue 59521 has been merged into this issue.

Issue 58190 has been merged into this issue.

Ubuntu (11-20-2010 all updates) v 10.10 (gnome)
according to original post, i get these results:

PASS :: Midori 0.2.4 GTK+ 2.21.2, WebKitGTK+ 1.2.1
FAIL :: Firefox 3.6.12
FAIL :: Chrome 7.0.517.44

Issue 67592 has been merged into this issue.

Issue 64872 has been merged into this issue.

Issue 47406 has been merged into this issue.

Issue 68528 has been merged into this issue.

The upstream bug has been reopened as the fix had to be reverted due to regressions.

Issue 71535 has been merged into this issue.

I had reported this issue in October with 7.0.517.41 beta, which ended up merged here. Since then I've installed dev and canary builds in the hope a proper fix would show up there first. Canary at the moment is up to 11.0.658.0 and sadly there has been no fix released.

I am sorry to see this bug has proved so difficult to resolve for those coding Chrome. Is there any estimate as to when this might be addressed?

There is a middle click extension that helps some people with this issue, however it does not work for mine.

In the meantime would it be possible to redirect the middle click option to the "open link in new tab" option one gets by right clicking on a link? When that is used the windows always open properly on a tab in the background. Maybe this could be done via an extension.
I tried to see if there was a shortcut key combo specific to that action so I could tell Logitechs mouse software to override the normal function, but there is none that I could see. 

skulkund, are you referring to this extension: https://chrome.google.com/extensions/detail/ikbkhpkapkmhaoiabhlkmicpeakhhpip

if so, where does it not work? 

Yes, that is the extension. I had written comments for the minimal version a few months ago I believe.
One example would be at cnn.com - Often on the main page, on the left under "latest news" there will be a link that goes to People magazine online. Middle click that and it will always steal focus. There was a link there an hour ago, but at this moment there isn't one.
If you go to their entertainment page there is currently a link to an article on In Style website. Middle click that, new tab opens and steals focus.
If you need another let me know.

happens too on .. http://www.opensubtitles.org/

Issue 76099 has been merged into this issue.

Issue 76862 has been merged into this issue.

#75 great THANKS for that extension, but it's a shame this bug can't be fixed for soo many versions from 6- (i don't remember) to 12+ version of Chrome and browser needs an extension just to work how it should =\

i think the issue is not with chrome but with these sites. some of them were fixed already, but the others just dont, maybe they think chrome doesnt have a large enough market share or whatever.
it seems like every other chrome version "fixes" this bug by adopting the wrong behavior of these pages, thereby breaking others that are programmed correctly. i am against that "fix" in chrome. its logically better to use an extension until those broken websites get fixed.

My $0.02:

What's annoying here is that we have three mouse buttons, and there's a stunning lack consistency between them.

One of the following should be the case:

* all three mouse buttons fire "click" and it's up to the site to determine whether it's left, right, or middle, or
* all three mouse buttons fire different events (left = click, right = contextmenu, middle = <newevent>)

Having left and middle fire "click", but right fire something else is a deer in the middle of the road getting hit by a truck.

This article sums up some of the madness, even though it's in need of an update for the latest browser versions: http://unixpapa.com/js/mouse.html

According to comment #60, "The fix is in the Dev builds, but won't make it into 7 Stable due to causing  Issue 56150".
Issue 56150 is fixed now. Does this mean the fix to this issue can be applied?

@82: i am clearly for number 1, only 1 click event. its the most elegant and most customizable, the most logical version.

@84 / @82 may be an elegant solution, but won't fit every user's need... unless the website *explicitly* has an use to the mmb, it should just open the damn link/action into another tab/windows like everyone else does... it has been more two years and it is not fixed yet, all we want is to middle click (or ctrl+click) something and NOT activate an link in the current window/tab...
to sum up, it theres a link showing in my status "bar", and I middle click (again, or ctrl+click), I want THAT link into another tab... not some hidden script that should be activated only when clicking with the default/left mouse button.

@83 I just hope this fix can land into builds again soon... (Just look at it... 22 merged issues, 2 years and 7 months... 111 stars to notify about this bug... it already took to much... don't want to let people down about it, but those are just facts...)

i dont understand, what needs would nr 1 from 82 not fit? both fit every regular situation, but 1 is more elegant and more flexible. what solution would you suggest? sounds a bit like forbidding to attach scripts to mouse events ...

For the record, I'd prefer option #2 from my previous comment (@84), for the following reasons:

1. Most sites don't expect the middle mouse button to fire "click", and browsers that do make such sites look broken.

2. Browser manufacturers disagree on how to number mouse buttons[1].  Which makes it extra-hard on developers.

3. The right mouse button already has its own event (contextmenu).  Giving middle-click its own event isn't a big stretch.

4. Having the right mouse button fire "click" would cause as much havoc (or more) as having the middle mouse button do so, which is the subject of the current debate.

[1] http://www.quirksmode.org/js/events_properties.html#button

#87, what debate? rest of browsers works fine while this doesn't, it's bug which needs fixing.

typically stuff works fine in browsers because it does different stuff depending on the current browser. if someone failed to include the case chrome and chrome is not identified as ff or ie, its likely that stuff doesnt work.

in a nutshell:

past browsers had bugs. instead of pressing them to fix these bugs, the webpages adapted to them. now these pages dont run on a standard compliant browser. i just cannot promote adapting the browser to these pages as a reasonable solution. the obvious (to me) best way is to make the browser as standard compliant (w3c) as possible and wait for the web pages to adapt to that. if they are slow with this, have plugins fix it for the time being. 

Peter, the standard does not require a user agent to assign any particular function to any particular mouse button. The standard, quite reasonably, does not even require a mouse, though it may use a mouse as a useful example of what a user agent might do.

As such, there is necessarily nothing in the standard requiring Chromium to fire an onClick event when the middle mouse button is pressed. This behavior is the result of a voluntary choice by the Chromium developers -- a choice a lot of us strongly disagree with, and one that goes against the historical expectations created by other browsers' choices.

Changing the Chromium behavior would have no effect on its standards compliance whatsoever, but it would make many users happier.

i thought this was kind of recognized as standard concerning such matters:

http://dev.w3.org//2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-click

You mean the thing that says "Draft" in a big red banner, says it's not stable, is a product of four different editors over 10 years, fails to adequately take account of the changing nature of web-accessing devices (e.g. touchscreens) and, in any case, says that the Chromium behavior is wrong?

If you want to find a document to support the very poor choice made by the Chromium devs in this case, I think you need to keep looking.

----

Middle click (MouseEvent.button value is 2, MouseEvent.buttons value is 4):
If the proximal event target has associated activation behavior, the default action must be to execute that activation behavior *********in an alternate fashion (such as opening a link in a new tab or window*********).

I believe we understand exactly what needs to be changed and that people are working on the fix.  In the interest of reducing mail to people who subscribed to this bug to learn when it's fixed, I'm restricting further comments to committers.  Please email me directly if you have any information relevant to fixing this bug.

Issue 81630 has been merged into this issue.

Issue 87239 has been merged into this issue.

Issue 89275 has been merged into this issue.

Issue 11967 has been merged into this issue.

Issue 93327 has been merged into this issue.

Issue 98076 has been merged into this issue.

Issue 130948 has been merged into this issue.

Issue 101305 has been merged into this issue.

I came across this bug based on a message board thread: http://boards.straightdope.com/sdmb/showthread.php?t=697085

I've only skimmed the relevant bug histories (they are long and complicated!) but it seems like this MIGHT be the kind of thing that we can fix more easily now that we have Blink.

CC'ing Adam explicitly given that he was the author of a few proposed patches on the WebKit side.

Assigned for investigation.

Simon Pieters forwarded this message:

http://lists.w3.org/Archives/Public/www-dom/2013JulSep/0203.html

------- Forwarded message -------
From: "Simon Pieters" <simonp@opera.com>
To: www-dom <www-dom@w3.org>
Cc:
Subject: [uievents] Middle click
Date: Tue, 27 Aug 2013 13:38:30 +0200

What should happen when the user clicks the middle mouse button?

The current situation is as follows:

Gecko always fires a click event on the document that bubbles and has as
target the element being clicked.

IE doesn't fire a click event if the target is a link, but does fire it if
another element is clicked even if it's a descendant of a link.

Blink/WebKit always fire a click event on the element being clicked.

Presto never fires a click event for middle mouse.

There even might not be fired in some browsers if the click starts panning
mode or some such.

The problem with Blink/WebKit's approach is that sites do something on
click which doesn't make sense to do if the user clicks the link with the
middle mouse button which should open the link in a new tab. Both actions
happen which is not what the user expects.

IE's approach maybe works most of the time but fails when a link contains
elements, so seems suboptimal.

Gecko's approach probably works pretty well but is a bit magic and would
still fail on sites that put the listener on document or window but still
assume the left button is being clicked.

Presto's approach works always AFAICT.

All browsers fire mousedown and mouseup as normal for middle mouse button,
so e.g. games or mapping apps that really want to use the middle mouse
button separately can still listen for it with these events.

Since click event for middle mouse button is already unreliable, it seems
that sites can't depend on it being fired if they want to use the middle
mouse button. As such it seems to me that the best approach is what Presto
does, to never fire click for the middle mouse button.

Blink bug for this issue is
https://code.google.com/p/chromium/issues/detail?id=255

Back to Available, since it is not really an external dependency anymore.

Issue 111927 has been merged into this issue.

Conclusion from the spec discussion (https://www.w3.org/Bugs/Public/show_bug.cgi?id=23240) was to update the spec to say click is only fired for the "primary" button.  https://w3c.github.io/uievents/#event-type-click
But it looks like we never changed blink (or presumably WebKit).

This seems easy to do and would potentially unblock other issues like issue 163604.  This is our 2nd most top-starred open input-dev issue. dtapuska@ WDYT?  

nzolghadr@ Are you able to put together a patch for this?

I'll take a look this week.

I did this in https://codereview.chromium.org/23060022/ but ran into regressions because internal actions in the UI (open in new window?) were hooked into the midclick events. Those internal actions needed to be rewired but I never completed the patch. 

Feel free to use the patch as inspiration or just as it is, if it still applies. It's a bit old.

Sure. Thanks bratell@ for sharing the patch.

FWIW: That patch seems to only deal with middle click. The spec has been adapted to say only the primary pointer.

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

commit 76fea00a18f75886ea649414393228180306e13d
Author: nzolghadr <nzolghadr@chromium.org>
Date: Wed Apr 27 21:33:45 2016

Prevent sending click event for non primary button

Prevent sending click and dblclick events when the
button in charge is a non-primary mouse button.

As the result of this change there is no way to
prevent the behavior of opening a new tap when
middle clicking on a link. Previously, js could
listen to click event of the middle button and
call preventDefault on it.

BUG= 255 

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

[modify] https://crrev.com/76fea00a18f75886ea649414393228180306e13d/chrome/browser/ui/browser_browsertest.cc
[modify] https://crrev.com/76fea00a18f75886ea649414393228180306e13d/testing/buildbot/filters/browser-side-navigation.linux.browser_tests.filter
[modify] https://crrev.com/76fea00a18f75886ea649414393228180306e13d/third_party/WebKit/LayoutTests/fast/events/mouse-click-events-expected.txt
[modify] https://crrev.com/76fea00a18f75886ea649414393228180306e13d/third_party/WebKit/LayoutTests/fast/events/script-tests/mouse-click-events.js
[modify] https://crrev.com/76fea00a18f75886ea649414393228180306e13d/third_party/WebKit/Source/core/events/MouseEvent.cpp
[modify] https://crrev.com/76fea00a18f75886ea649414393228180306e13d/third_party/WebKit/Source/core/input/EventHandler.cpp

I foresee copy pasta for those that need to detect middle click:

// Does this even work in shadow DOM?
document.addEventListener('mousedown', function(e) {
  if (e.button != 1) return;

  var mousedownElement = e.target;

  // Hope we get a matching up event...
  document.addEventListener('mouseup', function f(e) {
    if (e.target == mousedownElement) {
      // Dispatch a 'click' event on |mousedownElement|.
    }
    document.removeEventListener('mouseup', f);
  });
});

The old way was much less dubious, IMO:

  onclick = function(e) {
    if (e.button) return;
    // primary clicks only.
  };

i also agree with rbyers@ that a 'middleclick' event could be a useful compromise

rbyers@ were you trying to mark all those issued caused by this issue as blocking for this issue? If so there were 2 more so far which I can do the same for those.

Since Rick's comment was not here let me paste it here:

"Yeah, the key goal here is interoperability. But the reason this behavior is
considered better is that sites often cancel 'click' events without considering
the button state, which then breaks the browser "open in new tab" feature. This
is a long-standing user complaint of Chrome - see http://crbug.com/255 - #5 most
starred input bug ever.

A less hacky solution would be to fire an event named "middleclick" and update
the listeners to listen for that instead of "click". It's a reasonable argument
to say that such an event should just be added to the web platform (and it's
still possible we'll land there I think)."

dbeam@ even "middleclick" is not a perfect solution though. Note that a mouse may have more that three buttons. So one could argue they want the click for any of the buttons and middleclick is one single instance of that. Then we can talk about a "generalizedclick" event which is fired for all the buttons (maybe including or excluding the primary button). So that solution needs a bit more discussion and debates but as you said that seems to be a useful compromise.

Marking regression issues as the result of this change blocking for this issue for tracking.

I'm [maybe temporarily] unrestricting bug comments because I'd like to hear who this is breaking.  Additionally, I theorize it will reduce the amount of duplicate bugs filed.

Issue 407564 has been merged into this issue.

Issue 260659 has been merged into this issue.

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 change is reverted due to preventDefault functionality of middle click. We will pursue first adding the "auxclick" event as per this proposal:
https://discourse.wicg.io/t/new-event-for-non-primary-button-click/1527

to be able to then remove click for non-primary buttons.

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

Imo "the ability to prevent opening a new tab" is not a valid use case.

timbojones@ can you elaborate more why that is the case? Can you also post your comments here in this proposal as one of the reasons that we are creating that new event is particularly that use case which seems to be used quite often?
https://discourse.wicg.io/t/new-event-for-non-primary-button-click/1527

So you are suggesting we should ignore that use case altogether and remove the click event anyway?

The convention for browsers and in general computing is "left click activates, right click displays a context menu, middle click creates a new instance". The user should have control. There currently exist sites that disable the right click context menu. Those sites are broken and this user phobic behavior should be discouraged. Otoh I recognize e.g. that Gmail disables the default context menu to replace it with a more specific one and that is a great feature. Overriding mmb e.g. in order to control the camera in a 3d viewer control is a fine use case. But particularly in the case of hyperlinks, I can see no reason to cede control over number and size of tabs and windows from the user to the designer. It seems to me that the only door this opens is for rogue developers to break the web and user expectations.

#143 - developers can use href="#" which makes opening a new tab useless anyway. Or href="javascript: void 0;" for which Chrome does not open a new tab.
This does not add a functionality (blocking a new tab), it just makes it more convenient to react to middle clicks.
(With that said, I am not sure a new event type is the right way)

Tested the issue on windows 7, Linux Ubuntu 14.04 and Mac 10.11.5 using chrome version 53.0.2785.8 with the html attached in comment #24.Able to click on link using mouse middle click.Please find the attached screen cast for the same.

Thanks,

	255.mp4 333 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# 145. The same behavior is displayed on the Chrome Beta mentioned.
Thank You.

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

commit 6efe6e4b42ab875fee4ed7029f693fefc04c2658
Author: nzolghadr <nzolghadr@chromium.org>
Date: Mon Aug 15 18:56:40 2016

Start sending auxclick instead of click for non-primary buttons

Stop sending dblclick and click evnt for non-primary buttons
and send auxclick event for the click action of non-primary
buttons.

BUG= 625847 ,  255 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

TBR=dglazkov@chromium.org, holte@chromium.org

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

[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/chrome/browser/resources/history/other_devices.js
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/chrome/browser/resources/md_downloads/crisper.js
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/chrome/browser/resources/ntp4/apps_page.js
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/chrome/browser/resources/ntp4/new_tab.js
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/chrome/browser/ui/browser_browsertest.cc
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/testing/buildbot/filters/browser-side-navigation.linux.browser_tests.filter
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/third_party/WebKit/LayoutTests/fast/dom/Window/property-access-on-cached-window-after-frame-navigated-expected.txt
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/third_party/WebKit/LayoutTests/fast/dom/Window/property-access-on-cached-window-after-frame-removed-and-gced-expected.txt
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/third_party/WebKit/LayoutTests/fast/dom/Window/property-access-on-cached-window-after-frame-removed-expected.txt
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/third_party/WebKit/LayoutTests/fast/events/mouse-click-events-expected.txt
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/third_party/WebKit/LayoutTests/fast/events/script-tests/mouse-click-events.js
[add] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/third_party/WebKit/LayoutTests/virtual/stable/fast/events/mouse-click-events-expected.txt
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/third_party/WebKit/LayoutTests/webexposed/element-instance-property-listing-expected.txt
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/third_party/WebKit/LayoutTests/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/third_party/WebKit/Source/core/dom/GlobalEventHandlers.h
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/third_party/WebKit/Source/core/dom/GlobalEventHandlers.idl
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/third_party/WebKit/Source/core/events/EventTarget.cpp
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/third_party/WebKit/Source/core/events/EventTypeNames.in
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/third_party/WebKit/Source/core/frame/UseCounter.h
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/third_party/WebKit/Source/core/html/HTMLAnchorElement.cpp
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/third_party/WebKit/Source/core/input/EventHandler.cpp
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/third_party/WebKit/Source/devtools/front_end/ui/TabbedPane.js
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/tools/metrics/histograms/histograms.xml
[modify] https://crrev.com/6efe6e4b42ab875fee4ed7029f693fefc04c2658/ui/webui/resources/js/util.js

The fix for this is landed again behind the web experimental flag. Note that we now send "auxclick" event for the non-primary buttons and if someone for example wants to prevent opening a new tab when middle clicking on a link they should listen to the auxclick event and check button===1.

I'm not sure this is fixed until it is shipped since this is a OWP bug.

Issue 622266 has been merged into 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/