[Webkit-unassigned] [Bug 85573] New: Add a layout test for covering MEDIA_ERR_NETWORK errors

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=85573

           Summary: Add a layout test for covering MEDIA_ERR_NETWORK
                    errors
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Media Elements
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: scherkus at chromium.org
                CC: eric.carlson at apple.com, pnormand at igalia.com


Even though I have a sample layout test that will trigger a MEDIA_ERR_NETWORK in Chromium... I want to figure out what the right course of action is here.

Today the only way to trigger a MEDIA_ERR_NETWORK is to advance the ready state to HAVE_METADATA or beyond and then report MediaPlayer::NetworkError back up to HTMLMediaElement.

Today I believe Mac is the only port not making use of MediaPlayer::NetworkError (chromium's usage is in the chromium repo):
$ git grep NetworkError -- Source/WebCore/platform/graphics/
Source/WebCore/platform/graphics/MediaPlayer.h:    enum EndOfStreamStatus { EosNoError, EosNetworkError, EosDecodeError };
Source/WebCore/platform/graphics/MediaPlayer.h:    enum NetworkState { Empty, Idle, Loading, Loaded, FormatError, NetworkError, DecodeError };
Source/WebCore/platform/graphics/blackberry/MediaPlayerPrivateBlackBerry.cpp:            m_networkState = MediaPlayer::NetworkError;
Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:            error = MediaPlayer::NetworkError;
Source/WebCore/platform/graphics/qt/MediaPlayerPrivateQt.cpp:            m_networkState = MediaPlayer::NetworkError;
Source/WebCore/platform/graphics/wince/MediaPlayerProxy.h:        NetworkError,


So... what are actually the scenarios when a network error could/should occur? For example, I have a test that delivers less bytes than advertised in Content-Length header:
  * Firefox handles it gracefully by truncating the duration of the content
  * Chromium currently treats it as a network error
  * Safari on SL truncates the content but seems to unexpectedly loop the content (?!)
  * Haven't tested others just yet :)

I'm OK if this ends up being a platform/chromium/http/test/media/ test for the time being until we can figure out a common behaviour (if there is one!).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.