Closed Bug 1068354 Opened 6 years ago Closed 3 years ago

[new tab page] thumbnail is covered on return when dragged outside firefox window


(Firefox :: New Tab Page, defect)

34 Branch
Not set



Tracking Status
firefox33 - wontfix


(Reporter: agustina.hinojosa, Assigned: LMS, Mentored)




(1 file)

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.
Attached image newtab-ff35.jpg
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?
Assignee: nobody → thedavidhinojosa
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?
Flags: needinfo?(ttaubert)
Flags: needinfo?(kwierso)
Tim's probably a better bet than I am.
Flags: needinfo?(kwierso)
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.
Blocks: 1000097
OS: Mac OS X → All
Hardware: x86 → All
I used the mozregession tool and this is what i got, I used nightly.

2013-07-24 = bad
2013-07-23 = good
Thanks, that would seem to point to bug 894345.
Blocks: 894345
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.
Flags: needinfo?(ttaubert)
We do receive the "dragend" event but no "drop".
Mentor: ttaubert
Duplicate of this bug: 948413
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.
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
See Also: → 1076257
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.