257681 - [AviaryBranch] interfaces & components defined in our extension are not being registered correctly. First occurance 09/01/2004

Status: RESOLVED DUPLICATE of bug 258123

(Toolkit :: Add-ons Manager, defect)

Description

[Richard Klein]

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.

Comment 1

[Richard Klein]

Fixing some typos in the summary.  Sorry for the spam.

Comment 2

[Peter van der Woude [:Peter6]]

The extension needs to be updated to FF1.0+ (new maxversion)
It's probably FF0.9.1+ right now.

Comment 3

[Jon Stritar]

We have it set to max version .10

Comment 4

[Richard Klein]

Adding the other developer to the cc list.  The extension itself is registered
fine.  It is our interface that is the problem.

Comment 5

[Robert Strong (they/them - no direct email)]

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).

Comment 6

[:Mook]

This may be a regression from the patch for bug 252543 (checked in as part of the giant patch in bug 257304 ).

Comment 7

[Richard Klein]

Requesting blocking 1.0PR

Comment 8

[Nickolay_Ponomarev]

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

[Patrick Brunschwig]

*** Bug 258123 has been marked as a duplicate of this bug. ***

Comment 10

[Patrick Brunschwig]

Attachment: XPI showing the bug

Comment 11

[Patrick Brunschwig]

Attachment: Source Code for example XPI

Source code can be compiled from mozilla/extensions

Comment 12

[Patrick Brunschwig]

In addition to comment #8, I suggest to change the severity to ciritcal and the
component to Extension/Theme manager.

Comment 13

[Richard Klein]

Changing to severity and component.

Comment 14

[Richard Klein]

Adding component to summary.

Comment 15

[Mike Connor [:mconnor]]

critical is dataloss/crashing/hang etc.  This is major.

Comment 16

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 17

[Benjamin Smedberg]

See the patch in http://bugzilla.mozilla.org/show_bug.cgi?id=154272 and test to
see if that kind of codepath helps.

Comment 18

[Mike Shaver (:shaver emeritus)]

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?

Comment 19

[Ben Goodger (use ben at mozilla dot org for email)]

Going to dup off 258123 since it has a patch

*** This bug has been marked as a duplicate of 258123 ***