1713953 - New Tab page search bar not accessible with Tab key

Status: RESOLVED WONTFIX

(Firefox :: Address Bar, defect, P3)

Description

[[e-mail]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

1. Opened a new tab, which placed keyboard focus on the Location Bar in the new window.
2. Attempted to place keyboard focus on the in-content search bar by pressing the Tab key a few times.

Actual results:

Tab focus skips the search bar, making it impossible to focus on the search bar without clicking on it.

The order of which items receive focus are:
0. The URL bar itself

1. The set of toolbar icons to the right of the URL bar
2. The New Tab page itself
3. The "Personalize" button in the top-right hand corner of the page
4. Shortcut tiles below the search bar

Expected results:

Tab focus should be able to reach the in-content search bar.

A workaround is to disable the "browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar" pref.

Note that this issue affects the search bar in about:privatebrowsing (https://bugzilla.mozilla.org/show_bug.cgi?id=1538521). It seems this is a common issue with "handoff" search bars.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Address Bar' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Timea Cernea [:tbabos][inactive]]

Hi,
Thanks for submitting this issue, I can also reproduce this on all the latest Firefox versions on MacOS 10.15

Comment 3

[Drew Willcoxon :adw]

This seems like an unintentional regression, presumably from implementing handoff. I'll mark that as the regressing bug for now.

Comment 4

[Tudor Florea]

Is is possible that someone on Firefox is actualy try to look at the bug (or other similar) instead of just closing as duplicate of this awkward feature named "Enable new tab page handoff by default".
Thanks.
This is a bug not a feature.
The user should have a easy way of searching using a search engine (including the new private tab).
The new proton User interface is simply broken.
The solution should not involve tweaking about:config and or adding some newtab extension/plugin.

Comment 5

[Pascal Chevrel:pascalc (PTO until April 26)]

Drew, should we fix that for 90?

Comment 6

[Marco Bonardo [:mak]]

This should probably be fixed along with bug 1713827, when this bar has different functionality it makes sense that it is accessible separately. If it would have the same exact functionality of the urlbar every time, then this would rather be a wontfix.
Thus the real question is when we can fix bug 1713827 (and maybe bug 1645293, but that's a tad less problematic), fixing that would give value to this bug.

Comment 7

[Drew Willcoxon :adw]

Marco, I understand your comment, but to me this is simpler than that. You can still click in the in-content field to focus it, and the focus doesn't move to the urlbar until you start typing. I don't see why tabbing into it to focus it shouldn't also work, regardless of the outcome of those other bugs.

But I don't know why tabbing into it doesn't work anymore. If it's hard to fix for some reason, then OK, but if it's a simple fix, I do think we should fix it for 90.

Comment 8

[Marco Bonardo [:mak]]

Ah but I totally think we should fix it. I'm just saying that if the functionality of it would be 100% identical to the urlbar in all the cases, then the priority of the fix would be really low. I didn't look at the bug reasons, thus can't comment about difficulty.

Comment 9

[Marco Castelluccio [:marco]]

Drew, Marco, what are your plans regarding this? Are you waiting on bug 1713827 first?

Comment 10

[Drew Willcoxon :adw]

Amy, you've worked on newtab if I'm not mistaken? Do you know why tabbing into the search field doesn't work anymore and how hard it would be to fix?

Comment 11

[Amy Churchwell [:amy]]

(In reply to Drew Willcoxon :adw from comment #10)

Amy, you've worked on newtab if I'm not mistaken? Do you know why tabbing into the search field doesn't work anymore and how hard it would be to fix?

It looks like the field has a tabindex="-1" which explicitly prevents it from being focused, for some reason. It also has a class name of fake-editable which leads me to believe this was some kind of deliberate change. I know that making the search field fixed on scroll was a somewhat recent change, perhaps it's related. I can do some more digging, wanted to leave my initial observations.

Comment 12

[Marco Bonardo [:mak]]

I doubt we'll have a fix for uplift, we're not waiting for bug 1713827, this just needs an assignee.

Comment 13

[Amy Churchwell [:amy]]

Hi Ed, it looks like in https://phabricator.services.mozilla.com/D17455 we added fake-focus styles instead of native :focus styling and in https://phabricator.services.mozilla.com/D16394 we added tabIndex="-1" to the input field. It's not clear to me what the bug was, do you happen to remember? Any unintended consequences if we revert these changes to allow tabbing?

Also, Eitan & I have worked together on newtab accessibility issues before. Eitan, I would be interested in your thoughts. :) Is altering the tabIndex enough to make this accessible? I'm thinking it should probably be tabindex="4" ?

I will assign this to myself, but will not be able to start until July 6th.

Comment 14

[Ed Lee :Mardak]

There was some previous discussion about this in bug 1708009 comment 9. Looks like there were other bugs caused by having it tabbable.

Comment 15

[Amy Churchwell [:amy]]

(In reply to Ed Lee :Mardak from comment #14)

There was some previous discussion about this in bug 1708009 comment 9. Looks like there were other bugs caused by having it tabbable.

Seeing as https://bugzilla.mozilla.org/show_bug.cgi?id=1708009 was closed as a wontfix and it was agreed that the searchbox not being tabbable is expected behavior, it sounds like this bug is also a wontfix?

Comment 16

[Blake Winton (:bwinton) (:☕️)]

That sounds reasonable (although it feels weird to me as a user), but we should check with Asa (and possibly Jamie) first, to make sure that this is what they think we should do.

Comment 17

[James Teh [:Jamie]]

I did a bit of digging into this, as it seems there is a lot of context that has either been forgotten or is spread across so many places that it's impossible to reassemble. :)

The situation as to why this isn't tabbable is probably best explained by this comment in the code:

    // When search hand-off is enabled, we render a big button that is styled to
    // look like a search textbox. If the button is clicked, we style
    // the button as if it was a focused search box and show a fake cursor but
    // really focus the awesomebar without the focus styles ("hidden focus").

So, it "looks" like a search box, and when you click it, it "looks" like it has a cursor... but it's all fake. It's so fake that when you click it, we actually focus the awesomebar, except sighted users think we didn't.

That presents a problem with regard to making this tabbable. If we make it tabbable and we focus the awesomebar as soon as it has focus, that breaks tabbing through the New Tab page. If we don't focus the awesomebar as soon as it gets focus, we then have to intercept key presses, etc. and redirect focus (plus whatever we intercepted) to the awesomebar. My guess is that given the complexity here and the risks associated with intercepting and focusing things, a decision was made to just avoid all of that by not making it tabbable.

So, I think this will probably end up being another wontfix - I still think getting this to work is going to be more painful than it's worth - but I wanted to make sure we had a clear explanation of "why".