Bug 1961318 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

[pointerevent_setpointercapture_inactive_button_mouse.html](https://searchfox.org/mozilla-central/rev/0383ce6fe9579f345529b06170caaeb386ebc7c2/testing/web-platform/tests/pointerevents/pointerevent_setpointercapture_inactive_button_mouse.html) fails in [wpt.fyi](https://wpt.fyi/results/pointerevents/pointerevent_setpointercapture_inactive_button_mouse.html?label=experimental&label=master&aligned&view=interop&q=label%3Ainterop-2023-events), however, [looks like that it passes on our CI](https://searchfox.org/mozilla-central/rev/0383ce6fe9579f345529b06170caaeb386ebc7c2/testing/web-platform/meta/pointerevents/pointerevent_setpointercapture_inactive_button_mouse.html.ini#7,11).

The test tries to [capture the pointer within the `pointerover` listener](https://searchfox.org/mozilla-central/rev/0383ce6fe9579f345529b06170caaeb386ebc7c2/testing/web-platform/tests/pointerevents/pointerevent_setpointercapture_inactive_button_mouse.html#37,39) when [no button is pressed](https://searchfox.org/mozilla-central/rev/0383ce6fe9579f345529b06170caaeb386ebc7c2/testing/web-platform/tests/pointerevents/pointerevent_setpointercapture_inactive_button_mouse.html#48).

[`Element.setPointerCapture()` is defined as](https://w3c.github.io/pointerevents/#dom-element-setpointercapture)
> The pointer MUST be in its active buttons state for this method to be effective, otherwise it fails silently.

However, we failed the test with an exception:
> FAIL message: NotFoundError: Element.setPointerCapture: Invalid pointer id

On the other hand, ["Setting pointer capture" section defines](https://w3c.github.io/pointerevents/#dfn-set-pointer-capture)
> If the pointerId provided as the method's argument does not match any of the active pointers, then throw a "NotFoundError" DOMException.

as its first step.

["active pointers" is defined](https://w3c.github.io/pointerevents/#dfn-active-pointer) as
> Any touch contact, pen/stylus, mouse cursor, or other pointer that can produce events. If it is possible for a given pointer (identified by a unique pointerId) to produce additional events within the document, then that pointer is still considered active. Examples:
> *  A mouse connected to the device is always active.

Currently, [we activates mouse pointer only while the cursor is over the document](https://searchfox.org/mozilla-central/rev/0383ce6fe9579f345529b06170caaeb386ebc7c2/dom/events/PointerEventHandler.cpp#82,84-87,127,130). That requires `eMouseEnterIntoWidget` event before the `pointerover`, but it's not guaranteed that it's fired before the first synthesized mouse move.

So, perhaps, we need to active pointer if we synthesize a mouse move over a document, but for not breaking the actual user input handling, it should not affect to non-synthesized events.
[pointerevent_setpointercapture_inactive_button_mouse.html](https://searchfox.org/mozilla-central/rev/0383ce6fe9579f345529b06170caaeb386ebc7c2/testing/web-platform/tests/pointerevents/pointerevent_setpointercapture_inactive_button_mouse.html) fails in [wpt.fyi](https://wpt.fyi/results/pointerevents/pointerevent_setpointercapture_inactive_button_mouse.html?label=experimental&label=master&aligned&view=interop&q=label%3Ainterop-2023-events), however, [looks like that it passes on our CI](https://searchfox.org/mozilla-central/rev/0383ce6fe9579f345529b06170caaeb386ebc7c2/testing/web-platform/meta/pointerevents/pointerevent_setpointercapture_inactive_button_mouse.html.ini#7,11).

The test tries to [capture the pointer within the `pointerover` listener](https://searchfox.org/mozilla-central/rev/0383ce6fe9579f345529b06170caaeb386ebc7c2/testing/web-platform/tests/pointerevents/pointerevent_setpointercapture_inactive_button_mouse.html#37,39) when [no button is pressed](https://searchfox.org/mozilla-central/rev/0383ce6fe9579f345529b06170caaeb386ebc7c2/testing/web-platform/tests/pointerevents/pointerevent_setpointercapture_inactive_button_mouse.html#48).

[`Element.setPointerCapture()` is defined as](https://w3c.github.io/pointerevents/#dom-element-setpointercapture)
> The pointer MUST be in its active buttons state for this method to be effective, otherwise it fails silently.

However, we failed the test with an exception:
> FAIL message: NotFoundError: Element.setPointerCapture: Invalid pointer id

On the other hand, ["Setting pointer capture" section defines](https://w3c.github.io/pointerevents/#dfn-set-pointer-capture)
> If the pointerId provided as the method's argument does not match any of the active pointers, then throw a "NotFoundError" DOMException.

as its first step.

["active pointers" is defined](https://w3c.github.io/pointerevents/#dfn-active-pointer) as
> Any touch contact, pen/stylus, mouse cursor, or other pointer that can produce events. If it is possible for a given pointer (identified by a unique pointerId) to produce additional events within the document, then that pointer is still considered active. Examples:
> *  A mouse connected to the device is always active.

Currently, [we register mouse pointer only while the cursor is over the document](https://searchfox.org/mozilla-central/rev/0383ce6fe9579f345529b06170caaeb386ebc7c2/dom/events/PointerEventHandler.cpp#82,84-87,127,130). That requires `eMouseEnterIntoWidget` event before the `pointerover`, but it's not guaranteed that it's fired before the first synthesized mouse move.

So, perhaps, we need to register pointer if we synthesize a mouse move over a document. However, we cannot unregister it automatically. Therefore, I think it should have a bool flag and if it's required, `PointerEventHandler::GetPointerInfo()` callers should check whether it gets proper pointer info.

Back to Bug 1961318 Comment 0