I'm unable to install MultiZilla on mozilla builds after november 21. All mozilla builds after this date use the new chrome file chrome.rdf This file replaces the prior all-*.rdf files. Don't tell me that you have to change rdf files to get it installed again. I've set the severity to critical because all MultiZilla users will be unable to install the new MultiZilla versions with a recent mozilla build. In fact, it's more like a real blocker to us. -Neil.

I think this has something to do with this bugzilla report: http://bugzilla.mozilla.org/show_bug.cgi?id=109488 What can we do to make it work again?

Please consider to read this bug report for more information: http://mozdev.org/bugs/show_bug.cgi?id=682

Don't see how this is an install problem. I couldn't download the install .xpi to check your script but the registerChrome() command shouldn't care about the format the chrome registry keeps its files.

Our XPInstall package worked untill this chrome.rdf file is introduced. We have not change a bit after it is introduced. If we use mozilla builds without the chrome.rdf change, than everything is working again! "I couldn't download the install .xpi" use this link: http://multizilla.mozdev.org/xpi/multiviews-095.xpi and press shift to open your file dialog. -Neil.

Thanks, I found the link before, the server just wasn't serving it or something. It's working now. You've shown no evidence that XPInstall is failing to do what your script tells it to do -- the install.log output (of a single install!) would be helpful. In general, though, if your package fails to work because some other part of Mozilla has changed (for example, this happens all the time when non-frozen interfaces change) then take it up with the folks who changed that part of Mozilla. The install script looks pretty safe and other than the file name change in the chrome registry (which the install doesn't directly manipulate) there haven't been any chrome changes that I see. Things to investigate: - do your files get unpacked in the correct place (I assume so) - does the install run without errors (I assume so) - does the output in installed-chrome.txt look like the right format - if you then delete chrome.rdf does it get regenerated correctly including your data (would indicate a timestamp checking problem) - if you remove the DELAYED_CHROME flag from the script does it work?

Clean install.log without errors

- do your files get unpacked in the correct place (I assume so) ->Yes - does the install run without errors (I assume so) ->Yes - does the output in installed-chrome.txt look like the right format ->Yes, and this are the lines: content,install,url,jar:resource:/chrome/multiviews.jar!/content/multiviews/ skin,install,url,jar:resource:/chrome/multiviews.jar!/skin/modern/multiviews/ locale,install,url,jar:resource:/chrome/multiviews.jar!/locale/en-US/multiviews/ - if you then delete chrome.rdf does it get regenerated correctly including your data (would indicate a timestamp checking problem) ->No

Aha, we have a winner! Everything seems to work, after removing the DELAYED_CHROME flag. This is how it now looks: // registerChrome( CONTENT | DELAYED_CHROME, getFolder(G_CHROME, G_JAR_FILE), G_CONTENT ); // registerChrome( SKIN | DELAYED_CHROME, getFolder(G_CHROME, G_JAR_FILE), G_SKIN ); // registerChrome( LOCALE | DELAYED_CHROME, getFolder(G_CHROME, G_JAR_FILE), G_LOCALE ); registerChrome( CONTENT, getFolder(G_CHROME, G_JAR_FILE), G_CONTENT ); registerChrome( SKIN, getFolder(G_CHROME, G_JAR_FILE), G_SKIN ); registerChrome( LOCALE, getFolder(G_CHROME, G_JAR_FILE), G_LOCALE ); So it looks like a real XPInstall problem to me. -Neil.

Neil: Now, this report is kinda old I know, but I just wanted to know if it is still a valid one, as it still is open. Could you please let us know if you still experience this problem with a recent Moz build (Moz1-RC1 or a new nightly build)? If not, could you please resolve this?

*** This bug has been marked as a duplicate of 109044 ***

Verified as a dupe of bug 109044