GNOME Bugzilla – Bug 92509
Shouldn't be able to tab out of location field of location bar when using ctrl+L
Last modified: 2017-08-23 17:57:50 UTC
This only applies to when the location bar is off by default and the user either does ctrl+L or go => location... Currently if the user does ctrl+l or go => location... it is possible to tab out of the location entry field, leaving the toolbar permanently on the screen. I think this is inconsistent with how we expect this to work. I think the correct behavior would be for the location bar to go modal and either force the user to cancel out, enter a location, or hit the enter key as is done with rename.
A quicker fix I guess would just be to make the location bar hide again when you tabbed out of it, if View->Location Bar isn't selected. However, I agree that the current notion of the Location Bar being a regular toolbar with mysterious auto-showing/hiding properties is kind of weird and undiscoverable, and some other representation might be preferable.
well depending on the ui paradigm we use in the future, i wouldn't mind seeing the location bar being removed from nautilus and supplemented with a go to location dialog in the actions menu(this of course assumes OO design). However given the current navigation metaphor that is used, ctrl+l to drop down the location bar seems reasonable, but you shouldn't be able to tab out of it, or at least it should close the location bar when you tab out as you have recommended.
The behaviour is present in nautilus 2.1.2 as well.
Fairly minor IMHO, esp. since this isn't the default mode at all.
FWIW, I also suspect that Tab should *never* tab out of the location bar, as long as it's being used as our autocomplete key. If there is no matching completion when the user hits Tab, the cursor should stay where it is, and (perhaps) beep. Right now, sometimes Tab moves focus and sometimes it doesn't, and even though the behaviour predictable, it's highly annoying :) For consistency, Ctrl-Tab should be the only key that moves focus out of the location bar, and it should always do so (as it currently does).
at least as of 2.12 it is no longer possible to "tab out" with ctrl-l and TAB. however two TABs do and leave the location bar open. NOt sure if this is a problem as TAB is supposed to change focus onto other widgets?
You're right, at the very least you should be able to "tab out" by pressing Ctrl-L, then Ctrl-Tab (our universal "get me out of here if Tab is used by the focused control for something else" shortcut).
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Apologies for spam... marking as AP4 to reflect accessibility impact.
Changing component.
I think the real issue here is that Tab in the location entry has the double meaning of completing the file path and moving out if there's no completion for the path. We should not move the focus out in the latter case.
*** Bug 138328 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > it is no longer possible to "tab out" with ctrl-l and TAB. > however two TABs do and leave the location bar open. Still the same in 3.1.4.
Created attachment 223788 [details] [review] Hide location entry on focus out Otherwise there is no obvious way to hide it again.
Hmm, that doesn't work too well when you try to popup a menu. And doesn't work well with always-show-location-bar.
Review of attachment 223788 [details] [review]: Marking as rejected as per last comment.
Still valid. After using CTRL+L there is no discoverable way to dismiss the path entry, and not even undiscoverable ways if it loses focus. An idea: making it a popover.
(In reply to António Fernandes from comment #17) > Still valid. After using CTRL+L there is no discoverable way to dismiss the > path entry, and not even undiscoverable ways if it loses focus. > > An idea: making it a popover. Dismissing it as simple as pressing ESC, but we should probably aim to hide it when it loses focus, as well as consume all TAB presses.
Created attachment 358069 [details] [review] window: hide location entry on lost focus This solves the issue of the location entry remaining in the toolbar if the user inadvertently (or not) tab-focuses a different widget.
(In reply to Ernestas Kulik from comment #19) > Created attachment 358069 [details] [review] [review] > window: hide location entry on lost focus > > This solves the issue of the location entry remaining in the toolbar > if the user inadvertently (or not) tab-focuses a different widget. Now we need to figure out which problems we want to address. If the primary concern is that the location entry stays in the toolbar, this would be the patch, I believe (which appears to be more or less identical to William’s).
The location entry is a second-rate feature at this point and we don’t have a better option. I’m not sure if we want to have it as a dialog, either, as we’ve been moving away from those in general. FWIW, regardless of our decision, I think that we should hide it when the keyboard focus is lost.
Thanks for picking this up, Ernestas! I've tried your patch and it has got the same problem with context menu mentioned in comment 15: if I open the context menu to copy the path, the location entry disappears even though the the context menu is displayed. I guess it also doesn't play well with always-show-location-bar=TRUE gsetting key, but I'm not able to test.
Review of attachment 358069 [details] [review]: Same thing as in comment 15. Not gonna work in its current form.
Created attachment 358110 [details] [review] toolbar: hide location entry on lost focus This solves the issue of the location entry remaining in the toolbar if the user inadvertently (or not) tab-focuses a different widget.
(In reply to Ernestas Kulik from comment #24) > Created attachment 358110 [details] [review] [review] > toolbar: hide location entry on lost focus > > This solves the issue of the location entry remaining in the toolbar > if the user inadvertently (or not) tab-focuses a different widget. This is a little hacky^Wclever, but seems to work well.
Created attachment 358154 [details] [review] general: hide location entry on lost focus This solves the issue of the location entry remaining in the toolbar if the user inadvertently (or not) tab-focuses a different widget.
(In reply to Ernestas Kulik from comment #26) > Created attachment 358154 [details] [review] [review] > general: hide location entry on lost focus > > This solves the issue of the location entry remaining in the toolbar > if the user inadvertently (or not) tab-focuses a different widget. Summary: * the location entry is hidden when the keyboard focus is lost; * exception #1: the location entry is not hidden when the top-level window loses focus; * exception #2: the location entry is not hidden when the context menu is popped up. As you’ll see, the code for that looks sort of ridiculous, but at the same time I believe that we cover all the common use cases without regressions (until António surprises me).
Review of attachment 358154 [details] [review]: ::: src/nautilus-toolbar.c @@ +878,3 @@ + + (void) entry; + gpointer user_data) Don't try to oversmart me! ::: src/nautilus-window.c @@ +2862,3 @@ +static gboolean +on_window_focus_out_event (GtkWidget *widget, I think a comment here will really help to explain why this is done @@ +2888,3 @@ + +static gboolean + I think all of this should be handled in toolbar itself. So the toolbar would connect to the window focus events, then do all the toolbar thingies. You will avoid the API too, and have the things where it belong.
Created attachment 358229 [details] [review] toolbar: hide location entry on lost focus This solves the issue of the location entry remaining in the toolbar if the user inadvertently (or not) tab-focuses a different widget.
Created attachment 358230 [details] [review] toolbar: hide location entry on lost focus This solves the issue of the location entry remaining in the toolbar if the user inadvertently (or not) tab-focuses a different widget.
Review of attachment 358230 [details] [review]: ::: src/nautilus-toolbar.c @@ +1046,3 @@ + +/* The location entry in general is hidden when it loses focus, + if (g_settings_get_boolean (nautilus_preferences, It's quite convoluted sentence. @@ +1064,3 @@ + } + + } isn't the toolbar focus callback get handled before this one? If so, wouldn't the sense of this go away? @@ +1090,1 @@ self->window = g_value_get_object (value); can't the window be null?
Created attachment 358235 [details] [review] toolbar: hide location entry on lost focus This solves the issue of the location entry remaining in the toolbar if the user inadvertently (or not) tab-focuses a different widget.
Created attachment 358240 [details] [review] toolbar: hide location entry on lost focus This solves the issue of the location entry remaining in the toolbar if the user inadvertently (or not) tab-focuses a different widget.
(In reply to Carlos Soriano from comment #31) > Review of attachment 358230 [details] [review] [review]: > > isn't the toolbar focus callback get handled before this one? If so, > wouldn't the sense of this go away? No, focus events, along with some other types of input events aren’t propagated upwards.
Review of attachment 358240 [details] [review]: LGTM!
Attachment 358240 [details] pushed as 921cd36 - toolbar: hide location entry on lost focus