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?

(No comment was entered for this change.)

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

(No comment was entered for this change.)

 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!

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

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.

(No comment was entered for this change.)

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

(No comment was entered for this change.)

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.

(No comment was entered for this change.)

(No comment was entered for this change.)

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

(No comment was entered for this change.)

(No comment was entered for this change.)