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

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


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

win-high-dpi

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8973807479867353808

=== Auto-CCing suspected CL author kouhei@chromium.org ===

Hi kouhei@chromium.org, the bisect results pointed to your CL, please take a look at the
results.


=== BISECT JOB RESULTS ===
Perf regression found with culprit

Suspected Commit
  Author : Kouhei Ueno
  Commit : 9a7108cd4dd2cd64fd4d96602c11efee7e85529c
  Date   : Fri Jul 14 11:00:12 2017
  Subject: Remove Document::execute_scripts_waiting_for_resources_task_handle_

Bisect Details
  Configuration: winx64_high_dpi_perf_bisect
  Benchmark    : loading.desktop
  Metric       : timeToFirstMeaningfulPaint_avg/pcv1-warm/IndiaTimes
  Change       : 13.18% | 879.961833333 -> 995.920333333

Revision             Result                  N
chromium@486715      879.962 +- 54.9471      6      good
chromium@486724      853.675 +- 43.5832      6      good
chromium@486725      844.703 +- 21.186       6      good
chromium@486726      983.436 +- 34.9322      6      bad       <--
chromium@486728      996.96 +- 28.6631       6      bad
chromium@486732      991.154 +- 35.9586      6      bad
chromium@486749      1006.08 +- 77.6331      6      bad
chromium@486783      995.92 +- 32.6187       6      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=IndiaTimes loading.desktop

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8973807479867353808


For feedback, file a bug with component Speed>Bisection

Super surprised by this change, but I could repro this locally.
Let me revert the CL

tzik@ has came up w/ very plausible hypothesis.

Before this CL, another invocation of the PostCancellableTask actually cancelled the previously post task.
This CL will not cancel the previously post task thus will go ahead and run Document::ExecuteScriptsWaitingForResources at its originally scheduled timing, delaying the FMP.

---

I'll continue w/ the revert since its near branch cut.
I don't think the current behavior of postponing the task run is correct, but we need to fix the scheduler so that it would still cycle the rendering pipeline earlier than running this task.

The hypothesis sounds very plausible.  Going with the revert until branch cut sounds good to me too.

Just checking, did this get reverted?

Just to double check - this was reverted, wasn't it?

This was reverted in:
https://chromium.googlesource.com/chromium/src.git/+/94086bc3919179636c14efa2c0fba1ff3db34e7f