Closed Bug 599674 Opened 14 years ago Closed 14 years ago

ABP enabled alongside other addons prevents the AOM from installing updates

Categories

(Toolkit :: Add-ons Manager, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 587088

People

(Reporter: danialhorton, Unassigned)

References

()

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100925 Firefox/4.0b7pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100925 Firefox/4.0b7pre

When adblock plus is enabled alongside other addons (listed), addon updates fail either having the previous version remain (exists as xpi), or losing the addon completely from the addons list(exists as unpacked folder), leaving only chrome/jar file remains in the extension sub folder.

So far i've found the issue occurs alongside

Ebay status bar,
Optimise Google
flashblock
image toolbar

These 4 extensions work together and individually without this problem until ABP is enabled with them.


Reproducible: Always

Steps to Reproduce:
1. Install ABP
2. Install any of the 4 listed addons (flash block is updated for Minefield 4)
3. Restart, and ensure they are both enabled.
4. Install another addon, that is not the latest version but a newer one exists on mozilla addons, Restart.
5. Update the addon via the addons manager
Actual Results:  
If the previous version exists as an XPI inside the extensions folder, the previous version is listed, but not functional, it is not listed as disabled but on the next start of firefox it will be enabled again.

If the previous version is installed as a subfolder inside the extensions folder (in the case you migrated a profile from 3.x) the contents of the folder are mostly deleted except for the chrome/jar file, and the extension is removed from the AOM.

Expected Results:  
Its understood that extension sub folders are cleaned up and replaced with xpi's at this point, but ABP + * extension is causing this to fail so the extension is lost from AOM.

How an addon is intefering with the update is beyond me, but there must be some way to prevent an addon from breaking updates from the application side.

Image Toolbar 0.6.8
eBay Sidebar for Firefox 2.1.3
Flashblock 1.5.14a
OptimizeGoogle 0.78.1
Can you attach a copy of extensions.log from your profile folder to this bug report.
Component: Installer: XPInstall Engine → Add-ons Manager
Product: Core → Toolkit
QA Contact: xpi-engine → add-ons.manager
Version: unspecified → Trunk
Attached file extension log
fresh profile used for reproduction
each line represents an attempt to install the addon while i left ABP enabled, but switched between the individual extensions.

the 1st line is with then all enabled.

no lines exist for when the attempt succeeded, which would be when i disabled the 4 extensions or left them enabled but disabled ABP.
Attachment #478597 - Attachment mime type: application/octet-stream → text/plain
Should be solved by bug 587088
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
i can see how this might be a duplicate, but its specifically related to certain extensions that i have verified in a fresh profile.

This is more to do with the extensions themselves causing the issue than the actual issue occuring.
(In reply to comment #5)
> This is more to do with the extensions themselves causing the issue than the
> actual issue occuring.

You could try talking to the extension authors. As far as the platform is concerned though something outside of its control is locking the files it needs to use, the best we can hope to do in such a case is to detect that and recover as gracefully as possible, that is what bug 587088 aims to do.
It is not impossible to detect a locked file and force an unlock. The file system also allows you to rename in use files and place the updated file with the same name for later use, tracking these renames for cleanup on restart is also not a difficult thing, various installers manage updates in similar manners where the file is locked by the shell, such as in the case of a context menu provided by a shell registered dll.
(In reply to comment #7)
> It is not impossible to detect a locked file and force an unlock. The file
> system also allows you to rename in use files and place the updated file with
> the same name for later use, tracking these renames for cleanup on restart is
> also not a difficult thing, various installers manage updates in similar
> manners where the file is locked by the shell, such as in the case of a context
> menu provided by a shell registered dll.

This is true of OSX and Linux but the Windows file system does not allow you to rename or move files that are in use. The only options are either to close whatever has the file open, restart the computer or use a tool to forcibly unlock the file (presumably causing problems for the process that is using the file at the time).

Yes it would be possible to track the changes we want to make and ask the user to reboot their machine to install and add-on, but I don't think we are going to.
I wasn't meaning a reboot, this is unrequired, the file becomes unlocked after firefox releases it on close and the subsequent start will remove the now unused extension.

Also, Windows does allow files to be renamed while in use on NTFS partitions. Its a trick i use with some installers that register certain dll's for thumbnail creation.
(In reply to comment #9)
> I wasn't meaning a reboot, this is unrequired, the file becomes unlocked after
> firefox releases it on close and the subsequent start will remove the now
> unused extension.

That actually isn't necessarily true on windows either, locks can persist past application exit in some cases. And the particular instance here is seeing the file in use during early Firefox startup, none of the extensions will have been able to do anything to lock the files and Firefox doesn't either.
Is it possible ABP is initialising before it should? It wouldn't be the first time it has interfered with start, it prevented D2D from working previously.
(In reply to comment #11)
> Is it possible ABP is initialising before it should? It wouldn't be the first
> time it has interfered with start, it prevented D2D from working previously.

I know of no way it could, we don't load extension components or even the list of enabled extensions before we attempt to do the file moves for upgrades.
I'll run some file monitors on this specific case on Monday to see if I see the same behaviour though I know I've never been able to reproduce similar problems like this in the past.
(In reply to comment #13)
> I'll run some file monitors on this specific case on Monday to see if I see the
> same behaviour though I know I've never been able to reproduce similar problems
> like this in the past.

I was unable to reproduce this on my test machine with Adblock plus and Flashblock installing and an older verison of Stop Autoplay, the update was detected, downloaded and after the restart installed and working with no errors in the log.

It is possible that something else on your system is what is locking the files we can't access, we've seen this very commonly in the past with antivirus tools, spyware detectors and even version control tools like tortoisesvn.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: