Bug: .NET WebBrowserControl switches User-Agent headers when using XMLHttpRequest in compatibility view

Microsoft .NET supplies a WebBrowserControl that can be used to integrate web browser functionality into a windows application.

During the last days I learned some weird stuff about this component, especially regarding user agent HTTP headers.

According to MSDN, the control “duplicates” Internet Explorer Web browsing functionality.

The WebBrowser control provides a managed wrapper for the WebBrowser ActiveX control. The managed wrapper lets you display Web pages in your Windows Forms client applications. You can use the WebBrowser control to duplicate Internet Explorer Web browsing functionality in your application or you can disable default Internet Explorer functionality and use the control as a simple HTML document viewer. You can also use the control to add DHTML-based user interface elements to your form and hide the fact that they are hosted in the WebBrowser control. This approach lets you seamlessly combine Web controls with Windows Forms controls in a single application.

Remark: All my tests were done using Windows 7 x64 Professional and Internet Explorer 10.0.9200.17148.

This is where the fun starts: By default, the control is in compatibility view and sends a IE7.0 User Agent header. Both normal and XMLHttpRequests use the same header. There is no way to override this from server side e.g. by sending a X-UA-Compatible header! This means that if you have a web application and suffer from these problems, you need to modify your customers registry which is very bad.

A helpful batch file can be found on Github. Further information can be found in this helpful thread at Stackoverflow and here.

No settings
No settings

But be careful! As soon as the control is using IE8 or IE9 mode, the User-Agent starts switching between the “fake” User-Agent and the “original” User-Agent when sending AJAX calls with XMLHttpRequest. This can be very painful especially when you depend on the header for session pinning or security token generation.

IE8 mode
IE8 mode
IE9 mode
IE9 mode

Only in IE7 mode the User-Agent stays the same when using XMLHttpRequests:

IE7 mode
IE7 mode

From my point of view this is a severe bug that should be addressed.

Furthermore, that whole compatibility view thing was a totally bad design decision. But this is nothing new 😉

Update: I posted a bug at Microsoft Connect. Hopefully this will be fixed – I think it came with the IE10 update.

Update 2, 12.02.15: Microsoft posted a comment that they are investigating the issue.

Update 3, 02.03.16: Microsoft closed the bug without fixing it.

Leave a comment

Your email address will not be published. Required fields are marked *