While investigating another bug I found that we are not actually storing separate RegistrationDataPerPrincipal structures for each principal. Instead we are storing a single struct for all principals with the same extended origin attributes. In desktop this mean nearly all principals end up with a single struct. This will mostly work, but it means all domains are sharing job queues, etc. We also have much slower lookup of registrations by scope since its O(n) across all registrations in the system.

Try is looking pretty green: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a7c9f05f070e I'm going to clean up the patch for review.

In preparation for using something other than origin attributes for the scope key, require all clients to pass a full nsIPrincipal when looking up a registration.

Also rename variable to use the "scope key" terminology instead of referencing the origin suffix. I stopped short of creating an opaque ScopeKey type because its nice to be able to just pass strings around.

Change PrincipalToScopeKey() to use nsIPrincipal::GetOrigin(). This ensures that the hash table keys for different principals do not collide. The origin string produced by nsIPrincipal is guaranteed to contain the suffix if present. Also assert that we are not setting empty scope keys in the future.

https://hg.mozilla.org/integration/mozilla-inbound/rev/e35f587fa328 https://hg.mozilla.org/integration/mozilla-inbound/rev/ffb0e778ab75 https://hg.mozilla.org/integration/mozilla-inbound/rev/8ccab7d6447f

https://hg.mozilla.org/mozilla-central/rev/e35f587fa328 https://hg.mozilla.org/mozilla-central/rev/ffb0e778ab75 https://hg.mozilla.org/mozilla-central/rev/8ccab7d6447f