This turns out to be a pretty unfortunate bifurcation in practice.

For navigations, finalDisplayedUrl really isn't useful for almost anything except displaying at the top of the final report. In practice it doesn't matter many times (it has to be the same origin as mainDocumentUrl and a lot of our uses of it are same-origin checks), but it does allow keeping a standardized "use the main document" as the reference for everything.

Splitting between uses of mainDocumentUrl and the displayed url breaks that a bit, and makes it so you have to spend longer on code thinking, which URL do I need to use? But mainDocumentUrl doesn't exist for timespans/snapshots.

But...could it exist? Surely there's some way of retrieving that information. TracingStartedInBrowser event in traces? The frame tree somewhere? Page.getNavigationHistory or whatever?

But...could it exist? Surely there's some way of retrieving that information. TracingStartedInBrowser event in traces? The frame tree somewhere? Page.getNavigationHistory or whatever?

Believe me when I tell you that I have tried:

• TracingStartedInBrowser: Not available in snapshot mode
• The frame tree: Always the frame/displayed url
• Page.getNavigationHistory: I forget the details but hit a roadblock with 300 redirects

Even if we could get mainDocumentUrl for timespan, would it represent the main document at the start or at the end?

TBH we may not need to include mainDocumentUrl on the LHR. finalUrl is the exact same thing in its deprecated state for historical reasons but we don't actually use either from what I can tell.

Even if we could get mainDocumentUrl for timespan, would it represent the main document at the start or at the end?

Absolutely a good point but functionally equivalent to if it makes sense for e.g. third-party-summary's mainEntity to be based on finalDisplayedUrl, so it doesn't really matter for this. The answer to that is going to have to come out of some deeper decision(s).

edit: we still have time to switch it to finalMainDocumentUrl :P

TBH we may not need to include mainDocumentUrl on the LHR. finalUrl is the exact same thing in its deprecated state for historical reasons but we don't actually use either from what I can tell.

@brendankenny what do you think about removing mainDocumentUrl from the lhr but keeping finalUrl?

adam, can you update the PR title to reflect the current state?

seems like it's

add finalDisplayedUrl,mainDocumentUrl to LHR. deprecate finalUrl.

removing initialUrl from artifacts seems minor in comparison but i'd call it out in the initial summary.

@brendankenny what do you think about removing mainDocumentUrl from the lhr but keeping finalUrl?

The argument against that is that the name finalUrl is ambiguous. And that's why mainDocumentUrl is the new name of it. adding a final- prefix isn't needed for navigation, but does make sense for timespan, as there could be multiple.

But mainDocumentUrl doesn't exist for timespans/snapshots.
But...could it exist? Surely there's some way of retrieving that information.

performance.getEntriesByType('navigation')[0].name

This has it. It also includes the hash fragment, but that's easily strippable.

removing initialUrl from artifacts seems minor in comparison but i'd call it out in the initial summary.

Sounds good.

The argument against that is that the name finalUrl is ambiguous. And that's why mainDocumentUrl is the new name of it. adding a final- prefix isn't needed for navigation, but does make sense for timespan, as there could be multiple.

I just don't think it makes sense to call out a singular mainDocumentUrl in timespan mode. I could see us creating a list of main document urls for something like 3P analysis, but we will never need just the last one for timespan mode.

This has it. It also includes the hash fragment, but that's easily strippable.

This looks promising. I'm still hesitant to use it in timespan mode for the reasons above, but this could work for snapshot mode. I would do this in a follow-up PR since we don't have a use for it yet.