Move name up from SharedWorkerGlobalScope to WorkerGlobalScope, add corresponding argument to Worker()

[hober]

Since websites may spawn multiple dedicated workers with the same script URL, it would be nice if each could be given a name so they can be usefully disambiguated in debugging tools. See the related WebKit bug.

[hober]

cc @JosephPecoraro

[annevk]

That would also end up affecting service workers. Probably does not make sense there, @wanderview @jungkees?

The other thing is that we recently added WorkerOptions as second argument for dedicated workers and third argument for shared workers. If we added name as member there for dedicated workers that would make the APIs somewhat asymmetric. WorkerOptions is perhaps not implemented though (not sure anyone is doing that part of JavaScript modules) so maybe we can still change things around.

[wanderview]

Overall seems reasonable to me.

In regards to the webkit issue's example code:

    var worker1 = new Worker("worker.js")
    worker1.name = "Foo Worker";

    var worker2 = new Worker("worker.js");
    worker2.name = "Bar Worker";

It might be a bit nicer to make this a constructor option and then a readonly attribute. Immutable data is a bit easier to work with in our worker implementation.

In regards to service workers, we have internally actually mapped the service worker scope to the worker name. We don't expose that to script, though. Not sure if that is worth doing as a default name.

[domenic]

@mattto any thoughts from Blink? @travisleithead Edge?

Constructor option (as part of the WorkerOptions dictionary) sounds like a good idea to me.

Not sure what to do here for service workers; I'll leave that in the hands of the service worker spec people.

[mfalken]

I don't have a strong opinion but this sounds reasonable. @kinu @nhiroki

Should the API enforce the uniqueness of the name?

For service workers, the spec calls for an id per service worker which additionally is unique within a scope. However there is talk of removing that from the spec w3c/ServiceWorker#1076

It feels like this should be aligned with the service worker spec somehow. @jakearchibald

[kinu]

Sounds reasonable to me too, and constructor option looks good.

Agreed that it'd be nice to have an aligned story for Service Workers, we can expose something as a default (like 'id' thing), while a question there would be if we want to allow developers to specify other names (and if so how).

[domenic]

Hmm, OK, we should probably coordinate with service workers indeed. I filed w3c/ServiceWorker#1121. I hope we can get people to weigh in there quickly so as to unblock this approach.

One concern I had here is that people might expect the semantics of name for dedicated workers to be similar to those of shared worker, where if you supply the same name, it somehow shares the worker. I guess it's probably fine though? I dunno, should we throw an error if you supply a non-unique name for dedicated workers?

The other thing is that we recently added WorkerOptions as second argument for dedicated workers and third argument for shared workers. If we added name as member there for dedicated workers that would make the APIs somewhat asymmetric. WorkerOptions is perhaps not implemented though (not sure anyone is doing that part of JavaScript modules) so maybe we can still change things around.

I also noticed this. I think if we do this we should add an overload to SharedWorker that makes it (url, options) where options contains a name, and get rid of (url, name, options).

[annevk]

And whoever gets to answer the question about uniqueness, please qualify it with scope if it needs to be unique: unique within an agent cluster or unique within the browser.

[wanderview]

We have a compat problem with our implementation of this:

https://bugzilla.mozilla.org/show_bug.cgi?id=1375457

It seems like we need to make the property [replaceable].

[domenic]

I posted a spec fix: #2783.