The changes proposed here will speculatively parse all external scripts off thread as soon as they are fetched, except for async, link preload, and non parser inserted scripts. This should save us some time since currently all scripts are parsed right before execution or while they are blocking the dom parser.
Differential Revision: https://phabricator.services.mozilla.com/D76644
We need to extract the common method into the idl since the connection between necko
and XHR is idl. Need to import the whole necko if we do something like
`#include "HttpBaseChannel.h"
Differential Revision: https://phabricator.services.mozilla.com/D78830
NOTE: this also removes a mysterious old comment that implied this code could run without libpref initializing
the value, in which case they picked a different default. I assume this is no longer a real configuration?
Differential Revision: https://phabricator.services.mozilla.com/D77848
This renames the pref to remove 'experimental' and turns it on by default.
For integration with the CC, any DOM objects that are the target of a WeakRef or registered with a FinalizationRegistry have their wrappers preserved. WeakRef.deref() checks whether any wrapper is still preserved and returns undefined if not, to avoid giving out references to wrappers whose DOM object has been cycle collected.
Tests exercising browser integration are under js/xpconnect/tests/mochitest/.
Differential Revision: https://phabricator.services.mozilla.com/D77656
This is just cleanup and should have no behavior changes. In the future,
I may optimize GetPrimaryFrame to not flush frames in the whole document
if the style of the node and ancestors haven't changed.
I think one bit of this function shouldn't be needed, but I have left it
as is for now.
Differential Revision: https://phabricator.services.mozilla.com/D78886
Mozilla consider that we should protect even Nightly testers from the behavior
change of bug 1320229.
And I forgot to modify the new mochitest for bug 1635224 which is a regression
of bug1320229.
Differential Revision: https://phabricator.services.mozilla.com/D78841
This patch will
- remove `MediaControlKeysEvent` and use `MediaControlKey` to replace it
- rename names for all `MediaControlKey` related methods, functions, classes and descriptions
The advantage of doing so are
- remove the duplicated type so that we only need to maintain `MediaControlKey`
Differential Revision: https://phabricator.services.mozilla.com/D78140
This patch will
- create a chrome-only webdil interface `MediaController`
- expose supported keys via `MediaController` webidl interface
The advantage of doing so are
- to have a dedicated interface that is only used for MediaController that can be used for testing and our future plan (media hub)
More Details :
Currently, we access media controller's from `ChromeUtils` [1], but it causes a problem of creating a duplicated enum of the enum which we want to expose into Chrome JS.
Instead, we should create a media controller interface to access all its attibutes, which is more easier and clean.
In addition, we're planning to have a something like Chrome's media hub [2]. In order to do that, we have to expose some JS methods to allow us to control playback directly from Chrome JS.
[1] https://searchfox.org/mozilla-central/rev/559b25eb41c1cbffcb90a34e008b8288312fcd25/dom/chrome-webidl/ChromeUtils.webidl#485-493
[2] https://blog.google/products/chrome/manage-audio-and-video-in-chrome/
Differential Revision: https://phabricator.services.mozilla.com/D77757
This patch will
- prevent dispatching metadata change event for non-active media session (we only care about the event from the active media session)
The advantage of doing so are
- reduce some unnecessary code running
Differential Revision: https://phabricator.services.mozilla.com/D77756
This patch will
- add a method `SetSupportedMediaKeys()` on `MediaControlKeysEventSource`
- set main controller's supported key to the event source
The advantage of doing so are
- to allow the event source knowing which key is supported in order to determine the displayed UI button
Differential Revision: https://phabricator.services.mozilla.com/D77200
This patch will
- tell the media controll supported action changes when media session updates its action handler
The advantage of doing so are
- to sync the status between media session in content process and the `MediaSessionInfo` in chrome process
Differential Revision: https://phabricator.services.mozilla.com/D77199
This patch will
- add methods to allow media controller to enable/disable action for specific media session
The advantage of doing so are
- to know the supported actions for each media session
Differential Revision: https://phabricator.services.mozilla.com/D77198
This patch will
- `ContentMediaAgent` as the only class to propagate the information to chrome process
The advantage of doing so are
- to group all methods involving IPC in one place, that would be easier to see what information would be propagated to chrome process
Differential Revision: https://phabricator.services.mozilla.com/D77197
Denis Palmeiro
Molly Howell
Edgar Chen
Junior Hsu
Simon Giesecke
Csoregi Natalia
Noemi Erli
ssengupta
Emilio Cobos Álvarez
Alexis Beingessner
Andreas Farre
Andrea Marchesini
Tom Tung
Johann Hofmann
Razvan Maries
Dan Minor
Jan Varga
Butkovits Atila
Jon Coppeard
Masayuki Nakano
alwu