The STR for this is in bug 1140658 comment 6. Debugging this with Nikhil on IRC, we narrowed this down to RuntimeService::CreateSharedWorkerFromLoadInfo reusing the WorkerPrivate for the SW from the WorkerPrivate of the first SW registered. We should probably clear out the domain map of RuntimeService when a SW is unregistered or some such. Right now RuntimeService seems to be basically unaware of SWs, and I can't even find out what prevents us from reusing the WorkerPrivate for a sharedworker if someone creates a SharedWorker with the name set to the absolute URL for the scope of a SW with the same script spec. I think there is something in this setup that I'm probably not understanding correctly. Nikhil, can you please help me figure out how this is supposed to work? Thanks!

I filed bug 1141274 for the first issue with the name clash with shared workers and will fix that separately. The other part of this bug may be fixed after bug 931249 gets fixed, needs retesting and more thought.

When this bug is fixed, this changeset should be reverted: https://hg.mozilla.org/integration/mozilla-inbound/rev/1b071963e442

Bug 931249 has indeed fixed this issue: https://treeherder.mozilla.org/#/jobs?repo=try&revision=28e9245beb5e So I removed the URL randomization workaround: https://hg.mozilla.org/integration/mozilla-inbound/rev/761766b3de86