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
Initial version r=smaug.
Rebased to c616a6fd5e4b by Jan-Ivar Bruaroey <jib@mozilla.com> r=karlt.
Rebased to 83de58ddda20 by Karl Tomlinson <karlt+@karlt.net> r=baku.
MozReview-Commit-ID: Lo8TWtN8qyz
--HG--
extra : rebase_source : ffcb7b835ea49cda3e25dfa94a91b3725fdbfb29
We need to side-step existing cross-origin checks in Performance Timing code
when the caller is a web extension content script that otherwise has permission
to access the cross-origin resource.
MozReview-Commit-ID: 8IgtqZgPWgY
--HG--
extra : rebase_source : e8152c5d8ab32096d1ff7f97311c1b43b57c3694