1190368 - Focus is immediately grabbed by the AutoComplete/tags or bookmarks suggestion list when you start typing in the awesome bar

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P1)

Description

[Marco Zehe (:MarcoZ)]

This is a recent regression. When one starts typing, and the list with search engine, tag or bookmark suggestions appears, focus is immediately grabbed (e. g. the first item highlighted) by the autocomplete list. It used to be that one had to explicitly down arrow into the list to take focus off the actual text field. Similarly, when an autofill suggestion appears, and one presses RightArrow to jump to the end of it, focus is not returned to the text field either, so a screen reader user can no longer verify what they typed. Keyboard input might still be accepted by the text field, but because focus sits on the list item within the autocomplete list box, those changes in the text field are no longer observed.

To reproduce:
1. Run Firefox with NVDA.
2. Open a new tab and start typing b u g z (for bugzilla).
3. Two things happen: AutoFill suggests bugzilla.mozilla.org, *and* a list of suggestions appears.

Previously, one could press RightArrow, and the highlight would be taken off the auto-filled text, and cursor placed at the end. *or* one could DownArrow and highlight the first search suggestion.

Now, the first suggestion geets highlighted/focused, and focus control is taken off the text field, so the auto-fill can no longer be used in a controlled fashion. Press right and left Arrow, and you won't hear NVDA announce the characters the cursor moves over.

Comment 1

[:Gijs (he/him)]

Marco (B), any idea what's changed here?

Comment 2

[Marco Bonardo [:mak]]

