I often accidentaly detach a tab, because my machine gets very slow at the time I click to switch tab (probably because it needs to unswap this tab from my sleeping and slow laptop harddrive...)

This is a critical bug - it's annoying as hell after a while

I'm not sure why undocking by dragging tab's needs to be a feature, it's one of those rare things that could be done via a menu. perhaps keep re-ordering/drag to another terminal, but disable detaching.

please,please,please fix it..

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

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

-> gtk

What's the status of this bug? It annoys me on a daily basis - i'm regularly working on two machines at the same time and flicking between tabs - they keep getting detached!

This is really annoying. I agree it should not be possible to detach a tab via drag and drop.

The feature is useful - it needs fixing not removing. That being said though, the current situation is aggravating. A gconf configurable delay or minimum mouse movement pixel count would be good.

Agreed, there should be a delay and importantly the ability to switch it off completely as lagged mouse actions seem to be annoying some people - i'd quite like an actual response from devs on this?

It's good idea to fix it. Delay configuration should be placed in control panel - in mouse settings.

I think that this feature needs no delays, no minimal movements, but only an implementation fix: Clicking to tab, release the button and quicky moving the mouse pointer away must never detach the tab.

Mouse position must not be evaluated in time when the callback is executed, but it must use mouse position from the moment, when mouse button was released.

I'd also like to confirm this bug.  I work almost exclusively with gnome-terminal and several times a day, a tab gets detached (usually during some critical moment) simply by switching to another tab.

For example, I click onto another tab and immediately after doing so, the tab detaches itself and becomes its own window.  I do not have any tab detaching hot keys defined nor did I click on "detach tab". 

I cannot repro this bug on demand and I don't know what causes it. 

I'm glad I'm not the only one with this problem. Yes, its extremely annoying as I usually have 3 or more tabs open and switch between them constantly. When one detaches its a bit of a waste of time to have to close it and then start a new tab . Please disable this feature or gives us an option to disable it.

Thank-you.

Linux: Ubuntu Hardy Heron 8.04 64-bit
Kernel: 2.6.24-19-generic
Gnome: 2.22.3

There really seems to be NO response to this bug, this has been going on for ages, does gnome actually have developers? I don't like to have a go at volunteers but this thread was started in April! Presumably people keep looking at it and passing it over, not ideal

These kinds of comments are not going to help the cause.
Please refrain from venting frustration in bugzilla. 
It only causes frustration levels on the developer side to rise, too.
Thanks

Created attachment 119869 [details] [review]
gtknotebook-detach-test.patch

Here is a patch, which seems to fix this issue, but breaks drag motion rendering.

Please test. if you get a better experience, I'll try to clean the drag motion rendering. It seems that we need to discriminate between "where the mouse is just now" (needed for drag motion rendering) and "where the mouse was in the moment of button release (needed for detaching). On fast machines it is nearly equal, on slow machines or fast mouse movement the difference may be important (see "gtk_notebook_motion_notify() event=..." lines in the debugging messages).

Is there a way to reproduce this bug? To detach a non-active tab in gnome-terminal, I have to click on the tab, hold it for at least one second while i drag it outside gnome-terminals window. I can't see how this can happen by accident. Granted, fast computer, but still.

