Webkit doesn't seek when readyState is HAVE_METADATA

[tsenart]

Here: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#seeking

Note that it's an error to seek while in readyState HAVE_NOTHING. All other states are valid, including HAVE_METADATA.

Here: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#the-ready-states

Under HAVE_METADATA: "The API will no longer raise an exception when seeking."

Also note in that section that canplay is fired when the readyState is HAVE_FUTURE_DATA.

[eric-carlson]

All true, but the spec also says: http://dev.w3.org/html5/spec/the-iframe-element.html#seeking

If the (possibly now changed) new playback position is not 
in one of the ranges given in the seekable attribute, then 
let it be the position in one of the ranges given in the 
seekable attribute that is the nearest to the new playback 
position.

In the test you set currentTime when seekable() returns an object with no ranges, so the seek time is changed to 0. The spec doesn't mandate that a file be seekable when it reaches HAVE_METADATA.

[yvg]

Tomas: You labeled this issue "reported to vendor" can you include the links to bug reports into your description if they are existing and if not (like Opera) just precise which browsers, thanks.

[eric-carlson]

As written, this issue is about WebKit. In this case the vendor reported the issue to itself: https://bugs.webkit.org/show_bug.cgi?id=72145

[tsenart]

@eric-carlson Then I think this part of the spec left room to interpretation (once again). If all readyState states are valid for seeking, but none is mandatory, then is it up to the implementor to decide which one(s)? In Firefox they make it possible to seek on all valid states and I think that makes sense and doesn't break expectations.

[eric-carlson]

@tsenart - readyState is mostly orthogonal to seek-ability - seekable() is there to allow a script to find out what range(s) are seek-able.

Then I think this part of the spec left room to interpretation (once again)

Yes, and I think this is entirely appropriate. If the spec required specific seekable values for readystate, what would we do with servers that do not support byte-range requests?

[tsenart]

@eric-carlson I understand the use of seekable but perhaps when the metadata is fetched it makes sense to retrieve this information as well. AFAIK on the same HTTP request you do for fetching metadata you can also pass an empty range header Range:. Which will retrieve Accept-Ranges: bytes and Content-Range: bytes 0-1/xxxxxx. This allows you to be seekable right from the HAVE_METADATA state right? If the server doesn't support range requests the seekable attribute should either be empty or the full duration. If the full duration is chosen the seek should happen immediately on currentTime = xxx, the browser should buffer until that point and continue playback.

[kinetiknz]

As @tsenart says, the UA can (in most cases) detect that the media is seekable by inspecting the HTTP response headers. In situations where this is not possible, there does seem to be a gap in the spec--as far as I can tell, the author is forced to poll seekable until the target position is available since there's no event tied directly to updates of the seekable attribute (the progress event is probably the closest thing).

[tsenart]

@eric-carlson ping