New event for non-primary button click

Problem

In attempting to remove the click event for non-primary buttons in Chrome as per UI Event Spec it was discovered there is no way for the developers to prevent opening a new tab when the user middle clicks on a link. The default middle click action of “Open new tab” is not formally documented.

Traditionally Chrome and some of the other vendors like Safari and Edge have fired the click event for all buttons (including non-primary). This poses a number of issues with pages executing click event handlers as traditionally javascript hasn’t examined the button field. Likewise other vendors have followed different approaches here. Mozilla dispatches the click event only to the document level nodes.

It is believe that for interoperability and legacy purposes the best approach is to fire the click event only for the primary button and that is reflected in the current UI Events Spec. However some applications may wish to override the default behavior of the UA. Specifically it is desirable to have an event for the middle button and explicitly define the default behavior.

Incomplete Solution

By listening to the mousedown/up events and saving the target in a global variable, it is possible for javascript to dispatch an untrusted click event with the correct button value to the desired target. However this workaround doesn’t seem to work robustly for example when facing stopimmediatepropagation API as other listeners might interfere with these listeners.

Proposal

Introduce a MouseEvent of type “auxclick” (other suggestions are welcome) which is fired for all non-primary buttons. This event is not only dispatched for middle button but also covers click for other buttons. It should be targeted at the node (i.e. common ancestor of mousedown and mouseup targets) and bubble as the click event does.

Click events are special in terms of allowing untrusted default action behavior for legacy purposes. It is believe that untrusted auxclick events should be are treated purely as untrusted and must not run the default action behavior.

Since we are changing the type from click to auxclick but keeping all other semantics the same, we believe only minor changes to applications that are currently using this behavior would be required.

Use Cases

Some of the use cases were mentioned briefly in the problem specification. But beyond listening to the auxclick event and capability to prevent opening a new tab or recording the metrics for opening the links in the new tab, this new event enables developers to also do actions on click for other buttons and expands the number of ways developers can expect the actions of their users.

@dtapuska, @RickByers, @teddink, @jacobrossi, @travisleithead, @garykac

Following our discussion, here is the discourse for the new event.

Thanks Navid. I agree this is a good idea - we can’t make Chrome conform to the UI Events spec without giving web developers some way to preserve their existing behavior here. While niche, an auxclick event for the rare scenarios where you really do want to override the default non-primary click action sounds like the right solution to me.

I agree with this approach it balances the problems with authors listening to the click event but not handling buttons correctly; yet allowing authors not to lose out on events they have today.

It should be noted that dblclick is dispatched only to the primary button so this approach doesn’t seem out of left field.

What exactly is a use case for disabling the default “open in new tab” middle click behavior? It seems to me that the only door this opens is for rogue developers to break the web and user expectations, or to continue the legacy of bad design which held that the web designer should be able to control the browser window size. The user should be in full control of their experience wrt number of tabs and size of window.

Regarding the behavior of preventing the new tab being opened by the browser there are a lot of legit use cases. There are a lot of them in Chrome pages. I can also imagine a modern website that are more and more like PWAs wanting to be able to control more and more of these actions. Aside from that a page that is written by the developer should decide how it wants to handle the clicks of any button on a link or any other element. So I don’t see much of an abuse there. Also users can always go ahead and close the page/tab if a page is misbehaving without affecting any other page/tab. If we just remove click event for middle button then that existing functionality will be removed and all those legit use cases will have no way of doing that.

We have put up this community draft spec for the “auxclick” event which will be hopefull pursue in Chrome.

Note that many of the best use cases present a similar (open in new tab) user experience but have customized it in some way. Eg. instead of clicking on a <a> tag, the app is doing something more complex involving a window.open. So the goal is not necessarily to permit developers to disable the “open in new tab” behavior, but to give them the hooks such that they can opt-in to ensuring their app really behaves as the user expects.

Pragmatically, this new event is precisely the mechanism by which we fix the problem of sites accidentally overriding the behavior in browsers like Chrome today which don’t follow the spec (fire click for non-primary buttons). We can’t break the 99% of cases which are failing to consider non-primary buttons any differently without providing an alternative for the 1% which really are providing a better user experience for middle click (eg. clicks on things that don’t have a default behavior).

This API is now shipping in Chrome. Is anyone else interested in potentially implementing this API? If so we should move the repo to the WICG organization.

auxclick sounds good to me. It doesn’t let pages to do anything more bad than what they are already doing. However, to get more feedback, it might be best to try to get auxclick to UIEvents. Like, is there already UIEvents spec bug about this?

Thanks!

There is now. Sorry, although we did discuss this with the UI Events editor (@garykac) we definitely should have filed an issue earlier to increase visibility.

IMHO this is still a bit of an experiment - we don’t yet know if we can succeed in eating the web compat impact of changing Chrome not to fire click for the middle mouse button. I’ve encouraged the UI Events folks not to consider adding auxclick until after we’ve found out if changing Chrome to match the spec around click will have acceptable web compat impact. But if others disagree and want to see it added to UI Events working drafts sooner, I wouldn’t object. Otherwise (or in the interim) I propose we move the repo to the WICG organization.

By the way, I should add that although this has now landed in Chrome Canary, we have plenty of time to make changes if there is feedback. Chrome 55 is scheduled to branch early October - so it’s easy to make changes before then. And then we’ve got until last November or so to make changes before it hits stable. So please file any feedback you have in GitHub.

This sounds good to me too. My preference would be to spin this up as a WICG due to the experimental nature.

Ok, done. The repo is now at https://github.com/WICG/auxclick.