wicg / auxclick

Description for non-primary button click event

auxclick

This repository contained a proposed specification for a new MouseEvent called auxclick for non-primary buttons as the counterpart of click event which is restricted to the primary button.

As the incubation around this API was successful and the feature was shipped by multiple browsers the API moved to the W3C UIEvents specification, as maintained by the Web Platform Working Group.

References

• WICG Discourse thread
• Chrome shipping status and "Intent to ship" thread. Shipped in Chrome 55.
• Mozilla bug - shipping in Firerfox 53.
• Related WebKit bug - no public plans to ship.

auxclick's Issues

Clarify whether auxclick and contextmenu can both fire

When implementing auxclick in a test page, I noticed that in Chrome I couldn't get any auxclick event listeners to run on right clicks unless I called preventDefault() in a contextmenu listener.

I checked the spec to see what the intended behavior was, and this note lead me to believe that both events could/should fire.

After discussing with @RByers, he mentioned that Chrome stops all mouse events when a context menu is displayed.

Perhaps it's worth clarifying the intended behavior in the spec or linking to another spec that describes how mouse events should be handled when a context menu is displayed.

Consider adding use cases?

There have been multiple people claiming that there's no legitimate use case for a page to customize middle-click behavior. Perhaps we should add some real-world use cases to help motivate this? Eg:

1. A tab-strip where middle click (but not middle mouse-up) should close the tab
2. Non-link buttons (eg. GMail "reply") where middle click should open a new window

Define processing model

I'd like to have more detail on how this event works.

The draft needs to contain a description of the UI action that causes a task to be queued that eventually dispatches this event. The steps of that task need to have appropriate hooks for dispatching the contextmenu event so that interaction is also clearly defined.

Yes, this criticism also applies to UI events, but that's no reason to lower the bar.

Interaction with contextmenu

I don't think it makes much sense this is dispatched after contextmenu.

This represents one of the core UI actions that could result in a contextmenu being opened. It should dispatch first and canceling it should cause the contextmenu event to not dispatch.

Otherwise the flow is rather weird:

1. UI action comes in
2. It's a right click, let's deal with contextmenu first
3. Now actually deal with the UI action

Define auxclick as a PointerEvent?

The PointerEvent spec will soon say that click should be a PointerEvent (in addition to being a MouseEvent). Should auxclick be defined from the start to be a PointerEvent?

My feeling here is that it probably shouldn't require it. Maybe for now just say that it's the same type as click? We should aim for this event to mature into the UI Events spec, and not all UI Events implementors will necessarily implement PointerEvents. So eventually this should just added to the list of events to upgrade in the PE spec. But during incubation it probably belongs here in some optional form.

Should preventDefault override middle click autoscroll?

The issues surrounding right click context menu are quite unintuitive and unfortunate, but in a similar vein, is MMB autoscroll intended to be a preventable behaviour of auxclick? Currently Firefox for Windows sends an auxclick event and opens the autoscroll menu, while Chrome for Windows doesn't fire an auxclick event and instead opens the autoscroll menu. Would this be worthy of a note in the spec?

Use living-draft links instead of TR links for specs

Given the incubation nature of the spec, it's probably best to use living-links like https://w3c.github.io/uievents/ instead of https://www.w3.org/TR/uievents/.

This doesn't fully solve the problem of opening links in new tabs

The introduction describes a use case for why the click event should only fire for the primary button: To make it easier to add custom handling on navigating a link in the same tab, without breaking opening the link in a new tab by middle clicking. The proposed solution however only solves half the problem. Web sites still have to use JavaScript that emulate the browser's keyboard shortcut handling, for example to avoid breaking opening a link in a new tab by Ctrl-clicking. If you really want to make it easier to get this right, you should provide an event that explicitly means "going to open this link in the current tab", that takes all the browser's user interactions for opening links in new tabs, windows or whatever into account.

Define order relative to contextmenu

The contextmenu example raises an interesting question - which occurs first, contextmenu or auxclick? Is the contextmenu event the default action of the auxclick with button=2?

Should we define `onauxclick`?

Most events have on properties/attributes, but this is an old style and has issues - eg. confusion over the use of the return value. Given that we expect auxclick to be used rarely, perhaps it's actually a good thing if we break with tradition and don't define any on properties/attributes for it?