Maybe this happens because no drag and drop specific events like dragstart are synthesized? I'm not familiar with D&D so if you have some feedback James, I would appreciate. The spec also doesn't mention any of those events, so I assume it's an implementation detail?

I assumed this would happen as a side effect of the other events, but perhaps not. It's definitely intended per-spec that this kind of event happens. I notice that EventUtils has a specific way of creating drag events [1]; I don't know how exactly we should know when to invoke that. Maybe smaug has some insight into how this stuff is implemented in gecko? In particular what's needed to ensure that these events are emitted at the same time they would be for real pointer inputs.

[1] https://searchfox.org/mozilla-central/source/testing/mochitest/tests/SimpleTest/EventUtils.js#2587

So what does Marionette do when drag operation is supposed to start?
Does it do something like mousedown, then some moves ?
https://searchfox.org/mozilla-central/rev/014fe72eaba26dcf6082fb9bbaf208f97a38594e/dom/events/EventStateManager.cpp#1900-1919

All the event related code can be found in https://searchfox.org/mozilla-central/source/testing/marionette/event.js.

Most of the methods are copied from EventUtils.js, but the last sync happened a long time ago. Maybe meanwhile new code has been added to (better) support D&D?

Anyway, lets see how it should work... The entry point for D&D activity via Marionette are clearly the actions, which are a sequence of mouse and keyboard events to synthesize. The code is here:

https://searchfox.org/mozilla-central/source/testing/marionette/action.js

The important methods here are:

• dispatchPointerDown
• dispatchPointerMove (performOnePointerMove)
• dispatchPointerUp

Each of the methods call into event.synthesizeMouseAtPoint().

Here how the equivalent method in EventUtils.js looks like:
https://searchfox.org/mozilla-central/rev/014fe72eaba26dcf6082fb9bbaf208f97a38594e/testing/mochitest/tests/SimpleTest/EventUtils.js#552

Olli, if you have an idea what's missing here I would appreciate. Otherwise what's the best way to investigate these missing DOM events? Is there a log option to turn DOM logging on?

I wonder if that might be related to what Andrew just found out on bug 1686361.

But which events exactly? And where? Does that pointermove end up triggering drag threshold?
The events can be logged simply by adding event listeners for those.

From the Selenium user perspective, this bug is one of the most filed issues, especially since it doesn't work on any browser right now.

Being able to point to a fix or an explanation of why this isn't working would be greatly appreciated. Thanks.

We should check again with the fixes as landed on bug 1838221 for the drag and drop test.

So I had a look with the updated tests and we are still failing. Reason is that we do not really send drag and drop events. Instead we assume that a "pointerMove" after a "pointerDown" is still just a mouse event. Instead we should keep the pressed state of the pointer input device and emit drag events in case a movement happens and the pointer is down.

Maybe it's something we can have a look at during our M9 milestone.