406118 - Extension manager blocklist is broken

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect, P2)

Description

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

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.

Comment 1

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

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

Comment 2

[Benjamin Smedberg]

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?

Comment 3

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

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.

Comment 4

[Benjamin Smedberg]

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

Comment 5

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

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.

Comment 6

[Benjamin Smedberg]

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?

Comment 7

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

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.

Comment 8

[Tony Chung [:tchung]]

rob, benjamin, does this affect the blocklisting plugin behavior also?  if so, we'll need to note this in our regression testing as well.

Comment 9

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

If this affects blocklisting, it's at least P2, if not P1.

Comment 10

[Dave Townsend [:mossop]]

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.

Comment 11

[Dave Townsend [:mossop]]

Attachment: 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 :)

Comment 12

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

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

a1.9b4=beltzner

Comment 13

[Dave Townsend [:mossop]]

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

Comment 14

[chris hofmann]

> 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.