Current spec states:

"The click event type must be dispatched on the topmost event target indicated by the pointer, when the user presses down and releases the pointer button, or otherwise activates the pointer in a manner that simulates such an action."

Proposed change to:

"The click event type must be dispatched on the topmost event target indicated by the pointer, when the user presses down and releases the *primary* pointer button (i.e., when MouseEvent.button = 0), or otherwise activates the pointer in a manner that simulates such an action."

> 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.

The developer needs to check if e.button == 0.  Developers already need to do this, or they'll misbehave when the user right clicks.

Click events should only have fired for left clicks in the first place (failing to check .button is one of the most common scripting bugs I've seen--even YouTube screws this up, right in the search results), but it doesn't make much sense for right click to fire clicks but not middle click.


(In reply to Gary Kacmarcik from comment #1)
> Proposed change to:
> 
> "The click event type must be dispatched on the topmost event target
> indicated by the pointer, when the user presses down and releases the
> *primary* pointer button (i.e., when MouseEvent.button = 0), or otherwise
> activates the pointer in a manner that simulates such an action."

Browsers have fired click for right-click for a long time.  If it was web-compatible to simply stop doing that, I think browsers would have made that change years ago.

Given the weird behaviors of browsers here, there are probably a bunch of strange web-compat things going on.  I don't think it makes sense to try to spec this until it's known what those are.

Chrome Linux/Mac do not fire click for right-clicks. I don't have Windows on hand to tell you for sure that Chrome Windows also does not.

Firefox definitely does.

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

(Wow, that's painfully broken.  The .target of an event *is* the element that the event is dispatched to.)

(In reply to Glenn Maynard from comment #2)
> The developer needs to check if e.button == 0.  Developers already need to
> do this, or they'll misbehave when the user right clicks.
> 
> Click events should only have fired for left clicks in the first place
> (failing to check .button is one of the most common scripting bugs I've
> seen--even YouTube screws this up, right in the search results), but it
> doesn't make much sense for right click to fire clicks but not middle click.

Yeah, so then we shouldn't fire click for right click either.

> Browsers have fired click for right-click for a long time.  If it was
> web-compatible to simply stop doing that, I think browsers would have made
> that change years ago.

Presto doesn't fire click for right click.

Fixed in latest ED to specify that only the primary button fires click and dblclick events.

Looking at the text in the spec some more, it contains the following passage (which implies that click and dblclick should fire for all buttons):

The default action of the click event type varies based on the event target of the event and the value of the MouseEvent.button or MouseEvent.buttons attributes. Typical default actions of the click event type are as follows:

* Left click (MouseEvent.button value is 0, MouseEvent.buttons value is 1):
   * If the event target has associated activation behavior, the default action must be to execute that activation behavior (see Activation triggers and behavior).
   * If the event target is focusable, the default action must be to give that element document focus.

* Right click (MouseEvent.button value is 1, MouseEvent.buttons value is 2):
   * The default action must be to provide a context menu of options related to that event target.

* Middle click (MouseEvent.button value is 2, MouseEvent.buttons value is 4):
   * If the 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).
   * If the event target has no associated activation behavior, a user agent may assign a custom default action such as an alternate scrolling or panning mode.

Since the original intent of this was to have these events fire for all buttons, I've updated the ED to be more explicit about this.

Also note that since the dblclick time is a OS user preference, there is no easy way for apps to properly synthesize their own dblclick events if we don't provide them.

Ojan wrote (on www-dom@):
>FWIW, Blink is planning on moving to not firing click events for middle mouse
>clicks and already doesn't fire them for right clicks. As best I can tell, this
>matches Gecko and IE as well.

I just tested this using:
https://dvcs.w3.org/hg/d4e/raw-file/tip/mouse-event-test.html

Q&D browser test:

                  Chrome    Firefox   IE   Saf
                 Win  Mac  Win   Mac  Win  Mac
left click        y    y    y     y    y    y
left dblclick     y    y    y     y    y    y
mid click         -    y    -     -    y    y
mid dblclick      -    y    -     -    -    y
right click       -    -    -     -    -    -
right dblclick    -    -    -     -    -    -

Middle click often led to scrolling-mode for browsers that didn't produce a click.
Right click always pulled up a context menu.

(In reply to Gary Kacmarcik from comment #9)
> Middle click often led to scrolling-mode for browsers that didn't produce a
> click.

More specifically:
CrWin FFMac FFWin and IEWin entered scroll-mode on a middle click. IEWin would also generate a middle click the second time the middle button was clicked. IEWin did not generate a dblclick

CrMac and SafMac generated middle click and dblclick.

bzbarsky wrote (on www-dom@):
> Note that Gecko will fire non-left clicks directly on the document, so
> depending on how you wrote your testcase you may have not seen the events.

Why does it send them to the document instead of the element (as it does for left clicks)?

Because of some ancient reason to not break Camino.
Also, firing right or middle click on elements breaks pages easily.

Some history:
https://bugzilla.mozilla.org/show_bug.cgi?id=71705

(the less interesting Camino bug was https://bugzilla.mozilla.org/show_bug.cgi?id=329810)

(In reply to Gary Kacmarcik from comment #11)
> bzbarsky wrote (on www-dom@):
> > Note that Gecko will fire non-left clicks directly on the document, so
> > depending on how you wrote your testcase you may have not seen the events.
> 
> Why does it send them to the document instead of the element (as it does for
> left clicks)?

(In reply to Olli Pettay from comment #12)
> Because of some ancient reason to not break Camino.
> Also, firing right or middle click on elements breaks pages easily.

Oh, I misunderstood Gecko's behavior...

As I said in telecon, it's hard to emulate click event and dblclick event. Especially for dblclick event, web apps cannot retrieve the proper time between 2 clicks.

However, for not breaking current web apps, not dispatching click event and dblclidk event for non-left buttons is the best approach.

For solving these issues, how about to define new events, mouseclick and mousedblclick? They should be dispatched before click event and dblclick event and if their default are prevented, legacy click event and dblclick event should not be fired.

Exposing clicks for other buttons in some way seems reasonable.  It's nontrivial to emulate click using mousedown and mouseup, since the particular behavior (whether to fire a click or not) is up to the platform.  It probably makes more sense to have "rightclick" and "middleclick" events rather than reincarnating the .button property on a new event.

But, what are the use cases for doing this for dblclick?  I don't think I've ever seen a UI with "double-right-click".  (It's not even possible to double-right-click on Macbooks.)  A new event shouldn't be added just because it's hard to do manually, if nobody actually wants to do it.

right-click is already covered by the contextmenu event. I can't think of a reason a site would want to capture right click, but not the contextmenu keypress.

I don't really see the point of defining a click event for middle. It's extremely rare that a page wants to do something on click of middle buttons. It is getting even more rare as pages are designing for touch-based devices.

I can certainly see reasons for middle/right capturing, at least in games.

Wouldn't games use mousedown/mouseup?

Fixed (again!) in latest WD to specify that only the primary button fires click and dblclick events.

This behavior is required because sending click and dblclick for other buttons breaks too much of the web.

The text in the spec that implies that click and dblclick can be sent for non-primary mouse buttons has been updated as well.