The renaming here is like this:
SetStringBuffer -> SetKnownLiveStringBuffer
SetEphemeralStringBuffer -> SetStringBuffer
SetOwnedString -> SetKnownLiveString
SetOwnedAtom -> SetKnownLiveAtom
This should make it clearer what the lifetime expectations are on the caller side.
MozReview-Commit-ID: ERHbB3r6paN
This removes an unnecessary level of indirection by replacing all
nsStringGlue.h instances with just nsString.h.
--HG--
extra : rebase_source : 340989240af4018f3ebfd92826ae11b0cb46d019
This causes the subject principal that was responsible for setting a CSS
property, or the full cssText of an attribute, to be threaded through the call
chain to the point where CSS parsing happens, so that it can be used as the
triggering principal when loading URLs for that property.
Note that this allows for different properties defined in the same style
attribute to have different triggering principals, depending on the caller
which originally set them, as long as the cssText of that attribute is not
modified. Once it is, all properties revert to the principal of the caller
that modified the CSS text.
MozReview-Commit-ID: ISUyxbqAZMX
--HG--
extra : rebase_source : d4173d76d9afed74889269e3bf029abca54a4abb
This restriction was put in place back when we automatically added
QueryInterface to all rootmost non-abstract interfaces. At the time, we needed
to make sure it did NOT end up on EventTarget, because then webidl quickstubs
would replace the QI impl on non-webidl EventTargets with the WebIDL one, which
would not work for them.
Since then, we have removed WebIDL quickstubs and we now explicitly list which
interfaces get QueryInterface, so this check is no longer needed.
MozReview-Commit-ID: 5B13ymdyLp3
These were originally exposed directly as static methods on nsGlobalWindow, but
as they are clearly associated with either the inner or outer window, it makes
more sense for them to be called as such.
MozReview-Commit-ID: LFq8EfnhDlo
This is a large patch which tries to switch many of the external consumers of
nsGlobalWindow to instead use the new Inner or Outer variants.
MozReview-Commit-ID: 99648Lm46T5
When defining WebIDL constants in C++, we may need to undefine some
constant names that conflict with windows.h preprocessor defines.
Doing this in the binding header is far easier than tracking down the
include orders that may cause conflicts.
MozReview-Commit-ID: A0UoYezIQs5
--HG--
extra : rebase_source : d9100af2ccdb5c6e6468542ac68f74b2e4f9050c
Generate C++ const definitions for WebIDL interface members with
primitive types.
MozReview-Commit-ID: 4fLtteWZUWA
--HG--
extra : rebase_source : bf45427c6b0e4acfa32ed3431a3cf385972950a0
This was automatically generated by the script modeline.py.
MozReview-Commit-ID: BgulzkGteAL
--HG--
extra : rebase_source : a4b9d16a4c06c4e85d7d85f485221b1e4ebdfede
Currently nsAtom::mString points to the interior of an nsStringBuffer. For
static atoms this requires the use of nsFakeStringBuffer, which is pretty
gross.
This patch changes things so that nsAtom::mString points to a static char
buffer for static atoms. This simplifies a number of things:
- nsFakeStringBuffer and CheckStaticAtomSizes are no longer needed.
- FakeBufferRefCountHelper is no longer needed.
- nsAtom's constructor for static atoms is simpler.
- RegisterStaticAtoms() is simpler.
On the flip-side, a couple of things get more complicated.
- nsAtom::ToString() treats static and dynamic atoms differently.
- nsAtom::GetStringBuffer() is now only valid for dynamic atoms. This
function is only used in two places, both involving DOMString, so those
locations are updated appropriately. This also requires updating some other
code assigning nsStrings to DOMStrings, because we can't assume that
nsStrings are shared.
On Linux64 this change reduces the size of the binary by 8752 B, and moves
81968 B from the .data to the .rodata section, where it can be shared between
processes.
--HG--
extra : rebase_source : 0f6fcdec1c525aa66222e208b66a9f9026f69bcb
(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
We don't have access to an appropriate context to create the dead wrapper in
when the callback is nuked, so instead, this patch creates a new dead wrapper
in the caller compartment each time the property is accessed. This is the same
behavior we'd get when trying to re-wrap a cross-compartment dead wrapper, so
it's consistent with the way we handle these situations elsewhere.
MozReview-Commit-ID: 3cMeR4z8EOe
--HG--
extra : rebase_source : 7e8cf4a195ef64deb7677ce4ac9818d342815667
Now that Gecko controls error reporting and the JS engine is no longer doing
JS_IsRunning checks, we should consistently have exceptions here.
MozReview-Commit-ID: IqBe5ArJc2l
It a stateless wrapper around static methods in nsHTMLTags and nsHTMLElement,
and hence an unnecessary layer of indirection that just adds complexity and
slowness. This patch removes it, cutting almost 300 lines of code.
This requires making nsElementTable.h an exported header, to expose the
nsHTMLElement methods.
--HG--
extra : rebase_source : abbcb8e5001389affbf717092213b898673db07f
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
Remove following outdated comment from Codegen.py
# We don't enforce this for chrome in realease builds to avoid the addon
# compat fallout of making that change. See bug 916644.
Ehsan, can you please review the DOM bindings, and Shane the request logic?
The bulk of the overhead WebRequest API is in its access to nsIChannel and
friends through XPConnect. Since it's not really feasible to convert channels
to use WebIDL bindings directly, this generic channel wrapper class serves the
same purpose.
MozReview-Commit-ID: 4mNP8HiKWK
--HG--
extra : rebase_source : 111687dd0925619b5d93447aecffacd5d53532ef
This patch implements currency validation algorithm according to the spec
https://w3c.github.io/payment-request/#validity-checkers.
1. amount.currencySystem must be "urn:iso:std:iso:4217".
2. amount.currency is valid with following criteria
1. The currency length must be 3.
2. The currency contains any character that must be in the range "A" to
"Z"(U+0041 to U+005A) or the range "a" to "z"(U+0061 to U+007A).
According to the spec, converting the currency to upper case and save it in
nsIPaymentRequest.
Additionally, change the base class of AutoSuppressGCAnalysis from AutoAssertNoAlloc to AutoAssertNoGC.
In combination, these chances enable passing either JS::AutoCheckCannotGC or JS::AutoSuppressGCAnalysis, depending on whether suppressing the GC analysis is desired or not.
MozReview-Commit-ID: Eg1cl28ezeJ
* * *
Bug 1384513 - Follow-up to fix bustage from template usage of functions with a changed signature, on a CLOSED TREE. r=bustage
MozReview-Commit-ID: 5SsI4DoDwAT
Replace it with NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION, because it
has been the same for a while.
MozReview-Commit-ID: 5agRGFyUry1
--HG--
extra : rebase_source : 5388c56b2f6905c6ef969150f0c5b77bf247624d
XPConnect wrapper overhead for this interface has been showing up heavily in a
lot of my profiles, in some places accounting for 50ms of the 80ms we spend
getting getting <browser> messageManagers. This improves the situation
considerably.
MozReview-Commit-ID: 9d1hCORxsYG
--HG--
rename : dom/base/nsIFrameLoader.idl => dom/webidl/FrameLoader.webidl
extra : rebase_source : d8a1fc1a19632ba36a9fc6f63873f7534671a13b
This patch does 2 things:
. when SetBodyUsed() is called, the pump for the stream reading is activated.
. Just because of the reading of the stream could end up executing JS code, we
need to pass the JSContext in the correct state down to SetBodyUsed.
Removes applet tag interfaces, and changes HTML5 parser to output
HTMLUnknownElement when tag is found. Removes tag process from various
places in the browser.
MozReview-Commit-ID: 2zHhK2U2esX
--HG--
extra : rebase_source : d06ecaffd1cb656301e29b900bafde4c68a4606e
Extract CSSFontFeatureValuesRule from nsCSSFontFeatureValuesRule
class. This is necessary because we will create a FontFeatureValues
rule for Servo side.
MozReview-Commit-ID: GKy5wa6JLv9
--HG--
extra : rebase_source : 015f13da9a776c4ece8aa13655395afbb347b870
We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
codegen.pp isn't available immediately (there's a rule to generate it),
and so make warns when it's initially not found. But since this is a
depends file, like other dependency files generated by the build
process, we should silently include it so make doesn't even warn about
it.
The main reason to not do this would be performance (avoiding the
addref/release), but there are two main mitigating factors:
1) All calls to UnwrapReflectorToISupports that pass in a Web IDL object
already do the addref (and in fact QI). So this only affects the
XPCWrappedNative case.
2) The vast majority of the callers proceed to QI on the pointer anyway, and a
second addref is cheap; it's the first addref after a CC that can be
expensive on a cycle-collected object.
Going through the changes one by one:
* In GlobalObject::GetAsSupports, we do have a change that slightly slows down
precisely in the XPCWrappedNative global case. That's the message managers
and the backstagepass. And this really only affects calls to Web IDL statics
from those globals.
* In UnwrapArgImpl we're talking about a Web IDL method taking an "external
interface" type, and the UnwrapReflectorToISupports call is immediately
followed by QI anyway.
* In UnwrapXPConnectImpl we're talking about the case when we have a
non-WebIDL-object implementation of a Web IDL interface. Again, this is the
message manager globals, for EventTarget. And we have a QI call immediately
after the UnwrapReflectorToISupports.
* In the generated HasInstance hook for EventTarget we will be slightly slower
when the LHS of the instanceof is an XPCWrappedNative. And not much slower,
because again there's an immediate QI.
* In InstallXBLField we're never going to have an XPCWrappedNative as thisObj;
it's always an Element in practice. So this is no more expensive than before.
* In sandbox's GetPrincipalOrSOP we now have an extra addref. But it was
followed by various QIs anyway.
* In XPCConvert::JSValToXPCException we have an extra addref if someone throws
an XPCWrappedNative, which is fairly unlikely; our actual Exception objects
are on Web IDL bindings. Plus we have an immediate QI.
* In xpc::HasInstance we have an extra addred if the LHS of instanceof is an
XPCWrappedNative. But, again, there's an immediated QI after the
UnwrapReflectorToISupports.
* In xpcJSWeakReference::Init we are likely doing an extra addref, but again
immediately followed by QI.
I think it's worth making this change just to remove the footgun and that the
perf impact, if any, is pretty minimal.
Most of these changes are just replacements of GetNativeOfWrapper with
UnwrapReflectorToISupports, which is all it did under the hood.
The other changes are as follows:
* In nsDOMClassInfo, we really care whether we have a window, so we can just
UNWRAP_OBJECT to the Window interface, since Window is always on Web IDL
bindings now. Also, the weird compartment check hasn't been needed ever since
GetNativeOfWrapper stopped returning things off the passed-in object's
prototype chain (Firefox 22, bug 658909).
* The only use of do_QueryWrapper was to get a Window in nsDocument; again we
can UNWRAP_OBJECT.
* In XPCJSRuntime, we again just want to check for a Window, so UNWRAP_OBJECT.
The idea is that CastableObjectUnwrapper will want to have a MutableHandle for
the thing it's unwrapping whenever its target is a raw pointer. Since we have
convenient MutableHandle<Value> in most cases, it's easier to switch
CastableObjectUnwrapper to working with MutableHandle<Value> or Handle<Value>
instead of trying to get MutableHandle<JSObject*> in the right places.
There are basically two changes here:
1) Make CastableObjectUnwrapper work with at thing that looks like a Value.
2) Change various callsites to pass in MutableHandle<Value>, in addition to a
Handle<Value>, into the JS-to-C++ conversion templates. The
MutableHandle<Value> is passed as ${maybeMutableVal}. It may not actually
end up being a MutableHandle in some cases.
The reason for passing both a Handle and a MutableHandle is that when the thing
we actually have is a Rooted named "foo" the Handle will be "foo" but the
MutableHandle is most naturally written as "&foo". This is not a problem if
you're just passing it through, but if you want to test whether it's an object,
say, you have a problem. Writing "foo.isObject()" is ok, but "&foo.isObject()"
is not, and neither is "(&foo).isObject()". This could be worked around by
passing the MutableHandle as "JS::MutableHandle<JS::Value>(&foo)" or something,
and then "JS::MutableHandle<JS::Value>(&foo).isObject()" does work. But it
makes the code very hard to read.
So we just pass both things along; ${val} should be used for readonly access and
${maybeMutableVal} any time you really want a MutableHandle.
Current codegen list the methods for clearing cached attribute values in both
chrome only unforgeable methods and chrome only normal methods, but they should
exist only in the normal ones.
MozReview-Commit-ID: Il2JvCLZ2v3
--HG--
extra : rebase_source : 21b9c715c921c4ac7f6ed4c235ee79a3628162bd
Currently we resolve a property by iterating every prefable and check whether it
is enabled. If it is, we linear search the ids that it manages. This patch
changes that to binary searching to find whether the id being resolved is
present first, and checking whether its prefable is enabled only when we find
it. This improves the performance of property resolution, especially when the
property is not present.
The patch stores all the property ids a NativePropertiesN owns in a single array
of PropertyInfo structs. Each struct contains an id and the information needed
to find the corresponding Prefable for the enabled check, as well as the
information needed to find the correct property descriptor in the Prefable. We
also store an array of indices into the PropertyInfo array, sorted by bits of
the corresponding jsid. Given a jsid, this allows us to binary search for the
index of the corresponding PropertyInfo, if any. The index array requires 2
bytes for each property, which is ~20k across all our bindings. The extra
information stored in each PropertyInfo requires 4 bytes for each property,
which is about 40k across all our bindings in 32-bit builds, or 80k in 64-bit
builds due to alignment requirements on PropertyInfo. However we save a bit of
memory from changing NativePropertiesN's trios to duos.
The array of unsorted ids is kept because XrayOwnPropertyKeys() includes only
properties that are enabled. Without it, we will need to check every single
property to know whether its prefable is enabled or not, which is inefficient.
With this patch, initializing property ids takes longer because of the sorting.
I measured also insertion sort because I thought the ids should be nearly sorted
as they are generated sequentially at run time, but that's not the case and
NS_QuickSort() runs faster.
MozReview-Commit-ID: Lc4Z1ui3t0o
--HG--
extra : rebase_source : 314efe467a14428c57f90af2ecc0ec5c47a31993
There are several places in the WebExtensions framework where we currently
need to repeatedly serialize and deserialize structured clone data as it
passes through message managers, which can lead to significant performance
issues.
This helper class lets us serialize a value directly from the source extension
context into an opaque blob, and then directly deserialize it into the target
context on the other end, with no X-ray overhead or clones into privileged
scopes in-between.
MozReview-Commit-ID: 4QzHi89onxc
--HG--
extra : rebase_source : 2ec196ca9ce9be90b7eadf136c938373ac7d3fdd
Bill, can you please review the binding code? Shane and zombie, can you please
review the content script matching?
MozReview-Commit-ID: IJB5s0a7r7S
--HG--
extra : rebase_source : 4026105b8c04e6b88c9be8cf76898fca26f1c3e0
Bill, can you please review the binding code and the general sanity of the
platform code? Andrew and zombie, can you please review the policy logic and
tests?
As in part 1, this aims to reduce the overhead of our extension policy logic
by making it directly available to native code with as little JS and XPConnect
overhead as possible.
MozReview-Commit-ID: 40m1wSEYtBo
--HG--
extra : rebase_source : c03834791707f78431440af9b88035ab03dc9564
Bill, can you please review the binding code, and the general sanity of the
platform code. Andrew and zombie, can you please matching algorithms and
tests.
Change summary:
The existing JavaScript matching code works well overall, but it needs to be
called a lot, particularly from hot code paths. In most cases, the overhead of
the matching code on its own adds up enough to cause a problem. When we have
to call out to JavaScript via XPConnect to make a policy decision, it adds up
even more.
These classes solve both of these problems by a) being very fast, and b) being
accessible directly from C++. They are particularly optimized for the common
cases where only literal or prefix matches are required, and they take special
steps to avoid virtual calls wherever possible, and caching computed URL
values so that they can be reused across many match operations without
additional overhead.
MozReview-Commit-ID: BZzPZDQRnl
--HG--
rename : toolkit/modules/tests/xpcshell/test_MatchPattern.js => toolkit/components/extensions/test/xpcshell/test_MatchPattern.js
extra : rebase_source : c93c4c6c36460eb5ad0fc3aa86ad42a72e76bb6c
The only difference between proxies and non-proxies is that proxies only support
up to MAX_FIXED_SLOTS slots all told (reserved plus private slot). SpiderMonkey
already has static asserts to make sure we don't ask for too many reserved slots
on a proxy.
All DOMProxyHandler::ClearExternalRefsForWrapperRelease now does is clear a backpointer to the expando, and that's handled during reflector finalization already.
The patch makes the following proxy changes:
* The number of slots in ProxyValueArray is now dynamic and depends on the number of reserved slots we get from the Class.
* "Extra slots" was renamed to "Reserved slots" to make this clearer.
* All proxy Classes now have 2 reserved slots, but it should be easy to change that for proxy Classes that need more than 2 slots.
* Proxies now store a pointer to these slots and this means GetReservedSlot and SetReservedSlot can be used on proxies as well. We no longer need GetReservedOrProxyPrivateSlot and SetReservedOrProxyPrivateSlot.
And some changes to make DOM Proxies work with this:
* We now store the C++ object in the first reserved slot (DOM_OBJECT_SLOT) instead of in the proxy's private slot. This is pretty nice because it matches what we do for non-proxy DOM objects.
* We now store the expando in the proxy's private slot so I removed GetDOMProxyExpandoSlot and changed the IC code to get the expando from the private slot instead.
Bogdan Tara
Jon Coppeard
Edgar Chen
Valentin Gosu
Kyle Machulis
Andrea Marchesini
Boris Zbarsky
Narcis Beleuzu
Cosmin Sabou
Ben Kelly
Sylvestre Ledru
Eric Rahm
Nico Grunbaum
Byron Campen [:bwc]
Brindusan Cristian
Dave Townsend
Nika Layzell
Johann Hofmann
Kris Maglione
Adam Gashlin
Jonathan Watt
Andrew McCreight
Sebastian Hengst
Tom Schuster
Andi-Bogdan Postelnicu
Francois Marier
Masatoshi Kimura
Nicholas Nethercote
Steve Fink
Chung-Sheng Fu
Jason Orendorff
Peter Van der Beken
Ehsan Akhgari
Olli Pettay
Jan de Mooij
Wes Kocher
Jessica Jong
Eden Chuang
Nicolas Silva
Till Schneidereit
Benjamin Bouvier
John Dai
Alphan Chen
Dragana Damjanovic dd.mozilla@gmail.com
Christoph Kerschbaumer
Nazım Can Altınova
Carsten "Tomcat" Book
Kartikaya Gupta
Nathan Froyd
Ting-Yu Chou
L. David Baron
Thomas Wisniewski
Mats Palmgren
Boris Chiou
Samuel Vargas
Xidorn Quan
Ryan VanderMeulen
Fernando Jimenez Moreno
btian