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 27599 - Allow SourceBuffer.trackDefaults to be nullable
Summary: Allow SourceBuffer.trackDefaults to be nullable
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Media Source Extensions (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: CR
Assignee: Aaron Colwell
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-12 22:32 UTC by Matt Wolenetz
Modified: 2015-01-09 19:28 UTC (History)
5 users (show)

See Also:

Attachments

Description Matt Wolenetz 2014-12-12 22:32:46 UTC 
In current spec, if an app wants to clear a SourceBuffer's non-empty trackDefaults, it must set the attribute to a TrackDefaultList that was constructed with an empty sequence<TrackDefault>. For example:
...
sb = mediaSource.activeSourceBuffers[0];
sb.trackDefaults = new TrackDefaultList( [] );
...

This bug is to request change to spec to make this operation more natural, by specifying:
0. the SourceBuffer.trackDefaults attribute is nullable
1. the SourceBuffer.trackDefaults attribute setter allows null
2. the initial value of SourceBuffer.trackDefaults is null
3. the default {language, kind, label} algorithms behave correctly if trackDefaults is null

These changes would be app-visible and #2 would possibly break existing apps. Alternatively, maybe #2 should be:
2. prior to any explicit set operation by app, the SourceBuffer.trackDefaults attribute getter should return an empty TrackDefaultList object that is the same object (===) each time for this SourceBuffer.
Comment 1 Philip Jägenstedt 2014-12-12 23:40:05 UTC 
I think letting it default to null seems the most sane, a dummy object that doesn't hold any real info is a bit odd.
Comment 2 Philip Jägenstedt 2014-12-13 20:34:32 UTC 
About potential breakage, has SourceBuffer.trackDefaults been shipped in any browser?
Comment 3 Aaron Colwell 2014-12-16 19:40:55 UTC 
I'm not sure I agree with this position. It seems annoying to me that application code would always have to check for null AND then check for length > 0 before it could actually use the defaults. Having it always be non-null seems like a good way to avoid at least one of these checks.

I agree that requiring the [] is ugly. What if I made the constructor parameter optional and provided a default of []? That at least makes it a little less ugly.
Comment 4 Matt Wolenetz 2014-12-16 21:14:54 UTC 
(In reply to Aaron Colwell from comment #3)

> I agree that requiring the [] is ugly. What if I made the constructor
> parameter optional and provided a default of []? That at least makes it a
> little less ugly.

This seems a good approach to me.
Comment 5 Philip Jägenstedt 2014-12-16 23:17:23 UTC 
That seems OK to me too.