331665 - Chrome Registry generates complete screwed up chrome.manifest files

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[James Ross]

This is an odd bug, and I don't actually know what component to blame - it could be NSPR, it could be XPCOM, I'm really not sure. Feel free to move it.

This bug occurs on Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a1) Gecko/20060325 Firefox/1.6a1 ID:2006032500 (trunk as of 5h40m ago).

When an extension has contents.rdf files but no chrome.manifest, chromereg makes one for it. It does this in parts, writing out the conversion of each contents.rdf file separately, appending to the manifest file each time. Only there's a bit of a problem with that... the file pointer is at the *start* of the file each time it re-opens it for appending.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/chrome/src/nsChromeRegistry.cpp&rev=1.346&mark=1559-1560#1549

I've verified that aAppend is true (value 1), but cannot easily verify the location of the file pointer except by observing the resulting changes in the file after each PR_Write.

The result is that each segment is written ontop of the other, giving a completely messed up and broken manifest. Given the lack of code changes to the chromereg code in this area, I'm going to guess it is an NSPR or XPCOM bug. The Unicode XPCOM I/O bug springs to mind, but I've got no evidence either way.

I've set this to major because it looks like a low-level file handling issue, which could potentially affect a lot of things, and it completely breaks installing extensions in Firefox that have no chrome.manifest (which was exactly the thing I was testing).

Comment 1

[Justin Kerk]

Is this fixed now with the fix to bug 331453? I know extensions weren't installing correctly during that and they work now.

Comment 2

[James Ross]

Yeah, it seems all better here now.