After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 635485 - Doesn't always focus tab on drag hover
Doesn't always focus tab on drag hover
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: Tabs
2.32.x
Other Linux
: Normal minor
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on: 684415
Blocks:
 
 
Reported: 2010-11-22 04:04 UTC by Oliver Joos
Modified: 2012-10-22 22:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
window-slot-dnd: handle tab switching on hover ourselves (3.51 KB, patch)
2012-09-20 01:27 UTC, Cosimo Cecchi
committed Details | Review

Description Oliver Joos 2010-11-22 04:04:52 UTC
When I use drag&drop between tabs in a Nautilus window, the target tab sometimes does not pop to foreground although the mouse pointer is exactly over it. It seems that the tab is switched only if the mouse pointer is long enough over the pixels *around* the tab name. So if I move the mouse slowly from one tab name to the other then it mostly works as expected. But if I move quickly and stop over the tab name (a black rectangle is drawn around the name), then it does not work, and I have to leave and enter the tab slower again.

I checked out Ubuntu Lucid and Maverick (nautilus 2.30 and 2.32) and Fedora 14 (nautilus 2.32) - all these are affected.
Comment 1 William Jon McCann 2012-09-18 18:42:35 UTC
I see a slightly different behavior. It seems to switch tabs on hover fine except in the case where it was about to switch to a different tab.

1. Drag item from tab 1 to tab 2's label
2. After a moment, quickly drag same item over tab 3's label

What will happen is that tab 2 will pop forward even though you are over tab 3.
Comment 2 Oliver Joos 2012-09-18 23:01:36 UTC
@William: Do you use Nautilus 2.32 or 3.x? Anyway I think you see the very same effect: if the mouse pointer moves quickly enough from outside of a tab (tab 3 in your case) onto its label text then this tab will not be focused. Perhaps the label widget ignores mousemove events...

BTW: Meanwhile I use Ubuntu Natty (with nautilus 2.32.2.1) and Linux Mint 13 (with caja 1.2.1) - both are still affected.
Comment 3 Cosimo Cecchi 2012-09-20 01:27:35 UTC
This is mostly a GtkNotebook bug, combined with the (questionable) use we make of tab labels.

I filed https://bugzilla.gnome.org/show_bug.cgi?id=684415 for the GTK side of the bug, but Nautilus will need to be patched as well, to handle tab switching manually.
Comment 4 Cosimo Cecchi 2012-09-20 01:27:57 UTC
Created attachment 224797 [details] [review]
window-slot-dnd: handle tab switching on hover ourselves

Since we handle envets manually.
Comment 5 Oliver Joos 2012-09-20 08:56:39 UTC
Thank you Cosimo! Your patches definitely look like a fix for this bug.

The patches are for Gnome 3.x, aren't they? I'd be glad to help porting them to Nautilus forks like Caja or Nemo.
Comment 6 Cosimo Cecchi 2012-09-20 19:42:40 UTC
(In reply to comment #5)

> The patches are for Gnome 3.x, aren't they? I'd be glad to help porting them to
> Nautilus forks like Caja or Nemo.

Patches are for git master of GTK+ and Nautilus.
Comment 7 Cosimo Cecchi 2012-10-22 22:46:53 UTC
Attachment 224797 [details] pushed as 7a0001d - window-slot-dnd: handle tab switching on hover ourselves

Pushed now that the GTK patches have been committed.