This compartment flag was only ever needed in order to track system-privileged
add-on code running under the compartment-per-addon system. That system, and
the legacy add-ons it supported, are gone.
WebExtension compartments have their add-on ID stored on their principal, and
are tracked in less obtrusive ways, so this code is no longer useful.
MozReview-Commit-ID: NVEd3Oawak
--HG--
extra : rebase_source : 31908a4daa5e7897ce165a5383110fb722391662
The path service was created to allow us to track resources that were part of
legacy add-ons, and to map URIs ponting to those resources to add-on IDs, so
that we could apply special behavior to them.
We have better ways to track resources belonging to WebExtensions, so this
code does not benefit them in any significant way.
The only remaining legacy extensions are system add-ons, which we control, and
do not need the path service in order to track.
MozReview-Commit-ID: BKXkcaM7jJx
--HG--
extra : rebase_source : c8cb0f7cec919b767bbcfe5433a6838523747676
The compartment-per-addon code was added so that we could segregate at least
some of the code from system-privileged add-ons into tagged compartments, even
when it ran in browser windows. That allowed us to apply certain special
behavior to them, such as enabling e10s shims, and to track some performance
characteristics.
The only remaining chrome-privileged add-ons now are system add-ons controlled
by us, and the shim system and per-compartment performance metrics are gone,
it no longer serves a purpose.
MozReview-Commit-ID: Ap186bWAaqP
--HG--
extra : rebase_source : c5bf81b44dd42b7cebce2784b7dd98480b41b593
This is all dead code now that the add-on manager support for shimmed add-ons
has been removed.
MozReview-Commit-ID: J6aRQDqEahs
--HG--
extra : rebase_source : 406d65b2a0be6340df6c28f42b38bd8a47b96b77
* I am not entirely sure what this test is doing, but I found that replacing nsSimpleURI with CSPContext makes it work.
MozReview-Commit-ID: 4ATVXVrYX56
--HG--
extra : rebase_source : 33bd1621e23dbc138327a0a406c8e8a11adc8249
* I am not entirely sure what this test is doing, but I found that replacing nsSimpleURI with CSPContext makes it work.
MozReview-Commit-ID: 4ATVXVrYX56
--HG--
extra : rebase_source : 8f9be1a786c85344bfde13649f043a13e113b693
Seemed to only be used for the method that was removed in the previous patch.
MozReview-Commit-ID: 1cKpVBlxa7r
--HG--
extra : rebase_source : 357e5f9f34e418e386ac3966760241db8b7e088f
We're seeing startup crashes which point to data corruption in the source of
the AsyncShutdown component and module, but it's unclear whether the source of
this corruption is on disk, in memory, or in XDR data.
This change annotates crash reports with the contents of those files, so that
we can compare the actual source with the corrupted values in the generated
errors, and narrow down the source of the corruption.
MozReview-Commit-ID: 7p8y73XUGLK
--HG--
extra : rebase_source : 8e1b85df0cf69556af6f998f3d638bf2033e6ca0
extra : source : cf8613751378c8790b56131cd2a1be68573f9286
This is all dead code now that the interposition service has been removed.
MozReview-Commit-ID: H6eS26y1f0f
--HG--
extra : rebase_source : c6f94df51441a62c4fbff4be657aedc9699265f5
The TabBrowser.addProgressListener shim is the only remaining exception, since
the browser_google_behavior.js non-trivially relies on it.
MozReview-Commit-ID: Cc2ARwLkjTA
--HG--
extra : rebase_source : beea6f21dda0517c0a4c9cf09daeafcff85b93c0
We're seeing startup crashes which point to data corruption in the source of
the AsyncShutdown component and module, but it's unclear whether the source of
this corruption is on disk, in memory, or in XDR data.
This change annotates crash reports with the contents of those files, so that
we can compare the actual source with the corrupted values in the generated
errors, and narrow down the source of the corruption.
MozReview-Commit-ID: 7p8y73XUGLK
--HG--
extra : rebase_source : ad31c4fae1cb5c931e166702499dd1e56758d3e3