This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12547 - <video> Expose the /most recently reported readiness state/ as MediaController.readyState
Summary: <video> Expose the /most recently reported readiness state/ as MediaControlle...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, a11ytf, media
Depends on: 9452
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-23 03:17 UTC by John Foliot
Modified: 2012-06-05 00:15 UTC (History)
12 users (show)

See Also:


Attachments

Description John Foliot 2011-04-23 03:17:33 UTC
The MediaController object currently does not expose an aggregate view of the readyState of the slave media elements. It is, however, impossible for a developer to reliably aggregate the readyState from the individual slave media elements, since their states may continue to change. The media framework inside the UA is the only place where such aggregation is sensibly possible.

Therefore, we request addition of a readyState IDL attribute on the MediaController object.
It must represent the minimum state that all the slave media elements have achieved.
Comment 1 Philip Jägenstedt 2011-04-23 09:35:42 UTC
The suggestion 

If it is really just the minimum of all slave media elements, this is actually trivial to achieve using scripts and does not need to be
Comment 2 Philip Jägenstedt 2011-04-23 09:46:08 UTC
Oops, slipped on the submit button. Again:

The suggestion says "the UA is the only place where such aggregation is sensibly possible", but also that the aggregate readyState is simply the minimum of all the slave elements. This would actually be trivial to do with scripts, having the UA do it doesn't provide any benefit.

More generally, readyState on HTMLMediaElement is only really useful in two situations:

1. When the state after an event is ambiguous, such as in the waiting event.

2. When attaching controls to an already playing media element and need to bring them up to speed.

Both cases are somewhat advanced uses of the API, and I really think it wouldn't be much to ask in such a situation that the minimum of the readyStates be calculated by scripts.
Comment 3 Laura Carlson 2011-04-29 12:10:31 UTC
Per Martin Kliehm "although the bug-triage sub-team didn't decide on these bugs yet, John mentioned in yesterdays teleconference [1] that there are several important multimedia related bugs where he'd like to add the a11ytf keyword. There was approval". 

[1] http://www.w3.org/2011/04/28-html-a11y-minutes.html
Comment 4 Ian 'Hixie' Hickson 2011-06-16 21:53:25 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: see comment 2
Comment 5 Michael[tm] Smith 2011-08-04 05:16:49 UTC
mass-move component to LC1
Comment 6 Jer Noble 2011-11-02 22:55:05 UTC
(In reply to comment #2)
> Both cases are somewhat advanced uses of the API, and I really think it
> wouldn't be much to ask in such a situation that the minimum of the readyStates
> be calculated by scripts.

In implementing this spec for WebKit, I have become convinced that the implementation of a readyState accessor is so incredibly trivial that even if the only benefit were to keep script authors from having to calculate the minimum readyState of the slaved media elements, it would still be worth adding.

But as there is no accessor in MediaController for the current slaved media elements, even doing this calculation script-side has the potential for errors.

> 2. When attaching controls to an already playing media element and need to
bring them up to speed.

Note that, currently, attaching a playing media element to a media group does not trigger "reporting the controller state", and thus in this situation the minimum slaved element readyState and the controller readyState are not the same.

As such, I'd like to reopen this bug for consideration.
Comment 7 Ian 'Hixie' Hickson 2011-11-03 16:37:58 UTC
For the latter case, should we change the spec to report the state?
Comment 8 Jer Noble 2011-11-03 18:07:17 UTC
(In reply to comment #7)
> For the latter case, should we change the spec to report the state?

I believe so, yes. Does that deserve a separate bug?
Comment 9 Ian 'Hixie' Hickson 2011-12-07 00:56:31 UTC
Nah, we can use this bug for it.
Comment 10 contributor 2012-06-04 23:42:28 UTC
Checked in as WHATWG revision r7115.
Check-in comment: Update the controller state when the current media controller changes.
http://html5.org/tools/web-apps-tracker?from=7114&to=7115
Comment 11 contributor 2012-06-05 00:14:42 UTC
Checked in as WHATWG revision r7116.
Check-in comment: Expose the controller state, since implementing it is apparently easy and it can be a bit more subtle than it looks.
http://html5.org/tools/web-apps-tracker?from=7115&to=7116
Comment 12 Ian 'Hixie' Hickson 2012-06-05 00:15:13 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diffs given above
Rationale: Concurred with reporter's comments.