I've noticed that Safari is the only browser I've tested which fire onclick event after using middle click (wheel button) to load a link on a new tab. This is very frustrating behaviour, not visible in other popular browsers on Windows (Internet Explorer 7, Firefox 2 and Opera 9). Steps to reproduce: 1. Go to a page: http://bugs.blaut.biz/webkit/onclick-issue.htm 2. Middle click on the only link on the page. Expected result: Safari should open a new tab and load a page http://webkit.org. The tab with the clicked link should not load webkit.org site. Current result: Safari loads on a new tab a page http://webkit.org and also load a page webkit.org on the tab with the clicked link.
Created attachment 16247 [details] A minimal test case
<rdar://problem/5473092>
(In reply to comment #2) > <rdar://problem/5473092> > I assume the bug is confirmed.
It looks like in Firefox, click event handlers only fire for left click. In IE7, click events fire for left click or middle click. However, anchor tags seem to be a special case where if there's a href, the href is opened in a new tab. Otherwise, the click event handler runs. As far as I can tell, it seems like the click event should fire for middle clicks, but the spec seems ambiguous: http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-click Here's a good test case: http://www.w3.org/WAI/UA/TS/html401/cp0102/0102-ONCLICK-MULTIPLE-EVENTS.html Also, this is what causes middle clicking a link in Gmail to open in a new window rather than as a background tab in Safari.
The "fix" to this would be a one line change in: EventHandler.cpp: bool EventHandler::handleMouseReleaseEvent(const PlatformMouseEvent& mouseEvent) There is already code in that function to avoid ever dispatching click events for right-clicks, we'd just have to change it to not dispatch clicks for middle clicks as well (possibly only to dispatch click events for left-clicks in general).
"A pointing device button" on the spec seems unambiguous that any button should fire clicks. It's not clear to me whether to claim the other browsers are wrong (certainly not firing clicks on middle/right clicks _seems_ bizarre, and makes life harder on JS authors who want to use those buttons to trigger actions), or to claim that the spec should change.
It seems like the better behaviour would be to fire the click event normally, but then catch any attempt at navigating the page, and instead make another browsing context navigate, or something like that. Then it would work with all kinds of weird scripts, too. That's more work, though.
Created attachment 21957 [details] Only dispatch clicks for left-button clicks WebCore/ChangeLog | 13 +++++++++++++ WebCore/page/EventHandler.cpp | 7 ++++--- 2 files changed, 17 insertions(+), 3 deletions(-)
I see there are differing opinions above as to how this should be solved. Regardless, I wrote a patch which solves this by making us not send these click events like other browsers. I also noticed in my testing that we do not send a mouse-release event on right-clicks. FF does (right as it's displaying the context menu).
Comment on attachment 21957 [details] Only dispatch clicks for left-button clicks Lets add something to eventSender so we can do an automated tests. Should be simple.
I think Eric's patch is fine for now, my earlier suggestion is what I think we should do on the long term though. It would work for far more cases, and would be really cool.
Created attachment 21976 [details] First attempt at adding eventSender.mouseDown(1) support .../DumpRenderTree.xcodeproj/project.pbxproj | 2 +- .../DumpRenderTree/mac/EventSendingController.h | 2 +- .../DumpRenderTree/mac/EventSendingController.mm | 95 ++++++++++++++++---- 3 files changed, 79 insertions(+), 20 deletions(-)
Created attachment 21977 [details] Add multi-button mouseevent support to DRT and test case .../fast/events/mouse-click-events-expected.txt | 32 +++++++ LayoutTests/fast/events/mouse-click-events.html | 13 +++ .../fast/events/resources/mouse-click-events.js | 45 ++++++++++ .../DumpRenderTree.xcodeproj/project.pbxproj | 2 +- .../DumpRenderTree/mac/EventSendingController.h | 2 +- .../DumpRenderTree/mac/EventSendingController.mm | 88 ++++++++++++++++---- 6 files changed, 165 insertions(+), 17 deletions(-)
Created attachment 21980 [details] Add multi-button mouseevent support to DRT and test case LayoutTests/ChangeLog | 12 ++ .../fast/events/mouse-click-events-expected.txt | 32 ++++++ LayoutTests/fast/events/mouse-click-events.html | 13 +++ .../fast/events/resources/mouse-click-events.js | 45 ++++++++ WebKitTools/ChangeLog | 22 ++++ .../DumpRenderTree.xcodeproj/project.pbxproj | 2 +- .../DumpRenderTree/mac/EventSendingController.h | 2 +- .../DumpRenderTree/mac/EventSendingController.mm | 111 ++++++++++++++++---- 8 files changed, 214 insertions(+), 25 deletions(-)
Comment on attachment 21957 [details] Only dispatch clicks for left-button clicks r=me, assuming you land the test too
Comment on attachment 21980 [details] Add multi-button mouseevent support to DRT and test case Looks good, but we need to add this test to the skipped list for the other platforms, since the new support in DumpRenderTree is Mac-only. r=me
Actually. My patch just breaks middle-click-to-open-links entirely. I guess the "middle click to open links" behavior depends on there being a click event. Sigh.
(In reply to comment #17) > Actually. My patch just breaks middle-click-to-open-links entirely. I guess > the "middle click to open links" behavior depends on there being a click event. > Sigh. Yeah, of course it does. We do navigation based on HTMLAnchorElement::defaultEventHandler. I'm not sure why I ever thought this would work. I guess the test case is still useful, but there is no easy way for us to replicate FF/IE behavior here. I think we should scratch this patch and implement a better "window.open opens in new tab if called from a middle-click" behavior. However I bet that's a Safari change more than a WebKit change.
Comment on attachment 21957 [details] Only dispatch clicks for left-button clicks Removing Review flag. This patch breaks more than it helps. I'll still land the test case patch though.
Ok. I landed the test case and DRT enhancements as part of: http://trac.webkit.org/changeset/34871 We've decided to continue to send these events but instead fix window.open to open in a new tab when the result of a command-click or middle-click. The rest needs to be done in Safari (And is thus tracked internally by Apple). Closing.
So unfortunately Gmail still isn't fixed (middle clicking on links, still opens in a new window). Part of that is going to be a Safari fix, but part of it is going to need to be a WebKit fix. I don't believe this could be fixed in Safari TOT, since WebKit TOT isn't passing any event context information to the WebViewLoadDelegate as part of the open new url callback. the NavigationAction does not have an event() set on it when you middle-click a gmail link, so there is no way this information could be being passed up to Safari. I don't think this is the right bug to track the brokeness of gmail-middle-clicking. But I was asked by some avid Safari users internally to finally see if I couldn't get to the bottom of this Safari + Gmail bug. As far as I can tell, there are still fixes which need to happen in WebKit (and possibly Safari as well). Perhaps someone on the Apple side of things can give me some guidance as to any work you all have done to fix the "Safari + middle-click in Gmail opens a new window instead of a new-tab behind the current" bug.
*** This bug has been marked as a duplicate of bug 22382 ***