Closed Bug 985859 Opened 6 years ago Closed 6 years ago

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

Categories

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

defect

Tracking

()

VERIFIED FIXED
mozilla31
Tracking Status
firefox28 ? affected
firefox29 + verified
firefox30 + verified
firefox31 + verified

People

(Reporter: emk, Assigned: johns)

References

Details

(4 keywords)

Attachments

(1 file)

See bug 938885 comment #33 and following comments.
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.
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
Flags: needinfo?(benjamin)
Priority: -- → P4
(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
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.
Keywords: site-compat
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/
Some add-ons use .mimeTypes, but it's unlikely they are significantly affected.
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
Attachment #8394462 - Flags: review?(benjamin)
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.
Attachment #8394462 - Flags: review?(benjamin) → review+
Flags: needinfo?(benjamin)
(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.
Priority: P4 → P2
(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?
Comment on attachment 8394462 [details] [diff] [review]
navigator.mimeTypes access should be case-insensitive

https://hg.mozilla.org/integration/mozilla-inbound/rev/4f22c57a0ab4
Attachment #8394462 - Flags: checkin+
https://hg.mozilla.org/mozilla-central/rev/4f22c57a0ab4
Assignee: nobody → jschoenick
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
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
Attachment #8394462 - Flags: approval-mozilla-beta?
Attachment #8394462 - Flags: approval-mozilla-aurora?
Attachment #8394462 - Flags: approval-mozilla-beta?
Attachment #8394462 - Flags: approval-mozilla-beta+
Attachment #8394462 - Flags: approval-mozilla-aurora?
Attachment #8394462 - Flags: approval-mozilla-aurora+
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 ?
Flags: needinfo?(ryanvm)
Sounds like a question for John, not me.
Flags: needinfo?(ryanvm) → needinfo?(jschoenick)
You mean when you tested 29.0b2 you can still reproduce the problem?
(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
(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.
Flags: needinfo?(jschoenick)
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.
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
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.