MS compatible interface to xulrunner?

[Jacek Caban]

  Hi Thomas,

On 7/19/10 3:29 PM, Thomas Kaltenbrunner wrote:
> Hello,
>
> I am interested to port the wine interface to the xulrunner back to 
> mswindows to access the xulrunner via a IE compatible interface. So it 
> would be easy to replace an embedded IE with the gecko-engine.
> After some code browsing I thing it will be some of the "DLLs", 
> especially mshtml and shdocvw.
> I just wanted to hear from you an opinion about that project.
> What will be the main changes to the wine code - besides renaming of the 
> dlls?
> Where do you see problems?
> Did somebody else worked on that or implemented it already?

The main problem is that what we need (and we need it because apps need it) 
doesn't belong to XULRunner. Wine's IE libs implementation needs an 
architecture compatible with MS implementation. We do ugly things with 
Gecko to make it work. For example we don't use necko for loading 
documents. We use urlmon.dll instead. An app may register its own protocol 
handlers, overwrite an existing handler or simply depend on us using 
wininet for http. We also allow using our jscript instead of Gecko JS. This 
is needed to allow scripts written for IE work as well as interaction 
between script and app. There are more smaller things we have to do because 
applications need them. I think none of them makes sense to be in XULRunner 
itself.

There was a project (no longer maintained AFAIK) in Mozilla called Mozilla 
ActiveX control. It was kind of a replacement for WebBrowser control - a 
high level part of IE embedding API. It can work for some simple 
applications, esp if they are prepared to use it. I think it's a good 
compromise between having anything like that in XULRunner and not having 
things that don't belong there.

In my opinion, if your goal is to make embedding Gecko easier, it would be 
better to work on Gecko embedding API itself. Currently, although it's easy 
to do simple HTML embedding, if you want to do anything more complicated, 
you have to go through semi-internal, not backward compatible interfaces. 
Some things like interacting with scripts from the pages are not possible 
at all (although recently introduced ctypes might have changed it). It's 
far from being nice for developers IMO. Mozilla is getting rid of backward 
compatibility for mozilla2 (Firefox 4). It will surely hurt apps using 
XULRunner for embedding, but it may be also good time to rethink the API to 
be more friendly.

Jacek