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.
Depends on: 931249
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
Assignee: nobody → ehsan
You need to log in before you can comment on or make changes to this bug.