LightHouse HTML report generated in Debian not rendering in browser

[karthigeyan-saran]

Hi

Am trying to generated the LH HTML report programmatically using NodeJs, Pupetteer and lighthouse. Have verified the report on the windows environment and works fine. While testing the same in the Linux Debian environment both Json and HTML reports are generated successfully. Being a container environment with Debian chrome was launched with --no-sandbox option. While opening the report in chrome only blank page is shown up. There was browser level page error with the following stacktrace. Let me know if am missing anything / fix to solve the problem ?

Browser error stack trace 
-------------------------- 

Uncaught Error: query a not found
at DOM.find (compiled-reportrenderer.js:845)
at DetailsRenderer.renderSourceLocation (compiled-reportrenderer.js:1610)
at DetailsRenderer._renderTableValue (compiled-reportrenderer.js:1305)
at DetailsRenderer._renderTableRow (compiled-reportrenderer.js:1459)
at DetailsRenderer._renderTableRowsFromItem (compiled-reportrenderer.js:1493)
at DetailsRenderer._renderTable (compiled-reportrenderer.js:1525)
at DetailsRenderer.render (compiled-reportrenderer.js:1121)
at PerformanceCategoryRenderer.populateAuditValues (compiled-reportrenderer.js:3590)
at PerformanceCategoryRenderer.renderAudit (compiled-reportrenderer.js:3546)
at Array.map (<anonymous>)

  Code Snippet 
   -------------- 

const repGen = require('lighthouse/lighthouse-core/report/report-generator');
.
.
.
const testreport = await lighthouse(url, {
        port: (new URL(browser.wsEndpoint())).port,
        output: 'json',
        logLevel: 'SEVERE',
        disableDeviceEmulation: true,
        chromeFlags: ['--disable-mobile-emulation', '--disable-storage-reset']
    }, config);

const json = repGen.generateReport(testreport.lhr,'json'); 
const html = repGen.generateReport(testreport.lhr,'html'); 

Version details 
Chrome      : 79.0.3945.130 (64-bit) 
lighthouse  : 6.2.0
    NodeJs            : v12.18.3
Puppeteer   : 5.2.1
Chromium    : r782078

[patrickhulce]

Thanks for filing @karthigeyan-saran! I know what's going on here. We'll work on a fix 👍

The source-location renderer needs to be able to handle URLs that aren't valid (because they don't create <a> elements)

https://github.com/GoogleChrome/lighthouse/blob/f08ab37e8942205c4bbf91d56609f06631c67ce9/lighthouse-core/report/html/renderer/details-renderer.js#L547-L549

[connorjclark]

@karthigeyan-saran was there a particular URL that this happens on? Can you provide an example?

[brendankenny]

was there a particular URL that this happens on? Can you provide an example?

I've been getting it consistently for the last week in reports from running on https://store.google.com/us/.

[brendankenny]

I've been getting it consistently for the last week in reports from running on https://store.google.com/us/.

looks like it's the relative URL?

{
  type: 'source-location',
  url: '/_/gstore/_/js/k=gstore.gs.en_US.wT0--8C61Io.O/d=1/ct=zgms/rs=AF2QpWz4sGCjLARARhHywMDWhQy1Mxuxgg/m=base,main_app',
  urlProvider: 'network',
  line: 148,
  column: 37
}

[connorjclark]

gotcha, it comes from no-unload-listeners. I guess usage.url isn't an absolute URL. All the other "urlProvider: network" ones are. I bet if the script was from a different domain, the url from the coverage data would be an absolute url.

We could do new URL(scriptUsage.url, URL.finalURL).href in js-usage gatherer to normalize the URLs to absolutes.

[connorjclark]

More generally, how might we avoid such fatal errors? We could run Lighthouse against a few thousand URLs, but that's no good for CI we want to be <5min. Maybe do it as part of the release process? Or as a cron job set to every few days?

It could catch bugs like #11297 too.

[paulirish]

We could do new URL(scriptUsage.url, URL.finalURL).href in js-usage gatherer to normalize the URLs to absolutes.

yup i think we'll have to do this

and ideally we keep track in our types on if something is a fully qualified URL or a potentially-relative url.

[patrickhulce]

More generally, how might we avoid such fatal errors?

Failing to render any particular audit shouldn't crash the whole render. We can try/catch more around individual audits/categories in the report renderer.

[karthigeyan-saran]

Hi Team, @connorjclark Pls find the report which fails to render properly in browser, Hope it would help with further insights

KPI_Adults_report.zip