Closed Bug 508030 Opened 10 years ago Closed 10 years ago

nsIMIMEService.getTypeFromExtension fails to find a match in the "ext-to-type-mapping" category if the provided extension is not lowercase

Categories

(Core Graveyard :: File Handling, defect)

defect
Not set

Tracking

(status1.9.1 .3-fixed)

RESOLVED FIXED
Tracking Status
status1.9.1 --- .3-fixed

People

(Reporter: Paolo, Assigned: Paolo)

References

Details

(Keywords: verified1.9.1)

Attachments

(1 file, 1 obsolete file)

The "ext-to-type-mapping" category, introduced in bug 231886, is meant to
contain a set of lowercase file extensions that are checked as a last resort
when trying to determine the MIME type of a file based on its extension:

https://developer.mozilla.org/en/How_Mozilla_determines_MIME_Types#ExternalHelperAppService

At present, however, the check in nsIMIMEService.getTypeFromExtension is
case-sensitive and fails to find a match in the "ext-to-type-mapping"
category if the extension provided in the argument is not lowercase.

In practice, this means that any Mozilla extension that relies on the
"ext-to-type-mapping" would fail to open local files if their file extension
is not lowercase. For example, Mozilla Archive Format can currently open
"Example.mht" but not "Example.MHT", unless the MIME type is already
registered in the operating system.
Attached patch Patch and test case (obsolete) — Splinter Review
Here is the fix and the test case. Christian, would you like do a first
review, since you wrote the original code?

With this patch, the behavior for the "ext-to-type-mapping" is now to treat
file extensions case-insensitively on all platforms. I think this is the
appropriate behavior even for Unix-like platforms, since this will allow,
for example, a Mozilla extension on Linux to open a file with an uppercase
extension, published by a Windows user on a network share.
Assignee: nobody → paolo.02.prg
Attachment #392251 - Flags: superreview?(bzbarsky)
Attachment #392251 - Flags: review?(cbiesinger)
Attachment #392251 - Flags: review?(cbiesinger) → review+
Attachment #392251 - Flags: superreview?(bzbarsky) → superreview+
http://hg.mozilla.org/mozilla-central/rev/97ec2484a49a
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Wow, exceptionally fast review and checkin! :-)
Comment on attachment 392251 [details] [diff] [review]
Patch and test case

This simple fix is relevant for extensions running on current versions of Firefox and other products.
Attachment #392251 - Flags: approval1.9.1.2?
Attachment #392251 - Flags: approval1.9.0.14?
Attachment #392251 - Flags: approval1.9.1.2? → approval1.9.1.3?
(In reply to comment #5)
> the test contains a typo. see
> http://hg.mozilla.org/mozilla-central/rev/28a58910d695 for the fix.

I'm sorry. I always run tests with and without the fix to ensure that they
work, but this time it's possible that I erroneously saw a "TEST-PASS" for
an unrelated test and overlooked the "TEST-UNEXPECTED-FAIL".
Attachment #392251 - Attachment is obsolete: true
Attachment #392251 - Flags: approval1.9.1.3?
Attachment #392251 - Flags: approval1.9.0.14?
Attachment #392509 - Flags: approval1.9.1.3?
Attachment #392509 - Flags: approval1.9.0.14?
Comment on attachment 392509 [details] [diff] [review]
Patch and test case

Do not want for 3.0.x.

Approved for 1.9.1.3, a=dveditz for release-drivers
Attachment #392509 - Flags: approval1.9.1.3?
Attachment #392509 - Flags: approval1.9.1.3+
Attachment #392509 - Flags: approval1.9.0.14?
Attachment #392509 - Flags: approval1.9.0.14-
Keywords: checkin-needed
Keywords: checkin-needed
Verified for 1.9.1.3 using the checked in testcase.
Keywords: verified1.9.1
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.