528623 - Changes to components.list are not applied (inconsistent caching in profiles compreg.dat)

Status: RESOLVED INVALID

(Core :: XPCOM, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b3pre) Gecko/20091113 Namoroka/3.6b3pre GTB5 (.NET CLR 3.5.30729) ID:20091113124046

If changes have to be made to components.list those are not reflected after the next start of Firefox because the compreg.dat in the users profile will not be updated and still reflects the former state.

That could cause trouble if an extension installs it's own modules in this folder and adds those files to components.list. After the next update we will replace that file and remove those entries. But the modules will still be loaded.

Steps:
1. Start a Minefield/Namoroka build which has the components.list included
2. Open http://people.mozilla.org/~jmaher/wifi.html to check the geo location feature
3. Shutdown the application and remove the NetworkGeolocationProvider.js entry
4. Start the application and repeat step 2.

As result the geo location component is still enabled.

Comment 1

[Dave Townsend [:mossop]]

We should regenerate compreg.dat whenever we update the app which is the only time we can change components.list I believe so I'm not sure there is a problem here. You can try altering the build id in compatibility.ini in the profile or application.ini in the app before making a manual change to verify that.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

That would be interesting. It's a kinda self-protection against other applications which try to put their modules in our components folder. Those modules will never be loaded except the case the application performs it right before the first start of Firefox or a user creates a new profile.

Comment 3

[Dave Townsend [:mossop]]

(In reply to comment #2)
> That would be interesting. It's a kinda self-protection against other
> applications which try to put their modules in our components folder. Those
> modules will never be loaded except the case the application performs it right
> before the first start of Firefox or a user creates a new profile.

I don't think that is true. We should pick up new, removed or changed components on every run, but we completely refresh the components list during an app update.

Comment 4

[Dave Townsend [:mossop]]

(In reply to comment #3)
> (In reply to comment #2)
> > That would be interesting. It's a kinda self-protection against other
> > applications which try to put their modules in our components folder. Those
> > modules will never be loaded except the case the application performs it right
> > before the first start of Firefox or a user creates a new profile.
> 
> I don't think that is true. We should pick up new, removed or changed
> components on every run, but we completely refresh the components list during
> an app update.

Correction. On a regular startup (app hasn't changed) we will attempt to register any dll/js files that we have not cached components from in the past. In the app dir that only includes whitelisted dll/js files. If we fail to register any components from a dll/js file because the blacklist stops us loading it, or it is broken, then we should try to re-register it on every startup. On a startup where the app build ID has changed we should wipe the component registry and attempt to re-register everything fresh.

Comment 5

[Dave Townsend [:mossop]]

Note that bug 528651 is currently causing is to attempt to re-register everything on every startup on trunk builds.

Comment 6

[Benjamin Smedberg]

As filed this bug is not valid. We don't need to obey changes to components.list which happen between app updates which change the buildID and force general re-registration.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Do we have informed any of the add-ons or software vendors who place some of their files into our components folder? If not we would also break compatibility for those software packages. Changes like that shouldn't happen for builds later than the first beta, right? It's clearly a late-compat issue.

Comment 8

[Benjamin Smedberg]

What has comment 7 got to do with this bug? Did you mean to comment in bug 519357 instead? We are *intentionally* breaking addon/software vendors who place stuff in the application components folder, because they shouldn't ever be doing that. If they are dynamically changing stuff in their extension components folder, the components.list shouldn't affect them at all.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Oh, that really went into the wrong bug. Sorry.