CompartmentHasExclusiveExpandos(obj) returns true iff IsInSandboxCompartment(obj), but that's no longer valid when system sandboxes can be in the same compartment as other system realms.

I think we should be OK losing this feature for system principal sandboxes. It's generally not really what we want for those sandboxes, anyway. We actually talked about getting rid of it altogether, but it's necessary for X-ray ICs at this point.

(In reply to Kris Maglione [:kmag] from comment #1) > I think we should be OK losing this feature for system principal sandboxes. > It's generally not really what we want for those sandboxes, anyway. Agreed. > We actually talked about getting rid of it altogether, I believe the original motivation may have involved addons / content scripts. Is this a non-issue for WebExtensions? > but it's necessary for X-ray ICs at this point. Elaborate? Would this concern go away with CPO?

(In reply to Bobby Holley (:bholley) from comment #2) > (In reply to Kris Maglione [:kmag] from comment #1) > > but it's necessary for X-ray ICs at this point. > > Elaborate? Would this concern go away with CPO? So, basically, the ICs for expando properties rely on the compartment-specific expando behavior so that we can cache the expando object/slot for an object, and not worry about another same-origin compartment creating an expando object for an X-ray-wrapped object without us noticing. I don't remember the exact details, but that's the gist. I think CPO would probably help there if it lets us get rid of the origin->expando map, and just have compartment-specific expandos everywhere, yeah.

Pushed by jdemooij@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/dfe2c80571c6 Stop using exclusive expandos for xrays in system-principal sandboxes. r=kmag