This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24675 - Difference in error handling for video element
Summary: Difference in error handling for video element
Status: RESOLVED DUPLICATE of bug 24560
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on: 24558
Blocks: 24560
  Show dependency treegraph
 
Reported: 2014-02-15 04:18 UTC by Silvia Pfeiffer
Modified: 2014-02-17 14:42 UTC (History)
5 users (show)

See Also:


Attachments

Description Silvia Pfeiffer 2014-02-15 04:18:31 UTC
+++ 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.
Comment 1 Simon Pieters 2014-02-17 14:42:32 UTC

*** This bug has been marked as a duplicate of bug 24560 ***