985859 - navigator.mimeTypes has lower-cased MIME types since Firefox 28 while preserving case on earlier versions

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P2)

Description

[Masatoshi Kimura [:emk]]

See bug 938885 comment #33 and following comments.

Comment 1

[Georg Fritzsche [:gfritzsche]]

Some specific details in this bug would be nice.

So, since bug 206659:
* register a mixed-case or upper-case mimetype for your plugin, e.g. 'application/x-MyPlugin'
* doesn't work anymore: navigator.mimeTypes['application/x-MyPlugin']
* does work: navigator.mimeTypes['application/x-myplugin']

That is because since bug 206659 we store the mimetype lower-case and mimeTypes[] access is case-sensitive.

Comment 2

[Georg Fritzsche [:gfritzsche]]

Whatwg refers to RFC 2616 3.7 for mimetypes, which says they are not case sensitive (expect parameter values).
There are no specifics though, as far as i can tell, on how MimeTypeArray handles case-sensitivity (see [1]).

Depending on case-sensitivity either way seems wrong here.
Maybe MimeTypeArray could handle named accesses case-insensitive? bsmedberg, what do you think?

[1] http://www.whatwg.org/specs/web-apps/current-work/#mimetypearray

Comment 3

[Bruce Cartland]

(In reply to Georg Fritzsche [:gfritzsche] from comment #1)
> Some specific details in this bug would be nice.
> 
> So, since bug 206659:
> * register a mixed-case or upper-case mimetype for your plugin, e.g.
> 'application/x-MyPlugin'
> * doesn't work anymore: navigator.mimeTypes['application/x-MyPlugin']
> * does work: navigator.mimeTypes['application/x-myplugin']
> 
> That is because since bug 206659 we store the mimetype lower-case and
> mimeTypes[] access is case-sensitive.

Nice summary. For our part, we will change our JS checks to lower case. This means 2 checks: one for older versions (mixed case), and one for 28+ (lowercase). Until we get our fix out, we will advise clients to use IE (our plugin is Windows only). Of course, if this were to be fixed in the next day or 2, we would wait ;). BTW I'm in Oz and going to sleep. 

Regards

Comment 4

[Georg Fritzsche [:gfritzsche]]

I'm not sure yet what the best option here is, but it's definitely not going to be fixed in 28, maybe 30 or 31.
At least fixing it in websites is trivial. Given that this wasn't reported while it was in Aurora & Beta, it seems the problem isn't too common.

Comment 5

[Kohei Yoshino]

Added this to the site compat doc:
https://developer.mozilla.org/en-US/Firefox/Releases/28/Site_Compatibility

A tweet from https://twitter.com/MozWebCompat is coming.

> Late notice of #Firefox 28 site compatibility: navigator.mimeTypes
> now has lower-cased plug-in MIME types http://mzl.la/28sitecompat

I'm not sure about add-ons as I don't have access to https://mxr.mozilla.org/addons/

Comment 6

[Jorge Villalobos [:jorgev] (he/him)]

Some add-ons use .mimeTypes, but it's unlikely they are significantly affected.

Comment 7

[John Schoenick [:johns]]

Attachment: navigator.mimeTypes access should be case-insensitive

Since pluginhost lowercases these all now, just finish making these case insensitive. The alternative would be some odd "match all lowercase OR the exact casing used when registered" which doesn't make much sense.


That's interesting about parameters -- should things like navigator.mimeTypes["application/x-java-vm;jni-version=1.3A"] ever work? In plugin-code we basically treat parameter strings as part of the type, but for non-plugin code we might need smarter parsing of mime types if there are any consumers of this

Comment 8

[Benjamin Smedberg]

Comment on attachment 8394462 [details] [diff] [review]
navigator.mimeTypes access should be case-insensitive

I'd like this pushed up the trains to 29 and even considered for any 28 respins if we do them. It sucks that we shipped this regression.

Comment 9

[:Gavin Sharp [email: [e-mail]]]

