Bug 1515582 isn't getting all of it, because some of that state is used for security decisions tests depend on.

Boris, is this bug still relevant in light of other removals that have happened in the meantime (in particular the unifdef in Bug 1587627)?

Yes, this is still relevant. See https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/js/xpconnect/src/xpcprivate.h#929-932

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #2)

Yes, this is still relevant. See https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/js/xpconnect/src/xpcprivate.h#929-932

Thanks. Scanning that it looks like removing that may allow us to remove other functions there (RemoteXULForbidsXBLScope, RemoteXULForbidsXBLScopeForPrincipal, AllowContentXBLScope, XBLScopeStateMatches) although it looks like it depends on if we still need the same logic for CanShareCompartmentWith even post XBL (in which case we'd want to at least rename things).

That sounds about right. The real issue is figuring out what the callers of xpc::AllowContentXBLScope really want and then sorting out CanShareCompartmentWith.

It does look like XPCWrappedNativeScope::EnsureContentXBLScope and its transitive callers are all dead code already, as is XPCWrappedNativeScope::IsContentXBLScope. I strongly suspect that xpc::IsContentXBLScope and xpc::IsInContentXBLScope and all the associated machinery are dead too... We should probably file a separate bug on removing all that stuff.

I filed bug 1595890 on the second half of comment 4.

While we are here, we could also rename IsChromeOrXBL / IsChromeOrXBLOrUAWidget / ThreadSafeIsChromeOrXBLOrUAWidget to remove "OrXBL".