184051 - Fire middle/right-click events at content and remove click hack

Status: RESOLVED INVALID

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[John Keiser (jkeiser)]

We are not supposed to fire the onclick event at content for middle click or
right click, but we still need the document to receive the event so that our
normal handlers can deal with it.  So we hack the event by setting the flag
NS_EVENT_FLAG_NO_CONTENT_DISPATCH, and not dispatching the event to content.

Input, however, still needs the middle click event for pasting, so it reverses
this flag temporarily.  It is very much a hack and makes things work badly. 
People who want to make a GUI based on our system (people like, for example,
*us*) need to be able to receive these events.

I propose instead that we fire a new kind of event normally, call it
moz_alt_click or something, when middle / right click is fired.  That way people
doing onclick won't get surprised, and our system can handle these events in a
normal manner instead of hacking around them.

Comment 1

[John Keiser (jkeiser)]

This may or may not block the event flow rewrite, but it probably affects it.

Comment 5

[Johnny Stenback (:jst)]

Not blocking 1.9.3 on this. Olli, is this even a valid bug any more?

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

It seems that IE9 doesn't support onclick attribute.

Google Chrome supports for left click and middle click.

Opera supports left click only, middle click always causes auto scroll, cannot prevent it.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I commented about "onclick" attribute.

Comment 9

[simeng]

This bug is really annoying as Chrome and Opera don't trigger the click events for other buttons than left mouse button on both document or dom elements.
Firefox doesn't do that either on dom elements, but for some reason it does on document.

So in my case I have an element in my document and run stopPropagation on click, a right click on this element will not hit the stop propagation and propagate all the way to the document handler where it will trigger an click event on that, which is a strange behavior IMO.

Comment 10

[Navid Zolghadr]

I believe since Firefox already shipped auxclick this document level click can be removed as other browsers don't fire click event anymore:

https://bugzilla.mozilla.org/show_bug.cgi?id=1374096

Comment 11

[Thomas Wisniewski [:twisniewski]]

This is now causing subtle (albeit minor) compat issues even on YouTube's UI, as reported at https://webcompat.com/issues/25270

Comment 12

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 13

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 14

[Mike Taylor [:miketaylr]]

(In reply to Navid Zolghadr from comment #10)

I believe since Firefox already shipped auxclick this document level click
can be removed as other browsers don't fire click event anymore:

https://bugzilla.mozilla.org/show_bug.cgi?id=1374096

What do you think Kwan?

Comment 15

[Ian Moody [:Kwan] (UTC+1)]

So we have indeed removed the document (and window) level click from observation by web content. Unfortunately we can't yet get rid of it entirely since chrome UI depends on it. I did have a patch to remove the NO_CONTENT_DISPATCH hack, but unfortunately that will have to wait, since we introduced a pref to opt-in to (most of) the old behaviour if we need it for web-compat, ala the pref used for keypress changes. If we got rid of the hack now then the pref would lead to dispatching non-primary click on all elements, instead of just document and window objects.

Comment 16

[Kagami Rosylight [:saschanaz] (they/them)]

Seems NO_CONTENT_DISPATCH is not a thing anymore, and we don't fire click events anymore from middle/secondary clicks.