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
This mostly just copies the functional parts of the APZTestData code from
ClientLayerManager into WebRenderLayerManager, and propagates the paint sequence
number over to the compositor using the existing WebRenderScrollData machinery.
MozReview-Commit-ID: LHupFpqtWTX
This is fairly straightforward plumbing. The webrender equivalent of PLayerTransaction
is PWebRenderBridge and we can use that to get the compositor-side APZTestData.
MozReview-Commit-ID: Bn8WjKW5GoI
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 changes? Shane, can you please review
the policy service?
This is the first step to making extension policy data directly available to
C++ code without any COM overhead. It tracks the set of currently active
extensions, and how they map to add-on IDs and URIs.
MozReview-Commit-ID: 9Z61AXFll3P
--HG--
extra : rebase_source : c38898905a63ab8d0a424bfda7c61ea6c645ff32
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
Bug 612018 made us flush layout for caret painting which isn't triggered
from anything that can call this code any mode, therefore we can revert
the change from that bug.
This patch does the following renamings, which increase consistency.
- GeckoProfilerInitRAII -> AutoProfilerInit
- GeckoProfilerThread{Sleep,Wake}RAII -> AutoProfilerThread{Sleep,Wake}
- GeckoProfilerTracingRAII -> AutoProfilerTracing
- AutoProfilerRegister -> AutoProfilerRegisterThread
- ProfilerStackFrameRAII -> AutoProfilerLabel
- nsJSUtils::mProfilerRAII -> nsJSUtils::mAutoProfilerLabel
Plus a few other minor ones (e.g. local variables).
The patch also add MOZ_GUARD_OBJECT macros to all the profiler RAII classes
that lack them, and does some minor whitespace reformatting.
--HG--
extra : rebase_source : 47e298fdd6f6b4af70e3357ec0b7b0580c0d0f50
This mostly just copies the functional parts of the APZTestData code from
ClientLayerManager into WebRenderLayerManager, and propagates the paint sequence
number over to the compositor using the existing WebRenderScrollData machinery.
MozReview-Commit-ID: 6GD5Sl3dSJp
--HG--
extra : rebase_source : d2f212128f8b352ef81e5c25650b95fae1f90002
This is fairly straightforward plumbing. The webrender equivalent of PLayerTransaction
is PWebRenderBridge and we can use that to get the compositor-side APZTestData.
MozReview-Commit-ID: JE9WkmejuM9
--HG--
extra : rebase_source : 8872e8dffb988740fa816870cfad25dd6a7d3c21
Every JS plugin is assigned a unique ID. When an instance of a JS plugin is created the
frame loader that we use to load the plugin's handler URI will create a special
TabContext. This TabContext causes the ContentParent to use the process for this specific
JS plugin (creating one if it hasn't already) when it creates the PBrowser actors.
This causes the iframes for all the instances of a specific JS plugin to be grouped in the
same process.
--HG--
extra : rebase_source : c39560bdf66cda1a005c7b823b3a46e4734878a4
extra : source : 9cba1db527c7eed4371c9f4caf96fd942608cab6
- Added new chrome-only webidl methods to be used by browser UI and WebExtensions
- Implemented bitmasked group visibility for VR sessions to enable switching
between chrome and regular content presentations.
- Implemented throttling mechanism to avoid runaway, unthrottled render loops
for VR sessions that are hidden by group visibility bitmasks or due to
lower level platform VR events, such as during the Oculus
"Health and Safety Warning".
- Simplified the PVRManager IPC protocol while extending it to support
VR session groups and later WebVR content performance profiling API's.
- Removed the last WebVR related sync IPC call.
MozReview-Commit-ID: BMEIPyYeEbq
--HG--
extra : rebase_source : 47d3682cad3d913504175b7d4c3e9d992236f097
This implements some methods exposed on DOMWindowUtils and used by
reftests, for the WebRender codepath. The implementation is very similar
to the implementation in LayerTransactionParent.
MozReview-Commit-ID: HP8OxzIzS7P
The browser-chrome test suite now detects and reports unhandled rejections of native Promises, in addition to those created by Promise.jsm. The whitelisting mechanism is updated to use primarily the PromiseTestUtils.expectUncaughtRejection function. Tests will fail if a rejection that is not whitelisted occurs, or if a whitelisted rejection does not occur anymore.
MozReview-Commit-ID: 1beGB5GG8Ty
--HG--
extra : rebase_source : 64395c5fdf25deebd60dfbf2cf5df3cbf7ca8abb
extra : amend_source : 0a3f13419c050662680f2bd110d724b3bf991732
extra : source : 8d53be05afc59519c5ce8cfae96d284a972fda71
The browser-chrome test suite now detects and reports unhandled rejections of native Promises, in addition to those created by Promise.jsm. The whitelisting mechanism is updated to use primarily the PromiseTestUtils.expectUncaughtRejection function. Tests will fail if a rejection that is not whitelisted occurs, or if a whitelisted rejection does not occur anymore.
MozReview-Commit-ID: 1beGB5GG8Ty
--HG--
extra : rebase_source : 59e5b84cb431f3ca28287d30a3da8fbea1363ec5
This will enable us to re-use the logging code in MediaKeySystemAccess to log
the configuration we end up instantiating the MediaKeySystemAccess with.
MozReview-Commit-ID: AMnauhMLJ1R
--HG--
extra : rebase_source : a2dfeb7b263108ac1c60bfe2f47755e0a73d6324
The previous version of this test assumed that it was in control of all
processes (except for a single one that was hanging around). That meant that
changes to the environment, such as running it on a different branch could
cause it to fail. Now we explicitly test that creating new tabs creates a new
content process (and that the final tab creation *doesn't* do so) with a
sanity check that new ContentParents don't reuse the same underlying OS
process. Because we're now explicitly testing what we want, this works whether
the current branch holds a random extra process alive or not.
MozReview-Commit-ID: CNgLGL32Iog
--HG--
extra : rebase_source : f27d132d00bdd94d7034cc63c83bbacfe04bde0c
In the nsWindowMemoryReporter.cpp / nsArenaMemoryStats.h I'm only
including the concrete frame classes now - we obviously never have
instances of the other IDs so there's no need to collect stats for them.
MozReview-Commit-ID: 48uFCZ3xKBC
The <content> in an XBL document could be injected into documents with
different style backend types. Therefore, we need to set the XBL document's
style backend to the same as the bound document's so that the style
attribute of the content can be processed by the correct backend. <marquee>
elements in xbl-marquee.xml is one such example.
MozReview-Commit-ID: 7M33zlbZqNF
--HG--
extra : rebase_source : 363fd7c2bc91e959fbcfb288bdc1b65cfd1bba97
SupportsServoStyleBackend() uses methods in nsIDocument, so it would be more
straightforward to do that in UpdateStyleBackendType().
Also, call StyloEnabled() before doing other logic so that the warning about
"no docshell" won't show up when stylo is built but disabled.
MozReview-Commit-ID: 9ZUYatPBv1r
--HG--
extra : rebase_source : ea130cdf2ef0b49d73bd688aeca1fc227431441c
In this way, the callers who have nsIDocument don't need to cast to nsDocument.
MozReview-Commit-ID: 8zVUjkbrlaG
--HG--
extra : rebase_source : c444a103a430e3746508cc894902e677d58e65fe
Changed the type of argument |targetFilter| of NukeCrossCompartmentWrappers()
from CompartmentFilter to JSCompartment* because it is always a single target
compartment, and we can optimize the iteration not to iterate the outer map.
MozReview-Commit-ID: 7cDCgJI0H9z
--HG--
extra : rebase_source : 4973dfd4c3326bf48b78088979962e425e35030c
Selection::Collapse() removes all ranges first, then, adds a collapsed range which is a new instance of nsRange.
However, new nsRange's initialize cost isn't cheap. It needs to add itself to mutation observer and computes common ancestor. However, Selection::Collapse() doesn't move the range to different document. If old range is reusable, we can avoid to remove old range from mutation observer and add new range to mutation observer, and also we can avoid to recompute common ancestor if the node is not changed, e.g., only offset is changed in selected node.
MozReview-Commit-ID: BoCBod7WVr5
--HG--
extra : rebase_source : 9ccee28aebba355ebb1137ebc1d02e7d8a30aedf
nsRange::DoSetRange() adds/remove its root to/from mutation observer, initializes common ancestor, registers itself to the common ancestor, unregisters itself from old common ancestor, and notifies selection listeners of selection change.
However, those runtime cost is expensive but on the other hand, a lot of callers set both start and end of the range and that causes calling DoSetRange() twice.
This patch renames Set() to SetStartAndEnd() for easier to understand the meaning and make it call DoSetRange() only once.
MozReview-Commit-ID: FRV55tuBAgg
--HG--
extra : rebase_source : 67adf929cf119e2425f7d3741651217522094590
Changed the type of argument |targetFilter| of NukeCrossCompartmentWrappers()
from CompartmentFilter to JSCompartment* because it is always a single target
compartment, and we can optimize the iteration not to iterate the outer map.
MozReview-Commit-ID: 7cDCgJI0H9z
--HG--
extra : rebase_source : ee9341168a28b5e6f273c512b0562ee4ddc297bc
extra : source : e80197b115673f259293d112da61c8dd9edc121e
With nsIDocument::IsScriptTracking, we know that whether a script is a tracking script. If the XHR is created by a tracking script, we want to lower the priority of the http channel.
--HG--
extra : rebase_source : 7c9d2a545968a50c8ec34a3395132f0d99087058
Also, update an outdated comment that was leftover.
MozReview-Commit-ID: CC865rj3o3S
--HG--
extra : rebase_source : 094ed5c23a55f8f00f7aeb18856c539caa80ff86
IGNORE BAD COMMIT MESSAGES because something landed and was backed out for no bug number
--HG--
extra : amend_source : 1134c379d1134fe160fd2d889488d07acd9f4177
This makes UpdateLayerTree synchronous enough to ensure that the layer
transaction from the child reaches the compositor. Given the comment in
http://searchfox.org/mozilla-central/rev/484d2b7f51b7aed035147bbb4a565061659d9278/dom/interfaces/base/nsIDOMWindowUtils.idl#106
this seems to be the original intent of this function anyways. Without this, we
can have a race between the child talking to the compositor and the child
talking to the parent talking to the compositor.
This also changes GetCompositorBridgeChild to work even when the widget doesn't
have a CompositorBridge
This makes UpdateLayerTree synchronous enough to ensure that the layer
transaction from the child reaches the compositor. Given the comment in
http://searchfox.org/mozilla-central/rev/484d2b7f51b7aed035147bbb4a565061659d9278/dom/interfaces/base/nsIDOMWindowUtils.idl#106
this seems to be the original intent of this function anyways. Without this, we
can have a race between the child talking to the compositor and the child
talking to the parent talking to the compositor.
This also changes GetCompositorBridgeChild to work even when the widget doesn't
have a CompositorBridge
Ben Kelly
Hector Zhao
Nicolas B. Pierron
Kris Maglione
Tobias Schneider
Kartikaya Gupta
Sebastian Hengst
Joel Maher
Florian Quèze
Ryan VanderMeulen
Oriol
Ehsan Akhgari
Peter Van der Beken
Olli Pettay
Nicholas Nethercote
Xidorn Quan
John Schoenick
Kearwood Gilbert
Brad Werth
Carsten "Tomcat" Book
Christoph Kerschbaumer
Tim Taubert
Andrea Marchesini
Jonathan Kew
Jonathan Watt
Emilio Cobos Álvarez
Eden Chuang
Boris Zbarsky
Andreas Farre
Paolo Amadini
Chris Pearce
Blake Kaplan
Mats Palmgren
Timothy Nikkel
Bill McCloskey
Ting-Yu Lin
Ting-Yu Chou
Masayuki Nakano
Wes Kocher
Kershaw Chang
Iris Hsiao
btian
Jeff Muizelaar