Adding some extra context from kraush via email:

> Is it correct that:
> 
> 1. ContentView and TabStrip are combined into one virtual object (held in CompositorViewHolder, inflated into a control_container layout)
> 
> 2. The Toolbar is an actual (non-virtual) Android UI object
> 
> 3. ContentView and TabStrip are combined into one virtual object to enable fullscreen (not sure about this one)
>
> ...
> 
> I'd be particularly interested in whether or not 3 is true - in case it is not, what do you think about separating TabStrip and ContentView?
> 
> If that's impossible, do you think it would be feasible to make the toolbar virtual and include it in the CompositorView?
> 
> Or any other ideas if there might be a simpler way to change the accessibility order?

I've noticed this bug as well, though on M51, the ordering seems be correct: tab strip -> toolbar -> web contents. I'm using a Nexus 7 running KitKat.

Are you seeing this issue on M51 as well?

I don't think they're combined in that way, but I'm not sure.  IIRC the hierarchy looks like:

- FrameLayout
  - CompositorViewHolder
    - AccessibilityView (tab strip)
    - ContentView (page content)
  - Toolbar (toolbar!)

I know we explicitly set focus traversal ordering on some of these to get it to cycle right (specifically between the toolbar and other things), but I don't know if that's up to date or not.

So what is interesting is that it looks like we don't explicitly control the order between the AccessibilityView and the ContentView (we just call addView(), so their order isn't consistent).

Thanks for the explanation dtrainor! :)

@newt: I don't think this is fixed in 51 :(
Just fetched and built latest tip of master (a5608a59eb306d40d04e6c0d7d70b540b9bbc712) and the traversal order is still incorrect on my Nexus 9 on 5.1.1 as well as on a Nexus 7 on 5.0.2
Same problem with latest master on a non-Nexus device on KitKat (don't have a Nexus on KitKat at hand, but I would assume it behaves the same on all KitKat devices)

Note: I'm testing this on ChromePublic, since the Chrome Dev channel is still at v50 and I don't have access to build Chrome directly.
I would expect Chrome to not contain any accessibility changes that aren't in ChromePublic though.
--> Correct me if I'm wrong on that one.

@twellington, could you take a fresh look at this and see if it's still relevant?

It likely is, but I think it's a P3 given that it only affects tablets and is quite old.

+Needs-TestConfirmation - clank-te@, will you please confirm that this still reproduces.

Given the lack of response and the new Chrome UI, I am closing this bug.

Please reopen if this reproduces.