[Affected versions]: - Nightly 60.0a1 [Affected Platforms]: - All Windows - All Linux - All Mac [Prerequisites]: - Have the latest try build 60.0a1 from (2018-02-23) installed. - Accessibility tab is activated and enabled. [Steps to reproduce]: 1. Navigate to www.instagram.com 2. Press "F12" key and focus the "Accessibility" tab. 3. Press "F5" key (or click the "Reload Current Page" button). 4. Observe the content of the Accessibility panels. [Expected result]: - Specific information related to the opened website is displayed. [Actual result]: - "Accessible Information Unavailable" text is displayed. [Notes]: - Besides Instagram, this issue is encountered only on the following tested websites: -> www.amazon.com -> www.vk.com - Sometimes the issue is reproducible only if refreshing the page twice. - Attached a screen recording of the issue.

I believe this will be fixed with latest nightly.

On the latest Firefox Nightly (Build ID: 20180426220144) the issue can be reproduced on Mac OS X 10.12, Windows 10 x64 and Ubuntu 16.04 x64 by following the steps provided. The same behavior was experienced after testing on Instagram, Amazon and VK, thus I will reopen the issue for further investigations.

This is similar to how inspector deals with page reload. The sidebar there says "No elements selected". Victoria, would you comment whether this is reasonable, or if you'd like to see some changes (perhaps even if styling)?

In Inspector, I see that message for a second, but then it loads in the rules - could this panel do something similar? When I tested this in the a11y panel, it seemed to happen some of the time, and usually another refresh fixes it. It would be great if this error could be avoided, but I think it's not enough to block this from 61 - as a stop gap, the error message could have "Refresh to continue" added to the end, and more padding around the whole thing.

