Open Bug 1526622 Opened 6 years ago Updated 2 years ago

Remove the remaining "xbl scope" state from xpconnect


(Core :: XPConnect, task, P3)




Tracking Status
firefox67 --- affected


(Reporter: bzbarsky, Unassigned)


(Blocks 1 open bug)


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

Priority: -- → P3
Type: enhancement → task
No longer blocks: war-on-xbl

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

Flags: needinfo?(bzbarsky)

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

Yes, this is still relevant. See

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".

Depends on: 1595890
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.