We use `NotifyMediaStarted()` and `NotifyMediaStopped()` to notify `MediaControlService` on parent process to start/stop a media controller, and use `NotifyMediaAudibleChanged()` to notify controller's audible state in order to request audio focus.
As our goal is to use media controller to control media element, not for web audio, web speech and other stuffs which also use audio channel agent.
Therefore, we should notify parent process to start/stop controller only for media element, instead of sending a notification in AudioChannelService because that would create media controller for all different consumers which uses audio channel agent.
Differential Revision: https://phabricator.services.mozilla.com/D45591
--HG--
extra : moz-landing-system : lando
Spliting NotifyAudioChannelAgent() to StartAudioChannelAgent() and StopAudioChanelAgent() allows us to start and stop an AudioChannelAgent in a clear naming function, and to do related operation and checking every time we start/stop the agent.
Differential Revision: https://phabricator.services.mozilla.com/D45590
--HG--
extra : moz-landing-system : lando
Note that I've confirmed no-cross-origin-autofocus.html works fine with
enabling fission on w3c-test.org.
Differential Revision: https://phabricator.services.mozilla.com/D44950
--HG--
extra : moz-landing-system : lando
The grammar changes parallel those in https://github.com/heycam/webidl/pull/700
We don't prevent having both a constructor operation and [Constructor] or
[ChromeConstructor], because those extended attributes are about to get
removed, once they are no longer used in our IDL.
Differential Revision: https://phabricator.services.mozilla.com/D45387
--HG--
extra : moz-landing-system : lando
Existing tests will fail when there are more than 1 pending frames when Drain()
is called. Repeatly calling it to ensure all frames will be collected.
Differential Revision: https://phabricator.services.mozilla.com/D43689
--HG--
extra : moz-landing-system : lando
Some existing functions that manipulates H.264 bitstream already cover
most of the efforts for converting Android encoder output. With some minor
changes, they can be called by the encoder to avoid code duplications.
Differential Revision: https://phabricator.services.mozilla.com/D43686
--HG--
extra : moz-landing-system : lando
Accessing `offsetXXX` attributes of element, it would trigger reflow, and sometime it would result in a re-entry of `processCue()` because we would call `processCue()` when `resizecaption` occurs.
One specifical case is that, assigning CSS properties `min-width` and `max-width` at the same video element, in thise case, when we re-enter the `processCues()` and access `offsetXXX`. It seems that the layout system would reprocess those properites again and again and dispatch `resizecaption` when we access `offsetXXX`, which causes an infinite loop, starting from receving `resizecaption`, then calling `processCue()`, accessing `offSetXXX`, triggering reflow, sending `resizecaption` event again.
Therefore, we should stop revisiting `processCues()` if we're already running a processing, we should run a processing once at a time.
Differential Revision: https://phabricator.services.mozilla.com/D45421
--HG--
extra : moz-landing-system : lando
This patch changes a few things about how nsFrameLoader is created, specifically
around the ChangeRemoteness API.
1. The private 'nsFrameLoader::nsFrameLoader' constructor has been simplified to
only have one overload, shared by the different `::Create` static methods.
2. The creation static method used by `ChangeRemoteness` has changed name to
`::Recreate`, as the signature is becoming more like the old method.
3. The `mNetworkCreated` bit is preserved when doing a `ChangeRemoteness`, as a
remoteness change shouldn't be affecting that property.
4. Unused fields are removed from the ChangeRemoteness API.
5. The `remoteType` attribute is now mandatory in the ChangeRemoteness API,
which simplifies the logic and makes it harder to accidentally misuse.
Differential Revision: https://phabricator.services.mozilla.com/D44893
--HG--
extra : moz-landing-system : lando
The (non-normative) window.open spec does not specify what should happen when
window.open is called on a window with a null/discarded browsing context, but
in general the lookup and creation rules do not make sense when the window has
no BC. It does, however, specify that we should return null when a target BC
cannot be found or created, and gives us broad discretion over when we decide
to ignore a load request and return null. Since we can't trigger a
cross-process load from a discarded BC, simply aborting in that case seems
like the logical solution.
For Location objects, the spec is more specific, and requires that we ignore
load attempts on Location objects whose documents are null, which in our
implementation corresponds to a discarded BrowsingContext.
LocationBase::SetURI already enforces this, but a second check in
BrowsingContext::LoadURI is probably a good idea as well.
Differential Revision: https://phabricator.services.mozilla.com/D45635
--HG--
extra : moz-landing-system : lando
Note that the areas are clipped out by all ancestor scroll ports and
their coordinate systems are the screen coordinate. So that we can tell
arbitrary elements in out-of-process iframes are scrolled out or not with
this area and the transform matrix of the iframe on screen coodinate.
Differential Revision: https://phabricator.services.mozilla.com/D44420
--HG--
extra : moz-landing-system : lando
We are going to use these functions in gfx/layers/apz/tests/mochitest/ for
fission.
Differential Revision: https://phabricator.services.mozilla.com/D44418
--HG--
extra : moz-landing-system : lando
In most of the cases, the value to be stored is the same as the existing value, which does not require an update to the database. Setting something in the database requires disk access. By using this we avoid accessing the disk in the majority of the cases.
Differential Revision: https://phabricator.services.mozilla.com/D45504
--HG--
extra : moz-landing-system : lando
Existing tests will fail when there are more than 1 pending frames when Drain()
is called. Repeatly calling it to ensure all frames will be collected.
Differential Revision: https://phabricator.services.mozilla.com/D43689
--HG--
extra : moz-landing-system : lando