Silverlight Browser Support
I occasionally get asked about why we don’t support browser X on platform Y and wanted to share a little background on Silverlight browser support. This post will provide a bit of details what it means to be an officially supported Silverlight browser and what experience you should expect from not officially supported browsers. One thing to clarify up front is that independent of being “officially supported”, Silverlight should generally run in all common browsers that support either the Netscape Plug-in API or ActiveX plug-ins.
Browser Plug-Ins
Silverlight plugs into browsers using standard browser plug-in APIs. The browser plug-in APIs are effectively the base platform for all plug-ins (including Silverlight). For example, when Silverlight makes a networking request, it’s really calling through to the underlying browser provided plug-in API to make the network request. In this way, plug-ins are generally subjected to the same sandbox and security restrictions as the containing browser as well as automatically pick up browser based configuration settings (e.g. proxy settings, security, caching). On the negative side though, these APIs are limited in areas such as networking which prevents the plug-in from doing some things developers generally want to do (e.g. limited HTTP verbs).
Silverlight Support Plug-in Models
There are numerous combinations of browsers and platforms. In an ideal world, all browsers would support the same plug-in model and have a consistent implementation of their plug-in APIs. Unfortunately, there are two main plug-in models, ActiveX for Internet Explorer and the Netscape Plug-in API (NPAPI) for most other browsers. Given that, ideally Silverlight would just need to support these two APIs and would then work consistently across browsers/platforms. Unfortunately, browsers don’t provide 100% consistent implementations of the NPAPI and therefore Silverlight generally needs to work around these inconsistencies (e.g. Safari doesn’t support byte range requests through their implementation of the NPAPI). In addition, as with any software, the browser provided plug-in APIs occasionally have bugs. What this means is that even if Silverlight provides a consistent plug-in implementation, it will still not work consistently across all browsers and plug-ins.
Silverlight Supported Browsers
One of the key value-propositions of Silverlight is that it works consistently across all browsers and platforms. As such, for Silverlight “supported browsers and platforms”, the Silverlight team works around plug-in API inconsistencies/bugs to ensure general Silverlight platform consistency (as well as does performance and stress testing on these browsers). Note that even though a browser is not an officially supported browser, we’ll often do some level of testing on the most popular non supported browsers as this will occasionally either turn up a product issue or will turn up a browser issue that we can then report to the browser manufacturer. One general question we get asked is why don’t we just support browser X on platform Y and the reason is that there is a real cost to this supporting any browser/platform due to the issues just described. From a Silverlight product team perspective, we have to trade off the cost/impact of supporting new browsers with the cost/impact of supporting new product features. In addition, each supported browser/platform has a slight impact on overall product agility – meaning the more browsers/platforms officially supported with each release, the longer it takes to release the product. As such, we try to balance the need for new browser/platform support against the need for more features and agility.
Adding New Officially Supported Browsers
There are a couple of factors that contribute to Silverlight adding new officially supported browsers/platforms: new version/update to an officially supported browser, expected or measured up-tick in a browser’s penetration (here’s one site that measures share but this data varies on region and by polling method) or, as described above, based on customer demand when balanced against other requested features. Note that “demand” is typically directly related to “expected or measured up-tick” in browser penetration.
