525672 - Removing a registry installed extensions causes "itemLocation is null"

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[MvS]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4

Not a "Specific and detailed bug report." No Send Feedback (grayed out) at Leave quick feedback.
FF 3.5.4 (for Mac) doesn't rid itself of the post-Add-on updates "Restart Firefox to complete your changes" even after several restarts. And, the newly updated Add-ons are still grayed out.

Reproducible: Always

Steps to Reproduce:
1.Find Updates
2.Restart Firefox
2.Tools->Add-ons->Restart Firefox STILL THERE
2.
3.
Actual Results:  
Restart Firefox STILL THERE, newly updated Add-ons GRAYED OUT.

Expected Results:  
I expected to
a) see different text in yellow strip (e.g. "updates completed")
b) have the updated Add-ons enabled
c) close the Add-ons box

?

Comment 1

[Dave Townsend [:mossop]]

What add-ons are you updating? Can you attach copies of extensions.ini, extensions.rdf, extensions.cache and extensions.log from your profile folder to this bug report.

http://support.mozilla.com/en-US/kb/Profiles

Comment 2

[MvS]

Update to 3.5.5  solved this problem, but added a new one... http://www.google.com/ig?gl=all&refresh=1 now will not finish loading. Removing *all* cookies (not just the google ones) temporarily solves it, but it appears again upon reload of page and, of course, restart of browser. Removing all cookies is not useful. It creates havoc with other sites requiring cookies for e.g. logins.

Comment 3

[Anthony]

This is the same problem I am having with the new beta 2 build. At first it was showing the default theme was updated and needed a restart. after I canceled the update I went to the extensions area and Google Gears continued to say this will be uninstalled after restart. I reported Google gears as not compatible with this version and had disabled it. But now if I check disable, cancel uninstall or uninstall, the restart notification does not disappear.

Comment 4

[Anthony]

Attachment: extensions.cache

Comment 5

[Anthony]

Attachment: extensions.rdf

Comment 6

[Anthony]

Attachment: extensions.ini

Comment 7

[Anthony]

This is still happening with 3.6b3. Any suggestions?

Comment 8

[MK]

I am also experiencing this on 3.6b5pre running on WinXP/SP3

Comment 9

[MK]

Attachment: ZIP file containing my extensions.cache, extensions.rdf and extensions.log

Attached are the requested files from my profile folder

Comment 10

[MK]

I've just noticed a slightly different behavior. My add-on updates are not completing even after re-starting several times. They are all stuck with "This add-on will be update when Namoroka is restarted". Add-ons that are stuck are - Weave 1.0b2pre1 and default theme.

Comment 11

[Liam K.]

Attachment: Zip file containing requested files

I'm not sure I have exactly the same problem, but I just tried to update Session Manager via downloading a new .xpi from the Mozilla add-ons website, and the "Restart Firefox to complete your changes" message persists.

Strangely, I couldn't find an "extensions.ini".

Comment 12

[Liam K.]

To add to that, closing the window and killing firefox.exe via Task Manager doesn't fix the problem.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b4) Gecko/20091124 Firefox/3.6b4 (.NET CLR 3.5.30729)

Comment 13

[ekzot]

I have similar problem in Windows:

1. register extension in registry (winreg-app-global)
2. start FF -> ok
3. close FF
4. delete registry item
5. start FF
6. there is "Restart Firefox to complete your changes" in add-ons and "This add-on will be uninstalled when Firefox is restarted."
7. close FF
8. there is extensions.log:
  2009-12-15 11:03:49 - Reached _shutdown and without clearing any pending flushes
  2009-12-15 11:03:49 - Error flushing caches: TypeError: itemLocation is null

7. after restart it is ok in add-ons

Tested with FF 3.6 beta 5.

Everything works fine with FF 3.5.5

Comment 15

[Dave Townsend [:mossop]]

This appears to be two different problems since the latter comments show windows only issues but the original reporter is on Mac. Since the original reporter never provided enough information to track his issue down though I'll just morph this to the windows issue which is reproducable and fixable now.

This ends up being a regression from bug 511091. When the registry extension is detected as missing we send an observer notification saying it is being uninstalled. As part of that notification we generate an nsIUpdateItem including the items icon which we attempt to get from the filesystem, however we fail because we don't know where the extension used to be installed.

Comment 16

[Dave Townsend [:mossop]]

We shouldn't block on this at this stage since it doesn't put the extension manager into a permanently bad state, an additional restart clears it up

Comment 17

[Liam K.]

