DeveloperTools Audit [lighthouse] not working in Chromium
Reported by
gmia...@opera.com,
Apr 5 2018
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 OPR/52.0.2871.40 Steps to reproduce the problem: 1. Run chromium-browser on Linux (or any chromium based browser) 2. Open developer tools 3. Try to run audit What is the expected behavior? Audit run on chromium browser What went wrong? No audit performed. Error in logs: [10476:6028:0405/105533.186:ERROR:CONSOLE(1)] "Uncaught (in promise) SyntaxError: Unexpected identifier", source: chrome-devtools://devtools/bundled/audits2_worker.js?remoteBase=https://chrome-devtools-frontend.appspot.com/serve_file/@44919e4fea5e7e6a209f00d1780f799bf211e559/ (1) Requests made to not existing resource: Opera (v 53.0.2907.7) https://chrome-devtools-frontend.appspot.com/serve_file/@f241064382f73eef8d3b96bd8fe0927b5ccecfea/audits2_worker/audits2_worker_module.js Vivaldi (v 1.95.1077.60) https://chrome-devtools-frontend.appspot.com/serve_file/@44919e4fea5e7e6a209f00d1780f799bf211e559/audits2_worker/audits2_worker_module.js Did this work before? N/A Chrome version: 65.0.3325.181 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 29.0 r0 Looks like chromium based browser use some not existing commit_hash
,
Apr 5 2018
,
Apr 5 2018
,
Apr 5 2018
The solution would be to point to the Blink commit in the WebKitVersion. Can this be done on Opera side?
,
Apr 6 2018
Seems like this also broke remote debugging for Opera. Getting similar error: [3320:775:0406/101640.827169:ERROR:CONSOLE(1)] "Uncaught (in promise) SyntaxError: Unexpected identifier", source: chrome-devtools://devtools/bundled/inspector.html?remoteFrontend=true&remoteBase=https://chrome-devtools-frontend.appspot.com/serve_file/@abb5172872b726072a64dfabaf45894c6ecf7369/&dockSide=undocked (1) @pfeldman will try to ask developers about this. But even if we fix it for Opera this will probably still affect other chromium based browsers.
,
Apr 6 2018
@pfeldman We are using chromium sha that was generated by gclient sync, but since we are using release tags here is how their history always looks like: commit 0b393dcf23845afdc62a80b4062c7e9e042517dc Author: chrome-release-bot <chrome-release-bot@chromium.org> Date: Tue Apr 3 15:35:57 2018 -0700 Publish DEPS for Chromium 66.0.3359.81 commit fb2352fc7d3d530687ff90d6ccc195efd640c1a7 Author: chrome-release-bot <chrome-release-bot@chromium.org> Date: Tue Apr 3 22:29:31 2018 +0000 Incrementing VERSION to 66.0.3359.81 TBR=dimu@chromium.org Change-Id: I67cd40dce50238a41a8db2b46967f8a66bc384b8 Reviewed-on: https://chromium-review.googlesource.com/994292 Reviewed-by: chrome-release-bot@chromium.org <chrome-release-bot@chromium.org> Cr-Commit-Position: refs/branch-heads/3359@{#569} Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276} Before https://chromium-review.googlesource.com/949312 was integrated we were always getting sha of "Publish DEPS" commit during "gclient sync" which looks like is not being indexed on chrome-devtools-frontend.appspot.com. We confirmed that when manually updating LASTCHANGE sha to first previous commit in history containing Cr-Commit-Position entry made audit work again on our stabilization branch builds. Since the source of problem is now known we can handle it manually for M66 and M65 and it is already fixed on M67 by mentioned change. Maybe it would be good to backport the lastchange generation change (although change comment is a bit misleading)? Or index publish deps commits on chrome-devtools-frontend.appspot.com?
,
Apr 6 2018
If we are good M67+, let's handle 65-66 manually and call it a day? |
||||
►
Sign in to add a comment |
||||
Comment 1 by brat...@opera.com
, Apr 5 2018