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
On OS-X, this test sees an extra 'No chrome package registered for
chrome://branding/locale/brand.properties"' console warning, which causes it
to inspect the wrong error when checking for location information.
--HG--
extra : amend_source : a51aedad5b11b92f564ea739308000a41ff89578
There's no standard way to create a JS error with full stack and location
information from a saved stack. Since we need this functionality in order to
reject promises with useful Error objects, this patch adds a simple helper to
make that possible.
MozReview-Commit-ID: FyGuo4UjfsQ
--HG--
extra : rebase_source : 65ef11c56f23e04ea5eeb87b972bfc8e4867fdd2
Building on top of part 1, we need a way to link a saved caller location to a
reported error message. This change allows us to pass a stack to `reportError`
when called with a string.
This part was written before part 3, and could probably be removed in favor of
using createError in every call. But this method also has the advantage of
being more consise and somewhate more efficient.
MozReview-Commit-ID: 39jfCg9AerY
--HG--
extra : rebase_source : cc5bf96e11e861a81e04167c2bfa4828e5224c3e
Most WebExtension APIs are async, and have fairly complicated error reporting
semantics. As a result, when we report an error, the current JS stack has very
little to do with the JS caller that triggered the error, which makes it
difficult to diagnose.
In order to improve the situation, we need to store the location of the caller
at the start of an async operation, so we can tie the error to some marginally
useful location. We don't have a reasonable way to do that now other than
proactively creating an error object when the API is called, or creating a
promise with a full async stack, both of which are too expensive.
This helper instead returns a single SavedStack frame with a given principal,
which should be considerably cheaper, and likely good enough to give a
starting point for debugging cryptic errors.
MozReview-Commit-ID: BTxhpZK9Fdz
--HG--
extra : rebase_source : 7f2c66b1dc18d4ce4c47bef2e3b9d5d3ade929aa
Back out bug 1417254, bug 1348087, and bug 1416295 for continuing to cause app update failures.
Backed out changeset ec6f1b3c1317 (bug 1417254)
Backed out changeset df5703f27971 (bug 1416295)
Backed out changeset ae2fcdddead1 (bug 1348087)
Backed out changeset fb54cd45fa10 (bug 1348087)
Backed out changeset edfa340ec9fb (bug 1348087)
Also, get rid of a gratuitous use of a trinary operator in
nsXPCWrappedJSClass::CallMethod, clean up the style a little, and mark
an unimplemented ctor as deleted.
MozReview-Commit-ID: Kp64sMxyRWc
--HG--
extra : rebase_source : e6082003d3759234cd5f4630b5560b14930c0a88
nsXPTMethodInfo is a nicer structure to use, and this paves the way
for making the two types different, which will be needed if I make
XPTMethodDescriptor statically allocated.
Also, use the higher level accessor methods.
MozReview-Commit-ID: JbRdLU5Wwyt
--HG--
extra : rebase_source : 48f6c4e98e43c75006ceeb02bd727b59d3726681
This is needed to allow interposition for gBrowser, which will change from a DOM node
into a plain JS object in Bug 1392352. An object can set the `requiresAddonInterpositions`
property to enable this feature.
MozReview-Commit-ID: 4Uw5xzgZtXO
--HG--
extra : rebase_source : 203fe656da3ecd514d4e27ad0eeb4885cf4e9b0b
Removing #define XRE_DONT_PROTECT_DLL_LOAD from plugin-container.cpp and xpcshell.cpp allows the #included nsWindowsWMain.cpp to protect DLL loads much earlier in the plugin process startup.
MozReview-Commit-ID: HbgyfvljvFs
--HG--
extra : rebase_source : dccdabb2e5bee4472d5aef9400a58cb0e397c112
extra : histedit_source : da248fc6fbdf96f30979f3a0396aefcf4bfcd5d9
This avoids a redundant alloc and copy in `PutBuffer`. All existing callers
were destroying the passed in buffer after the call.
--HG--
extra : rebase_source : 065505219d70d26bad49c7eba2cec8edf0e9939d
extra : amend_source : 118eddad4dc901da02817c788fb98f6f4c85a3f0
extra : source : 7f0cedfb4bd85bfe1a523168019864c9c6c0e665
This avoids a redundant alloc and copy in `PutBuffer`. All existing callers
were destroying the passed in buffer after the call.
--HG--
extra : rebase_source : 39a21686becedf32c38e58fa832ae47845b2f5e0
"Include what you use."
--HG--
extra : rebase_source : 2239a380029e0efbc9dd3042459222a67c38d70f
extra : amend_source : 4453c32cc469caa592049167205666997f1a1e7b
extra : histedit_source : a533edd4a4d3d0642b08989e93674661d27baa6a%2C37d27eeef9580381ccc0de8507f60166dabf1730
The error handling logic here would fail to remove a stale raw pointer from
mInProgressImports if the EnsureURI() call failed. Fortunately, it's not
actually possible for EnsureURI() to fail in this case, because the
EnsureResolvedURI() call above already implies EnsureURI(). That said, we're
better off structuring this code to ensure that we never leave a value in
mInProgressImports after we exit the scope.
MozReview-Commit-ID: 8mnKcHL75x
--HG--
extra : rebase_source : 332b48fde97adacfefd7771185df35c217dfbe84
Now that we've used the standard NS_IMPL_QUERY_INTERFACE macro, we can
start using the even more standard NS_IMPL_ISUPPORTS macro. There's a
standard NS_IMPL_ISUPPORTS_CI macro that we could use for the bits in
XPCJSID.cpp, but said macro assumes that all the interfaces listed are
exported to classinfo. nsJSIID and nsJSCID expose nsIXPCScriptable
through QI, but not through classinfo, so I've chosen to leave those
alone.
This construct is nicer than NS_INTERFACE_MAP_BEGIN and assures the
reader there's no weirdness in the QI implementation. This change does
mean that PGO doesn't get an opportunity to measure the frequency of
which interfaces are QI'd most often. I think this is probably an OK
tradeoff to make, given the prevalence of NS_IMPL_QUERY_INTERFACE
elsewhere in the codebase.
The one thing we have to ensure with this change is that the ambiguous
QI to nsISupports uses the proper class after the change. The
NS_IMPL_QUERY_INTERFACE macro chooses the first interface listed to
disambiguate the cast to nsISupports. In many cases, the ordering of
the interfaces was already correct, but a few cases required reordering
the interfaces.
These are cases that are implementing the "convert an exception to a Promise"
steps of the Web IDL spec. Typically the exception is thrown in the current
compartment; the Promise returned should simply match that. Otherwise we can
end up with a situation in which the promise doesn't actaully have access to
its rejection value, which will cause problems if someone uses then() on the
promise: the return value of the then() call will get a sanitized exception
instead of the real one.
We _could_ try to match the actual compartment of the exception, in theory.
But it's not clear why this would be preferable to using the current
compartment, even if there were cases in which the exception _doesn't_ match
the current compartment. Which there likely are not.
MozReview-Commit-ID: Ac2BHIHxfvY
--HG--
rename : dom/promise/tests/test_promise_argument.html => dom/promise/tests/test_promise_retval.html
rename : dom/promise/tests/test_promise_argument_xrays.html => dom/promise/tests/test_promise_retval_xrays.html
For locations, it always returns undefined. For windows, it returns undefined
unless there is a named subframe named "then", in which case that named
subframe is returned.
The idea is to be able to resolve promises with cross-origin objects.
MozReview-Commit-ID: HPyTvtwFdsG
Deleting lines in part 1 caused two tests to break, because they check
the line numbers for source files. The devtools part of the patch was
automatically generated.
MozReview-Commit-ID: DrDZeyVnpE0
--HG--
extra : rebase_source : 72c1623015f029a5adef20669cc102c568d3b67e
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
This interface is not usable from JS, because we don't expose initialize() in
the WebIDL bindings for Exception. And C++ doesn't use it.
MozReview-Commit-ID: LsIm4YA0YZE
Almost every chrome script uses these abbreviations. We can avoid some
boilerplate by automatically defining them on chrome contexts where we
define Components.
The var declarations for Cc and Ci in MozillaFileLogger.js are run
before enablePrivilege("UniversalXPConnect"). The latter now attempts
to automatically define Cc and Ci, but the non-configurable Cc and Ci
prevent that. Work around this by just removing the var declarations.
MozReview-Commit-ID: 6FV9ahLeqUb
--HG--
extra : rebase_source : 75a3243ea2c267fad19cc6543046dc7b130cc4c1
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This patch adds a new environment variable XPCOM_MEM_LOG_JS_STACK that
changes XPCOM leakchecking to record a JS stack for all objects, in
addition to a C++ stack. This is useful when a C++ object is being
leaked due to JS. The JS stack will be printed if the object leaks, if
it is used in combination with XPCOM_MEM_BLOAT_LOG=1 and
XPCOM_MEM_LOG_CLASSES=nsFoo, if nsFoo is the class of interest.
This patch moves a few XPConnect functions for recording the stack
into xpcpublic.h so they can be called from nsTraceRefcnt.cpp.
MozReview-Commit-ID: FX2QVCSXz4f
--HG--
extra : rebase_source : 5bd4e341072f4cf7d3be774b63d2107479fe9985
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
This helper makes it easy to lazily import a JavaScript module the first time
one of its exports is required. It is intended to replace
XPCOMUtils.defineLazyModuleGetter, which has similar functionality but is much
less efficient.
MozReview-Commit-ID: 2zxXYwrn3Dr
--HG--
extra : rebase_source : 998de7388ee03fdec0a0949b4e43bd9169dbb592
extra : histedit_source : 414d0ed1842b2270146d37b2788a56c682d3d695
Looking up and copying exported properties each time a module is loaded is
fairly expensive at the best of times. It's even more expensive when we only
want to export a subset of symbols, which generally requires creating a
temporary object to hold the exports, or fetching them directly from the
returned global.
Aside from making the general case a bit faster, storing exports on an object
allows us to optimize lazy module imports by fetching imported symbols
directly from the exports object with very little additional overhead.
MozReview-Commit-ID: C9PGoXPNmsh
--HG--
extra : rebase_source : 6232cf7a52fd69ebeb8b6e39680646f287c272a8
extra : histedit_source : b223c73a6e9092491f4fb09f8c795f5aa4b43df3
This patch also adds the capitalization patch file to the chromium patches
MozReview-Commit-ID: BzAkEtCKAi4
--HG--
extra : rebase_source : 8f24d2b855e721f354f12b0d3fca5783cc66702e
Content processes can contain ghost windows, so the debug-only ghost
window unlinker needs to send a message to child processes to get them
to run it, too.
MozReview-Commit-ID: 9Ffc3SDNDJB
--HG--
extra : rebase_source : 875891e9332cf41c4157d246b71c2c361cab4aa6
This is a follow-up to bug 1409249. There are a lot of places where our
factory singleton constructors either don't correctly handle their returned
references being released by the component manager, or do handle it, but in
ways that are not obvious.
This patch handles a few places where we can sometimes wind up with dangling
singleton pointers, adds some explanatory comments and sanity check
assertions, and replaces some uses of manual refcounting with StaticRefPtr and
ClearOnShutdown.
There are still some places where we may wind up with odd behavior if the
first QI for a getService call fails. In those cases, we wind up destroying
the first instance of a service that we create, and re-creating a new one
later.
MozReview-Commit-ID: ANYndvd7aZx
--HG--
extra : rebase_source : acfb0611a028fef6b9387eb5d1d9e285782fbc7c
Whether the shims are no longer needed for Web compat is independent
of whether we can remove the interfaces themselves.
MozReview-Commit-ID: 2KGEfRSejgS
This removes an unnecessary level of indirection by replacing all
nsStringGlue.h instances with just nsString.h.
--HG--
extra : rebase_source : 340989240af4018f3ebfd92826ae11b0cb46d019
Also remove some out of date comments. GetObjectPrincipal() was removed a while ago.
MozReview-Commit-ID: IQFoVyaEMlY
--HG--
extra : rebase_source : 935ecc1094d46ac8cab11e236b6ffb1a95aa9a06
Presshell still does something along these lines, but it works completely differently.
MozReview-Commit-ID: JRenEDNlo6p
--HG--
extra : rebase_source : d90924fcbbf81b1b23311b8589ea86403f0fd630
This method is unused. It is the only caller of
XPCWrappedNative::GetUsedOnly(), so remove that, too.
MozReview-Commit-ID: LRMB2bAwgoS
--HG--
extra : rebase_source : 8203aae8d0263ca467fff8e63f187caca8aaf733
This method is unused. It is the only caller of
XPCWrappedNative::GetObjectPrincipal() so remove that, too.
MozReview-Commit-ID: 8s5toK85YUS
--HG--
extra : rebase_source : 551ec90d893ac9f47ef5166ec1dbd2ac8b5c6988
This is only called in a single place, and does not use any fields of
nsXPConnect, so remove it from the XPIDL interface and inline the
method to the one caller. It also fixes an error message to no longer
refer to a non-existant interface. Otherwise, the behavior should be
unchanged.
MozReview-Commit-ID: LwrosnHj2ip
--HG--
extra : rebase_source : 69c1ef142ee309ece75d1d2cc083417abf6f827b