This removes AutoMaybeEnterFrameRealm. Most places pass cx->realm->principals: it preserves behavior when the (possibly wrapped) SavedFrame and cx are same-compartment. The main exception is the JSStackFrame DOM bindings code where we have to be a bit smarter about which principals to use.
This ChromeUtils API now returns a promise that gets resolved once all the data
has been collected via IPDL and the main process. The existing notification
design and its related XPCOM classes are removed.
MozReview-Commit-ID: CYKukBOC8yh
--HG--
extra : rebase_source : 1e27524726ace0bfed5297d48af8be268c5b4945
Changes:
- The API now returns a Promise containing a sequence of IOActivityData dictionnaries.
- All the code related to notifications and XPCOM is removed.
- The counters are no longer reset to 0 when the API is called
MozReview-Commit-ID: 7J2EgFqDgf
--HG--
extra : rebase_source : eb7dc3e0921b12bbb3715a90863dc8e2a60c1c09
This ChromeUtils API now returns a promise that gets resolved once all the data
has been collected via IPDL and the main process. The existing notification
design and its related XPCOM classes are removed.
MozReview-Commit-ID: CYKukBOC8yh
--HG--
extra : rebase_source : 1e27524726ace0bfed5297d48af8be268c5b4945
Changes:
- The API now returns a Promise containing a sequence of IOActivityData dictionnaries.
- All the code related to notifications and XPCOM is removed.
- The counters are no longer reset to 0 when the API is called
MozReview-Commit-ID: 7J2EgFqDgf
--HG--
extra : rebase_source : 4e16640a3f52fd7c042687471153971a66158623
- Introduced the io.activity.enabled pref, so IOActivityMonitor can run without a timer
- Added IOActivityMonitor::NotifyActivities() to trigger notifications manually
- Added ChromeUtils.requestIOActivity() so we can trigger it via JS
MozReview-Commit-ID: 9JA2rLaM496
--HG--
extra : rebase_source : e473a7b0ec7c231ab321846c5ddcc4d6a88d7245
- Introduced the io.activity.enabled pref, so IOActivityMonitor can run without a timer
- Added IOActivityMonitor::NotifyActivities() to trigger notifications manually
- Added ChromeUtils.requestIOActivity() so we can trigger it via JS
MozReview-Commit-ID: 9JA2rLaM496
--HG--
extra : rebase_source : 0a92195b6b8314383c63de4b2bb1dfe033c40e9f
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
PerformanceCounters are currently disabled in two ways:
- a preference that's off by default "dom.performance.enable_scheduler_timing"
- calls made only for nightly using #ifndef RELEASE_OR_BETA
In order to simplify the code, let's remove the #ifndef and rely only on the pref.
That will also allows us to use the feature in every version going forward.
The performance will not be impacted since the current code is already using
the (cached) pref value to determine if the counters are used.
MozReview-Commit-ID: 47t2M1O13aH
--HG--
extra : rebase_source : e129e1829f1dc37c019e50e156474c4876d6d6cb
Chromeutils.RequestPerformanceMetrics() is now composed of two parts:
- calls content processes via IPDL to get their counters
- directly dispatch counters from the parent process
MozReview-Commit-ID: HlgcEOzkyAq
--HG--
extra : rebase_source : 60e81a27cd3a1bf1378e6b977529964507633b63
Adds the IPDL layer to asynchronously retrieve in the parent process the performance counters.
MozReview-Commit-ID: RbKstNx8pi
--HG--
extra : rebase_source : d7c00f2ef16623dbbd88ede0f6636ca56501e151
Adds the IPDL layer to asynchronously retrieve in the parent process the performance counters.
MozReview-Commit-ID: RbKstNx8pi
--HG--
extra : rebase_source : f81058b9bdd67c2f77bb5cd45d3838bc12f406ea
Adds the IPDL layer to asynchronously retrieve in the parent process the performance counters.
MozReview-Commit-ID: RbKstNx8pi
--HG--
extra : rebase_source : 673bbf79f5e20493eee5e129f6954c574c9c41b6
There's no standard way to create a JS error with full stack and location
information from a saved stack. Since we need this functionality in order to
reject promises with useful Error objects, this patch adds a simple helper to
make that possible.
MozReview-Commit-ID: FyGuo4UjfsQ
--HG--
extra : rebase_source : 65ef11c56f23e04ea5eeb87b972bfc8e4867fdd2
Most WebExtension APIs are async, and have fairly complicated error reporting
semantics. As a result, when we report an error, the current JS stack has very
little to do with the JS caller that triggered the error, which makes it
difficult to diagnose.
In order to improve the situation, we need to store the location of the caller
at the start of an async operation, so we can tie the error to some marginally
useful location. We don't have a reasonable way to do that now other than
proactively creating an error object when the API is called, or creating a
promise with a full async stack, both of which are too expensive.
This helper instead returns a single SavedStack frame with a given principal,
which should be considerably cheaper, and likely good enough to give a
starting point for debugging cryptic errors.
MozReview-Commit-ID: BTxhpZK9Fdz
--HG--
extra : rebase_source : 7f2c66b1dc18d4ce4c47bef2e3b9d5d3ade929aa
This helper makes it easy to lazily import a JavaScript module the first time
one of its exports is required. It is intended to replace
XPCOMUtils.defineLazyModuleGetter, which has similar functionality but is much
less efficient.
MozReview-Commit-ID: 2zxXYwrn3Dr
--HG--
extra : rebase_source : 998de7388ee03fdec0a0949b4e43bd9169dbb592
extra : histedit_source : 414d0ed1842b2270146d37b2788a56c682d3d695
Looking up and copying exported properties each time a module is loaded is
fairly expensive at the best of times. It's even more expensive when we only
want to export a subset of symbols, which generally requires creating a
temporary object to hold the exports, or fetching them directly from the
returned global.
Aside from making the general case a bit faster, storing exports on an object
allows us to optimize lazy module imports by fetching imported symbols
directly from the exports object with very little additional overhead.
MozReview-Commit-ID: C9PGoXPNmsh
--HG--
extra : rebase_source : 6232cf7a52fd69ebeb8b6e39680646f287c272a8
extra : histedit_source : b223c73a6e9092491f4fb09f8c795f5aa4b43df3
This was automatically generated by the script modeline.py.
MozReview-Commit-ID: BgulzkGteAL
--HG--
extra : rebase_source : a4b9d16a4c06c4e85d7d85f485221b1e4ebdfede
This is similar to Services.tm.idleDispatchToMainThread, but provides an
IdleDeadline argument to its callbacks, the same way that
Window.requestIdleCallback does.
The IdleDeadline argument was necessary for my first attempt at this bug. It's
not necessary for the current version, but I suspect it will be useful in
other areas, and it also avoids some XPConnect overhead, so it's probably
worth keeping.
MozReview-Commit-ID: FtrbNkE7Vz5
--HG--
extra : rebase_source : d28973641e914c8d180f66125669aabc29ab857f
This will allow us to verify the entire detection pipeline in real nightly
builds, which will give us confidence that real heap corruption will be
detected and reported properly.
MozReview-Commit-ID: 43Fp2HT8RYy
As part of the normalization process for WebExtension API calls, we need to
extract and validate the full set of value properties (including properties
X-rays would normally deny access to) from cross-compartment objects. This
currently involves waiving X-rays, enumerating property descriptors, and
unwaiving X-rays - all through X-ray wrappers and waivers - and generating a
lot of expensive and short-lived wrappers in-between.
This helper reads out the list of safe properties from within the object's
compartment, and then copies them over to an object in the target compartment,
without any X-ray overhead, or any unnecessary intermediate wrappers or
compartment switches. It cuts about 40% off the overhead of our normalization
code.
MozReview-Commit-ID: H582oAYocaX
--HG--
extra : rebase_source : 7f7d5df605bc6544cb7f1c0c7e224d81b211e09c
extra : histedit_source : f980a03413b5e65fc6fa272c012a769d2764d89b
In the code that I'm profiling, the XPC WrappedNative overhead of calling
these functions adds up to about a quarter of the time spent executing the
code. The overhead of the WebIDL versions is negligible.
MozReview-Commit-ID: 30qJy5RtP9d
--HG--
extra : rebase_source : 4fe73f4b9bde052a0eadf7d5634f792e16ca1c94
extra : histedit_source : ec61152a0181f3b0e28023c951e7181c43216d2f