pointerevents/pointerevent_pointerout_no_pointer_movement.html contradicts UIEvents spec and WPT

[mustaqahmed]

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]

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

[masayuki-nakano]

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]

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]

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]

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]

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

[smaug----]

Why was the test removed from interop without agreement? We should add it back, since it follows the spec.

[mustaqahmed]

Let me explain: I wouldn't have included this test in the original 2024 proposal if I was unaware of the two conflicting WPTs mentioned above in #695 (comment). It felt odd that Interop 2024 was essentially emphasizing only the newer of the two related WPTs, and that Q3 was too late to propose adding the older. You are correct that I was too quick to removed it from Interop but the WPT is still there to support the PointerEvent spec, right?

Anyway, we can open a PointerEvent spec issue to discuss the conflict, or add it back to Interop 2024, or do both. Let me know which one you would prefer.

[smaug----]

I'd prefer to add the test back, since it follows the specs. Pointer events (IIRC, but I might misremember and I don't have now a link to any discussion) on purpose doesn't have the weird behavior mouse events have.