If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Chrome Registry generates complete screwed up chrome.manifest files

RESOLVED FIXED

Status

()

Core
XPCOM
--
major
RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: James Ross, Unassigned)

Tracking

({regression})

Trunk
x86
Windows Server 2003
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

12 years ago
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).
(Reporter)

Updated

12 years ago
Keywords: regression

Comment 1

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

Comment 2

12 years ago
Yeah, it seems all better here now.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Depends on: 331453
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.