This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
https://html.spec.whatwg.org/multipage/webappapis.html#environment-settings-object Fetch uses environment settings object as a request client (https://fetch.spec.whatwg.org/#concept-request-client), it would be great if it could include: * "creation URL" - the initial URL of the environment (after any redirects) * "current URL" - the URL of the document including modification by pushState/replaceState/hash changes. For non-documents this would be the same as "creation URL" This would be used by fetch to provide an API to a document client (request.client) that included both fields. It would be used by ServiceWorker to: * use environment settings objects instead of Service Worker Clients https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#service-worker-client-concept * decide which ServiceWorker should control a page on navigation, by looking that the creation URL and seeing which ServiceWorker registrations are in scope * give an API that provides access to all environments for the origin (same object as request.client) * decide which clients a ServiceWorker should take control of, if a new version is choosing to barge in, this will be determined by all clients with a creation URL within the ServiceWorker registration's scope
Can't you get those via the responsible document object? Or is the concern that these need to also be available for workers? What is the URL of a worker environment? The base URL?
We also want these available to workers, although current URL would not be applicable. The URL for a worker environment would be the URL where the script is located, which I think is the same as its base URL, indeed.
A service worker client is now defined in terms of an environment settings object: https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#dfn-service-worker-client To get this work, we need an "active service worker" concept added to environment settings object. (e.g. used in https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#navigator-service-worker-controller). This concept holds an active worker (https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#dfn-active-worker) for the client. It's a service worker (https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#dfn-service-worker) and initially set to null. And its value is set by service worker spec during the installation of the service worker.
So, to sum from service worker POV: "creation URL", "current URL", and "active service worker" are related concepts currently missing to specify it. Could you add them onto environment settings object?
Jungkee, active service worker seems like the SW specification could tack on. Creation URL and current URL however are more intertwined with the rest of HTML and therefore better handled there.
What is "creation URL" to be used for? (Wouldn't base URL or current URL always be better?)
(In reply to Anne from comment #5) > Jungkee, active service worker seems like the SW specification could tack > on. Creation URL and current URL however are more intertwined with the rest > of HTML and therefore better handled there. I'll do this with the service worker client's associated active worker in service worker spec then.
(In reply to Ian 'Hixie' Hickson from comment #6) > What is "creation URL" to be used for? (Wouldn't base URL or current URL > always be better?) A document's service worker registration selection (https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#scope-match-algorithm) occurs when a browsing context navigates to the document's address. On the other hand, when pushState/replaceState/hash changes occur, it won't involve actual fetching and registration selection is not triggered again. This means some of the algorithms in service worker still needs to have a reference to the document's address before any modification by pushState/replaceState/hash changes. And we'd want this creation URL be a concept that can represent both the document's address (in the way explained above) and a worker's script url when the service worker client (environment settings object) represents a document environment and a worker environment, respectively.
(In reply to Ian 'Hixie' Hickson from comment #6) > What is "creation URL" to be used for? (Wouldn't base URL or current URL > always be better?) There's going to be an API to take control of documents that aren't currently controlled, such as documents created before the serviceworker was registered. This will be done by looking at open documents, filtering ones whose url is within scope of the SW that instigated the take-over (and doesn't match a larger scope), and taking them over. I think this should be based on creation url rather than current url, as changing the url with pushState doesn't change the SW controlling the page, but open to other opinions.
Seems like pushState() shouldn't be able to go outside the scope of a service worker. It's kind of weird if it can. But other than that, the above seems reasonable. What is "current URL" for? Is there any reason if you do need that you can't just get it from the Document?
From an environment settings object, what's my path to getting the current document url? Unless I got the wrong end of the stick, Anne suggested there was ambiguity here oin edge cases.
Well, I said you could not get it from the Location object, but you could get it from the document object. It seemed easier to me however if the environment settings object exposed a getter of sorts for the information.
Ahh yes, so "current URL" would be the document's url, or the API base url if there's no document.
I could go either way. My main concern with having lots of things on the settings object is that the more things we have, the more likely they are to diverge, the more likely we are to end up with APIs that are subtly confusing. If we have fewer things, there's more of a chance that APIs will use the same one all the time, and less chance that APIs will diverge in edge cases.
So, the decision would depend on whether those concepts would become useful across HTML spec from this point onward. But service workers spec needs them as convenience handles to the concepts to cover both window and worker clients at the same time anyway. And if I had to do this in service workers, I'd have to set the creation URL to the environment settings object's responsible document's URL in Handle Fetch algorithm when the client selects the service worker registration. I presume defining and setting the value of the creation URL in HTML spec in a right place would be sort of more accurate though. For current URL, I can do the following if we decide not to do this in HTML: A service worker client (an environment settings object)'s current URL is either its responsible document's URL (when its global object is Window object) or its API base URL (when its global object is Worker object).
(In reply to Jungkee Song from comment #15) > A service worker client (an environment settings object)'s current URL is > either its responsible document's URL (when its global object is Window > object) or its API base URL (when its global object is Worker object). It'd be more like: A service worker client (an environment settings object) has an associated current URL, which is either its responsible document's URL (when its global object is Window object) or its API base URL (when its global object is Worker object).
POWER also wants access to a URL from a settings object in order to correctly determine whether an object which has been sandboxed into a unique origin maps to a URL that we'd consider "sufficiently secure". Something like `creation URL` looks like what we'd want.
Moving this to https://github.com/whatwg/html/pull/123.