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 24558 - Difference in error handling for video element
Summary: Difference in error handling for video element
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: CR HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Robin Berjon
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 24560 24675
  Show dependency treegraph
 
Reported: 2014-02-06 09:18 UTC by krsacme
Modified: 2014-02-22 15:00 UTC (History)
4 users (show)

See Also:


Attachments
Samples to demonstrate the problem (1.07 KB, application/octet-stream)
2014-02-06 09:18 UTC, krsacme
Details

Description krsacme 2014-02-06 09:18:51 UTC
Created attachment 1438 [details]
Samples to demonstrate the problem

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
Comment 1 Philip Jägenstedt 2014-02-06 10:36:46 UTC
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.
Comment 2 Simon Pieters 2014-02-06 11:16:06 UTC
(In reply to Philip Jägenstedt from comment #1)
> 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.

It seems better to add .error to HTMLSourceElement.
Comment 3 krsacme 2014-02-22 15:00:40 UTC
As per the discussion on Bug# 24560, and comment# 6 (https://www.w3.org/Bugs/Public/show_bug.cgi?id=24560#c6), the expected behavior should be same for src and <srouce> element. Will discuss with corresponding vendor implementation.