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
Out of curiosity; are other browser engines passing this modified layout test?
(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?)
Yeah, Gecko passes too (117.0). WebKit is the only one that fails.
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.
Yeah I tried the same thing as well. I don’t think pointerLockWasApplied is doing what it needs to do.
I should note that this bug isn’t a big issue for me personally. I simply found it by code inspection.
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.
(Thanks for catching this, btw!)
<rdar://problem/115857922>
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.
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.
(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. :)