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)

x86
Windows XP
defect
Not set
major

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.
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
The extension needs to be updated to FF1.0+ (new maxversion)
It's probably FF0.9.1+ right now.
We have it set to max version .10
Adding the other developer to the cc list.  The extension itself is registered
fine.  It is our interface that is the problem.
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 ).
Requesting blocking 1.0PR
Flags: blocking-aviary1.0PR?
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
*** Bug 258123 has been marked as a duplicate of this bug. ***
Attached file XPI showing the bug
Source code can be compiled from mozilla/extensions
In addition to comment #8, I suggest to change the severity to ciritcal and the
component to Extension/Theme manager.
Changing to severity and component.
Severity: normal → critical
Component: General → Extension/Theme Manager
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
Keywords: regression
Assignee: firefox → bugs
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR+
critical is dataloss/crashing/hang etc.  This is major.
Severity: critical → major
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
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?
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
Flags: blocking-aviary1.0PR+
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: