Bug 70070

Created attachment 111160 [details] BBC News Article For historical preservation, a web archive of <http://www.bbc.co.uk/news/magazine-15288975> as seen on 10/15/2011.

From observation and briefly looking at the source code for the page in Web Inspector, this BBC News page captures mouse click events and selectively overrides the default browser behavior using document.location.href. I don't have a mouse with a middle mouse button. So, I programmatically generated a DOM Click event for the middle mouse button and dispatched it at the example hyperlink using Web Inspector and the following script (*): var link = document.querySelector("a[href='http://www.nti.org/e_research/e3_88.html']"); var mouseEvent = document.createEvent("MouseEvents"); mouseEvent.initMouseEvent("click", true, true, window, 0, 0, 0, 0, 0, false, false, false, false, 1, null); link.dispatchEvent(mouseEvent); Using Xcode's debugger (**) and middle clicking on the example hyperlink mentioned in the bug description (comment 0) we see that Location::setHref(), <http://trac.webkit.org/browser/trunk/Source/WebCore/page/Location.cpp?rev=96779#L155>, is ultimately called; => BBC News captures the DOM Click event and ultimately overrides the value of document.location.href with <http://www.nti.org/e_research/e3_88.html> (the URL associated with this hyperlink). Hence, we navigate the current page to this new URL instead of opening a new tab (the default browser behavior). Consistent with the bug description, middle clicking on a non-external hyperlink, say for the article "Do we understand 'risk' of mobile phone use?", doesn't override the value of document.location.href and the article opens in a new tab. (*) See <https://developer.mozilla.org/en/DOM/event.initMouseEvent>/<http://www.w3.org/TR/DOM-Level-3-Events/#events-event-type-initMouseEvent> for a composite breakdown of the arguments to initMouseEvent(). (**) The page at <http://www.bbc.co.uk/news/magazine-15288975> loads many obfuscated JavaScript scripts. These obfuscated script make it difficult to identify the script or snippet that is responsible for this behavior. If I have additional time, I'll try to identify the script or snippet that is responsible for the observed behavior.

I suspect that this is a Safari bug, not a WebKit one.

If it is, then there's an identical one in Chrome - reproduces in Chrome 16.0.904.0 dev-m but not in IE or Firefox.

*** This bug has been marked as a duplicate of bug 22382 ***

This may be related to bug 22382, but calling this a duplicate is inaccurate unless a patch for that bug lands and fixes both.

The web script behaves exactly as it should for a click event fired on middle click. The only difference with behaviour in other engines is that the event is not fired. The script even performs some validation on the event (istats-1.js, line 897) to detect clicks aimed at new tabs and windows with modifier keys and refrain from changing the window href on these clicks - it just doesn't check e.button. In other words, this is a specific example of behaviour that bug 22382 seeks to define. You can classify it as you please but I assumed a bug that is nothing more than a reproduction case for another bug would be considered unnecessary clutter.