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

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


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

chromium-rel-mac11-air
chromium-rel-mac12
chromium-rel-win7-dual

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

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

Apply fixed-position scroll offset if the containing block is ancestor. by chrishtr@chromium.org
https://chromium.googlesource.com/chromium/src/+/edc066c316b24fb3dea226ae6c1c5c1fdee062c3

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

The first graph on the "all pages regressed" page points at this range:

https://chromium.googlesource.com/chromium/src/+log/b8a0255907b5bea51f10c0caecaced971b0045e1%5E..1893a97da066e0f8408172aa3977d6b27b3087d1?pretty=fuller&n=1000

which includes this patch:

https://chromium.googlesource.com/chromium/src/+/e931d2aecb4d72946962e57e7e1586668071b504

which introduced the bug which my patch fixed. Same goes for other graphs.

Therefore my patch is just bringing things back to normal.

+cc pdr to add any commentary, but a similar set of graphs moved in the opposite
direction when he landed his first patch.

"points at" -> means goes from the value after my patch to the value before my
patch.

Yes, these graphs are just returning to baseline after my incorrect patch.