Setting video.currentTime (seeking) should synchronously update the attribute's value

[domenic]

By @foolip in https://www.w3.org/Bugs/Public/show_bug.cgi?id=28929:

There's a discrepancy between the spec and implementations that I think is unlikely to be resolved in favor of the spec.

https://html.spec.whatwg.org/#dom-media-seek returns early and the only effect that can be observed synchronously is that the seeking attribute is true.

I've tested Chromium, Firefox and IE, and all of them synchronously change the currentTime attribute:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3562

I think the spec should do the same. Either by someone reusing "official playback position" for this purpose, or by introducing a separate "seek position" or similar.

The main problem with the spec as it is is that it makes it harder to write a good UI where seeking look like it has an immediate effect, even if currentTime may be slightly adjusted when the seek has actually finished.

[foolip]

I'm not sure if the spec changed, but it now does require currentTime to immediately start returning the new value. In https://html.spec.whatwg.org/#dom-media-currenttime says:

On setting, if the media element's readyState is HAVE_NOTHING, then it must set the media element's default playback start position to the new value; otherwise, it must set the official playback position to the new value and then seek to the new value.

The official playback position is what currentTime returns.

[estobbart]

The currentTime value says it should be assigned to default playback start position when readyState is HAVE_NOTHING.

On setting, if the media element's readyState is HAVE_NOTHING, then it must set the media element's default playback start position to the new value

But the seeking definition makes no mention of the assignment.
4.8.11.9 step 2

If the media element's readyState is HAVE_NOTHING, return.

Can this be reopened to clarify those definitions?

[domenic]

I think I tried to fix the issue you're mentioning in #7638 but got confused by the review feedback and haven't made progress since. /cc @jernoble

It's also possible you're mentioning a different issue. I honestly am just pattern-matching at this point; I've lost all context on this stuff :(

[estobbart]

The implementations I looked at seem to implement the seek definition, but the language is a bit confusing if you set currentTime to a position when readyState is HAVE_NOTHING, and its getter does not return that default playback start position value, without a change in the readyState.