Implement a chrome-only method `getCurrentMediaSessionPlaybackState()` to expose current actual playback state in testing.
The reason we create an new enum `MediaSessionPlaybackTestState` is because of building issue. If we use `MediaSessionPlaybackState` directly in the `ChromeUtils.webidl`, then the codegen would automatically add an header include of `MediaSessionBinding.h` in the `ChromeUtilsBinding.h`, which would cause the complier complaining about lots of undeclared identifier.
Differential Revision: https://phabricator.services.mozilla.com/D66344
--HG--
extra : moz-landing-system : lando
Create a chrome-only method to get the current media metadata to know if we correctly update the media metadata or not. That method would only be used for testing.
Differential Revision: https://phabricator.services.mozilla.com/D64849
--HG--
extra : moz-landing-system : lando
We handle media control key events differently from normal key events, and at this point we haven't finished the implementation of capturing media control key events on each platform. Therefore, create a method to generate platform-independent events in order to help testing.
Differential Revision: https://phabricator.services.mozilla.com/D57911
--HG--
extra : moz-landing-system : lando
This helps retrieving the NodeId for any JS Object you pass in.
This allows identifying a particular object when using HeapSnapshot API.
`HeapSnapshot.computeDominatorTree()` returns a tree of object,
but there is no way to identify a given JS object in it.
Getting the node id of a given JS object helps you browse this tree
from a given object you know is leaking.
Differential Revision: https://phabricator.services.mozilla.com/D53971
--HG--
extra : moz-landing-system : lando
This patch introduces a new module in widget that implements a simple API to
retrieve system information about a process and its threads.
This function is wrapped into ChromeUtils.RequestProcInfo to return information
about processes started by Firefox.
The use case for this API is to monitor Firefox resources usage in projects
like the battery usage done by the data science team.
Differential Revision: https://phabricator.services.mozilla.com/D10069
--HG--
extra : moz-landing-system : lando
This patch introduces a new module in widget that implements a simple API to
retrieve system information about a process and its threads.
This function is wrapped into ChromeUtils.RequestProcInfo to return information
about processes started by Firefox.
The use case for this API is to monitor Firefox resources usage in projects
like the battery usage done by the data science team.
Differential Revision: https://phabricator.services.mozilla.com/D10069
--HG--
extra : moz-landing-system : lando
This is the first part of hiding the implementation of nsIJSID behind the
interface added in Part 1, such that we can substitute that implementation out.
I had to make a couple of changes to fix the errors caused by the new behaviour
in GenerateQI.
Differential Revision: https://phabricator.services.mozilla.com/D2279
Expose Chrome only WebIDL to interface with BrowsingContext from
script. The API consists of parent, firstChild and nextSibling
attributes for BrowsingContext, and the browsingContext attribute for
Window.
--HG--
extra : rebase_source : 772d25e8b4e5526453545ddb2b1607845f3b65ea
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
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
