mousemove_prevent_default_action.tentative.html checks the event sequence of mousemove and dragstart events

[EdgarChen]

Test List

https://wpt.fyi/results/uievents/mouse/mousemove_prevent_default_action.tentative.html?label=master&label=experimental&aligned

Rationale

This test was added for w3c/uievents#278. There are discussions on whether calling preventDefault on mousemove should prevent selectionchange. And we all agreed that it should not. The issue didn't mention drag operation, but if the mousemove event can not be canceled, I think it makes sense that the principle should apply to drag operation (?).

However, this test also tests the sequence of mousemove and dragstart events. It expects the mousemove event fired first then dragstart event, but in Gecko, we dispatch dragstart event first then mousemove event. I don't think spec has clear definition about the timing of firing the dragstart event. Therefore, I think the ordering-check is beyond the intent of this test. WDYT?

[nairnandu]

@flackr could you review this proposal for Chromium?
@gsnedders / @nt1m could you review this proposal for WebKit?

[gsnedders]

HTML seems to define:

This specification does not define exactly what a drag-and-drop operation actually is.

On a visual medium with a pointing device, a drag operation could be the default action of a mousedown event that is followed by a series of mousemove events, and the drop could be triggered by the mouse being released.

i.e., it leaves this explicitly undefined, therefore the test seems to be testing more than is specified.

It might be worth having an issue open on the spec to track the question of "do we want to want to define this or leave this down to individual implementations", but aside from that, avoiding asserting things the spec doesn't require is good.

[nt1m]

@flackr / @mustaqahmed / @foolip Can you provide feedback from Chromium?

[mustaqahmed]

The order dependency in the WPT is clearly not intended in the spec, thanks @EdgarChen for the catch. Not logging mousemove events (while keeping mousemove canceling intact) seems to be best fix here for both dragstart and selectionchange.

The test is tentative because of: w3c/uievents#278

[nt1m]

@EdgarChen Can you send a PR with the test changes? Thanks everyone for weighting in!