Proposed fix:
https://chromium-review.googlesource.com/c/585244/

Attaching video of behavior with fix.

Deleted: seek_after.mp4 1.7 MB

	seek_after.mp4 1.7 MB View Download

agdoug@amazon.com, I am using chrome 61.0.3162.3 on Android. I don't repro this bug.
Every time FF button is tapped, timestamp move forward for 0:05. 
I also tried stable chrome build 59.0.3071.125, get the same behavior.
The scrubber thumb and timestamp update is slow, it takes a moment after tap FF button though. But it does change. If you tap FF button too fast, it may seems not update simultaneously with tap action.
Please report what you see when tap FF button slowly.

Hi there,

This bug is precisely about tapping it quickly and it not getting updated simultaneously, hence "repeated rapid seek requests".
Eventually it catches up but until then it is difficult to tell where you have seeked to if you attempt to seek a few times rapidly (e.g. in a scenario where you know you want to seek to near the end of the video you wouldn't want to have to tap, wait for update, check time, tap again, wait again, etc.).

+media ui folks to weigh in. We don't commit the seek until we actually finish it, so this is WAI, whether or not it should be that way is another question.

Hi Dale,

Thanks for pulling in the media UI folks. 

The original behavior did appear to be working as intended but seemed like it could be improved. The proposed fix changes the behavior to be more in line with how I would expect things to look while seeking but it's always possible there's some reason why this wouldn't be desirable. 

Additionally, the proposed fix also forces the media controls to show while seeking which is related to the overall seeking experience but not necessarily tied to updating the time indicators immediately. Just wanted to bring that up while we're discussing this media UI change. I think it makes sense but again, maybe Chromium disagrees.

Thanks for taking a look.
Alec

give to ericde@ our PM to decide if this is a valid feature request or should behave as is. 

I'm sure you all fully understand the issue, but I just wanted to highlight the use case where I first encountered this: users with media keyboards that have a FF/RW key on them (e.g. Android + bluetooth media keyboard).

If the website has media session handlers for seek forward/backward and the user holds down the FF or RW key then seek requests are made rapidly but the user will not be able to tell where they have seeked to (and thus won't know when to release the FF/RW key).

In the attached videos, I used buttons on a test page so you can easily see when they are pressed but the media keyboard usecase is more realistic for creating rapid seek requests.

over to hbengali@ to triage.

Maybe the right solution here is to update the UI immediately, but have some sort of delay before the player attempts to start playback, thus preventing new segment/range requests from firing multiple times as a user attempts to rapidly seek?

+dahlke@, +mlamouri@ for their input.

dahlke@, assigning to you since it's pending your input.

+rachelis and amyroberts from UX

agdoug@, thanks for providing all the details. The use case and issue is clear. 

All, the playback time is getting more prominence in the updated media controls as a way to help users seek when we cannot provide thumbnails or real-time updating of the video frames. Having that time be very responsive to the user input is key to the success of that approach. I would like to see us fix this if possible. Throttling the actual video update, so we aren't continuously making unnecessary requests seems like a wise idea, but I would like the eng team to chime in. 

Assigning this to beccahughes@ since they are working on the updated media controls.

Now that modern media controls is resolved (https://bugs.chromium.org/p/chromium/issues/detail?id=761305), could we revisit this issue?

For our fork of Chromium, we've been maintaining a patch for this but it would be nice if it could land in Chromium so I wouldn't have to worry about hitting merge conflicts while pulling in upstream commits.

Over time I've updated it to work with the modern controls refactor, but I ran into a small snag with a couple tests (HTMLMediaElementWithMockSchedulerTest::OneTimeupdatePerSeek and PeriodicTimeupdateAfterSeek) where the change causes timeupdate to get called twice instead of once because the media controls now begin scrubbing when the 'seeking' event is fired, which pauses the video and causes a timeupdate event to be fired.

I'll attach updated before + after videos. The media in these videos is controlled via a bluetooth controller via media session action handlers for 'seekforward' and 'seekbackward'. The FF/RW buttons light up orange every time one of these media session events is handled.

I'll also post a new CL with the latest patch in a moment - let me know what you think. Thanks!

Deleted: modern_seek_before.mp4 6.4 MB

	modern_seek_before.mp4 6.4 MB View Download

Updated proposed fix:
https://chromium-review.googlesource.com/c/chromium/src/+/1274945