User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:34.0) Gecko/20100101 Firefox/34.0 Build ID: 20140916004001 Steps to reproduce: 1) Open a new tab page. 2) Drag the center website thumbnail around so that it's original position is taken by another thumbnail. 3) Release the thumbnail while the mouse is outside the firefox window. Actual results: When dragging a thumbnail, some additional thumbnails appear below the initial set. If a thumbnail is dragged such that it's original spot is covered, and the mouse is outside of the firefox window, then the thumbnail returns to its original spot underneath the thumbnail that has moved there. Expected results: The thumbnail should move to the empty position on the new tab page.
Status: UNCONFIRMED → NEW
Component: Untriaged → New Tab Page
Ever confirmed: true
I'm interested in working on this bug as part of the ascend project. My current understanding of this bug is the cell is not finding the hole it creates in the grid when I drag the cell out of the window. Ive found where the code lives through mozregression, I believe its the dropTargetShim.js file. I would start by reading the code line by line for understanding. Am I on the right track?
Hey Tim and Wes - wondering if you can make sure David's got someone to review his patch for this - he's been working on it for the past week and is close to a fix. Hopefully one of you could be a potential mentor here?
Tim's probably a better bet than I am.
This may be related to bug 1000097. From that bug, the underlying issue is that we put the new tab page into a "locked" state on drag, and we never get out of the locked state when dragging out of the browser.
I used the mozregession tool and this is what i got, I used nightly. 2013-07-24 = bad 2013-07-23 = good http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5ceea82a79c7&tochange=a4c1961bf723
This looks like a dupe of bug 948413? We can of course also dupe that to this bug here. David: Yes, dropTargetShim.js looks like the right file. I assume that when dragging something out of Firefox and dropping it there we somehow aren't notified of that and thus don't cancel the drag/drop operation.
We do receive the "dragend" event but no "drop".
The problem is that for the |dragend| event |aEvent.dataTransfer.mozUserCancelled| is false because from the d&d protocol point of view the d&d operation succeeded. From about:newtab's POV however dragging something outside the content area should cancel the operation. IIRC (we should check that) the "dragend" event is always sent before "drop". So maybe we should additionally check whether there was a drop event when receiving the dragend event to account for "implicit" cancellations?
(In reply to Tim Taubert [:ttaubert] from comment #11) > IIRC (we should check that) the "dragend" event is always sent before > "drop". So maybe we should additionally check whether there was a drop event > when receiving the dragend event to account for "implicit" cancellations? How would I check these events to find the order of them happening?
[Tracking Requested - why for this release]: Need to know if this should be fixed for 33.1 or not? There only a few days left for code changes to land and be tested.
status-firefox33: --- → affected
tracking-firefox33: --- → ?
For some context, this bug should fix bug 1000097, and both bugs were triggered by a new firefox 25 functionality from bug 894345.
I believe clarkbw meant to remove this from blocking the anniversary and move to followup work.
No longer blocks: 1075209
status-firefox33: affected → wontfix
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.