Closed Bug 800600 Opened 12 years ago Closed 9 years ago

canPlayType("video/mp4") == canPlayType("ViDeO/mP4") is true on OS X (case-insensitive) but false on Windows (case-sensitive)

Categories

(Core :: Audio/Video: Playback, defect, P2)

defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox19 --- affected
firefox43 --- affected
firefox44 --- affected
firefox45 --- fixed
firefox46 --- unaffected
firefox47 --- unaffected
firefox48 --- unaffected

People

(Reporter: cpeterson, Unassigned)

References

Details

Attachments

(1 file)

Attached file canPlayType.html
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: http://tools.ietf.org/html/rfc6381#section-3.3 The canPlayType() spec doesn’t say anything to override the RFC: http://www.whatwg.org/specs/web-apps/current-work/#dom-navigator-canplaytype 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.
Component: Audio/Video → Audio/Video: Playback
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. https://bug800600.bmoattachments.org/attachment.cgi?id=670576
Flags: needinfo?(cpearce)
Priority: -- → P2
Summary: Investigate making video.canPlayType() case-insensitive and/or supporting "avc1.*" wildcard codecs → canPlayType("video/mp4") == canPlayType("ViDeO/mP4") is true on OS X (case-insensitive) but false on Windows (case-sensitive)
Mime types/subtypes are case-sensitive and parameter values are case-insensitive per RFC 2045. https://tools.ietf.org/html/rfc2045#section-2 > 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.
> 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.
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")
Status: NEW → RESOLVED
Closed: 9 years ago
Depends on: 1230353
Flags: needinfo?(cpearce)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: