The new UI handling drag and drop of attachments needs to be covered by tests due to its nature.
These are the things that should be covered by the test:

• Test if the overlay appears and disappears properly.
• Test if the "Add as attachment" and "Insert inline" bucket are properly shown and hidden based on the file type.
• Test is the file is properly handled based on the dropped target.
• Test that the Escape key always hides the attachment overlay.

Asking a little feedback here to see if I'm doing the right thing and if what I'm trying to do is possible.
I want to simulate the drag over movement of an external file above the compose editor and wait for the overlay to appear.

That doesn't seem to happen and I'm not sure what I'm doing wrong.

Comment on attachment 9207355 [details] [diff] [review]
1696489-attachment-test.diff

Did you succeed in swapping text/x-moz-url for application/x-moz-file (as seen here)?

No success unfortunately.
I tried different combinations and copied what m-c did in various other tests, but nothing seems to work. The overlay simply doesn't appear (but of course it does if I manually drag a file over the compose window while the test is running).
I'm a bit lost.

This escapes me as I can't understand why the drag action is not working properly.

I think it might be related to the fact that we're passing the same element as both source and destination to the EventUtils.synthesizeDragOver() method, like here: https://searchfox.org/mozilla-central/rev/eed391546532eeafb0c1d17de0610d6cc9e65ca6/toolkit/mozapps/extensions/test/browser/browser_dragdrop.js#137-138

But I'm not sure.
Any idea what I'm doing wrong?

Our code is bailing out here at isDataFlavorSupported which is in turn bailing out here, at least on Linux. I don't quite understand why.

On Mac it throws an exception in isDataFlavorSupported instead of returning false, but same effect. (I guess you knew that from the log, but there's no such log message on Linux, so I didn't.)

(In reply to Geoff Lankow (:darktrojan) from comment #5)

Our code is bailing out here at isDataFlavorSupported which is in turn bailing out here, at least on Linux. I don't quite understand why.

Removing the for loop and replacing it with a condition that check the event.dataTransfer.types instead of the dragSession makes the test work.
It doesn't seem to affect the functionality of the whole section, so I think we could replace it.
Any concerns about it?

I'll write the test to cover all the scenarios and also to be sure that dragging pills or elements within the editor doesn't create any unexpected results.

I think I did it.
Let's wait for this try-run https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=059ca3d5c0862eec1aabfae1f37c9d374d574ba0

The previous try run was mostly green, except for some tests which expected the pop account that is configured on the first test.
So, my new test shouldn't delete the default account on teardownModule.
New try run: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=c5bbe936098dd855e87e519d6662c3203ef3f0ea

I wasn't having any luck with artifact builds.
This one looks good: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=4b7537c06e11c4b586166f38daf4795bbceef0ab

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/745fc0139eff
Implement tests to cover the new attachment Drag and Drop workflow in the compose window. r=darktrojan