User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040719 Firefox/0.9.1+ (best browser EVAR1!!) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040719 Firefox/0.9.1+ When an xpi file has some files in components\, it cannot be installed twice. It seems that Firefox has problems with overwriting existing files in user profile with new files. Reproducible: Always Steps to Reproduce: 1. Install an extension with files in components\ 2. Restart 3. Install the same extension again. *OR* 3a. Install another version of extension, that replaces some files in components\ 4. Restart Actual Results: The extension is listed in EM with this message: "This item will be installed after you restart Firefox" no matter how many times you restart. Expected Results: The extension should install. If you installed an extension with different files in components\ (step 3a), the newer files aren't copied to extension's folder. After I delete the files in components\ subdirectory of extension's dir, everything works fine. see http://user.rol.ru/~nponom/minimizetotray-test1.xpi and http://user.rol.ru/~nponom/minimizetotray-test2.xpi (for step 3a) for example of such extensions
CONFIRMing on Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040720 Firefox/0.9.1+ Looks like a "Can't overwrite, file in use" type of situation.
I just ran into this issue and it appears that it prevents extension from being updated if they have components. The only viable workaround I have found is to have the components as a second xpi that doesn't use the new methodology and install the components into the application's components directory. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040814 Firefox/0.9.1+
Created attachment 156410 [details] [diff] [review] partial work (doesn't work yet) - do extension installation finalization in a separate restart cycle prior to when additional components directories are registered so no extensions components are loaded and held open. oh, how I long for a better component registration system.
Created attachment 156412 [details] [diff] [review] more progress still doesn't work...
I've encountered this when developing my extension (FoxyTunes) and found a work-around: http://www.iosart.com/bugblog/item/81/catid/4 Ben - maybe a similar technique can be used in the final fix of this problem? The installer can rename the dll, go ahead and install the new extension, and then restart Firefox.
Created attachment 156773 [details] [diff] [review] patch this one works (I think)
In my tree, I changed the name of "ReadComponentsINI" to "ReadDirectoryList" since the function is used to read a list of default preferences locations too.
I've rolled this patch up into 257304, my odds of getting shaver or vlad to review before the end of the year are probably better than brendan :-P
Fixed on branch, having merging troubles, will land on trunk shortly
I don't know if this is related: Got the Firefox Nightly 2004-09-03 branch. Now, all the files in the components directory are just ignored (the FoxyTunes extension) compreg.dat, xpti.dat are not updated with the new entries and the components are unavailable to the extension. Removing these files (*.dat) and having them rebuilt by Firefox on the next startup didn't help. The 2004-08-23 nighly didn't have this problem. Should I open this as a separate bug?
Alex: I believe yes. I think I got bitten by it too (at least I noticed minimizetotray wasn't working with 20040903). Please post the bug# here.
This bug is already filed: http://bugzilla.mozilla.org/show_bug.cgi?id=257681 http://bugzilla.mozilla.org/show_bug.cgi?id=258123 The second bug is defined as a "blocker". I think the first is a "blocker" too. Sorry for the duplicated report.
Just tried to reproduce this on Firefox 1.0.1 and the latest trunk build (2005-03-20) and i cant reproduce it... Shouldnt this bug be marked FIXED ?
yes, landed on trunk in patch for bug 257304. I made sure that it works with TB 20050311.