NEW 261786
requestPointerLock does not cancel existing pointer capture
https://bugs.webkit.org/show_bug.cgi?id=261786
Summary requestPointerLock does not cancel existing pointer capture
James Howard
Reported 2023-09-19 17:36:32 PDT
Created attachment 467769 [details] Fixed version of pointerevent_pointerlock_after_pointercapture.html See attached test page, which is an adaptation of this wpt: https://github.com/WebKit/WebKit/blob/main/LayoutTests/imported/w3c/web-platform-tests/pointerevents/pointerlock/pointerevent_pointerlock_after_pointercapture.html The wpt passes because it only verifies that 'lostpointercapture' occurs after sending pointerUp({button: actions.ButtonType.LEFT}) to the test driver. But the spec[^1] says that we're supposed to get lostpointercapture after 'pointerlockchange'. In my modified test, the expected console output is as follows (taken from Chrome 116.0.5845.179): lostcapture.html:24 setPointerCapture lostcapture.html:45 got_capture = true lostcapture.html:38 requestPointerLock lostcapture.html:55 Pointer lock element: div1 lostcapture.html:49 lost_capture = true lostcapture.html:30 pointerup In STP 176 (Safari 17.0, WebKit 18617.1.3.2), as well as ToT WebKit as of this writing, the output is as follows: [Log] setPointerCapture (lostcapture.html, line 24) [Log] got_capture = true (lostcapture.html, line 45) [Log] requestPointerLock (lostcapture.html, line 38) [Log] Pointer lock element: – "div1" (lostcapture.html, line 55) [Log] pointerup (lostcapture.html, line 30) [Log] lost_capture = true (lostcapture.html, line 49) Note that the last two lines are swapped comparing Chromium to WebKit. This is because Chromium is correctly cancelling pointer capture when pointer lock is engaged, but WebKit is only doing it after I lifted the left mouse button, which is unrelated to pointer lock. [^1]: https://w3c.github.io/pointerevents/#implicit-release-of-pointer-capture
Attachments
Fixed version of pointerevent_pointerlock_after_pointercapture.html (3.27 KB, text/html)
2023-09-19 17:36 PDT, James Howard
no flags
Abrar Rahman Protyasha
Comment 1 2023-09-19 17:46:03 PDT
Out of curiosity; are other browser engines passing this modified layout test?
Abrar Rahman Protyasha
Comment 2 2023-09-19 17:47:06 PDT
(In reply to Abrar Rahman Protyasha from comment #1) > Out of curiosity; are other browser engines passing this modified layout > test? (it seems like Chromium is; and Gecko?)
James Howard
Comment 3 2023-09-19 17:48:42 PDT
Yeah, Gecko passes too (117.0). WebKit is the only one that fails.
Abrar Rahman Protyasha
Comment 4 2023-09-21 11:57:51 PDT
I believe this is a real bug, but without investigating too far, I can say that simply adding a call to `PointerCaptureController::pointerLockWasApplied()` in `PointerLockController::didAcquirePointerLock()` does not fix things. We should look into all possible ways to acquire pointer lock and unify the codepaths where we need to disengage pointer capture.
James Howard
Comment 5 2023-09-21 12:16:39 PDT
Yeah I tried the same thing as well. I don’t think pointerLockWasApplied is doing what it needs to do.
James Howard
Comment 6 2023-09-21 12:26:35 PDT
I should note that this bug isn’t a big issue for me personally. I simply found it by code inspection.
Abrar Rahman Protyasha
Comment 7 2023-09-21 13:28:03 PDT
Sure! But is a real bug (and a potential WPT failure) nonetheless, if someone were to change the WPT to be more in-line with the spec.
Abrar Rahman Protyasha
Comment 8 2023-09-21 13:32:11 PDT
(Thanks for catching this, btw!)
Radar WebKit Bug Importer
Comment 9 2023-09-21 13:32:42 PDT
Abrar Rahman Protyasha
Comment 10 2023-09-21 13:33:14 PDT
I'm importing this into our internal bug tracker, but feel free to work on this as you see fit. Just let me know if you're about to submit a patch so that we don't duplicate efforts.
James Howard
Comment 11 2023-09-21 13:36:40 PDT
Sure if you want to take this I'd appreciate it. I can help review since I'm not familiar with the surrounding code and tests.
James Howard
Comment 12 2023-09-21 13:37:02 PDT
(In reply to James Howard from comment #11) > Sure if you want to take this I'd appreciate it. I can help review since I'm > not familiar with the surrounding code and tests. err, I am *now* familiar with the surrounding code and tests. :)
Note You need to log in before you can comment on or make changes to this bug.