The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dc8cb3fd1bdc044d37789ddced153515dd7ab6e4

commit dc8cb3fd1bdc044d37789ddced153515dd7ab6e4
Author: yhirano <yhirano@chromium.org>
Date: Mon Jan 16 07:29:03 2017

Mark paint/invalidation/media-audio-no-spurious-repaints.html as flaky

BUG= 681471 
NOTRY=true
TBR=fs@opera.com

Review-Url: https://codereview.chromium.org/2630123004
Cr-Commit-Position: refs/heads/master@{#443854}

[modify] https://crrev.com/dc8cb3fd1bdc044d37789ddced153515dd7ab6e4/third_party/WebKit/LayoutTests/TestExpectations

Assigning to the original author of the test.

Not sure why the bot didn;t pick it up, but fixed by 

Make layout test media-audio-no-spurious-repaints.html pass

The number of invalidations has doubled in some cases. None of the
changes I could see to the MediaControls shadow DOM seem to have
caused this, so I cannot explain why the increase happened. But it
has, and a couple more repaints doesn't seem like a major problem.

TBR=wangxianzhu@chromium.org
BUG= 681471 
Review-Url: https://codereview.chromium.org/2754533002
Cr-Commit-Position: refs/heads/master@{#456855}
Committed: https://chromium.googlesource.com/chromium/src/+/d1df3ad6b707ae3bfff924a4674207e4772cd5fa

The point of the original change was to avoid power regressions due to spurious repaints of a plain audio element. If it's a total fixed number more that's probably okay, but if it's fixed multiple per second then it's probably worth reexamining to see if power usage has changed since this regressed.

I looked back for a cause in the media code and could find none. There's been enormous churn in invalidation code recently so it is probably due to that. We have plenty of checks in place to catch regressions due to those invalidation changes, and any change for this particular scenario will likely show up as a contributor to a larger behavior change.