I can repro. Alice, could you take a look at this?

If we're sure this was a regression we could try bisecting.

This is definitely a mac-specific bug - the internal tree shows "listBoxOption" for all of the children. Investigating...

Hah, totally misunderstood the issue. Looking again.

Ok, this is weird. If I look only with the tree in devtools (in my local build), everything seems ok. But as soon as I look at the tree with chrome://accessibility, it seems to add an extra ignored node which seems to correspond to the "itemsContainer" div.

Dominic, can you think of any mechanism by which requesting the tree from the browser process might change the shape of the tree?

Ok, I take it back, I can repro the weird ignored element showing up with just the devtools.

Sounds like a Heisenbug.

Oh - ok, it only seems to trigger when accessibility is "on" for that tab, i.e. not when using the scopedAXObjectCache.

Alright, here's what I know:
- I can only repro when accessibility mode is on, not when using the scopedAXObjectCache from devtools
- When accessibility mode is on, the role=none element shows up in the tree, but when using the scopedAXObjectCache alone, that element doesn't show up
- I can reproduce this without shadow DOM: http://output.jsbin.com/locevot - it seems like the role=none element is the significant thing, rather than the ShadowRoot.

Oh, and not updating aria-activedescendant also makes it fail to trigger.

Ah, I figured it out.

What's happening is that when you set aria-activedescendant, AXNodeObject::inheritsPresentationalRoleFrom() now marks that as NOT presentational because it's a descendant of a node with aria-activedescendant and it has an ID.

I've always felt like that was one of the sketchier rules in the ARIA spec, to mark something as focusable just because it happens to have an ID when it's not even a valid role.

Now the reason that's a problem is that initially the listbox has the options as immediate children, because the <div role=none> is presentational and skipped over. But then after we set aria-activedescendant, the <div role=none> is no longer considered presentational...but we're not correctly updating the tree to reparent all of its children to it.

The second issue is actually the more serious bug, i.e. the first was a quirk that would have been debuggable, but the second broke the tree by not updating things correctly.

I'd like to fix the first issue first because that seems easier: role=none is a stronger signal than having an ID, so it should take precedence. I think we should also consider whether descendants of aria-activedescendant should only be focusable if they're a reasonable role, like option or gridcell.

For the second issue, I'd like to consider that maybe Blink shouldn't hide ignored nodes when walking the tree, that just makes things a lot more complicated. It should just expose "ignored" as a flag, and we should exclude it from the tree somewhere else in the pipeline.

Slight correction: whether or not it has an ID is not relevant. The spec says that a descendant of an object with an activedescendant should be focusable if it has an ARIA role.

We just need to amend that to say if it has a non-presentational ARIA role.

@Elly, this might affect the combo box issues you are looking into.

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

commit 6940f7313fe70eb077836a6bdaa8502ffb256ad1
Author: dmazzoni <dmazzoni@chromium.org>
Date: Fri Sep 30 18:47:37 2016

Fix issue with descendants of aria-activedescendant being marked as focusable.

The ARIA spec says that descendants of a node with aria-activedescendant set should
be marked as focusable if they have an ARIA role. But this doesn't make sense if the
ARIA role is "none" or "presentation", so fix that. Also ensure that we recompute
cached attributes whenever aria-activedescendant changes, even if it doesn't point to
a valid ID, because it can affect focusability.

BUG= 651127 

Review-Url: https://codereview.chromium.org/2386473003
Cr-Commit-Position: refs/heads/master@{#422164}

[modify] https://crrev.com/6940f7313fe70eb077836a6bdaa8502ffb256ad1/third_party/WebKit/Source/modules/accessibility/AXNodeObject.cpp
[modify] https://crrev.com/6940f7313fe70eb077836a6bdaa8502ffb256ad1/third_party/WebKit/Source/modules/accessibility/AXObjectCacheImpl.cpp

Many thanks!