Whilst working on Bug 1325505 I noticed that the running serviceworker doesn't reflect the current tab that is running. To debug this use the WIP patch in Bug 1325505. STR: 1. Open a new non container tab with: https://airhorner.com/ 2. Open a personal container tab with: https://airhorner.com/ 3. Open a work container tab with: https://airhorner.com/ 4. Go to about:debugging, the current running container won't be work. 5. Refresh the work tab 6. Go to about:debugging, the current running container won't be work. 7. Unregister the worker that is running 8. Refresh the work tab 9. Go to about:debugging, the current running container will be work. It appears it's first come first serve on what service worker is running, after it is unregistered you are loading the correct service worker. This makes me think there is a limit on running service workers which doesn't check for userContextId.

We should be isolating service worker registrations by origin. So if the principal objects correctly represent the container origin attributes then we should have 3 different registrations here. We must be losing the origin attributes somewhere along the path.

3 are seen however they don't appear to run in the correct order. The current running appears to be the first running even long after that tab has been used. I'm looking into it, as you mention something is losing the origin attributes but I think that is just the debugging panel at the moment.

For what its worth, I checked the origin attributes on a service worker in a container while looking at bug 1388413. The userContextId was definitely set. I'm not sure this bug is valid any more. Or it might have been a representation problem with about:debugging not showing the userContextId.

Bulk change per https://bugzilla.mozilla.org/show_bug.cgi?id=1401020