The default bug view has changed. See this FAQ.

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

NEW
Assigned to

Status

()

Firefox
New Tab Page
3 years ago
2 years ago

People

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

Tracking

(Blocks: 2 bugs)

34 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox33- wontfix)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
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

3 years ago
Created attachment 8490494 [details]
newtab-ff35.jpg

Confirmed.

Updated

3 years ago
Status: UNCONFIRMED → NEW
Component: Untriaged → New Tab Page
Ever confirmed: true
(Assignee)

Comment 2

3 years ago
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)

Comment 5

3 years ago
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
(Assignee)

Updated

3 years ago
OS: Mac OS X → All
Hardware: x86 → All
(Assignee)

Comment 6

3 years ago
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

3 years ago
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@mozilla.com
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?
(Assignee)

Comment 12

3 years ago
(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?
Blocks: 1075209
Blocks: 1050643
[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: --- → ?

Comment 14

2 years ago
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

2 years ago
I believe clarkbw meant to remove this from blocking the anniversary and move to followup work.
No longer blocks: 1075209
status-firefox33: affected → wontfix
tracking-firefox33: ? → -

Updated

2 years ago
See Also: → bug 1076257
You need to log in before you can comment on or make changes to this bug.