w3c/pointerevents

pointerout even if the pointer doesn't move?

Opened this issue · 11 comments

smaug---- commented

This is from https://bugzilla.mozilla.org/show_bug.cgi?id=1529904
Testcase https://jsbin.com/pevofukono/2/edit?html,css,js,console,output
Chrome fires pointerout even though mouse doesn't move

I think the spec is quite clear "The pointing device is moved out..."
https://w3c.github.io/pointerevents/#dfn-pointerout

patrickhlauke commented

Confirmed by @flackr that Safari behaves like Firefox

mustaqahmed commented

Copy-pasting my comment from the Interop sheet:

Testing challenge: very hard to write a non-flaky test. The pointerout has to be dispatched before next pointer event dispatch. This absence can't be asserted at pointerup because we need a follow-up event to assert the missing pointerout."

smaug---- commented

But we don't need a followup event, if we just check that pointerup doesn't occur before the next rAF.

This issue can be closed, but we need still a wpt.

egirard commented

The underlying specification states "The user agent MUST fire a pointer event named pointerout when [[...]] The user agent has detected a scenario to suppress a pointer event stream."

I think we can agree that the test as written should satisfy the clause "The user agent MUST suppress a pointer event stream when it detects that a pointer is unlikely to continue to produce events"

BUT this conflicts with the parent's specification: "it MUST not be fired until the pointing device has left the boundaries of the element and the boundaries of all of its descendants"

Perhaps we should add language to clarify this? Perhaps something like: "it MUST not be fired while the pointing device remains un-moved within the previous boundaries of the element and the boundaries of all of its descendants. Note that this boundary test should consider the position of elements at the time of the originating event."

mustaqahmed commented

@egirard and I just discussed this and agreed the first line of 4.1.3.3 is the source of the confusion here: "a pointer is unlikely to continue to produce events" currently carries the implied meaning that "a pointing device is getting disconnected/isolated from the current web-content", and the spec doesn't say it explicitly.

In particular, for the popup condition there the device is not even stopping to produce events!

I will file a new issue to track this.

mustaqahmed commented

I am reopening this because the conclusion here seems to contradict the related behavior in UIEvent spec!

UIEvents wants mouseover/out events w/o a movement so that hover effect is updated correctly after a layout change or scroll, see w3c/uievents#154. This contradicts the PointerEvent spec behavior and corresponding WPT we discussed here!

mustaqahmed commented

Here are the related WPTs (with conflicting results!):

smaug---- commented

Need to think about this. Pointerevent is a pointerevent, not a mouse event, and I think so far we haven't dispatched "synthetic" pointermoves.
The tests don't conflict, they just show different behavior for mouse events and pointer events. There are quite a few cases when pointer events and mouse events work differently.

@masayuki-nakano

mustaqahmed commented

https://w3c.github.io/uievents/#event-type-mouseover

... The tests don't conflict, they just show different behavior for mouse events and pointer events.

Thanks, that's correct: we are talking about two disjoint sets of events which have no 1:1 correspondence! Is it acceptable to decouple these two sets a bit further with the restriction "synthetic mousemove events are/maybe exposed, and synthetic pointermove events are never exposed"?

masayuki-nakano commented

Yeah, I don't think synthetic pointermove should be fired to dispatch pointer boundary events. As far as I've investigated, Blink/WebKit may have odd behavior for the synthetic mousemove events for mouse boundary events if the target is temporarily removed and reconnected. The approach of Pointer Events is much clearer for better compatibility.