Spinoff of bug 382356. Per 382356 comment #44 > rob, can you file a separate bug for that? I think we have a case where, on > upgrade, we're reading the "old" extensions.ini from the profile... we'll need > to come up with a reasonable heuristic for removing/ignoring this file in some > set of circumstances. The .autoreg file should be in the profile at this time and should be adequate to prevent this.
I just verified that when an extension is disabled via the UI prior to the restart that the extensions.ini is immediately updated so this doesn't appear to be due to reading the extensions.ini... changing summary
Summary: Startup is reading the extensions.ini / loading newly disabled extensions on launch after disabling an extension → Startup is loading newly disabled extensions on launch after disabling an extension
So I'm confused about the "steps to reproduce"... I thought we were talking about * The user installs a new Firefox 3 * On initial startup, Firefox loads a stale extensions.ini or compreg.dat which causes us to load an incompatible component In this case we haven't even gotten to the EM yet, so how does disabling from the UI factor into this bug?
I believe The failure case that morgamic brought up in bug 382356 is where an already installed extension is disabled via blocklisting. After the extension has been app disabled the EM performs essentially the same steps as when using the ui to disable an extension. From my comment, it would appear to be due to reading a stale compreg.dat and I haven't verified that this is the case since I didn't perform the additional steps to verify that blocklisting in fact updated the extensions.ini and added the .autoreg file though I am quite sure it does.
So there are two possible causes, right? 1) EM writes the .autoreg file but apprunner doesn't see it properly 2) EM fails to write the .autoreg file
I'd also include the update to the extensions.ini in those. I'll get a hold of the IDM extension that causes this and try to figure out what is going on as far as the EM.
Yeah... I suspect that this is a general problem, not specific to IDM... could we try it with a "null extension" with a dummy JS component and see what ends up in compreg/extensions.ini at each step?
Sure, I figured I'd just use the IDM one so I can test it being blocklisted but any extension with a component can be used to test this.
rob, benjamin, does this affect the blocklisting plugin behavior also? if so, we'll need to note this in our regression testing as well.
If this affects blocklisting, it's at least P2, if not P1.
Priority: P3 → P2
I've tested this with a js component and I can't reproduce any issue with it. Specifically I wrote an extension with a js component that listens for xpcom-startup and app-startup logging messages on each as well as on the NSGetModule call. On normal startup it logs fine. I then pointed Firefox to a custom blocklist. As soon as the warning about a blocked extension appears the extensions.ini file had been updated to remove the extension and .autoreg had been created. On restart the component never logs anything.
Created attachment 306532 [details] [diff] [review] patch rev 1 So the problem is actually that the blocklist is just completely broken for the main case we use it, i.e. checking if something is blocked for the current version of the app. Turns out undefined doesn't works so well across to the xpcom component the blocklist service was split into. Switch to nulls and all is good. Threw in a unit test for good measure. Testing with the IDM extension and it will correctly fail to install in Firefox 3 with this and on upgrading from 2 to 3 will block it and no crashing :)
Assignee: nobody → dtownsend
Status: NEW → ASSIGNED
Attachment #306532 - Flags: review?(robert.bugzilla)
Comment on attachment 306532 [details] [diff] [review] patch rev 1 a1.9b4=beltzner
Attachment #306532 - Flags: approval1.9b4? → approval1.9b4+
Checking in toolkit/mozapps/extensions/public/nsIBlocklistService.idl; /cvsroot/mozilla/toolkit/mozapps/extensions/public/nsIBlocklistService.idl,v <-- nsIBlocklistService.idl new revision: 1.2; previous revision: 1.1 done Checking in toolkit/mozapps/extensions/src/nsBlocklistService.js; /cvsroot/mozilla/toolkit/mozapps/extensions/src/nsBlocklistService.js,v <-- nsBlocklistService.js new revision: 1.9; previous revision: 1.8 done Checking in toolkit/mozapps/extensions/src/nsExtensionManager.js.in; /cvsroot/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in,v <-- nsExtensionManager.js.in new revision: 1.276; previous revision: 1.275 done RCS file: /cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/test_bug406118.js,v done Checking in toolkit/mozapps/extensions/test/unit/test_bug406118.js; /cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/test_bug406118.js,v <-- test_bug406118.js initial revision: 1.1 done
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Summary: Startup is loading newly disabled extensions on launch after disabling an extension → Extension manager blocklist is broken
Whiteboard: [has patch]
Flags: tracking1.9+ → blocking1.9+
> Testing with the IDM extension and it will correctly fail to install in Firefox 3 with this and on upgrading from 2 to 3 will block it and no crashing :) still having some problems with blocking the IDM extension over in bug 382356 and crashes have appeared in fx3 b4. still trying to track down where problems might lie. any thoughts appreciated.
Component: XRE Startup → Startup and Profile System
QA Contact: xre.startup → startup
You need to log in before you can comment on or make changes to this bug.