253136 - Need a way to give XPCOM components precedence over others registered with the same contract ID

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect)

Description

[Christopher Aillon (sabbatical, not receiving bugmail)]

Currently, if you have two XPCOM components registered with the same contract
ID, the last one to register wins when creating an instance using foo contract ID.

In the case of the GTK2.4 file chooser which needs to do a run-time check to see
if it can load the proper symbols, and defer to the XUL file chooser if not, I
need to have my factory constructor called FIRST.

I can make that work for clobber builds by returning
NS_ERROR_FACTORY_REGISTER_AGAIN which will force the GTK2.4 file chooser to
re-register after everything else, thereby giving it the last registration and
winning when asked for the contract ID.  But if someone rebuilds in a chrome
directory which causes the XUL picker to get repackaged, it will re-register at
next startup, and the native file picker component will not get called.

I need a way to tell XPCOM that the native component should always be tried
first.  Additionally, if a failover mechanism can be implemented, then I can get
rid of the CreateInstance(xulFilePickerClassID) call in my native factory
constructor.

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

or you could #ifdef the registration of a contract id for the XP filepicker, so
that it doesn't get a contractid for gtk2 builds

Comment 2

[Christopher Aillon (sabbatical, not receiving bugmail)]

(In reply to comment #1)
> or you could #ifdef the registration of a contract id for the XP filepicker, so
> that it doesn't get a contractid for gtk2 builds

The point is that mozilla.org wants one to be able to build against gtk2.4, and
have users running gtk2.0 get the xul file chooser (2.4 users get the native
chooser).  And one should be able to build with gtk 2.0, and allow users who are
running that build on gtk 2.4 to get the native gtk file chooser (those who
don't get the xul chooser).

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #2)
> The point is that mozilla.org wants one to be able to build against gtk2.4, and
> have users running gtk2.0 get the xul file chooser (2.4 users get the native
> chooser).  And one should be able to build with gtk 2.0, and allow users who are
> running that build on gtk 2.4 to get the native gtk file chooser (those who
> don't get the xul chooser).

Yes. Exactly. My suggestion should give you that - since the XP (XUL) filepicker
would not have a contract id, your gtk2 filepicker would be chosen, and it would
create the XUL filepicker by CID if needed.

Comment 4

[Christopher Aillon (sabbatical, not receiving bugmail)]

Oh, I see what you're saying.  That looks, feels, and smells like a hack.  I'd
much rather see the solution proposed in comment 0 implemented over your
suggestion.  There are of course, multiple suggestions to how to fix the file
chooser issue.  Another would be to have native-filepicker and xul-filepicker
contractids, and have code try both.  But that again is a hack, IMO.

Note that this bug is not really intended to be a "how to fix the dual
contractid issue with the filepicker" bug.  I proposed (well, actually its
shaver's idea) a specific solution, and would like to see discussion on that
solution.

Comment 5

[Doug Turner (:dougt)]

Yes, this is a problem that needs addressing.  It is more than just precedence,
but it is also the ablity to replace then at a later time remove a component
that overrides an existing contract id.  There are work arounds, as mentioned in
this bug and ones that I have seen in the field, but XPCOM should simply should
provide better support for this.