This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12541 - <video> Make seeking change the current playback position before going async, then update it to the clamped value ASAP, then try to buffer
Summary: <video> Make seeking change the current playback position before going async,...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords: media, needsAction, needsReview
Depends on: 12267
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-22 21:49 UTC by contributor
Modified: 2011-08-29 16:38 UTC (History)
9 users (show)

See Also:


Attachments

Description contributor 2011-04-22 21:49:26 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html
Section: http://www.whatwg.org/specs/web-apps/current-work/#seeking

Comment:
The asynchronous behaviour of steps 5-12 causes unexpected, unwanted behaviour
when getting the currentTime immediately after it's been set.
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/029961.html

Posted from: 75.150.66.249
User agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.0 Safari/534.30
Comment 1 Rick Waldron 2011-04-22 21:52:58 UTC
Further information can be found here: 

https://bugzilla.mozilla.org/show_bug.cgi?id=627139
Comment 2 Rick Waldron 2011-05-25 00:07:06 UTC
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.
Comment 3 Philip J├Ągenstedt 2011-05-25 08:17:24 UTC
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.
Comment 4 Rick Waldron 2011-05-25 13:20:52 UTC
@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.
Comment 5 Simon Pieters 2011-06-17 21:49:17 UTC
(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.
Comment 6 Ian 'Hixie' Hickson 2011-06-21 05:15:31 UTC
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?
Comment 7 Philip J├Ągenstedt 2011-06-21 08:09:10 UTC
(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.
Comment 8 Rick Waldron 2011-06-21 15:10:40 UTC
(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.
Comment 9 Ian 'Hixie' Hickson 2011-08-01 21:19:50 UTC
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.)
Comment 10 Rick Waldron 2011-08-02 00:56:21 UTC
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.
Comment 11 Michael[tm] Smith 2011-08-04 05:11:48 UTC
mass-move component to LC1
Comment 12 Ian 'Hixie' Hickson 2011-08-29 05:28:36 UTC
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.
Comment 13 contributor 2011-08-29 07:33:57 UTC
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
Comment 14 Simon Pieters 2011-08-29 10:00:44 UTC
Assume you meant FIXED
Comment 15 Ian 'Hixie' Hickson 2011-08-29 16:38:18 UTC
Oops, yes. Thanks.