Lighthouse in DevTools errors/hangs on installability checks #13396
Comments
|
Tried on Canary 98.0.4719.0. Still won't complete but at least could cancel and see console.
On 2 attempts after that, left it run to see what happened and got this reproducible error, so duly reporting as requested. Channel: DevTools May be of interest that it appears that after each of these failed attempts at Lighthouse audits, Canary is unable to load the service worker properly, even with a hard refresh until I close devtools. Once that is done, devtools can be reopened and service worker happily loads again as expected. |
|
Tried on Version 98.0.4710.4 (Official Build) dev (64-bit) on Ubuntu and also getting hanged with this in the console:
Was able to cancel also. |
|
I am getting |
# python bisect-builds.py -o --verify-range -a mac -g 857950 -b 929940 --use-local-cache --not-interactive -c "bash $PWD/scripts/cdt-manifest-install-errors-hang/script.sh %p"
LH=~/src/lighthouse
export CHROME_PATH=$1
# brew install coreutils
cd $LH
pwd
if gtimeout 30 yarn run-devtools 'https://www.enricofromrome.eu/edb6/'; then
echo "ok $1"
exit 0
else
echo "bad $1"
exit 1
fiDoes not hang with this Chrome flag: |
HUGE FIND. This is definitely key. We've since followed up with some chromium folks to better understand what its all about. |
|
I've added some basic printf logging to the installability manager in Chromium to better understand what's happening. The repro is basically: open https://caltrainschedule.io/ . open devtools. lighthouse panel. just pwa. hit analyze. this will hit our protocol_timeout case. But now with Chromium logging there's something more interesting going on. In a happy run (with PlzServiceWorker) it looks like this:
in a sad, hanging run though:
Also different this time:
|
|
current theory is that the SW target is paused. Targets are resumed when we attach but for some reason we don't get the opportunity to resume the target dealing with this SW network fetch, which now happens in the browser. If you turn off the |
|
If I avoid our usage of I found that when replaying a log of CDT protocol commands (from a hanging repro), and filtering out all the methods I could while keeping the hanging reproduction. |
|
We have a fix that should land in Canary ~soon: https://chromium-review.googlesource.com/c/chromium/src/+/3318838 We'll request a merge to Chrome 97 (scheduled to release Jan 4). In the meantime, you can avoid the hanging by disabling Clear Storage |
|
Confirmed with latest Canary 98.0.4755.0 that all the URLs in the original post work, and none return the temporary error message. Will keep this open to track the merge into Chrome 97 and (maybe) 96. |
|
Merged to 97: https://bugs.chromium.org/p/chromium/issues/detail?id=1276339#c30 I don't see any pending stuff on m96 merge tho. |
|
The fix has reached stable. |
|
No changes in my software ('https://www.enricofromrome.eu/edb6/') and now, on chrome 97 it works. Thank you |
Latest:
We have a fix that should land in Canary ~soon: chromium-review.googlesource.com/c/chromium/src/+/3318838
We'll request a merge to Chrome 97 (scheduled to release Jan 4).
In the meantime, you can avoid the hanging by disabling Clear Storage
Before 98.0.4711.0, some sites with service workers would hang indefinitely while determining if there were any installability errors. With 98.0.4711.0, hanging should occur less often (these issues were fixed), a report will be generated and this error will be seen in the installable audit:
Lighthouse could not determine if there was a service worker. Please try with a newer version of Chrome.. This message is aspirational, as there is not yet a fix for the underlying cause.However, there are still URLs that will hang indefinitely:
Debugging shows that the target for the service worker is never resumed.
Some URLs that will show the new
could not determinemessage (and not hang):related crbug: https://bugs.chromium.org/p/chromium/issues/detail?id=1276339
The text was updated successfully, but these errors were encountered: