252543 - Extension never gets installed second time when it has files in components\

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Nickolay_Ponomarev]

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

Comment 1

[PikeUK]

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.

Comment 2

[Robert Strong (they/them - no direct email)]

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+

Comment 3

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: 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.

Comment 4

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: more progress

still doesn't work...

Comment 5

[Alex Sirota (iosart)]

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.

Comment 6

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch

this one works (I think)

Comment 7

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 8

[Ben Goodger (use ben at mozilla dot org for email)]

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 

Comment 9

[Ben Goodger (use ben at mozilla dot org for email)]

Fixed on branch, having merging troubles, will land on trunk shortly

Comment 10

[Alex Sirota (iosart)]

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?

Comment 11

[Nickolay_Ponomarev]

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.

Comment 12

[Alex Sirota (iosart)]

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.

Comment 13

[Samir L. Boulema]

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 ?

Comment 14

[Nickolay_Ponomarev]

yes, landed on trunk in patch for bug 257304. I made sure that it works with TB
20050311.