Text selection remains whether or not widget has focus

[Konrad Kleine]

A Note infront: I think that this bug is easy to fix! Just take a look at the proposal at the bottom.

Take any dialog in GNOME:

Whenever you are selecting text in a text entry and then change the focus to another widget (e.g. the server text entry in the screenshot below) the selection isn't touched. One might find scenarios in which this is a useful behaviour but I've found myself having trouble with "Save file" dialogs so many times! It irritates if you plan to overwrite a filename when your text is for instance being entered in a popup search field, only because the desired widget hasn't got the focus.

From the end-user's point of view, one has to double check (WHICH IS ONE CHECK TO MUCH) if you're text is selected and if the desired widget has the focus before you can start to overwrite the text. Moreover, it makes no sense to keep the text of a defocused text entry selected when this selection is discarded, once the widget regains focus by clicking on it!!! Currently the selection only remains intacts when you use your <TAB> key to tab through a form.

How to reproduce bug:

1. To reproduce this "bug" simply open any application in GNOME that can save a file.
2. Click "Save as"
3. Now select the name of the file in the top text entry
4. While leaving this entry selected go to the extended view for saving files and click in the right widget
5. Now start to enter some text. An immediate search starts and your text is being entered in the little pattern field.

Proposal:

Change the default behaviour of any GTK text entry widget: On focus lost, clear text selection.
Currently the selection only seems to be cleared when you start selecting text in a separate text entry widget or when the widget with selected text regains focus by clicking on it. When tabbing through a form with <TAB> all selections remain intact.

[Ralf Hersel (ralf.hersel)]

This bug is especially annoying in the GNOME File Save dialog.

Reproduction:
1. open GEDIT
2. click SAVE
3. click or double-click a folder
Now the filename remains highlighted but you cannot type in a filename.

I agree to Konrad's proposal: don't leave a widget highligted when it does not have the focus.
Or in the mentioned case (file save dialog): set the focus back to the filename as soon as a new folder was selected.

[Konrad Kleine (konrad.kleine)]

Yes, Ralf's solution to return the focus to the text entry with the selected text is even better than discarding the selected text.

But how can one describe when the focus shall be returned. When selecting a directory the action is clearly specified: Click and then you're done.

But what about switching between text entries in forms? The behaviour needs to be different there, I guess. Here, discarding the selection or at least finding a behaviour that is identical to mouse-clicking AND tabbing is a better solution.

[TheShadow (theshadow-shadowpedia)]

So the use cases should be as follows

Window Opens:
   * File name field has focus

Single Click on a Folder:
   * Folder has focus

Double Click on Folder:
   * Navigate to folder
   * Return focus to file name

Over all 90% of the time the user will be changing folders to change its location then change its name.

Of course this is just my opinion but how I would expect it to work.

[J (dump)]

The effects of this bug extends to an earlier reported bug (reported by me).

Nautilus should deselect selection when focus is lost:
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/373927
http://bugzilla.gnome.org/show_bug.cgi?id=582522

I was going to try resubmit the bug as a paper cut but I noticed this one... and already confirmed...

The solution to this problem, that would solve both bugs, would be adding a different selection colour for widgets without focus.

[Nathaniel Sherry (nsherry)]

I think that the reasoning (at least partly) behind continuing to show it as selected was for X's immediate clipboard. Note that if you open up two instances of gedit, get the file name in the file save dialogue selected in one, and then select text in the other gedit, the text in the first gedit's file name field is deselected. This indicates to the user what text is in the X immediate clipboard at any given time, and I find it rather useful, so removing it outright is not optimal.

What I would like to see is for the selected text to grey out when the widget or window has lost focus. If the regular text selection colour is blue, then when the window/widget selection changes, the text-selection background should desaturate to indicate that while the text is still selected (and this still in the X immediate clipboard), the window/widget does not have focus, and typing will not affect it.

[Jake Rayson (growdigital)]

I agree with Nathaniel "selected text to grey out when the widget or window has lost focus", which seems to be the same issue as this bug:

Selected items do not change color when window is unfocused
https://bugs.edge.launchpad.net/hundredpapercuts/+bug/393585

[johnk (johnk-riceball)]

gtk under xubuntu currently behaves like #6.

[carniola (michael-manske)]

I realize this one has been passed up, but as a new user this was definitely the most confusing thing for me. And fwiw, it was also the most "dugg" bug on the digg thread about 100 papercuts. (http://digg.com/linux_unix/Canonical_to_boost_Ubuntu_usability_by_tackling)