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

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


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

android-nexus6

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

=== BISECT JOB RESULTS ===
Bisect was unable to run to completion

Error: INFRA_FAILURE

The bisect was able to narrow the range, you can try running with:
  good_revision: c5089743aa5194a4ae3f575fb54e73e20e3d22ff
  bad_revision : 427067e8f07be7f2e7cc8ab531e53494bcd9d5fb

If failures persist contact the team (see below) and report the error.


Bisect Details
  Configuration: android_nexus6_perf_bisect
  Benchmark    : media.mobile
  Metric       : time_to_video_play_avg/mse.html?media_aac_audio.mp4_h264_video.mp4_waitForPageLoaded_true

Revision             Result                  N
chromium@522083      131.442 +- 10.5541      14      good
chromium@522131      131.73 +- 3.45552       9       good
chromium@522155      131.51 +- 9.61393       9       good
chromium@522161      140.507 +- 3.58905      6       bad
chromium@522167      137.222 +- 5.98992      6       bad
chromium@522178      136.52 +- 9.9555        9       bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=mse.html.media.aac.audio.mp4.h264.video.mp4.waitForPageLoaded.true media.mobile

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

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


For feedback, file a bug with component Speed>Bisection

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

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

Hi mdjones@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 : Matthew Jones
  Commit : 427067e8f07be7f2e7cc8ab531e53494bcd9d5fb
  Date   : Wed Dec 06 19:20:58 2017
  Subject: Simplify and add tests for the progress bar

Bisect Details
  Configuration: android_nexus6_perf_bisect
  Benchmark    : media.mobile
  Metric       : time_to_video_play_avg/mse.html?media_aac_audio.mp4_h264_video.mp4_waitForPageLoaded_true
  Change       : 6.26% | 132.876011111 -> 141.196

Revision             Result                  N
chromium@522083      132.876 +- 11.719       9       good
chromium@522131      131.112 +- 6.95216      6       good
chromium@522155      130.296 +- 5.25025      6       good
chromium@522158      131.685 +- 5.1473       9       good
chromium@522160      131.295 +- 12.7091      14      good
chromium@522161      137.698 +- 9.47844      9       bad       <--
chromium@522167      140.018 +- 5.92913      6       bad
chromium@522178      141.196 +- 8.24127      6       bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=mse.html.media.aac.audio.mp4.h264.video.mp4.waitForPageLoaded.true media.mobile

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

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


For feedback, file a bug with component Speed>Bisection

I'll take a look. The only obvious culprit is the fact that the indeterminate animator runs until the page finishes loading. However, that case requires the animation start in the first place and has an early return to prevent needless updates to the progress bar. I'll update if I find anything.

Any update on this issue? Thanks.

I'm still looking into the issue, but this seems suspicious to me since the only warning triggered is one that runs media, which my patch should affect (I'd expect other page loads to see the same performance hit). Is there any way we can rerun the bisect?

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

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

Suspected Commit
  Author : Matthew Jones
  Commit : 427067e8f07be7f2e7cc8ab531e53494bcd9d5fb
  Date   : Wed Dec 06 19:20:58 2017
  Subject: Simplify and add tests for the progress bar

Bisect Details
  Configuration: android_nexus6_perf_bisect
  Benchmark    : media.mobile
  Metric       : time_to_video_play_avg/mse.html?media_aac_audio.mp4_h264_video.mp4_waitForPageLoaded_true
  Change       : 4.96% | 131.864583333 -> 138.408883333

Revision             Result                  N
chromium@522083      131.865 +- 4.32643      6      good
chromium@522131      130.155 +- 2.34185      6      good
chromium@522155      131.306 +- 4.96154      6      good
chromium@522158      129.96 +- 5.72358       6      good
chromium@522160      131.86 +- 7.23761       6      good
chromium@522161      138.921 +- 3.35112      6      bad       <--
chromium@522167      138.964 +- 7.07176      6      bad
chromium@522178      138.409 +- 4.35444      6      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=mse.html.media.aac.audio.mp4.h264.video.mp4.waitForPageLoaded.true media.mobile

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

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


For feedback, file a bug with component Speed>Bisection

Rerunning the bisect pointed to the same CL. So I think it should worth some investigation. Thanks.

I've been debugging this on the bots, it looks like the indeterminate animation may be updating too frequently. I set the animation to never trigger and the issue was fixed. I'll update when I have more info.

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

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

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

After going through the code a number of times, I have been unable to pin-point what would be causing this issue. I'd expect any perf regression caused by the progress bar to impact every page load metric (since it shows on literally every page) instead of just media. The source of the issue seems to revolve around the indeterminate animation (which is a known perf regression anywhere it triggers, but does benefit the user).

Marking as WontFix as per @dougman's request. We can re-open this issue if we find this needs to be investigated further. Likely we will need to discuss further delaying the triggering of the animation.