(In reply to Timea Babos from comment #2) > On the latest Firefox Nightly (Build ID: 20180426220144) the issue can be > reproduced on Mac OS X 10.12, Windows 10 x64 and Ubuntu 16.04 x64 by > following the steps provided. > The same behavior was experienced after testing on Instagram, Amazon and VK, > thus I will reopen the issue for further investigations. Hi Timea, just to confirm. The message is only visible for a short period of time, until the page "loads" and then the tree is displayed or does the message just persist indefinitely? Thanks

Hi Yura, The message persists indefinitely even after refreshing (F5) the page and all the content is properly loaded. However, if accessibility is disabled and re-enabled the tree will be displayed if the page is refreshed. After disabling/enabling it’s quite hard to reproduce the issue, unless the browser is restarted and the STR are followed once again from the start. I can also confirm that a simple refresh might fix the issue sometimes and that it may not reproduce specifically after 1 refresh attempt (as mentioned in the STR), thus being an intermittent issue. Note that it’s behavior can be best observed on the sites: Instagram and VK.

Hi Timea, I have a build with a potential fix for this bug - https://treeherder.mozilla.org/#/jobs?repo=try&revision=3ea4cc4de7f4a676e659b4a369062a00bc1af447 , could you see if you can reproduce any one of the above described issues? Thanks!

Hi Yura, The issue can be reproduced only on Windows 10 x64 on the VK.com page using the same STR. I couldn’t reproduce it on any other OS or on Instagram.

(In reply to Timea Babos from comment #8) > Hi Yura, > > The issue can be reproduced only on Windows 10 x64 on the VK.com page using > the same STR. > I couldn’t reproduce it on any other OS or on Instagram. Hi Timea, just following up, I tried on a Windows machine and I could only notice a lag in updating when testing VK.com, within a couple of seconds the properties sidebar updates to the right values. Does it remain empty in your case forever?

Hi Yura, In my case it will remain empty unless I refresh the page once more (or several times). Attached a video of the issue reproduced on the latest Nightly, Windows 10 x64.

This patch fixes all platforms but windows (but is still a big improvements).

Comment on attachment 8973738 [details] [diff] [review] 1441187 patch Review of attachment 8973738 [details] [diff] [review]: ----------------------------------------------------------------- Looks good, jut some suggestions to make the code easier to read. ::: devtools/server/actors/accessibility.js @@ +506,5 @@ > return Promise.resolve(doc); > } > > let doc = this.getRawAccessibleFor(this.rootDoc); > + let extState = {}; extState is a bit cryptic if you don't know that there is such a thing as extended state flags on the platform. Consider changing the name for this variable, or adding a comment to give readers a little bit of a clue for what's happening in these 3 lines of code. @@ +581,5 @@ > + let rootDocAcc = this.getRawAccessibleFor(this.rootDoc); > + if (rawAccessible === rootDocAcc) { > + let extState = {}; > + rawAccessible.getState({}, extState); > + if (!(extState.value & Ci.nsIAccessibleStates.EXT_STATE_STALE)) { Same comment here. In fact, you could wrap these 3 lines in a helper function somewhere else with a self-explanatory name: function isStale(rawAcc) { let extendedState = {}; rawAcc.getState({}, extendedState); return extendedState.value & Ci.nsIAccessibleStates.EXT_STATE_STALE; } and then just call isStale(rawAccessible) here, and isStale(doc) above (in my previous comment).

Pushed by yura.zenevich@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/b3147109d3af wait for non-stale state instead of non-busy when waiting for root document accessible. r=pbro

Hi Timea, could you take a look at the latest nightly now, we landed a fix that should reduce the number of times this can be reproduced. Thanks

Hi Yura, I cannot reproduce the issue on Windows 10 x64 on the latest Nightly 62.0a1 (20180509100510). Note that the message might be displayed for 2-3 seconds until the page is fully loaded. However, all the content in the panels will be displayed afterwards, thus I can confirm that the message does not persist indefinitely anymore after refreshing. I also retested the issue on Mac OS X 10.12 and Ubuntu 16.04 x64 without any success in reproducing it.

(In reply to Timea Babos from comment #17) > Hi Yura, > > I cannot reproduce the issue on Windows 10 x64 on the latest Nightly 62.0a1 > (20180509100510). > Note that the message might be displayed for 2-3 seconds until the page is > fully loaded. However, all the content in the panels will be displayed > afterwards, thus I can confirm that the message does not persist > indefinitely anymore after refreshing. > I also retested the issue on Mac OS X 10.12 and Ubuntu 16.04 x64 without any > success in reproducing it. Ah that's great! Yes that message is pretty much saying that the accessibility information is no ready yet as we are processing the page. I will resolve it then. Thanks.

Comment on attachment 8979564 [details] [diff] [review] 1441187 patch Approval Request Comment [Feature/Bug causing the regression]: This is one of the bugs found to be high priority for a11y inspector tool. [User impact if declined]: Sometimes the panel could get into an unusable state until it is refreshed. [Is this code covered by automated tests?]: Yes [Has the fix been verified in Nightly?]: Yes [Needs manual test from QE? If yes, steps to reproduce]: No [List of other uplifts needed for the feature/fix]: None [Is the change risky?]: No [Why is the change risky/not risky?]: Affects a11y panel only, other tools and the browser itself would work just fine. [String changes made/needed]: No

Comment on attachment 8979564 [details] [diff] [review] 1441187 patch a11y inspector fix, approved for 61.0b8.

(In reply to Yura Zenevich [:yzen] from comment #20) > [Is this code covered by automated tests?]: Yes > [Needs manual test from QE? If yes, steps to reproduce]: No Setting qe-verify to - since this is covered by automated tests and no longer requires manual testing, per Yura's assessment.

Reopening for another issue discovered by Emil (from Slack): We noticed an interesting behavior, which is related to Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1441187. We noticed that this behavior is still reproducible on latest Nightly and Beta. We noticed that after spamming the F5 key a little, the same behavior is encountered. We tried contacting Timea (with no success) because the behavior that we encountered is different from what she has stated in Comment 17 (It seems that the message doesn't disappear after 2-3 seconds and refreshing the page is not helping in some cases).

(In reply to Yura Zenevich [:yzen] from comment #26) > Created attachment 8982106 [details] [diff] [review] > 1441187 patch follow up From slack looks like the issue is fixed by the patch: Yep, looks good! It seems that the panel is populated with data after 2-3 seconds. Verified this on both Ubuntu and macOS. It seems that I can't confirm this for Windows too because the try build got busted.

The try build that was tested: https://treeherder.mozilla.org/#/jobs?repo=try&revision=e4bcee657ab3ee8368260b2c4cd1826745981d49

Pushed by yura.zenevich@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/aebf9e698f76 throttle children() operation on a11y walker. r=pbro

Comment on attachment 8982106 [details] [diff] [review] 1441187 patch follow up [Feature/Bug causing the regression]: This is one of the bugs found to be high priority for a11y inspector tool. [User impact if declined]: Sometimes the panel could get into an unusable state until it is refreshed (see comment 24). [Is this code covered by automated tests?]: No [Has the fix been verified in Nightly?]: Not yet, but it was verified fixed on all platforms with try builds. [Needs manual test from QE? If yes, steps to reproduce]: See comment 24 [List of other uplifts needed for the feature/fix]: None [Is the change risky?]: No [Why is the change risky/not risky?]: Affects a11y panel only, other tools and the browser itself would work just fine. [String changes made/needed]: No

Comment on attachment 8982106 [details] [diff] [review] 1441187 patch follow up Follow-up fix for an a11y inspector improvement. Approved for 61.0b11.