pointerevents/pointerevent_pointerout_no_pointer_movement.html contradicts UIEvents spec and WPT

web-platform-tests / interop

web-platform-tests Interop project

https://wpt.fyi/interop

281 stars 28 forks source link

pointerevents/pointerevent_pointerout_no_pointer_movement.html contradicts UIEvents spec and WPT #695

Open mustaqahmed opened 6 days ago

mustaqahmed commented 6 days ago

Test List

pointerevents/pointerevent_pointerout_no_pointer_movement.html

Rationale

I am proposing to remove the above test from Interop 2024: while the test matches the spec, both the test and the spec contradicts the corresponding behavior defined in UIEvents 7 years ago.

PointerEvents doesn't want pointerover/out events w/o a movement in the mouse pointer, but UIEvents wants mouseover/out events w/o a movement so that hover effect is updated correctly after a layout change or scroll.

FYI @smaug---- @flackr

masayuki-nakano commented 5 days ago

Shouldn't be it caused by dispatching a lostpointercapture for the implicit pointer capture of the click?

masayuki-nakano commented 5 days ago

Err, no, opposite. pointerup -> lostpointercapture (-> mouseup) -> click -> layout change. So, no pointer boundary events should be fired. (So, it seems that the current expectation of the test matches with current spec.)

mustaqahmed commented 5 days ago

Good point, I completely forgot about capturing! I presumed test_driver.click() is with pointerType == "mouse" but the documentation doesn't say anything! So it could be with "touch" and therefore subject to implicit capture. Let me file a bug for that.

mustaqahmed commented 4 days ago

Err, no, opposite. pointerup -> lostpointercapture (-> mouseup) -> click -> layout change. So, no pointer boundary events should be fired. (So, it seems that the current expectation of the test matches with current spec.)

Let me explain in a different way: both the test and the spec contradicts UIEvent for the simplest case that there is a mouse and no touch or pen (so there is no implicit capturing at all). When a click adds a <div> under the non-moving mouse pointer:

pointerevents/pointerevent_pointerout_no_pointer_movement.html expects no "pointerout" event at the <div> below, and this conforms to the PointerEvents spec, but
uievents/mouse/layout_change_should_fire_mouseover.html expects a "mouseover" event at the <div> above, and this conforms to the UIEvent spec.

I don't see how we can support both even when there is a single pointing device. In Chrome the latter is needed for a consistent hover behavior.

gsnedders commented 4 days ago

Good point, I completely forgot about capturing! I presumed test_driver.click() is with pointerType == "mouse" but the documentation doesn't say anything! So it could be with "touch" and therefore subject to implicit capture. Let me file a bug for that.

It should match the semantics of https://w3c.github.io/webdriver/#element-click, which I think ends up with https://w3c.github.io/webdriver/#dfn-default-pointer-parameters (i.e., mouse), though @jgraham might remember these parts of the spec better than me.

mustaqahmed commented 4 days ago

Thanks @gsnedders, I just re-posted your comment at https://github.com/web-platform-tests/wpt/issues/48158 (I am planning to send a testdriver PR there).