Closed Bug 1292321 Opened 7 years ago Closed 7 years ago

Pressing tab key in address bar selects one-off search buttons instead of the entries in the history dropdown list

Categories

(Firefox :: Address Bar, defect, P1)

Product:
Firefox
Component:
Address Bar
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 51
Tracking Flags:
Tracking Status
firefox48 --- unaffected
firefox49 --- unaffected
firefox50 --- unaffected
firefox51 --- verified

People

(Reporter: cpeterson, Assigned: adw)

References

Details

(Keywords: regression, Whiteboard: [fxsearch])

Attachments

(1 file)

Bug 1292321 - Pressing tab key in address bar selects one-off search buttons instead of the entries in the history dropdown list.
58 bytes, text/x-review-board-request
florian
: review+
Details 
STR:
1. Enter some text into the address bar.
2. Press the TAB key.

RESULT:
Instead of selecting the first entry in the history/search suggestions drop down list, the one-off search boxes are selected. You can still select the first entry using the down arrow key, but previously you could use either the tab key or down arrow key.

@ Drew, is this the new expected behavior? This is a regression from bug 1180944.
Flags: needinfo?(adw)
Yes, that's the expected behavior.  We can debate whether that's what should happen though.
Flags: needinfo?(adw)
(In reply to Drew Willcoxon :adw from comment #1)
> Yes, that's the expected behavior.  We can debate whether that's what should
> happen though.

Please, no. This breaks all users (including me) that we've been teaching over the last decade (maybe a little less) that <TAB> brings you to the first result. Using arrow keys is really not an option for people that use the keyboard extensively.

Why anyway would <TAB> behave differently from <KEYDOWN>? This UX changes assumes that what users always want and must be able to do without moving their fingers on the keyboard is to select another search engine? That seems like a wrong assumption to me.
(In reply to Tim Taubert [:ttaubert] from comment #2)
> (In reply to Drew Willcoxon :adw from comment #1)
> > Yes, that's the expected behavior.  We can debate whether that's what should
> > happen though.
> 
> Please, no. This breaks all users (including me) that we've been teaching
> over the last decade (maybe a little less) that <TAB> brings you to the
> first result.

Where have we been teaching this?

> Using arrow keys is really not an option for people that use
> the keyboard extensively.

You mean for people who use the keyboard with a single hand? (I would assume that's mostly people who use an external mouse rather than a touchpad.) When I have both hands on the keyboard the arrow key and the tab key are equally reachable.

> Why anyway would <TAB> behave differently from <KEYDOWN>? This UX changes
> assumes that what users always want and must be able to do without moving
> their fingers on the keyboard is to select another search engine? That seems
> like a wrong assumption to me.

No, it just assumes that keyboard users need a way to access the first search engine in the list without having to go through the dozen of url completions first.
(In reply to Florian Quèze [:florian] [:flo] from comment #3)
> (In reply to Tim Taubert [:ttaubert] from comment #2)
> > (In reply to Drew Willcoxon :adw from comment #1)
> > > Yes, that's the expected behavior.  We can debate whether that's what should
> > > happen though.
> > 
> > Please, no. This breaks all users (including me) that we've been teaching
> > over the last decade (maybe a little less) that <TAB> brings you to the
> > first result.
> 
> Where have we been teaching this?

In all previous Firefox versions that shipped with the Awesomebar. And maybe before that, I don't know.

> > Using arrow keys is really not an option for people that use
> > the keyboard extensively.
> 
> You mean for people who use the keyboard with a single hand? (I would assume
> that's mostly people who use an external mouse rather than a touchpad.) When
> I have both hands on the keyboard the arrow key and the tab key are equally
> reachable.

That's just not true. I don't use a mouse that often and the tab key is a lot more accessible than aiming for the arrow keys.

> > Why anyway would <TAB> behave differently from <KEYDOWN>? This UX changes
> > assumes that what users always want and must be able to do without moving
> > their fingers on the keyboard is to select another search engine? That seems
> > like a wrong assumption to me.
> 
> No, it just assumes that keyboard users need a way to access the first
> search engine in the list without having to go through the dozen of url
> completions first.

No, it assumes that this action would be more important than picking on the url completion suggestions. If you want to give users an easy way to access search engines then pick a different shortcut and don't override an important existing one. Something numbered like Alt+# would probably make more sense anyway so a user doesn't have to tab through a horizontal list of items.
Just as another point to consider, the tab button is also commonly used in Chrome's Omnibox, so it may also be a problem for users moving from Chrome to Firefox.
I personally think we did it wrong when we allowed the use of Tab in the past, especially because it's unconsistent with the other input field (searchbar for example), but no time machines yet.

Do we also disable tab if one-off feature is disabled in other channels? That is even more problematic since it would look like a removal without any benefit.

This should probably be discussed at the next meeting.
Priority: -- → P1
Whiteboard: [fxsearch]
I just noticed that ALT+up/down already allows to move directly through the engines.
Maybe we could just keep this?
(In reply to Marco Bonardo [::mak] (Away 6-20 Aug) from comment #5)

> Do we also disable tab if one-off feature is disabled in other channels?
> That is even more problematic since it would look like a removal without any
> benefit.

That's worth checking (and fixing if broken).

> This should probably be discussed at the next meeting.

Right.

(In reply to Marco Bonardo [::mak] (Away 6-20 Aug) from comment #6)
> I just noticed that ALT+up/down already allows to move directly through the
> engines.

That's hardly discoverable though.

Note: we had similar complaints when we introduced one-off buttons in the searchbar (see bug 1102948), and one of the rationale used by users who wanted us to revert to the previous behavior was consistency with the awesomebar.

It's not unexpected that changing a behavior that's been there for years causes some frustration.
(In reply to Florian Quèze [:florian] [:flo] from comment #7)
> It's not unexpected that changing a behavior that's been there for years
> causes some frustration.

The question here is whether it's really worth the hassle.

> > I just noticed that ALT+up/down already allows to move directly through the
> > engines.
> 
> That's hardly discoverable though.

So is pressing the tab key for the target user group. If they discovered the <tab> key before they will have used it to navigate autocompletion results. If the didn't discover <tab> yet then they very likely won't try to reach the search engines at the bottom with a key they never used before, but rather use the  mouse.
(In reply to Tim Taubert [:ttaubert] from comment #8)

> > > I just noticed that ALT+up/down already allows to move directly through the
> > > engines.
> > 
> > That's hardly discoverable though.
> 
> So is pressing the tab key

No, the tab key is the key used to go to the next UI element (not the next item in a list), throughout the UI (and this is not Firefox-specific). It's the natural key to try.
(In reply to Marco Bonardo [::mak] (Away 6-20 Aug) from comment #5)

> Do we also disable tab if one-off feature is disabled in other channels?

No, Tab works as it always has when browser.urlbar.oneOffSearches=false.

I agree with Tim on this.  You can't take away an important shortcut in such an important UI that people have been using for years.  There ought to be a shortcut for the one-offs, but it should be something other than Tab.  (Despite not having thought a lot about it while working on the patch, yeah.)
(In reply to Marco Bonardo [::mak] (Away 6-20 Aug) from comment #5)
> Just as another point to consider, the tab button is also commonly used in
> Chrome's Omnibox, so it may also be a problem for users moving from Chrome
> to Firefox.

FWIW, the tab key selects the first URL suggestion in Chrome and IE11.

The tab key does *not* select the first URL suggestion in Safari or Edge (?!). It's curious that Microsoft changed the tab key behavior when going from IE11 to Edge.
(In reply to Florian Quèze [:florian] [:flo] from comment #7)
> (In reply to Marco Bonardo [::mak] (Away 6-20 Aug) from comment #6)
> > I just noticed that ALT+up/down already allows to move directly through the
> > engines.
> 
> That's hardly discoverable though.

Tab is not much more discoverable, people who are used to Tab are likely expecting it to go thrrough results than through engines.
I'd expect non-technical to actually use the mouse to reach buttons, and others to be able to figure a shortcut if we advertize it somehow (maybe a tip/hint somewhere?)
We need to keep Tab moving to the next awesomebar result. Hijacking it to change search engines is optimizing for a less-likely direction.

If the user tabs to the end of the awesomebar results, then the next Tab can move to the engines. Similarly, Shift+Tab could move to the search engines directly.
Florian, is there any update on this? This change in behavior is very breaking to existing keyboard users.

I also disagree with your argument that Tab moves to the next focusable element, and that the next focusable element would be the search destinations. Why would the next UI element be the search destinations when they are the furthest away from the location bar, whereas the first result in the dropdown is geographically closer? Wouldn't the first result in the dropdown be the "next" UI element?
Flags: needinfo?(florian)
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #16)
> Florian, is there any update on this?

Last I heard Stephen intended to comment here to give UX input.
Flags: needinfo?(florian) → needinfo?(shorlander)
Even when all search engines are removed, tab does not move to the next focusable element (which is still the next item in the suggestions list) — focus is lost instead.  
Behavior should be consistent with previous/current expectations and everything else on the web — moves focus to next item in list.
Would it be possible to get a quick revert for nightly users affected by this? Then we can settle 'what should we do' in longer form bug reports and such.
We should just disable this Tab behavior in the urlbar until Stephen comments.  You can still use Alt+Up/Down to cycle through the engines from the keyboard.
(In reply to Drew Willcoxon :adw from comment #22)
> We should just disable this Tab behavior in the urlbar until Stephen
> comments.  You can still use Alt+Up/Down to cycle through the engines from
> the keyboard.

Yeah, that seems like the best solution until we figure out the desired behavior. Thank you!
Flags: needinfo?(shorlander)
Comment on attachment 8780298 [details]
Bug 1292321 - Pressing tab key in address bar selects one-off search buttons instead of the entries in the history dropdown list.

https://reviewboard.mozilla.org/r/71006/#review68710
Attachment #8780298 - Flags: review?(florian) → review+
Assignee: nobody → adw
Status: NEW → ASSIGNED
Pushed by dwillcoxon@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a31f07fbdc2e
Pressing tab key in address bar selects one-off search buttons instead of the entries in the history dropdown list. r=florian
https://hg.mozilla.org/integration/fx-team/rev/4cf5aa807f27376197743b62eff2b2c3c2891b44
Bug 1292321 - Pressing tab key in address bar selects one-off search buttons instead of the entries in the history dropdown list. r=florian
Sorry about that!
Flags: needinfo?(adw)
Interesting note on this feature.  If you Tab (now Alt+Down?) to the Search Options button then mouse-click on an item from the search suggestions, FF opens 'about:preferences#search' instead of the search suggestion.
https://hg.mozilla.org/mozilla-central/rev/4cf5aa807f27
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox51: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 51
I have reproduced this bug with Nightly 51.0a1 (2016-08-05) on Elementary OS 64bit. 

This bug's fix is now verified on Latest Nightly 51.0a1

build id 	20160817030202
user agent	Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0

[bugday-20160817]
I have reproduced this bug with 51.0a1 (2016-08-04) on windows 7 , 64 Bit!

This bug's fix is verified with latest Nightly

Build   ID    20160816030459
User Agent    Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0

 [bugday-20160817]
Thanks!
Status: RESOLVED → VERIFIED
status-firefox51: fixed → verified
Blocks: 1810557
You need to log in before you can comment on or make changes to this bug.