| Summary: | releasePointerCapture() not working for implicit capture; can't opt-in to pointerenter/leave for touches | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | ian | ||||||||
| Component: | UI Events | Assignee: | Antoine Quint <graouts> | ||||||||
| Status: | RESOLVED FIXED | ||||||||||
| Severity: | Normal | CC: | ap, dino, ggaren, graouts, ian, koivisto, rniwa, webkit-bug-importer, zalan | ||||||||
| Priority: | P2 | Keywords: | InRadar | ||||||||
| Version: | Safari Technology Preview | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Attachments: |
|
||||||||||
Thanks for the report, I'll take look at this. Thank you!! It looks like this issue (and maybe other PE issues?) is unresolved in iOS13 -but- PE is enabled by default. Because the browser indicates it supports PE, I have a polyfil (PEP) standing down and things are breaking. I'm pretty sure I'll be able to get the polyfil to kick in, but there may be some users and authors in for a surprise. I'm effectively a dilettante and can't make presumptions about priority, but PE is a bridge between user and interface — so if it misbehaves, a site could stop responding properly in real fundamental ways — on _just_ iOS. That's like, bad, right? Sorry if I'm griping about some pet issue — web-tech is just tiring sometimes. Best Could you give us an example of website that's broken due to this bug? First, apologies -- I mistakenly thought iOS13 dropped and got real anxious, but I see it's not scheduled until the 19th. Second, I haven't had time to dig into what exactly is breaking and whether or not it's tied to this bug specifically, but I do know it's only apparent when doing touch input on iOS13 with native PE on (turn it off an things work fine, except for installed PWA). I can have more detailed info by Sunday. Site: http://sheets.flechs.net Example of the specific interaction that's breaking: http://www.youtube.com/watch?v=uzn056QBLBc&t=0m54s Works on Desktop/Tablet Chrome, Desktop Safari (11-13), Mobile Safari (11-12), Firefox Desktop, but not Mobile Safari 13. ( Slightly better example: https://www.youtube.com/watch?v=uzn056QBLBc&t=0m44s ) It looks like the example above is caused by a different PointerEvent issue regarding the buttons property. I've filed it here: https://bugs.webkit.org/show_bug.cgi?id=201770 So we do account for releasePointerCapture() being called, but only partially. We'll dispatch pointermove and pointerup events correctly, but we fail to dispatch boundary events (pointerover, pointerout, pointerenter and pointerleave). We'll use this bug to track completion of non-capturing event dispatch on iOS. Created attachment 379229 [details]
Patch
Created attachment 379230 [details]
Patch
Committed r250182: <https://trac.webkit.org/changeset/250182> This should be testable on the iOS 13.2 betas which are available to developers. Can confirm this issue is fixed in 13.2! (Tested on 6th generation iPad.) |
Created attachment 374143 [details] Example. w3c pointer events specs 10.4 note that a dev can/should call releasePointerCapture(pid) just after pointerdown and before any other pointer events to opt-in to hit-testing any following touch-generated pointer events. Assumedly, opting-in would make touch pointers work more like mouse pointers in that enter/leave events would be dispatched while the primary button is pressed. In Chrome at least, this is what happens. In iOS13 beta, calling releasePointerCapture(pid) does not result in his behavior. As such, there seems to be no way to opt-in to receiving pointerenter/leave events.