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

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

--- Comment #4 from Glenn Adams <glenn@skynav.com> 2011-08-24 07:43:16 UTC ---
(In reply to comment #3)
> (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.

sorry, had the logic inverted

> > (2) e.readyState == HAVE_NOTHING
> 
> This will happen regardless of what you set currentTime to.

I'm suggesting that should not be the case, i.e., an exception should not be
raised if the new playback position is not different than the current playback
position. In general, I would say that should hold regardless of the
readyState, but I'm willing to constrain the interpretation to when readyState
is HAVE_NOTHING and the new playback position does not differ.

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

The problem is that the current behavior is not what one would expect. I do not
expect a state exception when there is no difference in new and current
playback position.

By my interpretation a playback position is not a *new* position unless it is
different than the current position. As a consequence, no seek is being
requested. So why incur an exception resulting from an erroneous attempt to
seek to the current position?

-- 
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:43:17 UTC