(In reply to Marco Zehe (:MarcoZ) from comment #0)
> This is a recent regression. When one starts typing, focus is immediately
> grabbed (e. g. the first item highlighted) by the autocomplete list.

This is part of the unified complete experience, the first entry in the popup is special and is pre-selected, it represents what happens when you confirm the input field contents with Enter.
Can you understand what the pre-selected entry contains or is it not announced?

> Similarly, when an autofill suggestion appears, and
> one presses RightArrow to jump to the end of it, focus is not returned to
> the text field either

This is strange, if I right on an autofill suggestion, the popup closes and the input field gets focus. The popup should not be able to steal focus since it's closed and from this point on right/left cursors should work like in a normal text field.

> Press right and left Arrow, and you won't hear NVDA
> announce the characters the cursor moves over.

Do you mean that generally you don't hear those announcements, or only after confirming an autofill entry?

Comment 3

[Marco Zehe (:MarcoZ)]

(In reply to Marco Bonardo [::mak] from comment #2)
> (In reply to Marco Zehe (:MarcoZ) from comment #0)
> > This is a recent regression. When one starts typing, focus is immediately
> > grabbed (e. g. the first item highlighted) by the autocomplete list.
> 
> This is part of the unified complete experience, the first entry in the
> popup is special and is pre-selected, it represents what happens when you
> confirm the input field contents with Enter.

Yes, but this is problematic, because focus is definitely stolen by the popup. The moment I start typing, and the popup appears, focus gets stolen from the text field. So, there is a disconnect between the actual cursor and the item with focus, as represented by the accessibility API. And the latter gets its information from the fact that the popup is there and something is selected in here.

> Can you understand what the pre-selected entry contains or is it not
> announced?

That's actually what bug 1190366 is about.

> > Similarly, when an autofill suggestion appears, and
> > one presses RightArrow to jump to the end of it, focus is not returned to
> > the text field either
> This is strange, if I right on an autofill suggestion, the popup closes and
> the input field gets focus. The popup should not be able to steal focus
> since it's closed and from this point on right/left cursors should work like
> in a normal text field.

Well, they don't. I cannot tell visually if the popup has disappeared or not. Fact is that focus, according to accessibility APIs, is on the list item, not the text field, that represents the first suggestion/action/search behavior or whatever. The thing is that, whatever I type that has an auto-fill, will most likely also have an item in my history, thus prompting the popup to appear.

> > Press right and left Arrow, and you won't hear NVDA
> > announce the characters the cursor moves over.
> 
> Do you mean that generally you don't hear those announcements, or only after
> confirming an autofill entry?

I no longer hear them generally. Left and Right arrows simply no longer talk as soon as I have typed something.

Comment 4

[Marco Bonardo [:mak]]

(In reply to Marco Zehe (:MarcoZ) from comment #3)
> So, there is a disconnect between the actual cursor and
> the item with focus, as represented by the accessibility API. And the latter
> gets its information from the fact that the popup is there and something is
> selected in here.

So as soon as there is a popup open with a selection, the accessibility API assumes it has focus even if it does not? This may be very problematic to fix on our side.
The input field has focus, the fact there's a popup with selection attached should not assume anything until the popup is focused too.
Does the same happen if you use Chrome with accessibility? cause they basically do the same, the popup is open with a selection, but the input field is focused.

> I no longer hear them generally. Left and Right arrows simply no longer talk
> as soon as I have typed something.

I suspect accessibility has a specific heuristic for the autocoplete interaction that always gives priority to the popup instead of the currently focused element. That would explain most of the problem.

Comment 5

[Marco Zehe (:MarcoZ)]

(In reply to Marco Bonardo [::mak] from comment #4)
> (In reply to Marco Zehe (:MarcoZ) from comment #3)
> > So, there is a disconnect between the actual cursor and
> > the item with focus, as represented by the accessibility API. And the latter
> > gets its information from the fact that the popup is there and something is
> > selected in here.
> 
> So as soon as there is a popup open with a selection, the accessibility API
> assumes it has focus even if it does not? This may be very problematic to
> fix on our side.

Well, it *did* work until recently, in that the first item needed to be selected explicitly. Furthermore, we could run into a situation where both the text field and the popup have a selection, which is confusing, to say the least.

> The input field has focus, the fact there's a popup with selection attached
> should not assume anything until the popup is focused too.
> Does the same happen if you use Chrome with accessibility? cause they
> basically do the same, the popup is open with a selection, but the input
> field is focused.

I'll have to check that. I don't keep a real history in Chrome, so they don't have much to auto-complete/suggest. ;)

> > I no longer hear them generally. Left and Right arrows simply no longer talk
> > as soon as I have typed something.
> I suspect accessibility has a specific heuristic for the autocoplete
> interaction that always gives priority to the popup instead of the currently
> focused element. That would explain most of the problem.

Support for the autocomplete/awesome bar popup was first introduced in bug 407359. It might have morphed a bit through code reorgs since then, but basically, the principles have been in effect since then. Perhaps that helps a bit to understand the interaction.

Comment 6

[Marco Bonardo [:mak]]

I installed nvda and I can reproduce the issue locally.
I noticed that a bunch of widget related NS_ERROR are fired by a11y code when the issue happens, something related to textbounds.

I'm not taking the bug though, cause my availability will be spotty in the next 2 weeks and I don't want to block this for weeks. If I figure out something I'll post it.

Comment 7

[:shell escalante]

Hi David, is there a better way to do this given screen readers?

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to :shell escalante from comment #7)
> Hi David, is there a better way to do this given screen readers?

Hi Shell, Marco can provide expert advice in this respect. I've cc'ed some people involved in the older bug 407359 work.

Comment 9

[Drew Willcoxon :adw]

(In reply to Marco Zehe (:MarcoZ) from comment #0)
> Press right and left Arrow, and you won't hear NVDA announce the
> characters the cursor moves over.

Marco Z., when I use Apple's VoiceOver, it doesn't announce the characters that my cursor moves over for any text field in Firefox, not only the URL bar.  Is that your experience too?  In contrast, when I tested with Safari, TextEdit, and other Apple apps, VoiceOver does announce characters under my cursor.  Maybe this one part is a problem with text fields in Firefox in general?

Comment 10

[Drew Willcoxon :adw]

(In reply to Marco Bonardo [::mak] (spotty available until 24 Aug) from comment #6)
> I noticed that a bunch of widget related NS_ERROR are fired by a11y code
> when the issue happens, something related to textbounds.

Maybe that's related to the one problem I just mentioned in comment 9.  I'll check.

Comment 11

[Trevor Saunders (:tbsaunde)]

(In reply to Drew Willcoxon :adw from comment #9)
> (In reply to Marco Zehe (:MarcoZ) from comment #0)
> > Press right and left Arrow, and you won't hear NVDA announce the
> > characters the cursor moves over.
> 
> Marco Z., when I use Apple's VoiceOver, it doesn't announce the characters
> that my cursor moves over for any text field in Firefox, not only the URL
> bar.  Is that your experience too?  In contrast, when I tested with Safari,
> TextEdit, and other Apple apps, VoiceOver does announce characters under my
> cursor.  Maybe this one part is a problem with text fields in Firefox in
> general?

I believe that may be true on mac, but its not true on linux, and I expect windows.

(In reply to Drew Willcoxon :adw from comment #10)
> (In reply to Marco Bonardo [::mak] (spotty available until 24 Aug) from
> comment #6)
> > I noticed that a bunch of widget related NS_ERROR are fired by a11y code
> > when the issue happens, something related to textbounds.
> 
> Maybe that's related to the one problem I just mentioned in comment 9.  I'll
> check.

I think those have been around for a long time so I suspect not.  From my experience I'd guess the reason character movement doesn't read anything is that the text field isn't actually focused, and so your not actually moving the cursor.

Comment 12

[Marco Zehe (:MarcoZ)]

(In reply to Drew Willcoxon :adw from comment #9)
> (In reply to Marco Zehe (:MarcoZ) from comment #0)
> > Press right and left Arrow, and you won't hear NVDA announce the
> > characters the cursor moves over.
> 
> Marco Z., when I use Apple's VoiceOver, it doesn't announce the characters
> that my cursor moves over for any text field in Firefox, not only the URL
> bar.  Is that your experience too?  In contrast, when I tested with Safari,
> TextEdit, and other Apple apps, VoiceOver does announce characters under my
> cursor.  Maybe this one part is a problem with text fields in Firefox in
> general?

No, that's a totally unrelated bug. What you were seeing there is bug 914052, which is an incomplete implementation of the Mac NSAccessibility APIs when it comes to retrieving text the cursor moves over. So testing this bug here on Mac with VoiceOver is currently a no-go. We have to use Windows or Linux, and what Trevor says in comment #11 is true: We used to not set focus to the list automatically, but since a fairly recent change that possibly coincided with the addition of the search engine bit, we do, and that breaks navigating the actual address text field.

Comment 13

[Drew Willcoxon :adw]

Thanks guys.  My Windows build is still going (very slowly...), and I'll test myself when it's done.  But in the meantime, given our time zone difference, could you please try the build I'll link below?  It's a shot in the dark, but all it does it focus the urlbar after selecting the first item in the popup.

https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-bfc262923355

Comment 14

[Marco Zehe (:MarcoZ)]

I see no chane in behavior with this try build. Focus still goes to the first item and stays in the list unless everything in the field is deleted and the list goes away.

Comment 15

[Drew Willcoxon :adw]

Marco, I'm sorry to say that I really don't know what I'm doing here, neither in testing this on Windows nor in the a11y code.  I downloaded NVDA for Windows, but its output seems wrong or at least different from VoiceOver's.  For example, it just says "unknown" whenever I highlight an item in the urlbar popup.

Would it be possible for someone on the a11y team to work on this for us?

Comment 16

[Drew Willcoxon :adw]

Marco, could you please try this build?  https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-622273b8013c

Thanks for your patience in this bug, by the way.

When I type the first character, NVDA stops speaking "list" followed by the first item in the popup when I comment out the _fireEvent("DOMMenuItemActive") line here: http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/listbox.xml#916

I'm guessing that the DOMMenuItemActive is what tells the accessibility software that the first item is "focused"?  This build simply sets a flag on the listbox item that tells it not to fire the event.  No idea whether that messes up other stuff.

Comment 17

[Marco Zehe (:MarcoZ)]

OK, this build is better, in that it no longer automatically draws the focus to the list. I can now type and the screen reader still sees me in the text field. When I then press DownArrow, I land on the second item. So when the list finally gets focus, the second item is highlighted, because the first was pre-selected before. But I guess considering that one lands on the same thing as before (bookmark, keyword or tag), that is kind of OK. The cleaner solution would, of course, be, to only select, but not focus, the first item when the user is typing, and when they pressDownArrow, actually focus it. But again, this is better than before.

Comment 18

[Marco Bonardo [:mak]]

I suppose the problematic call is the one in the "current" setter in listitem code? If so I guess we could make it send the event only if the listbox is actually focused... provided that doesn't break selection/behavior. Or a11y code could ignore the event if the element issuing the event is not focused.

Comment 19

[Drew Willcoxon :adw]

(In reply to Marco Bonardo [::mak] (spotty available until 24 Aug) from comment #18)
> I suppose the problematic call is the one in the "current" setter in
> listitem code?

Yes.

Comment 20

[Drew Willcoxon :adw]

(In reply to Marco Zehe (:MarcoZ) from comment #17)
> But I guess considering that one lands on the same thing as before
> (bookmark, keyword or tag), that is kind of OK.

I think that's the best we can do.  That matches up with what's happening visually for sighted users.

> The cleaner solution would, of course, be, to only select, but not focus,
> the first item when the user is typing, and when they pressDownArrow,
> actually focus it. But again, this is better than before.

I'm interested in what you mean by "only select, but not focus."  Is that not what this most recent build does?  If not, what is the difference between selecting and focusing for a screen reader?

However, pressing the down arrow key to focus the first item is just not possible given the interaction design of Unified Complete -- for both sighted and non-sighted users.  Because by design, the first item is pre-selected, as you say, so pressing down selects the next and second item.  In other words, I think the part of your comment that I quoted here is not specific to accessibility but is a comment on the interaction design.  (But maybe I'm misunderstanding.)

Comment 21

[Drew Willcoxon :adw]

(In reply to Marco Bonardo [::mak] (spotty available until 24 Aug) from comment #18)
> I suppose the problematic call is the one in the "current" setter in
> listitem code? If so I guess we could make it send the event only if the
> listbox is actually focused... provided that doesn't break
> selection/behavior. Or a11y code could ignore the event if the element
> issuing the event is not focused.

Problem with that is that the input remains focused, as far as the DOM is concerned, the whole time you're interacting with the popup with the arrow keys.

Some relevant code:

XULListboxAccessible::IsActiveWidget
http://mxr.mozilla.org/mozilla-central/source/accessible/xul/XULListboxAccessible.cpp#477

FocusManager::ActiveItemChanged
http://mxr.mozilla.org/mozilla-central/source/accessible/base/FocusManager.cpp#169

Comment 22

[Drew Willcoxon :adw]

Attachment: patch

This takes advantage of the widget->AreItemsOperable() check here: http://mxr.mozilla.org/mozilla-central/source/accessible/base/FocusManager.cpp#188

It adds a new attribute to nsIAutoCompletePopup called isActive, which tells the a11y code whether the popup should be considered active.  The a11y code checks it in XULListboxAccessible::IsActiveWidget.  As far as I can tell, this IsActiveWidget method exists exactly for this kind of check, so that's cool.

The base autocomplete popup binding defaults to isActive=true, and then the urlbar binding overrides it when setting the initially selected index.

r? for both toolkit and a11y changes.

Comment 23

[Drew Willcoxon :adw]

Builds here: https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-e4f038c9a6ea

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e4f038c9a6ea

Comment 24

[Marco Zehe (:MarcoZ)]

Comment on attachment 8652110 [details] [diff] [review]
patch

Review of attachment 8652110 [details] [diff] [review]:
-----------------------------------------------------------------

::: accessible/xul/XULListboxAccessible.cpp
@@ +487,5 @@
> +        return false;
> +      }
> +      bool isActive = false;
> +      autoCompletePopupElm->GetIsActive(&isActive);
> +      return isActive;

This needs an a11y mochitest here: http://mxr.mozilla.org/mozilla-central/source/accessible/tests/mochitest/events/test_focus_autocomplete.xul

Comment 25

[Marco Zehe (:MarcoZ)]

Comment on attachment 8652110 [details] [diff] [review]
patch

Review of attachment 8652110 [details] [diff] [review]:
-----------------------------------------------------------------

This patch doesn't work like the previous one did. When I start typing, I now hear the auto-complete first, then the first list item again gets accessibility focus. Pressing left and right arrows does again not speak the characters I arrow over. At some point, pressing up or down arrows will snap back to the address bar, which is a difference to current nightly builds, but left and right arrows should immediately do that and set accessibility focus back to the URL bar. So either something is missing in this patch, or the method doesn't work as reliably as thought. Sorry to be a pain with this, but the current user experience for screen reader users is simply no longer acceptable. :(

Comment 26

[Drew Willcoxon :adw]

Attachment: front-end patch

OK, here's a cleaned-up patch for the first build I posted, the one that worked.  It's entirely in the front-end and it seems pretty hacky to me but if it works it works.

Marco Z., is that acceptable?  As I said, I think that's the best we can do given UnifiedComplete's interaction design.  Unless it's possible to switch to a different design at runtime when the user is using a screen reader?

Builds: https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-16ae44d8bfa3

https://treeherder.mozilla.org/#/jobs?repo=try&revision=16ae44d8bfa3

Comment 27

[James Teh [:Jamie]]

(In reply to Drew Willcoxon :adw from comment #15)
> it just says "unknown" whenever I highlight an
> item in the urlbar popup.
I'm seeing this as well. A bit of poking reveals that this occurs if the search suggestions prompt is displayed; i.e. browser.urlbar.userMadeSearchSuggestionsChoice is false. The list appears in a separate MozillaDropShadowWindowClass HWND. However, WM_GETOBJECT returns the label for the search suggestions prompt and accChild for the search list items fails on this label accessible.

When the search suggestions prompt is *not* displayed, the list works as expected. In that case, WM-GETOBJECT on the MozillaDropShadowWindowClass returns the list (as expected) and therefore accChild works.

Comment 28

[Marco Zehe (:MarcoZ)]

(In reply to Drew Willcoxon :adw from comment #26)
> Marco Z., is that acceptable?  As I said, I think that's the best we can do
> given UnifiedComplete's interaction design.  Unless it's possible to switch
> to a different design at runtime when the user is using a screen reader?

If possible, I'd like to avoid that. I still don't understand how something that has focus in two places at once can be considered unambiguous, even for sighted users. To me, it seems logical to indicate visually to indicate that the search will be executed, but pretending to have focus in two places at once just seems completely wrong to me.

(In reply to James Teh [:Jamie] from comment #27)
> (In reply to Drew Willcoxon :adw from comment #15)
> > it just says "unknown" whenever I highlight an
> > item in the urlbar popup.
> I'm seeing this as well. A bit of poking reveals that this occurs if the
> search suggestions prompt is displayed; i.e.
> browser.urlbar.userMadeSearchSuggestionsChoice is false. The list appears in
> a separate MozillaDropShadowWindowClass HWND. However, WM_GETOBJECT returns
> the label for the search suggestions prompt and accChild for the search list
> items fails on this label accessible.

So, this is using yet another popup implementation that differs from the ones we already have, like doorhangers or info bars? Yikes, this is killing me... :(

Thanks for investigating this, Jamie! Since this prompt doesn't even fire an alert, and I was told early on to turn this pref on to get it working altogether, so I actually never saw this prompt and thus didn't run into the problem of the "unknown" accessibles.

jamie, if you think this is a separate issue, please file a bug.

Comment 29

[:Gijs (he/him)]

(In reply to Marco Zehe (:MarcoZ) from comment #28)
> (In reply to Drew Willcoxon :adw from comment #26)
> > Marco Z., is that acceptable?  As I said, I think that's the best we can do
> > given UnifiedComplete's interaction design.  Unless it's possible to switch
> > to a different design at runtime when the user is using a screen reader?
> 
> If possible, I'd like to avoid that. I still don't understand how something
> that has focus in two places at once can be considered unambiguous, even for
> sighted users. To me, it seems logical to indicate visually to indicate that
> the search will be executed, but pretending to have focus in two places at
> once just seems completely wrong to me.

It is possible everywhere for an item (or even multiple items) in a list to be selected, and for another element to be focused, which is all that's going on here. The fact that the a11y code indicates the listbox has focus is wrong.

For a comparison, if you are in a textarea (like this one for bugzilla comments) and hit 'alt' on windows, the textbox keeps focus (cursor keeps blinking, focus style persists and everything) but the "File" menu is selected - when you arrow left/right, you select different menus, and only when you go into one of the menus, the focus disappears from the textbox... Presumably that, too, is a result of the DOMMenuItemActive thing, which I find pretty weird to be happening on listboxes, but here we are...

> (In reply to James Teh [:Jamie] from comment #27)
> > (In reply to Drew Willcoxon :adw from comment #15)
> > > it just says "unknown" whenever I highlight an
> > > item in the urlbar popup.
> > I'm seeing this as well. A bit of poking reveals that this occurs if the
> > search suggestions prompt is displayed; i.e.
> > browser.urlbar.userMadeSearchSuggestionsChoice is false. The list appears in
> > a separate MozillaDropShadowWindowClass HWND. However, WM_GETOBJECT returns
> > the label for the search suggestions prompt and accChild for the search list
> > items fails on this label accessible.
> 
> So, this is using yet another popup implementation that differs from the
> ones we already have, like doorhangers or info bars? Yikes, this is killing
> me... :(

The prompt is inside the listbox because that makes visual sense. The same happens on Android, IIRC. I'm not sure how to make sense of it in terms of accessibility, but there we are. We can take a look in Toronto if we don't figure it out beforehand.

> Thanks for investigating this, Jamie! Since this prompt doesn't even fire an
> alert, and I was told early on to turn this pref on to get it working
> altogether, so I actually never saw this prompt and thus didn't run into the
> problem of the "unknown" accessibles.
> 
> jamie, if you think this is a separate issue, please file a bug.

Yes, this should be a separate bug.

Comment 30

[James Teh [:Jamie]]

Maybe I'm missing something, but why is this list box widget even firing DOMMenuItemActive on the selected item if the list box doesn't have focus? That suggests there must be a list box out there which *doesn't* get focus but we want to fake it for accessibility for some reason, which is weird at best. That sort of hackery makes sense for menus, but I wouldn't have thought it made sense for list boxes.

Comment 31

[:Gijs (he/him)]

(In reply to James Teh [:Jamie] from comment #30)
> Maybe I'm missing something, but why is this list box widget even firing
> DOMMenuItemActive on the selected item if the list box doesn't have focus?

This is a fair question, and would maybe enable a less hacky fix.

> That suggests there must be a list box out there which *doesn't* get focus
> but we want to fake it for accessibility for some reason, which is weird at
> best. That sort of hackery makes sense for menus, but I wouldn't have
> thought it made sense for list boxes.

Well, no, you're assuming malice where simple mistakes would suffice (ie, not checking for focus - just always firing that event whenever the current item in the listbox changes, irrespective of focus state). Very old mistakes, looking at gecko-dev blame (this goes back to CVS days).

Looks like the events were first added by Aaron in bug 301737.

Note that really, the only way this would happen is if people programmatically change the selected item(s) in a listbox, which is presumably rare because it seems nobody noticed this up until now.

Comment 32

[:Gijs (he/him)]

bug 298371 is potentially also relevant, if people want to re-do some of my archaeology:

https://github.com/mozilla/gecko-dev/blame/master/toolkit/content/widgets/listbox.xml

https://github.com/mozilla/gecko-dev/commit/ac1ea6de1bb1e84be69f7db4929f0ee640f22e40
-> parent to see what put the older lines there:

https://github.com/mozilla/gecko-dev/blame/e258d2655832f297a64f2657d67ff654fc5d7b86/toolkit/content/widgets/listbox.xml#L219-L224

Comment 33

[:Gijs (he/him)]

Hm, thinking about it some more, it seems technically people normally care about the selected item in a listbox changing, even if it happens as a result of e.g. pressing another button (that has and keeps focus) ?

If we made the listbox not report selection changes at all unless it had focus, this means that arrowing up/down from the location bar would no longer trigger a selection change either. The selection is also represented in the textbox that will keep focus throughout, so maybe that's not a bad thing per se? I'm not sure.

Comment 34

[Marco Zehe (:MarcoZ)]

Again, the current (until Dev Edition at least) behavior was introduced in bug 407359. I believe Aaron had to do this trickery because logically, from a DOM point of view, focus never leaves the text field in the address bar, but visually, selection occurs in the list box that drops down as soon as the suggestions appear. Due to the hell that is Windows menu modes, we decided to not go that route, since that confused the hell out of JAWS and Window-Eyes, and probably still would today. Instead, to make this work somehow, Aaron did this DOMMenuItem thing to fire fake focus events so we could arrow up and down through the list and actually hear something. Left and right arrows would then snap focus back to the edit field.

In essence, Aaron took advantage of the Windows behavior that Gijs just described in comment #29. With the difference that the items the focus is fired on this time aren't menu bar items, but list box items in the suggestions list. Back then we simply didn't find any other way to satisfy the legacy screen readers.

Comment 35

[Marco Zehe (:MarcoZ)]

For reference on why the menu/popup menu/whatever menu thing on Windows is so bad, I wrote something about it last year in the context of an ARIA tip that has to do with - surprise - auto completes: https://www.marcozehe.de/2014/03/11/easy-aria-tip-7-use-listbox-and-option-roles-when-constructing-autocomplete-lists/

Comment 36

[Marco Bonardo [:mak]]

(In reply to Marco Zehe (:MarcoZ) from comment #34)
> from a DOM point of view, focus never leaves the text field in the address bar,
> but visually, selection occurs in the list box that drops down as soon as
> the suggestions appear.

This is still what happens, but while before there was no selection, now there is one. As I said this is the same thing that Chrome and Edge do in their urlbar, so it's not exotic at all and we need proper support for it.

Regardless, I think it may not be a good idea to uplift complex changes to a11y, I'd personally go for a workaround here, and file a follow-up to find a better solution in a11y to support the case where one element is focused and its changes cause a selection change in a not focused listbox.
Could you please test the builds in 26, if you didn't yet?

Comment 37

[Marco Bonardo [:mak]]

sorry for the typo, I meant builds in comment 26

Comment 38

[James Teh [:Jamie]]

(In reply to :Gijs Kruitbosch from comment #33)
> If we made the listbox not report selection changes at all unless it had
> focus, this means that arrowing up/down from the location bar would no
> longer trigger a selection change either.
Oh. Sorry. Somehow, I got the impression the list box actually got focus when you hit up/down arrow. If it doesn't, we definitely want it to from an accessibility perspective.

IMO, it actually does make sense for these list items (other than the first) to be "focused" in terms of accessibility. I'd argue they are logically focused because keyboard commands are handled by the list/list item, which is the primary point of "focus", hence it often being called "keyboard focus". The same is true for menus.

Comment 39

[:Gijs (he/him)]

(In reply to James Teh [:Jamie] from comment #38)
> (In reply to :Gijs Kruitbosch from comment #33)
> > If we made the listbox not report selection changes at all unless it had
> > focus, this means that arrowing up/down from the location bar would no
> > longer trigger a selection change either.
> Oh. Sorry. Somehow, I got the impression the list box actually got focus
> when you hit up/down arrow. If it doesn't, we definitely want it to from an
> accessibility perspective.
> 
> IMO, it actually does make sense for these list items (other than the first)
> to be "focused" in terms of accessibility. I'd argue they are logically
> focused because keyboard commands are handled by the list/list item, which
> is the primary point of "focus", hence it often being called "keyboard
> focus". The same is true for menus.

Why? Characters you type go into the input box at the cursor insertion point, and we want the cursor insertion point to be visible...

Comment 40

[James Teh [:Jamie]]

(In reply to :Gijs Kruitbosch from comment #39)
> > IMO, it actually does make sense for these list items (other than the first)
> > to be "focused" in terms of accessibility. I'd argue they are logically
> > focused because keyboard commands are handled by the list/list item...
> Why?
Because the arrow keys change the selected list item, so they're (directlyor indirectly) going to the list.

> Characters you type go into the input box at the cursor insertion
> point, and we want the cursor insertion point to be visible...
True enough. This autocomplete pattern is currently not handled well by accessibility APIs. In a sense, two things have the "focus" as far as the user is concerned. In theory, a better way to do this might be to expose a controlledBy relation on the list pointing at the location bar. Screen readers would then handle selection events for lists if the list was "controlled by" the focus. This is actually how search suggestions are (supposedly) exposed via UI Automation for the Windows 10 Start Menu. However, getting all ATs to support this would probably be rather tricky.

Comment 41

[Marco Zehe (:MarcoZ)]

(In reply to Marco Bonardo [::mak] (spotty available until 24 Aug) from comment #36)
> Could you please test the builds in 26, if you didn't yet?

The build works, except for one thing:
1. Type something.
2. DownArrow to select the second list item.
3. Press left or right arrow.

Result: Focus used to go back to the text field for a11y before this whole introduction of the search UI. Now, it doesn't. I have to press an up and down arrow in addition to make focus go back to the text field.

Comment 42

[Marco Zehe (:MarcoZ)]

Chrome on Windows, btw, never focuses any list item. When up and down arrowing, it simply fills the edit field with search suggestions it comes up with. Even though I also have some things in my browser history that matched what I typed, it never suggested those to me, so I can't tell how they would expose history, bookmarks or other such items to the screen reader user. So for Chrome, keyboard focus never leaves the text field.

Comment 43

[Marco Bonardo [:mak]]

(In reply to Marco Zehe (:MarcoZ) from comment #41)
> Result: Focus used to go back to the text field for a11y before this whole
> introduction of the search UI.

Interesting, right or left cause the popup to close and the text field has focus (autocomplete.xml forces a _focus call on popuphiding, likely for accessibility reasons).
The behavior is exactly the same as old autocomplete, if it doesn't work anymore there may be more to fix.

Comment 44

[James Teh [:Jamie]]

(In reply to Marco Zehe (:MarcoZ) from comment #42)
> Chrome on Windows, btw, never focuses any list item. When up and down
> arrowing, it simply fills the edit field with search suggestions it comes up
> with.
I'm guessing that like Firefox, that's basically how it works for sighted users too, but they do see the selected item. The problem is that a screen reader doesn't read the selected item unless it gets focus. The problem with the current Chrome approach is that you lose additional info in the list item that *doesn't* appear in the text box; e.g. the text "Google search".

Comment 45

[Marco Zehe (:MarcoZ)]

(In reply to James Teh [:Jamie] from comment #44)
> (In reply to Marco Zehe (:MarcoZ) from comment #42)
> > Chrome on Windows, btw, never focuses any list item. When up and down
> > arrowing, it simply fills the edit field with search suggestions it comes up
> > with.
> I'm guessing that like Firefox, that's basically how it works for sighted
> users too, but they do see the selected item. The problem is that a screen
> reader doesn't read the selected item unless it gets focus. The problem with
> the current Chrome approach is that you lose additional info in the list
> item that *doesn't* appear in the text box; e.g. the text "Google search".

Yes, that's what I thought, too. So, we are doing it better than Chrome, and I would like it to stay that way. :) Thanks for confirming!

Comment 46

[Marco Bonardo [:mak]]

Drew, do you plan to look into comment 41 here, or should I evaluate the patch as-is (afaict it looks ok)

Comment 47

[Drew Willcoxon :adw]

Comment on attachment 8652598 [details] [diff] [review]
front-end patch

Sorry, meant to clear review on this since I am trying to fix comment 41.  Thanks for asking.

Comment 48

[Drew Willcoxon :adw]

Comment on attachment 8652598 [details] [diff] [review]
front-end patch

Comment 41 was caused by bug 1174471, and it happens even with UnifiedComplete disabled.  I filed bug 1200322 for it.

So I think we should take this patch if it works, and fix bug 1200322 separately?

Comment 49

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/5f6c64cb49dc

Comment 50

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/5f6c64cb49dc

Comment 51

[Drew Willcoxon :adw]

Comment on attachment 8652598 [details] [diff] [review]
front-end patch

Approval Request Comment
[Feature/regressing bug #]:
UnifiedComplete, the new urlbar back-end, bug 995091, which we are trying to enable in 42.

[User impact if declined]:
It will be very difficult for people who use screen readers to use the urlbar.

[Describe test coverage new/current, TreeHerder]:
No new test, UnifiedComplete is covered by existing tests, multiple people have tested this patch manually.

[Risks and why]:
Low risk, fairly small and well understood change.

[String/UUID change made/needed]:
None

Comment 52

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8652598 [details] [diff] [review]
front-end patch

ok, recent regression, taking it.

Comment 53

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/5133f5c9fff0

Comment 54

[Petruta Horea [:phorea], Desktop Test Engineering]

Verified with Firefox 42 beta 1 and Developer Edition 43.0a2 2015-09-23 nder Win 7 64-bit with NVDA. Issues reported seem fixed now, but I'm not sure what NVDA should actually say for each suggestion.

Marco, could you please confirm this works correctly now? Thank you!

Comment 55

[Marco Zehe (:MarcoZ)]

Yup it does. There may still be some new uplifts to dev edition that are follow-ups to a dependent bug, but if that happens, I'll make sure everything works as expected.

Comment 56

[Petruta Horea [:phorea], Desktop Test Engineering]

Thanks a lot, Marco!

Marking as verified.