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.
Boris Zbarsky
Andrea Marchesini
Valentin Gosu
Kris Maglione
Bogdan Tara
Tim Huang
Olli Pettay
imjching
shindli
Joel Maher
Emilio Cobos Álvarez
Jan de Mooij
Tom Schuster
Gijs Kruitbosch
Adrian Wielgosik
Brian Grinstead
Chris Peterson
Tomislav Jovanovic
Coroiu Cristina
Tom Ritter
Andreea Pavel
Christian Holler
Nathan Froyd
Jason Orendorff
Christoph Kerschbaumer
Sebastian Hengst
Andrew McCreight
Florian Quèze
Cosmin Sabou
Brindusan Cristian
Anthony Ramine
Jonathan Kingston
Mark Banner
Felipe Gomes
Nicholas Nethercote
Dan Banner
Amy Chung
Karl Tomlinson
Xidorn Quan
Chung-Sheng Fu
Gabriele Svelto
Eric Rahm
Shane Caraveo
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
Ehsan Akhgari
Frederik Braun
Jorg K
Bobby Holley