whatwg
Change light dismiss to use click events
This PR replaces the existing pointerdown and pointerup listening and tracking with algorithms which use a click event. The click event is going to be used by the pointerevents spec here: https://github.com/w3c/pointerevents/pull/460
Using click events instead of doing click detection with pointerdown and pointerup fixes a number of issues which are detailed here: https://github.com/w3c/pointerevents/issues/542
Fixes https://github.com/whatwg/html/issues/10905
- [ ] At least two implementers are interested (and none opposed):
- Chromium
- …
- [ ] Tests are written and can be reviewed and commented upon at:
- https://chromium-review.googlesource.com/c/chromium/src/+/6664038
- [ ] Implementation bugs are filed:
- Chromium: https://issues.chromium.org/issues/408010435
- Gecko: …
- WebKit: …
- [x] Corresponding HTML AAM & ARIA in HTML issues & PRs: I don't think this changes any accessibility mappings.
- [x] MDN issue is filed: This is a bug fix which I don't think the details of are or should be documented on MDN.
- [x] The top of this comment includes a clear commit message to use.
(See WHATWG Working Mode: Changes for more details.)
/interactive-elements.html ( diff ) /popover.html ( diff )
I'm likely missing something here, but since mousedown triggers select's popup to be shown, aren't there cases when just relying on click here then immediately dismisses it.
I'm likely missing something here, but since mousedown triggers select's popup to be shown, aren't there cases when just relying on click here then immediately dismisses it.
Good catch! I'm working on a fix for this, I'll try putting it in this spec PR after I get something that works well.
Here is the aforementioned fix for the immediate light dismiss: https://github.com/whatwg/html/pull/12008
If I understand correctly, this PR will change user-facing behavior from:
(the arrows indicate a pointerdown pointerup pair, with red indicating light dismiss and green indicating no action)
to
If this isn’t intentional, I can suggest fixes.
demo: https://codepen.io/sb3nder/pen/qEZpXqL
Regarding whatwg/html#12008, I wonder if it would be better to apply the same behavior to non‑select popovers. I can suggest a small change that wouldn’t require a flag.
Thanks for the images, but I'm having a hard time understanding the behavior difference. The change is released in chrome canary with experimental web platform features enabled: chrome://flags/#enable-experimental-web-platform-features
Do you think you could test it out and share a video? Or give a list of steps I can read to repro the change in behavior?
Thank you, I tested with the Experimental Web Platform features enabled, and everything works fine for me:
But I’m having a hard time understanding from the spec how, with just the click target, it is able to differentiate the various cases. For example, if I click-drag from a popover to <body>, the click target is <body> and it does not light-dismiss. However, if I just click <body>, the click target is <body> and it does light-dismiss. I must be missing the obvious.
Thank you.
Ah good point I messed this up in the process of rewriting the chromium patch several times, I'll update this and the pointerevents spec PR soon
Ok it should have substantially more detail now, please take a look. I also updated the pointerevents spec PR accordingly
Looks good to me!
~~My only nitpick is that, to open a modal dialog on pointerdown, one has to call preventDefault() on the cancel event, while for a popover it works out of the box when the button has the commandfor/popovertarget attribute.~~ EDIT: changed my mind, please ignore this in the context of this PR