Closed Bug 528623 Opened 13 years ago Closed 13 years ago

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

Categories

(Core :: XPCOM, defect)

1.9.1 Branch
defect
Not set
major

Tracking

()

RESOLVED INVALID

People

(Reporter: whimboo, Unassigned)

References

Details

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.
Flags: blocking1.9.2?
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.
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.
(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.
(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.
Note that bug 528651 is currently causing is to attempt to re-register everything on every startup on trunk builds.
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.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
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.
Status: RESOLVED → REOPENED
Keywords: late-compat
Resolution: INVALID → ---
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.
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → INVALID
Oh, that really went into the wrong bug. Sorry.
Flags: blocking1.9.2?
Keywords: late-compat
You need to log in before you can comment on or make changes to this bug.