it was a theme decision to make the colors for selected-and-unfocused the same as selected-and-focused

This is not due to the highlighting style – the highlighting needs to be undone at changing the selection. Because everyone at the moment thinks that pressing some keys would alter the file name – but it doesn't (instead the search is started).

To me the current behaviour is pretty clear, it works consistently with everything else in the platform. For example if you select some text in an editor then focus an entry on a toolbar or something the text selection remains there selected and you don't expect that to change, I don't see why doing that in entry is a special case frankly speaking.

Yes, I expect it to get either either active again or unselected (when staying inactive), since the selection is then on the file browser and not on the text. What's the sense of selecting multiple things simultaneously inside the same window? Nobody would know what's active.

The point „it's like everywhere else“ is absurd – we want make things better and not „like everything else“ – not regarding if „everything else“ is good or bad.

And the text in the editor of your example remains selected, because otherwise you couldn't do e.g. Edit->Copy. And when you close the toolbar/menu, the (still selected) text gets active again – what is expected because it's still selected! Whereas in Nautilus, the file browser part of the window is active and typing starts a search instead of editing the selected text. Why should the text be selected, when no operation applies on it? Makes absolutely no sense, in my opinion.

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

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

Addition to my previous comment: When some text inside some window is selected and another window is focused, the selected text remains selected, but gets grey instead of remaining blue. So everybody sees that it’s not active – what’s not true for this case, since EVERYBODY thinks that the text is active and has focus while that’s not the case – so please unselect the text or paint it grey at least.

This behaves like no other UI I've encountered, and find it annoying. I also find it specious that the typical workflow, and therefore default position, is search in a Save dialog. I don't ever use this search feature at all, what I want is to click to navigate, then switch to the keyboard to enter the filename and either return or enter means the same thing as clicking on the blue highlighted save button.

Anyway for whatever reason I'm not able to reproduce this in Gedit on Fedora 26 right now. New document, type some text, click Save, and start typing and it's in the filename field. The search field isn't active.

Same for Libreoffice and Firefox.

You’re right. I too think it’s better to let the focus stay on the name while switching to the right directory – one can then alter the name without having to select it again.

(On my Fedora 26 station it’s still occurring in Gedit and LibreOffice, Firefox uses another dialog, where I can change directorys and directly alter the name without having to select anything – perfect.)

I perceive at least 3 issues and potential fixes:
 * whether selections in unfocussed vs focussed Entries should be the same colour
 * whether the selection should be cleared on focus-out
 * whether doing other stuff should stop 'stealing' focus from the location Entry

My personal, totally reflexive preferences are yes to #1, no to #2, and 'ummmmm' to #3.

I'm attempting a rename to better explain what's going on, i.e. #1 and #2

For the latter, that's a tricker thing to debate, and let's try to keep https://bugzilla.gnome.org/show_bug.cgi?id=756907 as the canonical bug.

Well, what I'm seeing now is there's no search field. I have to click on a magnifying glass icon to get the search field. So my system must be in some new state that I haven't previously seen, and isn't the default behavior (?). But to me the simplest way of handling this is what I'm presently seeing which doesn't confuse different available fields. I have just the filename field, and if I want a search field, I have to click on the magnifying glass icon.

I totally see the use case, and value, of search in a save dialog. I just don't see it as the default field. And I really really do not see it defendable to have two fields visible at the same time by default which is the behavior I previously was encountering: an "untitled" document highlighted an active, and a search field active with nearly invisible cursor, and when I type it's in the search field. Really it makes zero sense Ux wise, not least of which is that the search field is under the filename field.

I'd say just make the filename field in-focus by default. And the user has to explicitly click on the magnifying glass icon to get a search field. A distant second, is an explicit click in the already present search field which can be switch to by pressing TAB or the magnifying class icon.

