1614833 - Tabbing through address bar and separate search bar results in inconsistent behavior

Status: RESOLVED DUPLICATE of bug 1437524

(Firefox :: Address Bar, defect, P3)

Description

[Asif Youssuff]

Spawned from bug 1608766

I noticed while testing the new behavior in bug 1608766, that tabbing through the search box and address bar results in inconsistent behavior.

Steps to reproduce:

1. Enable separate search bar.
2. Do control-l or control-k
3. type in query
4. press tab key

What happens:

The result is inconsistent.

In the address bar, tapping tab moves focus to the search box.
In the search box, tapping tab moves focus through the one off search engines.

Expected result:

The behavior should be consistent. I would prefer to have tab move focus to the one off search engines in both places, but that does open up some questions about whether tab should move through the engines (this was rejected in 1608766 for autocomplete entries) -- this may be solved by using the arrow keys to move between search engines once focus has moved to the search engines.

FWIW, the arrow keys (both left and right and up and down) both work in the separate search box to move the selection between search engines.

I think that ideally, the interaction would look like this (for example on this page):

1. Control-l
2. tab (this moves to one off search engines)
3. User can switch between search engines using arrow keys
4. tab (this moves to "change search settings")
5. tab (user is moved to separate search box)
6. tab (this moves to one off search engines)
7. tab (this moves to "add search engine")
8. tab (this moves to "change search settings")

That would result in a consistent user interaction and expected results when using tab.

Comment 1

[jeff.gandt]

I see similar behavior. I have enumerated my prequisites and scenarios in a slightly different way. Hopefully it will help in understand expected behavior (consistent with live 73.0.1) and the bug I am encountering.

The first two scenarios match the behavior of 73.0.1 and are included for context/reference.

Prereq:

Mac
browser.toolbars.keyboard_navigation set to true (default)

Scenario 1 (behavior matches live)

Steps

1. New Tab via Cmd+T
2. Address bar should be focused
3. No text is entered in the address bar

Expectation:

Tab key should navigate through toolbar items

Actual:

Behavior matches live (73.0.1). Does not focus all items on toolbar.

Scenario 2 (behavior matches live)

Steps

1. New Tab via Cmd+T
2. Address bar should be focused
3. No text is entered in the address bar
4. click on address bar
5. autocomplete/suggestions appear

Expectation:

Tab key should navigate through toolbar items

Actual:

Behavior matches live (73.0.1). Cycles through autocomplete/suggestion results

Scenario 3 (does not match live and is seemingly broken)

Prereq:

Mac
browser.toolbars.keyboard_navigation set to true (default)

Steps

1. New Tab via Cmd+T
2. Address bar should be focused
3. No text is entered in the address bar
4. type something that is expected to have completions in the address bar
5. autocomplete/suggestions appear

Expectation:

Tab key should navigate through toolbar items

Actual:

Tab key shifts focus to next toolbar item.

Layman's conclusion

This appears to be a problem with the address bar properly capturing focus when characters are typed in.

Comment 2

[Marco Bonardo [:mak]]

If the panel is closed, tab moves to the next widget.
If the panel is open, tab moves through results, this was and is still being discussed at length in bug 1437524, we may or may not introduce a preference to make it easier to access one-off buttons, but it's all there in bug 1437524.
We don't plan to support other behaviors apart from those for now.