I just noticed that when you tab to the document from the address bar, the document doesn't get the focused state any more either. It does in Chrome 49. I'm not sure about 50. I'm not sure whether these are related or not.

Thanks, I'll look into both of those.

They're all related and should be easy enough to fix. I rewrote all of our focus handling code to keep track of focus globally. Cases where multiple objects all simultaneously report focus were a big cause of bugginess.

Now internally only one thing has focus at a time, which is far more sensible for us to reason about.

It should be easy for us to fix these cases - we should just report a document is focused when focus is inside it, and a menu is focused when focus is inside it. I already checked and fixed <select> drop-down menus, which have similar behavior.

Can you think of any other "containers" that behave that way, where both the container and the selected item both report they're focused?

To clarify, the focused state should ideally only be present on the 
element which actually has focus. So, if a link inside a document has 
the focus, the link should report focused, not the document. If a menu 
item has the focus, the menu item should report focused, not the menu. 
NVDA will cope regardless, but if you're refactoring, I guess it'd make 
sense to be correct.

You asked whether there are any other cases where "both the container 
and the selected item both report they're focused". Right now, the issue 
I'm seeing is that sometimes, nothing reports it's focused, rather than 
duplicate focused states. I wouldn't have noticed duplicate focused 
states because NVDA will cope with that just fine.

jamie@ - Is there any NVDA extensions ? While checking for NVDA extensions I am unable to find under chrome webstore. Could you please provide a sample test case file or manifest json file where we can check the issue from QA end.

Thanks!

NVDA is Windows screen reading software. http://www.nvda-project.org/
dmazzoni is already looking into this bug.

Had an offline Chat with dmazzoni@ based on comment#6 and he suggested no bisect is needed as he already started working on the bug. Hence removing the needs-bisect label.

Fix landed:
https://codereview.chromium.org/1801183002/

Merge to M50 needed

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/34bf4c64e98f95f62d37891f45a945076c506a56

commit 34bf4c64e98f95f62d37891f45a945076c506a56
Author: dmazzoni <dmazzoni@chromium.org>
Date: Tue Mar 15 21:30:26 2016

Fix accessible focus state on menu bar container.

When the Chrome menu is open, we use a role of "menu bar" for the outer
pop-up container, "menu" inside of that, and "menu item" for each item.
One screen reader, NVDA, ignores focus events inside the menu unless the
menu bar indicates that it's focused.

This code was moved from cross-platform code to Windows-specific code in
r376339 when we switched to keeping track of focus globally, but
unfortunately it broke because we don't keep track of focus inside
the menu pop-up.

So for now as a quick fix, just mark the menu bar role as focused when
visible. This will work fine because this is the only place we use the
menu bar role and it's only visible when the menu is popped up. Later
a better fix would be to properly track focus inside the menu pop-up.

Tested manually with NVDA.

BUG= 593589 

Review URL: https://codereview.chromium.org/1801183002

