Shift + Tab to reach tabs through invisible components when focus on aboout:home searchbar

RESOLVED INVALID

Status

()

Firefox
Keyboard Navigation
RESOLVED INVALID
5 years ago
5 years ago

People

(Reporter: sindhus, Unassigned)

Tracking

({ux-consistency})

21 Branch
x86_64
Linux
ux-consistency
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Created attachment 760115 [details]
Screenshot of Firefox with new tab opening home page set to about:home. Notice the blue dotted line and refer to the bug description.

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release)
Build ID: 20130514193536

Steps to reproduce:

I have set my home page to be "about:home" as I like the search box it gives me. Every new tab is set to open my home page (about:home). Sometimes I want to go to the address to type an address directly. 

As I open a new tab and the focus is on the searchbar in it, I use shift + tab to tab back to the address bar. 


Actual results:

While doing so the focus goes on 2 components:
1. the mozilla logo
2. the entire about:home page itself

...before I have to **** + tab two more times to reach the addressbar.


Expected results:

Shift + tab from the about:home searchbar should shift cursor focus to address bar directly.
(Reporter)

Updated

5 years ago
Keywords: ux-consistency
(Reporter)

Updated

5 years ago
Component: Untriaged → Keyboard Navigation
The first shift-tab (given a focused search field in about:home) I see goes to the tab contents itself. The second goes to the navbar search box, and the third to the navbar URL box.

I think each step is technically correct (ie, the previously selectable element), but I can see how this would be undesirable in general.

The correct shortcut, if you want to specifically jump to the URL bar, would be Control/Command-L.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
(Reporter)

Comment 2

5 years ago
Tested the behaviour tab focus with Shift + tab (tab focus going in reverse direction) with a default config profile. 

http://i.imgur.com/6944reb.png

The tab focus starts with search box inside about:home page
Shift + tab > leads to Mozilla icon being focussed
Shift + tab > leads to about:home frame itself being foccussed 
Shift + tab > leads to searchbar (next to addressbar) being focussed
Shift + tab > leads to addressbar being foccused.

So, my case is that I have removed the searchbar (next to addressbar) and the shift+ tab should goes to addressbar instead. 

Question is why the tab focus on about:home frame itsefl? What's click-able or type-able for that?

The opinion of having no tab focus for mozilla icon is highly my personal choice. We can ignore that.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
(Reporter)

Comment 3

5 years ago
(In reply to Justin Dolske [:Dolske] from comment #1)
> The first shift-tab (given a focused search field in about:home) I see goes
> to the tab contents itself. The second goes to the navbar search box, and
> the third to the navbar URL box.
> 
> I think each step is technically correct (ie, the previously selectable
> element), but I can see how this would be undesirable in general.
> 
> The correct shortcut, if you want to specifically jump to the URL bar, would
> be Control/Command-L.

http://i.imgur.com/XPhoI7Y.png > Please observe the dotted gray outline over the entire area that displays about:home (I am calling it as a frame).

Is that necessary?
Pretty sure this is all expected, but CC Neil "focus masta" Deakin.
(Reporter)

Comment 5

5 years ago
I tested some more using the inspector and realised that the focus on body (which I have been calling as frame) is able to bring up a context menu when the right click key is pressed on keyboard. That said, now the focus makes sense for keyboard navigators and that focus on the body is not completely useless.

Closing bug. Thanks.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.