finalDisplayedUrl being set to :

[vipulnaik]

FAQ

• Yes, my issue is not about variability or throttling.
• Yes, my issue is not about a specific accessibility audit (file with axe-core instead).

URL

https://www.si.com/
https://www.elle.com/
https://www.newyorker.com/

What happened?

For a few sites with ads, running the Lighthouse report in non-incognito Google Chrome yields empty reports.

Example of www.si.com

The Lighthouse section of devtools while the Lighthouse report is running:

What the Lighthouse section of devtools looks like right after the run finishes -- note the blank page, and the fact that there's nothing after the - following the time for the title in the dropdown on the top left (after the time of run) left where the url should be present.

Example of www.elle.com

The Lighthouse section of devtools while the Lighthouse report is running:

What the Lighthouse section of devtools looks like right after the run finishes -- note the blank page, and the fact that there's nothing after the - following the time for the title in the dropdown on the top left (after the time of run) where the url should be present.

Example of www.newyorker.com

What the Lighthouse section of devtools looks like right after the run finishes -- note the blank page, and the fact that there's nothing after the - following the time for the title in the dropdown on the top left (after the time of run) where the url should be present.

What did you expect?

I expected behavior similar to what I see in incognito.

The Lighthouse section of devtools while the Lighthouse report is running:

What the Lighthouse section of devtools looks like right after the run finishes -- note the presence of an actual report on the page, and also note that the title in the dropdown on the top left includes the url:

What have you tried?

I used devtools of devtools to access the browser console panel as well as the sources panel for the Lighthouse run itself.

I noticed this error consistently in the console (in devtools of devtools)every time a blank report was generated, with an occurrence right at the end of the report generation (so right before the blank report was served up to me):

Clicking through took me to sources (in devtools of devtools), and I located the line in report.js. I added a debugger breakpoint and reran the Lighthouse report to catch the error when it happened.

Note the value of e is :, and this is causing createOrReturnURL to give an error because : is not a url. See also the stack trace summary printed on the right. Working backward through the trace, I got to this line:

So it looks like the return value of getFinalDisplayedUrl is :, and that's what gets passed down as e. To figure out why getFinalDisplayedUrl is returning :, I set a debugger breakpoint in that function. Then I reran the Lighthouse report.

Here's what I found. See the Watch on the right that includes the full value of e, and note that at the point of first entry into this function, the finalDisplayedUrl attribute is already :. So getFinalDisplayedUrl is just reading that value and returning it.

So what's responsible for the setting of finalDisplayedUrl to :? I could not figure this part out conclusively, because searching through sources in devtools of devtools did not find the place it was being set. However, looking at the Lighthouse source code on GitHub suggests that this is likely happening with the line

lighthouse/core/gather/navigation-runner.js

Line 244 in 49aa142

finalDisplayedUrl: await navigationContext.driver.url(),

I inferred this because my Lighthouse run was of type navigation, and this seems like the only match in the code where that value is being set and that I expect the code to go through. Unfortunately, this code doesn't seem to be accessible in devtools of devtools.

So unwinding, we get that, in non-incognito Google Chrome Devtools Lighthouse, for some sites with ads:

1. finalDisplayedUrl is being set to : somehow; this is likely a result of

   lighthouse/core/gather/navigation-runner.js

   Line 244 in 49aa142

   finalDisplayedUrl: await navigationContext.driver.url(),

   somehow returning : but I could not verify this directly.
2. Therefore, getFinalDisplayedUrl in https://github.com/GoogleChrome/lighthouse/blob/main/shared/util.js (specifically,

   lighthouse/shared/util.js

   Lines 58 to 62 in 49aa142

   	static getFinalDisplayedUrl(lhr) {
   	if (lhr.finalDisplayedUrl) return lhr.finalDisplayedUrl;
   	if (lhr.finalUrl) return lhr.finalUrl;
   	throw new Error('Could not determine final displayed URL');
   	}

   ) returns :.
3. Therefore, createOrReturnURL in https://github.com/GoogleChrome/lighthouse/blob/main/shared/util.js (specifically,

   lighthouse/shared/util.js

   Lines 281 to 287 in 49aa142

   	static createOrReturnURL(value) {
   	if (value instanceof URL) {
   	return value;
   	}
   	return new URL(value);
   	}

   ), gets passed the value : and gives an error because : is not a url.
4. This causes an uncaught error and seems to be responsible for generating a blank report.

NOTE: See comments for further diagnosis, particularly #15073 (comment) suggesting that this is related to the privacy sandbox setting.

Other data

How were you running Lighthouse?

Chrome DevTools (non-incognito)

I haven't had an issue with any of these sites when using incognito Chrome Devtools. I also haven't had an issue using the Node Lighthouse, which is similar to incognito in the sense of having a relatively clean slate.

I don't know what is different between my regular Chrome and incognito; one possibility is a bunch of application state including cookies, local storage, IndexedDB etc. However, I haven't visited www.newyorker.com for a while before today when I ran the Lighthouse reports, and I still got the error on www.newyorker.com in my regular Chrome.

I've also seen an increased rate of Lighthouse errors when making requests to pagespeed.web.dev and/or the PageSpeed Insights API for sites with ads, and I suspect that those failures may be for a related reason. In those cases, the information I get is just that "something went wrong" or ERRORED_DOCUMENT_REQUEST or something like that, so it's difficult to map that back to the root cause. PageSpeed Insights API seems to be running Lighthouse 10.2.0, so if the root cause is the same, that suggests it is not yet fixed in 10.2.0.

Lighthouse Version

10.0.1

I manually looked through the changes since 10.0.1 and none of them seem to address the portions of code that I identified. However, since I can't reproduce the issue with Node Lighthouse, it's a little tricky to test the issue against a newer version of Lighthouse.