It happens to me each time my laptop is loaded (for example when I'm extracting a tarball or installing a package, or starting some big app...). At that times the mouse is not fluid and often does not move for half a second or one second...

The way I tried to reproduce it of fast machine:

- Open a multi-tab gnome-terminal

- Call ten times "while : ; do : ; done" or so

- Now move pointer quickly from up to down and do a short click to the tab you want to activate

You will experience tab detaching, even if you are sure, that you released the mouse button before you left the tab area.

Slower machine => easier to reproduce with slow mouse speed.

Another way to reproduce: Use high load or low bandwidth X connection. Slow thin client is optimal device to reproduce: Click to tab not moving the pointer, after releasing the mouse button, move quickly pointer away. After a second, tab is detached.

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

Can gnome-term and possibly other programs behaviour be changed similar to epiphany and firefox?
Left mouse on a tab: select active tab and tab reordering possible
Rigth mouse on a tab: detach, close and whatever

That could fix the immediate problem I and others experience.

I also suffer this "bug", and it's very annoying. For me it happens with the computer loaded or not so much, and it just interprets the click to select a tab as a click and drag to detach it. I guess that I perform a small and short drag when clicking if I do it very fast, but it's very very small and fast drag! However, if I try to detach a tab I have to drag it outside the window, which is difficult because I always have the window maximized...
Possible solutions:
- A profile option to disable tab detaching (I have never used it...).
- Perform tab detaching ONLY with keyboard shortcut or tab contextual menu (the same that offers moving or closing the tab).
- Maybe the problem is that the mouse button release event arrives too late...
Thanks a lot,

Another solution, which would be a useful feature in its own right, would be to allow tabs to be reattached to a window, by dragging the window over the tab bar. This is what iTerm for Mac OS X does.

I can't really reproduce this issue.

The patch in comment 16 does seem to make things worse though. It breaks reordering without detaching. With the patch, tabs are always detached immediately. Before the patch, it was possible to reorder tabs by dragging without detaching them.

(In reply to comment #24)
> I can't really reproduce this issue.
> 
I recognize that reproducing it is very difficult. I can try all sort of ways, but as I'm concentrated on clicking the tabs it does not happen. However, later when I'm working and quickly I change the gnome-terminal tab it happens, and it's annoying. In fact, the first times I thought that it was my fault, but then it also started to happen to other colleagues.
Maybe the easiest solution is avoid the problem (a profile option to completely disable tab detaching or change the way you detach a tab or at least add the possibility to reattach a tab).
Thanks for your effort,

I had this happen to me a few times a day and it was really annoying.  I eventually gave up on this getting fixed and switch to another terminal.  However, it was only the one install that had the problem.  I switched to a new desktop and installed Ubuntu 8.04 and the problem went away.

I think part of the reason this is yet to be solved is that it only happens on to some people and the people it's not happening to assume that they just click a mouse better others.  I think this is actually a bug that is only apparent on certain hardware or configurations.

Created attachment 127866 [details] [review]
gtk-gtknotebook-detach.patch

Possible patch.

Rationale: Check threshold against mouse position saved in the event instead using of the current position. On fast systems, both values are typically nearly equal. On a system with a high load and fast-mouse-moving user, values may differ causing false assumption of long drag and detaching.

We should compute threshold with the position where mouse button was released, not the mouse position when mouse button release was processed.

I am starting to test it to see the experience.

The last part of the patch seems to be a good explanation for this behavior and a good fix, but I don't understand why you did the other changes

Different origin of coordinate systems: priv->mouse_? is window relative, event->x is widget relative.

In case of terminal with menu, these values differ by ~23 pixels.

Example from the debug log using previous patch and slow mouse motion:
priv->mouse_x = 441
priv->mouse_y = 28
event->x = 441
event->y = 5

Yes thank you for the explanation, I actually thought about it in my bed after posting but forgot to check this morning.

I'll start testing your patch right now :)

Since applying of the patch in the comment #27 I did not experience any unintentional detaching, so I guess that this patch fixes the problem.

But I encountered, that the same problem may affect tab reordering: If the machine is heavily loaded and you click while quickly moving over the set of tabs, you can sometimes experience unwanted tab reordering instead of just an activation.

I can confirm that extremely annoying bug on my Debian gnome-terminal 2.22.3-3.
PLEASE just add an option to disable detaching by mouse. Do not try to reproduce / fix etc the bug, if this seems complicated or time consuming. 

Please apply patch in comment 27, test it and report your experience.

Created attachment 129345 [details]
dilatory.c

Here is a very simple GTK+ module, which allows to easily reproduce this problem on fast machines and even find similar problems in other widgets.

Feel free to edit delays as you want. Feel free to add this module to the gtk test suite.

How to reproduce:
Run GTK_MODULES=dilatory gnome-terminal --disable-factory
Then click to tab to activate and then run quicky away with the mouse pointer. You have a good chance, that the tab will be detached. With the patch, the tab is not detached.

Accidental reordering was not confirmed, but the module found another ocurrence of the bug: Panes.

How to reproduce:
Run GTK_MODULES=dilatory gtk-demo -> Paned Widgets
Increase the size of the paned window
Now drag any pane, move, release in the middle of dragging and continue moving the mouse
Pane is moved to the place, where dilatory releases control instead of place where release event ocurred.

Further similar problems found:


Tab reorder

Run GTK_MODULES=dilatory gnome-terminal --disable-factory
Open more tabs
Push the mouse button, wait few seconds, start dragging quickly along the tab bar
Drop and continue with mouse moving

Actual result: Tab is moved to place of dilatory release.
Expected result: Tab is moved to place where mouse button was released.


Mark text - end

Start any GTK+ application with GTK_MODULES=dilatory.
Start moving a mouse
Push button and mark text without stopping mouse moving.
Release without stopping mouse moving.

Actual result: Text is marked from place of button push to place of dilatory release.
Expected result: Text is marked from place of button push to place button release.

I created a small project using the code in comment #34.
Tool:
http://pack.suse.cz/sbrabec/gtk-dilatory
Announce:
http://mail.gnome.org/archives/usability/2009-February/msg00052.html

I can't reproduce your findings about text selection. The other ones, I can.

Text selection dilatory evaluation of button release can be reproduced in gtk2-2.14.4. Note that button press evaluation is not affected.

(In reply to comment #27)
> Created an attachment (id=127866) [edit]
> gtk-gtknotebook-detach.patch
> 
> Possible patch.

I think this patch is curing a symptom, not the real cause, but I'm not sure yet.

I noticed that both gtk_notebook_button_press() and gtk_notebook_motion_notify() call gdk_window_get_pointer().  This means that if the mouse is moving, they may get a different position than what came in with the event.  Instead, they should call XTranslateCoordinates() with the window and coordinates from the event, to translate them to the appropriate window.

Can you please remove the use of gdk_window_get_pointer() and use the event's coordinates (translated to the appropriate window) instead?

About your patch --- in check_threshold(), changing rectangle.{x, y} to 0 doesn't seem correct.  That's not the origin of the event_window with respect to the widget's window.

Finally, in gtk_notebook_motion_notify() you changed
-      check_threshold (notebook, priv->mouse_x, priv->mouse_y))
+      check_threshold (notebook, event->x, event->y))

If you remove the use of gdk_window_get_pointer(), then that won't be necessary.

(In reply to comment #38)
> Text selection dilatory evaluation of button release can be reproduced in
> gtk2-2.14.4. Note that button press evaluation is not affected.
> 

I just looked at gtktextview.c:selection_motion_event_handler() - it calls get_iter_at_pointer(), which in turn does gdk_window_get_pointer() --- that's wrong; selection_motion_event_handler() already has a GdkEventMotion with the appropriate coordinates, so it should pass those coords to the get_iter function.  

Congratulations, you just found a bad pattern where getting the pointer explicitly, rather than from the current event, leds to problems with slow machines :)

Confirming this bug, since many people are experiencing it (myself included).

another possible example. when resizing a sidebar or list column. If you drag the sidebar handle, release it, and then move the mouse, the sidebar can jump to the current mouse position.

I see this a lot when running graphical apps tunneled through ssh.

(In reply to comment #42)
> another possible example. when resizing a sidebar or list column. If you drag
> the sidebar handle, release it, and then move the mouse, the sidebar can jump
> to the current mouse position.

GtkPaned:  It uses gdk_window_get_pointer() but it doesn't check if the event is a motion hint.  Also, it doesn't update the paned position on button release; it should do that.

GtkTreeView:  It properly checks if the event is a motion hint.  However, it doesn't update the column width when the button is released; it should do that.

I just filed bug #573154 as a tracker bug for these issues.  Please file separate bugs for other widgets, and make that tracker bug depend on them.

Yes, very annoying, please fix

George: Please don't add such useless comments wasting my time.
Complaints or "Please fix" comments generally do not motivate someone to fix a bug. Instead, provide patches if you want to see issues fixed... Thanks.

Cheers Andre, my comment was in response to posting 2 on this Ubuntu forum. http://ubuntuforums.org/showthread.php?t=855178 

I thought more names on the complaints list might increase the priority of fixing this. In future I won't bother.

ta.

(You can CC yourself on this bug if you want to track progress, without leaving a comment. Yelling "me too" at the same time is not helpful at all.)

Anyway, it looks like this bug should be marked as blocking #573154 (doing so now).

Since so many people are having issues with this, I move that this "feature" be removed altogether until it can be refactored. It doesn't seem like it adds much benefit for the amount of pain it causes. 

I confirming this bug. It make work with console hard as hell.

Could someone make a deb packege with patch from comment 27?
It will be very helpful for non delopers.

Created attachment 137267 [details] [review]
gtk-gtknotebook-detach.patch

Here is a new patch that gets rid gdk_window_get_pointer() completely. It's not much tested yet.

I hope it is correct now, but it is incomplete - according to bug 573154, gtk_notebook_button_release() should also contain a check.

Created attachment 137273 [details] [review]
gtk2-bgo529908-sanitize-notebook-motion.diff

Thanks, Stanislav; I fixed the patch up a bit and committed it to master (commit a39b2dcee44d747c0803c0913fcaa19d1b681ad4) and gtk-2-16 (commit bc27497020de7287c74a012b8f6a49c9f30c35b8).

As I understand correctly description in bug 573154, gtk_notebook_button_release() should process event coordinates as well, isn't it?

Since GtkNotebook doesn't use motion hints, I *think* we can assume that all motion events are delivered and the last one before the ButtonRelease will have the same coordinates as the release itself.

To comment #54: Confirming. Without motion hints all events are delivered, even at cost of processing delay.

Regarding other similar reported here and later added to the tracker bug 573154: Using motion hints for visual feedback seems to be have some problems. See bug 587714 for more information.