Note: There are a few cases of duplicates in user autocompletion which are being worked on.
Last Comment Bug 800600 - canPlayType("video/mp4") == canPlayType("ViDeO/mP4") is true on OS X (case-insensitive) but false on Windows (case-sensitive)
: canPlayType("video/mp4") == canPlayType("ViDeO/mP4") is true on OS X (case-in...
Product: Core
Classification: Components
Component: Audio/Video: Playback (show other bugs)
: Trunk
: All All
P2 normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Anthony Jones (:kentuckyfriedtakahe, :k17e)
Depends on: 1230353
Blocks: 794171
  Show dependency treegraph
Reported: 2012-10-11 15:41 PDT by Chris Peterson [:cpeterson]
Modified: 2016-04-07 10:05 PDT (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

canPlayType.html (1.31 KB, text/html)
2012-10-11 15:41 PDT, Chris Peterson [:cpeterson]
no flags Details

Description User image Chris Peterson [:cpeterson] 2012-10-11 15:41:19 PDT
Created attachment 670576 [details]

1. Chrome and Safari's canPlayType() MIME type check is case-insensitive, but Firefox's is case-sensitive, e.g. "video/mp4" vs "ViDeO/mP4".

2. Chrome and Safari's canPlayType() codec name check returns "probably" support for any "avc1.*" codec name (even "avc1.BOGUS"), but Firefox checks a short, case-sensitive list. Curiously, Chrome and Safari's codec name prefix check for "avc1." *is* case-sensitive.

See the attached test case.

* In bug 794171 comment 9, hsivonen says:

The RFC says the ISO BMF namespace is case-sensitive:

The canPlayType() spec doesn’t say anything to override the RFC:

That said, I wouldn’t oppose to making it ASCII case-insensitive if you file a WHATWG spec bug to request ASCII case-insensitivity and citing the outright wildcarding in WebKit.
Comment 1 User image Chris Pearce (:cpearce) 2013-05-11 19:35:36 PDT
A test case:
Comment 2 User image Chris Peterson [:cpeterson] 2016-01-15 20:14:44 PST
cpearce: why would Firefox's canPlayType's case-sensitivity differ on Windows vs OS X? Does Firefox really use platform-specific code paths to parse these canPlayType strings?

To maximize compatibility, we should probably make canPlayType case-insensitive like Chrome, Edge/IE, and Firefox on OS X. OTOH, Safari is case-sensitive here and we have gotten away with it on Windows for years, so we could probably make Firefox on OS X case-sensitive, too.

It looks like Chrome's canPlayType results may have changed post-Blink. Chrome now matches Firefox on OS X.

Is container string case-sensitive, e.g. "video/mp4" vs "ViDeO/mP4"?

* Firefox on OS X: NO
* Firefox on Windows: YES?!
* Chrome on OS X and Windows: NO
* Safari: YES!
* Edge/IE: NO

Is codec string case-sensitive, e.g. "avc1.42E01E" vs "AvC1.42e01e"?

* Firefox on OS X: YES
* Firefox on Windows: YES
* Chrome on OS X and Windows: YES
* Safari: PARTIALLY? Returns "maybe" for "AvC1.42e01e" instead of ""
* Edge/IE: NO, codec string appears to be ignored.
Comment 3 User image Masatoshi Kimura [:emk] 2016-02-21 17:31:49 PST
Mime types/subtypes are case-sensitive and parameter values are case-insensitive per RFC 2045.
>   All numeric and octet values are given in decimal notation in this
>   set of documents. All media type values, subtype values, and
>   parameter names as defined are case-insensitive.  However, parameter
>   values are case-sensitive unless otherwise specified for the specific
>   parameter.
Comment 4 User image Masatoshi Kimura [:emk] 2016-02-21 17:32:26 PST
> Mime types/subtypes are case-sensitive and parameter values are case-insensitive per RFC 2045.

Sorry, it was opposite.
Mime types/subtypes are case-insensitive and parameter values are case-sensitive per RFC 2045.
Comment 5 User image Chris Peterson [:cpeterson] 2016-04-07 10:05:05 PDT
jya's fix for bug 1230353 fixed this bug in 45. The following expression now returns true on OS X, Windows XP, and Windows 10:

document.createElement("video").canPlayType("video/mp4") === document.createElement("video").canPlayType("ViDeO/mP4")

Note You need to log in before you can comment on or make changes to this bug.