-
Notifications
You must be signed in to change notification settings - Fork 312
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
Don't associate a job with a client, instead just have a referrer. #889
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@domenic any suggestions on how to best address this? For dedicated and shared workers a settings object is created for the worker before "fetch a module script tree" is invoked, and then that settings object is used to get a module map to store the fetched modules on. For service workers we generally don't create a settings object until the worker actually is started.
Also I would somewhat expect the main script of a module worker to be fetched with the document/worker that created the worker as referrer, similar to how class workers use that as referrer. With the current spec of "Fetch a module script tree" that isn't possible/what happens though. All modules, including the main module of a worker are fetched with the worker itself as referrer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can't start a worker until its global scope/settings object have been created; it doesn't really make sense. Why do you think it's necessary in this case?
It sounds like there's a bug in the referrer handling though; filing an issue at whatwg/html would be much appreciated!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently service workers do:
fetch, create settings object, start
, while other workers do:create settings object, fetch, start
. So in both cases start happens after creating a settings object, it's just the fetching that happens differently.The way the algorithms are currently written we don't create a settings object until after an update check has decided that a new script was indeed downloaded and we really need to start the worker. But yeah, it might actually be a lot clearer/easier to understand if we always create a settings object/global scope for the service worker before we initiate any kind of fetch/update check. If the update check fails we just throw the settings object away, and if the update check succeeded we can then reuse it to fire the install event at etc. Additionally at the end of a successful update check we can store the settings object's module map, similarly to how we currently store the workers script (and when we have to restart the same worker we can prepopulate the settings object's module map with that same module map). That would also address a couple of other places where the spec currently doesn't make sense around module type workers.
Actually rewriting things like that would be a fairly major undertaking, but probably the best way to actually make this all make sense...
Will do.