W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > July 2011

[Bug 12267] <video> Make video state transitions happen in the same task as firing events

From: <bugzilla@jessica.w3.org>
Date: Fri, 15 Jul 2011 23:10:16 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QhrWS-0003tn-Cn@jessica.w3.org>

--- 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:55 UTC