Re: [w3c/ServiceWorker] Making a concurrent request for navigations (#920)

Implementor feedback from Chrome: the ability to change navigation preload state (NPS) anywhere (enable/disable/setHeaderValue) is causing some complexities with how this thing is persisted in relation to the existing Registration record.

1. I believe the ideal behavior for the NPS setters is to first persist to disk, then resolve the promise, or reject, e.g., an IO error. A much simpler design would be to resolve immediately and persist to disk as a best effort. How do others feel about this?

2. (Assuming we do care about resolving after successful persistence above) I think most complexity is caused by the ability to set NPS before there is an installed worker: register().then(r => r.navigationPreload.enable()). In this case, for Chrome, nothing is yet on disk: a stored Registration is really just an installed worker: before a worker is installed, there is nothing stored. I believe Firefox is similar. It'd simplify things if the NPS setters reject if there is no active worker. What do others feel about this restriction?

Arguably the registration returned is a nascent one and won't have meaning until a worker successfully installs, so setters shouldn't be called yet.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/920#issuecomment-259661616