XRE chokes on .manifest files containing a UTF-8 byte-order-mark (BOM)

RESOLVED WONTFIX

Status

()

--
minor
RESOLVED WONTFIX
13 years ago
10 years ago

People

(Reporter: dark-dev, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: http://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.0.1/win32/en-US/xulrunner-1.8.0.1.en-US.win32.zip

Any .manifest file which has been saved as UTF-8 in an editor which uses the optional byte-order-mark (0xEF 0xBB 0xBF) will produce an "unrecognized chrome manifest instruction" warning when read and fail to register the chrome package on the first line.

Log excerpt:
[JavaScript Warning: "Warning: Ignoring unrecognized chrome manifest instruction." {file: "file:///H:/Projects/XUL/testapp/chrome.manifest" line: 1}]

Reproducible: Always

Steps to Reproduce:
1. Save any .manifest as UTF-8 in any editor which uses the optional BOM or manually prepend the bytes 0xEF 0xBB 0xBF.
2. Attempt to load the app/extention of which that .manifest is a part.  (A good way to see this is to use `xulrunner -jsconsole application.ini`.)
Actual Results:  
1. "Warning: Ignoring unrecognized chrome manifest instruction." {file: "file:///H:/Projects/XUL/testapp/chrome.manifest" line: 1}
2. Failure to register the chrome package on the first line.

Expected Results:  
UTF BOMs to be used to determine the encoding of the file and then stripped before processing the chrome instructions.

I can attach an example file if needed, but creating your own test is pretty trivial.

Comment 1

13 years ago
Chrome manifest files are ASCII. I think this should be WONTFIXed unless there's a compelling reason we need to allow UTF8 BOMs.
(Reporter)

Comment 2

13 years ago
Non-ASCII filenames?  Not all filesystems use the same encoding, which makes manually encoding the characters a chancy proposition.  For example, if an author is naming files in their native language and use the 'Latin Capital Letter O With Stroke' on a filesystem that is Unicode-friendly, it might get encoded as C3 98.  Later, the app/extension gets moved over to a Windows box, which always uses the 1252 encoding and that O-with-slash gets translated into D8.  Not understanding Unicode, the manifest now refers to a file which doesn't exist.

So supporting Unicode character encodings (at least those that are easily recognizable by their BOM) does have some benefit.  Couldn't say whether it's worth the effort to implement, though.  If this gets WONTFIXed, there should probably be a note mentioning the "ASCII-only" restriction on http://developer.mozilla.org/en/docs/Chrome_Registration,.

Comment 3

13 years ago
The .manifest files do not contain "filenames", they contain URIs (typically relative URIs)... you can and should %escape any non-ascii characters.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WONTFIX

Comment 4

12 years ago
(In reply to comment #3)
> The .manifest files do not contain "filenames", they contain URIs (typically
> relative URIs)... you can and should %escape any non-ascii characters.
> 
I just lost 2 hours searching for the bug.
In my xulrunner application chrome.manifest is the only file encoded in ASCII.

Updated

10 years ago
Duplicate of this bug: 434388

Updated

10 years ago
Component: XRE Startup → Startup and Profile System
QA Contact: xre.startup → startup
You need to log in before you can comment on or make changes to this bug.