"Wouldn't it be great if the Mozilla browser engine were an Active control that could be embedded as in applications?"
That's a question that myself and other had asked on the Mozilla groups soon after the Mozilla project began. And further:
"Wouldn't it be great if the Mozilla control used the same API as the Internet Explorer control?"
The aim of this project is to be both of these things.
Previous versions of Netscape Communicator/Navigator were arguably superior to IE as day to day browsers but they suffered through their immediate usability and modularity. Although the Netscape browser was great as a standalone application, it wasn't possible to utilize that functionality in third party applications. On the other hand, Internet Explorer shipped with an ActiveX control which allowed exactly that ability.
Take a look at some of the applications that already use the IE control:
There are hundreds of others apps, some commercial and probably many more running in intranets all over the world.
So what would it take for developers to use the Mozilla control as opposed to the IE control?
An identical one! That's right, the Mozilla control will implement the IWebBrowser and DWebBrowserEvents interfaces that Microsoft have already defined for Internet Explorer.
Since the Mozilla control implements exactly the same API, it will mean that developers can take existing IE code and port it, sometimes in a matter of minutes!
The only modification required may be to replace the line that creates the control of type CLSID_WebBrowser with one of CLSID_MozillaBrowser. VB developers must delete the IE control from their project and insert a Mozilla one with the same instance name.
Let's look at what the IE control exposes interface-wise to the world:
Obviously an application will not be so portable if it is viewing IE specific HTML such as VBScript, ActiveX controls or DHTML. In this case, the application may need to modify the HTML content in order to be compatible.
Gecko is a very powerful set of APIs implemented in XPCOM (COM-like) set of interfaces. Unfortunately, it is only suitable for C++ and has a steep learning curve that may not appeal to some. So if you're a VB or Delphi programmer, your only way of using Mozilla is through the control. Also, it's the easiest way to port code that already uses IE.
The Mozilla control provides the wrapper code that converts between the IWebBrowser and the internal Gecko engine interfaces and catches Gecko events and fires the appropriate ActiveX events. Since it is a true ActiveX control, it can be shipped without headers or source. All the programming information is stored in the DLL as a type library and is therefore language independent.
The IE wrapper control will implement a simple DOM using the same COM interfaces as you find in Internet Explorer 4.0, i.e.
This enables the client application to parse the contents of a page programmatically and even modify the page.
It is important to note that the Mozilla control will not have a complete implementation of the DOM since it is extremely complex. Here is what you can expect:
What you shouldn't expect:
The interfaces for Internet Explorer 5.0 are considerably more complicated and I have not reached a decision whether I should attempt to implement them in Mozilla.
Okay, enough of the blurb, here's the current state of play.
The following interfaces have been implemented satisfactorily:
Many of the methods on the IWebBrowserApp, IWebBrowser2 and DWebBrowserEvents2 interfaces are implemented by dummy, no-operation code since they don't have meaning when the browser is running as a control.
In the current state of the Mozilla control, it is possible to run the IEPatcher tool on existing binaries and have them run using the Mozilla control.
The Mozilla control is implemented in ATL. Anyone who has tried to write complex COM objects in raw C++ or with the hateful MFC will know exactly the reasons why I chose ATL!
Amongst the reasons for using ATL are:
The main class is CMozillaBrowser which is the ActiveX control itself. It derives from CComControl plus IWebBrowser and a host of ATL implementation classes. It is a window only control and hooks the WM_CREATE and WM_DESTROY events to create and destroy the Gecko web browser class.
When an IWebBrowser method is called, a piece of code in CMozillaBrowser converts the parameters to their nsIWebWidget equivalents to perform the actual operation.
For outgoing events, everything goes in the opposite direction. During creation of the Gecko web browser, CMozillaBrowser registers event listeners implemented by the CWebBrowserContainer class with Gecko. Gecko calls these methods when a page is loaded, for progress notifications and son and CWebBrowserContainer fires the equivalent IE control events out via the CProxyDWebBrowserEvents template that CMozillaBrowser inherits from.
Standalone Mozilla ActiveX Control installers. Note these contain just the control and the parts of Mozilla Gecko it needs to function. It does not contain the full Mozilla browser.
| Version |
| Mozilla ActiveX Control 1.7.12 |
| Mozilla ActiveX Control 1.7.7 |
| Mozilla ActiveX Control 1.7.1 |
| Mozilla ActiveX Control 1.6 |
| Mozilla ActiveX Control 1.5 |
The Mozilla executable (including the control) is built at Mozilla.org on a nightly basis. You can find information about the latest builds here.
Please note that nightly builds are automated and represent work in progress. If this bothers you consider using one of the more stable milestone releases.
The ActiveX source code is part of the Mozilla source tree. Tarballs are usually to be found here. All the code is contained in the subdirectory mozilla/embedding/browser/activex/src.
Source code for IEPatcher, VBrowse and CBrowse are contained in the mozilla/embedding/browser/activex/tests subdirectory. The source is also online courtesy of LXR.
The control is built as part of the normal Mozilla Win32 build process. Follow the instructions on the Mozilla.org website to build Mozilla:
Refer to Mozilla.org or netscape.public.mozilla.builds if you have difficulties building Mozilla.
Note: You cannot build the control standalone! The control depends on libraries and header files that you only get from building the whole Mozilla!
The ActiveX control is particularly finicky about compilers since it uses the ATL libraries which have been known to clash with certain Platform SDKs. Please see below for certain notes to avoid problems.
I don't own .NET 2003 but I've had no reports of issues and assume it works.
There are no special requirements for this build except that your configuration matches that specified by Mozilla build instructions (GNU make, cygwin etc.).
There are no special requirements for DevStudio 6 except that you apply the latest service pack (at least SP5). You do not need to install a Win32 Platform SDK but if you have I recommend that you remove references to it from your PATH, INCLUDE and LIB environment variables before commencing a build.
Note: Nov 2003 - I have absolutely no idea if it still builds in DevStudio 5. Miracles happen, but you're on your own I'm afraid.
Note: DevStudio 5 is no longer supported, but these old instructions might still be valid.
The default installation of DevStudio 5 is broken, especially with regard to its ActiveX and IDL support. Therefore, you need to do a little work before you can build the control:
set PATH=c:\winsdk\bin;c:\progra~1\devstudio\bin;%PATH% set INCLUDE=c:\winsdk\include;c:\progra~1\devstudio\include;%INCLUDE% set LIB=c:\winsdk\lib;c:\progra~1\devstudio\lib;%LIB%
Installation should be a straightforward procedure:
Note that building Mozilla will usually register the control for you unless you have set MOZ_NO_ACTIVEX_REGISTRATION to disable this behaviour.
If regsvr32.exe is not in you path use the "Find Files..." facility of 95/98/NT to locate it and run it using its the full path.
Do not register mozctl.dll! The new mozctlx.dll now contains all the PATH fixup magic that ensures the control works correctly.
The Mozilla control should work any ActiveX control compatible container. This includes:
Notice the last one? That's right! Since IE HTML pages can contain controls, you can test if your Mozilla control works, by following this link. This take you to a page containing simple browser application using the Mozilla control that runs from IE.
Most of my test work is done with an application called CBrowse. This is a C++ application that can be found in the Mozilla source code tarball.
The control is a standard ActiveX component and can be used from any development environment which supports ActiveX. The sections below show you how touse the control in popular environments.
You may also like to read about the IE patcher
As Mozilla has an identical API to IE, you can program it using the documentation for Microsoft's WebBrowser - Reusing the WebBrowser Control
The Mozilla Browser control should be usable from any automation control container. This includes Visual Basic .NET, so follow these steps to add the control to your VB project:
The Mozilla Browser control should be usable from any automation control container. This includes Visual Basic, so follow these steps to add the control to your VB project:
Once the control is inserted, you should be able to directly call the events, methods and properties it exposes. The latest control source contains an example VB project called VBrowse.
Note: Save your project often! Bugs in the alpha-quality Mozilla will crash your development environment and will wipe out any unsaved work you may have.
This is a test application I have written in Visual Basic to test the Mozilla control (and in future compare it to the IE control). It takes the form of a simple web browser app which should increase in functionality as the control becomes more complete. To use it, simply run the executable (or hit play from VB) and then use it like a web browser.
Here's a picture!
ActiveX controls are slightly more tricky to use from C++, however here are 3 ways you can use the control.
MFC provides a CHtmlView class which may be used to instantiate the Internet Explorer control. Since the Mozilla control is API compatible, the steps are practically identical as using CHtmlView, except for overriding the Create method.
a) Edit stdafx.h and add "#include <afxhtml.h>" to pull in the CHtmlView class.
b) Derive your view class from CHtmlView and replace all calls to CView in your class to CHtmlView, e.g. in the IMPLEMENT_DYNCREATE macros and elsewhere.
c) Override the default Create method of CHtmlView with your own:
In the .h file add:
public: virtual BOOL Create(LPCTSTR lpszClassName, LPCTSTR lpszWindowName, DWORD dwStyle, const RECT& rect, CWnd* pParentWnd, UINT nID, CCreateContext* pContext = NULL);
In the .cpp file add:
BOOL CHtmlView::Create(LPCTSTR lpszClassName, LPCTSTR lpszWindowName, DWORD dwStyle, const RECT& rect, CWnd* pParentWnd, UINT nID, CCreateContext* pContext){ // create the view window itself m_pCreateContext = pContext; if (!CView::Create(lpszClassName, lpszWindowName, dwStyle, rect, pParentWnd, nID, pContext)) { return FALSE; } AfxEnableControlContainer(); RECT rectClient; GetClientRect(&rectClient); const CLSID CLSID_MozillaBrowser = { 0x1339B54C, 0x3453, 0x11D2, { 0x93, 0xB9, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 } }; // create the control window // AFX_IDW_PANE_FIRST is a safe but arbitrary ID if (!m_wndBrowser.CreateControl(CLSID_MozillaBrowser, lpszWindowName, WS_VISIBLE | WS_CHILD, rectClient, this, AFX_IDW_PANE_FIRST)) { DestroyWindow(); return FALSE; } LPUNKNOWN lpUnk = m_wndBrowser.GetControlUnknown(); HRESULT hr = lpUnk->QueryInterface(IID_IWebBrowser2, (void**) &m_pBrowserApp); if (!SUCCEEDED(hr)) { m_pBrowserApp = NULL; m_wndBrowser.DestroyWindow(); DestroyWindow(); return FALSE; } return TRUE;} Note that this code is practically identical to the code in the CHtmlView::Create method, the only change is that CLSID_MozillaBrowser is defined and supplied to the call to CreateControl instead of CLSID_WebBrowser (IE).
d) In your view's OnInitialUpdate add a line such as this to see it working!
Navigate2(_T("http://www.mozilla.org/"), 0, _T("")); Important Note: The CHtmlView::Navigate2 class calls IWebBrowser::Navigate with a target frame variant containing VT_BSTR and a NULL string value. Versions of the Mozilla control prior to Mozilla 1.3 did not like this and would crash, so specify the target as _T("") instead of NULL.
Here is a sample application that uses CHtmlView.
The MFC CWnd class has built-in site control support and an Add Components wizard that generates a wrapper class from any installed control.
To use the Mozilla control from DevStudio 6:
Here is a sample application generated using the wizards.
If you're a COM expert / purist who hates wrappers then you may prefer to use the CControlSite class that is part of the Mozilla control project itself. This is a class for hosting any ActiveX control including the Mozilla control. Host the control in the site and control it via its IWebBrowser2 interface and the usual event sink mechanisms.
The advantage of using this class is that it is based on ATL and not MFC and is therefore lighter and suitable for non-MFC projects. You don't get wizards to help you of course, but the class is much easier to pull apart and understand.
The CBrowse sample application demonstrates how this class may be used.
Most C++ projects that use the IE control do so via a wrapper class. This in turn usually wraps the MFC CWnd class, providing stub functions for creating the browser and calling methods upon it.
static const CLSID CLSID_MozillaBrowser={ 0x1339B54C, 0x3453, 0x11D2, { 0x93, 0xB9, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 } }; Thanks to Nick Bradbury & Irongut (Dave Murray) for this section!
Here is a comprehensive tutorial.
And here is a slightly older brief rundown on how to use the control from Delphi. Follow these steps to install and register the Mozilla control on your system
You can now drop the MozillaBrowser control onto a Delphi form.
The dbrowse application demonstrates a simple browser written in Delphi.
This is another simple project that demonstrates how to use the Mozilla control. Note that this demo dynamically creates the browser object
IEPatcher is a tool to scan an executable or DLL and patch it to replace instances of the IE control with the Mozilla control. Since both controls are binary compatible, this is just a matter of replacing the CLSID_WebBrowser with CLSID_MozillaBrowser. If you have built the Mozilla browser, try running the patcher on an app that uses IE and see if it works!
Note: As a safety feature, the patcher does not let you overwrite the original file, but be careful all the same!
Here's a picture!
联系客服
