Closed
Bug 528623
Opened 15 years ago
Closed 15 years ago
Changes to components.list are not applied (inconsistent caching in profiles compreg.dat)
Categories
(Core :: XPCOM, defect)
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.
Reporter | ||
Updated•15 years ago
|
Flags: blocking1.9.2?
Comment 1•15 years ago
|
||
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.
Reporter | ||
Comment 2•15 years ago
|
||
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•15 years ago
|
||
(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•15 years ago
|
||
(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•15 years ago
|
||
Note that bug 528651 is currently causing is to attempt to re-register everything on every startup on trunk builds.
Comment 6•15 years ago
|
||
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: 15 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 7•15 years ago
|
||
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•15 years ago
|
||
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: 15 years ago → 15 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 9•15 years ago
|
||
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.
Description
•