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

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


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

linux-perf

rendering.desktop - Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

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

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

Propagate window positions down OOPIF chains by kenrb@chromium.org
https://chromium.googlesource.com/chromium/src/+/ee24be2aa0c578cf371f64dea1b887635959c833
258.7 → 336.5 (+77.82)

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

Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

Sorry for taking so long in having a look at this.

Is it certain that my CL caused that perf regression? It was fixing a functional regression that was causing <select> element menus to sometimes appear in the wrong position. This could potentially cause more IPC messages to OOPIFs while a top-level page is scrolling, but that is hard to avoid while still be correct.

The graphs have moved after this regression... one way to find out is to do a test CL that undoes the propagation and run a pinpoint job using the appropriate https://chromium.googlesource.com URL. If this fixes a bug and the regression is deemed acceptable (not sure if this CL was blamed to other regressions or not) then feel free to WontFix.