Bug 261786 – requestPointerLock does not cancel existing pointer capture

• Component: UI Events
• Status: NEW

[James Howard]

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

[Abrar Rahman Protyasha]

Out of curiosity; are other browser engines passing this modified layout test?

[Abrar Rahman Protyasha]

(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]

Yeah, Gecko passes too (117.0). WebKit is the only one that fails.

[Abrar Rahman Protyasha]

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]

Yeah I tried the same thing as well.

I don’t think pointerLockWasApplied is doing what it needs to do.

[James Howard]

I should note that this bug isn’t a big issue for me personally. I simply found it by code inspection.

[Abrar Rahman Protyasha]

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]

(Thanks for catching this, btw!)

[Radar WebKit Bug Importer]

<rdar://problem/115857922>

[Abrar Rahman Protyasha]

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]

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]

(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. :)