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

Issue 742993 link

Starred by 5 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

lighthouse keeps loading

Reported by pdk...@gmail.com, Jul 14 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.68 Safari/537.36

Steps to reproduce the problem:
Run Lighthouse on any website.

What is the expected behavior?

What went wrong?
It doesn't work. It displays "Loading..." and the blue spinner spins, but that's it. Even 15 minutes later nothing happens. Clicking Cancel works, but then it keeps "Cancelling..." until the tab is closed manually.

I tried picking only some sub-options, but it makes no difference. What happens is that the page is put into mobile-view, and then it keeps loading.

I don't know how I would debug this either.

Did this work before? No 

Chrome version: 60.0.3112.68  Channel: beta
OS Version: Ubuntu 14.04
Flash Version:
 

Comment 1 by phistuck@gmail.com, Jul 14 2017

I think it might be a remote module (downloads on demand perhaps), so chrome:net-internals might give you a clue about it.

Comment 2 by alph@chromium.org, Jul 14 2017

Owner: paulir...@chromium.org
Status: Assigned (was: Unconfirmed)

Comment 3 by pdk...@gmail.com, Jul 15 2017

​That was a good tip. It makes several requests ​to https://
chrome-devtools-frontend.appspot.com all of which return 404.

Comment 4 by pdk...@gmail.com, Jul 15 2017

I think I might have figured out the reason. The requests are of this format.

> :path: /serve_file/@835c1318dde5dd3d2fc63cf1212727587943aef8/<file>

Now the hex string seemed familiar to me.

https://chromium.googlesource.com/chromium/src/+/835c1318dde5dd3d2fc63cf1212727587943aef8

I compile Chromium myself and usually pick the latest commit on a branch, and I guess only "official" commits that are featured on OmahaProxy are supported. I hope that's a bug and not a feature.

Comment 5 by pdk...@gmail.com, Jul 21 2017

I think there is also a wider bug here in that network errors are not considered.
Indeed. I was looking into this yesterday and see that we can often have failed requests. The common remote modules that will fail are:  product_registry_impl, audits2_worker, and device images like the nexus5x.

In the case of audits2_worker it begins the request via `new Worker(url)` and currently there is no error handling set up on that to observe the fetch failure. 
The other two I mentioned will need slightly different error handling setups.


Thanks for digging into this.

Comment 7 by phulce@chromium.org, May 25 2018

Cc: phulce@chromium.org sindhu.chelamcherla@chromium.org susan.boorgula@chromium.org
 Issue 845410  has been merged into this issue.
I have this issue as well, with the path

> chrome-devtools://devtools/bundled/audits2_worker.js?remoteBase=https://chrome-devtools-frontend.appspot.com/serve_file/@cf598d63a4f1b9e7cd14f2a8433276b196e3e07d/:23

I attached the console output for the inspector of the inspector where I tried to run the audit
Screenshot from 2018-07-24 15-41-50.png
70.0 KB View Download
I am having the same problem on windows 10 chrome Version 68.0.3440.75 (Official Build) (64-bit).

Sign in to add a comment