I was working on MSHTML implementation. More about what MSHTML is on the MozillaIntegration page.
MSHTML generally works as HTML is displayed, but there is still a bit to do. The thing that blocks correct implementation is loading pages from stream. It prevents correct implementation of functions like stop or refresh. What I mean here is that the function Load gets IMoniker interface that should be used to load the page, but the current implementation just gets URL by GetDisplayName and lets Gecko load the page. Not only it is a hack, it limits the functionality so that only protocols supported by Gecko may be used - which definitely is not what we want. Among others HTML Help, because of this, can't work with current implementation, as it uses mk protocol. There is some code that allowed us to implement it correctly, but presently it's disabled. I gave more info about this in comment to the patch: http://www.winehq.org/pipermail/wine-patches/2005-August/020059.html
Before I'll enable it again in CVS, I'd like to have a better URLMoniker implementation (most apps use it to pass IMoniker to the Load function but the current Load implementation hides bugs in it). First thing that needs to be done with URLMoniker is to switch it to use the pluggable protocol. That means rewriting most of URLMoniker, but, first of all, these protocols have to be correctly implemented. I have almost finished http implementation, so there remain https and ftp. That's what I'm going to work on in the nearest future, however now it can't go to the CVS before 0.9 release (correct me if I'm wrong). Other things that have to be done are:
- More functionality of MSHTML: there are leaks in its functionality. Although I don't think edit mode is something we should really care, there are things like refresh or stop.
WebBrowser control implementation - when we have its true implementation, MSHTML will become truly useful and in most apps HTML pages should work out of box.
Builtin MSHTML works fine with shdocvw. urlmon is a bit worse. It currently fails after BindToStorage call. I didn't try to get it working with current implementation as it's really just a hack and my tests show that it's very buggy. Switching to use pluggable protocol means rewriting it and I hope to get it working then.
shdocvw currently uses the Mozilla ActiveX control implementation of WebBrowser control. Some apps work fine with it, so we need to have them working with our own implementation before we can get rid of Mozilla ActiveX in shdocvw (and have only Gecko depended MSHTML). Meantime we can develop the WebBrowser version that is used when Mozilla ActiveX control is not available (it's just a stub now) to use MSHTML.
-- JacekCaban, Sun, 02 Oct 2005