This follows the behavior of HTMLMediaElement.buffered/played/seekable, so maybe file an HTML bug if you want some change there.

That HTML/WHATWG bug has existed for a while and been ignored.  Basically, Ian thinks it's not an issue in WHATWG because he tends not to care too much about consistency with JS author expectations, the HTML WG is not aiming to change things like this from the WHATWG spec (though this is a case where sanity via the HTML WG might have been nice), and as far as I can tell the TAG hasn't really been looking very closely at HTML, because it's too big, so here we are.

Changing this for HTMLMediaElement is also harder because those bits have been shipping in browsers for a good long while now...

But just because the HTML situation is broken due to the politics around HTML and possible legacy compat issues doesn't mean we should be spreading the brokenness further to new specs, imo.

In particular, see the discussion in bug 22471 where the suggestion that we stop doing the bad thing was just summarily ignored and all the conversation centered around how we prevent other specs from copying the bad thing....

Thanks, bug 22471 was the discussion I wasn't sure had happened. I'm not the spec editor here, but my take is that returning a new object every time isn't terrible enough to warrant trying to replace the attribute with a method, it's too late for HTMLMediaElement and consistency is worth something as well, even when consistently bad.

Ensuring that .buffered returns the same object as long as it hasn't changed since last access would be a less radical change that's probably Web compatible, if both specs made the same change.

I'm also OK with the current state of things.

> my take is that returning a new object every time isn't terrible enough 

It's pretty terrible.  It's a behavior that only C++ implementors seem to think is OK for a JS property get....  Not least because it's simple for them to do.

> Ensuring that .buffered returns the same object as long as it hasn't changed
> since last access

Can it change without the event loop spinning or script in some way invoking browser APIs?  Because if not, then this is clearly the correct solution, imo.

I'm fine with changing SourceBuffer.buffered to return the same object all the time. Technically these values can only change as part of the "Coded Frame Removal" and "Coded Frame Processing" algorithms.

I'm assuming that you want the value to be stable as long as webapp Javascript is executing. Is this usually handled by using language like "post a task to update the buffered attribute with the contents of intersection_ranges"? If not, could you point me at a good example in other specs.


The spec text that describes always creating a new object for access HTMLMediaElement.buffered probably needs to remain though so that the behavior is consistent with non-MSE playback.

> Is this usually handled by using language like "post a task to update the
> buffered attribute with the contents of intersection_ranges"?

Yep, this would work fine.  Just have to say which task queue to post it to.  Thank you!

For HTMLMediaElement, that would be bug 22471, so let's not worry about it here.

(In reply to Boris Zbarsky from comment #5)
> > my take is that returning a new object every time isn't terrible enough 
> 
> It's pretty terrible.  It's a behavior that only C++ implementors seem to
> think is OK for a JS property get....  Not least because it's simple for
> them to do.

Guilty as charged, I didn't even consider this problem when implementing these properties in Presto.

> > Ensuring that .buffered returns the same object as long as it hasn't changed
> > since last access
> 
> Can it change without the event loop spinning or script in some way invoking
> browser APIs?  Because if not, then this is clearly the correct solution,
> imo.

I think that's true for MediaSource as the append/remove bits are all async. HTMLMediaElement can synchronously detach from its backend by e.g. HTMLMediaElement.load(), but that's in response to an explicit call. I can think of no way 'video.buffered === video.buffered' to ever be false with a definition like "return the same object iff the ranges are identical to the previously returned object." I don't think MSE should do this if HTML doesn't, though.

Always returning the same object and having that be live is also possible, but I'm not a fan of live objects, and it could possibly break existing code that keeps old ranges in order to compare with new ones.

(In reply to Aaron Colwell from comment #6)
> Technically these values can only change as part of the "Coded
> Frame Removal" and "Coded Frame Processing" algorithms.

Just to be clear - value reported to user is also affected by changing MediaSource readyState state to ended/from ended to open, in cases with 2 track buffers with different buffered regions. 
Example: trackbuffer1: 3-5; trackbuffer2: 7-10; returns buffered 7-10 in ended state, empty range in open.

Boris,

Would just changing the spec to return the same object if the ranges haven't changed, as Philip suggest, be sufficient? 

I'm worried about making this attribute a live object for the following reasons:
1. It would become inconsistent with HTMLMediaElement.buffered behavior. I know you don't like this, but I think there is something to be said for keeping all TimeRanges attributes in the web platform behaving the same way especially if they are highly related like the .buffered attributes are.

2. This is one of the oldest parts of the MSE spec and is likely to break sites including large deployments like YouTube and Netflix for seemingly only aesthetic gain.

3. There is no simple way for the web app to make its own copy. The TimeRanges object doesn't have a way to clone itself so all web applications that wanted to keep a copy have to implement their own cloning logic.

> Would just changing the spec to return the same object if the ranges haven't
> changed, as Philip suggest, be sufficient? 

Yep.  I said so in comment 5, right?

> I'm worried about making this attribute a live object

Sure.  I think the compat worries are well-justified, live objects are a pain to work with, and we don't need to go there.

(In reply to Boris Zbarsky from comment #11)
> > Would just changing the spec to return the same object if the ranges haven't
> > changed, as Philip suggest, be sufficient? 
> 
> Yep.  I said so in comment 5, right?

Ok. It wasn't clear to me.

> 
> > I'm worried about making this attribute a live object
> 
> Sure.  I think the compat worries are well-justified, live objects are a
> pain to work with, and we don't need to go there.

Agreed. I'll make the changes in the next spec update then. Thanks. :)

Change committed...
https://github.com/w3c/media-source/commit/7a495fe29540835d0e219d3d52f3041f556a1f7d

While this bug clearly describe that we should only return the same object (same reference) only if it hasn't changed.

And so is the summary:
"Bug 27790 - Make .buffered attributes return the same object if nothing has changed."

is very clear.

I find the actual description of the buffered attribute however to not be reflecting this.
"5.        If intersection ranges does not contain the exact same range information as the current value of this attribute, then update the current value of this attribute to intersection ranges.
6.        Return the current value of this attribute.
"

I read this as always returning the same TimeRange object, and updating the object. Making it effectively a "live" object as described in comment 10.

(In reply to Jean-Yves Avenard from comment #14)
> While this bug clearly describe that we should only return the same object
> (same reference) only if it hasn't changed.
> 
> And so is the summary:
> "Bug 27790 - Make .buffered attributes return the same object if nothing has
> changed."
> 
> is very clear.
> 
> I find the actual description of the buffered attribute however to not be
> reflecting this.
> "5.        If intersection ranges does not contain the exact same range
> information as the current value of this attribute, then update the current
> value of this attribute to intersection ranges.
> 6.        Return the current value of this attribute.
> "
> 
> I read this as always returning the same TimeRange object, and updating the
> object. Making it effectively a "live" object as described in comment 10.

That was not the intent. Please suggest some alternate text that would make step 5 clearer to you.

This bug has been migrated to the GitHub issue tracker. Please follow/update progress using the GitHub issue:
https://github.com/w3c/media-source/issues/16

In particular, Jean-Yves Avenard, do you have a suggestion for improved text? (Please respond on the GitHub issue.)