W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2013

[uievents] Middle click

From: Simon Pieters <simonp@opera.com>
Date: Tue, 27 Aug 2013 13:38:30 +0200
To: www-dom <www-dom@w3.org>
Message-ID: <op.w2g3yg1lidj3kv@simons-macbook-pro.local>
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  

Simon Pieters
Opera Software
Received on Tuesday, 27 August 2013 11:33:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:03 UTC