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

RESOLVED FIXED

Status

()

Toolkit
Add-ons Manager
RESOLVED FIXED
14 years ago
9 years ago

People

(Reporter: Nickolay_Ponomarev, Assigned: Ben Goodger (use ben at mozilla dot org for email))

Tracking

({fixed-aviary1.0})

unspecified
x86
Windows XP
fixed-aviary1.0
Points:
---
Bug Flags:
blocking-aviary1.0PR +
blocking-aviary1.0 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [have patch] need review-brendan ETA 8/27, URL)

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

14 years ago
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

14 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-aviary1.0?
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+
Flags: blocking-aviary1.0PR+
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0+
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...
Attachment #156410 - Attachment is obsolete: true

Comment 5

13 years ago
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)
Attachment #156412 - Attachment is obsolete: true
Attachment #156773 - Flags: review?(brendan)

Updated

13 years ago
Whiteboard: [have patch] need review-brendan
Whiteboard: [have patch] need review-brendan → [have patch] need review-brendan ETA 8/27
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 
Depends on: 257304
Fixed on branch, having merging troubles, will land on trunk shortly
Keywords: fixed-aviary1.0

Comment 10

13 years ago
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?
(Reporter)

Comment 11

13 years ago
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

13 years ago
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.

Updated

13 years ago
Attachment #156773 - Flags: review?(brendan)

Comment 13

13 years ago
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 ?
(Reporter)

Comment 14

13 years ago
yes, landed on trunk in patch for bug 257304. I made sure that it works with TB
20050311.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.