Closed Bug 184051 Opened 22 years ago Closed 4 years ago

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

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED INVALID
Milestone:
Future
Project Flags:
Webcompat Priority revisit
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: john, Assigned: smaug)

References

(Blocks 1 open bug,
URL
)

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.
Blocks: 151142
This may or may not block the event flow rewrite, but it probably affects it.
Blocks: 185758
Priority: -- → P3
Target Milestone: --- → Future
QA Contact: rakeshmishra → events
blocking2.0: --- → ?
Not blocking 1.9.3 on this. Olli, is this even a valid bug any more?
Assignee: john → Olli.Pettay
blocking2.0: ? → -
Blocks: 421112
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.
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.
Depends on: 968265
Blocks: 968240
No longer blocks: 110007
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

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

Flags: webcompat?
See Also: → https://webcompat.com/issues/25270
Whiteboard: [webcompat]
Component: Event Handling → User events and focus handling

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

Webcompat Priority: --- → ?

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

(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?

Flags: needinfo?(moz-ian)

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.

Flags: needinfo?(moz-ian)
Webcompat Priority: ? → revisit
Flags: webcompat?

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

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.