A single tap or a long press may cause compatibility mouse events,
`mousemove`, `mousedown`, `mouseup`, then, `click` unless the target
is changed during the sequence. Currently, we synthesize a mouse move
event after a layout change or a scroll to dispatch mouse boundary
events and update the `:hover` state. However, if the last mouse event
is caused by a touch which does not support `:hover` state, it's odd
to treat the new target as hovered.
This patch prevents the synthesized mouse moves if the last mouse event
is caused by a pointing device which does not support hover state unless
the button state is active (e.g., the layout change at `mousedown` of
a single tap should cause mouse boundary events before the following
`mouseup`).
I think that the compatibility `mouseup` event should reset the
`:hover` state and dispatch mouse boundary events like `pointerup`.
However, Chrome does not do that. Therefore, we should align the
behavior to Chrome for the compatibility.
Differential Revision: https://phabricator.services.mozilla.com/D309800
Masayuki Nakano
8461aba084