This moves the telemetry and preferences out into their own files and restores the parse result telemetery.
Differential Revision: https://phabricator.services.mozilla.com/D52749
--HG--
extra : moz-landing-system : lando
This moves the telemetry and preferences out into their own files and restores the parse result telemetery.
Differential Revision: https://phabricator.services.mozilla.com/D52749
--HG--
extra : moz-landing-system : lando
PhysicalSocketServer isn't currently used by Mozilla's WebRTC
integration, but just in case, let's make sure that this array index is
bounds-checked in actual use, not just in debug builds (which tend to
never see realistic test conditions).
Differential Revision: https://phabricator.services.mozilla.com/D52745
--HG--
extra : moz-landing-system : lando
This adds a whitelist of domains for which mDNS hostname obfuscation is
disabled. The implementation is an updated version of the old screensharing
whitelist code.
Differential Revision: https://phabricator.services.mozilla.com/D52012
--HG--
extra : moz-landing-system : lando
This adds a whitelist of domains for which mDNS hostname obfuscation is
disabled. The implementation is an updated version of the old screensharing
whitelist code.
Differential Revision: https://phabricator.services.mozilla.com/D52012
--HG--
extra : moz-landing-system : lando
The mDNS code makes use of the StunAddrsRequest which does not exist when
we are running with e10s disabled. If e10s is disabled, PeerConnectionMedia
will not be in the content process, and we can disable hostname obfuscation
in that case.
Differential Revision: https://phabricator.services.mozilla.com/D51986
--HG--
extra : moz-landing-system : lando
This swaps things around so that received tracks in peer connections have a
content principal instead of a null principal initially.
This puts an extra requirement on us to not output any frames under the content
principal after ALPN has been negotiated with requested privacy, but before this
private principal has been signaled to the MediaPipelines. The private principal
is signaled from the STS thread, via the main thread, whereas media is consumed
directly by MediaPipelines after being received on the STS thread.
This patch adds an extra signaling path directly from the STS thread that tells
MediaPipelines to make their PrincipalHandle private, and to ignore any data
until the private PrincipalHandle is set. It also moves the responsibility of
updating the principal of the received MediaStreamTracks from TransceiverImpl
to MediaPipeline, so it's all in the same path.
This lets all MediaStream and MediaStreamTrack APIs consume received tracks
directly after getting exposed to JS without errors. In case privacy is later
requested, consumers that have already been set up must handle this on the fly.
(They do, in specs and impls)
Differential Revision: https://phabricator.services.mozilla.com/D48947
--HG--
extra : moz-landing-system : lando
nsISerialEventTarget is more semantically accurate for these uses, as the
dispatched runnables cannot run in parallel. It also allows us to use
InvokeAsync in future patches, as that function only takes nsISerialEventTarget.
Differential Revision: https://phabricator.services.mozilla.com/D49262
--HG--
extra : moz-landing-system : lando
This patch fixes two things:
1) A potential threading issue in setting and reading the PrincipalHandle for
MediaPipelineReceiveVideo.
2) Plumbs the PrincipalHandle down to the receiving MediaPipelines right from
the start. It hasn't been necessary in the past as initially the principal
handed to a track's constructor is trusted, but it's good form and will help
clarify the situation for the next patch which switches the initial
principal from always-private to mostly-non-private. In most cases this
principal does no longer get updated after the track's been created, so it
helps to have a PrincipalHandle that matches the track's principal.
Differential Revision: https://phabricator.services.mozilla.com/D48946
--HG--
extra : moz-landing-system : lando
This swaps things around so that received tracks in peer connections have a
content principal instead of a null principal initially.
This puts an extra requirement on us to not output any frames under the content
principal after ALPN has been negotiated with requested privacy, but before this
private principal has been signaled to the MediaPipelines. The private principal
is signaled from the STS thread, via the main thread, whereas media is consumed
directly by MediaPipelines after being received on the STS thread.
This patch adds an extra signaling path directly from the STS thread that tells
MediaPipelines to make their PrincipalHandle private, and to ignore any data
until the private PrincipalHandle is set. It also moves the responsibility of
updating the principal of the received MediaStreamTracks from TransceiverImpl
to MediaPipeline, so it's all in the same path.
This lets all MediaStream and MediaStreamTrack APIs consume received tracks
directly after getting exposed to JS without errors. In case privacy is later
requested, consumers that have already been set up must handle this on the fly.
(They do, in specs and impls)
Differential Revision: https://phabricator.services.mozilla.com/D48947
--HG--
extra : moz-landing-system : lando
nsISerialEventTarget is more semantically accurate for these uses, as the
dispatched runnables cannot run in parallel. It also allows us to use
InvokeAsync in future patches, as that function only takes nsISerialEventTarget.
Differential Revision: https://phabricator.services.mozilla.com/D49262
--HG--
extra : moz-landing-system : lando
This patch fixes two things:
1) A potential threading issue in setting and reading the PrincipalHandle for
MediaPipelineReceiveVideo.
2) Plumbs the PrincipalHandle down to the receiving MediaPipelines right from
the start. It hasn't been necessary in the past as initially the principal
handed to a track's constructor is trusted, but it's good form and will help
clarify the situation for the next patch which switches the initial
principal from always-private to mostly-non-private. In most cases this
principal does no longer get updated after the track's been created, so it
helps to have a PrincipalHandle that matches the track's principal.
Differential Revision: https://phabricator.services.mozilla.com/D48946
--HG--
extra : moz-landing-system : lando
The number of channels is available in mAudioFrame in GetAudioFrame so
there is no reason to calculate it after the fact in MediaPipeline.
Differential Revision: https://phabricator.services.mozilla.com/D50934
--HG--
extra : moz-landing-system : lando
The use of select() was leading to crashes when the file descriptor value was
larger than FD_SETSIZE. Recent versions of glibc have checks in the FD_CLR(),
FD_SET() and FD_ISSET() macros that will abort() the program instead of doing
an out-of-bounds access. poll() doesn't have limitations on the file
descriptor values and provides behavior that is otherwise identical to
select() thus solving the problem.
Differential Revision: https://phabricator.services.mozilla.com/D50798
--HG--
extra : moz-landing-system : lando
This ICE candidate telemetry has not been used in a long time and in
addition requires special handling by the telemetry code. It is best
removed.
Differential Revision: https://phabricator.services.mozilla.com/D50656
--HG--
extra : moz-landing-system : lando
The code for handling backwards wraps left shifts num_wrap_ - 1. If
num_wrap_ is zero, this results in a left shift of a negative value which
is undefined behaviour. This modifies the code to avoid the shift at the cost
of an extra multiplication.
Differential Revision: https://phabricator.services.mozilla.com/D49609
--HG--
extra : moz-landing-system : lando
This adds checks for invalid and duplicated rtp extension ids to
JsepSessionImpl. Since the version of webrtc.org we're using does not support
two byte extension ids, ids must be between 1 and 14 inclusive. Duplicated
extension ids are also disallowed by RFC 8285. Passing an invalid extension id
into the webrtc.org code will trigger a release assertion and a browser crash.
Differential Revision: https://phabricator.services.mozilla.com/D48689
--HG--
extra : moz-landing-system : lando
