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
This is a large patch which tries to switch many of the external consumers of
nsGlobalWindow to instead use the new Inner or Outer variants.
MozReview-Commit-ID: 99648Lm46T5
As a result of this patch, the hash algorithm used in add-on signature
verification will come from the PKCS#7 signature. If SHA-256 is present, it will
be used. SHA-1 is used as a fallback. Otherwise, the signature is invalid.
This means that, for example, if the PKCS#7 signature only has SHA-1 but there
are SHA-256 hashes in the signature file and/or manifest file, only the SHA-1
hashes in the signature file and manifest file will be used, if they are present
(and verification will fail if they are not present). Similarly, if the PKCS#7
signature has SHA-256, there must be SHA-256 hashes in the signature file and
manifest file (even if SHA-1 is also present in the PKCS#7 signature).
MozReview-Commit-ID: K3OQEpIrnUW
--HG--
extra : rebase_source : 704a2a18e166bfaf3e3d944d13918054bd012000
The use counters JS_ASMJS and JS_WASM will measure usage in a more interesting
fashion.
MozReview-Commit-ID: BhZTWKN1oTQ
--HG--
extra : rebase_source : 5ffc84b34418a2422afd6384f8ebbe67b94c6717
And remove unreachable code after MOZ_CRASH().
MozReview-Commit-ID: 6ShBtPRKYlF
--HG--
extra : rebase_source : 0fe45a59411bda663828336e2686707b550144ae
extra : source : 8473fd7333d2abe1ea1cc176510c292a5b34df45
The crash reports for this section of code suggest that in some cases, we're
ending up with a null Omnijar archive when trying to pre-load files. Since the
pre-load file list is determined in the previous session, and the startup
cache (where the pre-load list is stored) is cleared whenever the build ID
changes, it should never be possible for the given omnijar archive to be
missing here.
These crashes also tend to appear in conjunction with crashes due to failures
in the GetSharedGlobal function, and may have a similar cause.
This change adds better diagnostic information to these crashes, and should at
least tell us which omnijar archive we're failing to get, and the archive path
that caused us to load that archive. It may not tell us much, but it may point
to data corruption, or provide some other clues.
MozReview-Commit-ID: EKq3r4eG5ii
--HG--
extra : rebase_source : 745f99b8d5d7fbbf8511b62082d224899cdff947
Since we don't currently know where or how loading the service is failing, we
need logging in two places:
1) In ServiceWorkerRegistrar, which will tell us about any JS errors that
occur in the factory constructor.
2) In the XPConnect module loader, which will tell us about any JS errors
which happen while loading the top-level module script.
If the load fails due to a non-JS error, we'll simply get a nsresult failure
code, which well be less informative, but will still tell us something about
the failure mode.
MozReview-Commit-ID: 1CsDegJfiho
--HG--
extra : rebase_source : c998e0393d3cb8aca008da47dfce985d0c3affb6
Right now, NS_GENERIC_FACTORY_SINGLETON_CONSTRUCTOR expects singleton
constructors to return already-addrefed raw pointers, and while it accepts
constructors that return already_AddRefed, most existing don't do so.
Meanwhile, the convention elsewhere is that a raw pointer return value is
owned by the callee, and that the caller needs to addref it if it wants to
keep its own reference to it.
The difference in convention makes it easy to leak (I've definitely caused
more than one shutdown leak this way), so it would be better if we required
the singleton getters to return an explicit already_AddRefed, which would
behave the same for all callers.
This also cleans up several singleton constructors that left a dangling
pointer to their singletons when their initialization methods failed, when
they released their references without clearing their global raw pointers.
MozReview-Commit-ID: 9peyG4pRYcr
--HG--
extra : rebase_source : 2f5bd89c17cb554541be38444672a827c1392f3f
mozJSComponentLoader is created using XPCOM. However, you can only
call it once or it'll crash. This patch fixes that by using a
singleton macro.
MozReview-Commit-ID: Bq2k7nv9dKA
--HG--
extra : rebase_source : d2008da7628edf5db283c8a44c17e741f7ae0a96
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive. This patch splits that macro into three new ones that are harder to
mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
--HG--
extra : rebase_source : 3e2bbec4737b696e1c86579ae54be4cb3186c100
This lets us replace moz_xstrdup() of string literals with AssignLiteral(),
among other improvements.
--HG--
extra : rebase_source : 9994d8ccb4f196cf63564b0dac2ae6c4370defb4
This change requires introducing nsID::Clone(). Because it's infallible, the
patch also removes some redundant failure-handling code. (nsMemory::Clone() is
also infallible, so this code was redundant even before this change.)
--HG--
extra : rebase_source : ef22757d3fa814320490bf7e19e822b8f0c4bdc3
The new code is slightly less efficient because it requires measuring the
string length, but these strings are all short so it shouldn't matter.
Note that the case in DataToString() is a little different. The std::min() that
was there appears to be excessive caution -- this code is always printf'ing
some kind of number, so 32 chars should never be reached -- but it was bogus
anyway, because if 32 was exceeded then (a) we would have overflowed `buf`, and
(b) we'd be returning a non-null-terminated string.
--HG--
extra : rebase_source : b666ad72c09d8c32b98bb9abc9dce1bd0c912c9b
They are equivalent -- both infallible, both requiring measuring the length of
the string -- but moz_xstrdup is much more readable. (One place deals with
16-bit strings and so uses NS_strdup instead, which is also infallible.)
The patch also removes some failure-path code that will never execute due to
the infallibility.
--HG--
extra : rebase_source : 115574cf55db90b60e6bee59e5dc6ee409374159
The current API makes the life time and ownership of the result array unclear
without careful reading. The result array is always owned by the principal,
and its lifetime tied to the lifetime of the principal itself. Returning a
const array reference makes this clear, and should prevent callers from
accidentally modifying the returned array.
MozReview-Commit-ID: 3f8mhynkKAj
--HG--
extra : source : 237acf2879f6222bc4b076c377bf026d18a6ebef
extra : amend_source : dfaf6e88e3c4758f7fdcf7fb422d457edafab1b7
The current API makes the life time and ownership of the result array unclear
without careful reading. The result array is always owned by the principal,
and its lifetime tied to the lifetime of the principal itself. Returning a
const array reference makes this clear, and should prevent callers from
accidentally modifying the returned array.
MozReview-Commit-ID: 3f8mhynkKAj
--HG--
extra : rebase_source : d2a5e0862f8c964fb5a3e46b50c2e9629b218699
extra : amend_source : 27d7a7ef5da6fe2aa1104009b6ee067465db73e1
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive.
This patch splits that macro into three new ones that are harder to mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
--HG--
extra : rebase_source : 53c8b43b6a1be06d00618a133e28bf95c46a3ba3
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive.
This patch splits that macro into three new ones that are harder to mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
--HG--
extra : rebase_source : 59f77df0124249bfd11fee3585420a17b4201d37
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
The URLPreloader's initialization code accesses the Omnijar cache off-main
thread. It can do so safely only as long as the main thread is blocked, or
running code which is guaranteed never to touch Omnijar, while its critical
section runs.
While that was guaranteed for previous versions of the code, some invariants
changed when we began using the component loader's shared global for initial
compilation. Once the global is created, we can safely use it to initialize
compilation. But creating the global invokes a large amount of Gecko code,
some of which touches Omnijar in the process.
MozReview-Commit-ID: 48WoIZtGPTo
--HG--
extra : rebase_source : 9bd5d884e32cfa59c022edb00078aac050acb20b
This patch also ensures that we won't accidentally try stopping slow scripts
when we're shutting down the watchdog manager.
MozReview-Commit-ID: EMb0enfivd8
--HG--
extra : rebase_source : b27205c4d593caa1c33534591686e85fba9f0d41
The last argument is always null, so we don't need this function any more.
MozReview-Commit-ID: 5YWMO9ywZK3
--HG--
extra : rebase_source : 56bce2611135bb1b30e7f8ad763e13f112d2395f
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: DbTW5Bhd9E1
--HG--
extra : rebase_source : b27f666e5ca832d814fb6846208474e1ec66e5f4
extra : source : 9ff4e11402a9a43ed90298a9c354b0164cf9414f
XPCOM's string API doesn't have the notion of a "null string". But it does have
the notion of a "void string" (or "voided string"), and that's what these
functions are returning. So the names should reflect that.
--HG--
extra : rebase_source : 4e3f982e0873877174a08a25413595ff66f7d20e
nsIHandleReportCallback, typedef of nsIMemoryReporterCallback, has been the
preferred name for a long time and is used in most places. This patch removes
nsIMemoryReporterCallback.
--HG--
extra : rebase_source : c675076b4f98d93d96235dad890e31e0b0e6c277
We don't have access to an appropriate context to create the dead wrapper in
when the callback is nuked, so instead, this patch creates a new dead wrapper
in the caller compartment each time the property is accessed. This is the same
behavior we'd get when trying to re-wrap a cross-compartment dead wrapper, so
it's consistent with the way we handle these situations elsewhere.
MozReview-Commit-ID: 3cMeR4z8EOe
--HG--
extra : rebase_source : 7e8cf4a195ef64deb7677ce4ac9818d342815667
Also, MOZ_XPCTOOLS does not appear to be a thing any more.
MozReview-Commit-ID: 99BR9rl4EnD
--HG--
extra : rebase_source : 3712b7b2b180b583ca761cdc5d6ddf17728e8b74