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.

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

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

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

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.

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.