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.
This changes JS_smprintf to return UniqueChars, rather than relying on
manual memory management.
MozReview-Commit-ID: ENjQJODYdD1
--HG--
extra : rebase_source : 4c8ad4719dce205a7ef25e41eca25c5af793bb47
Everything depending on the widget being gonk can go away, as well as
everything depending on MOZ_AUDIO_CHANNEL_MANAGER, which was only
defined on gonk builds under b2g/ (which goes away in bug 1357326).
--HG--
extra : rebase_source : 9f0aeeb7eea8417fa4e06d662d566d67ecaf2a24
Most of the time, the return value of this method should be checked,
because behavior should depend on whether or not an exception is
thrown. However, if it is called immediately after a throw it doesn't
need to be checked because it will always return true. bz said there
is no public API that lets you assume there is an exception because it
would be "too easy to misuse".
MozReview-Commit-ID: CqyicBbcNjW
--HG--
extra : rebase_source : a5b74ba88a927a90d491ceb8f0b750a67f62b0f4
Extract a `CSSPageRule` base class from the existing Gecko `nsCSSPageRule`
class. This will be used in the next commit as the parent of a new
`ServoPageRule` for the Servo variant.
MozReview-Commit-ID: 1F3FWfVKH29
--HG--
extra : rebase_source : 5186cf2e233f3a757676a0127752faa8cc748cd4
Kris Maglione
Boris Zbarsky
Andrea Marchesini
Xidorn Quan
Eden Chuang
Ryan VanderMeulen
Fernando Jimenez Moreno
Edgar Chen
btian
Jan de Mooij
Wes Kocher
Jon Coppeard
Tom Tromey
Carsten "Tomcat" Book
Chih-Yi Leu
Mike Hommey
Sebastian Hengst
John Dai
Andrew McCreight
Olli Pettay
J. Ryan Stinnett
Ben Kelly