(In reply to Georg Fritzsche [:gfritzsche] from comment #4)
> Given that this wasn't reported while it was in Aurora & Beta, it seems the problem
> isn't too common.

It's possible it's true in this case, but unfortunately that assumption isn't a safe one in general. We relatively frequently discover serious, widespread compatibility issues only on the release channel.

Comment 10

[Kohei Yoshino]

(In reply to :Gavin Sharp (email [e-mail]) from comment #9)
> We relatively frequently discover serious, widespread compatibility
> issues only on the release channel.

Unfortunately true. We need a bigger, robust Aurora/Beta community to avoid such a regression as I mentioned in https://wiki.mozilla.org/FxSiteCompat. Anyone interested?

Comment 11

[John Schoenick [:johns]]

Comment on attachment 8394462 [details] [diff] [review]
navigator.mimeTypes access should be case-insensitive

https://hg.mozilla.org/integration/mozilla-inbound/rev/4f22c57a0ab4

Comment 12

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/4f22c57a0ab4

Comment 13

[John Schoenick [:johns]]

Comment on attachment 8394462 [details] [diff] [review]
navigator.mimeTypes access should be case-insensitive

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #8)
> I'd like this pushed up the trains to 29 and even considered for any 28
> respins if we do them. It sucks that we shipped this regression.

[Approval Request Comment]
Bug caused by (feature/regressing bug #):
Bug 206659

User impact if declined: 
Sites or addons that check for plugins with capitalized MIME types in navigator.mimeTypes will fail (e.g. navigator.mimeTypes["application/FOO"] fails while navigator.mimeTypes["application/foo"] succeeds, even if the plugin itself uses application/FOO)

Testing completed (on m-c, etc.): 
on m-c

Risk to taking this patch (and alternatives if risky): 
Low -- The patch itself is very straightforward, and it's hard to imagine sites are depending on mimeTypes["FOO"] failing when "foo" exists, when plugin mimetypes are case-insensitive to begin with. ("FOO" could never validly exist)

String or IDL/UUID changes made by this patch:
None

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/c16340f255c2
https://hg.mozilla.org/releases/mozilla-beta/rev/7e557fbd1fda

Comment 15

[Kohei Yoshino]

Updated https://developer.mozilla.org/en-US/Firefox/Releases/28/Site_Compatibility

Comment 16

[Paul Silaghi, QA [:pauly]]

This bug appears in the 29b1 - 29b2 pushlog https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=904eb7fb178c&tochange=fceb90d30601 , but this is not actually fixed in 29b2, only in 30 and 31. What am I missing here ?

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Sounds like a question for John, not me.

Comment 18

[Benjamin Smedberg]

You mean when you tested 29.0b2 you can still reproduce the problem?

Comment 19

[Paul Silaghi, QA [:pauly]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #18)
> You mean when you tested 29.0b2 you can still reproduce the problem?
Yes.
navigator.mimeTypes["application/x-java-vm"]
MimeType {description: "", enabledPlugin: Plugin, suffixes: "", type: "application/x-java-vm"}
navigator.mimeTypes["application/x-Java-vm"]
undefined

Comment 20

[John Schoenick [:johns]]

(In reply to Paul Silaghi, QA [:pauly] from comment #16)
> This bug appears in the 29b1 - 29b2 pushlog
> https://hg.mozilla.org/releases/mozilla-beta/
> pushloghtml?fromchange=904eb7fb178c&tochange=fceb90d30601 , but this is not
> actually fixed in 29b2, only in 30 and 31. What am I missing here ?

The pushlog only shows all changes pushed chronologically after fromchange, whether or not they landed on top of it, so it is misleading. The graph looks like: http://people.mozilla.org/~jschoenick/snapshot-1395772956.png

In this case FIREFOX_29_0b2_RELEASE tag landed on top of hg 662d9090988b, which is before this change. The tag was set after this bug landed chronologically, so that pushlog link includes it, but it is not in b2.

Comment 21

[Paul Silaghi, QA [:pauly]]

Thanks for explaining, John.
Waiting for the next 29 beta then.
Verified fixed in FF 30.0a2(2014-03-25), 31.0a1(2014-03-25) Win 7, Ubuntu 13.04, Mac OS X 10.8.5.

Comment 22

[Ada [:adalucinet]]

Reproduced with Firefox 29 beta 2.
Verified as fixed with Firefox 29 beta 4 (Build ID: 20140331125246) on Windows 7 x64, Mac OS X 10.9 and Ubuntu 13.10 x64:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0