Open
Bug 1493169
Opened 6 years ago
Updated 2 years ago
Consider putting all things that should be sharing an Xray's expandos into a single compartment
Categories
(Core :: XPConnect, enhancement, P3)
Core
XPConnect
Tracking
()
NEW
People
(Reporter: bzbarsky, Unassigned)
References
(Depends on 1 open bug)
Details
Once we can do multiple globals per compartment, would it make sense to use a single compartment for all system code? Or at least for all the things that might want to share expandos on an Xray? The goal would be to get rid of Xray expando chains and just always have the expando object hang off the holder. Maybe we're already there with all JSMs sharing a global...
Comment 1•6 years ago
|
||
Yeah, this was only ever really needed for system compartments. If we get to (or already are at) the point where all non-sandbox system principal code is running in the same global, we can just do this. That said, it might be a bit less risky to wait for Jan's stuff.
Comment 2•6 years ago
|
||
(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #0) > Once we can do multiple globals per compartment, would it make sense to use > a single compartment for all system code? Or at least for all the things > that might want to share expandos on an Xray? Definitely. We should do this even if we don't care about X-ray expandos. The cross-compartment overhead between browser window and JSM scopes still adds up to a lot. (In reply to Bobby Holley (:bholley) from comment #1) > Yeah, this was only ever really needed for system compartments. If we get to > (or already are at) the point where all non-sandbox system principal code is > running in the same global We're close, but browser windows still each get their own compartment. I don't think we could get away with losing expando sharing for those. We unfortunately also still have some system code running in sandboxes (mainly devtools, but also some extension framework code that an intern decided to move to a sandbox for some reason :/). That probably isn't relevant here, though.
Comment 3•6 years ago
|
||
(In reply to Kris Maglione [:kmag] from comment #2) > (In reply to Bobby Holley (:bholley) from comment #1) > > Yeah, this was only ever really needed for system compartments. If we get to > > (or already are at) the point where all non-sandbox system principal code is > > running in the same global > > We're close, but browser windows still each get their own compartment. I > don't think we could get away with losing expando sharing for those. Although, realistically, with e10s maybe we can. There shouldn't be many places we need to deal with X-rays in the parent process anymore, and all chrome code in the content process should run in the same global now. I suppose if we wanted to play it safe, we could just change the behavior of content processes to start with, and extend it to the parent process when we're sure it's safe.
Updated•6 years ago
|
Priority: -- → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•