Closed Bug 1441755 Opened 7 years ago Closed 4 years ago

auxclick: default action is not prevented on mouse wheel click.

Categories

(Core :: DOM: Events, defect, P3)

Product:
Core
Component:
DOM: Events
Version:
58 Branch
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: sanjayishkjay, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36 Steps to reproduce: Tested on Mozilla Quantum 58 On Windows 8. I've added an auxclick handler that should prevent the default action. In my case, I am trying to prevent the default action of opening the link in new tab when a mouse wheel is clicked. This should be possible as per https://developer.mozilla.org/en-US/docs/Web/Events/auxclick <html> <body> <a href="https://www.google.com" target="_blank">Google Link</a> <script> var handler = function(e) { e.preventDefault(); e.stopPropagation(); e.stopImmediatePropagation(); return false; }; var anchorTag = document.getElementsByTagName('a')[0]; anchorTag.addEventListener('auxclick', handler, false); </script> </body> </html> Actual results: Link is opened in new tab and then the event handler is executed. Expected results: Event handler should have been executed first and then the new tab shouldn't have opened because of preventDefault method. To Add, this works as expected in the Chrome 64. Default action is prevented.
I really don't think web pages should have the power to sabotage basic browser behavior like "Open in new Tab". The user's choice should come before any wishes web developers might have.
Component: General → DOM: Events
I get it. Definitely agree with user before developer argument. But when I look at what we can do with Ctrl+click, it seems right to give the same ability to developer for mouse wheel click too. Shouldn't there be uniformity ? Not that it makes it right, chrome does this already. Moreover it's mentioned in the mdn documentation that this sort of thing should be possible.
Olli, this seems like another thing you need to decide on (or is someone else in charge of user input events?).
Flags: needinfo?(bugs)
Priority: -- → P3
This should be a valid bug report. When I work on bug 1461708, I realized that our "auxclick" event implementation is wrong. Currently, we dispatch "click"/"dblclick"/"auxclick" events as default action of "mouseup" event. The order is: 1. "click" 2. "dblclick" (only when clickCount is 2) 3. "auxclick" (only when button is not 0) (Note that non-primary button's "click" and "dblclick" events are fired only on window and document node on Gecko due to historical reason.) Additionally, default action handlers for non-primary button keep listening to "click" events rather than "auxclick" events. Therefore, before dispatching "auxclick" events, all default action handlers handle the click event! Therefore, preventDefault() of "auxclick" event cannot prevent any default action. I think that if we dispatch "auxclick" event from nsPresShellEventCB for "click" event, we can make the event order as: 1. "click" in the default event group. 2. "auxclick" in the default event group. 3. "auxclick" in the system event group. 4. "click" in the system event group. 5. "dblclick" This approach changes the event order between "dblclick" and "auxclick", I feel this order is more natural. Then, we make all default handlers of click event in the system event group, we can keep current code as is.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → All
QA Contact: overholt
Hardware: Unspecified → All
QA Contact: overholt

This seems to be working now.

Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(bugs)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.