If an XPIDL interface has a method or attribute that is [notxpcom],
then it is implicitly treated as [builtinclass], even if it is not
marked as such. For clarity, this patch goes through and marks every
place that relies on this behavior (aside from some test code).
Differential Revision: https://phabricator.services.mozilla.com/D30714
--HG--
extra : moz-landing-system : lando
The attributes for an interface should be on the line right before the
interface.
Interface attributes should be separated by spaces.
Clean up some trailing whitespace in widget/.
Differential Revision: https://phabricator.services.mozilla.com/D28234
--HG--
extra : moz-landing-system : lando
This excludes dom/, otherwise the file size is too large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27456
--HG--
extra : moz-landing-system : lando
Right now the firstPartyDomain is not set when host is in the public suffix list. The patch fixes it by setting firstPartyDomain to eTLD.getPublicSuffix in these cases.
Differential Revision: https://phabricator.services.mozilla.com/D26767
--HG--
extra : moz-landing-system : lando
1. Adding a new attribute chromeContext in ConsoleEvent
2. Adding a new boolean attribute isFromChromeContext in nsIConsoleMessage
3. Sending IsFromChromeContext to the parent process
Differential Revision: https://phabricator.services.mozilla.com/D23330
--HG--
extra : moz-landing-system : lando
1. Adding a new attribute chromeContext in ConsoleEvent
2. Adding a new boolean attribute isFromChromeContext in nsIConsoleMessage
3. Sending IsFromChromeContext to the parent process
Differential Revision: https://phabricator.services.mozilla.com/D23330
--HG--
extra : moz-landing-system : lando
Replaced instances of callers in both C++ and JS files to query the state from the principal directly.
Differential Revision: https://phabricator.services.mozilla.com/D22532
--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 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
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
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
* Deserialization now only happens via a mutator
* The CID for URI implementations actually returns the nsIURIMutator for each class
* The QueryInterface of mutators implementing nsISerializable will now act as a finalizer if passed the IID of an interface implemented by the URI it holds
MozReview-Commit-ID: H5MUJOEkpia
--HG--
extra : rebase_source : 01c8d16f7d31977eda6ca061e7889cedbf6940c2
* Deserialization now only happens via a mutator
* The CID for URI implementations actually returns the nsIURIMutator for each class
* The QueryInterface of mutators implementing nsISerializable will now act as a finalizer if passed the IID of an interface implemented by the URI it holds
MozReview-Commit-ID: H5MUJOEkpia
--HG--
extra : rebase_source : 8ebb459445cab23288a6c4c86e4e00c6ee611e34
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
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 was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
This trades off more virtual calls in URLParams::ParseInput, while removing any extra
allocation when calling URLParams::Parse.
MozReview-Commit-ID: HrIqsguQjrk
--HG--
extra : rebase_source : fd6d4f0455f5c3df72bd3518b98359ac8759a89d
The logic for choosing the principal here was originally written before
loadInfo had a separate principalToInherit field, and we needed to specify it
via the triggeringPrincipal instead. At that point, we had to choose a
component principal with permission to load the URI at the start of the
request.
However, now that we have a separate field for the principal to inherit, it's
only needed after access checks have passed and we know that we have a URI
which inherits a principal. In that case, the current logic causes us to
always inherit the first principal in the whitelist (which is the page
principal) for URIs (such as data: URIs) that always inherit, where we really
want to inherit the last (which is the extension principal).
MozReview-Commit-ID: EPoUNuOCwrH
--HG--
extra : rebase_source : 535083e3dd4598ac4e8ea187d27d61ac2ac48476
We currently use plain extension codebase principals for most of the extension
stylesheets that we inject into content pages. Since we want the content
loaded by those stylesheets to be exempt from CSP, and can't safely use
expanded principals for their loads, we need to make plain extension codebase
principals exempt from CSP.
MozReview-Commit-ID: IIAUWU68nor
--HG--
extra : rebase_source : f7447e1d87c8d75b97de580a641fcac6333a9f27
This also changes URIUtils.cpp:DeserializeURI() to use the mutator to instantiate new URIs, instead of using their default constructor.
MozReview-Commit-ID: JQOvIquuQAP
--HG--
extra : rebase_source : e146624c5ae423f7f69a738aaaafaa55dd0940d9
This patch uses MozURL in ServiceWorkerRegistrar and in DBScheme to obtain the
origin of a URL. This is safe because the URL is always http/https/ftp.
It also changes the serialization of Principal in nsJSPrincipals in order to
pass the originNoSuffix together with the OriginAttributes and the spec.
This also updates its :hover and :active visuals to match the tab bar
MozReview-Commit-ID: 98LiqClr3SG
--HG--
extra : rebase_source : 4f20c5803702a2da731a1eb6880e2b68e1867f9e
This also updates its :hover and :active visuals to match the tab bar
MozReview-Commit-ID: SijUvVrAAF
--HG--
extra : rebase_source : 7a3b711a32edd76e3ed02e5ccb9aa1fbb48e3345
This also updates its :hover and :active visuals to match the tab bar
MozReview-Commit-ID: SijUvVrAAF
--HG--
extra : rebase_source : 7a3b711a32edd76e3ed02e5ccb9aa1fbb48e3345
There are several ways that expanded principals can be used as triggering
principals for requests. While that works fine for security checks, it also
sometimes causes them to be inherited, and used as result principals in
contexts where expanded principals aren't allowed.
This patch changes our inheritance behavior so that expanded principals are
downgraded to the most appropriate constituent principal when they would
otherwise be inherited.
The logic for choosing the most appropriate principal is a bit suspect, and
may eventually need to be changed to always select the last whitelist
principal, but I chose it to preserve the current principal downgrade behavior
used by XMLHttpRequest for the time being.
MozReview-Commit-ID: 9fvAKr2e2fa
--HG--
extra : rebase_source : c30df1b3851c11fed5a1d6a7fb158cec14933182
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
This class does some caching of an nsIClassInfo's flags and name. Presumably it
made sense at some time in the past, but now it's only used by
CanCreateWrapper(). It's simpler to just directly get the flags and name when
needed, so this patch does that and removes the class.
--HG--
extra : rebase_source : 0f11844ca6be4ff007b50d95bb8f5a88037fb1b5
This lets us replace moz_xstrdup() of string literals with AssignLiteral(),
among other improvements.
--HG--
extra : rebase_source : 9994d8ccb4f196cf63564b0dac2ae6c4370defb4
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
Per the CSP specification, content injected by extensions is meant to be
exempt from page CSP. This patch takes care of the most common case of content
injected by extension content scripts, which always have expanded principals
which inherit from the page principal.
In a follow-up, we'll probably need to extend the exemption to stylesheet
content loaded by extension codebase principals.
MozReview-Commit-ID: GlY887QAb5V
--HG--
extra : rebase_source : 1371b4e4e7f330b7f7721d4aa169fcb52a7622d0
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
--HG--
extra : rebase_source : 254404e318e94b4c93ec8d4081ff0f0fda8aa7d1
This also introduces JS::GetObjectRealmOrNull, which returns an object's realm,
or null if the object is a cross-compartment wrapper. In the new order,
wrappers can't have realms, since they must be shared across all realms in a
compartment. We're introducing this new function early (even though it's
*currently* possible to assign a realm to wrappers) in order to see in
advance if the possibility of returning null will cause problems.
(It looks like it won't.)
--HG--
extra : rebase_source : e55ebbbc4edf2a18ce267198928246592060e339
extra : source : d6bfce1187aa13dbfab03f9566ff7b05b6705e70
In the new order, it will be a compartment-level bit rather than a
realm-level bit, so it does not belong on the Scope.
--HG--
extra : rebase_source : 44aa4620f7fd7f8d253c8c7f09bf8c97c00ff061
extra : source : 5a9c01720d7929e43aa70341d3821bfaa2479592
With JSM global sharing, the object returned by Cu.import() is a
NonSyntacticVariablesObject, rather than a global. Various code tries
to use properties from a JSM global via an import.
Cu.importGlobalProperties can also be used in some places.
MozReview-Commit-ID: HudCXO2GKN0
--HG--
extra : rebase_source : 6b5fa6f5509397504cb461a761f6cc2399f18c40
The extension policy services uses atoms internally for permission names, so
using them directly rather than strings is considerably cheaper.
MozReview-Commit-ID: Io8EuOXHKVy
--HG--
extra : rebase_source : 577b4bdf7f899729e4cf92961a8e9e25bf886a72
Going through the extension policy service rather than using
WebExtensionPolicy objects directly adds a lot of unnecessary overhead to
common operations on extension principals, and also makes the code more
complicated than it needs to be.
We also use weak references to policy objects here, since principals should
ideally lose as much of their elevated privileges as possible once the
extension instance that created them has been destroyed (which is something we
couldn't handle easily when we simply tracked ID strings).
MozReview-Commit-ID: KDNvVdvLkIt
--HG--
extra : rebase_source : 1b567919d2461bd0315d1a7d89f330cbd585f579
GTK should be used only from the main thread, but the specific symptom before
this change was that creating a GtkEntry causes
pango_cairo_font_map_get_default() to be called. This function returns a
different font map on each thread. The font map is leaked when StyleThreads
are leaked at exit.
Font caches are usually expensive and so using the existing font map on the
main thread is preferable.
A GtkEntry already exists on the main thread, as well as style contexts for
most other system fonts, and so it is more efficient to create these on the
main thread while the style contexts exist.
Doing this also avoids the need for Gecko_nsFont_InitSystem() to hold a global
lock to avoid concurrently calling into GTK through LookAndFeel::GetColor().
MozReview-Commit-ID: DSOwEUeYmtV
--HG--
extra : rebase_source : 971bc565e465b2d2482308006f68451ecaa6e264
This is straightforward, with only two notable things.
- `#include "nsXPIDLString.h" is replaced with `#include "nsString.h"`
throughout, because all nsXPIDLString.h did was include nsString.h. The
exception is for files which already include nsString.h, in which case the
patch just removes the nsXPIDLString.h inclusion.
- The patch removes the |xpidl_string| gtest, but improves the |voided| test to
cover some of its ground, e.g. testing Adopt(nullptr).
--HG--
extra : rebase_source : 452cc4a08046a1adb1a8099a7e85a1917de5add8
We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
--HG--
extra : rebase_source : b2c7554e8632f078167ff2f609392e63a136c299
- Use displayPrePath in the pageInfo permissions that shows "Permissions for:"
- The extra displayPrePath method is necessary because it's difficult to compute it manually, as opposed to not having a displaySpecWithoutRef - as it's easy to get that by truncating displaySpec at the first '#' symbol.
MozReview-Commit-ID: 9RM5kQ2OqfC
In all of these cases the fixed buffer has the same lifetime as the string
object, so we can use nsAuto[C]String for simplicity.
For the 128-length ones in dom/xul/ I just switched to the default of 64 for
simplicity, because the choice of 128 didn't seem that important. (These code
paths weren't hit when I started the browser and opened a few sites.)
Finally, the patch also changes LoggingIdString to use
nsAutoCStringN<NSID_LENGTH>, similar to NullPrincipalURI.
This removes about 2/3 of the occurrences of nsXPIDLString in the tree. The
places where nsXPIDLStrings are null-checked are replaced with |rv| checks.
The patch also removes a couple of unused declarations from
nsIStringBundle.idl.
Note that nsStringBundle::GetStringFromNameHelper() was merged into
GetStringFromName(), because they both would have had the same signature.
--HG--
extra : rebase_source : ac40bc31c2a4997f2db0bd5069cc008757a2df6d
This mechanically replaces nsILocalFile with nsIFile in
*.js, *.jsm, *.sjs, *.html, *.xul, *.xml, and *.py.
MozReview-Commit-ID: 4ecl3RZhOwC
--HG--
extra : rebase_source : 412880ea27766118c38498d021331a3df6bccc70
nsIURI.originCharset had two use cases:
1) Dealing with the spec-incompliant feature of escapes in the hash
(reference) part of the URL.
2) For UI display of non-UTF-8 URLs.
For hash part handling, we use the document charset instead. For pretty
display of query strings on legacy-encoded pages, we no longer care to them
(see bug 817374 comment 18).
Also, the URL Standard has no concept of "origin charset". This patch
removes nsIURI.originCharset for reducing complexity and spec compliance.
MozReview-Commit-ID: 3tHd0VCWSqF
--HG--
extra : rebase_source : b2caa01f75e5dd26078a7679fd7caa319a65af14
Most of the names passed to nsIStringBundle::{Get,Format}StringFromUTF8Name
have one of the two following forms:
- a 16-bit C string literal, which is then converted to an 8-bit string in
order for the lookup to occur;
- an 8-bit C string literal converted to a 16-bit string, which is then
converted back to an 8-bit string in order for the lookup to occur.
This patch introduces and uses alternative methods that can take an 8-bit C
string literal, which requires changing some signatures in other methods and
functions. It replaces all C++ uses of the old methods.
The patch also changes the existing {Get,Format}StringFromName() methods so
they take an AUTF8String argument for the name instead of a wstring, because
that's nicer for JS code.
Even though there is a method for C++ code and a different one for JS code,
|binaryname| is used so that the existing method names can be used for the
common case in both languages.
The change reduces the number of NS_ConvertUTF8toUTF16 and
NS_ConvertUTF16toUTF8 conversions while running Speedometer v2 from ~270,000 to
~160,000. (Most of these conversions involved the string
"deprecatedReferrerDirective" in nsCSPParser.cpp.)
--HG--
extra : rebase_source : 3bee57a501035f76a81230d95186f8c3f460ff8e
* nsStandardURL::GetHost/GetHostPort/GetSpec contain an punycode encoded hostname.
* Added nsIURI::GetDisplayHost/GetDisplayHostPort/GetDisplaySpec which have unicode hostnames, depending on the hostname, character blacklist and the network.IDN_show_punycode pref
* remove mHostEncoding since it's not needed anymore (the hostname is always ASCII encoded)
* Add mCheckedIfHostA to know when GetDisplayHost can return the regular host, or when we need to use the cached mDisplayHost
MozReview-Commit-ID: 4qV9Ynhr2Jl
* * *
Bug 945240 - Make sure nsIURI.specIgnoringRef/.getSensitiveInfoHiddenSpec/.prePath contain unicode hosts when network.standard-url.punycode-host is set to false r=mcmanus
MozReview-Commit-ID: F6bZuHOWEsj
--HG--
extra : rebase_source : d8ae8bf774eb22b549370ca96565bafc930faf51
Adds nsISubstitutionObserver so that substitutions set on a
parent nsISubstitutingProtocolHandler which are then propagated
to child processes can be observed in the child.
Updates test_extensionURL.html to set substitutions on the parent
ExtensionProtocolHandler before trying to load moz-extension URI's
using those substitutions.
MozReview-Commit-ID: JaW1A3uZpoO
--HG--
extra : rebase_source : b908a3ef51c2b077809614fd39595c3255dff7ad
This replaces the JS policy service stubs with a pure C++ version which
directly makes policy decisions based on active WebExtensionPolicy objects.
This is the first step in a larger refactoring, which will remove the
ExtensionManagement module entirely, and replace the current add-on policy
service with direct, non-virtual access to native WebExtensionPolicy objects.
It will also be followed by related changes to migrate the content script and
extension page matching to native code, based on the existing MatchPattern and
WebExtensionPolicy bindings.
MozReview-Commit-ID: 2MpbmXZGiPZ
--HG--
extra : rebase_source : 8b268618164b45605143e858665e592de829a6fa
Stop excluding caps/ from eslint runs and apply mozilla/recommended rules.
This generally affects xpcshell and mochitest files under caps/tests.
Includes many mechanical changes to comply with mozilla recommended
formatting rules.
A web page could generate an URL by URl.createObjectURL(new Blob(...));
then navigate to this generated URL.
In this case the (top-level) document URI will be blob:{origin}:{uuid}.
And we try to add firstPartyDomain on this top-level document with blob URI, so
the following request from this document could have correct origin
attributes.
Our caller is C++ code, and the implementations are all also written in C++,
so there is no reason to go through SpiderMonkey here. This patch also makes
nsILoadContext builtinclass to ensure that the implementation is always native.
In the past we used a fixed value for the firstPartyDomain of
NullPrincipal, now we derive it from the path of NullPrincipal, so it
will be unique everytime we create it.
All the consumers relying on this have disappeared, so we can (finally!) get
rid of this ugly bit of special-casing.
MozReview-Commit-ID: HSeeG21O0p4
--HG--
extra : rebase_source : faebaf646308fe29b1c23e4117db2c1ea52ad658
Our caller is C++ code, and the implementations are all also written in C++,
so there is no reason to go through SpiderMonkey here. This patch also makes
nsILoadContext builtinclass to ensure that the implementation is always native.
Our caller is C++ code, and the implementations are all also written in C++,
so there is no reason to go through SpiderMonkey here. This patch also makes
nsILoadContext builtinclass to ensure that the implementation is always native.
When we load about:blank in a remote tab, it will have
LOAD_FLAGS_DISALLOW_INHERIT_PRINCIPAL flag set, which will make
NullPrinicipal as its document principal. So we add
NULL_PRINCIPAL_FIRST_PARTY_DOMAIN as its firstPartyDomain.
So when we load data:, or javascript: URI in a remote tab, it will inherit the
principal from about:blank, hence also inherit the origin attributes.
There are also some about: pages will use codebase principal, so we also
set ABOUT_URI_FIRST_PARTY_DOMAIN as firstPartyDomain on their
principals.
Two about:blank codebase URI principals are only equal if their
object identities are the same, but not if their string
serializations happen to be equal (as they always will be.) In order
to ensure that we always get this right in places where we compare
the origin properties of two principals to check for their equality,
we should ensure that the origin getter would throw so that we never
incorrectly conclude that two such principals are equal.
We will soon start returning a null principal instead of a codebase
principal under this situation.
Sylvestre Ledru
arthur.iakab
Andrea Marchesini
Christoph Kerschbaumer
Andrew McCreight
Bogdan Tara
Cosmin Sabou
Sebastian Hengst
Jonas Allmann
Eugen Sawin
Brian Hackett
Brian Grinstead
Alex Catarineu
Jeremy Lempereur
Csoregi Natalia
Narcis Beleuzu
Eden Chuang
Mark Banner
sakshaat
Dorel Luca
Jan Varga
Alex Gaynor
Gurzau Raul
Nika Layzell
Ryan Hunt
Ehsan Akhgari
Jonathan Kingston
Boris Zbarsky
Myk Melez
shindli
Shane Caraveo
Kris Maglione
Kyle Machulis
Gijs Kruitbosch
Dave Townsend
Ciure Andrei
Emilio Cobos Álvarez
Jan de Mooij
vinoth
Tooru Fujisawa
Benjamin Bouvier
Timothy Guan-tin Chien
Tim Huang
Collin Wing
Margareta Eliza Balazs
Julian Descottes
Tiberius Oros
Jorg K
Valentin Gosu
Olli Pettay
imjching
Joel Maher
Tom Schuster
Adrian Wielgosik
Chris Peterson
Tomislav Jovanovic
Coroiu Cristina
Tom Ritter
Andreea Pavel
Christian Holler
Nathan Froyd
Jason Orendorff
Florian Quèze
Brindusan Cristian
Anthony Ramine
Felipe Gomes
Nicholas Nethercote
Dan Banner
Amy Chung
Karl Tomlinson
Xidorn Quan
Chung-Sheng Fu
Gabriele Svelto
Eric Rahm
Ryan VanderMeulen
Masatoshi Kimura
Thomas Wisniewski
Phil Ringnalda
Rajesh Kathiriya
Bob Owen
Haik Aftandilian
Honza Bambas
Peter Van der Beken
Carsten "Tomcat" Book
Hemant Singh Patwal
Geoff Brown
Yoshi Huang
Frederik Braun
Bobby Holley
Wes Kocher
David Major