- From: Masayuki Nakano via GitHub <sysbot+gh@w3.org>
- Date: Sat, 10 May 2025 07:01:30 +0000
- To: public-pointer-events@w3.org
Oh, this is partially tested by [a WPT](pointerevents/pointerevent_capture_mouse_and_release_and_capture_again.html), but it was added by me. [Chrome and Firefox pass the test](https://wpt.fyi/results/pointerevents/pointerevent_capture_mouse_and_release_and_capture_again.html?label=master&label=experimental&aligned&q=pointerevent_capture_mouse_and_release_and_capture_again). So, new pending element which is set by a `lostpointercapture` event listener should be processed at dispatching next pointer event. There are following scenarios: 1. `A.setPointerCapture(n)` 2. `B.setPointerCapture(n)`, then, `lostpointercapture` listener does `C.setPointerCapture(n)` and 1. `A.setPointerCapture(n)` 2. `B.setPointerCapture(n)`, then, `lostpointercapture` listener does `B.releasePointerCapture(n)` In the test, the new pending element is expected to be set to the override element when next "process the pending capture" time. I guess this should be true for the both cases (setting to updating to another element or cleared). However, `gotpointercapture` should be fired on the previously set to the pending element? [4.1.3.2 Process pending pointer capture](https://w3c.github.io/pointerevents/#dfn-process-pending-pointer-capture) should define this clearer. -- GitHub Notification of comment by masayuki-nakano Please view or discuss this issue at https://github.com/w3c/pointerevents/issues/550#issuecomment-2868563753 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 10 May 2025 07:01:31 UTC