finalDisplayedUrl and getFinalDisplayedUrl seem to have been introduced as part of Lighthouse 10, so this particular issue should not have happened with Lighthouse 9. Indeed, I haven't encountered blank reports occurring with Lighthouse 9.

Chrome Version

113.0.5672.92

This is the latest Chrome version, released about two days ago.

Node Version

No response

I also have Lighthouse installed using npm and I run it with Node v18.15.0, npm 9.5.0. But I haven't replicated the issue in Node Lighthouse, as noted above.

OS

Mac Silicon, M1 Air, Mac OS 13.3.1 (a)

Relevant log output

No response

[vipulnaik]

One suggested fix is to update getFinalDisplayedUrl to also validate finalDisplayedUrl (to check if it is of type URL, the same way that createOrReturnURL runs a check) and to fall back to finalUrl if finalDisplayedUrl is not of type URL. I am not sure this should be done, though. Perhaps it is better to enforce the validation further upstream? Or perhaps enforcing it here as well is a sound idea?

[devtools-bot]

Thanks! Appreciate you filing this bug. 👏

This is a known issue, most well described in #2784. So, we'll automatically close this as a duplicate.

However, if you believe your bug is different than the cases described there, please comment here with "necessarily-wide-alpaca" and I'll reopen this bug. 🤖 Beep beep boop.

[connorjclark]

@paulirish i'm kind of over this bot.

[connorjclark]

I cannot repro. This not happening in incognito for you is typically a sign of an extension being the cause. Could you try toggling some extensions in your main Chrome profile and see which one it could be?

[vipulnaik]

EDIT: I see one extension that I didn't turn off (though this extension doesn't connect to any website data at all), let me turn that off and retry.

EDIT 2: Done retrying, see next comment: #15073 (comment)

This is still happening to me after I deactivated all extensions, then quit and restart Chrome.

Chrome extensions that I had, all deactivated (even previously, none of the extensions were active on those specific pages because I've configured my Chrome extensions to only be active on click or on specific sites):

The report is blank again:

I see the same error again in devtools console of devtools:

I can try to triangulate exactly what aspect of my local state (cookies, IndexedDB, etc.) is responsible for this. But regardless of the specific cause, what do you think about falling back to finalUrl when finalDisplayedUrl exists but isn't a url, as I suggested at #15073 (comment)? At minimum that would get us past the situation of a completely blank report.

Stay tuned -- I'll post another comment after triangulating the aspect of my user state that is causing this issue.

[vipulnaik]

ok here's a fixed version of the previous comment after I disabled all extensions (I had left one out). Still seeing the issue:

[vipulnaik]

@connorjclark it seems that it isn't related to extensions or application state, but rather to the privacy sandbox setting. I noticed something suspicious with some user sync requests being pending on one page load, and nothing else was pending. This led me to remember that I have the privacy sandbox origin trial enabled. This setting can be toggled at chrome://settings/privacySandbox

Toggling this on and off, I was able to replicate the Lighthouse report failing and succeeding. This time I tried another site https://www.thestreet.com/

Here's the alternating on/off fail/success pattern, demonstrated through a screenshot (see the dropdown on the top left):

Can you reproduce the issue after toggling privacy sandbox on at chrome://settings/privacySandbox on any of the urls (www.si.com, www.elle.com, www.newyorker.com, www.thestreet.com)? If you can't reproduce, I'll continue to look into differences in my environment that may be driving this. If you can reproduce, I think you're all set? But let me know if you need anything else.

[vipulnaik]

@connorjclark FWIW I'm still seeing this issue in Chrome 114 with Lighthouse 10.1.1: the finalDisplayedUrl is being set to - when the privacy sandbox setting at chrome://settings/privacySandbox is toggled to on, and therefore the Lighthouse report isn't showing up by the mechanism I outlined above. The report is generated when I toggle privacy sandbox to off. I think this fix #15073 (comment) would still work for such situations though it doesn't get to the root cause of why finalDisplayedUrl is being set this way.

[adamraine]

I'm seeing this happen consistently on https://espn.com in DevTools now. Will investigate further.

[adamraine]

Update on investigation, this appears to be coming from a fenced frame (notice the target subtype). Still not sure exactly how this event gets created though. Will file upstream.

{
  "method": "Target.attachedToTarget",
  "params": {
    "sessionId": "221795A5659470D7AC6FCBF3F311D882",
    "targetInfo": {
      "targetId": "F5B7345C9BF9413F71A9B51D22304A82",
      "type": "iframe",
      "title": "",
      "url": "",
      "attached": true,
      "canAccessOpener": false,
      "browserContextId": "6310EBC13B0F02CB468081EC10C1A4B0",
      "subtype": "fenced"
    },
    "waitingForDebugger": true
  },
  "sessionId": "B5668ED04C68E8A4178A04D5EE1EB6E0"
}

Frame tree:

{
  "frame": {
    "id": "F5B7345C9BF9413F71A9B51D22304A82",
    "loaderId": "4BDF72DDE41DDD533EFDE652EB563B30",
    "url": ":",
    "domainAndRegistry": "",
    "securityOrigin": "://",
    "mimeType": "text/html",
    "adFrameStatus": {
      "adFrameType": "none"
    },
    "secureContextType": "InsecureScheme",
    "crossOriginIsolatedContextType": "NotIsolatedFeatureDisabled",
    "gatedAPIFeatures": []
  }
}

[adamraine]

https://bugs.chromium.org/p/chromium/issues/detail?id=1464949

[adamraine]

The bandaid fix has landed in the latest Puppeteer and it was merged into DevTools. The root cause is tracked by the chromium issue.

No further action should be necessary in the Lighthouse repo.