Also:
* Update the DefaultNurseryMaxBytes comment
* Fix the shell parameter handling.
Differential Revision: https://phabricator.services.mozilla.com/D47869
--HG--
extra : moz-landing-system : lando
Under Wayland it is possible to add only one popup window
to a parent window. If we try to attach another popup to the window,
the GTK refuses to do that. This can happen when the previous popup
has not yet been hidden while the new popup is showing (in some cases
the nsWindow::Show(false) for the previous popup is not called before
nsWindow::Show(true) for the new one).
We deal with it by hiding wayland popups which are no longer in the
XULPopupManager (PM) before showing a new one. We only do that for
the main menu popups or context (sub)menus. We cannot use PM to check
for the panel popup content like Folder dropdown in Edit Bookmark panel
or WebRTC microphone/video source dropdown. In that case we simply use
the last shown popup as a transient for the new one or the toplevel window.
Differential Revision: https://phabricator.services.mozilla.com/D47610
--HG--
extra : moz-landing-system : lando
AudioNodeStream is a subclass of MediaStream, which now exposes a
public const mSampleRate member.
Differential Revision: https://phabricator.services.mozilla.com/D47688
--HG--
extra : moz-landing-system : lando
This change mainly removes the `mTracks` member from MediaStream and moves all
associated members up a level, so that a MediaStream in practice represents a
single track.
Classes will be renamed in a future patch to reflect this.
Other changes include:
The new `mEnded` member of MediaStream changes meaning to only become true when
all data in the stream has been processed. It stems from
StreamTracks::Track::mEnded which used to become true as soon as the last bit of
data had been added to a track, and there could still be data in the track that
would get processed in future iterations. We are moving towards not having any
future data in tracks, which is why this change is ok to make -- keeping the old
behavior will soon not make sense.
TrackUnionStream is changed to no longer take a list of streams as input and
forward the union of their tracks to itself. Instead it's limited to having one
track as input at a time.
The autofinishing functionality that TrackUnionStream had before has been
transformed into an autoending functionality to allow it to defer ending until
its been told that it's ok to end through the control API. This lets a single
TrackUnionStream span the lifetime of multiple inputs, which will be useful for
making DecodedStream spec compliant with HTMLMediaElement::CaptureStream(), and
for implementing the currently discussed MediaRecorder::ReplaceTrack(), to name
a few potential use cases.
AudioNodeStreams used to only have a track (and thus an AudioSegment) if the
EXTERNAL_OUTPUT flag was enabled on them. With all MediaStreams now representing
a track, AudioNodeStreams inherently have an AudioSegment as a member. It is
however only used with data if the EXTERNAL_OUTPUT flag is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D45821
--HG--
extra : moz-landing-system : lando
The stream order does not depend on streams' finished state, so these calls are
unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D47687
--HG--
extra : moz-landing-system : lando
This functionality is not used since we moved to only having a single track per
MediaStream (bug 1493613).
Differential Revision: https://phabricator.services.mozilla.com/D47686
--HG--
extra : moz-landing-system : lando
TrackID has been used to denote tracks that are part of MediaStreams in the
MediaStreamGraph. The TrackInfo::mTrackId IDs are no longer used in the
MediaStream APIs and as such it's not necessary that they have the type TrackID.
This patch changes TrackInfo::mTrackId to be of type uint32_t instead, as that
is the type of Mp4parseTrackInfo::track_id, which is assigned to
TrackInfo::mTrackId as the sole remaining non-static user.
Other users set a static trackId of `1` or `2`, and as such remain supported by
this change.
Differential Revision: https://phabricator.services.mozilla.com/D46763
--HG--
extra : moz-landing-system : lando
This patch introduces the concept of a "future ClientSource" to the
ClientManagerService. A "future ClientSource" is registered/removed
from the ClientManagerService by
ClientManager::{Register,Forget}FutureClientSource and is required
when a ClientInfo is initially created without a backing ClientSource.
As a result, the ClientManagerService can distinguish between a
ClientSourceParent* that has yet to register itself with the
ClientManagerService and a ClientSourceParent* that has already
both registered and removed itself from the ClientManagerService.
Differential Revision: https://phabricator.services.mozilla.com/D47592
--HG--
extra : moz-landing-system : lando
