The Problem

You see, when running IE from the Metro experience, IE10 behaves in a different way. The UI is different, and one of the more notable differences is that no ActiveX plugins will work, at all, period. If you’re running is desktop mode, then IE doesn’t have this limitation and works pretty much as it does on Windows 7. Fine, a hard line decision that seems to stem from their push to get people to write HTML5 and Metro apps, but I’ve got no real issues with that either. The issue I do have is this: there is no way for a web app developer to tell if IE is running in “metro mode” or not. This is a problem.

You see, I work on a product which requires a native plugin to work. There is no HTML5 way to monitor a screen for changes and then capture those changes, compress them efficiently and then send them to a server to be shared with other people you have elected to share them with. This is the kind of thing that is only possible through a native code that can interface with the HTML on a browser page, and so our product requires a plugin that makes available an ActiveX control that our HTML web app can communicate with. So, for our product to be able to work on Windows 8, you’ll need to be running on IE10 from the desktop, not in “Metro mode” (or Firefox or Chrome, we have plugins for those browsers as well that work just fine). However, since we have no way of detecting that you are in Metro mode, then we can’t put up friendly UI to explain that we won’t work in Metro mode. To our code, everything just looks like you don’t have our plugin installed, and we will desperately try to install it, to no avail. The easiest solution to this, for me, seems to be some sort of addition to the User-Agent string that IE10 in Metro mode publishes to indicate that it is in Metro mode.

X-UA-Compatible: requiresActiveX=true

Microsoft has attempted to add something, but, unfortunately it isn’t acceptable. You can add a HTTP header to a response, or a meta tag in your HTML to indicate that your page requires a plugin. This will cause IE running in Metro mode to display something like this:

However, this UI is fairly easy to miss, goes away quickly, and doesn’t allow for any indication as to what parts of the website might not work due to the lack of plugin support. All of which could be handled by the web app were it able to detect that the features were unavailable.

Plugin Free Web

In doing some research on this problem, I came across some sentiment that plugins don’t belong on the web. I find this disconcerting. I understand it to a point, there are certain things that are becoming possible with HTML5 and the hope is to push people in that direction instead of relying on browser plugins (ie. Adobe’s Flash). The problem is where web applications need to do things that are outside of the browser sandbox and will likely NEVER be possible using HTML technology alone (ex: Web-based Application Sharing). For these applications there will always need to be some sort of bridge from the web application to a native component, be it a plugin or a native app that should be launched to take over the rest of the interaction. Even still, if the stance for one particular browser is, “no plugins, tough luck” then there should at least be a way for web developers to be able to detect this browser so that they can present clear information to their users about what is going on and what they can do.

I am rushing this post out a bit, and I’m sure I’m missing some key points, but I hope some people from MS will chime in with comments on this, or even better, make some changes to IE10 to fix this problem. I also hope some other web developers will chime in with comments of how this problem is effecting your applications as well.