1602818 - NavigationStart (and thus 'loadtime') for a page doesn't start until the content process is started in Fission

Status: RESOLVED FIXED

(Core :: DOM: Navigation, task, P3)

Description

[Randell Jesup [:jesup] (needinfo me)]

NavigationStart doesn't start until the content process for the load is assigned and if need be started. In fission, this means that up to a second can elapse between keydown (or click) and NavigationStart. This probably has always been misleading, but in e10s the delay was probably largely constant and small, since we either reused a process (if we were full) or used a prestarted process.

This may be required by spec behavior, but this is misleading currently in fission since content processes are started on-demand, not prestarted (unless we can reuse one from the same domain). This causes reported pageload times in e.g. raptor to be better than reality or visual metrics show. see bug 1602757 for profiles to show examples of this.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

This doesn't affect to pageload as such, but makes measuring hard.

Comment 2

[Chris Peterson [:cpeterson]]

Jesup, will you be working on this NavigationStart bug? Will this bug require changes to the Raptor test runner?

M6a

Comment 3

[u608768]

Could this also be the cause of bug 1623461? The test expects performance.timing.connectStart >= performance.timing.navigationStart but this isn't the case when fission is enabled.

Comment 4

[Matt Woodrow (:mattwoodrow)]

Randell, do you know specifically which sort of loads we get this wrong for?

The current flow should be that load requests get send to the current process for the tab (parent process, or content process, either way is fine).

At that point we should be recording the navigation start timestamp in the DOMNavigationTiming object, and then we send the load request to the parent process.

The parent process waits for a response, creates a new process if necessary, and then delivers the response to the right process. The timing object should be preserved through that.

Comment 5

[Matt Woodrow (:mattwoodrow)]

(In reply to Matt Woodrow (:mattwoodrow) from comment #4)

The timing object should be preserved through that.

Ok, this part is not true right now. We pass it around between process switches, and then overwrite the values :(

I'll fix that in bug 1623461, which has a specific test that catches it.

Comment 6

[Sean Feng [:sefeng]]

Matt, not sure if my comment is going to be helpful.

I also did some investigation about this and left a comment in https://bugzilla.mozilla.org/show_bug.cgi?id=1601401#c5. I'd like to mention that I also see this behaviour without fission when the navigation would create a new process.

Another thing I'd like to mention is the spec. https://bugzilla.mozilla.org/show_bug.cgi?id=1601401#c7. I wonder, depends on the type of the navigation, it might be correct that navigationStart <= connectStart?

Comment 7

[Matt Woodrow (:mattwoodrow)]

(In reply to Sean Feng [:sefeng] from comment #6)

Matt, not sure if my comment is going to be helpful.

I also did some investigation about this and left a comment in https://bugzilla.mozilla.org/show_bug.cgi?id=1601401#c5. I'd like to mention that I also see this behaviour without fission when the navigation would create a new process.

Ok thanks, that's really useful. The fix I landed in bug 1623461 should address exactly that issue (navigationStart being late when we switched process).

Comment 8

[Neha Kochar [:neha]]

Matt, please provide an ETA for this in the whiteboard field.

Comment 9

[Matt Woodrow (:mattwoodrow)]

I don't have anything actionable to do in this bug, the only concrete issue I know of (bug 1623461) has been fixed.

We should probably drop this from M6a, unless jesup knows of other broken cases.

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

(In reply to Matt Woodrow (:mattwoodrow) from comment #4)

Randell, do you know specifically which sort of loads we get this wrong for?

The current flow should be that load requests get send to the current process for the tab (parent process, or content process, either way is fine).

At that point we should be recording the navigation start timestamp in the DOMNavigationTiming object, and then we send the load request to the parent process.

Right. The spec is that NavigationStart is the time the previous page finishes the beforeunload prompt. If there was no previous document (open in new tab, etc) then it's the same as fetchStart (when we start checking the caches or sends the first request. Does "load requests get send to the current process for the tab" mean "we send a load request to the current tab document, which records navigation start after it prompts for unload"?

The parent process waits for a response, creates a new process if necessary, and then delivers the response to the right process. The timing object should be preserved through that.

That sounds like the answer to my question would be "yes". If so, we're handling the first case correctly. The second case would be open-in-new-tab, and in that case is it the same as fetchStart?

If that answer is yes as well, we're done with this, thanks.

Comment 11

[Matt Woodrow (:mattwoodrow)]

Yeah, I think we're doing both of those correctly in most cases.

The exception is for loads that initiate from the parent process (like using the url bar), we sometimes start the load speculatively.

In that case, the navigation start time gets recorded at that point, which will be before we've sent the beforeunload to the old Document.

It doesn't seem possible to have speculative loading, have navigationStart recorded after unload and have connectStart be >= navigationStart.

We might need to push back on the spec, fudge the numbers, or not allow speculative loading. Changing the spec seems like the most useful thing to do.

Comment 12

[Randell Jesup [:jesup] (needinfo me)]

The spec doesn't appear to mandate a relationship between fetchstart/NavigationStart and connectstart, though it's implied.
We could have connectStart be before NavigationStart (and fetchStart too; that has to equal NavigationStart only in the case of no previous document).
In any case, I think we're ok here for now.

Comment 13

[Randell Jesup [:jesup] (needinfo me)]

https://www.w3.org/TR/navigation-timing-2/#processing-model is more relevant, and defines the second case as "when the document was created", not as equal to fetchStart. Also, it deprecates NavigationStart in general.