Bug 125270 – [MSE] Bring end-of-stream algorithm section up to current spec.

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Jer Noble]

[MSE] Bring end-of-stream algorithm section up to current spec.

[Jer Noble]

Created attachment 218575 [details]
Patch

[Darin Adler]

Comment on attachment 218575 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=218575&action=review

This looks good. The patch did not apply, so EWS did not process it. I can’t tell how well the test covers all the code paths.

> Source/WebCore/Modules/mediasource/MediaSource.cpp:344
> +    if (error.isNull() || error.isEmpty()) {

Null strings return true for isEmpty so there is no need to check both. Can just check isEmpty.

> Source/WebCore/Modules/mediasource/MediaSource.cpp:368
> +        if (m_mediaElement->readyState() == HTMLMediaElement::HAVE_NOTHING) {
> +            //  âªï¸ If the HTMLMediaElement.readyState attribute equals HAVE_NOTHING
> +            //    Run the "If the media data cannot be fetched at all, due to network errors, causing
> +            //    the user agent to give up trying to fetch the resource" steps of the resource fetch algorithm.
> +            m_mediaElement->mediaLoadingFailed(MediaPlayer::NetworkError);
> +        } else {
> +            //  âªï¸ If the HTMLMediaElement.readyState attribute is greater than HAVE_NOTHING
> +            //    Run the "If the connection is interrupted after some media data has been received, causing the
> +            //    user agent to give up trying to fetch the resource" steps of the resource fetch algorithm.
> +            m_mediaElement->mediaLoadingFailedFatally(MediaPlayer::NetworkError);
> +        }

The comments here do not make it clear why one case calls “failed fatally” and the other does not. I guess the problem is that literally quoting this piece of the spec ends up meaning we don’t say enough.

> Source/WebCore/Modules/mediasource/MediaSource.cpp:384
> +        return;

Seems unnecessary to have a return just before the end of the function.

> Source/WebCore/Modules/mediasource/MediaSource.h:83
>      void endOfStream(const AtomicString& error, ExceptionCode&);
> +    void endOfStreamAlgorithm(const AtomicString& error, ExceptionCode&);

I don’t think the names here are clear enough. It’s not like “end of stream” is not already an algorithm. I know there is some term of art or concept in the spec we are referring to here, but I would suggest making the names more distinct, probably also including a verb in the name of the new function. And also I would suggest not paragraphing this internal function right next to public functions from the DOM API.

[Jer Noble]

(In reply to comment #2)
> (From update of attachment 218575 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=218575&action=review
> 
> This looks good. The patch did not apply, so EWS did not process it. I can’t tell how well the test covers all the code paths.

Yes, this patch depends on a patch which hasn't been committed yet.  I'll upload a "Patch for committing" and let the EWS chew on it before landing.

> > Source/WebCore/Modules/mediasource/MediaSource.cpp:344
> > +    if (error.isNull() || error.isEmpty()) {
> 
> Null strings return true for isEmpty so there is no need to check both. Can just check isEmpty.

Will do.

> > Source/WebCore/Modules/mediasource/MediaSource.cpp:368
> > +        if (m_mediaElement->readyState() == HTMLMediaElement::HAVE_NOTHING) {
> > +            //  âªï¸ If the HTMLMediaElement.readyState attribute equals HAVE_NOTHING
> > +            //    Run the "If the media data cannot be fetched at all, due to network errors, causing
> > +            //    the user agent to give up trying to fetch the resource" steps of the resource fetch algorithm.
> > +            m_mediaElement->mediaLoadingFailed(MediaPlayer::NetworkError);
> > +        } else {
> > +            //  âªï¸ If the HTMLMediaElement.readyState attribute is greater than HAVE_NOTHING
> > +            //    Run the "If the connection is interrupted after some media data has been received, causing the
> > +            //    user agent to give up trying to fetch the resource" steps of the resource fetch algorithm.
> > +            m_mediaElement->mediaLoadingFailedFatally(MediaPlayer::NetworkError);
> > +        }
> 
> The comments here do not make it clear why one case calls “failed fatally” and the other does not. I guess the problem is that literally quoting this piece of the spec ends up meaning we don’t say enough.

Yeah, unfortunately, the MSE spec just refers to the HTML Media spec, which explicitly says that loading should be a soft failure vs. a hard one.

> > Source/WebCore/Modules/mediasource/MediaSource.cpp:384
> > +        return;
> 
> Seems unnecessary to have a return just before the end of the function.
> 
> > Source/WebCore/Modules/mediasource/MediaSource.h:83
> >      void endOfStream(const AtomicString& error, ExceptionCode&);
> > +    void endOfStreamAlgorithm(const AtomicString& error, ExceptionCode&);
> 
> I don’t think the names here are clear enough. It’s not like “end of stream” is not already an algorithm. I know there is some term of art or concept in the spec we are referring to here, but I would suggest making the names more distinct, probably also including a verb in the name of the new function. And also I would suggest not paragraphing this internal function right next to public functions from the DOM API.

Okay, I'm not a huge fan of the name either.  I'll rename this to streamEndedWithError().

[Jer Noble]

Created attachment 218639 [details]
Patch for landing

Darin, I added an extra note at each of those confusing call sites, but I'm not certain they do much more te explain the following code than the code does itself.

[Build Bot]

Comment on attachment 218639 [details]
Patch for landing

Attachment 218639 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/45408032

New failing tests:
media/media-source/media-source-fastseek.html
media/media-source/media-source-play.html

[Build Bot]

Created attachment 218644 [details]
Archive of layout-test-results from webkit-ews-15 for mac-mountainlion-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-15  Port: mac-mountainlion-wk2  Platform: Mac OS X 10.8.5

[Build Bot]

Comment on attachment 218639 [details]
Patch for landing

Attachment 218639 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/45408058

New failing tests:
media/media-source/media-source-fastseek.html
media/media-source/media-source-play.html

[Build Bot]

Created attachment 218649 [details]
Archive of layout-test-results from webkit-ews-06 for mac-mountainlion

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-06  Port: mac-mountainlion  Platform: Mac OS X 10.8.5

[Jer Noble]

Created attachment 218666 [details]
Patch for landing

[Jer Noble]

Marking this bug as depending on bug #125269, which fixes the crashes seen on some of the EWS bots.  I'll wait till that one is reviewed and lands before committing this one.

[Jer Noble]

Committed r160282: <http://trac.webkit.org/changeset/160282>

[Simon Fraser (smfr)]

Could this have caused two tests to show malloc errors?
http://build.webkit.org/results/Apple%20Mavericks%20Debug%20WK2%20(Tests)/r160286%20(853)/results.html

[Jer Noble]

(In reply to comment #12)
> Could this have caused two tests to show malloc errors?
> http://build.webkit.org/results/Apple%20Mavericks%20Debug%20WK2%20(Tests)/r160286%20(853)/results.html

It's unlikely; those test cases should never hit MSE code.  But i'll check.

[Jer Noble]

(In reply to comment #13)
> (In reply to comment #12)
> > Could this have caused two tests to show malloc errors?
> > http://build.webkit.org/results/Apple%20Mavericks%20Debug%20WK2%20(Tests)/r160286%20(853)/results.html
> 
> It's unlikely; those test cases should never hit MSE code.  But i'll check.

I haven't updated my local tree since committing this change, and running those tests with MallocScribble enabled doesn't cause a crash (as you might expect if some new code was modifying freed objects). But since there's nothing suspicious between r160282 (this change) and r160286, it's either an old bug or these patches caused it.

[Jer Noble]

(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #12)
> > > Could this have caused two tests to show malloc errors?
> > > http://build.webkit.org/results/Apple%20Mavericks%20Debug%20WK2%20(Tests)/r160286%20(853)/results.html
> > 
> > It's unlikely; those test cases should never hit MSE code.  But i'll check.
> 
> I haven't updated my local tree since committing this change, and running those tests with MallocScribble enabled doesn't cause a crash (as you might expect if some new code was modifying freed objects). But since there's nothing suspicious between r160282 (this change) and r160286, it's either an old bug or these patches caused it.

Okay, probably not this patch, as it's been happening for a while: http://build.webkit.org/results/Apple%20Mavericks%20Debug%20WK2%20(Tests)/r160276%20(849)/results.html

It's crashing in a different track test each time, but always in track/.  Is there already a bug for this issue, or should I file a new one?