Further information can be found here: 

https://bugzilla.mozilla.org/show_bug.cgi?id=627139

I've taken the liberty to mark this as critical considering every major browser vendor has implemented a "fixed" version, yet the spec still lists this bizarre behaviour.

I don't think it's that anyone has "fixed" this, it's just that the spec used to say something different. In any case, it important that currentTime be updated to the new value even before we know if it's possible to seek to that position, or the seekbar UI would seem very laggy/jumpy.

@Philip

Thanks for your time! And to clarify, by "fixed" I meant that a workaround was added to accommodate a "desired" behaviour. 


Thanks again, 

Rick



ps. I quoted "desired" to emphasize that this is not the intended spec behaviour, but a logical deviation.

(In reply to comment #3)
> In any case, it important that currentTime be
> updated to the new value even before we know if it's possible to seek to that
> position, or the seekbar UI would seem very laggy/jumpy.

It appears that the spec doesn't do this currently. Setting currentTime invokes seek which changes the "current playback position" async. Getting currentTime returns "current playback position". So getting currentTime immediately after setting it would return the old time per spec.

You can't just set currentTime to the new value, because the new value might be greater than the length of the clip, and in that case you need to warp to the end of the clip, but you might not know that time synchronously. No?

(In reply to comment #6)
> You can't just set currentTime to the new value, because the new value might be
> greater than the length of the clip, and in that case you need to warp to the
> end of the clip, but you might not know that time synchronously. No?

When the position where we actually seek to is know, we just set currentTime to that instead. Possibly currentTime should be clamped to duration synchronously to make it a bit less weird.

It's also quite possible we have different ideas about how this would work if currentTime were only updated asynchronously. If it is updated as soon as it is known to which point it is possible to seek, this should be fairly fast. However, updating it only as the seek that position has succeeded would make the UI look sluggish.

(In reply to comment #6)
> You can't just set currentTime to the new value, because the new value might be
> greater than the length of the clip, and in that case you need to warp to the
> end of the clip, but you might not know that time synchronously. No?


I'm not sure how else to describe the problem that this behaviour causes...

1. Given "video" 

2. Starting at currentTime equals zero;
  
    video.currentTime;
    // 0

3. Set "video"s currentTime to 1 second
    
    video.currentTime = 1;

4. Get "video"s currentTime

    video.currentTime;
    // Could be 0, but we're expecting 1


The only browser that implements the async behaviour without additionally implementing a means to always return the correct currentTime is Firefox 3.6 -- I'v put together the following test case: http://dl.dropbox.com/u/3531958/12541.html which can be run in that browser to illustrate the issue.

We can't set currentTime once only, since some UAs can't know ahead of time if the stream is seekable.

What we _could_ do is have currentTime get set immediately, and then adjust itself asynchronously if the seek is not possible.

That would basically be the same as now except that the attribute does get set straight away. In most cases that would mean it seems synchronous. In cases where seeking to the given time doesn't work, it would mean the attribute changes twice, so you could still find that immediately after setting it it doesn't have the same value in one UA as another. (Then again, that's always going to be true modulo bug 12267.)

At this point, every UA is doing _something_ to ensure that a very close approximation of the expected currentTime is returned when media.currentTime is accessed.

mass-move component to LC1

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: I've made currentTime return the value at the last time the event loop ran, the last time it was set, or the last time the clip was paused, whichever happened last.

Checked in as WHATWG revision r6531.
Check-in comment: Make video.currentTime return a stable value rather than the current value. This lets us make setting this attribute always seem to work, so authors don't find the attribute hasn't changed after they set it.
http://html5.org/tools/web-apps-tracker?from=6530&to=6531

Assume you meant FIXED

Oops, yes. Thanks.