I can reproduce it on Nexus 5 and Nexus 5X, but not Pixel. The recorded screen is attached.

When the small element is selected, the audio says: "dom_distiller_material_spinner graphic". Looks like the accessibility interface got the old DOM state where the loading spinner is still there.

This only happens when "Reader Mode in CCT" is turned off in flags.

Deleted: reader-talkback.mp4 572 KB

	reader-talkback.mp4 572 KB View Download

I can definitely reproduce this on Pixel. Try different  pages.

On Pixel 2 XL, repro rate is 1/6 on Zine suggestions, with "Reader Mode in CCT" turned off.

After using TalkBack intensively for a day, I can sometimes reach this state on normal web pages as well. The symptom is similar: no accessibility content, but visually it's working fine.

This doesn't look exclusive to Reader Mode, even though the probability of this happening on the normal web pages is much lower.

Laura, would you mind helping re-route this to the appropriate team?

@Dominic, would you be able to look into this or reroute to someone else who can? 

@ibobra and I should look at this together.

Isha, could you try to reproduce first and then I can help you debug it?

Could reproduce on nexus 6P.

@wychen: Isha and I tried to debug it for a while today.

We can reproduce the bug easily on Canary but not on our own build. Can you think of any reason why running Clankium would be much different? With Clankium, the mobile friendly page loads and it always works fine with TalkBack.

Even with Canary, we enabled some verbose logs and determined that we're only seeing accessibility events from the distiller "loading" page. When the mobile friendly page appears, we don't see any accessibility events at all.

Can you explain a bit about how the process works and point us to the relevant code?

When the distiller "loading" page is visible and the mobile friendly page is finished, how is it swapped in? Is the current WebContents changed in-place? Is the current WebContents redirected to another url that serves the mobile friendly page? Or is the mobile friendly page loaded in a new WebContents that's shown in place of the old one?

A high-level explanation and a pointer to that part of the code that triggers that swap would be helpful.

Another thing that might be helpful would be a way to artificially delay the distilling, I'd like to see it stay on the "loading" page longer for debugging.

Thanks for looking into this issue!

I think the discrepancy between Canary and a local build is mostly timing, since this bug is timing-sensitive in nature. A non-component official release build might help shrink the gap. Debugging on Nexus 5 might also make it more reproducible.

After distillation is done, a piece of JavaScript code is executed to populate the DOM elements. It's still in the same WebContents. You can take a look at OnArticleReady(), which calls SendJavaScript(), and in the end ExecuteJavaScriptInIsolatedWorld().

https://cs.chromium.org/chromium/src/components/dom_distiller/core/dom_distiller_request_view_base.cc?l=46&gs=cpp%253Adom_distiller%253A%253Aclass-DomDistillerRequestViewBase%253A%253AOnArticleReady(const%2Bdom_distiller%253A%253ADistilledArticleProto%2B*)%2540chromium%252F..%252F..%252Fcomponents%252Fdom_distiller%252Fcore%252Fdom_distiller_request_view_base.cc%257Cdef&gsn=OnArticleReady&ct=xref_usages

I haven't tried, but I think it should be possible to add delay in OnArticleReady() so that it stays on the "loading" page for longer.

Re: #c8

Dynamically loading content can happen on normal web pages as well, like AMP pages. I'm not sure whether the root cause is similar though.

I have a theory and two things that we can test on canary.

Try running with this flag:

  --vmodule="*render_accessibility_impl*=1"

Use adb_command_line and don't forget to append the other command line flags you need to turn the Reader feature on.

What I'm looking for is if you see this message:

"Failed to serialize one accessibility event"

If that appears when it fails, that could explain why the accessibility tree isn't updating.

Finally, I'm curious if rotating the display and rotating it back fixes it when it's broken.

Following the instruction in #c16, I didn't see the error message. I did see lots of messages in this format:

[VERBOSE1:render_accessibility_impl.cc(456)] Accessibility event: ....

Rotating the display doesn't fix it.

OK, one theory was wrong.

For the logs you did see, I know they get truncated but critically, do you see any events that appear to be sending over the accessibility tree for the *new* formatted page? Or are you only seeing events related to the loading page?

On the browser site where we're serving accessibility via Java we seem to be stuck with the loading page, and it's not clear why.

It's especially confusing if it's all happening only via JavaScript. Are you sure there's no page transition or swapping of WebContents or RenderFrameHosts happening? It looks a lot like what I'd expect to happen if we're serving out of a stale RenderFrameHost and not the one that's visually on top. 

We do swap WebContents, but that's before showing the loading page. When we get into Reader Mode, one WebContents is created for the DOM distiller viewer, and swapped with the original one, while the distillation might still be ongoing in the original WebContents.

