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

Status: RESOLVED WONTFIX

(Firefox :: New Tab Page, defect)

Description

[agustina.hinojosa]

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.

Comment 1

[Loic]

Attachment: newtab-ff35.jpg

Confirmed.

Comment 2

[David Hinojosa [:LMS]]

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?

Comment 3

[Lukas Blakk [:lsblakk] use ?needinfo]

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?

Comment 4

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Tim's probably a better bet than I am.

Comment 5

[Ed Lee :Mardak]

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.

Comment 6

[David Hinojosa [:LMS]]

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

Comment 7

[Ed Lee :Mardak]

Thanks, that would seem to point to bug 894345.

Comment 8

[Tim Taubert [:ttaubert] (inactive)]

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.

Comment 9

[Tim Taubert [:ttaubert] (inactive)]

We do receive the "dragend" event but no "drop".

Comment 11

[Tim Taubert [:ttaubert] (inactive)]

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?

Comment 12

[David Hinojosa [:LMS]]

(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?

Comment 13

[Tracy Walker [:tracy]]

[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.

Comment 14

[Ed Lee :Mardak]

For some context, this bug should fix bug 1000097, and both bugs were triggered by a new firefox 25 functionality from bug 894345.

Comment 15

[Ed Lee :Mardak]

I believe clarkbw meant to remove this from blocking the anniversary and move to followup work.