Masatoshi Kimura [:emk] Reporter
	Description • 11 years ago

See bug 938885 comment #33 and following comments.

	Georg Fritzsche [:gfritzsche]
	Comment 1 • 11 years ago

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.

	Georg Fritzsche [:gfritzsche]
	Comment 2 • 11 years ago

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

	Bruce Cartland
	Comment 3 • 11 years ago

(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

	Georg Fritzsche [:gfritzsche]
	Comment 4 • 11 years ago

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.

	Kohei Yoshino
	Comment 5 • 11 years ago

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/

	Jorge Villalobos [:jorgev] (he/him)
	Comment 6 • 11 years ago

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

	John Schoenick [:johns] Assignee
	Comment 7 • 11 years ago

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

	Benjamin Smedberg
	Comment 8 • 11 years ago

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.

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 9 • 11 years ago

(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.

	Kohei Yoshino
	Comment 10 • 11 years ago

(In reply to :Gavin Sharp (email gavin@gavinsharp.com) 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?

	John Schoenick [:johns] Assignee
	Comment 11 • 11 years ago

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

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

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 12 • 11 years ago

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

	John Schoenick [:johns] Assignee
	Comment 13 • 11 years ago

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

	Ryan VanderMeulen [:RyanVM]
	Comment 14 • 11 years ago

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

	Kohei Yoshino
	Comment 15 • 11 years ago

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

	Paul Silaghi, QA [:pauly]
	Comment 16 • 11 years ago

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 ?

	Ryan VanderMeulen [:RyanVM]
	Comment 17 • 11 years ago

Sounds like a question for John, not me.

	Benjamin Smedberg
	Comment 18 • 11 years ago

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

	Paul Silaghi, QA [:pauly]
	Comment 19 • 11 years ago

(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

	John Schoenick [:johns] Assignee
	Comment 20 • 11 years ago

(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.

	Paul Silaghi, QA [:pauly]
	Comment 21 • 11 years ago

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.

	Ada [:adalucinet]
	Comment 22 • 11 years ago

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