267351 - nsIDOMParser mismatch between firefox and mozilla

Status: RESOLVED WONTFIX

(Core :: XML, defect)

Description

[CREPLET Nicolas]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

In mozilla xpti.dat
you get 748,nsIDOMParser,{d347c6c0-5129-11d4-9a54-000064657374},42,-1,1

In firefox xpti.dat
you get 242,nsIDOMParser,{4f45513e-55e5-411c-a844-e899057026c1},0,-1,1

So my plugin which require the nsIDOMParser service with the IID of mozilla 
doesn't work in firefox.

Reproducible: Always
Steps to Reproduce:
See details for explanation.

Comment 1

[CREPLET Nicolas]

Actually this mismatch is not present in Firefox 0.9.3.
This problem occurs in Firefox 1.0PR.

Comment 2

[CREPLET Nicolas]

Actually, this mismatch has appeared between Firefox 0.9.3 and 1.0PR.

Comment 3

[Bernard Alleysson]

I can't see any FROZEN statement in nsDOMParser.idl so maybe you shouldn't use
that interface. If you need it you should request it to be frozen.

Moreover, IID was changed by (no bug number):
1.11	vladimir%pobox.com	2004-09-20 21:25	 	wrong IID; this one matches aviary
and 1.7

So I would say that if IID is the same between Mozilla trunk and 1.7/aviary like
 it seems to be then it was a bug that got fixed, as the checkin comment implies.

Comment 4

[Bernard Alleysson]

CC vladimir who should know about this

Comment 5

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

the change was for bug 253954

only interfaces marked as frozen are guaranteed to be unchanged. the rest can
and do get changed occasionally.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Note that the next non-security 1.7 release will have the api Firefox 1.0 has...
1.7.3 was released from the mini-branch, which doesn't include a lot of the
aviary changes.

Comment 7

[Daniel Veditz [:dveditz]]

Realistically I think it's safe to say we're not going to change this interface
back so close to the Firefox release, and that this difference will remain
between shipped versions of Mozilla.

The IID change is so your code could conceivably tell which version of the
interface it's getting and make the appropriate calls on it, if you must use
this interface and must support various versions of Mozilla. It's a PITA for
you, of course, but that's kind of the risk of using internal interfaces.

Depending on what you're doing there may be some other way to get there using
supported interfaces that won't be changing.

Comment 8

[CREPLET Nicolas]

I'd like to thank you for all your answers.

Actually, I want to make a plugin supported by Mozilla 1.4 and over, on Windows
and every unix (Sun, Aix, HP, SGI). I want to parse xml documents. For that, I
have some issues. Over 1.7, I can use dynamically load of xpcom.dll to use
nsEmbedString and nsEmbedCString from nsStringAPI (modified version to avoid
linking on the static library), and I used nsDOMParser to create my nsDOMDocument.

Then I tested my plugin in Firefox 1.0RC and discovered that the nsDOMParser IID
had changed. So I may consider the fact that, if the QueryInterface on the old
IID fail, I could make one on the new IID.

But when I tested my plugin in Mozilla 1.4, I discovered that nsStringAPI didn't
exist and that I couln't use xpcom.dll to create nsAString and nsACString.

I know that the simplest way for me to create such strings would be to link on
xpcomglue, but it's not so easy to build this library on hp, aix and sgi. So I
try to find another way to create strings. The old nsIStringService would have a
solution, but it doesn't exist anymore.

If you have some suggestions, I will apreciate a lot.

Thanks a lot for all.

Comment 9

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

if I remember correctly, 1.4 had an embedstring_s.lib library which has an
nsEmbedString implementation you can use. is that not correct?

Comment 10

[CREPLET Nicolas]

Yes, that's right.
But this is a static library. So to build my plugin on unix platforms, I need 
to have this lib already built, and I have not all the needed tools to build 
the entire mozilla source on unix.

So is there a way to extract just the needed .h and .cpp for that library ?

Comment 11

[Darin Fisher]

Nicolas:

If you are using Mozilla's XPCOM interfaces, then you should take care to build
your code against the Gecko SDK:

http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.4/

(You should build your code against the oldest version of Mozilla that you wish
to support.)

Once you "dip" into the set of interfaces not included in the Gecko SDK, you are
effectively running the risk of being broken by future versions of
Mozilla/Firefox.  Make sure you verify that the set of XPCOM.DLL symbols that
you are depending on includes only the set that is marked frozen in the header
files.

Comment 12

[CREPLET Nicolas]

I'd a look at Gecko SDK, and it would give me all I need. But it uses static 
library, that I can't find for HPUX, AIX or IRIX. And I'm not able to build 
the entire mozilla source on this platforms.

Actually, I'd like to determine the minimal list of .h and .cpp needed to 
build this libraries.

Comment 13

[Darin Fisher]

you'd only need to build nspr and xpcom.  to generate all of the header files,
however, you'd need to "make export" over the entire mozilla tree.  the SDK is
output into the dist/sdk directory.  since nspr and xpcom are some of the first
libraries built by the mozilla build process, it should be easy enough for you
to start a build on those platforms, and then kill it after it has finished with
mozilla/xpcom.  or, something like that ;-)

unfortunately, the gecko-sdk for platforms other than Linux and Win32 are
community contributed at this point.

Comment 14

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

or you could follow http://www.mozilla.org/projects/xpcom/xpcom-standalone.html
- it describes how to build just xpcom ;)