[Webkit-unassigned] [Bug 261786] New: requestPointerLock does not cancel existing pointer capture

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Sep 19 17:36:32 PDT 2023


            Bug ID: 261786
           Summary: requestPointerLock does not cancel existing pointer
           Product: WebKit
           Version: Safari 17
          Hardware: Unspecified
                OS: macOS 13
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: UI Events
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: jameshoward at mac.com

Created attachment 467769

  --> https://bugs.webkit.org/attachment.cgi?id=467769&action=review

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

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230920/3fff792b/attachment.htm>

More information about the webkit-unassigned mailing list