User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

1. Drag images and Drop them into an DIV-Element with "contenteditable"-attribute.
2. Change order of images in the DIV (D&D)

Actual results:

1. Only the first images appears. More Images will not be droped.
2. Ordering impossible. Dragged Image is always droped in first Position

Expected results:

Before v73 Firefox handled D&D correct as expected.
Tested on MacOS and Windows 8.5.

PS: no wondering: I downgraded my FF to version 72

Can you provide us with a test page/case that reproduces this issue so I can confirm it? Thanks!

I have uploaded an example to my private page:
https://www.toepferei-koerner.de/dragdroptest.html

Reproduces in nightly on Mac but not on 72. Looks like a regression.

I can reproduce the issue on Nightly75.0a1 Windows10.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=cae6a2e1838b522f7e940d41db2b61299f9e2b18&tochange=f2637cbcc2ca75be447689fd66baa0e5bfd07c66

I found a strange behavior after Bug 1597829.
If you click on the gray area before dragstart, you can drag and drop an image from the gray area to the green area even if after second time....

Must be fixed by the patch for bug 1616509.

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #7)

Must be fixed by the patch for bug 1616509.

Masayuki, this is this bug, can you provide the bug number where the patch lives? Thanks

Oops, bug 1616539. In my local tree, I cannot reproduce this bug.

I can confirm this problem is no longer reproduced on Latest Nightly75.0a1(20200225214332) Windows10.

Fixed range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7d59549f2fda3aed3927ab49b940d9024e161798&tochange=81f420f057e45d76c2ea5a9533588341154c92fb

Thank you! Alice-san!

Masayuki, bug 1616539 is a P3 and I had marked fix-optional for 74, but you marked this one as P1. Should we uplift bug 1616539 then? Is that risk-free or do you prefer to let it ride the 75 train. I am mostly concerned about stability and webcompat regressions we may introduce before RC week. Thanks.

(In reply to Pascal Chevrel:pascalc from comment #12)

Masayuki, bug 1616539 is a P3 and I had marked fix-optional for 74, but you marked this one as P1. Should we uplift bug 1616539 then? Is that risk-free or do you prefer to let it ride the 75 train. I am mostly concerned about stability and webcompat regressions we may introduce before RC week. Thanks.

I think we should uplift it because of a new regression, but I don't know how many web apps are broken by this regression and how much DnD in such web apps is important. So, if you're afraid about another regression, reject the uplift request (I'm verifying whether it's graftable cleanly or not).

I have reproduced this issue in Nightly v75.0a1 from 2020-02-24 and verified the fix in Nightly v76.0a1 from 2020-03-20 and Beta v75.0b6.
I have to mention that a different behavior was observable un Ubuntu 18, but the same expected result is seen on both OSes on fixed builds.