click-to-focus window is too sensitive

thanks for the report, are you getting that with compiz or metacity? i don't see the issue here, may you tell us a few easy steps in order to reproduce the bug? could you test the same with karmic and comment back? thanks.

I have the same problem. I use metacity, but don't think it is related to metacity. It goes like this:
I want to copy-paste some text from terminal 1 to terminal 2, using mouse only.
(1) I use mouse left button to select some text in terminal 1.
(2) Move mouse over the terminal 2, click with left button to set focus to it.
(3) Click mouse wheel button to paste the selection into terminal 2.

The problem is in step 2. Often I make a tiny move during the click, thus making a new selection in terminal 2. The original selection from terminal 1 is lost, and I can start over with step (1).

problem persists in karmic.

no compiz, just metacity.

steps to reproduce:

1. open 2 gnome-terminals
2. move and/or resize so both are visible
3. run a 'ls' a few times in each to get a variety of characters on each
4. click-to-focus between the two terminals a few times, and notice that doing so often selects whole lines, etc.

I don't think click-to-focus should pass the click to the window the click is focusing in general.

clearly an usability bug.
the gnome terminal should not create a new selection until the mouse cursor is dragged by at least one character.
accidental mouse movements are nearly unavoidable with todays high resolution screens.

combined with the stupid unix selection model (losing the "clipboard" by merely selecting another text) this is one of the most frustrating defects in the gnome desktop.

Further notes:

- It's not just while focusing into the window, but that's when the behaviour is most annoying.

 - The problem is worst in the "end of line" space to the right of text in the terminal. In that area, any mouse movement (seemingly even a sub-pixel movement) will cause a selection and effectively erase the copy buffer.

- The problem is still somewhat annoying even in the non-end-of-line text area depending on where in the character your cursor lands (to the left or right or near the center):
  - If you cursor is on the right half of a character, any horizontal movement will cause a selection. In emacs, by comparison, you have to drag to the end of the character before it's selected.
  - If you cursor is on the left half of a character, it nicely allows you to drag half a character in either direction. This would be desirable in the above case as well, IMO.
  - Vertical movement is ok because you can move a whole line height without causing a selection.

If I get ambitious, maybe I'll look at the source code myself.

I'm running a fresh install of Ubuntu 9.10. In my previous installation I was so annoyed that I installed konsole (yes, under gnome), but that comes with a lot of unwanted KDE packages.

This behaviour must be inherent in some other GUI library, because it's not apparent in the gnome-terminal code.

I use the highlight copy/paste buffer so extensively that this is a very serious usability issue for me. I finally got fed up and installed konsole. While it did install some 191MB of KDE libraries, I'm quite happy with the end result. konsole has a very similar feature-set (tabs, etc) and tons of configuration options like gnome-terminal.

For anybody else that wants to use konsole as a workaround for this bug:

sudo apt-get install konsole

I also put a launcher icon in my to panel pointing to /usr/bin/konsole.

I dont experience this problem with the gnome terminal in 10.04

I can confirm this behaviour on 10.04 and GNOME Terminal 2.29.6

This still happens for me, but not always. I cant really figure out when...
Im using ubuntu in virtualbox

Thiago: are you using virtualbox too?

Mattias: no, I'm booting into Ubuntu natively.

It always happens to me whenever I click past the end-of-line in a terminal
screen. It started happening after I upgraded from 9.10 to 10.04.

Thiago: Ok

The times gnome-terminal have got into this weird state i think i only selected lines if i clicked on blank places in the terminal, not when click on a character.

Confirming this nasty behaviour for 10.04 ... i first recognized it after setting up xinerama.

I'm runing Ubuntu 10.04 with latest updates (as for yesterday 18:00 UTC) and gnome-terminal 2.29.6.

Here the problem is as following:

When you click on text in the deactivated window and move the cursor around a few pixels, text gets selected. While this is not very userfriendly it is at least expectable.

However when you click on a line end (area past the last character on a line) the line end gets selected. To confirm I'm not moving by any subpixel i used the Keyboard-Controlled mouse (from accessibility settings) to perform the click.

Once the window is active this doesn't happen and you can click on the same spot than before without any text being selected.

I'm using recent Ubuntu 10.04 with all updates up to yesterday 18:00 UTC. My gnome-terminal version is 2.29.6.

I tried to reproduce this bug using the keyboard controlled mouse from accessibility settings. With that I could make clicks whilst ensuring absolutely no mouse movement.

