Closed
Bug 257681
Opened 20 years ago
Closed 20 years ago
[AviaryBranch] interfaces & components defined in our extension are not being registered correctly. First occurance 09/01/2004
Categories
(Toolkit :: Add-ons Manager, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 258123
People
(Reporter: richwklein, Assigned: bugs)
Details
(Keywords: regression)
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040831 Firefox/0.9.1+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040831 Firefox/0.9.1+ We have an extension http://weatherfox.mozdev.org/ that uses an javascript xpcom object as its backend. It worked on the 8/31 build of aviarybranch, but not the 9/1 build. It looks like the component is getting registered and shows, but the interface we defined does not show up using Robert Ginda's XPCOM Component Viewer. We also get an error thrown BAD_IID Reproducible: Always Steps to Reproduce: 1. 2. 3.
Reporter | ||
Comment 1•20 years ago
|
||
Fixing some typos in the summary. Sorry for the spam.
Summary: [AviaryBranch] interfaced defined in extensions are not being registered. First Occurance 09/01/2004 → [AviaryBranch] interfaces defined in our extension are not being registered correctly. First occurance 09/01/2004
Comment 2•20 years ago
|
||
The extension needs to be updated to FF1.0+ (new maxversion) It's probably FF0.9.1+ right now.
Comment 3•20 years ago
|
||
We have it set to max version .10
Reporter | ||
Comment 4•20 years ago
|
||
Adding the other developer to the cc list. The extension itself is registered fine. It is our interface that is the problem.
Comment 5•20 years ago
|
||
I can confirm that the weatherfox extension registered properly and that the components did not. Also, copying the weatherfox components from the extension's components directory to the application's components directory and forcing a re-registration fixes the problem (e.g. the extension then works properly).
This may be a regression from the patch for bug 252543 (checked in as part of the giant patch in bug 257304 ).
Comment 8•20 years ago
|
||
Could you add a word "components" to the summary please? And severity should be major or critical If I understood correctly, there is a testcase attached to bug 258123
Comment 9•20 years ago
|
||
*** Bug 258123 has been marked as a duplicate of this bug. ***
Comment 10•20 years ago
|
||
Comment 11•20 years ago
|
||
Source code can be compiled from mozilla/extensions
Comment 12•20 years ago
|
||
In addition to comment #8, I suggest to change the severity to ciritcal and the component to Extension/Theme manager.
Reporter | ||
Comment 13•20 years ago
|
||
Changing to severity and component.
Severity: normal → critical
Component: General → Extension/Theme Manager
Reporter | ||
Comment 14•20 years ago
|
||
Adding component to summary.
Summary: [AviaryBranch] interfaces defined in our extension are not being registered correctly. First occurance 09/01/2004 → [AviaryBranch] interfaces & components defined in our extension are not being registered correctly. First occurance 09/01/2004
Updated•20 years ago
|
Keywords: regression
Updated•20 years ago
|
Assignee: firefox → bugs
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR+
Comment 15•20 years ago
|
||
critical is dataloss/crashing/hang etc. This is major.
Severity: critical → major
Assignee | ||
Comment 16•20 years ago
|
||
I sent this mail to darin, shaver and bsmedberg: Recently we changed the way extension components are registered to fix a couple of bugs, specifically: - upgrading or uninstalling an extension with a component does not work, since the uninstall/replace operation is performed after the EM (and thus XPCOM) has been started and components registered and loaded, so the files in question cannot be removed/replaced because the files are busy. - when a user upgrades the app, before checkForMismatches is run incompatible components get a chance to run because extensions are not disabled until after XPCOM has been started and potentially harmful incompatible components loaded. The solution was seen to be as follows: - defer registration of extension ("extra") components until after the extension manager has started and mismatch/install/uninstall operations have been completed. This ensures that these operations are only performed with the baseline set of components and no others and that uninstall/replace/etc operations can perform safely. Unfortunately, a side effect has resulted in bug 257681. When I call AutoRegister on nsIComponentRegistrar after the fact components in the location specified are registered and added to compreg.dat, but xpt files in that location are not registered and added - this appears to be because the xptiInterfaceInfoManager was started when XPCOM started as a singleton, its search path created at that time and never re-created. We need a way to either tell xptiInterfaceInfoManager about changes to its search path (extension components dirs should be inserted at the start of it) or make it discover such changes itself when AutoRegisterInterfaces is called. This is a nasty bug that is preventing extensions from being able to use components. We need some sort of solution here for PR. I can think of a few off hand - but want to know from XPCOM components folk what seems best. Feel free to poke me on IRC to discuss.
Status: NEW → ASSIGNED
Comment 17•20 years ago
|
||
See the patch in http://bugzilla.mozilla.org/show_bug.cgi?id=154272 and test to see if that kind of codepath helps.
That kind of codepath should work, by my cursory analysis, as long as the EM has written the new components.ini correctly before calling into AutoRegisterInterfaces (and therefore into nsXREDirProvider::GetFiles' NS_XPCOM_COMPONENT_DIR_LIST case). Ben: is that so? If not, can you make it so?
Assignee | ||
Comment 19•20 years ago
|
||
Going to dup off 258123 since it has a patch *** This bug has been marked as a duplicate of 258123 ***
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Updated•20 years ago
|
Flags: blocking-aviary1.0PR+
Updated•16 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•