The changed-files are updated by running `sh update.sh <upstream-path>`
with moz-libsoundtouch.patch applied.
Differential Revision: https://phabricator.services.mozilla.com/D49029
--HG--
extra : moz-landing-system : lando
Correct the format of the diff for AAFilter.cpp so the update-script can
work.
Differential Revision: https://phabricator.services.mozilla.com/D49028
--HG--
extra : moz-landing-system : lando
This happens very frequently in rr runs, and may explain some
intermittents we've seen in automation.
Differential Revision: https://phabricator.services.mozilla.com/D54520
--HG--
extra : moz-landing-system : lando
Removes calls to the win32k API.
Replaces hardware and event timers with waitable timers.
Removes handling various task objects through the thread message queue.
Removes ProcessQueuedMessages, CancelTimers functions.
Adds event handle for stopping the TaskQueue thread.
Adds ReplyHandler class as an in between for TaskQueue objects to post tasks to each other without worrying if the other TaskQueue remains valid.
Adds rtc::CriticalSection's for timer_tasks_.
Removes ThreadState scoped class.
Differential Revision: https://phabricator.services.mozilla.com/D43480
--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
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
Chun-Min Chang
Dan Minor
june wilde
Nico Grunbaum
Brindusan Cristian
Noemi Erli
Sylvestre Ledru
Jed Davis
Landry Breuil
Byron Campen [:bwc]
Andreas Pehrson