-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Add worker modules #608
Add worker modules #608
Conversation
fc7510a
to
d5c09d0
Compare
}; | ||
|
||
enum <dfn>WorkerType</dfn> { "classic", "module" }; | ||
enum <dfn>WorkerCrossOriginMode</dfn> { "anonymous", "use-credentials" }; |
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.
When you pass "omit" here it's not a crossOrigin mode. How about we name this WorkerModuleCredentialsMode
and moduleCredentials
as member (or just credentials
as all new features will require the opt-in anyway)?
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 don't pass omit. It mirrors the crossOrigin
IDL attribute/crossorigin=""
content attribute: missing (null) = omit, anonymous = same-origin, use-credentials = include.
We could use fetch()'s RequestCredentials enum, but I thought it'd be better to stick with the terms and API from HTML. WDYT?
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.
It seemed a little ugly to me to reuse that for a new API. Nullable enum still feels wrong. Workers happen to be in HTML, but that's it.
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.
One advantage of the existing setup is that we can use null to mean different defaults if we extend CORS to classic workers (there null -> same-origin, for back-compat). I guess we could do that with the new scheme though too; we just use RequestCredentials? credentials = null
and determine what null
means based on classic vs. module.
I'm happy to switch this to RequestCredentials credentials = "omit"
for now if you think that's best for new APIs.
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.
Fixed in a separate commit.
7ab1e80
to
85898c9
Compare
I was worried we would not be setting origin and referrer correctly but since we have the correct environment settings object I think that will all work fine. I was thinking that if we do not change classic workers we might entice folks to upgrade to module workers sooner since they can be hosted on a CDN. For service workers the main service worker script is required to be same-origin. There are no restrictions on |
@ajklein @DigiTec @Constellation @jonco3 can I get some comments on this? Is this something we should add to the spec, and you are interested in implementing as you work on modules? Would really be great to get everyone's opinions here. |
There's no doubt that support for modules in Workers is something I, as an implementer (in Chromium/Blink/V8), want to make available on the web. I think most of the interesting bits of this proposal, though, have to do with the API, not with implementation concerns. Workers are less constrained than script tags, since they don't have to interact with the HTML parser and the page-loading system. This might make us wish for a constructor that defaults to module mode, rather than having to pass a second argument to get the module behavior (of course this comes down to a naming problem). I'm also not sure that we want to expose |
Thanks for commenting @ajklein! My intention was for workers, shared workers, and service modules all to be module-ifyiable. If we introduce a new worker constructor, and a corresponding new type of WorkerGlobalScope, I don't think we accomplish this---or at least we cause a small combinatorial explosion as we add (Shared|Service)Worker(Module)(GlobalScope). I also don't think the ergonomic benefits of new WorkerModule(s) over new Worker(s, { type: "module" }) are strong. I'd be up for disabling importScripts inside module workers though. I thought it would be good to allow it so that people can continue to use things like the service worker cache polyfill (which is not authored as a module) but maybe that's short-term thinking. |
FYI this has our interest ;-) I've read the diffs and I don't see anything that would pose difficulties for our implementation. I think the only open question is whether or not we should continue to allow importScripts. Thinking through use cases. I have a worker and I want to import another module, but I don't have access to imperative module loader APIs yet. In the HTML spec, you can start a new module root with script type="module" but workers don't have the same option unless we update importScripts to allow a module type as well. This thinking is also likely short-term as more pieces of modules land. So I'd be okay removing importScripts in the type="module" worker in order to simplify things. It does mean that worker modules are effectively 100% declarative until module loader APIs come along unless i'm missing something else. |
Awesome, thanks @DigiTec! It sounds like there's a collective weak leaning toward disabling importScripts for modules, at least for now. I'll work on updating things in that direction (but keep the commit around in case @Constellation or @jonco3 feel strongly we should keep importScripts). Note that I'll just make importScripts throw a TypeError immediately in a module worker, instead of trying to create some new type of WorkerGlobalScope. @annevk, I'll ping this thread again when that's ready for editor review. Regarding
I think we should leave that for the time when service workers does the integration work, so we can have a discussion on the service worker repo where you educate me as to why it has to be same-origin even with CORS :). |
This looks good to me. I agree with @ajklein about importScripts. I don't think this really make sense for module workers. |
@domenic I'll buy that given the wealth of different worker constructors an options arg is probably the lightest way to go. Thanks for expanding on that. |
85898c9
to
1e9c63c
Compare
1e9c63c
to
c265cc7
Compare
@annevk ready for review! importScripts now throws a TypeError in module workers. (Which, for the record, turns out to be a better name than "worker modules", because "worker classics" doesn't work.) |
c265cc7
to
780cdd4
Compare
@@ -93430,6 +93505,11 @@ function showLogout() { | |||
|
|||
<pre>var worker = new Worker('helper.js');</pre> | |||
|
|||
<p>If you want your worker script to be interpreted as a <span>module script</span> instead of | |||
the default <span>classic script</span>, you can use a slightly different signature:</p> |
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.
s/can/need to/
@annevk pushed a fixup1 commit addressing your feedback. |
LGTM then. The reason service workers require same-origin by the way is to ensure that the domain itself controls the service worker. If the service worker could be controlled by another domain that would make XSS even uglier since the domain might never find out it lost a bunch of users to that other domain. |
d66cbf4
to
e3a5bb7
Compare
Closes #550. The Worker and SharedWorker constructors now get an options object, which can be specified as { type: "module", credentials }, where credentials specifies the credentials mode used for the initial fetch and for subsequent imports. (This only applies to module workers; in the future we could extend it to classic workers if we wished.) importScripts will always throw a TypeError in modules, per discussion in the pull request. The module fetching and execution machinery is entirely reused from that for <script type="module">. This also refactors the machinery for fetching a classic worker script out into its own sub-algorithm of the "Fetching scripts" section.
/cc @ajklein @DigiTec @Constellation @jonco3
Builds on top of the editorial #607 (the first commit), and split into two commits for easier reviewing. This is a pretty simple spec, with most of the complication being in threading the CORS-awareness of modules through workers.
These commits also make it very easy to add CORS support to non-module workers, if people are interested in that while they are mucking around with this area of their implementation. If so let me know and I can tack on another commit doing so.
/cc @jungkees since you are probably going to want to do some of this for service workers too.