Closed Bug 1452131 Opened 2 years ago Closed 2 years ago
Drag and drop events get into broken state
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.
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.
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
Thanks for answering. I am assigning a component to this issue in order to involve the development team and get an opinion on this.
Any news on this?
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.
Is there any progress with this bug? It breaks a critical part of our application, we cannot release it unless this bug is solved.
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Attachment #8993329 - Flags: review?(nika)
Attachment #8993329 - Flags: review?(nika) → review+
Pushed by email@example.com: 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
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.
ni? Neil regarding comment 10.
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
Attachment #8993329 - Flags: approval-mozilla-beta?
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
Yes, it is in nightly since August 3rd.
Renuad, Hector, dgee, jonathan: Are any of you able to verify that this is fixed in Nightly?
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.
Confirmed that the issues no longer happen on build 63 for me on macOS 10.13.6. Thanks for getting this fixed.
Neil, given the comments above it may be worth digging into this some more before uplift. What do you think?
I'll look at this and bug 1481034 a bit more.
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!
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 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.
Attachment #8993329 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
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!
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
Are there any plans for this bug to be uplifted to ESR60?
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.
Based on the previous comment, removing the qe-verify+ flag.
You need to log in before you can comment on or make changes to this bug.