Last Comment Bug 723121 - [New Tab Page] Dragging and clicking on a thumbnail freezes the thumbnail grid
: [New Tab Page] Dragging and clicking on a thumbnail freezes the thumbnail grid
Product: Firefox
Classification: Client Software
Component: Tabbed Browser (show other bugs)
: Trunk
: All All
-- normal (vote)
: Firefox 13
Assigned To: Tim Taubert [:ttaubert]
: Dão Gottwald [:dao]
Depends on:
  Show dependency treegraph
Reported: 2012-02-01 07:58 PST by Virgil Dicu [:virgil] [QA]
Modified: 2012-03-08 06:50 PST (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

patch v1 (1.07 KB, patch)
2012-02-09 05:40 PST, Tim Taubert [:ttaubert]
dietrich: review+
Details | Diff | Splinter Review

Description User image Virgil Dicu [:virgil] [QA] 2012-02-01 07:58:24 PST
Mozilla/5.0 (Windows NT 5.1; rv:13.0a1) Gecko/20120201 Firefox/13.0a1

Dragging and clicking a thumbnail while in drag operation makes the thumbnail grid freeze. No operation on thumbnails can be performed afterwards. 

Opening a new tab or hiding/showing the New Tab Page resolves the issue.


Initially, found aleatory while dragging a thumbnail. The thumbnail froze on screen, between cells. Couldn't reproduce afterwards. 

Howver, the reported problem above (drag and click while the thumbnail reaches the future position)can be reproduced always.
Comment 1 User image Tim Taubert [:ttaubert] 2012-02-02 02:40:14 PST
Thanks for finding this, I'll have a look at it. Can you please use or something similar to upload your screencasts to in the future? requires Windows Media Player which not all people have :) Thanks!
Comment 2 User image Virgil Dicu [:virgil] [QA] 2012-02-06 08:55:48 PST
Yes, I know what you mean. I don't have it either on Linux, but it came in handy while on Windows.

Occurs on all platforms. STR:

1. Drag the thumbnail.
2. Drop.
3. Quickly click and drag once again.
Comment 3 User image Tim Taubert [:ttaubert] 2012-02-09 05:40:50 PST
Created attachment 595710 [details] [diff] [review]
patch v1

Problem: when quickly dragging a tab after dropping it again it still fades into its target position and does not receive mouse events. So we receive a dragstart event for the underlying cell which we should just ignore.

Solution: ignore dragstart events when the event target :not(.site).
Comment 4 User image Dietrich Ayala (:dietrich) 2012-02-11 09:27:31 PST
Comment on attachment 595710 [details] [diff] [review]
patch v1

Review of attachment 595710 [details] [diff] [review]:

r=me with a test added
Comment 5 User image Tim Taubert [:ttaubert] 2012-02-20 14:41:30 PST
Phew, so the reason I didn't add a test in the first place was because I anticipated how hard writing a good test for this scenario would be. We have no real drag&drop test case in the code base because it's really hard to write one for code using the html5 dnd api. I'd have to not only fake mousedown/move/up events but also drag/start/end/over/enter/leave and drop.

Should we maybe ask for some help from the MozMill guys here? Not sure if they have better APIs for stuff like this...
Comment 6 User image Tim Taubert [:ttaubert] 2012-03-01 03:09:10 PST
Dietrich, how should we proceed with this?
Comment 7 User image Dietrich Ayala (:dietrich) 2012-03-01 07:43:19 PST
Neil, do you know how to best go about testing the new dnd api?
Comment 8 User image Neil Deakin 2012-03-01 07:55:00 PST
We do have some drag and drop tests. For example, the recently added editor/libeditor/base/test/test_dragdrop.html to test editor/textbox drag/drop, plus some browser specific drag tests in browser_drag.js. However there are many aspects of drag and drop that cannot be tested automatically, as the native apis control most of the operation.

But if you could describe what you need testing (where you would put ok/is calls for example), I can tell you if and how it could be done.
Comment 9 User image Tim Taubert [:ttaubert] 2012-03-08 03:58:45 PST
Comment 10 User image Rob Campbell [:rc] (:robcee) 2012-03-08 06:50:19 PST

Note You need to log in before you can comment on or make changes to this bug.