1376004 - Show proper error on UI when getting 404

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, enhancement, P3)

Description

[Blake Wu [:bwu][:blakewu]]

Per bug 1374510 comment 3, we should show the proper error message for 404.

Comment 1

[JW Wang [:jwwang] [:jw_wang]]

Attachment: test_404.html

This test case set 'src' to a resource that doesn't exist. Our video control shows "Video format or MIME type is not supported" while Chrome shows an empty UI.

Our UI is confusing which looks we don't support the format instead of 404 file not found.

Comment 2

[JW Wang [:jwwang] [:jw_wang]]

This should be a bug of video control.

Comment 3

[Ray Lin[:ralin]]

Hi JW,

If the error msg is "Video format or MIME type is not supported", that means we received "MEDIA_ERR_SRC_NOT_SUPPORTED" in the video controls. Do we have any additional information can help us indicate 404 error instead of a generic "MEDIA_ERR_SRC_NOT_SUPPORTED" error? otherwise we might need to change message to a more neutral wording for both cases.

Comment 4

[JW Wang [:jwwang] [:jw_wang]]

The spec. doesn't talk about any specific error like 404.

https://html.spec.whatwg.org/multipage/media.html#dom-mediaerror-media_err_src_not_supported
"The media resource indicated by the src attribute or assigned media provider object was not suitable."

Can we assume "not suitable" means "doesn't exist"? Or at least we can show an empty UI as Chrome does that is less misleading.

Comment 5

[Chris Pearce [:cpearce (Not reading bugmail)]]

We cannot assume that "not suitable" means "doesn't exist". "not suitable" includes not having a codec that can decode the media for example.

We could certainly feed back more details on the HTMLMediaElement.error.message field; we have the capability now to have that contain an arbitrary string, so we could set it to a known value which conveys 404 which the videocontrols could look out for.

Comment 6

[JW Wang [:jwwang] [:jw_wang]]

Attachment: Bug 1376004. P1 - include http response code in the error.message field so the UI has more details to display a proper error message.

Review commit: https://reviewboard.mozilla.org/r/157300/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/157300/

Comment 7

[Chris Pearce [:cpearce (Not reading bugmail)]]

Comment on attachment 8886496 [details]
Bug 1376004. P1 - include http response code in the error.message field so the UI has more details to display a proper error message.

https://reviewboard.mozilla.org/r/157300/#review162730

Great, thanks.

Comment 8

[JW Wang [:jwwang] [:jw_wang]]

Thanks!

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/974788a46fa3
P1 - include http response code in the error.message field so the UI has more details to display a proper error message. r=cpearce

Comment 10

[JW Wang [:jwwang] [:jw_wang]]

Hi Ray,
We include response code in the error.message field. You can now parse the string to get more details about the error.

The format is: xxx: yyy. xxx is the http response code and yyy is a string that describes the code.
E.g. 404: Not Found.

I think 404 is the only code we care about for now.

Comment 11

[Ray Lin[:ralin]]

(In reply to JW Wang [:jwwang] [:jw_wang] from comment #10)
> Hi Ray,
> We include response code in the error.message field. You can now parse the
> string to get more details about the error.
> 
> The format is: xxx: yyy. xxx is the http response code and yyy is a string
> that describes the code.
> E.g. 404: Not Found.
> 
> I think 404 is the only code we care about for now.

Sure, is bug 1380232 the right place to carry on the UI part?

Comment 12

[JW Wang [:jwwang] [:jw_wang]]

No. Please open a new bug for UI changes.

Comment 13

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/974788a46fa3