Report URL in "name" attribute (instead of "document")

[spanicker]

NT2 "name" attribute is currently set to "document".
Should this be set to the URL instead (as in RT2) ?
Related discussion in: https://crbug.com/675039

[igrigorik]

@toddreifsteck if we wanted to align RT and NT in this regard, and report the URL in both.. is that something Edge would be able to align with?

[toddreifsteck]

We should reach out to the various Analytics vendors who are part of the group as well as internal Analytics folks at our various companies.

IE11 and Edge 12-15 currently have shipped with this name='document' behavior for Navigation Timing 2. Although I have no pushback on the value of this update, I have concerns about breaking this behavior given years of a shipping implementation. If we choose to make this change, we should be clear that we are potentially breaking existing web code and should have some due diligence.

@spanicker Perhaps Chrome can ship with name==URL and add Telemetry for getEntriesByName('document') and access to the entry.name entry on NavigationTiming2 objects?

[igrigorik]

We should reach out to the various Analytics vendors who are part of the group as well as internal Analytics folks at our various companies.

/cc @nicjansma

[nicjansma]

I agree that it makes more sense to have name be the document's URL instead of "document" for consistency with RT, though, most people will get the URL from window.location anyways.

Note boomerang does not query for NT2 in the Perf Timeline -- we query performance.timing (which doesn't have the name attribute).

I haven't seen anyone query for getEntriesByName("document") (other than W3C tests) to get NT from the PerformanceTimeline -- and there's only a few examples for getEntriesByType("navigation") (according to Google searches). (My guess is most people just use performance.timing which has been around longer and provides the same data in a different epoch)

Telemetry to validate our assumptions is always good :)

[spanicker]

Unless web devs / Nic indicate that moving to URL improves usability significantly, I'm not sure it's worth the additional last minute drill for NT2, given that it'll take some time & effort to investigate the compatibility issue.

[nicjansma]

I think it would be a requirement for fixing #37, since in that case you would want to know the actual URL of each redirect.

[spanicker]

@igrigorik if you want this for M57, please file a crbug and I'll try to get it pulled in to the release.

[igrigorik]

@nicjansma yep, exactly.

@spanicker we already have https://bugs.chromium.org/p/chromium/issues/detail?id=675039, do we need another one? Personally, I'd strongly prefer we make this change now, before we have to implementations in the wild..

[cvazac]

I haven't yet seen anyone rely on name === 'document'. (I checked episodes and newrelic.)

If this change is made, I suggest the value of name be the requested URL as opposed to the redirect URL. Redirect entries might look like:

PerformanceNavigationTiming
 entryType: navigation
 name: http://www.mysite.com <!-- requested url -->
 redirect_url: https://www.mysite.com

PerformanceNavigationTiming
 entryType: redirect
 name: https://www.mysite.com

[igrigorik]

If this change is made, I suggest the value of name be the requested URL as opposed to the redirect URL.

The other way around, we need to report the final URL (window.location.toString()), otherwise we'll be reporting wrong timestamps for the advertised URL in the future; we can't expose the original URL unless that response passes TAO opt-in.

• Chrome CL (landed): https://codereview.chromium.org/2675973004
• WPT tests (updated): web-platform-tests/wpt@d24a86b

[igrigorik]

• shipping in M57 in Chrome, stable ~mid march
• we'll pause landing it until we have confidence in it

Check back in 2~3 weeks.

[foolip]

I came here from https://lists.w3.org/Archives/Public/public-test-infra/2017JanMar/0025.html

Is it a correct reading of this issue that everyone can live with the proposed behavior, but want to see it proven web compatible before actually committing to the change? This is a fairly common situation, but does make things tricky with Chromium's new 2-way wpt sync. Will comment further on public-test-infra.

[toddreifsteck]

@foolip That is the exact concern.

@patrickkettner flagged so he is aware of this thread.

[plehegar]

web-platform-tests/wpt#9559