(Sorry to butt in here, I don't know the culture of the Phabricator project and maybe it's considered impolite to post diff comments as a stranger. I apologise if that's the case.)

This looks good to me. The only thing is that on "weird" devices with touch and a mouse, I think this code would disable the mouse hover highlighting until the next mouse click following a touch. It'd go like this:

1. A touchstart event activates "touch mode" for all coming events.
2. More than 1 occurrence of mousedown, mouseup or click is required to deactivate "touch mode".
3. ...but no such event will arrive if we have a "content change aborts touch event" situation. In this cases the last event we'll see is a mouseover event.
4. ...and even if we don't, only 1 of each event will arrive for a single touch.

So the flag won't be reset until the user clicks somewhere. Which is probably okay, just technically a minor bug.

I think you're right about the other case, but I don't think we can easily accommodate it without either encoding more information about how devices work or tracking more information about event handling. The complexity in either case doesn't seem worthwhile to me, although maybe devices which support both input methods are more widespread than I believe (is it common to use Surface tablets with mice?)

The advantages of the current approach are:

• it's relatively simple;
• it will work regardless of the order devices fire the events in: one browser doing "touchstart, touchend, mousedown, click, mouseup" and another doing "touchstart, mousedown, click, mouseup, touchend" will work. From briefly googling, it seems like there's a lot of diversity in what browsers do;
• it will work regardless of which events fire: if some events do not fire (because an earlier event was killed by the application, or a user aborted the touch by tapping more fingers) we'll get back to the right state on the next event.

We could make it more complex (track aborted events, track 'touchcancel') or possibly encode more user agent behavior, but the specific case of "hover doesn't work between the time you touch the screen and the next time you click, if you're using a device with both touch-device and mouse-device cursor input methods" doesn't seem worth the effort -- at least right now, when we have no knowledge of any users with such devices.

(The whole approach is also probably garbage for multi-touch inputs, but that's a whole separate can of worms.)

In D15136#173568, @epriestley wrote:

... the specific case of "hover doesn't work between the time you touch the screen and the next time you click, if you're using a device with both touch-device and mouse-device cursor input methods" doesn't seem worth the effort -- at least right now, when we have no knowledge of any users with such devices.

Yeah this sounds like a classic issue to postpone until someone actually cares.

(Although for that day, a simple setTimeout to clear the flag after 1 s will probably do the trick. The delay needs to be "somewhat longer" than 300 ms due to the delay between touch and simulated events, and we can't know exactly how much longer "somewhat" is since that depends on the device. At the same time 1 s is short enough that it'd be quite difficult for a user to switch between touch and mouse interaction so fast that they'd ever notice the workaround.)

Like you said, it doesn't matter. The above will do the job and it's definitely nice not to have to make assumptions about the event ordering.

Yeah, I think that's a pretty reasonable approach to try should we encounter touchey-mouse devices in the wild.