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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZydwsSE1N0b3BwYWdlQWxlcnRQYXJlbnQiSUNocm9taXVtUGVyZi9hbmRyb2lkLW5leHVzNi9zbW9vdGhuZXNzLnRvdWdoX3BpbmNoX3pvb21fY2FzZXMvZnJhbWVfdGltZXMMCxINU3RvcHBhZ2VBbGVydBjpmhgM,agxzfmNocm9tZXBlcmZyiwELEhNTdG9wcGFnZUFsZXJ0UGFyZW50Il1DaHJvbWl1bVBlcmYvYW5kcm9pZC1uZXh1czYvc21vb3RobmVzcy50b3VnaF9waW5jaF96b29tX2Nhc2VzL2lucHV0X2V2ZW50X2xhdGVuY3lfZGlzY3JlcGFuY3kMCxINU3RvcHBhZ2VBbGVydBjpmhgM,agxzfmNocm9tZXBlcmZyhAELEhNTdG9wcGFnZUFsZXJ0UGFyZW50IlZDaHJvbWl1bVBlcmYvYW5kcm9pZC1uZXh1czYvc21vb3RobmVzcy50b3VnaF9waW5jaF96b29tX2Nhc2VzL21lYW5faW5wdXRfZXZlbnRfbGF0ZW5jeQwLEg1TdG9wcGFnZUFsZXJ0GOmaGAw


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

android-nexus6

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

===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : Uses the activedescendant_changed event received from Blink to fire the right focus event on the browser side.
Author  : nektar
Commit description:
  
1. Changed all <select> based widgets (list box role and menu list popup role) to fire activedescendant_changed events when the current selection changes. This behavior is the same as with ARIA combo boxes and other ARIA-based widgets that can have an active descendant. This means that we now have a uniform way of notifying the browser when the active child of a widget has changed.
2. Modified platform-specific code to fire the focus events on the active descendant when it changes, instead of relying on Blink.
3. Fires a focus event on the whole list or combo box when it collapses to make Windows screen readers enable their virtual cursor again.
BUG= 593646 
R=dmazzoni@chromium.org
TESTED=Jaws NVDA and VoiceOver, browser tests

Review-Url: https://codereview.chromium.org/1899823002
Cr-Commit-Position: refs/heads/master@{#396653}
Commit  : 2c4ec4bed7e28e4f45efe742833dd3a154ac266b
Date    : Sun May 29 01:28:05 2016


===== TESTED REVISIONS =====
Revision         Exit Code  Std Dev  N   Good?
chromium@396649  0          N/A      20  good
chromium@396652  0          N/A      20  good
chromium@396653  1          N/A      20  bad    <--
chromium@396654  1          N/A      20  bad
chromium@396658  1          N/A      20  bad

Bisect job ran on: android_nexus6_perf_bisect
Bug ID: 627470

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests smoothness.tough_pinch_zoom_cases
Test Metric: input_event_latency_discrepancy/input_event_latency_discrepancy
Relative Change: Zero to non-zero
Score: 0.0

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus6_perf_bisect/builds/2306
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9007329885341163360


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=6434993107107840

| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Tests>AutoBisect.  Thank you!

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

nektar@, does that make any sense?

The change that was found in bisecting was reverted and then re-landed:

Landed:    r396563
Reverted:  r396830
Re-landed: r396833

Did the performance issue go away after the revert and then come back when it was re-landed?

It might be worth testing that to confirm that this really was the cause.

I don't see the graphs making that many changes - too much noise - during that revision period:
https://chromeperf.appspot.com/report?sid=433c17846abbe55c5c49dfcb3d26a9f2c2294165056641a7293a491bbe55f381&start_rev=396579&end_rev=396960

We removed data stoppage alerts.