- From: <bugzilla@jessica.w3.org>
- Date: Fri, 15 Jul 2011 23:10:16 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12267 --- Comment #37 from Robert O'Callahan (Mozilla) <roc@ocallahan.org> 2011-07-15 23:10:15 UTC --- (In reply to comment #35) > What about a script that tries to fast-forward by 5 each time it is invoked. > The script is invoked at t=1, but by the time the script is ready to do the > fast-forward, it's actually at t=7, such that the user actually sees the script > go _backwards_ rather than jumping forwards. This can happen with pretty much any implementation. For example, after reading currentTime perhaps the script is stalled for some reason (GC or whatever) while the video continues to play. Then the script adds 5 and gets a number smaller than the current playback position. If we want to advance the playback position by exactly 5 in a reliable manner, we need new API. > I don't understand why authors would find it intuitive that new Date() is > consistent with reality but video.currentTime or video.readyState is not. None of these features are guaranteed to be consistent with reality in any implementation. In any implementation, by the time you've finished fetching the value of currentTime or readyState, it may no longer reflect reality. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Friday, 15 July 2011 23:10:17 UTC