All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=779799

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=e44e66b8639f46aeec10c62dc8153308ddbec485e57f689b4fe09f64ec1f2f4f


Bot(s) for this bug's original alert(s):

chromium-rel-mac-retina
chromium-rel-mac11
chromium-rel-mac11-pro
chromium-rel-mac12
chromium-rel-mac12-mini-8gb
linux-release

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/149b5eecf80000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/149b5eecf80000

Add field trial testing config for sign-in process isolation.
By alexmos@chromium.org · Wed Oct 25 21:26:19 2017
chromium @ 9cf0ac139cc65890b9e036f704040c8da332d6e3

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Indeed, this seems triggered by enabling sign-in process isolation on the waterfall.  This mode gives a dedicated process to accounts.google.com (see go/sign-in-isolation-experiments).  A related  issue 779475  covers memory overhead, whereas this is about first meaningful paint averages.  

I ran one of the stories locally, long_running_tools_gmail-background from system_health.common_desktop, and see that it first goes to https://accounts.google.com, types in a password, then goes to myaccount.google.com, then to gmail.com, which eventually creates an accounts.google.com subframe.  

Previously, all these navigations stayed in one renderer process, e.g., as seen in the trace at https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/long_running_tools_gmail_background_2017-10-25_14-35-42_70603.html (from Point ID 511506 of
 ChromiumPerf/linux-release/system_health.common_desktop / timeToFirstMeaningfulPaint_avg / long_running_tools /).  After the CL in #3 enabled sign-in process isolation, this is split across two renderer processes, one of which is used for all accounts.google.com frames, and the other for everything else (e.g., in Point ID 511608 trace at https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/long_running_tools_gmail_background_2017-10-25_20-12-26_65309.html).

However, it's very surprising that this would affect time-to-first-meaningful-paint metrics.  Paint-related UMAs from canary/dev trials (see go/sign-in-isolation-experiments) didn't show any statistically significant increase in the paint metrics, including PageLoad.PaintTiming.NavigationToFirstPaint, PageLoad.PaintTiming.NavigationToFirstContentfulPaint, and PageLoad.Experimental.PaintTiming.NavigationToFirstMeaningfulPaint.

It looks like all the metrics referenced in this bug are timeToFirstMeaningfulPaint_avg.  brianderson@ or other perf experts: how exactly is this measured from the traces?  Which page load's meaningful paint is this measuring, given that there are several navigations here?  Could we be pulling metrics from the wrong renderer process, now that there are two of them?  Or simply averaging things differently across two renderers?  

FWIW, I see that https://mail.google.com/mail/ commits at about the same time in both traces, with firstMeaningfulPaintCandidate coming ~6 ms after that, also in both traces.  So I'm inclined to think that this is a problem with how these measurements are produced, likely due to the extra renderer, and not an actual regression in paint times.

+Tim, Kouhei, Ksakamoto for questions related to timeToFirstMeaningfulPaint metrics

C#4 analysis makes sense to me. I think we can WONTFIX this issue.