Closed Bug 396695 Opened 17 years ago Closed 17 years ago

add-ons go into "needs to restart" loop commonly after a firefox update

Categories

(Toolkit :: Add-ons Manager, defect, P3)

Product:
Toolkit
Component:
Add-ons Manager
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9beta1

People

(Reporter: aggboss, Assigned: robert.strong.bugs)

References

Details

(Keywords: fixed1.8.1.10, fixed1.8.1.9)

Attachments

(3 files, 3 obsolete files)

minimal patch (checked in to trunk and GECKO181_20071004_RELBRANCH for 1.8.1.9)
1.62 KB, patch
moco
: review+
dveditz
: superreview+
dveditz
: approval1.8.1.9+
dveditz
: approval1.8.1.10+
beltzner
: approvalM9+
Details | Diff | Splinter Review
trunk patch
35.23 KB, patch
robert.strong.bugs
: review-
Details | Diff | Splinter Review
Screenshot of add-ons dialog box
45.48 KB, image/jpeg
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

extensions/add-ons say they will update/install after firefox is restarted. However, they do not update or install (adblock, for example)in new firefox release despite restart and/or reboot. As a result,the add-on no longer works. This has never happened in any prior firefox update/release.

Reproducible: Always

Steps to Reproduce:
1.start firefox and view add-on window
2.note message that add-ons will either update or reinstall upon restart of firefox
3.restarting firefox or rebooting computer does not update or reinstall add-ons. Same message as #2 appears.
Actual Results:  
see above

Expected Results:  
As in all prior firefox releases, I expected the add-ons to either update or reinstall or give me a message if the add-on is no longer compatible with the new release

add-ons should update/reinstall and then work. Not having adblock is now a major inconvenience to using firefox
I have the same problem. No add-ons will load or update since Firefox/2.0.0.7 update. 
Could you zip Can you zip up your profile's extensions directory along with the extensions.rdf, extensions.cache, and extensions.ini files that are located inside your profile's directory and either email the zip file to me or attach it to this bug? I suspect the resulting zip file will be larger than the maximum allowed for attachments so you will probably have to email them to me.
http://www.mozilla.org/support/firefox/profile

