This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
+++ This bug was initially created as a clone of Bug #24558 +++ Overview: Observed a difference in error handling with and without source element for the video tag. In both the cases, the expectation is that application should know correct error codes (Network or Decode or Source Not Supported). Video element with out source is behaving as expected. Want to know why such a difference has been forced. Steps To Reproduce: 1. Load "video_error_good.html file" 2. MediaError object in video element is updated with correct error code 3. Load "video_error_bad.html" 4. MediaError object in video element is null Expected Behavior: Application should be able to identify the reason for the failure (Network or Decode or source not supported) Actual Behavior: Application does not know what error it is even though source element fires error handler, type of the error is not known Posted a query on the public-html5-comments list, haven't received any update. Link - http://lists.w3.org/Archives/Public/public-html-comments/2014Jan/0000.html (also see comments in Bug #24558)
I don't follow. For src="", there's four possible error codes: MEDIA_ERR_ABORTED MEDIA_ERR_NETWORK MEDIA_ERR_DECODE MEDIA_ERR_SRC_NOT_SUPPORTED The first three only occur if the file pointed to by src="" could be fetched and is supported; in the case of a DNS error or other error meaning the file couldn't be fetched at all, you get the last one. For <source>, the last one doesn't apply, because if a <source> isn't supported, rather than abort, the algorithm just continues, looking for another <source> (that's the key difference between src="" and <source>). However, the other three codes still work fine; if the media file is determined to be supported, but then later there is either a network error, or the data is corrupted, or the user aborts the load, then the error code is set to one of the first three above, and then the whole thing is aborted. To catch the case of a <source> being skipped (as if it had gotten the last code above), you just use <source onerror="">.
Hmm, yes, you're right.
(In reply to Ian 'Hixie' Hickson from comment #1) > I don't follow. > > For src="", there's four possible error codes: > MEDIA_ERR_ABORTED > MEDIA_ERR_NETWORK > MEDIA_ERR_DECODE > MEDIA_ERR_SRC_NOT_SUPPORTED > > The first three only occur if the file pointed to by src="" could be fetched > and is supported; in the case of a DNS error or other error meaning the file > couldn't be fetched at all, you get the last one. > > For <source>, the last one doesn't apply, because if a <source> isn't > supported, rather than abort, the algorithm just continues, looking for > another <source> (that's the key difference between src="" and <source>). > However, the other three codes still work fine; if the media file is > determined to be supported, but then later there is either a network error, > or the data is corrupted, or the user aborts the load, then the error code > is set to one of the first three above, and then the whole thing is aborted. > > To catch the case of a <source> being skipped (as if it had gotten the last > code above), you just use <source onerror="">. In my sample (in the original Bug #24558), refer "video_error_bad.html" file. In which "onerror" event is handled to get the error on the source. But "onerror" does not give the type of the error (either network or decode). Let me take below use-case as an example: - Platform 1 supports only MP4 Content Playback - Below code is to support 2 platforms <video> <source src="content.mp4" type="video/mp4" onerror="error1()"/> <source src="content.flv" type="video/flv" onerror="error2()"/> </video> Assume that platform is facing network issues. Both error1 and error2 callback will be fired, without the type of the error and <video>.error attribute will be null. How does application knows it is a network error?
It doesn't. That's also the case for <video src>, as Hixie said. I believe that is by design, for security reasons we avoid exposing to scripts the exact reason why something failed to load.
(In reply to Simon Pieters from comment #4) > It doesn't. That's also the case for <video src>, as Hixie said. I believe > that is by design, for security reasons we avoid exposing to scripts the > exact reason why something failed to load. I beg to differ, it is not the same with <video src>, in which <video error> attribute will be updated with MediaError.MEDIA_ERR_NETWORK. My problem here is, why is the difference in the behavior for <video src> and <video><source>?
If the browser is giving you MediaError.MEDIA_ERR_NETWORK for src="" but is just firing 'error' on the <source> element and then moving on to the next <source> when you use <source>, then it's a bug in the browser. You should file that bug with the relevant vendor. (Please feel free to cc me when doing so.)
*** Bug 24675 has been marked as a duplicate of this bug. ***
Marking WORKSFORME per comment 6. Please reopen if I have made a mistake.