Bug 1599728 - Create ChangesFront/Actor pair for each target in inspector. r=jdescottes Request a ChangesFront for each target as soon as is becomes available. The on-demand approach in D54725 is abandoned because it introduces a client-server round trip on _every_ CSS mutation operation due to the need to ensure the ChangesActor is instantiated. By awaiting `changesFront.setup()` on every mutation, needless slowdown is introduced after the actor becomes available. Furthermore, the approach in D54725 spreads the knowledge about the ChangesFront in too many places in the codebase, something that will only get worse over time as the ChangesActor gains capabilities to track CSS changes from other sources or supports tracking DOM changes. Differential Revision: https://phabricator.services.mozilla.com/D55945

Bug 1603384 - Update cubeb from upstream to aa63601. r=padenot Differential Revision: https://phabricator.services.mozilla.com/D56872

Merge mozilla-central to autoland. a=merge on a CLOSED TREE

Bug 1601423 - Don't send a postMessage IPC message if the source BC has been discarded. r=farre Differential Revision: https://phabricator.services.mozilla.com/D56615

No Bug, mozilla-central repo-update HSTS HPKP blocklist remote-settings tld-suffixes - a=repo-update r=RyanVM Differential Revision: https://phabricator.services.mozilla.com/D56907

Bug 1601016 - Clarify crash ping docs r=gsvelto Make clear that payload.sessionId belongs to the crashing session, not the assembling session. The TelemetrySessionId crash annotation was never intentionally populated. Differential Revision: https://phabricator.services.mozilla.com/D56831

Bug 1601034 - Only update the conduit in replaceTrack() if the track source changed between camera and non-camera. r=bwc Differential Revision: https://phabricator.services.mozilla.com/D56620

Bug 1601034 - Add a ProcessedMediaTrack layer in MediaPipelineTransmit to handle replaceTrack of ended tracks. r=dminor,padenot Before this patch, if a send audio MediaStreamTrack ended, we ended up not sending anything over the network. If replaceTrack() at that point replaced the ended track with a live one, we'd start sending data again, but the rtp stream would continue from where the previous track ended. Having a gap in audio like that would confuse a receiver's *video* jitter buffer, because it's trying to sync to an audio track that just had a massive amount of "jitter" (it can't tell the difference). This patch fixes this by adding a track layer in MediaPipelineTransmit that remains active for as long as the MediaPipeline is active. Thus if the send audio MediaStreamTrack ends, we continue sending silence over the network, which the receiver can understand. If later replaced, the receiver sees real audio instead of silence and continues gracefully. Differential Revision: https://phabricator.services.mozilla.com/D56619

Bug 1584568 - add an API to construct background task queues; r=KrisWright For some clients, just dispatching tasks to some anonymous background thread is fine. But for other clients, they need to guarantee that dispatched events are executed in dispatch order, or they would like to have some guarantee that functions executing in the background are executing on a particular event target, or both. For such uses cases, we need something a little more sophisticated than simply handing out the `BackgroundEventTarget` `nsThreadManager` is using. Fortunately, we have an abstraction that provides these sorts of guarantees already in `mozilla::TaskQueue`. Since `mozilla::TaskQueue` requires a bit of special care during shutdown, we're not going to hand out new `TaskQueue` objects directly, but will instead hand out `nsISerialEventTarget` wrappers of the newly-created `TaskQueues`. `nsThreadManager` can then take care of shutting down all of the `TaskQueue` objects itself, rather than requiring clients to handle shutdown themselves. Differential Revision: https://phabricator.services.mozilla.com/D47454

Backed out 10 changesets (bug 1599043) for build bustages in nsGlobalWindowOuter.cpp on a CLOSED TREE Backed out changeset 463b815557e4 (bug 1599043) Backed out changeset 7c3f0a58cc6c (bug 1599043) Backed out changeset 1eadd9f5b50e (bug 1599043) Backed out changeset e4ea0d47136b (bug 1599043) Backed out changeset 6b97581c33b6 (bug 1599043) Backed out changeset a68bd2acf5d6 (bug 1599043) Backed out changeset c8ed9c52508c (bug 1599043) Backed out changeset aaf83f7806b4 (bug 1599043) Backed out changeset 0ad30634e416 (bug 1599043) Backed out changeset 68219c132efc (bug 1599043)

Bug 1595775 - Update raptor mobile recordings Q4/2019 r=perftest-reviewers,alexandru.irimovici,AlexandruIonescu Differential Revision: https://phabricator.services.mozilla.com/D53184

Bug 1561715 - Part 1: Remove unused functionality in SchedulerGroup. r=smaug Differential Revision: https://phabricator.services.mozilla.com/D55638

Bug 1599043 - Part 10: Make GeckoView to listen OnContentBlockingEvent on the parent process. r=geckoview-reviewers,agi The GeckoView is listening OnContentBlockingEvent in the content process. As we move the event into the parent process, we have to change it to listen the event in the parent process. This patch also adds a workaround in the test ContentBlockingControllerTest#getLog(). This workaround adds a 500ms delays before we check the ContentBlockingLog. This is needed because there is a delay between the notification of OnContentBlockingEven in the parent process and the actual recording of the log in the content process. This workaround will be no longer needed once we move the log entirely to the parent process (Bug 1599046). Differential Revision: https://phabricator.services.mozilla.com/D56749

Bug 1599043 - Part 9: Set channel matched info in channels in parent process. r=dimi This patch makes the matched info also set into the channels in the parent process. This info is neeced for the ContentBlocking telemetry and GeckoView also relies on it. Differential Revision: https://phabricator.services.mozilla.com/D56748

Bug 1599043 - Part 8: Remove the unnecessary OnContentBlockingEvent event in PBrowser. r=dimi,Ehsan The OnContentBlockingEvent is no longer needed once we make the OnContentBlockingEvent parent only. Differential Revision: https://phabricator.services.mozilla.com/D55788