(In reply to Chris Murphy from comment #11)
> Well, what I'm seeing now is there's no search field. I have to click on a
> magnifying glass icon to get the search field. So my system must be in some
> new state that I haven't previously seen, and isn't the default behavior
> (?).

It's been default for as long as I've been paying attention. What happens is this:

There's no search field initially, and the location entry has focus initially. Great!

But if you click on / otherwise move to something in the file list, sidebar, etc. - for example to browse into the folder where you want to save - then the clicked widget gets focus. So, the location entry no longer has focus. Therefore, now, keys (that aren't consumed by widget navigation and whatnot) start propagating to the toplevel, at which point the search gets them, so it shows and grabs focus.


Hence, the related report about focus behaviour. I'm not sure that'll change, though.


I'm also not sure that the search behaviour will change; like it or lump it (and I lean towards the latter), that's a pattern that appears throughout GNOME now, and GTK+ being heavily GNOME-oriented follows suit.


For these reasons, I think amending the theming, to make selected-but-unfocussed entry regions grey - or at least _less_ blue than focussed ones - is the simplest thing to change, which would at least do a lot to reduce confusion of users who (A) think blue means focussed and  (B)don't realise that they also need to notice whether the entry's border itself is currently blue

In the Gedit save dialog window, there is a magnifier glass icon right on the right side of the location entry – can the text input therefore be mapped manually to the location entry field, even if the file chooser widget has focus? When needing to _save_ something, in 99% of all cases one just wants to alter the file name and not do any search, so this would save a manual selection of the file name every time. I understand the search concept, but sticking to it makes almost no sense in case of saving a file.

Daniel, on windows 10 and osx the entry focus out cancels the selection. On windows focusing the entry automatically selects all the content, while that doesn't happen on osx.

errata corrige: in recents osx the focus on the main entry automatically select all the content as on window

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

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

I'd like to chime in and agree that I have never once in my life used the "type to search" feature in a file save dialog. I'm sure some people use it. But I'm also sure that MANY more people only ever type into a file save dialog to change the file name.

Thus, the search function should not steal focus. It should wait to be selected by the user, most of whom won't select it because they don't want to use it.

I would prefer that the file name text field "keep focus" in that any non-navigation keystrokes would be consumed by it and replace the highlighted text in the file name text field, as the visual cues suggest will happen.

A less useful but visually/cognitively consistent solution would be for the text to be deselected when a click is made elsewhere in the chooser. This would be irritating but not violate expectations.

I don't have an opinion on the highlight colors.

It's also worth noting that a different control pops up for the type-to-search feature based on whether the last click was in the Places pane or the general chooser, at least in Cinnamon 3.4.6: when the last click was in Places, a text field with magnifying glass appears above the file chooser; when the last click was in the chooser, an unlabeled text field appears below its bottom right corner. WTF.

^ sounds like a Cinnamon patch. What does the latter text box do? I'm guessing it implements moving to the item whose name matches what you've typed so far, instead of searching - circumventing another common (and IMO [even more] justified!) grumble with the upstream FileChooser.

It does indeed appear that the lower-right text box will move to the item in the current directory with a head-end substring match to what you've typed.

Interestingly enough, if I manage to pop up the top-center text box with magnifying glass, the box in the lower right appears and steals focus from it after a short period of time! So it would be good to know if the lower-right box is a Cinnamon thing, so that I can go report a bug if necessary.

AFAICT, it is a Ubuntu patch, which of course is inherited by Linux Mint. That patch is named restore_filechooser_typeaheadfind and simply toggles the :enable-search property of the internal GtkTreeView to TRUE and sets the filename as the search column.


(In reply to GoMo from comment #20)
> the box in the lower right appears and steals focus from
> it after a short period of time!

What happens in the stock FileChooserWidget is this:

* You have focus in the file list
* You type a character
* It goes to the search entry
* The file list is filtered by the search so far
* ...and the top item gets focus
* so now the search entry does not have focus.

So I wouldn't be surprised if, in your case, the next keypress goes to the TreeView search.

That's not a bug *per se*, but it does indicate that the search may not play nicely with Ubuntu's patch.

I would like to state that this issue is the biggest usability issue I have in Gnome. Also, when I see someone new to Gnome trying to save a file, this person usually gets confused by the behaviour of the 'save as' dialogue.
I highly recommend to make 'save as' more intuitive, especially when you first select the directory, and then want to enter the file name (this is my preferred work order).

(In reply to Jan Vlug from comment #22)
> I would like to state that this issue is the biggest usability issue I have
> in Gnome.

I was just thinking the exact same thing today, and thought "apparently I need to go into the bug report and make a finer point about how bad of a bug this is, because it's still not really being taken seriously."

I've been using Fedora Workstation full time for over a year, and I'm still not used to the behavior this bug is about. Pretty much everytime it happens I say fuck outloud. Making users pissed off is not good UI/UX.

A. Click Save and start typing affects the filename.
B. Click Save, double click on a directory, start typing and it searches? It's not consistent nor is it even logical. The search field isn't even visible until I type - I type and *then* the search field appears.

It's high order UI/UX betrayal.

Instead of leaving yet another melodramatic or hyperbolic "+1" comment, please contribute a patch to the file chooser. I'll gladly review on.

If you don't plan on writing a patch, please: don't leave any other comment.

(In reply to Emmanuele Bassi (:ebassi) from comment #24)
> If you don't plan on writing a patch, please: don't leave any other comment.

Request denied.

https://xenoterracide.com/post/dont-say-patches-welcome/
https://www.urbandictionary.com/define.php?term=patches%20are%20welcome

All you're going to incentivize in me with this kind of attitude is me posting fuck each time I run into this bug as a demonstration of how often I run into it and how fucking annoying it really is.

In my opinion, „patches are welcome“ is fully valid for feature requests – but not for bug reports. This is very annoying every time, and ineffective, if we would have to do that. As someone who knows the code could probably fix this in half an hour, whereas we other not-involved people would need several hours or more.

I'm a bit lost, this bug was supposed to be fixed in bug 746202 or otherwise I cannot grasp the difference between the problem on that bug and this.

That was about the focus outline, but I think the remaining complaint here is about the colour of selected text, i.e. the fact that the blue highlight remains when the entry is no longer focussed.

but it's very difficult to tell all these bugs apart when there are so many people posting so much noise about how annoyed they are or how Other System oes it, rather than concrete reports of the problem and ways forward.

(In reply to Emmanuele Bassi (:ebassi) from comment #24)
> Instead of leaving yet another melodramatic or hyperbolic "+1" comment,
> please contribute a patch to the file chooser. I'll gladly review on.

I'd point out that the patch would need to be for selected text across our themes, not the FC or any other widget specifically.

afaics, bug 746202 has discussion and unreviewed patches for that, but clearly they never went anywhere. Nelson, maybe you should rebase your patches and reopen that one for further discussion? We could then close this as a dupe of it, while bearing in mind that this one is perhaps the main reason people dislike the current lack of differentiation.

Daniel, the right fix here is canceling the selection on entry focus out and selecting all the entry content on focusing back as Windows and the Mac do. To me creating weird special cases in our visual language is not a good fix.

> the right fix here is canceling the selection on entry focus out

True. Why don't we do that?

> and selecting all the entry content on focusing back

We already do this when focussing by keyboard (and we shouldn't by mouse).

> True. Why don't we do that?

That's a good question, maybe since it's easier to defer the issue to the theme :-)

> We already do this when focussing by keyboard (and we shouldn't by mouse).

Not sure about the mouse exception though, Windows does that for example and that seems legit to me.

Thanks for your responses!

I don’t know what you mean with that mouse focus thing – but I hope you don’t want to change the behaviour, that we’re (in contrast to windows) able to scroll not-active windows, as this as a HUGE advantage of Gnome!

No, not related. You're thinking of toplevel focus and active/backdrop windows.

My understanding of what Lapo said is that he was suggesting that, just as GtkEntry selects all text when tabbed into by keyboard, giving it focus a widget - so it should do the same if it gets focus because the user clicked inside it.

Just IMHO, that's not really useful. If I click in an Entry, it's usually because I know I want to start doing something with its text, such as editing or starting a partial selection. I don't then want the toolkit making assumptions that get in my way, or at least are redundant, making me click again to cancel the selection and start my own operation. If I want to select all, I just click 3 times! (This *could* work if only applied when clicking beyond the text, but that's about it.)

And sure, half of that argument could be made against selecting on all Tab, too, but that's an existing behaviour, so it's harder to justify removing, versus adding the same for mouse clicks.

That's just my opinion and may not agree with everyone else's. But anyway, this idea is not a part of this bug (and its implications for text widgets generally).

Yeah, I totally agree. Clicking into a text widget should just place a cursor at that exact point, and not select some parts of that text.

At tab selection, I’d assume to regain the last active selection, if one existed. Otherwise, I’d say that this depends on the specific case, and maybe you like to introduce a switch in the widget for that setting? But I never recognized some sort of misbehaviour there.

> At tab selection, I’d assume to regain the last active selection, if one existed.

Right now it selects all the text. There wouldn't be a last active selection, if we were to start clearing it on focus-out, at least without adding logic to save and reload it, which I'm not sure would be worthwhile.

If we wanted focus-out to *appear* to clear the selection and reload it, we could just hide the bg of unfocussed widgets' selected text in our themes (instead of the other suggestion of desaturating or otherwise softening it). This would let us avoid bugs like this, while not depriving other themes of the ability to e.g. have it be a different colour. But it may be seen as confusing if our theme does not show a selection that still exists. There's presumably a reason against it.

(In reply to Daniel Boles from comment #28)
> but it's very difficult to tell all these bugs apart when there are so many
> people posting so much noise about how annoyed they are or how Other System
> oes it, rather than concrete reports of the problem and ways forward.

That's why I filed bug 775861, and then you marked it as a duplicate of this bug.

Primary problem is the search field becoming the default field when typing. Searching is not the primary purpose of a Save As dialog, it's naming and saving files. Searching is a context switch that should be explicitly chosen by the user. It is not a search tool. It is a name and save tool.

Secondary is the inconsistency of the primary problem presenting itself. If I do not change dirs, typing goes into the file name field. If I change dirs, typing goes into a previously invisible search field.

Third, the search field is invisible until I start typing. Which is actually hilarious bait and switch. It's so obviously atrocious I make it the third problem because it's not even debatable. If what I typed went nowhere, did nothing, it would be better behavior than this.

Fourth, the file name field focus betrayal, when in fact the typed text goes into a previously invisible search field. This I put last because the correct field is in fact in focus! The problem is the text doesn't go there.

Each of these does in fact make total experience really bad, rather than any one particular bug. But fixing this by making search a visible field, by default, and in focus, will really make me exasperated. It will be doing something different with save as dialog boxes just for the sake of being different than *all other save as dialogs in the whole goddamn world*. And it is far less efficient. I should be able to TAB TAB or DOWN ARROR

The real test for UI/UX in this dialog is to take away the mouse/trackpad, and try to consistently navigate the dialog by keyboard to save files. Do this with 100 files.

(premature send while that post was still being edited so starting at the last sentence in the 2nd to last paragraph)

I should be able to TAB TAB or DOWN ARROW (even this is inconsistent right now) and ENTER to navigate through directories, and then when I start typing text it's for the file name, then hit RETURN and it's saved.

Once I've already navigated somewhere, it's beyond bizarre that I'd want to do a search. No. I've navigated to location, typing letters absolutely indisputably is for the file name. Not search.

Created attachment 370657 [details] [review]
Entry,TextView: Deselect text on ::focus-out

We don't differentiate between foreground and backdropped selections,
which confuses/infuriates users, particularly in the FileChooser entry.
There's no design desire to introduce that differentiation in the theme.
The preferred fix is instead to clear the selection on focussing out.

This patch does that by changing the existing code that clears the
selection when the state changes and the widget is no longer :sensitive
to instead clear the selection if it's not the focus within its toplevel

https://bugzilla.gnome.org/show_bug.cgi?id=770941#c30

> We don't differentiate between foreground and backdropped selections,

What. I must've been working on some other CSS thing at the time. This is true, but only trivially so: it's not fore/background that's the problem here; it's un/focussed.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/665.