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

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


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

chromium-rel-win7-dual
chromium-rel-win7-x64-dual
chromium-rel-win8-dual

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

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

Use unique_ptrs in MessagePumpLibevent::FileDescriptorWatcher. by thestig@chromium.org
https://chromium.googlesource.com/chromium/src/+/21476d052ea2fce4cc0e06826afd25ce0bff942b

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

base/message_loop/message_pump_libevent.cc is not built on Windows. Changes to it can't possibly affect performance on Windows.

WontFix-ing because this recovered, but cc-ing tdresser since the eqt metric is pretty noisy here; pinpoint reproduced a regression at a CL that isn't built into Windows. (Note we re-use binaries, so compile differences between binaries are consistent for pinpoint)

Some of the EQT graphs look pretty non-noisy and non-recovered.

It's weird how stable the graph can look, and we can still have pinpoint unable to repro.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/159818d0c40000

Yea I feel like bisects have been behaving very differently to graphs recently... not sure if it's a problem with the machines or the metrics though. Let's retry a bisect.

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

Add components_perftests to chromium.perf.json by csharrison@chromium.org
https://chromium.googlesource.com/chromium/src/+/a33ba78b7502b9bfad38cfd48fa5f8ff698bac79

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

Is it common for adding some perf tests to cause regressions in other benchmarks? That seems strange, so I'm not quite sure if the bisect is correct.

Moving myself to cc

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12b4d158c40000

Ok last try...

😿 Pinpoint job stopped with an error.
https://pinpoint-dot-chromeperf.appspot.com/job/12b4d158c40000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12eb4592c40000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12f5ad02c40000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/120cbefcc40000

For some reason this was only bisected on EQT but there are first paint regressions too. Trying to bisect some of those.

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/12eb4592c40000

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

Get navigation info without using FrameLoader snapshots by dproy@chromium.org
https://chromium.googlesource.com/catapult/+/5d35a2c7122c1ac4a9a37e7743a19f628f25a38b

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

This is weird. Before my change, FMP was being calculated for "https://myaccount.google.com/?pli=1" - that feels wrong. After the change, FMP is now being calculated for "https://mail.google.com/mail/", which feels more correct. Maybe some benchmark owner has more context here? 

 Issue 831089  might be relevant. 

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/12f5ad02c40000

This root cause of this issue is similar to  Issue 827145 . Adding Ned and Kouhei. 

friendly ping from today's perf sheriff

Ping! This bug has been flagged as stale by Chrome Speed Metrics bug triage, and it has an owner. Any update on this issue?

Based on c#20, I'm going to say the metric was wrong before and is correct now. Marking as WontFix.