Cr-Commit-Position: refs/heads/master@{#381320}

[modify] https://crrev.com/34bf4c64e98f95f62d37891f45a945076c506a56/ui/accessibility/platform/ax_platform_node_win.cc

Just a clarification:

"One screen reader, NVDA, ignores focus events inside the menu unless the
menu bar indicates that it's focused."

NVDA ignores focus events inside the menu unless the focus (the menu 
item) or one of its ancestors has the focused state. Ideally, this 
should be the menu item, but the menu bar will work just as well.

Thanks for clarifying, I finally understand now. So really it'd be cleanest if the menu item itself reported it was focused.

This is okay as a quick fix, but really we ought to be able to track focus across windows that pop up like menus, then we can properly set the focused state.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/02f4658071ca4d361e107f81bf397ac2a2f234df

commit 02f4658071ca4d361e107f81bf397ac2a2f234df
Author: tommi <tommi@chromium.org>
Date: Wed Mar 16 16:28:39 2016

Revert of Fix accessible focus state on menu bar container. (patchset #1 id:1 of https://codereview.chromium.org/1801183002/ )

Reason for revert:
I'm speculatively reverting this cl since webkit tests started failing on Windows. See here for example:
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Win7%20%28dbg%29/builds/4939

webkit_tests webkit_tests
unexpected_failures:
virtual/scalefactor150/fast/hidpi/static/calendar-picker-appearance.html
virtual/scalefactor150/fast/hidpi/static/data-suggestion-picker-appearance.html
virtual/scalefactor150/fast/hidpi/static/popup-menu-appearance.html

Original issue's description:
> Fix accessible focus state on menu bar container.
>
> When the Chrome menu is open, we use a role of "menu bar" for the outer
> pop-up container, "menu" inside of that, and "menu item" for each item.
> One screen reader, NVDA, ignores focus events inside the menu unless the
> menu bar indicates that it's focused.
>
> This code was moved from cross-platform code to Windows-specific code in
> r376339 when we switched to keeping track of focus globally, but
> unfortunately it broke because we don't keep track of focus inside
> the menu pop-up.
>
> So for now as a quick fix, just mark the menu bar role as focused when
> visible. This will work fine because this is the only place we use the
> menu bar role and it's only visible when the menu is popped up. Later
> a better fix would be to properly track focus inside the menu pop-up.
>
> Tested manually with NVDA.
>
> BUG= 593589 
>
> Committed: https://crrev.com/34bf4c64e98f95f62d37891f45a945076c506a56
> Cr-Commit-Position: refs/heads/master@{#381320}

TBR=nektar@chromium.org,dmazzoni@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 593589 

Review URL: https://codereview.chromium.org/1806943002

Cr-Commit-Position: refs/heads/master@{#381469}

[modify] https://crrev.com/02f4658071ca4d361e107f81bf397ac2a2f234df/ui/accessibility/platform/ax_platform_node_win.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f639831519bf5dd7bfc1437d87864a7137e81a29

commit f639831519bf5dd7bfc1437d87864a7137e81a29
Author: tommi <tommi@chromium.org>
Date: Wed Mar 16 17:26:04 2016

Reland of Fix accessible focus state on menu bar container. (patchset #1 id:1 of https://codereview.chromium.org/1806943002/ )

Reason for revert:
Tests still fail so I'm relanding.

Original issue's description:
> Revert of Fix accessible focus state on menu bar container. (patchset #1 id:1 of https://codereview.chromium.org/1801183002/ )
>
> Reason for revert:
> I'm speculatively reverting this cl since webkit tests started failing on Windows. See here for example:
> https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Win7%20%28dbg%29/builds/4939
>
> webkit_tests webkit_tests
> unexpected_failures:
> virtual/scalefactor150/fast/hidpi/static/calendar-picker-appearance.html
> virtual/scalefactor150/fast/hidpi/static/data-suggestion-picker-appearance.html
> virtual/scalefactor150/fast/hidpi/static/popup-menu-appearance.html
>
> Original issue's description:
> > Fix accessible focus state on menu bar container.
> >
> > When the Chrome menu is open, we use a role of "menu bar" for the outer
> > pop-up container, "menu" inside of that, and "menu item" for each item.
> > One screen reader, NVDA, ignores focus events inside the menu unless the
> > menu bar indicates that it's focused.
> >
> > This code was moved from cross-platform code to Windows-specific code in
> > r376339 when we switched to keeping track of focus globally, but
> > unfortunately it broke because we don't keep track of focus inside
> > the menu pop-up.
> >
> > So for now as a quick fix, just mark the menu bar role as focused when
> > visible. This will work fine because this is the only place we use the
> > menu bar role and it's only visible when the menu is popped up. Later
> > a better fix would be to properly track focus inside the menu pop-up.
> >
> > Tested manually with NVDA.
> >
> > BUG= 593589 
> >
> > Committed: https://crrev.com/34bf4c64e98f95f62d37891f45a945076c506a56
> > Cr-Commit-Position: refs/heads/master@{#381320}
>
> TBR=nektar@chromium.org,dmazzoni@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG= 593589 
>
> Committed: https://crrev.com/02f4658071ca4d361e107f81bf397ac2a2f234df
> Cr-Commit-Position: refs/heads/master@{#381469}

TBR=nektar@chromium.org,dmazzoni@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 593589 

Review URL: https://codereview.chromium.org/1812553002

Cr-Commit-Position: refs/heads/master@{#381483}

[modify] https://crrev.com/f639831519bf5dd7bfc1437d87864a7137e81a29/ui/accessibility/platform/ax_platform_node_win.cc

[Automated comment] Reverts referenced in bugdroid comments, after merge request, needs manual review.

Merge approved for M50 (branch 2661). Pls go ahead merge.

Please try to merge your change to M50 branch 2661 asap as we're getting closer to M50 beta candidate cut for this week. Thank you.

Missed this week Beta release.

Please merge your change by  this Friday EOD so we can take it in for next week beta.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d301ea79b9a13f2d6dbed1afbf1b0ba4b8675e74

commit d301ea79b9a13f2d6dbed1afbf1b0ba4b8675e74
Author: Dominic Mazzoni <dmazzoni@chromium.org>
Date: Thu Mar 24 04:36:35 2016

Merge to M50: Fix accessible focus state on menu bar container.

When the Chrome menu is open, we use a role of "menu bar" for the outer
pop-up container, "menu" inside of that, and "menu item" for each item.
One screen reader, NVDA, ignores focus events inside the menu unless the
menu bar indicates that it's focused.

This code was moved from cross-platform code to Windows-specific code in
r376339 when we switched to keeping track of focus globally, but
unfortunately it broke because we don't keep track of focus inside
the menu pop-up.

So for now as a quick fix, just mark the menu bar role as focused when
visible. This will work fine because this is the only place we use the
menu bar role and it's only visible when the menu is popped up. Later
a better fix would be to properly track focus inside the menu pop-up.

Tested manually with NVDA.

BUG= 593589 

Review URL: https://codereview.chromium.org/1801183002

Cr-Commit-Position: refs/heads/master@{#381320}
(cherry picked from commit 34bf4c64e98f95f62d37891f45a945076c506a56)

Review URL: https://codereview.chromium.org/1828853002 .

Cr-Commit-Position: refs/branch-heads/2661@{#373}
Cr-Branched-From: ef6f6ae5e4c96622286b563658d5cd62a6cf1197-refs/heads/master@{#378081}

[modify] https://crrev.com/d301ea79b9a13f2d6dbed1afbf1b0ba4b8675e74/ui/accessibility/platform/ax_platform_node_win.cc

Verified the merge on the latest M-50(50.0.2661.57- 64 bit) on Windows-10 with NVDA version: 2016.1. This is working as intended and NVDA reads out the Wrench menu options on Arrow down key.


Adding the verified labels therefore.