A forward declaration right before a definition is useless, and
ParseLazyURIValue is not implemented.
Differential Revision: https://phabricator.services.mozilla.com/D48760
--HG--
extra : moz-landing-system : lando
Implement the setActionHandler interface. The API will be enabled behind
a pref.
Differential Revision: https://phabricator.services.mozilla.com//D45458
Depends on D45457
--HG--
extra : histedit_source : 43cf16795b27126a96441b117c9bbfdf2aea6aa9
Implement the MediaMetadata interface. The API will be enabled behind a
pref.
Differential Revision: https://phabricator.services.mozilla.com//D45457
Depends on D45456
--HG--
extra : histedit_source : a572d4abe88c2b4cd8c03a0fadc6c7b30a8c8798
Create dummy implementations for the MediaSession interfaces. The files
are generated by running `./mach webidl-example` with necessary changes
to make it buildable.
The internal implementations are blank in this patch. They will be done
in the following patches.
Due to some spec issues, the final implementations only support some
basic operations like "play" and "pause".
Differential Revision: https://phabricator.services.mozilla.com//D45456
--HG--
extra : histedit_source : 2fc6e1e63347211cad3a19354a38040760c7ce0f
The first call to Extract() comes from MediaEncoderInitialized() and runs before
we dispatch the task to fire "start". With a very small timeslice (even 0), the
first call to Extract() could decide to push a blob, which is against the spec.
With this patch, the caller is in control of what time Extract() thinks "now"
is. This lets the particular call from MediaEncoderInitialized() gather data
into the blob through Extract() without being at risk of pushing a blob.
Differential Revision: https://phabricator.services.mozilla.com/D48842
--HG--
extra : moz-landing-system : lando
Create dummy implementations for the MediaSession interfaces. The files
are generated by running `./mach webidl-example` with necessary changes
to make it buildable.
The internal implementations are blank in this patch. They will be done
in the following patches.
Due to some spec issues, the final implementations only support some
basic operations like "play" and "pause".
Differential Revision: https://phabricator.services.mozilla.com/D45456
--HG--
extra : moz-landing-system : lando
On Android, decoded buffers need to be send back to MediaCodec in order to be
rendered and/or recycled. The current mechanism introduced in bug 1299068 only
works for playback(VideoData/VideoSink) but not WebRTC(VideoFrame/VideoOutput).
Move the callback to SurfaceTextureImage because VideoData and VideoFrame both
own that when using MediaCodec, and move the notification to VideoFrameContainer
for both VideoSink and VideoOutput pass frames there for compositing.
Differential Revision: https://phabricator.services.mozilla.com/D45771
--HG--
extra : moz-landing-system : lando
See the first patch's commit message to learn why we had to change the
PageInformation's IDs to BrowsingContextID and InnerWindowID.
Previously we were registering profiler PageInformation in the nsDocShell
methods. That was not the correct place to handle page loads correctly. That's
why we had to move the registration to WindowGlobalChild::SetDocumentURI and
WindowGlobalChild::ActorDestroy. In those functions we are sure that each
document URIs will come here only once.
Differential Revision: https://phabricator.services.mozilla.com/D47066
--HG--
extra : moz-landing-system : lando
We were keeping nsDocShell::mHistoryId and nsDocShell::mOSHE as keys. They
weren't quite good because:
1. While loading an iframe, they were being registered twice with the same
ids(for about:blank and the real URL) sometimes.
2. It wasn't possible to access to the parent mHistoryId and mOSHE from a child
processes if the parent is in a different process. That may not be the case for
now, but it will be after fission.
So we had to find other IDs to:
1. Determine the Tab of the frames.
2. Determine the URLs of the frames.
For the first use case, we were using nsDocShell::mHistoryId for that purpose
but that was wrong. The closest thing that we can get to a tab ID is
BrowsingContext ID because they don't change after a navigation. But iframes
have different BrowsingContext's, so we still need to create a tree to
construct a tab content. That can be either in the front-end or capture time.
For the second use case, we were using a key pair of mHistoryId and mOSHE. We
now chose to keep inner window IDs for that purpose. Inner window IDs are
unique for each navigation loads because inner window correspond to each JS
window global objects. That's why we can use that without any problem. But one
problem is that we cannot handle `history.pushState` and `history.replaceState`
changes with that change since window global objects won't change during those.
But that was the best thing we can do after fission. So this will be a small
sacrifice for us to keep that functionality working after fission.
In that patch we also remove the registration/unregistration calls. We are
going to add those calls in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D47065
--HG--
extra : moz-landing-system : lando
This method turned out to only be used for tracing wrapper cached things. The wrapper cache has its own way of implementing barriers and contains a raw JSObject pointer. Changing this trace method to take an nsWrapperCache pointer (effectively a JSObjct**) enforces correct use of Heap<T> for other TraceCallbacks callers.
Differential Revision: https://phabricator.services.mozilla.com/D48693
--HG--
extra : moz-landing-system : lando
Looks like an oversight from all the way back to bug 806506.
Depends on D48538
Differential Revision: https://phabricator.services.mozilla.com/D48539
--HG--
extra : moz-landing-system : lando
Web Share base implementation just of DOM stuff - working together with @saschanaz.
@Baku, we would greatly appreciate your review.
-Nika, as she is traveling.
Differential Revision: https://phabricator.services.mozilla.com/D44598
--HG--
extra : moz-landing-system : lando
We should have a basic test where do a simply request and revoke audio focus for same controller.
Differential Revision: https://phabricator.services.mozilla.com/D47372
--HG--
extra : moz-landing-system : lando
`TestMultipleAudioFocusNums` is used to test whether we can increase the amount of the audio focus when we don't enable audio focus management. As we won't handle the audio competing in this situation, so we allow multiple controllers owing audio focus at the same time.
However, if we enable audio focus management, we would start to handle audio competing and ensure that only one controller can own audio focus at a time. As it involves multiple components, we are not able to test it by simply using `AudioFocusManager`'s APIs.
Therefore, we should have two separate tests to test the behavior of owning audio focus when enabling or disabling audio focus management.
Differential Revision: https://phabricator.services.mozilla.com/D47371
--HG--
extra : moz-landing-system : lando
Ehsan Akhgari
Edgar Chen
Emilio Cobos Álvarez
Oana Pop Rus
Chun-Min Chang
Jan Varga
Andreas Pehrson
Daniel Varga
John Lin
Nazım Can Altınova
Simon Giesecke
Brian Hackett
Jon Coppeard
Nika Layzell
Christoph Kerschbaumer
Thomas Nguyen
Marcos Cáceres
Gijs Kruitbosch
Mirko Brodesser
Tim Nguyen
John Dai
Brindusan Cristian
Matt Woodrow
alwu
Narcis Beleuzu
Jean-Yves Avenard