STR:
Open a new compose window.
Drag an image over it, "Add as Attachment" | "Append inline" overlay appears.
Drag image off, overlay disappears.
Repeat a few times until a the end, the overlay is permanent although the image has been dragged off.

Seen on Windows 10 with TB 87 beta 1.

Confirming on 88.0a1 (2021-02-28) (64-bit), thank you Klaus!

This is easily reproducible by dragging the image in and out of the drop area several times swiftly.
Needs an additional/different strategy for hiding the landing zone. Maybe mouseover check: if it's not drag, remove the landing zone. And probably something for keyboard, too. Or prevent this in the first place. Maybe caused by async race conditions, or logic flaw.

This is pretty inconvenient when it happens, as the landing zone overlay prevents any mouse interaction with the composition (keyboard works, good way of training yourself for keyboard-only... ;-).

The workaround is simple, but perhaps not easy to discover - just drag an image in and out again slowly until landing zone disappears.

I don't understand your priority/severity system, but this bug renders the Write window pretty much useless, at least visually. Imagine that happens after writing a long email and then trying to add attachments.

Trying to add a new attachment over the blocked message should remove the overlay again and you can work again with your message.

The offered workaround of starting another drag action isn't discoverable. Usually overlays or "full screen mode" can be dismissed by hitting escape, but that doesn't work here either.

I'm increasing the priority/severity level since indeed it's pretty disruptive.
The initial level is mostly due to the fact that this feature is only present in the beta.
I'll take care of this right away.

Very strange, it seems that I can't reproduce this on Linux.

Nevermind, I lied, I reproduced it.

This should fix everything.

• I removed the dragenter and dragexit from the overlay child elements.
• I'm handling the highlight of the drop bucket (attach/inline) from the parent's dragover event.
• I'm using a timeout to avoid the jarring on/off effect of the overlay when dragging over child elements (is this okay or there's a better method?).

I was planning to add a test to cover this and be sure the overlay is always hidden, but I'm not sure mochitest supports what I need to do (dragging a file from outside Thundebird).
Is this comment still relevant? https://searchfox.org/comm-central/rev/57a26c960bcb91a28575c96c44833b78b8393e20/mail/test/browser/composition/browser_attachment.js#926-927

I'm asking a ui-review to Richard since I changed some styling and to be sure the usage of pointer-events: none; doesn't create any issue.

Comment on attachment 9206194 [details] [diff] [review]
1695521-attachment-overlay.diff

Looks good and couldn't make the overlay stay when not dragging the file over it (before with multiple times dragging the file over and out it stayed sometimes).

The code comment seems obsolete. You should be able to simulate a drag in mochitest, something like this: https://searchfox.org/mozilla-central/rev/63fcc3f1a2cc73488d8986f4cf91fce2cd4b7564/toolkit/mozapps/extensions/test/browser/browser_dragdrop.js#227

Unfortunately I don't think I can remove the setTimeout as the dragenter and dragleave events fire non stop when passing over a child element of the overlay. Super annoying.

I implemented some subtle fade in and out transitions for the whole area and also added support for the reduced motion media query.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/d3a134270a55
Fix attachment overlay remaining visible after image is dragged out. r=mkmelin

Comment on attachment 9206775 [details] [diff] [review]
1695521-attachment-overlay.diff

[Approval Request Comment]
Regression caused by (bug #): bug 1640760
User impact if declined: the new attachment overlay remains if the drag and drop action is too fast, preventing the usage of the message compose.
Testing completed (on c-c, etc.): on c-c
Risk to taking this patch (and alternatives if risky): low.

Comment on attachment 9206775 [details] [diff] [review]
1695521-attachment-overlay.diff

[Triage Comment]
Approved for beta

Thunderbird 87.0b3:
https://hg.mozilla.org/releases/comm-beta/rev/1434f3f3e239