I'm going to mark the test as failing in https://codereview.chromium.org/2709393004 ( issue 695459 ), which fixes the discrepancy in current time display and hence reveals the lack of mismatch.

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

commit 792dd3474f7076b0dc33126a90ba4affbaac2c7f
Author: johnme <johnme@chromium.org>
Date: Tue Mar 07 18:50:00 2017

Media Controls timeline: immediately update current time display

Before this patch, dragging the scrubber starting from its current
position would immediately update the current time display, but all
other ways of changing the scrubber (dragging from some other start
position, click on a position, or using the keyboard) would only update
the current time display once the media had finished seeking to the
desired position (which might have to wait for network requests).

This patch removes that distinction, and now immediately updates the
current time display whenever the timeline receives input. This should
make it easier to precisely set the current time.

BUG= 695459 ,699096

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

[modify] https://crrev.com/792dd3474f7076b0dc33126a90ba4affbaac2c7f/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/792dd3474f7076b0dc33126a90ba4affbaac2c7f/third_party/WebKit/Source/core/html/shadow/MediaControlElements.cpp
[modify] https://crrev.com/792dd3474f7076b0dc33126a90ba4affbaac2c7f/third_party/WebKit/Source/core/html/shadow/MediaControlsTest.cpp

foolip@ any chance you can have a look or leave some feedback that could help someone else to have a look?

In some manual testing, it seems like the user-visible behavior is at least still correct, whether playing or paused, dragging the time slider doesn't cause the play/pause button state to flicker.

Attaching the actual results from running the test locally. Because it's an -expected-mismatch.html test, failure means that this is also what the reference looked like.

Deleted: controls-drag-timebar-rendering-actual.png 34.4 KB

	controls-drag-timebar-rendering-actual.png 34.4 KB View Download

In other words, unlike my manual testing, it looks like the icon is in the wrong state in this test.

To investigate, I would see if the early return in MediaControls::updatePlayState() is being taken in this test. If not, that would be a problem. I would check if MediaControlPlayButtonElement::defaultEventHandler() calling updateDisplayType() directly and not going through MediaControls::updatePlayState() could be related.

Marking as available.

FYI, this test just flaked for me in a try-bot run:
https://ci.chromium.org/buildbot/tryserver.chromium.linux/linux_chromium_rel_ng/610900
(The try run is just modifying some GN and waterfall rules, not code).

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

FYI, https://crrev.com/c/840617 removed the lines from TestExpectations that were referencing this bug some time ago. You may be able to close it now (I'm just doing a bulk update, I have not looked at the details of each test).