UI Events WD compliance

(was “Fixing the click event in browsers”)

While the UI Events (DOM Events L3) spec states that the click event should only be fired for clicks from the “primary button” on the mouse (as well as other synthetic sources, such as touches and keyboard focus), it appears different browsers disagree on this behavior, specifically regarding middle-clicking.

WebKit has had a bug for this for over six years, but it still hasn’t been fixed (partially because the spec was still vague about which buttons should trigger click when the issue was originally written).

What is the state of click in the other browsers? Is it too late to fix this / too big to fix (akin to the many broken implementations of mouse wheel events)?

@stuartpb, I don’t know if the UI Events Editors (Travis and Gary) have seen your posting. As such, you might want to ask your questions on the spec’s www-dom e-mail list or its Github repo.

Well, I didn’t ping them initially because I don’t want to change the spec. The spec behavior is good. I want to fix the browsers to comply to that spec behavior (or at least rattle some chains on the relevant bug trackers to raise awareness of this less-ambiguous spec behavior).

Specifically:

• WebKit should stop firing click for middle-clicks (bringing it in line with Firefox and IE).
• The Webkit bug mentions Firefox firing click for all buttons for document and body - if this hasn’t been fixed yet, it should be fixed as well.

That said, they’d probably be the first ones to ask about what the current support landscape is / what work needs to be done, so https://github.com/w3c/uievents/issues/3

If IE and Firefox don’t fire click for middle button, then I’d be willing to attempt changing blink to match (of course we may have to revert if we break anyone depending on blink/WebKit specific behavior). Please file a bug at crbug.com/new and I’ll try to find someone to take a look. Any example where this difference caused pain in practice will help get it prioritized.

By the way, the title here is probably too vague. Specific interoperability differences are great topics, as are improving conformance test suites. But general “conformance” in the absence of a good test suite isn’t really actionable. I know the UI events folks are investing in test suites, and I’m talking with folks about getting automated input testing, so maybe then we’d really have a way to reasonable test UI events conformance!

This causes lots of pain in practice wrt sites that add special listeners to the click event to add extra magic to their link opening behavior: see the WebKit bug, where multiple users posted Chrome extensions to fix this for precisely that reason.

Will probably submit a crbug later: I want to bang out some discussion here, since my experience with crbug is you basically get one shot for the devs to look at your issue, and if they don’t understand it it never gets looked at again (example).

I just tried this in a couple browsers. IE 11 on Windows also sends click for the middle button, but Firefox doesn’t. Given that only Firefox seems to match the spec here, it’s possible trying to fix this could cause more web compat issues than it fixes (and if so, one could argue that the spec should be changed instead). That said, I agree the lack of consistency between browsers is a bug and I’m willing to at least review patches to blink that attempts to change the behavior to match the spec.

Another bug caused by this behavior.