This is needed to maintain full feature parity with the existing
nsIPrincipal serializer while switching to using the PrincipalInfo-based
one.
Depends on D14434
Differential Revision: https://phabricator.services.mozilla.com/D20854
--HG--
extra : moz-landing-system : lando
This is needed to maintain full feature parity with the existing
nsIPrincipal serializer while switching to using the PrincipalInfo-based
one.
Depends on D20853
Differential Revision: https://phabricator.services.mozilla.com/D20854
--HG--
extra : moz-landing-system : lando
This patch in the series ensures that the order of operations in
recursive invocations of CommonTestPermission() remains consistent
compared to before the patch series, even though it is not strictly
needed for the performance improvements that the series focuses on.
The core idea behind CommonPrepareToTestPermission() now is to do the checks
that do not depend on the host name being tested, and for
CommonTestPermissionInternal() itself to focus on the rest of the checks,
that is looking up our hashtable entry based on the host name being tested,
and everything else that's needed from that point on.
Depends on D20235
Differential Revision: https://phabricator.services.mozilla.com/D20236
--HG--
extra : moz-landing-system : lando
The change to test_clonewrapper.xul is because in the new setup we've already
tried handing an object across origins via chrome code, so it has a cached
(opaque) wrapper. When we set document.domain and pass the same object again,
we end up picking up the cached wrapper when we try to wrap across the
compartment boundary, so don't grant access when perhaps we should...
This does lead to a possible spec violation in the following situation:
1) Two documents (A, B) start out same-site but different-origin.
2) Privileged code (system or extension) puts a reference to an object from
site A into site B. This object gets an opaque CCW.
3) Both sites set document.domain to become same-effective-script-origin and
then site B goes through the site A Window and the object graph hanging off it
and gets to the object involved. It gets an opaque CCW when it should have a
transparent CCW.
We could fix this if we kept recomputing wrappers on document.domain change and
just fixed the compartment filter used by the recomputation. But this seems
like a pretty rare situation, and not one web sites can get into without an
assist from a somewhat buggy extension or system code, so let's see whether we
can just live with it and remove the recomputation.
Differential Revision: https://phabricator.services.mozilla.com/D18032
--HG--
extra : moz-landing-system : lando
Prevent web_accessible_resources resources loading in private contexts when extension does not have permission.
Differential Revision: https://phabricator.services.mozilla.com/D17138
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
nsIPrincipal::GetURI returns NS_OK for all implementations. Make it
infallible so we can clean up status checks in C++ code that uses principals.
Differential Revision: https://phabricator.services.mozilla.com/D16145
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
Because it release-asserts the compartment has a single realm.
I also renamed JS_GetCompartmentPrincipals to JS_DeprecatedGetCompartmentPrincipals
to discourage people from using it.
Differential Revision: https://phabricator.services.mozilla.com/D14252
--HG--
extra : moz-landing-system : lando
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
This is needed because UA Widget cannot load resources from chrome://mozapps.
Depends on D11701
Differential Revision: https://phabricator.services.mozilla.com/D11702
--HG--
rename : toolkit/themes/osx/mozapps/plugins/pluginHelp-16.png => toolkit/themes/osx/global/plugins/pluginHelp-16.png
rename : toolkit/themes/osx/mozapps/plugins/pluginHelp-16.png => toolkit/themes/windows/global/plugins/pluginHelp-16.png
extra : moz-landing-system : lando
This is needed because UA Widget cannot load resources from chrome://mozapps.
Depends on D11701
Differential Revision: https://phabricator.services.mozilla.com/D11702
--HG--
rename : toolkit/themes/osx/mozapps/plugins/pluginHelp-16.png => toolkit/themes/osx/global/plugins/pluginHelp-16.png
rename : toolkit/themes/osx/mozapps/plugins/pluginHelp-16.png => toolkit/themes/windows/global/plugins/pluginHelp-16.png
extra : moz-landing-system : lando
Creates the nsDocShellLoadState object, which is basically
nsDocShellLoadInfo plus a few extra fields to make it usable as a
single argument to nsDocShell::LoadURI (and eventually
nsDocShell::InternalLoad).
Subframe history handling is a huge logic block in
nsDocShell::LoadURI, which is only used on history loads. This patch
also extracts the logic out into its own function to make the body of
LoadURI clearer.
This patch adds a MOZ_DIAGNOSTIC_ASSERT for assuring the OAs
are matching when the targetOrigin is "*" for the postMessage().
But it ignores the FPD in OA since the FPDs are possible to be
different.
We also add a new pref 'privacy.firstparty.isolate.block_post_message'
for allowing blocking postMessage across different FPDs.
Differential Revision: https://phabricator.services.mozilla.com/D8521
--HG--
extra : moz-landing-system : lando
Creates the nsDocShellLoadState object, which is basically
nsDocShellLoadInfo plus a few extra fields to make it usable as a
single argument to nsDocShell::LoadURI (and eventually
nsDocShell::InternalLoad).
Subframe history handling is a huge logic block in
nsDocShell::LoadURI, which is only used on history loads. This patch
also extracts the logic out into its own function to make the body of
LoadURI clearer.
Differential Revision: https://phabricator.services.mozilla.com/D6944
--HG--
rename : docshell/base/nsDocShellLoadInfo.cpp => docshell/base/nsDocShellLoadState.cpp
rename : docshell/base/nsDocShellLoadInfo.h => docshell/base/nsDocShellLoadState.h
extra : moz-landing-system : lando
Depends on D8740.
This changeset replaces calls to ok with 3 arguments to calls with 2 arguments
in situations where the switch does not have a significant impact on the assert.
Differential Revision: https://phabricator.services.mozilla.com/D8741
--HG--
extra : moz-landing-system : lando
Creates the nsDocShellLoadState object, which is basically
nsDocShellLoadInfo plus a few extra fields to make it usable as a
single argument to nsDocShell::LoadURI (and eventually
nsDocShell::InternalLoad).
Subframe history handling is a huge logic block in
nsDocShell::LoadURI, which is only used on history loads. This patch
also extracts the logic out into its own function to make the body of
LoadURI clearer.
Differential Revision: https://phabricator.services.mozilla.com/D6944
--HG--
rename : docshell/base/nsDocShellLoadInfo.cpp => docshell/base/nsDocShellLoadState.cpp
rename : docshell/base/nsDocShellLoadInfo.h => docshell/base/nsDocShellLoadState.h
extra : moz-landing-system : lando
The problem is that we used ThirdPartyUtil.getBaseDomain and for IP addresses that
returns the host, and for IPv6 addresses GetHost strips the '[' and ']' brackets.
Then when we passed that IP address to SetHost, we failed because SetHost wants
the brackets to be present.
This patch changes GetSiteOrigin to call getBaseDomain on the TLD service instead,
so we can handle this case ourselves by not calling SetHost when we have an IP
address. GetBaseDomain still uses ThirdPartyUtil.
I tried to add a test for this (with an iframe + postMessage) but the mochitest
http server doesn't support IPv6.
Differential Revision: https://phabricator.services.mozilla.com/D6523
--HG--
extra : moz-landing-system : lando
We want to get rid of JS_GetCompartmentPrincipals. The origin stored in CompartmentPrivate does not account for document.domain changes because that's a per-realm thing.
Fortunately we should not have waivers in any cases that involve document.domain.
Differential Revision: https://phabricator.services.mozilla.com/D6035
--HG--
extra : moz-landing-system : lando
This will let us answer the following questions (in a performant way):
1) What's the compartment's origin? Necessary to implement compartment-per-origin.
2) What's the origin's site? Necessary for the new Wrap() algorithm.
3) Has any realm in the compartment set document.domain? Necessary for the new Wrap() algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D5423
--HG--
extra : moz-landing-system : lando
This fixes two issues:
1) We no longer SetHasExplicitDomain() when the domain is null.
2) We avoid the unnecessary (because new principal) wrapper recomputation.
Differential Revision: https://phabricator.services.mozilla.com/D5160
--HG--
extra : moz-landing-system : lando
This patch creates the basic structure on how the widget scripts can be loaded
and be pointed to the Shadow Root, from the UAWidgetsChild.jsm.
The UAWidgetsClass class asks for a sandbox from Cu.getUAWidgetScope(), which
calls into XPCJSRuntime::GetUAWidgetScope(). It creates and keeps the
sandboxes, in a GCHashMap keyed to the origin, so we could reuse it if needed.
MozReview-Commit-ID: J6W4PDQWMcN
--HG--
extra : rebase_source : a62b0a22195f09cdb508df72c954e20d18c7bf68
nsIURIWithPrincipal is currently used to retrieve the nsIPrincipal from a
BlobURL object. BlobURLProtocolHandler has a hashtable containing, for each
blobURL, a BlobImpl and its nsIPrincipal. This patch introduces
BlobURLProtocolHandler::GetBlobURLPrincipal() that retrieves the nsIPrincipal
from this hashtable.
This patch fixes also a bug in how the revocation of blobURLs is broadcasted to
other processes. This should be done immediately because each process creates
its own timer to revoke them after 5 seconds.
An important change is related to NS_SecurityCompareURIs() where, if 1 (or
both) of the 2 URIs to compare, is a revoked BlobURL, we will QI its URL to
nsIStandardURL and fail out at that point.
The patch introduces NS_GetURIWithNewRef and NS_GetURIWithNewRef which perform the same function.
Differential Revision: https://phabricator.services.mozilla.com/D2239
--HG--
extra : moz-landing-system : lando
Right now, the firstPartyDomain won't be set when using IP addresses as
first party domains. It is because of that the TLD service won't accept
IP addresses as valid hosts. The patch fixes this problem by detecting
that if the host is a IP address. If it is, we will still set the
firstPartyDoamin with the IP address.
Differential Revision: https://phabricator.services.mozilla.com/D1977
--HG--
extra : moz-landing-system : lando
This patch adds a sanitization of firstPartyDomain when calling the
OriginAttributes::CreateSuffix() and remove the release assert there.
The cookies API for the web extension can use a arbitrary string for the
firstPartyDomain. So, we should sanitize the firstPartyDomain before
we creating a suffix. The release assert is not required anymore since
the firstPartyDomain is sanitized
Depends on D1845.
Differential Revision: https://phabricator.services.mozilla.com/D1856
--HG--
extra : moz-landing-system : lando
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Making about:home unlinkable changes its URL structure. Prior to this change,
it is a nested URL. After this change, it no longer is.
We store serialized versions of principals in some cases. These include
details about whether the URI is nested etc. This is problematic for the
about:home change because the change in nesting changes the origin of the
page, so the origin would mismatch between the principal and its URL.
To avoid this, we always re-create URIs for about: URIs when deserializing
them from strings, ensuring we don't create bogus principals.
MozReview-Commit-ID: 87zVUFgbusn
--HG--
extra : rebase_source : a7ad0dc3b1ea39521517da648f234d35d9a1729f
The security.allow_chrome_frames_inside_content pref was added to support
XUL extension compat after the hiddenWindow special case was removed in
Bug 1145470. Since we don't need to support that use-case anymore, this
changeset backs out the change that relanded the special case with the pref.
MozReview-Commit-ID: 4keMEIQvt1Y
--HG--
extra : rebase_source : 1a9c54c9807eaed2645d0ea03b5064ed7472d7a4
Jan Varga
Alex Gaynor
Gurzau Raul
Nika Layzell
Ryan Hunt
Christoph Kerschbaumer
Ehsan Akhgari
Jonathan Kingston
Boris Zbarsky
Myk Melez
shindli
Shane Caraveo
Kris Maglione
Kyle Machulis
Gijs Kruitbosch
arthur.iakab
Dave Townsend
Ciure Andrei
Emilio Cobos Álvarez
Jan de Mooij
vinoth
Tooru Fujisawa
Benjamin Bouvier
Sylvestre Ledru
Timothy Guan-tin Chien
Dorel Luca
Tim Huang
Collin Wing
Margareta Eliza Balazs
Andrea Marchesini
Julian Descottes
Mark Banner
Narcis Beleuzu
Tiberius Oros
Jorg K
Valentin Gosu
Bogdan Tara
Olli Pettay
imjching
Joel Maher
Tom Schuster
Adrian Wielgosik
Brian Grinstead