Mouse and Pointer events from a stationary mouse

[mustaqahmed]

Forking off from #457 to highlight my question there:

If the mouse is held stationary, do we expect to see CSS hover effect and pointer/mouse events after a touch/wheel scroll ends?

There are important differences between major browsers here:

• Repro for top frame:

  • After a short delay, Chrome fires pointer/mouse over/out events and no move event, and shows hover effect.
  • After a short delay, Firefox fires mouseover/out events only, and shows hover effect.
  • Safari fires no events, and shows hover effect. EDIT: Safari fires pointer/mouse move/over/out events, and shows hover effect.

• Repro for sub-frame:

  • Chrome fires no events, and shows no hover effect.
  • After a short delay, Firefox fires mouseover/out events only, and shows hover effect.
  • [TODO]: need to check. EDIT: Safari fires pointer/mouse move/over/out events, and shows hover effect.

I think it is important to fire some events to let the developers know when the hover-effect is shown, and in that case both pointer and mouse over/out events need to be fired for consistency between these two classes of events, like what Chrome does. But to be frank, I got confused upon discovering Chrome's subframe behavior above!

---

The PointerEvents spec expects no event in this case, but the UIEvent spec expects mouse events!

Related WPTs: pointerevents/pointerevent_pointerout_no_pointer_movement.html and uievents/mouse/layout_change_should_fire_mouseover.html

[mustaqahmed]

FYI: @flackr @smaug---- @masayuki-nakano

[flackr]

There are important differences between major browsers here:

• Repro for top frame:

  • After a short delay, Chrome fires pointer/mouse over/out events and no move event, and shows hover effect.
  • After a short delay, Firefox fires mouseover/out events only, and shows hover effect.
  • Safari fires no events, and shows hover effect.

When I tested this, safari fired pout mout pover mover pmove mmove in addition to the hover effect.

• Repro for sub-frame:

  • Chrome fires no events, and shows no hover effect.
  • After a short delay, Firefox fires mouseover/out events only, and shows hover effect.
  • [TODO]: need to check.

I get the same result as the first case here.

[mustaqahmed]

I have edited my original post above based on @flackr's observation above.

[masayuki-nakano]

Firefox just follows the Pointer Events spec. I mean Firefox can synthesize pointer boundary events too after scroll with a tiny change.

[mustaqahmed]

Thanks @masayuki-nakano, that will definitely be helpful for Interop.

Let me slice our observations above into 5 Interop questions, only two of which seem to need attention now:

1. Hover effect: Chrome, Firefox and Safari.
2. mouse{over,out} events: Chrome, Firefox and Safari.
3. pointer{over,out} events: Chrome and Safari.
4. {mouse,pointer}move events: Safari only.
5. Sub-frames behaving differently: Chrome only.

We still need to discuss 4-5.

[flackr]

We still need to discuss 4-5.

I think point 5 is just a bug, do you think there's any reason it should behave differently?

For point 4, I think it would be better not to dispatch move events if the pointer hasn't physically moved. This to me feels like it more directly reflects what has happened - the pointer hasn't moved but it is over a new element.

If we dispatched move events, then I would expect that you'd see move events even if the element that it's over didn't change.

[masayuki-nakano]

How about the cases when the element underneath the pointer is changed by mutation or style changes? That was tested in some WPT as not causes pointer boundary events. I think that it's hard to change the behavior only for scroll because after enqueuing the boundary events at scroll, the element underneath the point may be changed by mutation or something. So, only in the case, boundary event target computation is affected by the mutation or something other than scroll.

[mustaqahmed]

Today the PEWG reached the consensus that the PointerEvents spec should match the UIEvent spec behavior for non-moving pointing device: the boundary events should fire after a layout change, and no move events should fire. (For reference, the UIEvent spec mentions changes "underneath the primary pointing device" for each boundary event.)

[flackr]

the boundary events should fire after a layout change

I think an important caveat here is not with any expected timing, right? E.g. similar to scrolling and hover effects it can be delayed, not requiring frame-by-frame hit testing and boundary event updates. This should help mitigate the performance cost.

[masayuki-nakano]

the boundary events should fire after a layout change

I think an important caveat here is not with any expected timing, right? E.g. similar to scrolling and hover effects it can be delayed, not requiring frame-by-frame hit testing and boundary event updates. This should help mitigate the performance cost.

I agree with that. Firefox tries to do that at next vsync for both performance and security. Dispatching boundary events synchronously at every layout change would makes things complicated because the listeners may change the layout again.