New search box focuses every search engine between awesome bar and web page

NEW
Unassigned

Status

()

defect
P3
normal
Rank:
35
4 years ago
2 years ago

People

(Reporter: rfeeley, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fxsearch])

Reporter

Description

4 years ago
Steps to reproduce:
- User has previously entered search term in the search box
- User has focus in the address bar
- User is on a web page with a text input (e.g. search field)
- User tabs from awesomebar and new search box expands, requiring user to tab through every search engine before getting field on web page
How would you propose fixing this, without harming the keyboard accessibility of the search panel?

(FWIW F6 is a mostly undiscoverable alternative way to shift focus between the content area and the location bar.)
Reporter

Comment 2

4 years ago
Currently if the user clicks in the field again, the search suggestions collapse. Ideally they could be put directly into this state by tabbing from previous area. If they want to expand it, they can press down arrow or click in it. Make sense?
Flags: needinfo?(gavin.sharp)
Yeah maybe. I think the "panel is open while you're typing" behavior was intentional and considered important, but maybe this is a case worth making an exception for.
Flags: needinfo?(gavin.sharp) → needinfo?(philipp)
(In reply to Ryan Feeley from comment #2)
> Currently if the user clicks in the field again, the search suggestions
> collapse. Ideally they could be put directly into this state by tabbing from
> previous area. If they want to expand it, they can press down arrow or click
> in it. Make sense?

Hm, what you describe makes sense.
The "always keep it open" behavior was mostly for the case where a user would click into the search field (which is a clear indication that he wants to use it), whereas the user could also focus it on his way to some other place.

If we make an exception to that behavior when tabbing to the search field, would we break any other use cases?
Flags: needinfo?(philipp)
Reporter

Comment 5

4 years ago
I don't think it would, but I would have to defer to Gavin on that.
Flags: needinfo?(gavin.sharp)
I can't think of any problems with that approach, but Florian has thought about this more than I have.
Flags: needinfo?(gavin.sharp) → needinfo?(florian)
(In reply to Ryan Feeley from comment #2)
> Currently if the user clicks in the field again, the search suggestions
> collapse.

Assuming you meant the text field, this used to be the case, but was a bug that has been fixed a relatively long time ago. However, if you click the search icon, the panel is (intentionally) closed.

(In reply to Philipp Sackl [:phlsa] please use needinfo from comment #4)

> If we make an exception to that behavior when tabbing to the search field,
> would we break any other use cases?

Is this really an exception, or are you proposing that we remove the last case where the panel gets opened due to the searchbox receiving focus? (we already added a few exceptions, eg. when opening the context menu or when the searchbox receives focus due to the window receiving focus)
Flags: needinfo?(florian) → needinfo?(philipp)
> (In reply to Philipp Sackl [:phlsa] please use needinfo from comment #4)
> 
> > If we make an exception to that behavior when tabbing to the search field,
> > would we break any other use cases?
> 
> Is this really an exception, or are you proposing that we remove the last
> case where the panel gets opened due to the searchbox receiving focus? (we
> already added a few exceptions, eg. when opening the context menu or when
> the searchbox receives focus due to the window receiving focus)

There would still be the case of the user focusing the text field by clicking (more explicit) as opposed to using the tab key.

That being said, I'm leaning more and more towards a wontfix for this. It's an edge case within an edge case and the popup can be closed at any time by pressing the esc key.
Flags: needinfo?(philipp)
Reporter

Comment 9

4 years ago
(In reply to Philipp Sackl [:phlsa] please use needinfo from comment #8)
> That being said, I'm leaning more and more towards a wontfix for this. It's
> an edge case within an edge case and the popup can be closed at any time by
> pressing the esc key.

This is a new issue introduced by the new search UI. I wish we had numbers on how many people close the search box without searching for anything. If it has gone up since the new design, it's affecting people.
Priority: -- → P3
Whiteboard: [fxsearch]

Updated

4 years ago
Rank: 35
Just 5c about a11y:
* Ideally tabbing thought popup under the search should not happen, if focus is on the input, tab or shift tab should move focus normally to the next/previous focusable item outside of the popup.
* User should however be able to step into and navigate the popup (suggestions+search engines) with arrow keys with maintaining the focus on the input field. Tabbing away from input should dismiss the popup even if the user is arrowing around in the popup.
You need to log in before you can comment on or make changes to this bug.