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

Status: RESOLVED WONTFIX

(Toolkit :: Startup and Profile System, defect)

Description

[dark-dev]

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

[Benjamin Smedberg]

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

Comment 2

[dark-dev]

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

[Benjamin Smedberg]

The .manifest files do not contain "filenames", they contain URIs (typically relative URIs)... you can and should %escape any non-ascii characters.

Comment 4

[francek prijatelj]

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