When the gnome-terminal window is deactivated and you click on some text in the terminal nothing gets selected unless you move the mouse cursor by at least one pixel.

However if you click on an area past the last character in a line, the line-ending gets selected even without moving the mouse.

My "workaround" is to click the window-title or some part of the menu bar to activate the window. Once it is activated you could click anywhere without text getting selected.

However this is so annoying I'm going to switch to xterm, aterm, rxvt or something similar by now.

@nomike: Many people can reproduce this bug, while many other (incl. me) cannot. You mention that the bug only occurs when the window is given focus, not when it already has it.

Just wondering: is it possible that you're using a theme where the window itself moves when getting focus? (I mean the inner content of the window, not the decoration.) What window manager and which theme are you using? Could you maybe please test the behavior with other graphical themes, and with both metacity & compiz, and with different focus models (focus follows vs. click to focus)?

This might be a stpuid idea, but it'd really nice to catch the difference between the good & bad settings.

Another debugging idea that might be useful: What happens if you replace gnome-terminal with xev? That is, give focus to an xev window by clicking inside it (using accessibility keyboard-driven fake mouse). Does it print any event regarding mouse movement or anything unusual?

I can verify that the gnome-terminal is receiving MotionNotify events (which are presumably what make it select full lines when you click-to-focus past the end of text on a line).

Tested as follows:
In Assitive Technologies keyboard preferences, enable controlling the mouse from the keyboard (this doesn't effect the test if you hold the mouse steady).
In one screen, launch xev from a terminal.
Ensure the terminal (not xev) has focus, and move the cursor to the xev window. Here you can wait a few seconds to make it easier to identify the subsequent events by timestamp.
Hit Numpad-5, giving xev focus.

On a workstation where I see this problem, this is the sequence of events I see on clicking (some of them annotated with coordinates to show that the cursor is not moving - always the same location):
EnterNotify root:(1942,65) KeymapNotify FocusIn KeymapNotify LeaveNotify root:(1942,65) ButtonPress root:(1942,65) EnterNotify root:(1942,65) KeymapNotify MotionNotify root:(1942,65) MotionNotify root:(1942,65) ButtonRelease root:(1942,65)
LeaveNotify root:(1942,65)

On a laptop that does not exhibit this problem, this is the sequence of events I see (note: no MotionNotify events; also tested without the keyboard-controlled mouse here):
EnterNotify KeymapNotify ConfigureNotify FocusIn KeymapNotify ButtonPress EnterNotify KeymapNotify ButtonRelease LeaveNotify

Both the problematic workstation and the working laptop are running 10.04 and both are using the "Ambiance" theme. The working laptop is using the "intel" driver, with no Xinerama, with "visual effects" set to "normal", and the problematic workstation has Xinerama enabled with the nvidia driver (/usr/lib/xorg/extra-modules/nvidia_drv.so), with "visual effects" set to "off".

I also see the same problem on Ubuntu 10.04 (and Fedora Core 13). I am running on Mac Pro towers and am running with Xinerama enabled with the nvidia driver. I only see this behaviour with gnome-terminal. Konsole, xterm and others behave as expected.

I can confirm this bug too.

It only happens with xinerama enabled.

When I open a gnome-terminal, focus on another window (does not need to be a terminal), and click into the terminal to focus it again, it immediately selects a whole line.

Happens with any visual effects setting.
xterm unaffected.

This never happens without xinerama (not even on a dual monitor setup).

I have Ubuntu 10.4 x64 with the latest fglrx binaries from AMD.

This bug is still very alive.

Curiously, I have number of machines and it only happens in one of them. This machine uses the nVidia driver and has Xinerama enabled. However, I have coworkers with the same configuration where the problem does not happen.

My first reaction (before I saw this bug) was to look at the output of xev and I can confirm that there is a "ghost" Motion event between the clicks.

I'm using plain old metacity.

Let me know if I can help with debugging data or attempt a few things locally.

I'm also seeing this bug in gnome-terminal 2.30.2. It causes frequent errors when I attempt to copy and paste text between windows.

Fortunately, other terminals don't seem to have this bug. I've switched to konsole, which works great.

Still happening in Trusty 14.04 LTS. Renders gnome-terminal unusable. Click on a tab and 75% of the time you get a new window. xubuntu nvidia mutltimonitor setup. Changed the 'drag detection' in the mouse settings to be an insensitive as possible, no change. Too bad really, I liked the feature set otherwise.