if / when you do email this to me please post in this bug that you have. I get a ton of spam to this account which it will most likely get marked as so I'll need to search through the recent email.
(In reply to comment #3)
> if / when you do email this to me please post in this bug that you have. I get
> a ton of spam to this account which it will most likely get marked as so I'll
> need to search through the recent email.

Robert - I emailed you on 9/19 in the evening with requested data
> 


Robert, have sent you the extensions directory and the extensions.* files from a German user which had this problem.
I received Alan's but not archaeopteryx@coole-files.de.

Alan, where did the extensions directory come from? Your profile or the application directory? I ask because it seems that they are from your application directory and I need the extensions directory from your profile directory.

archaeopteryx@coole-files.de, could you try sending them again?
Sorry, I uploaded it here http://www.file-upload.net/download-415650/prob-prof.zip.html and had mailed it to Mossop and you, but from your account it always bounces with 'illegal attachment'.
I have no idea why gmail would complain about an attached zip file since I get those all the time... anyways, thank you and no worries.
Could one or both of you try removing the following directories from your application's extensions directory?

{CAFEEFAC-0016-0000-0001-ABCDEFFEDCBA}
{CAFEEFAC-0016-0000-0002-ABCDEFFEDCBA}

I suspect it is something to do with the Java Console hidden extension installed when installing the Sun JRE.
Robert - I just emailed the profiles extension directory to your gmail account.
(In reply to comment #9)
> Could one or both of you try removing the following directories from your
> application's extensions directory?
> 
> {CAFEEFAC-0016-0000-0001-ABCDEFFEDCBA}
> {CAFEEFAC-0016-0000-0002-ABCDEFFEDCBA}
> 
> I suspect it is something to do with the Java Console hidden extension
> installed when installing the Sun JRE.
> 
Robert - I removed both directories mentioned above and restarted Firefox 3 times - no change. Add-ons still will not load.

Could you toggle the extensions.logging.enabled pref so it is true in about:config. Then restart and open the Error Console under the tools menu. There should be errors in there that reference the file nsExtensionManager.js. Copy and paste all of those into this bug report. Thanks!
Robert - I am not a developer and have limited programming knowledge. I did find the extensions.logging.enabled pref in the firefox.js file and changed it from false to true (words, not "1" and "0")but this resulted in irrelevant errors and I have changed it back. If you would be willing to educate a neophyte with more explicit directions, I would be happy to post the results.
What were the irrelevant errors?

Were there any messages info, warning, or errors in the Error Console immediately after starting up Firefox with the string nsExtensionManager.js in them. The string will usually be a file:// path ending with nsExtensionManager.js.
Robert - gave it another try with extensions.logging.enabled reset to "true" and the 2 directories in comment 11 removed. Let me know if you want the rest of the yahoo mail errors; however, the first one below meets your criteria:


ExtensionManager:_finishOperations - failure, catching exception - lineno: 3678 - file: file:///C:/Program%20Files/Mozilla%20Firefox/components/nsExtensionManager.js - TypeError: oldLocation has no properties

Error: uncaught exception: Permission denied to call method Location.toString

Error: mismatched tag. Expected: </meta>.
Source File: https://addons.update.mozilla.org/rss/?application=firefox&type=E&list=newest
Line: 14, Column: 3
Source Code:
</head>--^

Error: mismatched tag. Expected: </meta>.
Source File: https://addons.update.mozilla.org/rss/?application=firefox&type=E&list=newest
Line: 14, Column: 3
Source Code:
</head>--^

Warning: Unknown property '_padding-bottom'.  Declaration dropped.
Source File: http://my.yahoo.com/p/1.html
Line: 0

Error: no element found
Source File: http://us.mg1.mail.yahoo.com/dc/launch?.rand=9glrepft6t1qg
Line: 1, Column: 1
Source Code:
^

and a lot of "line 42" errors dealing with yahoo mail such as:

Warning: Unknown property 'line-spacing'.  Declaration dropped.
Source File: http://us.mg1.mail.yahoo.com/dc/launch?.rand=9glrepft6t1qg
Line: 42

Alan, when was it you installed Adblock Plus and do you remember getting an update for it or anything just previous to getting the firefox update?
Adblock and its updates have been installed since 2005. I think there was an adblock update just prior to the new release. However, no update problems on 3 other computers running firefox and adblock.
(In reply to comment #16)
> Alan, when was it you installed Adblock Plus and do you remember getting an
> update for it or anything just previous to getting the firefox update?
> 

Actually Alan ignore me, that question was for archaeopteryx

Interesting - I can still automatically load Yahoo mail "beta" when opening the browser on the computer I have been working on, but my other computers no longer can log on to "my" Yahoo mail beta since a "non-Yahoo program has modified the mail page" and gives a mail.yahoo url error message ending with a .js file name. When I retry, the Yahoo mail beta then opens. An Adblock Plus issue? (Adblock is set not to block mail.yahoo)
Yahoo Mail Beta experienced a login error:

name: ReferenceError
message:gExtContent is not defined
lineNumber:615
fileName: a long mail.yahoo launch? name

and 

name:TypeError
message: Q has no properties
lineNumber:111
fileName: another long mail.yimg.com file name ending in .js

When I "Click Here to Try Again", Yahoo mail beta then opens.

FWIW
Requesting blocking for this, it's a problem that seems to appear every time a new update comes out and I think I have enough information to at the very least solve the problem after it has occurred. That fix could likely be easily applied to the 1.8 branch as well.
Flags: blocking-firefox3?
Summary: add-ons and extensions failed to update/load after 9.18.2007 Firefox release installed → add-ons go into "needs to restart" loop commonly after a firefox update
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: nobody → dtownsend
Flags: blocking-firefox3? → blocking-firefox3+
Would like to get a fix for this into the next available branch release if possible.
Flags: blocking1.8.1.9?
Target Milestone: --- → Firefox 3 M10
Is a fix available for my 2.0.0.7 version? Or should I just uninstall Firefox and do a clean reinstall?
(In reply to comment #25)
> Is a fix available for my 2.0.0.7 version? Or should I just uninstall Firefox
> and do a clean reinstall?

Reinstalling will do nothing. If you delete the extensions.rdf, extensions.cache and extensions.ini files from your profile though it should sort itself out.
Deleting extensions.rdf, extensions.cache and extensions.ini from the profile subfolder fixed the problem. Thank you.
Attached patch patch rev 1 (obsolete) — — Splinter Review 
So I'm still drawing a blank figuring out exactly what could be causing this issue, however this should attempt to resolve it when it happens.

When performing the upgrade during the restart we don't really need to compare the install location in the startup cache against that in the rdf. The only way we set up for an upgrade is from _upgradeItem which sets the install location in the startup cache and the rdf to be the same so if we have something different then something has gone wrong.

Additionally even if we were to have different values we currently use the old value not the new value for performing the upgrade.

This ignores any value in the rdf, just using the location in the startup cache for to run the upgrade.

My current suspicion is that this bug is actually stemming from _finalizeUpgrade failing once, and then because oldLocation is invalid never getting tried again. What this change does is make _finalizeUpgrade get called again. Presumably this will just finish things off properly, it's possible though that whatever went wrong previously will go wrong again, but in this case it will be going wrong on every startup, which sounds a little worrying but shouldn't be any worse than currently and would mean we could get exception messages from the actual root problem from users if they continue to hit this.
Attachment #285374 - Flags: review?(robert.bugzilla)
Whiteboard: [has patch][need review robstrong]
Status: NEW → ASSIGNED
Dave, I'm going to run through some if the more edgecase scenarios before finishing the review. Things like the same global extension, profile extension, registry installed extension. Have you had the time to test the behavior of these scenaiors?
(In reply to comment #30)
> Dave, I'm going to run through some if the more edgecase scenarios before
> finishing the review. Things like the same global extension, profile extension,
> registry installed extension. Have you had the time to test the behavior of
> these scenaiors?

I have done some testing of those scenarios, specifically one in appdir and one in profile dir since I'm on mac I don't have the registry install location. I'm pretty sure that we still behave the same under normal conditions with this patch as without though I don't doubt that additional testing is a good thing given that we want this on branch. What I'm of course unsure about is the state we can get into with the same extension installed twice when this failure occurs.
(In reply to comment #1)
> I have the same problem. No add-ons will load or update since Firefox/2.0.0.8
> update. 
>
Flags: blocking1.8.1.9?
(In reply to comment #30)
> Dave, I'm going to run through some if the more edgecase scenarios before
> finishing the review. Things like the same global extension, profile extension,
> registry installed extension. Have you had the time to test the behavior of
> these scenaiors?
> 

I work on some testings here also, but so far i was not able to reproduce this. Still trying.
A couple of thoughts:

What do you think about updating the date/time stamp of the extension directory when performing a min/max Version sync? This would prevent the needs-upgrade on the majority of extensions since the code also updates the install.rdf and on some filesystems that is all that is needed for the date/time stamp to change.

It might also be a good time to remove the upgrade from 1.5 code which may be causing some of the problems. At the same time removing the old extensions datasource (e.g. profdir\extensions\Extensions.rdf), installed-extensions.txt, and Temp directory.

I believe should remove the staged-xpis directory during upgrade as long as it is after we show the compatibility wizard.

We have code to cope with invalid extension id's in that we ignore them and leave them behind. How about if they are removed during upgrade?

For 2.0.0.9 I'd like to flip extensions.logging.enabled back to true with the hope that we can actually find the cause of this bug.
One last thing I forgot to mention and hate to suggest. We can probably shim in detection of being in this unknown state (e.g. damn near all extensions having needs-upgrade) and fall back to removing the extensions.rdf, extensions.ini, and extensions.cache which appears to fix this consistently.
(In reply to comment #34)
> What do you think about updating the date/time stamp of the extension directory
> when performing a min/max Version sync? This would prevent the needs-upgrade on
> the majority of extensions since the code also updates the install.rdf and on
> some filesystems that is all that is needed for the date/time stamp to change.

That seems a sensible thing to be doing. To be honest I'm not all that keen on updating the install.rdf at all, it helps us out a little in the event that the extensions.rdf is lost but other than that I'm concerned with it causing problems.

> It might also be a good time to remove the upgrade from 1.5 code which may be
> causing some of the problems. At the same time removing the old extensions
> datasource (e.g. profdir\extensions\Extensions.rdf), installed-extensions.txt,
> and Temp directory.

I assume you mean the 1.0 code? I don't know of any 1.5 specific code. I'm not really sure the upgrade code itself is really a problem but removing the old Extensions.rdf regardless once the upgrade is done seems like a good idea.

> I believe should remove the staged-xpis directory during upgrade as long as it
> is after we show the compatibility wizard.

Sure

> We have code to cope with invalid extension id's in that we ignore them and
> leave them behind. How about if they are removed during upgrade?

Need to think about this, and I've had a few other thoughts that I need to run through over this.

> For 2.0.0.9 I'd like to flip extensions.logging.enabled back to true with the
> hope that we can actually find the cause of this bug.

Sure

(In reply to comment #35)
> One last thing I forgot to mention and hate to suggest. We can probably shim in
> detection of being in this unknown state (e.g. damn near all extensions having
> needs-upgrade) and fall back to removing the extensions.rdf, extensions.ini,
> and extensions.cache which appears to fix this consistently.

I don't like this idea at all. Even if we fix the datetime of the folders when we change install.rdf, just what is "damn near all"? What if I have just 2 extensions and I happen to have upgraded them both?

(In reply to comment #36)
> (In reply to comment #35)
> > One last thing I forgot to mention and hate to suggest. We can probably shim in
> > detection of being in this unknown state (e.g. damn near all extensions having
> > needs-upgrade) and fall back to removing the extensions.rdf, extensions.ini,
> > and extensions.cache which appears to fix this consistently.
> 
> I don't like this idea at all. Even if we fix the datetime of the folders when
> we change install.rdf, just what is "damn near all"? What if I have just 2
> extensions and I happen to have upgraded them both?
I don't like it one bit either but as a last ditch effort it would resolve this and as such should be considered. As for "damn near all" I was referring to what I've seen in the extensions.cache... as for how this could be implemented we could keep track of extensions that never successfully upgrade using any one of a number of methods with the simplest being using another file for keeping track.

My concern with the current patch and essentially only changing _finalizeUpgrade is that I've yet to see a report of this bug during normal operations which leads me to believe that it lies somewhere in checkForMismatches. It *might* help us locate the actual cause but I think we need to do a few more things especially around the upgrade code in checkForMismatches. Perhaps we should do a concall sometime in the next day and brainstorm for a bit about what else can be done?
(In reply to comment #36)
> That seems a sensible thing to be doing. To be honest I'm not all that keen on
> updating the install.rdf at all, it helps us out a little in the event that the
> extensions.rdf is lost but other than that I'm concerned with it causing
> problems.
Let's go over removing the update of the install.rdf as an option as well. The exact scenario that required this wasn't due to losing the extensions.rdf and I forgot the exact reason... I'll find the bug.
After much trial and error I still couldn't get my add ons to load. I tried everything and then reread this thread and did as Dave suggested, deleting extensions.rdf, extensions.cache and extensions.ini files. 

It worked! 

Thanks Dave!

(In reply to comment #38)
> (In reply to comment #36)
> > That seems a sensible thing to be doing. To be honest I'm not all that keen on
> > updating the install.rdf at all, it helps us out a little in the event that the
> > extensions.rdf is lost but other than that I'm concerned with it causing
> > problems.
> Let's go over removing the update of the install.rdf as an option as well. The
> exact scenario that required this wasn't due to losing the extensions.rdf and I
> forgot the exact reason... I'll find the bug.

I think I have a rough idea of why we are writing the new application data to the install manifest, but we aren't actually writing this to disk it seems. We just rely on the rdf service's datasource cache to give us an install manifest with the new compatibility info when we ask for it again. So I don't think this will be affecting the update detection at all.

(In reply to comment #37)
> (In reply to comment #36)
> > (In reply to comment #35)
> > > One last thing I forgot to mention and hate to suggest. We can probably shim in
> > > detection of being in this unknown state (e.g. damn near all extensions having
> > > needs-upgrade) and fall back to removing the extensions.rdf, extensions.ini,
> > > and extensions.cache which appears to fix this consistently.
> > 
> > I don't like this idea at all. Even if we fix the datetime of the folders when
> > we change install.rdf, just what is "damn near all"? What if I have just 2
> > extensions and I happen to have upgraded them both?
> I don't like it one bit either but as a last ditch effort it would resolve this
> and as such should be considered. As for "damn near all" I was referring to
> what I've seen in the extensions.cache... as for how this could be implemented
> we could keep track of extensions that never successfully upgrade using any one
> of a number of methods with the simplest being using another file for keeping
> track.

Well perhaps a simpler method would be to just do something if _finishOperations throws an exception. If it does then something has gone wrong so wipe the datasource and startup cache (maybe just trying to cache the disabled state of addons if we can) and rebuild from scratch. In this situation we could also log this exception to a file somewhere perhaps so we can pick it up off users later if they report issues with their extensions.

> My concern with the current patch and essentially only changing
> _finalizeUpgrade is that I've yet to see a report of this bug during normal
> operations which leads me to believe that it lies somewhere in
> checkForMismatches. It *might* help us locate the actual cause but I think we
> need to do a few more things especially around the upgrade code in
> checkForMismatches. Perhaps we should do a concall sometime in the next day and
> brainstorm for a bit about what else can be done?

I agree its restricted to the update case which certainly points to checkForMismatches. I would love to come up with a plausible explanation for the problem's root cause and fix that but although I have an idea of some steps that would leave us in the state we've seen, at least one step can't be explained short of something odd (out of memory, rdf/js bug, act of god) and I don't think the problem would be this widespread without a more rational explanation.

All the patch posted tries to do is recover once the problem has occurred.

(In reply to comment #40)
>...
> I think I have a rough idea of why we are writing the new application data to
> the install manifest, but we aren't actually writing this to disk it seems. We
> just rely on the rdf service's datasource cache to give us an install manifest
> with the new compatibility info when we ask for it again. So I don't think this
> will be affecting the update detection at all.
I've seen it written to the install.rdf numerous times. I recall that the patch was written prior to my writing the patch to update the updated targetapp min/max version info during an install of an incompatible extension and decided to go ahead and add it so people that copy profile extensions to a new profile wouldn't have to deal with a check for updates and then a restart to get their extensions working. We should go ahead and remove it to lessen the number of areas that might be causing this.

> (In reply to comment #37)
>...
> Well perhaps a simpler method would be to just do something if
> _finishOperations throws an exception. If it does then something has gone wrong
> so wipe the datasource and startup cache (maybe just trying to cache the
> disabled state of addons if we can) and rebuild from scratch. In this situation
> we could also log this exception to a file somewhere perhaps so we can pick it
> up off users later if they report issues with their extensions.
Exactly... not saying we have to do it one way or the other but having a last ditch effort for this state would IMO be a good thing.

> I agree its restricted to the update case which certainly points to
> checkForMismatches. I would love to come up with a plausible explanation for
> the problem's root cause and fix that but although I have an idea of some steps
> that would leave us in the state we've seen, at least one step can't be
> explained short of something odd (out of memory, rdf/js bug, act of god) and I
> don't think the problem would be this widespread without a more rational
> explanation.
Considering the number of users I think it just seems widespread and that this bug is hitting a low percentage of the total. For example, I have never seen this specific bug where it can't be reproduced on anything other than Windows users.
Dave, I am fine with the current patch but I think we should also do the following in addition to:
1) Set the extensions.logging.enabled to true for Firefox
2) Replacement of updateTargetAppInfo to use setTargetApplicationInfo so it no longer updates the install.rdf except in the one instance during an install where new compatibility info is required to perform the install.
3) Removal of the old Extensions.rdf in the extensions directory if it exists after _upgradeFromV10
4) Removal of installed-extensions.txt, and Temp directory inside the extensions directory.
5) Removal of staged-xpis after the datasource has been made consistent in checkForMismatches.

Number 4 is most likely not important as far as this bug is concerned but it might as well be done.

Does these sound like a good idea to you? Do you have any suggestions of additional tasks?

If you don't have time to do these let me know. Thanks!
Bah... do you think it would be worthwhile to disable the compatibility syncing on the branch for now?
(In reply to comment #41)
> (In reply to comment #40)
> >...
> > I think I have a rough idea of why we are writing the new application data to
> > the install manifest, but we aren't actually writing this to disk it seems. We
> > just rely on the rdf service's datasource cache to give us an install manifest
> > with the new compatibility info when we ask for it again. So I don't think this
> > will be affecting the update detection at all.
> I've seen it written to the install.rdf numerous times. I recall that the patch
> was written prior to my writing the patch to update the updated targetapp
> min/max version info during an install of an incompatible extension and decided
> to go ahead and add it so people that copy profile extensions to a new profile
> wouldn't have to deal with a check for updates and then a restart to get their
> extensions working. We should go ahead and remove it to lessen the number of
> areas that might be causing this.

Actually there is one case where we do write the updated install.rdf, but that is during the compatibility update check during an install of an addon:

http://mxr.mozilla.org/mozilla1.8/source/toolkit/mozapps/extensions/src/nsExtensionManager.js.in#4547

Here is a thought, the EM uses setItemProperty a /lot/ which is potentially a problem since it flushes extensions.rdf to disk each call (perf and maybe even file handling issues). So take _configureForthcomingItem f.e., it will write extensions.rdf to disk 7 times per call. Any failure in the middle of that leaves us in an inconsistent state which is I think what we're seeing.

Imagine somehow 20 add-ons have got into the needs-upgrade state somehow (this might be caused by the upgrade), on startup we then run _configureForthcomingItem for each, thats 140 flushes of the datasource. What if we're hitting some file handle limit during that?

We might be better off using _setProperty then flushing at the end once everything is in the datasource.

I don't recall reading a spec that defined how it saves but the following states:
http://www.xulplanet.com/tutorials/mozsdk/rdfsave.php
"In fact, RDF/XML loaded from a file URL tends to automatically save back to disk when the datasource itself is no longer being used."

I entirely agree that we should optimize the calls to setItemProperty so we don't flush so often in _configureForthcomingItem
(In reply to comment #45)
> I don't recall reading a spec that defined how it saves but the following
> states:
> http://www.xulplanet.com/tutorials/mozsdk/rdfsave.php
> "In fact, RDF/XML loaded from a file URL tends to automatically save back to
> disk when the datasource itself is no longer being used."

Yeah I checked the code, a datasource flushes itself in its destructor.

> I entirely agree that we should optimize the calls to setItemProperty so we
> don't flush so often in _configureForthcomingItem

I was thinking a setItemProperties on the ds that jsut took the list of properties and did the loop itself, but then it looks like the only places that do loops like that are _configureForthcomingItem and _upgradeItem, but both of those can be called during startup.
Attached patch patch rev2 (branch) (obsolete) — — Splinter Review 
The more I investigate this the more I think this is caused by all extension install.rdf files being modified during app upgrade and this causing them to be marked for needs-upgrade. I limited the patch to the original patch (plus one missing _finalizeUpgrade callsite from the original patch), the removal of updating the extension install.rdf files, and the cleanup of the obsolete files/dirs. I don't see much value in removing the staged-xpis dir so I didn't to lessen the risk of this patch.

In thinking about it I don't think we should flip the logging pref since this happens during startup and in the past it hasn't provided any info of value.

I think we should hold off on the changes to _configureForthcomingItem and _upgradeItem on the branch for now but we should do them on the trunk.
Assignee: dtownsend → robert.bugzilla
Attachment #285374 - Attachment is obsolete: true
Attachment #285972 - Flags: review?(dtownsend)
Attachment #285374 - Flags: review?(robert.bugzilla)
Whiteboard: [has patch][need review robstrong] → [has patch][need review dtownsend]
(In reply to comment #47)
> The more I investigate this the more I think this is caused by all extension
> install.rdf files being modified during app upgrade and this causing them to be
> marked for needs-upgrade. I limited the patch to the original patch (plus one
> missing _finalizeUpgrade callsite from the original patch), the removal of
> updating the extension install.rdf files, and the cleanup of the obsolete
> files/dirs. I don't see much value in removing the staged-xpis dir so I didn't
> to lessen the risk of this patch.

While I agree modifying the install.rdf certainly looks like a trigger for the problem I'm not so sure that its the only problem. All that should be doing is putting a lot of addons into needs-upgrade which we should be able to cope with.

The patch looks ok so far I just want to spend a little more time this morning testing and checking over it to be sure its ok for branch. I also have an additional thing that I think it would be worthwhile taking.
Comment on attachment 285972 [details] [diff] [review]
patch rev2 (branch)

Ok this looks good, patch looks right and testing all seems to work, install.rdf doesnt get touched by compatibility updates etc.
Attachment #285972 - Flags: review?(dtownsend) → review+
Attached patch failure logging (obsolete) — — Splinter Review 
What do you think of this in addition. It adds a simple extra logging function that allows us to log appropriately nasty errors out to a permanent log file. Just enabled in one place for now but that should catch any issues that are still causing problems.

Under normal operation the log file should never get written to, only in real problems should it happen and it could provide key information from users in those cases.
Attachment #285998 - Flags: review?(robert.bugzilla)
Comment on attachment 285998 [details] [diff] [review]
failure logging

>Index: toolkit/mozapps/extensions/src/nsExtensionManager.js.in
>===================================================================
>RCS file: /cvsroot/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in,v
>retrieving revision 1.144.2.62
>diff -u -8 -p -r1.144.2.62 nsExtensionManager.js.in
>--- toolkit/mozapps/extensions/src/nsExtensionManager.js.in	14 Sep 2007 19:59:42 -0000	1.144.2.62
>+++ toolkit/mozapps/extensions/src/nsExtensionManager.js.in	24 Oct 2007 11:11:16 -0000
>...
>+/**
>+ * Logs a string to the error console and to a permanent log file. 
>+ * @param   string
>+ *          The string to write out.
>+ */  
>+function ERROR(string) {
>+  LOG(string);
>+  try {
>+    var logfile = getFile(KEY_PROFILEDIR, [FILE_EXTENSIONS_LOG]);
>+    var stream = Components.classes["@mozilla.org/network/file-output-stream;1"]
>+                           .createInstance(Components.interfaces.nsIFileOutputStream);
>+    stream.init(logfile, 0x02 | 0x08 | 0x10, 0666, 0); // write, create, append
>+    var writer = Components.classes["@mozilla.org/intl/converter-output-stream;1"]
>+                           .createInstance(Components.interfaces.nsIConverterOutputStream);
>+    writer.init(stream, "UTF-8", 0, 0x0000);
>+    writer.writeString("*** " + string + "\n");
>+    writer.close();
>+    stream.close()
>+  }
>+  catch (e) { }
>+}
I like this especially for code that runs during startup but could you use windows line endings and is there any reason not to use Cc and Ci?

With that addressed r=me
Attachment #285998 - Flags: review?(robert.bugzilla) → review+
Comment on attachment 285972 [details] [diff] [review]
patch rev2 (branch)

drivers, both Dave and I tested this patch out and believe it is a safe approach to take for the branch.
Attachment #285972 - Flags: approvalM9?
Attachment #285972 - Flags: approval1.8.1.9?
Whiteboard: [has patch][need review dtownsend] → [has patch]
(In reply to comment #51)
>
> I like this especially for code that runs during startup but could you use
> windows line endings and is there any reason not to use Cc and Ci?
Sorry about that... Cc and Ci only for trunk. I better drink some coffee.
Comment on attachment 285972 [details] [diff] [review]
patch rev2 (branch)

This is larger and riskier than we want to take in 1.8.1.9, but let's get this into the trunk and the next security update
Attachment #285972 - Flags: approval1.8.1.9?
Attachment #285972 - Flags: approval1.8.1.9-
Attachment #285972 - Flags: approval1.8.1.10?
Dave, drivers are looking to minimize potential regressions and have asked for a minimal patch.
Attachment #286027 - Flags: review?(dtownsend)
Attachment #286027 - Flags: superreview?(dveditz)
Comment on attachment 286027 [details] [diff] [review]
minimal patch (checked in to trunk and GECKO181_20071004_RELBRANCH for 1.8.1.9)

Seth, the code removal is to no longer update an extension's install.rdf when it's targetApp min/max Version info changes.
Attachment #286027 - Flags: review?(dtownsend) → review?(sspitzer)
Bug 267906 comment #9 explains why it should be safe for this change
Comment on attachment 286027 [details] [diff] [review]
minimal patch (checked in to trunk and GECKO181_20071004_RELBRANCH for 1.8.1.9)

sr=dveditz (or 2nd r=)
Attachment #286027 - Flags: superreview?(dveditz)
Attachment #286027 - Flags: superreview+
Attachment #286027 - Flags: approval1.8.1.9?
Are we sure of all the callers into this function - e.g. we are not breaking a caller somewhere else...
(In reply to comment #59)
> Are we sure of all the callers into this function - e.g. we are not breaking a
> caller somewhere else...
Yes. I've double verified it and this is the same as the patch Dave tested and reviewed in relation to the removal of the updating of the install.rdf without the cleanup.
Comment on attachment 286027 [details] [diff] [review]
minimal patch (checked in to trunk and GECKO181_20071004_RELBRANCH for 1.8.1.9)

r=sspitzer.

to clarify:

with this lower risk version of the other patch, we no longer update the add-ons install.rdf except after updating the add-on.
Attachment #286027 - Flags: review?(sspitzer) → review+
Comment on attachment 286027 [details] [diff] [review]
minimal patch (checked in to trunk and GECKO181_20071004_RELBRANCH for 1.8.1.9)

approved for 1.8.1.9, a=dveditz for release-drivers

Please land on GECKO181_20071004_RELBRANCH and add the "fixed1.8.1.9" keyword
Attachment #286027 - Flags: approval1.8.1.9? → approval1.8.1.9+
We never update the extension's install.rdf. We do have one place where we update a temporary install.rdf when installing an extension that has an install.rdf that is incompatible and the extension's update datasource makes it compatible.
http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/extensions/src/nsExtensionManager.js.in#4272
Comment on attachment 286027 [details] [diff] [review]
minimal patch (checked in to trunk and GECKO181_20071004_RELBRANCH for 1.8.1.9)

Patch check in to GECKO181_20071004_RELBRANCH

Checking in mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in;
/cvsroot/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in,v  <--  nsExtensionManager.js.in
new revision: 1.144.2.62.4.1; previous revision: 1.144.2.62
done

We'll do a different patch for 1.8.1.10 (e.g. Firefox 2.0.0.10
Flags: blocking1.8.1.9? → blocking1.8.1.9+
Attachment #285972 - Flags: approval1.8.1.10?
Attachment #285998 - Flags: approvalM9?
Attachment #285998 - Flags: approvalM9?
Attachment #285972 - Flags: approvalM9?
Comment on attachment 286027 [details] [diff] [review]
minimal patch (checked in to trunk and GECKO181_20071004_RELBRANCH for 1.8.1.9)

M9 Endgame Drivers, I'd like to have this minimal patch that has already landed for 1.8.1.9 on the trunk for M9. It is about as safe as can be.
Attachment #286027 - Flags: approvalM9?
Comment on attachment 286027 [details] [diff] [review]
minimal patch (checked in to trunk and GECKO181_20071004_RELBRANCH for 1.8.1.9)

a=endgame drivers for M9 landing
Attachment #286027 - Flags: approvalM9? → approvalM9+
Comment on attachment 286027 [details] [diff] [review]
minimal patch (checked in to trunk and GECKO181_20071004_RELBRANCH for 1.8.1.9)

Checked in to trunk

Checking in mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in;
/cvsroot/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in,v  <--  nsExtensionManager.js.in
new revision: 1.258; previous revision: 1.257
done

Leaving this bug open for additional work to be done
Attachment #286027 - Attachment description: minimal branch patch → minimal patch (checked in to trunk and GECKO181_20071004_RELBRANCH for 1.8.1.9)
Attached patch trunk patch — — Splinter Review 
This is a combined patch of the previous two updated for trunk and also additional places where it calls the new file logging, basically most LOG calls that would be during startup are converted to ERRORs.

The error log has had a time added to the front so we can tell which errors are actually relevant as opposed to months old.

I'm thinking about truncating but Im not sure there is an easy way to cut off the first part of a file short of rewriting it, though I guess that's not out of the question.
Attachment #285972 - Attachment is obsolete: true
Attachment #285998 - Attachment is obsolete: true
Attachment #286181 - Flags: review?(robert.bugzilla)
Assignee: robert.bugzilla → dtownsend
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
> We'll do a different patch for 1.8.1.10 (e.g. Firefox 2.0.0.10

Until we get that different patch we should land this one on the 1.8 branch. Otherwise we end up regressing if we have a faster-than-expected turnaround on 2.0.0.10 such as we did at the end of 2.0.0.5 where we lopped off a week or two of dev time to accellerate some security fixes that were made public.
Attachment #286027 - Flags: approval1.8.1.10?
Comment on attachment 286027 [details] [diff] [review]
minimal patch (checked in to trunk and GECKO181_20071004_RELBRANCH for 1.8.1.9)

approved for 1.8.1.10, a=dveditz for release-drivers
Attachment #286027 - Flags: approval1.8.1.10? → approval1.8.1.10+
Flags: blocking1.8.1.10? → blocking1.8.1.10+
I'll go ahead and land it.
Checked in to MOZILLA_1_8_BRANCH

Checking in mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in;
/cvsroot/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in,v  <--  nsExtensionManager.js.in
new revision: 1.144.2.63; previous revision: 1.144.2.62
done

Leaving open for the additional work to be done on the trunk and to see if this does indeed fix things on the branch.
Keywords: fixed1.8.1.10
(In reply to comment #72)
> My PC is running Firefox 2.0.0.9 and I have the exact problems documented here in # 396695. I have grown tired of waiting for a new release with a fix, so I attempted to perform a normal removal of Firefox via Control Panel. When I re-installed Firefox, the SAME Firefox configuration appeared with all my add-ons installed saying  "will load when Firefox re-starts (which of course do not load at re-start)". If there will be a 2.0.1.0 release soon that fixes this problem, please tell me when it will be available. If the fix will not occur very soon, please tell me how to TOTALLY remove Firefox so that when I re-install I can start from scratch. Thank you very much.  
(In reply to comment #73)
> (In reply to comment #72)
> > My PC is running Firefox 2.0.0.9 and I have the exact problems documented here in # 396695. I have grown tired of waiting for a new release with a fix, so I attempted to perform a normal removal of Firefox via Control Panel. When I re-installed Firefox, the SAME Firefox configuration appeared with all my add-ons installed saying  "will load when Firefox re-starts (which of course do not load at re-start)". If there will be a 2.0.1.0 release soon that fixes this problem, please tell me when it will be available. If the fix will not occur very soon, please tell me how to TOTALLY remove Firefox so that when I re-install I can start from scratch. Thank you very much.  
> 

Repeat.
(In reply to comment #74)
> (In reply to comment #73)
> > (In reply to comment #72)
> > > My PC is running Firefox 2.0.0.9 and I have the exact problems documented here in # 396695. I have grown tired of waiting for a new release with a fix, so I attempted to perform a normal removal of Firefox via Control Panel. When I re-installed Firefox, the SAME Firefox configuration appeared with all my add-ons installed saying  "will load when Firefox re-starts (which of course do not load at re-start)". If there will be a 2.0.1.0 release soon that fixes this problem, please tell me when it will be available. If the fix will not occur very soon, please tell me how to TOTALLY remove Firefox so that when I re-install I can start from scratch. Thank you very much.  
> > 
> 
> Repeat.
> 

John - read comments 25, 26 and 27 and follow Dave's protocol in comment 26. This will solve the problem.
Robert, we have both keywords fixed1.8.1.9 and fixed1.8.1.10 set. I assume that we can remove fixed1.8.1.9? Or what fixes your first patch?
Version: unspecified → Trunk
(In reply to comment #76)
> Robert, we have both keywords fixed1.8.1.9 and fixed1.8.1.10 set. I assume that
> we can remove fixed1.8.1.9? Or what fixes your first patch?

No, as 1.8.1.9 and 1.8.1.10 were released from separate branches that this patch had to be individually landed on.
Version: Trunk → unspecified
Priority: -- → P1
It appears that dcamp may be affected by this bug *fingers crossed* and I will be taking a look at his system tomorrow.
Flags: blocking1.8.1.11+ → blocking1.8.1.10+
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Priority: P1 → P3
Can someone verify that this issue is fixed for 1.8.1.10 (or 1.8.1.9 for that matter)?
Not fixed in .9!!!

also i can't dl .10 auto, must web crawl for it...


If the patch that landed in .9 didn't fix it then .10 won't be fixed, it's the same patch.
(In reply to comment #81)
> Not fixed in .9!!!
> 
> also i can't dl .10 auto, must web crawl for it...
John, was it broken before you installed 2.0.0.9?
no it wasn't...

i took the update (.8) and it broke, then .9 and it's still broke, and i can't get .10 to fix it ether...

this is really bugging me, so much i'm using Opera now, come on FireFox, lets fix this, i can't even use my main browser, and have to resourt to **** alternitives like Opera...
The patch that landed at best might prevent this from happening and it definitely won't fix it if it already happened to you. We haven't been able to reproduce this bug otherwise we would be able to tell you if this will prevent it from happening again. To resolve this issue after it has happened follow the instructions in comment #26. Thanks
(In reply to comment #27)
> Deleting extensions.rdf, extensions.cache and extensions.ini from the profile
> subfolder fixed the problem. Thank you.
> 

where do i find these files?
Where your profile folder is located you'll find here: http://kb.mozillazine.org/Profile_folder_-_Firefox
I know this is already marked as major, but it doesn't seem to be treated as major. All of my existing Firefox Extensions no longer work, and I honestly can't believe this bug has been open since September and the problem is still not fixed. Mozilla has pushed out another two releases of the browser 2.0.0.8 and 2.0.0.9 to the public in the meantime.

This probably isn't the place to discuss how something like this got pushed out to the general public in the first place, but I see this as a major hit to Firefox's reputation as the stable browser.

I've put myself on the cc: list to follow the thread and find out when I can download an update that fixes this. I'll probably end up deleting the extensions files and crossing my fingers that it will work, but what about the millions of Firefox users who don't ready these bug reports? There needs to be a fix that fixes it for everyone through an automatic update.

(In reply to comment #89)
> I'll probably end up deleting the
> extensions files and crossing my fingers that it will work, but what about the
> millions of Firefox users who don't ready these bug reports? There needs to be
> a fix that fixes it for everyone through an automatic update.
> 

Oh don't worry, it didn't work, your just as bad as the general public...
(In reply to comment #89)
> This probably isn't the place to discuss how something like this got pushed out
> to the general public in the first place.

This actually isn't the place for any of your comment, it basically adds nothing to the discussion. It would be helpful if you could give some details of exactly what happened that caused your extensions to enter the "needs to restart" state, was it due to a firefox update? if so what version were you updating to?

(In reply to comment #90)
> Oh don't worry, it didn't work, your just as bad as the general public...

If removing the extensions.rdf extensions.cache and extensions.ini files didn't work then you may have some valuable information for us. Please do the following:

Type about:config into the address bar.
Find extensions.logging.enabled and toggle it to true.
Find javascript.options.showInConsole and toggle it to true.
Close any open webpages then shutdown Firefox using File - Exit.
Delete the extensions.rdf extensions.cache and extensions.ini files from your profile folder.
Startup Firefox.

Now if your extensions are still saying that they need to restart look in the error console and post any error messages listed there.

> (In reply to comment #90)
> > Oh don't worry, it didn't work, your just as bad as the general public...
> 
> If removing the extensions.rdf extensions.cache and extensions.ini files didn't
> work then you may have some valuable information for us. Please do the
> following:
> 
> Type about:config into the address bar.
> Find extensions.logging.enabled and toggle it to true.
> Find javascript.options.showInConsole and toggle it to true.
> Close any open webpages then shutdown Firefox using File - Exit.
> Delete the extensions.rdf extensions.cache and extensions.ini files from your
> profile folder.
> Startup Firefox.
> 
> Now if your extensions are still saying that they need to restart look in the
> error console and post any error messages listed there.
> 

There we go, THAT did it...

Thanks!

(In reply to comment #91)
> It would be helpful if you could give some details
> of exactly what happened that caused your extensions to enter the "needs to
> restart" state, was it due to a firefox update? if so what version were you
> updating to?

OK, more info:
* Running version 2.0.0.8 on Windows XP
* The last version of Firefox I manually downloaded was 2.0.0.4, the progression from .4 to .8 has been through automatic updates
* I know for a fact that my extensions were working 2 weeks ago, because I downloaded the SEOQuake extension and used it around November 1st
* Using Help > Check for Updates does not download 2.0.0.9 even though its apparently available

I'll upload a screenshot even.

Other than that, I can't say I did anything different or unusual to cause this to happen.

Removing the extensions.* files from my profile directory fixed it. I'd like to see a fix available through a normal upgrade however. So this issue isn't really solved.
Depends on: 404375
Filed bug 404375 to try to find a way to recover from this state
Here's the entry I get in my error log after upgrading to 2.0.0.9.  I do have a number of older extensions, but all have been working properly up through 2.0.0.8.  Deleting the three extension-related files does not help.  Hopefully this info helps out.

ExtensionManager:_finishOperations - failure, catching exception - lineno: 7368 - file: undefined - [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIRDFDataSource.Assert]"  nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame :: file:///E:/PROGRA~1/Mozilla%20Firefox/components/nsExtensionManager.js :: anonymous :: line 7368"  data: no]
(In reply to comment #96)
> Here's the entry I get in my error log after upgrading to 2.0.0.9.  I do have a
> number of older extensions, but all have been working properly up through
> 2.0.0.8.  Deleting the three extension-related files does not help.  Hopefully
> this info helps out.

This is potentially very useful information, thanks. Can you add the firefox user agent string from help - about and if you deleting those files isn't helping can you email a copy of them to me so I can look over them.
I've seen that when the install.rdf was missing required info so it might be due to writing to the install.rdf when sync'ing targetApp version info.
Yeah assuming that was from a windows build the error is coming from: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in&rev=1.144.2.63&mark=7299#7281

So that'd be an extension missing an id in a targetApplication section (or possible a requires but that's less likely). Not sure how we could be breaking an install.rdf like that with our code, though there is an oddity I can see in setTargetApplicationInfo. However of course since 2.0.0.9 we aren't doing that anymore so it's possible here the extension got broke with 2.0.0.8 but the breakage didnt take effect till the upgrade.
The error cited in comment #96 shows it is a Windows Build
file:///E:/PROGRA~1/Mozilla%20Firefox/components/nsExtensionManager.js ::
anonymous :: line 7368"  data: no]

In the past I have seen this with personal builds where the version.txt wasn't checked out and it was caused by an incorrectly formated / missing targetApplication minVersion and / or maxVersion
Yes, it's Windows XP SP2, fully patched.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9; .NET CLR 2.0.50727) Gecko/20071025 Firefox/2.0.0.9

Standard .exe download installed fairly recently (just built a new PC), updated through the automatic updater.  Using the saved profile from the old machine, in the same location.

I've uploaded the 3 files to http://files.invisibill.net/addonfiles.zip for anyone who wants to look.

I do have a LOT of extensions (9.5MB in my extensions dir), many of which are quite old (but worked fine on 2.0.0.8).  It's very possible it could be due to bad formatting in one of the files for an extension.

Some additional info...  Some of my addons do work correctly right now.  They seem to be the older ones which say they aren't compatible with 2.0.0.9.  Also, I have seen this (or a similar) issue in the past.  Sometimes I'd start Firefox to find all my addons disabled like this.  Usually disabling and re-enabling the addons once or removing and reinstalling Qute (the theme I always use) would fix it.  In the past, it seemed like something just got out of sync and "rebooting" it would fix everything.  This time, it seems more like the extension setup stuff isn't processing on restart.
If removing the extensions.rdf extensions.cache and extensions.ini files didn't
work then you may have some valuable information for us. Please do the
following:

Type about:config into the address bar.
Find extensions.logging.enabled and toggle it to true.
Find javascript.options.showInConsole and toggle it to true.
Close any open webpages then shutdown Firefox using File - Exit.
Delete the extensions.rdf extensions.cache and extensions.ini files from your
profile folder.
Startup Firefox.

Now if your extensions are still saying that they need to restart look in the
error console and post any error messages listed there.
=========

Tried all of the above! No luck - all my scripts are stuck in Restart mode. Really annoying...using 2.0.0.9 as well.

Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIRDFService.GetLiteral]"  nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame :: file:///C:/PROGRA~1/MOZILL~1/components/nsExtensionManager.js :: EM_L :: line 318"  data: no]
Source File: file:///C:/PROGRA~1/MOZILL~1/components/nsExtensionManager.js
Line: 318
FYI, I auto-upgraded to 2.0.0.10, and it appears to have interrupted that process as well.  I did get the "You have upgraded Firefox" page after restarting, but I still have the old version in my UA.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9; .NET CLR 2.0.50727) Gecko/20071025 Firefox/2.0.0.9
Had a report over IRC that this might be caused by an antivirus tool blocking access to some of the extension files during the update. The particular one used was Avira AntiVir http://www.free-av.de.
Auto updated to .11, still showing .9 in the UA...
See http://images.invisibill.net/fx_ua_9-11.png

I use McAfee Enterprise 8.0, not showing anything blocked at all.
InvisiBill - please file a separate bug for the user agent issue.
Whiteboard: [has patch] → [has patch][needs review rob_strong]
We are going to move the additional patch into another bug since so far the reports on this issue have significantly lessened and the reports there have been have been due to previous corruption.
Whiteboard: [has patch][needs review rob_strong]
Comment on attachment 286181 [details] [diff] [review]
trunk patch

Dave, could you submit these changes in bug 406718? Thanks
Attachment #286181 - Flags: review?(robert.bugzilla) → review-
Resolving... we are going to try to get bug 404375 fixed in 2.0.0.12 to try to recover from this state.
Assignee: dtownsend → robert.bugzilla
Status: ASSIGNED → NEW
Target Milestone: Firefox 3 M11 → Firefox 3 M9
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: