I suspect this is a regression of Bug 1678323 related to unsetting tabIndex, but I didn't verify that explicitly.
When voiceover is enabled it doesn't announce one-off buttons when moving through them with the keyboard, either in the urlbar or in the search bar. This bug doesn't happen with nvda on Windows, afaict.

Isn't this the same issue as bug 1665094 ?

(In reply to Adrian Florinescu [:aflorinescu] from comment #1)

Isn't this the same issue as bug 1665094 ?

That's about mouse over, here we don't announce them also when they are keyboard selected.
We should verify the regrange probably, since I guessed it.

Hmm. I wouldn't expect changing tabindex to break this, since it still has a tabindex of -1 (so it's still "focusable" even though it's not "tabbable") and (I think?) focus is actually controlled with aria-activedescendant in this case.

Thanks Jamie, I'll look for a proper regression range.

Hi! Can you post a STR?

I'm just typing something in the urlbar, then pressing "down" until I reach the search shortcut buttons

I can get VO to read them if I use the VO commands (ctrl+option+arrows), but yes I can confirm they don't work with VO when you navigate with the keyboard arrow keys

EDIT: I think maybe I misunderstood the bug initially -- VO reads them for me if I use either the VO commands or the keyboard arrow keys, but the VO cursor doesn't follow focus when I use the latter. Is that the problem, or am I not reproducing this correctly?

The problem is that this issue is intermittent, sometimes it works, sometimes it doesn't. The video doesn't show the bug, when the bug happens selecting the search shortcuts at the end of the panel only says "You are in a menu", that is not particularly useful.
The exact steps I used to find the regression range are complex. In practice for each build I spent a few seconds typing in the urlbar, moving with the keyboard through results and search shortcuts (like in your video), closing the urlbar and repeating at variable speeds. The bug may happen immediately or after a few tries. It took almost 2 hours to find the range.

Doing that I found a regression range that I think it's correct enough, and it points to either Bug 1699551 or Bug 1691553, and it seems to make sense since it's a Mac only change related to menus. Something there is confusing voiceover or our a11y code and once the bug happens it seems to persist for a while.
Markus, it looks like your changes somehow caused this intermittent VoiceOver issue.

Hmm, it sounds like no menu is open during those steps to reproduce. Both bug 1699551 and bug 1691553 affect code that should only be executed when a menu is open.
It would be great if we could find more consistent steps to reproduce for this bug, in order to double-check the regression range and to allow debugging it.

I found reliable STR for both my OS 11 and my OS 10.15 machines:

1. open Nightly
2. focus the address bar
3. type in something, e.g. “goo”
4. press TAB, then navigate the list with arrow keys until you reach the search icons at the bottom => this will work
5. press ESC twice
6. repeat steps 3 & 4 => this time it won’t work

Ok, I admit those steps only work 95% of the time. However, using them I am able to confirm the same regression range that :mak found.

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=fde809702d8452e884e0756cc10a5cfee10d5e19&tochange=ec747d3d5f85e36c47826f6160253d52293a8122

Going through the 4 commits locally, the first one where I can reproduce it is this https://hg.mozilla.org/integration/autoland/rev/70d5566772ce9493c5b480b85c595f78fe96d8c0

Thanks a lot! I'm taking a look.

[Tracking Requested - why for this release]: accessibility regression in 89, independent of native context menu pref value

I can reproduce.

This has to do with the Dock menu, and with the accessibility notifications we (unintentionally) fire for it. The inconsistent reproducibility is because macOS calls applicationDockMenu at some point after startup but not immediately.

macOS calls -[MacApplicationDelegate applicationDockMenu:] shortly after startup.
We fire popupshowing/shown/hiding/hidden events for the Dock menu when this
happens, mostly for consistency with other menus. Accessibility code was
processing these events and turning them into unintended accessibility notifications.

The Dock menu is a "native menu", but it is not covered by the workaround from
bug 1703482 because it's not a native context menu. It's its own special thing
and makes use of nsIMacDockSupport and nsIStandaloneNativeMenu and some JS glue
code.

Prior to the "Simplify nsMenuX state management" patch from bug 1699551, we were
not firing the popup DOM events for the Dock menu, mostly by accident.
In fact, it looks like we were only ever firing the events if a DOM modification
had occurred in the menu between menu construction and the current menu opening.
That's definitely not what we want and I'm surprised we got away with it for so
long.

https://hg.mozilla.org/mozilla-central/rev/81fa07a83c65

Martin, could you verify that this bug is fixed in the latest nightly?

I can confirm that I can no longer reproduce this!

The patch landed in nightly and beta is affected.
:mstange, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

https://hg.mozilla.org/releases/mozilla-beta/rev/0b090e4fd1bd