307184 - activating tabs (fast mouse movement) produces accidently dragging of tabs (drag and drop)

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Gero Mudersbach]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+

Using Firefox (Deer Park) under Linux (FC4, KDE) activating a tab and moving the
mouse to fast from the tab away results in dragging the tab. This does not
happen under Windows.

Reproducible: Always

Steps to Reproduce:
1. Open some tabs
2. Switch between the tabs with your mouse (try to do it fast)
3. While switching notice the dragging icon

Actual Results:  
Dragging the tabs

Expected Results:  
Switch tab

I really don't know what to do about it, because sometimes you would like to
switch tabs, sometimes drag them to reorder them. But on another OS (Windows)
this problem isn't there!

Comment 1

[Adam Guthrie]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050906 Firefox/1.6a1
ID:2005090619

I've been noticing this too. Happens when I'm switching tabs quickly like you
described.

Comment 2

[Simon Ruggier]

I can confirm this bug in GNOME, on FC2 running an old version of GNOME, later
today I might check if it happens in Ubuntu Breezy, which I have at home.

To clarify how to reproduce it, the sequence of events is as follows(in a split
second):

-mouse down on inactive tab
-cursor moves, activating a drag event
-mouse up
-tab activates

The key is that the mouse is released really quickly after clicking on the
inactive tab, but after dragging has been triggered.  The result is that the
mouse button is up, and the cursor remains in the state of dragging a tab around.

Comment 3

[Simon Ruggier]

I forgot to mention, I'm not running the trunk, I'm running 1.5b1.

Simon

Comment 4

[Adam Guthrie]

I noticed after switching back to Windows that the reason this doesn't seem to
occur on Windows is because we don't allow tab dragging unless the tab is
dragged outside of the tab region. We don't allow it to activate drag and drop
until it's moved enough to drop it; e.g. we put a crossed out "O". Maybe we can
implement this somehow on Linux?

Comment 5

[Darrel Yurychuk]

I've noticed that this also has something to do with how quickly the content on the tab comes up.  For example if the page loads immediately before you've had a chance to move the mouse, no problem.  However it shows up if you get a chance to move the mouse before the page finishes loading.  It's almost like the new tab drag functionality is checking just for the movement of the mouse rather than checking the movement of the mouse while the left mouse button is being pressed.

This bug occurs frequently enough for me to be a major annoyance however it is the only problem I have experienced so far with Firefox 1.5 on Linux.  Would this be a good candidate for a release blocker?  Otherwise 1.5 rocks, especially the speed/memory improvements under Linux and the SVG support.  Thank you all who contributed!

Comment 6

[Ilya Konstantinov]

Does anyone else experience the problem where, when this happens, Firefox refuses to release the dragged object and when you release the mouse button?

Comment 7

[Randy Wilson]

Using 1.5RC2 on Ubuntu Breezy, I do get into the situation where I can't get Firefox to release the drag object. The CPU utilization spikes to 100% and the mouse cursor remains in drag mode until the page finishes loading. I do agree with the previous comment about this happening more when the tab's content is slow to retrieve and display.

Comment 8

[Ilya Konstantinov]

This happens to me as well, but seems to have nothing to do with activating tab, as this CPU-intensive (and finite, although long) operation which hangs Firefox for its duration, can also be triggered by starting a drag of any object in Firefox, or by raising certain dialogs (alert dialogs and File Save dialogs come to mind)...

I've created bug 316247 to cover this problem. Whoever has this issue, please continue discussion there.

Comment 9

[Adam Guthrie]

*** Bug 317223 has been marked as a duplicate of this bug. ***

Comment 10

[:Gavin Sharp [email: [e-mail]]]

*** Bug 320264 has been marked as a duplicate of this bug. ***

Comment 11

[Jasper Bryant-Greene]

This is the single most annoying thing about Firefox 1.5 for me. I'm on Ubuntu Breezy and it happens to me at least once every 10 minutes or so during a browsing session. Either the drag start event shouldn't happen until the mouse leaves the tab with the button held down, or there should be a longer delay before the drag start event fires.

Comment 12

[Todd Whiteman]

The fixes found in bug 316247 (and subsequently bug 305970, which are both marked resolved) do not resolve this problem.

Comment 13

[Mike Connor [:mconnor]]

Seems to be related to GTK2 DnD code

ccing roc/caillon, (caillon apparently had a fix that rotted for this).  If we can't fix this in the GTK dnd code, we might have to just disable this on Linux.

