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.
This may or may not block the event flow rewrite, but it probably affects it.
Not blocking 1.9.3 on this. Olli, is this even a valid bug any more?
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.