[Bug 12598] <video> Odd distinction between two kinds of network errors

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12598

Philip Jägenstedt <philipj@opera.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |philipj@opera.com

--- Comment #1 from Philip Jägenstedt <philipj@opera.com> 2011-05-04 14:54:03 UTC ---
The spec has different code paths for "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" and "If the connection is interrupted, causing the user agent to
give up trying to fetch the resource".

In the case where readyState is still HAVE_NOTHING, is the spec asking UAs make
a distinction between the case when some data (not headers?) has been received
before the network error and the case when the network error occurs before any
data (but potentially headers?) has been received? What is the reason for
returning to the resource selection algorithm in one case but firing an error
event and giving up in the other?

The reason I noticed this is because I've been checking
readyState==HAVE_NOTHING to distinguish the first case -- "the media data
cannot be fetched at all, due to network errors". This makes step 4 in  the
second case dead code, it can never be reached. This is what it looks like:

if (readyState == HAVE_NOTHING) {
  // 1. The user agent should cancel the fetching process.
  // 2. Abort this subalgorithm, returning to the resource selection algorithm.
} else {
  // 1. The user agent should cancel the fetching process.
  // 2. Set the error attribute to a new MediaError object whose code attribute
is set to MEDIA_ERR_NETWORK.
  // 3. Queue a task to fire a simple event named error at the media element.
  // Step 4:
  if (readyState == HAVE_NOTHING) {
    // THIS POINT CAN NEVER BE REACHED
    // set the element's networkState attribute to the NETWORK_EMPTY value and
queue a task to fire a simple event named emptied at the element.
  } else {
    // set the element's networkState attribute to the NETWORK_IDLE value.
  }
  // etc ...
}

I could of course try to do what the spec says instead, but it doesn't seem
intentional or like a very good idea. I'd suggest to always return to the
resource selection algorithm if (readyState == HAVE_NOTHING) and keep only the
"otherwise" branch at step 4.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 4 May 2011 14:54:05 UTC