1910801 - `file_pointercapture_xorigin_iframe_pointerlock.html` depends on native mouse move event

Status: ASSIGNED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

When pointer lock is requested and granted, EventStateManager::SetPointerLock() is called. Then, EventStateManager synthesizes a native mouse move for:

• Making the initial mouse cursor position to center of the widget
• Flushing pending lostpointercapture event which is dispatched when next pointer event is dispatched

Currently, synthesized mouse events for tests may block the following native mouse events which accidentally fired by OS. Therefore, we need to guarantee that PresShell will handle the native mouse move even during a test.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Hmm, my investigation seems wrong. Not ignoring native mouse events for a while does not fix the new orange of file_pointercapture_xorigin_iframe_pointerlock.html. So, I think that we need to make PointerEventHandler::ReleaseAllPointerCapture() enqueue lostpointercapture events.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1910801 - Make `PointerEventHandler::ReleaseAllPointerCapture' run `CheckPointerCaptureState` asynchronously r=smaug!,#dom-core

PointerEventHandler::ReleaseAllPointerCapture just clear the pending element.
So, lostpointercapture event won't be fired immediately. Therefore, a caller,
EventStateManager::SetPointerLock, synthesizes a native mouse move event to
make PointerEventHandler dispatch pending lostpointercapture events.

However, this means that we need that eMouseMove which is not marked as
synthesized for tests to flush the pending lostpointercapture events.
This may become a problem for PresShell::HandleEvent to ignore odd mouse
events coming from OS while running a test.

There are only 2 callers of the method. The other is
BrowserChild::RecvReleaseAllPointerCapture() whose sender,
BrowserParent::SendReleaseAllPointerCapture(), is called only by
PointerEventHandler::ReleaseAllPointerCaptureRemoteTarget() only during to
lock pointer. Therefore, in this case, we don't have a chance to flush
the pending lostpointercapture if native mouse move event is not handled in
proper PresShell. So, this patch could fix a hidden bug too.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Ah, no. I was taking a wrong approach. The behavior, dispatching lostpointercapture alone when locking pointer event is wrong because the event should be fired as a preceding event of a pointer event.

https://w3c.github.io/pointerevents/#dfn-lostpointercapture

The user agent MUST fire a pointer event named lostpointercapture after pointer capture is released for a pointer. This event MUST be fired prior to any subsequent events for the pointer after capture was released.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Hmm, it seems that it's caused by an edge case of bug 1793267.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Pointer Lock does not define about Pointer Capture. Instead, Pointer Capture defines it as:

When a pointer lock [PointerLock] is successfully applied on an element, the user agent MUST run the steps as if the releasePointerCapture() method has been called if any element is set to be captured or pending to be captured.

So, strictly believing this definition, lostpointercapture should not be fired even if pointer capture is forcibly canceled by Pointer Lock. However, I guess that it's not expected behavior for web developers. I guess that they want lostpointercapture without user input after setting Pointer Lock like implicitly releasing pointer capture.