(In reply to comment #16)
> We shouldn't block on this at this stage since it doesn't put the extension
> manager into a permanently bad state, an additional restart clears it up

False; the message is still there, even though it started occurring almost a month ago.

Comment 18

[Dave Townsend [:mossop]]

(In reply to comment #17)
> (In reply to comment #16)
> > We shouldn't block on this at this stage since it doesn't put the extension
> > manager into a permanently bad state, an additional restart clears it up
> 
> False; the message is still there, even though it started occurring almost a
> month ago.

In which case there are other classes of problems here causing similar error messages. The only one that I can reproduce and hence fix is that in comment 13. It's possible the fix might solve the other cases but without being able to test that I cannot say for sure.

Comment 19

[Tan Wei Lin Jason [:Ryuji]]

For my case, all my add-on are disabled. But somehow the message that tell me to restart firefox is gone.

Comment 20

[Dave Townsend [:mossop]]

Attachment: patch rev 1

This patch stops us throwing when trying to get the iconURL for an uninstalled registry extension. It covers a few additional callsites of getFile for safety where I believed it might be possible there could be a similar issue. Unfortunately there isn't really a way to automatically test this in out current test suite since the fake restart we use isn't enough to drop the cache of keys loaded from the registry on startup.

Comment 21

[Dave Townsend [:mossop]]

Pushed to trunk: http://hg.mozilla.org/mozilla-central/rev/d74e4f967a1d

Comment 22

[Tan Wei Lin Jason [:Ryuji]]

Problem still exist as of Firefox 3.6beta 5

Comment 23

[Tan Wei Lin Jason [:Ryuji]]

For My case, Same problem with a lot of you guys, with reoccuring prompt to restart Firefox in Add-on manager. 
When I change from Firefox 3.6b4 to Minefield 3.7prea1/Firefox 3.5.5, the same bug is still there. 

However, when I restarted Firefox 3.5.5 hoping that the add-on manager will be fixed, all add-ons are disabled including personas. 

When I say Disabled, that means they don't even have menu in tools menus or any icons in any toolbars. 

As I said above, this bug still exist as of Firefox 3.6b5.

Sorry for double posting.

Comment 24

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

In case it isn't clear the patch has only landed on the trunk as of today and has not landed for 3.5.x or 3.6 so this bug still exists with those versions. If you'd like to check if the fix has fixed this for you you will need to try tomorrow's nightly.

Comment 25

[MK]

I've just updated and it doesn't seem to have sorted the problem for me. I am on the latest nightly as of today noon GMT. 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b6pre) Gecko/20091217 Namoroka/3.6b6pre

Comment 26

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

(In reply to comment #25)
> I've just updated and it doesn't seem to have sorted the problem for me. I am
> on the latest nightly as of today noon GMT. 
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b6pre) Gecko/20091217
> Namoroka/3.6b6pre

Your user agent shows you are using 3.6b6pre where this has not landed per comment #24 and not the trunk where it has landed

Comment 27

[Dave Townsend [:mossop]]

We also have multiple bugs causing this error. This bug fix covers the problem specifically listed in comment 13. If anyone can come up with working steps to reproduce for any of the other issues then I'll happily fix those too, but I cannot fix what I cannot reproduce/identify.

Comment 28

[Tan Wei Lin Jason [:Ryuji]]

Will this bug block Firefox 3.6? 

or will Firefox 3.6 be release without this bug being resolved? 


I don't think it is correct to solve this bug after official Firefox 3.6 release, 
because this bug causes serious Add-On Manager Error.

Comment 29

[Tan Wei Lin Jason [:Ryuji]]

By the Way, Happy New Year Everyone. (sorry for double post)

Comment 30

[Dave Townsend [:mossop]]

I should probably have simply opened a separate bug for the reproducible issue described in comment 13 instead of morphing this one into it, however since I did I'm going to close this bug as fixed since the issue in comment 13 is fixed.

If you are still seeing hte error "Error flushing caches: TypeError: itemLocation is null" then a new bug should be filed however without steps to reproduce or evidence that it is a common problem we wouldn't block Firefox 3.6 on it.

Comment 31

[Dave Townsend [:mossop]]

Comment on attachment 418221 [details] [diff] [review]
patch rev 1

This has baked for longer than I intended and I'd like to land it on 1.9.2. It should be very low risk and the code altered should all be exercised by existing tests.

Comment 32

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 418221 [details] [diff] [review]
patch rev 1

a192=beltzner

Comment 33

[Dave Townsend [:mossop]]

Fixed on branch: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/79fb1af02f17

Comment 34

[MK]

(In reply to comment #33)
> Fixed on branch: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/79fb1af02f17

Hi, is this already available for testing? I've just tested this on the latest build available and I am still able to reproduce it using the steps in Comment 13.

--
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b6pre) Gecko/20100105 Namoroka/3.6b6pre

Comment 35

[MK]

OK. Seperate bug filed for this https://bugzilla.mozilla.org/show_bug.cgi?id=538138