Closed Bug 299652 Opened 20 years ago Closed 15 years ago

xpcom-startup notification can trigger loading of uninstalling/ed component

Categories

(Toolkit :: Add-ons Manager, defect)

Product:
Toolkit
Component:
Add-ons Manager
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla2.0b2

People

(Reporter: shaver, Unassigned)

References

Details

(Whiteboard: [AOMTestday])

(Saw this with Tbird, but there's no component there, nor one in core!) I had a file in $profile/extensions with the path to my Lightning build. I needed to uninstall it because it was causing the most recent nightlies to crash on startup (nsACString symbol mismatch), so I deleted the file. When I start Tbird, though, it still tries to load those components, because we have an xpcom-startup observer, which references the native libs, etc. Should we be firing xpcom-startup before the extension manager has rejigged the component path, etc.? Manually removing the entry from extensions.ini let it start up, notice that the path-file was gone, and get on with its life. I suspect that removing compreg.dat would have done the same.
Mike, you can uninstall the extension's pointer file by selecting uninstall from the EM ui and this will add the .autoreg file which will cause the compreg.dat to be rebuilt. Doesn't solve the problem for the case where the pointer is removed manually which is an edgecase IMO.
cc'ing bsmedberg. Benjamin, what ya' think?
The problem is that EM is a XPCOM component itself... and it is not something that NS_InitXPCOM2 knows about. One solution would be to make XRE_Main validate the paths in extensions.ini before initializing XPCOM. If it finds that the paths have changed, then it can startup with all extensions disabled, load EM, and let EM figure out what to do about it.
That sounds like too much trouble/code for a situation that only occurs during testing
It is a lot of work (is there an easier solution?), but this problem extends beyond testing. What if there are complex relationships between extensions that result in badness when one of them is suddenly not there? The EM is designed to handle manual removal as equivalent to uninstall.
Can you provide a scenario that would cause this bad behavior that dependencies doesn't solve?
Rob: I don't know how 'dependencies' are designed, but if it involved loading nsExtensionManager.js, then I don't think it would help. Here's a concrete example: Imagine if someone writes an extension that overrides some built-in service or component. For arguments sake, let's say that it is something low-level in necko, like the IO service. Now, imagine that the extension is suddenly not there, but compreg.dat says that the IO service is implemented by a ClassID in foobar.dll, but foobar.dll does not exist! What happens to the app?
If an extension is set to be disabled or uninstalled then it will also set all extensions that depend on it to be disabled before restart and the .autoreg is generated, etc. The suddenly not there scenario should only happen when manually removing extensions.
> The suddenly not there scenario should only happen when > manually removing extensions. Which is how extensions are removed when they are registered via the windows registry (via a third-party installer). For example, people may use a MSI installer to insert extensions into a directory and set the registry keys to "install" their extension. When they wish to remove their extension, they remove the registry key and blow away the directory.
Which is why I wish I was more involved when the registry location was added... handling cases that aren't fully managed by the EM are just a PITA. It seems it would be simpler / faster to just enumerate the registry install locations on startup to see if there are changes (perhaps dir existence / last modified time?) especially since there are very few extensions that use registry install locations. We could add code to do the right thing from that point.
Hmmm... what about the portable use case especially if we support additional install locations as per bug 311008?
We currently do that enumeration of the registry in EM code. We'd need to do it before NS_InitXPCOM2. I don't see why we couldn't just enumerate extensions.ini from nsAppStartup.cpp instead. It isn't much different.
Product: Firefox → Toolkit
This is fixed with the extension manager rewrite, also the new component registration makes it impossible to load extension components before profile-after-change now.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Dave, do we have a bug # for this fix? Also, how can it be tested? I assume it's something we also have to do with Mozmill?
Dave, how can the underlying issue be tested? Is there a known extension, which I could use to test the specific situation covered by this bug?
Depends on: data-driven-compreg
Flags: in-testsuite?
Flags: in-litmus-
OS: Mac OS X → All
Hardware: PowerPC → All
Whiteboard: [AOMTestday]
Target Milestone: --- → mozilla2.0b2
(In reply to comment #15) > Dave, how can the underlying issue be tested? Is there a known extension, which > I could use to test the specific situation covered by this bug? e no longer call xpcom-startup for installed or uninstalled extensions, I guess you could test that but it wouldn't really verify the issue here.
Means a situation like this cannot happen with the profile-after-change notification?
(In reply to comment #17) > Means a situation like this cannot happen with the profile-after-change > notification? Right
Thanks Dave. So marking as verified fixed based on the changes happened to the component registration and the observers.
Status: RESOLVED → VERIFIED
Flags: in-testsuite? → in-testsuite-
You need to log in before you can comment on or make changes to this bug.