12541 2011-04-22 21:49:26 +0000 <video> Make seeking change the current playback position before going async, then update it to the clamped value ASAP, then try to buffer 2011-08-29 16:38:18 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified All All RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#seeking media, needsAction, needsReview P3 normal --- 12267 1 contributor ian ian kinetik mike philipj public-html-admin public-html-wg-issue-tracking silviapfeiffer1 w3c waldron.rick public-html-bugzilla oldest_to_newest 47612 0 contributor 2011-04-22 21:49:26 +0000 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 47613 1 waldron.rick 2011-04-22 21:52:58 +0000 Further information can be found here: https://bugzilla.mozilla.org/show_bug.cgi?id=627139 48758 2 waldron.rick 2011-05-25 00:07:06 +0000 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. 48800 3 philipj 2011-05-25 08:17:24 +0000 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. 48807 4 waldron.rick 2011-05-25 13:20:52 +0000 @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. 49808 5 zcorpan 2011-06-17 21:49:17 +0000 (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. 49953 6 ian 2011-06-21 05:15:31 +0000 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? 50009 7 philipj 2011-06-21 08:09:10 +0000 (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. 50033 8 waldron.rick 2011-06-21 15:10:40 +0000 (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. 51924 9 ian 2011-08-01 21:19:50 +0000 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.) 51938 10 waldron.rick 2011-08-02 00:56:21 +0000 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. 53239 11 mike 2011-08-04 05:11:48 +0000 mass-move component to LC1 55964 12 ian 2011-08-29 05:28:36 +0000 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. 55968 13 contributor 2011-08-29 07:33:57 +0000 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 55972 14 zcorpan 2011-08-29 10:00:44 +0000 Assume you meant FIXED 55984 15 ian 2011-08-29 16:38:18 +0000 Oops, yes. Thanks.