Now that XPT files are not loaded from files at runtime, code for
packaging XPT files can be removed.
This means that a couple of test XPIDL interfaces will get shipped in
builds to users that weren't before, but I don't think that matters
much.
This also puts XPT files into the local objdir for the XPIDL makefile,
instead of dist/bin, because they are no longer part of the
distribution.
MozReview-Commit-ID: 7gWj8KWUun3
--HG--
extra : rebase_source : 65bac47c2cd1a20b3c675a01b44a25a1d2d3ab7a
Now that XPT files are not loaded from files at runtime, code for
packaging XPT files can be removed.
This means that a couple of test XPIDL interfaces will get shipped in
builds to users that weren't before, but I don't think that matters
much.
This also puts XPT files into the local objdir for the XPIDL makefile,
instead of dist/bin, because they are no longer part of the
distribution.
MozReview-Commit-ID: 7gWj8KWUun3
--HG--
extra : rebase_source : 6f7d4fd1d6cdea2c14866705a2dc972eb5f43382
NullPrincipal::Create() (will null OA) may cause an OriginAttributes bypass.
We change Create() so OriginAttributes is no longer optional, and rename
Create() with no arguments to make it more explicit about what the caller is doing.
MozReview-Commit-ID: 7DQGlgh1tgJ
Since VS2015, vsnprintf is supposed to be C99-compliant on Windows, too and will
especially always null-terminate the string written into the given buffer.
In addition, the build define we were using was misspelled and therefore not
working anyway, so might we as well remove it now.
MozReview-Commit-ID: 44ERI6TUz1B
--HG--
extra : rebase_source : cdbcf6e20033fd94fb96319c7dc35f4aabce5b3f
Currently, we only shut down the BGReadURLs code when we reach the end of the
task. If we return early because a cache file doesn't exist, though, the
thread never gets shut down. In general, this should only affect sessions
immediately after a cache flush, but it's still not ideal.
MozReview-Commit-ID: 1R9Q9JiBpmY
--HG--
extra : rebase_source : d774b73b06f049e8e6294aa11b1c0390257d1fbe
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 {, <