Skip to content

Webkit doesn't seek when readyState is HAVE_METADATA #28

tsenart opened this Issue Nov 14, 2011 · 8 comments

4 participants

tsenart commented Nov 14, 2011


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


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.


All true, but the spec also says:

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 

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.

SoundCloud member
yvg commented Nov 15, 2011

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.


As written, this issue is about WebKit. In this case the vendor reported the issue to itself:

tsenart commented Nov 15, 2011

@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.


@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 commented Nov 15, 2011

@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.


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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.