Backed out 6 changesets (bug 1159042) for crashtest failures. CLOSED TREE Backed out changeset fe77c09dee31 (bug 1159042) Backed out changeset db0e173a6ed2 (bug 1159042) Backed out changeset 080b9ceee8ec (bug 1159042) Backed out changeset 6a5191742ca1 (bug 1159042) Backed out changeset 3a86c3e65d44 (bug 1159042) Backed out changeset 845bc8316b05 (bug 1159042)

Bug 1503074 - Only touch the FX_TAB_SWITCH_COMPOSITE_E10S_MS stopwatch when we have actually started it in the past Differential Revision: https://phabricator.services.mozilla.com/D12966

Bug 1508044 - Part 4: Make nsChannelClassifier use nsContentUtils::IsThirdPartyWindowOrChannel() in order to avoid having duplicated logic r=francois Depends on D12853 Differential Revision: https://phabricator.services.mozilla.com/D12854

Bug 1508044 - Part 3: Ensure that the third-party checks performed on channels in nsContentUtils::IsThirdPartyWindowOrChannel() follow the same logic as those performed in nsChannelClassifier r=francois Depends on D12852 Differential Revision: https://phabricator.services.mozilla.com/D12853

Bug 1508044 - Part 2: Check the return values of mozIThirdPartyUtil::IsThirdPartyFoo() in nsContentUtils::IsThirdPartyWindowOrChannel() r=francois Differential Revision: https://phabricator.services.mozilla.com/D12852

