Able to reproduce the issue on the latest canary(59.0.3054.0) and the latest stable(57.0.2987.110) on Windows-10, Mac OS 10.12.3 and Linux Ubuntu 14.04.

Regressed in M-56.

Last good build: 56.0.2920.0
First bad build: 56.0.2922.0 (no 56.0.2921.0 available)

Changelog:
==========
https://chromium.googlesource.com/chromium/src/+log/56.0.2920.0..56.0.2922.0?pretty=fuller&n=10000

Bisect script isn't invoking any good builds even on adjusting the range hence unable to provide the bisect per revision.

Not sure but manually inspecting seeing few media related changes by mlamouri@ in the above regression range.

mlamouri@: Could this be related to https://codereview.chromium.org/2501523003. If not, appreciate your help in investigating this further.

Thank you!

johnme@, can you take a look?

Thanks for reporting this, I can confirm in 56.0.2924.87 Ubuntu that there's definitely a bug that causes us to fail to update the visible frame of a video sometimes (even though $v.currentTime reports the correct value).

I made a slightly reduced testcase at: https://jsbin.com/yemusaq (well, not so much reduced, as linearized, to make it a little clearer what order things happen in).

As you pointed out, it's quite a subtle bug, as any of the following minor changes to the testcase cause it to stop failing:
- waiting less than ~25 seconds [remainPausedTime]
- seeking programmatically rather than from a click handler [autoSeek=true]
- not calling $v.pause() before seeking [pauseBeforeSeekAhead=false]
- making the initial calls to $v.play() and $v.pause() from a click handler instead of from the `canplay` handler

(I recommend testing in a clean incognito session, in case caching affects this).

+hubbe@, can you look at this? I suspect it might be a network issue because it's related to seeking and the cache seems to have an impact.

It's unclear if johnme@'s reduced test case is working as expected as it's working 100% on stable/beta/dev/trunk for me. I did not try the initial test case.

Feel free to bounce this back to johnme@ or I but I want to make sure that it's not an obvious networking issue before we spend more time investigating :)

I am also not able to reproduce the issue with johnme@'s test case.

I'm on vacation this week. I scanned through the changelog though, which seems to be oddly low on buffering changes and/or changes by me.  I suspect that this is somehow related to the idle suspension, which jbauman enabled in this range, so I'm assigning this to jbauman and also adding sandersd to see if they can take a look this week. (If not, feel free to assign back to me.)

I am able to reproduce using the original codepen on M56 but not on ToT. I cannot reproduce using the jsfiddle (#6) on either version.

Erik: Are you able to reproduce this issue with a Canary version of Chrome?

Just now tested my original codepen on Version 57.0.2987.133 (64-bit) on osX 10.12.4
and reproduced the bug.

Can you please test in a Canary version, which should be M59? Thanks.

Sorry.  Just tested on Version 59.0.3067.0 canary (64-bit) and the bug appears to be gone!

Is the bug reproducible on Chrome Beta (58.*)? If it's only a bug on stable, we should probably ignore it but if it happens on Beta, we might want to consider sending a fix before the branch.

I am able to reproduce on M58.

Initial reports are on Mac and Linux, so not related to my enabling of idle suspension on windows.

This seems to be fixed. Please re-open or leave I comment if I misunderstood.

Yes, appears to be fixed, thank you.