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 === Reply by Philip Jägenstedt: > AFAICT this is working as expected. When using <source> elements, if the > error occurs before reaching readyState HAVE_METADATA will cause the next > <source> element to be tried instead. The error event is queued to be fired > later, and at the time it fires the next source may already be loading, so > it would be strange if HTMLMediaElement.error were not null at that point. > > If distinguishing between network errors and decode errors at this point is > important, the required spec change would be to set .error, delay trying the > next source until the error event has been fired, and to set .error back to > null at that point. === Reply by Simon Pieters: > It seems better to add .error to HTMLSourceElement. === Am curious to get a WHATWG opinion.
*** This bug has been marked as a duplicate of bug 24560 ***