The sub-test dragstart event firing when mousemove event is prevented fails.

The test expects:

1. mousemove
2. mousedown
3. mousemove
4. dragstart

If I make it log pointermove too, the result in Gecko becomes:

1. pointermove
2. mousemove
3. mousedown
4. dragstart
5. mousemove

If I move these lines from EventStateManager::PreHandleEvent to EventStateManager::PostHandleEvent, I got:

1. pointermove
2. mousemove
3. mousedown
4. pointermove
5. dragstart
6. mousemove

I'm not sure why we don't get pointermove within current build (I guess, 4.1.3.3 Suppressing a pointer event stream?), but after the patched build, obviously we start the drag with pointermove event.

We started to start a drag session with pointermove from bug 967796 (changeset). It's very early stage of our Pointer Events implementation, and I don't see any reasons that we should start a drag session before mousemove.

So, if I make EventStateManager::PostHandleEvent calls GenerateDragGesture() only when eMouseMove, the test passes.

(FYI: It seems that doing it breaks some DnD test APIs...)

Edgar, WDYT? Should we follow the test's expectation? (I'm not sure exactly when the other browsers start to handle a drag because (perhaps) it's impossible to observe it with manual testing and according to current results, they don't support DnD with testdiver (no dragstart).)

I also wonder if this .tentative.html is included in the interop dashboard on purpose or accidentally.

This test was added for https://github.com/w3c/uievents/issues/278 and the issue is listed in the investigation list. So I think it is intentionally included in the dashboard. However, it also tests the sequence of mousemove and dragstart events, I don't think it is defined in the spec explicitly and also is beyond the intent of this test. I filed https://github.com/web-platform-tests/interop/issues/396 to clarify.

Thank you!