Bug 261786

Summary: requestPointerLock does not cancel existing pointer capture
Product: WebKit Reporter: James Howard <jameshoward>
Component: UI EventsAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: a_protyasha, jameshoward, karlcow, webkit-bug-importer
Priority: P2 Keywords: BrowserCompat, InRadar
Version: Safari 17   
Hardware: Mac (Apple Silicon)   
OS: macOS 13   
Attachments:
Description Flags
Fixed version of pointerevent_pointerlock_after_pointercapture.html none

Description James Howard 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
Comment 1 Abrar Rahman Protyasha 2023-09-19 17:46:03 PDT 
Out of curiosity; are other browser engines passing this modified layout test?
Comment 2 Abrar Rahman Protyasha 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?)
Comment 3 James Howard 2023-09-19 17:48:42 PDT 
Yeah, Gecko passes too (117.0). WebKit is the only one that fails.
Comment 4 Abrar Rahman Protyasha 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.
Comment 5 James Howard 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.
Comment 6 James Howard 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.
Comment 7 Abrar Rahman Protyasha 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.
Comment 8 Abrar Rahman Protyasha 2023-09-21 13:32:11 PDT 
(Thanks for catching this, btw!)
Comment 9 Radar WebKit Bug Importer 2023-09-21 13:32:42 PDT 
<rdar://problem/115857922>
Comment 10 Abrar Rahman Protyasha 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.
Comment 11 James Howard 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.
Comment 12 James Howard 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. :)