[Bug 13871] <video> behavior when setting currentTime to current playback position

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13871

--- Comment #2 from Glenn Adams <glenn@skynav.com> 2011-08-23 16:07:03 UTC ---
(In reply to comment #1)
> Why? It seems more predictable if setting currentTime always does the same
> thing. Otherwise scripted UIs that depend on the seeked event being fired after
> currentTime is set would fail at random when the user happens to seek to a time
> that is the same as currentTime.

i notice this when running basic API tests on audio/video element interfaces to
verify mutability of non-readonly IDL attributes, which in this case, basically
reduced to:

e = document.createElement('video');
e.currentTime = e.currentTime;

the second statement results in an INVALID_STATE_ERROR exception because, in
this devolutionary case,

(1) e.controller is null (no controller), and
(2) e.readyState == HAVE_NOTHING

part of the problem here is that "new playback position" is not well defined,
since it can mean "new, different playback position" or "new, not necessarily
different playback position";

i would also note that step (7) under 4.8.10.9, may result in an non-exception
raising abort of the seek without firing a seeking event; this would occur "If
there are no ranges given in the seekable attribute then set the seeking IDL
attribute to false and abort these steps."

i would propose doing the following:

(1) defining "new playback position" as "new, different playback position",
where different means != the current playback position as denoted
(synchronically at set time) by the current value of currentTime;

(2) modify step (1) under 4.8.10.9 to read as follows:

"If the media element's readyState is HAVE_NOTHING, then (1) if the new
playback position is the same as the current playback position, abort these
steps; otherwise (2) raise an INVALID_STATE_ERR exception (if the seek was in
response to a DOM method call or setting of an IDL attribute), and abort these
steps."

-- 
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 Tuesday, 23 August 2011 16:07:10 UTC