You may have noticed the zoom keyboard shortcuts (CTRL+mouse wheel forward/back, CTRL+PLUS SIGN, and CTRL+MINUS SIGN) are not enabled by default when hosting the WebBrowser control if you have installed IE7, while it does without any problem with older IE versions. This was now an issue for a long time in RSS Bandit, that we couldn't fix. Yesterday I did a research again and found this page: MSDN about IZoomEvents. We already implemented the font size change using a menu (see KB 304103) but it offers not the same usability that you have with older IE x and loose if you switch from IEx to IE7 and run RSS Bandit. Now it works again like a charm and for your convenience I repeat the important part you have to apply in your own IE hosting code:

"To enable this behavior, call IWebBrowser2::ExecWB with OLECMDID_OPTICAL_ZOOM, passing 100 in pvaIn. Once set, the keyboard shortcuts remain available as long as the host navigates to HTML content because the same instance of MSHTML is used. However, if the host navigates to Active documents, such as XML or Portable Document Format (PDF) files, optical zoom is disabled and will need to be enabled again."

What the docs are not mention: you should call this at a time the hosted control is visible and fully initialized, or you will get wired COM exceptions...

As a RSS Bandit user you know we are hosting a IE Control. So we have to consider all the security vulnerability related to Internet Explorer. Don Park pointed to Zap the Dingbat, that provides a exploit to test Url spoofing. We use our own Url toolbar, so my first idea was: we should be aware of this. But the used control is not under our control, so I really had to test it out. Here is the result:

You see: it displays the full address not cutted after the magic character... Doh!

Posted my piece of code to embed the IE WebBrowser control in .NET without wrapping DLL's [.NET] as a GDN User Sample In general it is a rework of the code posted here, but with some extensions I needed and without saving static html to temporary file to navigate to later. The crux of matter is how to define the correct Interop for IHTMLDocument2.Write().
Here is my working solution:

using System;
using System.Runtime.InteropServices;

namespace System.Windows.Forms.Html {
  [InterfaceType(ComInterfaceType.InterfaceIsDual), ComVisible(true),   Guid(@"332C4425-26CB-11D0-B483-00C04FD90119")]
  interface IHTMLDocument2 {
    ...     
    ///

    
    /// Write complete html doc content including markup.
    ///


    /// object[] containing the string(s)
    ///
    ///
    /// IHTMLDocument2 document = control.GetDocument();
    /// if (document != null) {
    /// document.Open("", null, null, null);
    /// object[] a = new object[]{"Hello world"};
    /// document.Write(a);
    /// document.Close();
    /// }
    ///
    ///
    void Write(
      [In, MarshalAs(UnmanagedType.SafeArray)] object[] psarray);
    ...
  }
}

May be there is an Interop Guy that is able to solve it in a more elegant way? Currently IJW. This functionality is covered by the control itself. Usage of that feature of IE Control looks like this:

htmlControl.Html = myHtmlString;
htmlControl.Navigate(null);

With this approach you will also get the NavigateXYZ() events to listen for further usage.

Jon Udell about Mozilla Firebird 0.6. Really nice to know about the XML support there. The package also contains the mozctlx.dll, that's currently a (spare-time) project of Adam Lock (member of the Netscape Dev team).
But how about a native (means .NET managed) render control based on Gecko or a layered framework like Apple's WebCore ? If there would be enough time I would wrote it by myself. Someone out there just working on this kind of bits?