Bug 1510085 - Update webrender to commit 05bdcae134d73aca7bb48358e91de1f8aef27773 (WR PR #3354). r=kats https://github.com/servo/webrender/pull/3354 Differential Revision: https://phabricator.services.mozilla.com/D13029

Bug 1510084 - Update webrender to commit 35027d93aded8c0a7887dadc8aef5e393171e802 (WR PR #3348). r=kats https://github.com/servo/webrender/pull/3348 Differential Revision: https://phabricator.services.mozilla.com/D13028

Bug 1510082 - Update reftest annotations for changes in WR PR #3346. r=kats Depends on D13026 Differential Revision: https://phabricator.services.mozilla.com/D13027

Bug 1510082 - Update webrender to commit e2e52b1145ad959191c0612edd41b0b189cf6b59 (WR PR #3346). r=kats https://github.com/servo/webrender/pull/3346 Differential Revision: https://phabricator.services.mozilla.com/D13026

Bug 1510078 - Update webrender to commit f450af9277e2474e2a2a2c1358689ca9486e2a09 (WR PR #3345). r=kats https://github.com/servo/webrender/pull/3345 Differential Revision: https://phabricator.services.mozilla.com/D13025

Bug 1509488 - Use keydown handler instead of <key> for Shift+Ctrl+Tab. r=jaws Differential Revision: https://phabricator.services.mozilla.com/D12744

Bug 1487287 - Move child process launch off the I/O thread. r=mccr8 Launching processes takes enough time that we should avoid blocking the parent process's IPC I/O thread for it; it's less bad for responsiveness than blocking the main thread, but it's not good. On Windows we need to use a dedicated thread, because the sandbox isn't thread-safe and it asserts that the same thread is used for every launch. Otherwise, a thread pool is used. Depends on D8945 Differential Revision: https://phabricator.services.mozilla.com/D8946

Bug 1487287 - Set profiler env vars in child processes without side-effecting the parent process. r=mstange We can directly set environment variables for the child process on all platforms now, instead of changing the parent's environment and inheriting the changes. This simplifies memory management, but more importantly it's necessary for thread safety to allow launching processes from a thread pool. Depends on D8944 Differential Revision: https://phabricator.services.mozilla.com/D8945

Bug 1474991 - Add new and improved performance telemetry for child process launching. r=mccr8,mconley,janerik This patch adds some telemetry histograms: * CONTENT_PROCESS_LAUNCH_IS_SYNC - boolean, true if the content process was launched synchronously (blocking the main thread) * CONTENT_PROCESS_SYNC_LAUNCH_MS - the time consumed by sync launch; the main thread will be busy or blocked for this entire time * CONTENT_PROCESS_LAUNCH_TOTAL_MS - the total time elapsed from the start of async content process launch until the launch promise is resolved and the ContentParent can be sent IPDL messages * CONTENT_PROCESS_LAUNCH_MAINTHREAD_MS - the time consumed on the parent process main thread during async content process launch; typically this is due to ContentParent::Init. * CHILD_PROCESS_LAUNCH_MS - for any kind of Gecko child process (including plugins, GPU, etc.), the time taken in the common process launch code (which is run off-main-thread) The probes restricted to async content process launch don't have "async" in the name because that will eventually become the only kind of content process launch. Depends on D8943 Differential Revision: https://phabricator.services.mozilla.com/D8944

Bug 1446161 - Asynchronously launch preallocated content processes using MozPromise. r=mccr8 There are several layers to this patch: 1. GeckoChildProcessHost now exposes a promise that's resolved when the process handle is available (or rejected if launch failed), as a nonblocking alternative to LaunchAndWaitForProcessHandle. 2. ContentParent builds on this with the private method LaunchSubprocessAsync and the public method PreallocateProcessAsync; synchronous launch continues to exist for the regular on-demand launch path, for the time being. 3. PreallocatedProcessManager now uses async launch, and handles the new "launch in progress" state appropriately. Depends on D8942 Differential Revision: https://phabricator.services.mozilla.com/D8943

Bug 1446161 - Remove the earlier attempt at async launch. r=spohl,mccr8 The first attempt at async launch tried to hide the asynchrony inside IPC, by making the process seem to be launched enough to construct new channels and send it messages, and lazily blocking on the pid/handle. Unfortunately, in practice we wind up needing the pid/handle immediately, and this requirement is too deeply embedded in IPC for that to be viable. (The alternative that will be used instead -- exposing process launch via an explicitly asynchronous promise interface -- is made simpler by Project Fission's upcoming rewrite of how the DOM requests new content processes.) Depends on D8941 Differential Revision: https://phabricator.services.mozilla.com/D8942

Bug 1446161 - Remove CONTENT_PROCESS_LAUNCH_TIME_MS telemetry. r=mconley,chutten The CONTENT_PROCESS_LAUNCH_TIME_MS histogram is currently gathering times from two different spans of the launch process and mixing them together; it's at best a rough approximation of "launch time". In addition, with async launch we'll want to gather different metrics than for sync launch (see comments on bug 1474991). So I'm removing this histogram and will replace it with separate sync and async metrics in bug 1474991; I intend to land both bugs' patches at or near the same time, so we won't have a gap in getting some kind of data. Depends on D8940 Differential Revision: https://phabricator.services.mozilla.com/D8941

Bug 1496608 - Don't leak GeckoChildProcessHost when a content process fails to launch. r=mccr8 Depends on D8939 Differential Revision: https://phabricator.services.mozilla.com/D8940

Bug 1488993 - Fix PreallocatedProcessManager blocker management (v2). r=mconley,smaug This fixes/adjusts two things about how content process preallocation is blocked: 1. Processes aren't registered as blockers until after they launch successfully. The main goal is to not leak a blocker if launch fails, but we don't need to block *while* launching synchronously, because this all happens on the main thread. 2. Preallocated processes themselves aren't blockers. The main goal here is so that async preallocation doesn't need extra complexity to avoid being blocked by itself when launch completes. This mostly doesn't affect actual behavior, because we currently support at most one preallocated process. The difference is the window from when the process is sent its first PBrowserConstructor until when it's next idle, where there is now no longer a blocker, but this seems to be relatively short (~100ms) and we don't even try to launch a new process until at least 1s + an idle runnable. This patch does not explicitly RemoveBlocker in ActorDestroy like the first attempt did, because it's unnecessary: this is handled in the ipc:content-shutdown observer. Differential Revision: https://phabricator.services.mozilla.com/D8939

Bug 1159042 - p6. Use NS_FRAME_DYNAMIC_REFLOW_ROOT - r=dholbert Differential Revision: https://phabricator.services.mozilla.com/D9492