New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Navigation Preload can have negative times #139

Closed
yoavweiss opened this Issue Jan 22, 2018 · 5 comments

Comments

Projects
None yet
4 participants
@yoavweiss
Copy link
Contributor

yoavweiss commented Jan 22, 2018

As discussed in #88 (comment), Navigation Preload requests can (and likely to) start before the SW time origin. If they appear in the SW's timeline, they will have negative times.

We should either decide they do not appear in the SW's timeline and make that explicit, and somehow otherwise resolve this issue.

@yoavweiss

This comment has been minimized.

Copy link
Contributor

yoavweiss commented Oct 24, 2018

@yoavweiss

This comment has been minimized.

Copy link
Contributor

yoavweiss commented Oct 24, 2018

According to HR-time, 0 should be the official moment of creation.

@wanderview - do you have any insights into when navigation preload is started in relation to that time? Should it actually be negative, or is it an implementation bug where the worker's timeOrigin is measured too late?

@mattto

This comment has been minimized.

Copy link
Member

mattto commented Oct 24, 2018

Chrome's implementation starts navigation preload just before trying to start the worker. The spec makes them parallel so I don't know if there's a guarantee:
https://w3c.github.io/ServiceWorker/#on-fetch-request-algorithm

Nav preload is at step 12.7 and the request starts in "run in parallel" substeps. Running the worker is at step 17.

@wanderview

This comment has been minimized.

Copy link
Member

wanderview commented Oct 24, 2018

I think the "official moment of creation" definition might be a bit vague here. Its included in step 1 that says:

"Create a separate parallel execution environment (i.e. a separate thread or process or equivalent construct), and run the rest of these steps in that context."

Creating that separate parallel execution environment takes time. Is the timeOrigin at the start or end of this step?

The goal of navigation preload is to start the fetching before the creation of the parallel execution environment. So if the timeOrigin is measured at the end of the step then navigation preload start time will be negative.

FWIW, I have always thought the timeOrigin was marked after the thread was created and the global created on that thread. So at the end of the step. I guess we just need to clarify.

@yoavweiss

This comment has been minimized.

Copy link
Contributor

yoavweiss commented Oct 25, 2018

Decided on TPAC:
We'll add a note to the spec indicating that negative times are possible is these scenarios.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment