Adding this requirement to the specs create a few challenges. For the case of tracing metrics, we need to make sure that we have good probes that capture the possible  external user inputs & include them in the tracing categories required for computing TTI.
It's also worth pointing out that we currently have the problem of over tracing that sometimes make the trace analyzing code OOM'ed so we should be careful about including more trace categories that capture the user input.

I don't think I understand totally. If there's a 2nd navigation, then I'd expect we start from scratch for all metrics. So in the example above, I would just expect that we can't compute a TTI for 1st nav. As a result, TTI is Infinity and Page Lifetime was ~12000ms.

Ah, I see the pwm list thread where we decided `null` is a better value in these cases. sgtm

HTTP redirections are handled as a part of navigation [1], so if the page uses HTTP redirection, there should be only one navigation.

If the page automatically jumps to different URL by other means (e.g. setting window.location), it starts another navigation, so this problem arises.

In trace-based systems, it would be possible to compute TTI over navigations as Ned suggested. But it's harder to do that in PageLoadMetrics (used for paint timings UMA). Also, it wouldn't fit the model of webperf API which is tied to single navigation.

How often does this happen? If possible I'd like to keep current simple model where we start from scratch after new navigation.

[1] https://www.w3.org/TR/navigation-timing-2/#process

It sounds like this will be really hard to solve in full generality, but can we fix it for the case where we can't compute the TTI for an early subsequent navigation? Right now if we have this case: 

*                   *                 *                   *                 *           *
|                   |                 .                   |                 |           |
|                   |                 .                   |                 |           |
v                   v                 v                   |                 v           v
1st navigation   1st FMP        1st TTI never          2nd nav            2nd FMP     2nd TTI
N1                  P1            reached                 N2                P2          T2

we report both [N1, T2] and [N2, T2], while we should be reporting only [N2, T2]. This is mostly because the logic for deciding whether to report TTI is coupled with whether to report FMP, but there are certainly many cases when FMP is reached but TTI is not.

FMP behavior today is more reasonable. If we have this case: 

*                       *           *             *
|                       .           |             |
|                       .           |             |
v                       v           v             v
1st navigation   1st FMP never    2nd nav      2nd FMP
N1                  reached         N2            P2

we only report [N2, P2] as our FMP time and discard N1. 

Here is a quick fix: https://codereview.chromium.org/2337023004. If the approach looks reasonable I can fix the test as well and make it ready for proper review. 

Looks reasonable to me.

+Ned

The logic above WFM, too.

I am not sure discarding [N1, T2] is right. If you squint your eyes, the automatic redirection of the page could be considered an anti-pattern that push TTI further. By keeping [N1, T2] & reporting T2 - N1 being huge we make sure that our loading metrics discourage people from doing so, which is a desirable effect?

For a concrete example, think about a case of facebook adds redirection to their homepage. Which loading metric in their CI service will regress?

Is there a way to differentiate between an page-initiated-redirection vs a user-initiated-navigation? It sounds problematic to have one metric that serves both use cases. 

When I record a trace from chrome://tracing, and then open the metrics side panel, the average value of TTI should be something reasonable. If my activities include doing user-initiated-navigation across a bunch of pages, some of which navigations never let the page reach interactive status, then the TTI histogram should only contain the cases where a TTI could be computed. Right now it's polluted with some strange super-high-valued TTIs that I really was not meaning to monitor. On the other hand, if any of the sites I visited had funky window.location setting redirections, then yes, it would be awesome if the TTI value can call out this shenanigan.

But unless we can tell the navigations apart, these two use cases are in conflict and cannot be represented by the same metric. How do we go forward from here? 

1. Can we already or is there any possibility in near future of being able to differentiate navigation sources?
2. If not, does it make sense to create two different TTI metrics for these two use cases?
3. If that will introduce too maintainability burden for what it's worth, should we just assume that users of this metric will only compute this for the case of a single page load with no user-initiated navigation? Then we can assume all navigations are page-initiated and then the TTI values make sense. 

On user input, we want to essentially abort TTI computation, right? I believe we already do this for FMP.

If we do this, I think it should be pretty straight forward to do what Ned suggestions

Do you mean that for every user-initiated navigation, there should be a user input we can capture that we can use to abort the computation? Hm yes that would definitely be the best solution. 

I'm not sure this is true even in the case where the user types in another url in the browser or clicks a bookmark, although we can constrain the scope of this metric to exclude those stories. 

You're right that this wouldn't work outside of web contents. Ideally we'd have a solution that would for for UMA.

I'm not sure how easy it would be to detect redirects vs user input outside of web contents. It may not be too bad?

Deep, what's the current status here?

We do this already for UMA. When we substitute our TTI catapult definition to instead pick up the TTI value from the chromium trace event, we will get this for free. 

Should we switch the TTI catapult definition to use the value from the trace event?

I guess we should probably add the UMA version as a separate metric first, to make sure they agree?

That sgtm. I can take this on. 

Deep, any update on this?

Not yet sorry but thanks for the reminder. I have an OKR to enable alerting on TTI. I'll fix this bug before doing that.