Is it possible that some accessibility channels are still with the original WebContents? It seems unlikely since we've already got the accessibility events from the loading page.

In the latest builds of Canary I'm getting "no data" message pretty much 100% of the time when attempting to access "mobile-friendly" view.

Comment#20 looks like some other issue. It can be reproduced using clankium for mobile-friendly views of facebook.com and twitter.com almost everytime, but for other sites, I was not able to see it getting reproduced.

 We are able to repro this issue in M63 and M64 builds when reader mode flag is on, but it is very hard to bisect, It is not consistent behavior for all articles.

 Tested Device : Pixel 2XL/OPD
 Tested on "Chrome on Andriod"
 Steps:
Talkback is ON
1. Launch the app
2. Enable the flag -Reader mode flag for all articles
3. Open new tab
4. Tap on any article and open in Reader mode
5. Try to tap access the article(Tap or side swipe)

  Good Build :63.0.3224.4
  Bad  Build  :63.0.3226.0,63.0.3231.0

63.0.3226.0 -> we hit the issue on first time open the reader mode article.
63.0.3231.0 -> We hit the the issue most of the times

CL range: https://chromium.googlesource.com/chromium/src/+log/63.0.3224.0..63.0.3231.0?pretty=fuller&n=10000

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

commit 8df7574b3caa59a25de7c735f0abdd2735a4dccb
Author: Jinsuk Kim <jinsukkim@chromium.org>
Date: Thu Nov 30 00:01:58 2017

Fix the stale DOM bug for a11y mobile-friendly pages

https://crrev.com/c/688035 accidentally made calls to
reset a11y mode when disabling WebContentsAccessibility
state. This CL prevents it to fix the stale DOM issue
reported in a11y mobile-friendly pages (and maybe in others).

Bug:  775532 
Change-Id: I69cffa7a10c5fd466941faa12ee121b5be2a746e
Reviewed-on: https://chromium-review.googlesource.com/795478
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#520312}
[modify] https://crrev.com/8df7574b3caa59a25de7c735f0abdd2735a4dccb/content/browser/accessibility/web_contents_accessibility_android.cc

This is a regression in M63 which can have some impact on users of a11y.

This bug requires manual review: We are only 4 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

 Issue 788856  has been merged into this issue.

Please verify the fix in the next canary

jinsukkim@ I hope we are not missing any use case that could be negatively impacted by the removal of that code in your changelist. Do we have tests for that?

Unfortunately I don't have tests for that. But what I can say is that the removed code had been a dead code before the culprit CL https://crrev.com/c/688035 landed. But the CL inadvertently executed it, which caused the regression. Mine fixed it by removing the dead code which should not have been executed in the first place. I'm quite sure it won't have any negative impact.

Merge approved upon verification of the fix in canary. Also verify the fix on branch 3239 after merging it.

 Verified in M64-64.0.3281.0 build with Pixel device-"Chrome on Android"

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

commit 67687391dfa99542f6a94a5556258ef8eb8b2a68
Author: Jinsuk Kim <jinsukkim@chromium.org>
Date: Thu Nov 30 23:11:32 2017

Fix the stale DOM bug for a11y mobile-friendly pages

https://crrev.com/c/688035 accidentally made calls to
reset a11y mode when disabling WebContentsAccessibility
state. This CL prevents it to fix the stale DOM issue
reported in a11y mobile-friendly pages (and maybe in others).

Bug:  775532 
Change-Id: I69cffa7a10c5fd466941faa12ee121b5be2a746e
Reviewed-on: https://chromium-review.googlesource.com/795478
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#520312}(cherry picked from commit 8df7574b3caa59a25de7c735f0abdd2735a4dccb)
Reviewed-on: https://chromium-review.googlesource.com/798910
Cr-Commit-Position: refs/branch-heads/3239@{#619}
Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578}
[modify] https://crrev.com/67687391dfa99542f6a94a5556258ef8eb8b2a68/content/browser/accessibility/web_contents_accessibility_android.cc

I've also verified 64.0.3281.0 on Nexus 5. It is much easier to reproduce the symptom on lower-end devices like N5 than Pixel 2.

Issue no longer reproducible on Pixel XL/ OPM1.171019.011 having monochrome dev 64.0.3281.0 on webview apps Amazon,Facebook,Pinterest

"Chrome on Android"-Verified on M63-63.0.3239.83 build

Issue 791453 has been merged into this issue.

Issue no  longer reproducible on Pixel / 63.0.3239.83 (Monochrome stable) and tested webview apps like amazon, wikipedia webview content  after the steps mentioned in #23