[whatwg] Value of media.currentTime immediately after setting

[Eric Carlson]

On Jan 20, 2011, at 12:46 AM, Philip Jägenstedt wrote:

> On Thu, 20 Jan 2011 04:20:09 +0100, Matthew Gregan <kinetik at flim.org> wrote:
> 
>> Hi,
>> 
>> The media seek algorithm (4.8.10.9) states that the current playback
>> position should be set to the new playback position during the asynchronous
>> part of the algorithm, just before the seeking event is fired.  This implies
>> the following behaviour:
>> 
>> 0. Initial load state (currentTime reports 0)
>> 1. currentTime set to 20 by script
>> 2. currentTime continues to report 0
>> 3. Script returns to main loop
>> 4. "seeking" event raised
>> 5. currentTime reports 20 in "seeking" event handler
>> 
>> This is the behaviour in Firefox 4.  In every other browser I tested (Chrome
>> 10, Opera 11, Safari 5, and Internet Explorer 9), the following behaviour is
>> observed:
>> 
>> 2. currentTime immediately reports 20
>> 
>> This doesn't seem to be required by the current wording of the spec (in
>> fact, it seems to be incorrect behaviour), but I think this behaviour is
>> more intuitive, as it seems unusual that currentTime returns to the old
>> value immediately after being set and remains that way until the "seeking"
>> event fires.
>> 
>> Does it make sense to update the seeking algorithm to reflect how
>> non-Firefox browsers are implementing this?  My proposal is, effectively, to
>> take steps 5 through 8 and insert them before step 4.
>> 
>> I've uploaded a testcase to http://flim.org/~kinetik/seek-627139.html if
>> anyone's curious.
>> 
>> Thanks,
>> -mjg
> 
> There have been two non-trivial changes to the seeking algorithm in the last year:
> 
> Discussed at http://lists.w3.org/Archives/Public/public-html/2010Feb/0003.html lead to http://html5.org/r/4868
> 
> Discussed at http://lists.w3.org/Archives/Public/public-html/2010Jul/0217.html lead to http://html5.org/r/5219
> 
> At least we (Opera) just haven't gotten around to updating our implementation yet.
> 
> With that said, it seems like there's nothing that guarantees that the asynchronous section doesn't start running while the script is still running. It's also odd that currentTime is updated before the seek has actually been completed, but the reason for this is that the UI should show the new position.
> 
  In WebKit this happens because currentTime isn't maintained in HTMLMediaElement (modulo the caching added in https://bugs.webkit.org/show_bug.cgi?id=49009), it is whatever the media engine (QuickTime, GStreamer, etc) reports. When currentTime is set the media engine is asked to seek immediately so the asynchronous section may run in parallel to the script, and therefore the seek may actually have completed by the time you check currentTime. 

eric