So I was going over some demos for my ASP.NET Core talk this week and I was looking over my ASPNET Hosting demos which host the ASP.NET runtime in a WinForms application. There are a number of examples that use a Web Browser embedded into the page.

Way back in .NET 1.x I struggled to find and customized a WebBrowser control class using low level COM to hook up basic browser functionality for navigation and basic event access to many common operations without relying on the 3 meg mshtml runtime. The control works, but it's pretty finicky and the design experience is not quite optimal.

WinForms . NET 2.0 now includes a new Web Browser control and mshtml is now part of the runtime I believe so you don’t have to worry about shipping this 3 meg monster interop assembly. Sounds great, right?

Yeah, yeah, the control is nice for very basic scenarios. It’s easy to drop on a form and it handles many common display only scenarios. However, one of the most frequent tasks that I do is take over the navigation process of the browser and hook up navigation that bypasses the browser’s navigation engine and instead routes request to local files. One of the examples I use in the Hosting application is running an Web Site completely offline without any Web Server directly from disk.

So there’s a Navigating event which is meant to be like the WebBrowser’s BeforeNavigate event that can be used to override Navigation with a custom navigation for special Urls or translating URLs into something that the application can work with and generate HTML. Great – it’s way easier than my old code, but the damn simple minded event doesn’t publish the browser’s POST data. Or the headers. Or the flags. Who are these people making decisions on crap like this? They mirror an API that already exist and then nilly willy decide to leave out functionality that already exists on the old API arbitrarily.

Right – who would ever need to look at the POST data or Headers in their code? It’s rare, but damn it the old API had it, why not go the extra two steps and add a couple of properties to bring that data back? Unbelievable.

The control also doesn’t make it easy to extend in the HTML model. For example, Html Editing isn't supported so if you want to go down that path you're back to programming against HTML document element objects in slim COM wrappers.  I suppose I could probably figure out how to an interface reference to the raw browser events and fire those instead, but then I’m back to low level interfaces. Offhand I don’t remember what it takes to wrap these events manually (shit I was hoping I’d never have to look at that nasty code ever again).

Drat, this bugs me. Basically keeps me from using this control and stick with my old control...

Incidentally one of the reasons I even bothered updating this sample was because my Web Browser wasn't anchoring properly in the window. As it turns out the WinForms 2.0 control has the same behavior - it also oversizes itself by half a scrollbar...