Comment 14

[Todd Whiteman]

Just to clarify. This happens for all drag/drop objects, not just the tabs.

What I think is happening:
A mouse-down combined with a mouse move causes the start of the drag event (normal), which is dispatched to the DOM. If the mouse up occurs very shortly after (before the DOM has finished processing the drag event) then the drag event will remain even though the GTK mouse up event already occured. I think this is because the dom tells GTK that a drag event is occuring after the mouse up occured, so GTK then has no way of triggering the drop event (there will be no forthcoming mouse up which would normally trigger the GTK drop event, it occured before the GTK drag was started). Is this correct?

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It sounds plausible.

Comment 16

[Michael Wu [:mwu]]

I can reproduce this easily. Simply start dragging in another tab very slightly and let go while you're still in the tab box. 

Comment 17

[Robert Strong (they/them - no direct email)]

Possibly related to bug 269568? The GTK2 DnD code uses a GTK2 timer along with a nsITimer iirc. Under several circumstances I have found that the GTK2 timer isn't reset and continues to fire.

Comment 18

[Michael Wu [:mwu]]

Attachment: Cancel impossible drags

When we setup a drag, sometimes a button release event is already on its way. By the time we're done setting up, the button release has avoided the drag handlers which convert the button release to a drag leave.

This patch takes advantage of the fact that it is impossible to receive a button release event after a gtk_drag_begin (thus making drag motion events). If that occurs, we detect the problem and kill the drag from the drag motion event handler.

Comment 19

[Gero Mudersbach]

Michael, I tested your patch against the current cvs. It works, but we still have one problem here: When dragging starts, there appears a dragging icon and the mouse cursor changes. Since there is already the vertical arrow between the tabs it isn't really needed. Well, it's a gtk feature, but couldn't it be turned off? We don't have this on Win32, I think. The dragging icon and mouse cursor change just confuses here.

Comment 20

[Michael Wu [:mwu]]

(In reply to comment #19)
> Michael, I tested your patch against the current cvs.
Thanks for testing!

> It works, but we still
> have one problem here: When dragging starts, there appears a dragging icon and
> the mouse cursor changes. Since there is already the vertical arrow between the
> tabs it isn't really needed. Well, it's a gtk feature, but couldn't it be
> turned off? We don't have this on Win32, I think. The dragging icon and mouse
> cursor change just confuses here.
> 
That change would be beyond the scope of this patch and bug. Also, the tabs may be dragged to other locations to perform actions other than reordering tabs, in which case the cursor change makes sense. However, feel free to file a new bug if you think special casing DnD inside the tabbar to not have an icon is worth it.

Comment 21

[Gero Mudersbach]

Opened new bug #344230

Comment 22

[Mike Schroepfer]

Clearing the flag for blocking - if you get the patch reviewed, landed on the trunk, and no regression can you should nom the patch.

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 228653 [details] [diff] [review]
Cancel impossible drags

The code looks OK. Is this the only way to get GTK to notice that the button was released and it should exit the drag state?

Comment 24

[Michael Wu [:mwu]]

(In reply to comment #23)
> (From update of attachment 228653 [details] [diff] [review] [edit])
> The code looks OK. Is this the only way to get GTK to notice that the button
> was released and it should exit the drag state?
> 
GTK doesn't export any simple function to kill the current drag, so the next best thing was to create an event that would do it. I studied the gtk dnd code for a bit, and this appears to be the most direct thing possible. The race itself is nearly impossible to fix and I think ordinary GTK applications may have it too. However, they respond much much faster so races wouldn't happen.

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This could be fixed in GTK though, right? It probably should be. Mind filing a bug in bugzilla.gnome.org?

Comment 26

[Michael Wu [:mwu]]

(In reply to comment #25)
> This could be fixed in GTK though, right? It probably should be. Mind filing a
> bug in bugzilla.gnome.org?
> 

Here it is:
http://bugzilla.gnome.org/show_bug.cgi?id=347277

Comment 27

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Thanks.

Comment 28

[Michael Wu [:mwu]]

Patch checked in. We can remove this eventually if gtk+ fixes the problem on their side.

Comment 29

[Adam Guthrie]

*** Bug 317293 has been marked as a duplicate of this bug. ***

Comment 30

[Adam Guthrie]

*** Bug 314618 has been marked as a duplicate of this bug. ***

Comment 31

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

*** Bug 325533 has been marked as a duplicate of this bug. ***