Open Bug 1700234 Opened 4 years ago Updated 1 year ago

New wpt failure in /pointerevents/pointerevent_pointercapture_in_frame.html?pen

Categories

(Core :: DOM: Events, defect)

defect

Tracking

()

People

(Reporter: wpt-sync, Unassigned)

References

()

Details

(Whiteboard: [wpt])

Syncing wpt PR 28010 found new untriaged test failures in CI

Tests Affected

Firefox-only failures

/pointerevents/pointerevent_pointercapture_in_frame.html?mouse
Test mousepointer capture in same-origin frame: Pointer down at outer frame body and set pointer capture.: FAIL
/pointerevents/pointerevent_pointercapture_in_frame.html?pen: ERROR
/pointerevents/pointerevent_pointercapture_in_frame.html?touch: ERROR

CI Results

Gecko CI (Treeherder)
GitHub PR Head

Notes

These updates will be on mozilla-central once bug 1697656 lands.

Note: this bug is for tracking fixing the issues and is not
owned by the wpt sync bot.

This bug is linked to the relevant tests by an annotation in
https://github.com/web-platform-tests/wpt-metadata. These annotations
can be edited using the wpt interop dashboard
https://jgraham.github.io/wptdash/

If this bug is split into multiple bugs, please also update the
annotations, otherwise we are unable to track which wpt issues are
already triaged. Resolving as duplicate or closing this issue should
be cause the bot to automatically update or remove the annotation.

For interop-2023, only /pointerevents/ [pointerevent_pointercapture_in_frame.html?mouse is included in the metric.

Quick debug about the failure in ?mouse case.

First, the test listens to pointerup event in the outer <div> of the <iframe>. Then, it starts to listen to lostpointercapture event in the outer <div> after a tick because of after the Promise is resolved. This means that the test assumes that pointerup and lostpointercapture events are fired in different event loop ticks. However, we dispatch them in a same tick within this stack:

#02: mozilla::PointerEventHandler::DispatchGotOrLostPointerCaptureEvent (M:\src\dom\events\PointerEventHandler.cpp:781)
#03: mozilla::PointerEventHandler::CheckPointerCaptureState (M:\src\dom\events\PointerEventHandler.cpp:367)
#04: mozilla::EventStateManager::PostHandleEvent (M:\src\dom\events\EventStateManager.cpp:3561)
#05: mozilla::PresShell::EventHandler::DispatchEvent (M:\src\layout\base\PresShell.cpp:8261)
#06: mozilla::PresShell::EventHandler::HandleEventWithCurrentEventInfo (M:\src\layout\base\PresShell.cpp:8182)
#07: mozilla::PresShell::EventHandler::HandleEventWithTarget (M:\src\layout\base\PresShell.cpp:8086)
#08: mozilla::PointerEventHandler::DispatchPointerFromMouseOrTouch (M:\src\dom\events\PointerEventHandler.cpp:632)
#09: mozilla::PresShell::EventHandler::DispatchPrecedingPointerEvent (M:\src\layout\base\PresShell.cpp:7303)
#10: mozilla::PresShell::EventHandler::HandleEventUsingCoordinates (M:\src\layout\base\PresShell.cpp:7107)
#11: mozilla::PresShell::EventHandler::HandleEvent (M:\src\layout\base\PresShell.cpp:6926)
#12: mozilla::PresShell::HandleEvent (M:\src\layout\base\PresShell.cpp:6869)
#13: mozilla::PresShell::EventHandler::MaybeHandleEventWithAnotherPresShell (M:\src\layout\base\PresShell.cpp:7608)
#14: mozilla::PresShell::EventHandler::HandleEvent (M:\src\layout\base\PresShell.cpp:6913)
#15: mozilla::PresShell::HandleEvent (M:\src\layout\base\PresShell.cpp:6869)
#16: nsViewManager::DispatchEvent (M:\src\view\nsViewManager.cpp:652)
#17: nsView::HandleEvent (M:\src\view\nsView.cpp:1150)
#18: mozilla::widget::PuppetWidget::DispatchEvent (M:\src\widget\PuppetWidget.cpp:347)
#19: nsContentUtils::SendMouseEvent (M:\src\dom\base\nsContentUtils.cpp:8602)
#20: nsDOMWindowUtils::SendMouseEvent (M:\src\dom\base\nsDOMWindowUtils.cpp:695)

Therefore, I think it's too late the test to start listening to lostpointercapture event.

The event is declared as:

This event MUST be fired prior to any subsequent events for the pointer after capture was released.

And using AsyncEventDispatcher::PostEvent() breaks this rule. How can we spin the event loops before dispatching the lostpointercapture event?

Flags: needinfo?(smaug)
Flags: needinfo?(smaug) → needinfo?(echen)

There were some discussion around the timing of firing lostpointercapture event, https://github.com/w3c/pointerevents/issues/357 and https://github.com/w3c/pointerevents/issues/356. The resolution is to fire lostpointercapture before the click and spec also has https://w3c.github.io/pointerevents/#event-dispatch now. So I think the test isn't correct and should be updated, i.e. our behavior is expected and Chrome doesn't follow spec yet.

Flags: needinfo?(echen)

Thank you, Edgar! I'll file an issue.

Test fix has been merged upstream https://github.com/web-platform-tests/wpt/pull/41039

Now the fix is merged into m-c.

The remaining issue is only in the pen mode.

No longer blocks: interop-2023-events
Summary: New wpt failures in /pointerevents/ [pointerevent_pointercapture_in_frame.html?mouse, pointerevent_pointercapture_in_frame.html?pen, pointerevent_pointercapture_in_frame.html?touch] → New wpt failure in /pointerevents/pointerevent_pointercapture_in_frame.html?pen
You need to log in before you can comment on or make changes to this bug.