[MSE] Bring end-of-stream algorithm section up to current spec.
Created attachment 218575 [details] Patch
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.
(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().
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.
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
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
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
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
Created attachment 218666 [details] Patch for landing
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.
Committed r160282: <http://trac.webkit.org/changeset/160282>
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
(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.
(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.
(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?