1452131 - Drag and drop events get into broken state

Status: VERIFIED FIXED

(Core :: DOM: Copy & Paste and Drag & Drop, defect, P1)

Description

[jonathansteel128]

Attachment: firefox_bug.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce:

Start dragging and item and release the drag before the drag preview appears.

Using the sample file I have uploaded, you can reproduce the issue by dragging the item and releasing the drag within 1 second. If you drag for longer then a second, it will do a normal drag.


Actual results:

All drag events will no longer call their registered event handlers. This effect will persist across multiple tabs. If you have two of the example open, then breaking the one will instantly break the other. The only way I have found to get out of this state is to either restart Firefox, or move the chess piece on this page: https://react-dnd.github.io/react-dnd/examples-chessboard-tutorial-app.html. If you move the piece, a dragend event will fire on the broken tab, and it will start working again.


Expected results:

It should have just dragged like normal.

Comment 1

[Cristina Badescu [:cbadescu], Experiments QA]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180411100123

Hello,

I have managed to reproduce this issue on latest Firefox release 59.0.2, latest Nightly build 61.0.a1 using Mac 10.13.3 and Windows 7 x64.
This issue doesn't seem to be a regression since I've managed to reproduce it on older Nightly versions, such as 55.0a1 (Build ID: 20170306150342.
This issue is not reproducible on Windows 10 x64.

I have accessed the provided example, succeeded to drag once and I can see in the browser console some events (dragover, drop, dragend), but at the second attempt, I could no longer drag and drop the div and no events appeared in the console.

Just to be sure, is this the issue that you are encountering?
Thanks.

Comment 2

[jonathansteel128]

Hi Cristina,

That does sound correct. For further reference, here is a bug I originally filed related to this that has a video showing the problem: https://github.com/react-dnd/react-dnd/issues/1000.

We are having similar issues that only crop up post version 57, but this is the first one I've been able to isolate. Hopefully if it gets fixed, I can isolate the other issues which may actually be regressions.

Thanks,
Jonathan

Comment 3

[Cristina Badescu [:cbadescu], Experiments QA]

Thanks for answering. I am assigning a component to this issue in order to involve the development team and get an opinion on this.

Comment 4

[Renaud Chaput]

Any news on this?

Comment 5

[dgee]

Any update on this? This is a fairly critical issue for any web application that utilizes drag and drop and as far as I can tell, there is no workaround.

Comment 6

[Hector Romero]

Is there any progress with this bug? It breaks a critical part of our application, we cannot release it unless this bug is solved.

Comment 7

[Neil Deakin]

Attachment: Properly end the drag session when the drag is aborted

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a1e3bbe5ad0a
properly end the drag session when the drag is aborted, for example if the mouse is released before the child process starts the drag, r=nika

Comment 9

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/a1e3bbe5ad0a

Comment 10

[Renaud Chaput]

Would it be possible to backport this fix to ESR?
It breaks drag & drop in many cases and renders the tab unusable until its closed.

Comment 11

[Julien Cristau [:jcristau]]

ni? Neil regarding comment 10.

Comment 12

[Neil Deakin]

Comment on attachment 8993329 [details] [diff] [review]
Properly end the drag session when the drag is aborted

Not sure if the bug can go to ESR; this bug has existed for a while, but it makes the UI state unresponsive.

Approval Request Comment
[Feature/Bug causing the regression]: probably 1216916
[User impact if declined]: fixes an issue when stopping a drag too quickly can make the UI unresponsive  
[Is this code covered by automated tests?]: no, dragging cannot be testing automatically
[Has the fix been verified in Nightly?]: yes
[Needs manual test from QE? If yes, steps to reproduce]: testcase attached to bug
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: no
[Why is the change risky/not risky?]:
[String changes made/needed]: none

Comment 14

[juraj.masiar]

Is the fix merged? Because I just tested 63.0a1 (2018-08-07) (64-bit) and my duplicate bug is still present https://bugzilla.mozilla.org/show_bug.cgi?id=1481034

Comment 15

[Julien Cristau [:jcristau]]

Yes, it is in nightly since August 3rd.

Comment 16

[Liz Henry (:lizzard) (relman/hg->git project)]

Renuad, Hector, dgee, jonathan:  Are any of you able to verify that this is fixed in Nightly?

Comment 17

[Hector Romero]

I still see the same behavior in nightly.
This is running on macOS high sierra.

It is worth mentioning though that the behavior I see is a bit different.
For me, when I drag my element the dragStart event is fired, but I never get the ghost element and my cursor remains the same. When I let go of my right click the dragEnd or drop events are never fired.

Comment 18

[jonathansteel128]

Confirmed that the issues no longer happen on build 63 for me on macOS 10.13.6. Thanks for getting this fixed.

Comment 19

[Liz Henry (:lizzard) (relman/hg->git project)]

Neil, given the comments above it may be worth digging into this some more before uplift. What do you think?

Comment 20

[Neil Deakin]

I'll look at this and bug 1481034 a bit more.

Comment 21

[Daniel Bodea [:danibodea]]

Hi Jonathan,

I cannot confirm the fix in Nightly (v63.0a1 2018-08-10) on Windows 7 and Mac OS X 10.13.6.
Maybe I do not understand the actual and expected results.

What I understand is that the "dragenter", "dragover", "dragleave" and drop events are not being displayed after abusing the drag and drop action. This issue still occurs on the these 2 OSes, while it doesn't on Windows 10.

Can you tell me exactly how you verified the fix on your system?

Thank yuor for your contribution!

Comment 22

[jonathansteel128]

I have confirmed again on 63.0a1 (2018-08-16) (64-bit) using Mac OS X 10.13.6.

I'm not so much concerned about losing a few drag events as with the browser getting into a state where it loses all drag events. I can confirm the it is working using the firefox_bug.html I originally attached and following the instructions. I can also test it using just about any page that has drag and drop. Sometimes the page may get into a state on the nightly where it seems to have missed an even, but subsequent events then work.

The current behaviour is that once it misses the one event, all your tabs will now miss all events.

You can see a video of the old behaviour at https://github.com/react-dnd/react-dnd/issues/1000. I can use that as an example with nightly. I can get it into the state where the chess board squares are highlighted after I release my click, meaning it missed the drop event. But as soon as I start dragging again, everything is back to normal.

Let me know if I can help further.

Jonathan

Comment 23

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8993329 [details] [diff] [review]
Properly end the drag session when the drag is aborted

It sounds like this improves the drag and drop behavior for some but not all reported cases. That seems worth uplift. Let's bring it to beta 19.

Comment 24

[Raul Gurzau (:RaulG)]

https://hg.mozilla.org/releases/mozilla-beta/rev/13ded90ac628

Comment 25

[Daniel Bodea [:danibodea]]

I have performed another session of testing and these are my results:

A. I have attempted to reproduce the issue on Nightly build v63.0a1 from 2018-04-01:
   1. On the chess example (https://react-dnd.github.io/react-dnd/examples-chessboard-tutorial-app.html):
I could not reproduce the issue seen in the video (https://github.com/react-dnd/react-dnd/files/1881731/ReactDnDFirefoxBug.zip) and no "dragenter", "dragover", "dragleave" and "drop" events would be seen in the Web Console at all. Results inconclusive.
   2. On the originally attached test case (https://bugzilla.mozilla.org/attachment.cgi?id=8965747):
I could reproduce the following: the UI would get stuck after the first or first few drags (the UI/UX of the whole process is very confusing as the draggable is hard to catch); 
Conclusion: The UI gets stuck and no events can be triggered as a cause.

B. I have attempted to verify the fix on Nighly build v63.0a1 from 2018-08-23:
   1. On the chess example (https://react-dnd.github.io/react-dnd/examples-chessboard-tutorial-app.html):
I could still not reproduce the issue seen in the video and still no "dragenter", "dragover", "dragleave" and "drop" events would be seen in the Web Console at all. Results inconclusive.
   2. On the originally attached test case (https://bugzilla.mozilla.org/attachment.cgi?id=8965747):
I could see the following: The UI would NOT get stuck after performing some drag actions, BUT the UI/UX had a bad stutter to it.
Conclusion: The issue appears to be fixed, but another issue is now visible.

Furthermore, I have done the same in the case of the Beta build and the results were the same as in the case of the Beta build.

Considering all the above, I will mark this issue as verified in firefox63 and firefox62, but I would log another issue for the stutter observed.

Nell Deakin, jonathansteel128, Do you think I should log a new bug for the stutter issue?

Thank you!

Comment 26

[jonathansteel128]

While the stutter is not perfect, it doesn't really affect what the user is trying to do. I think a new bug might be appropriate as the new issue is much lower priority than this one.

Thanks,
Jonathan

Comment 27

[Brindusa Tot, Desktop QA]

Are there any plans for this bug to be uplifted to ESR60?

Comment 28

[Liz Henry (:lizzard) (relman/hg->git project)]

That's a hard call -- we are now at the point where we want to start limiting ESR60 fixes to security and stability issues. If drag and drop were completely broken in ESR60, we could consider uplift, but this seems more like an edge case.

Comment 29

[Brindusa Tot, Desktop QA]

Based on the previous comment, removing the qe-verify+ flag.

Comment 30

[Victor]

I am fairly sure either I miss something or the fix is incomplete.

Test the following, if possible, please:

1. Visit http://react-dnd.github.io/react-dnd/examples/sortable/simple
2. Pick an element (not the first nor the last one though), and drag it outside to the right (into the empty space adjacent to the "list" thing).
3. Try to "wedge" it with the mouse into between any other two elements than those it was originally removed from amongst.

In Chrome, it works flawlessly (i.e. I can "insert" it any times wherever I like).
In Firefox (Quantum; 65.0.1; Linux amd64), however, it breaks on EXACTLY the third attempt (e.g. it becomes completely static; no further "drop" is possible; but no error or warning messages in the console whatsoever).

Alternatively, you may also try to move up and down the items, as in "ordinary" use.
It is just that with "my method", it always breaks on the third attempt, while in "regular sorting", it is somewhat stochastic as of when it loses traction (sometimes after passing by just two elements - especially if one is the first or last - but at other times, it may take 8-10 "position changes" before it "sinks").

It does break though all the time, sooner or even more sooner.

Comment 31

[Victor]

From other sources, it is somewhat apparent that only Linux is affected.

Comment 32

[Daniel Bodea [:danibodea]]

I think the issue in the last 2 comments should be logged separately. Jonathan, can you confirm?

Comment 33

[Victor]

The issue is seemingly also happening only if redrawing is requested "in the main thread".
When wrapping the redrawing in requestAnimationFrame(), this works as expected.

Comment 34

[Sebastian]

This bug is still happening for me in v69 both on Fedora 30 (latest updates) and on Windows 10. I can reproduce it with most examples at https://react-dnd.github.io/react-dnd/examples

Comment 35

[juraj.masiar]

It also affects "Responsive Design Mode" in the Developer Tools. If you activate it, each drag and drop attempt will stuck it completely (even after you close it). You can test this using the link above or almost any other drag-and-drop powered page.

Comment 36

[Daniel Bodea [:danibodea]]

Victor, Sebastian and Juraj, considering that this bug has been verified using certain steps to reproduce, please log your issues separately.

Thank you for your contributions!

Comment 37

[Sebastian]

Seperate issue filed here https://bugzilla.mozilla.org/show_bug.cgi?id=1582401 - I actually cloned this issue since there seems to have been a regression / the issue is still very much the same as in this ticket.

Comment 38

[Victor]

One thing that is certain with me that Jonathan's original test case (attached) does not work for me with Quantum, 69.0, 64 bit on Linux (Debian Buster).

If I start dragging then release within 1 second, the div (the "text") gets stuck to the cursor, and to "drop" it, I have to click any of the drop targets.

(At least now an onDrop event is generated seemingly; before, the only way to get out of the situation was to reload the page or so IIRC.)

I suggest that whoever verifies such issues being fixed states the platform explicitly as well.

Comment 39

[juraj.masiar]

"Responsive Design Mode" drag issue reported here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1582708