Many times when using the WebBrowser control, you may want to get the underlying cached file instead of using "document.innerHTML". Using this technique avoids the HTML/JavaScript markup that IE injects into the XML file for display. The key to doing this is using the function called GetUrlCacheEntryInfo. Following is how you would call it from managed code. [UPDATE] Using the cached file may be the best way in some cases, but another alternative is to access the "XMLDocument" expando property that IE attaches to the document element when browsing to XML documents. Read the "Straight to XML" section this MSDN page for more details.

If you're in the mood for a little nerd humor, these links should help you out (via Don Box's Spoulet):

• Battle of the Avalon authors
• YODA Language

I've been wondering why VS 2005 uses it's *.vshost.exe binary to debug projects... I've seen several problems that it has caused posted in the newsgroups, but I assumed that there were actually benefits that came from it.  Today I came across a blog post outlining those reasons:
http://blogs.msdn.com/dtemp/archive/2004/09/09/215764.aspx

Here's the summary of reasons from the above post:

• Improved performance
• Partial trust debugging
• Design time expression evaluation (using the "immediate window")

Sometimes, it is useful to be able to track windows events even when your application doesn't have focus. In order to accomplish this, you can use the function SetWindowsHookEx. Below is an example of using this API in .NET and then wrapping the events with managed mouse and keyboard events. The code is not production strength, but hopefully, it will give you a good start. Let me know if you have suggestions for improvements, and I'll update the post.

I always assumed that when the documentation for the JavaScript window.open said that the "height" argument "Specifies the height of the window, in pixels" that it meant the height of entire parent window (the one with the "X" in the upper-right corner) not the client-size of the browser control window!  The same is true of the "width" argument. (at least we're consistent!) 

So, if you're worried about the positioning and sizing of a popup window be sure to account for the size of your status bar, toolbar, and outer border of your window.  They all 3 affect how window.open is (or should be) handled.