Fire middle/right-click events at content and remove click hack
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: john, Assigned: smaug)
References
(Blocks 1 open bug, )
Details
(Whiteboard: [webcompat])
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.
Reporter | ||
Comment 1•22 years ago
|
||
This may or may not block the event flow rewrite, but it probably affects it.
Updated•15 years ago
|
Updated•14 years ago
|
Updated•14 years ago
|
Comment 5•14 years ago
|
||
Not blocking 1.9.3 on this. Olli, is this even a valid bug any more?
Comment 7•13 years ago
|
||
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•13 years ago
|
||
I commented about "onclick" attribute.
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.
Updated•9 years ago
|
Comment 10•6 years ago
|
||
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•5 years ago
|
||
This is now causing subtle (albeit minor) compat issues even on YouTube's UI, as reported at https://webcompat.com/issues/25270
Updated•5 years ago
|
Comment 12•5 years ago
|
||
Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.
Comment 13•5 years ago
|
||
See bug 1547409. Migrating whiteboard priority tags to program flags.
Comment 14•5 years ago
|
||
(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:
What do you think Kwan?
Comment 15•5 years ago
|
||
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.
Updated•5 years ago
|
Seems NO_CONTENT_DISPATCH
is not a thing anymore, and we don't fire click events anymore from middle/secondary clicks.
Description
•