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

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

From: <bugzilla@jessica.w3.org>
Date: Wed, 24 Aug 2011 07:02:27 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Qw7Tn-00014w-5I@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13871

--- Comment #3 from Philip Jägenstedt <philipj@opera.com> 2011-08-24 07:02:25 UTC ---
(In reply to comment #2)

> 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

This seems wrong, it will throw INVALID_STATE_ERROR if it *has* a controller.

> (2) e.readyState == HAVE_NOTHING

This will happen regardless of what you set currentTime to.

Neither of the above are related to what the old or new currentTime is.

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

It's well defined, it just doesn't make a difference between these two cases.

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

Right, for a resource which is completely unseekable no seeked event will be
fired. However, that will be the case regardless of what you set currentTime
to, so that won't cause scripts to fail at random.

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

It seems like this could only work when the media is paused. If it is playing,
currentTime is continuously changing so if you check for equality in step x, it
will no longer be equal in step x+1.

> (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."

My main question is still "why?" What problem is being solved?

-- 
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 Wednesday, 24 August 2011 07:02:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:17 UTC