New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 865134 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Accessibility panel in dev tools is blank, creates "Error could not instantiate" error

Reported by fst...@gmail.com, Jul 18

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

Steps to reproduce the problem:
1. Launch Chrome Canary
2. Browse to any site
3. Open dev tools
4. Detach dev tools so it's a floating panel
5. Select the Elements tab
6. Select the Accessibility panel
7. Inspect Dev Tools
8. Open the Console tab
9. View errors.

What is the expected behavior?
The accessibility panel should open and provide accessibility information on the content I'm inspecting.

What went wrong?
The accessibility panel doesn't show any information. Using Dev Tools' "restore defaults and reload" button doesn't fix the problem.

Errors are:

Empty response arrived for script 'chrome-devtools://devtools/remote/serve_file/@bc6daf0166d18e090b7026ceae6c5d4f448d082b/accessibility/accessibility_module.js'
evaluateScript @ shell.js:24

Uncaught (in promise) Error: Could not instantiate: Accessibility.AccessibilitySidebarView
    at Runtime.Extension._createInstance (shell.js:108)

Did this work before? Yes Unsure of exact number, but it worked approximately two weeks ago (circa early July 2018)

Chrome version:  69.0.3495.0 (Official Build) canary (64-bit)  Channel: stable
OS Version: OS X 10.13.6
Flash Version:
 
chrome-accessibility-devtools-errors.png
44.0 KB View Download
Components: -UI Platform>Apps>DevTools
Labels: Needs-Triage-M69 Needs-Bisect
Cc: vamshi.kommuri@chromium.org l...@chromium.org lushnikov@chromium.org
Labels: -Pri-2 -Needs-Bisect Triaged-ET M-69 RegressedIn-69 hasbisect Target-69 FoundIn-69 OS-Linux OS-Windows Pri-1
Status: Untriaged (was: Unconfirmed)
Thanks for filing the issue!

Able to reproduce the issue on reported chrome version 69.0.3495.0 using Mac 10.13.1, Ubuntu 14.04 and Windows 10.

Bisect Information:
--------------------
Good Build: 69.0.3489.0
Bad Build:  69.0.3491.0

Providing with the manual change log as running tool bisect invoked all the good builds, even after changing the revision numbers didn't help us.
Change log from omahaproxy:
---------------------------
https://chromium.googlesource.com/chromium/src/+log/69.0.3489.0..69.0.3491.0?pretty=fuller&n=10000

As we are not very sure about the suspect from the above change log, marking it as Untriaged and requesting someone from Dev team to help us in assigning it to the right owner. CC'ing few Devs from above CL for their inputs...
Owner: dgozman@chromium.org
Status: Assigned (was: Untriaged)
Thanks for the report.  I can confirm that the hash returns 404:
https://chromium.googlesource.com/chromium/src.git/+/bc6daf0166d18e090b7026ceae6c5d4f448d082b

The parent hash works, it seems like a possible frontend uploader problem.  dgozman@, could you please take a look?  Or is there some way I can check?
Hm, I haven't seen any uploader failure notifications, and SSH'ing into the uploader doesn't show any errors in the logs either :/
Cc: dgozman@chromium.org
Owner: einbinder@chromium.org

Sign in to add a comment