Will .NET code run on FireFox?

This is a good question posed in an MV forum. I think this question and answer are good for a more general audience so I’m responding here.

Why you might want to read this

If you use ASP.NET and your web server does not properly recognize client browsers then your web pages won’t look right and visitors might not visit so often anymore. It’s also possible that some new browser change will cause your website to generate mysterious server errors, or exhibit hard to diagnose issues like rendering some pages OK but others not. This article should help to figure out why things don’t look right in different browsers, and how to fix the problem.

Here is a response from Gerry Simpson in the U2 forum to the title inquiry:

Nothing runs ‘ON’ FireFox. ASP.NET code running on a web server generates HTML that is requested and interpreted by client browsers. Its up to the programmer to ensure that the generated HTML renders properly on any particular client browser just the same as it is with any other type HTML service.

That’s a good summary, but you know I can expand it into pages of details. LOL

A brief recap of what .NET is, to help answer the question

.NET is a framework which includes many categories of functions. As a tiny example, there is ADO.NET for database operations and ASP.NET for websites and web services. One of the major differences between ASP.NET and LAMP development is that most ASP.NET tags are meta-tags – not specifically HTML or script targeted to a specific browser. You create your pages in a generic but consistent code and the ASP.NET runtime generates browser-specific code based on the environment variables provided by the client browser. This is a lot like MV BASIC object code which is portable to all platforms for the same DBMS vendor, and the BASIC runtime generates and executes OS/chip-specific machine code at runtime. This is also the way the Java Virtual Machine works.

Unfortunately LAMP development doesn’t do anything like this. The PHP (or Perl or Python, whatever you want the ‘P’ to mean) developer has to write code specifically targeted to each browser. This is one of the reasons why so many people are fond of ASP.NET vs LAMP – the framework does a lot more for us under the hood so that we don’t need to spend a lot of time dealing with stupid browser issues. Conversely, this is also another reason why many ASP.NET websites don’t look right in various browsers. That’s not to say a framework is a bad idea in general – there are a lot of web development frameworks that people use for LAMP and Java development as part of their "stack". The more we can let a system generate code for us the more we can focus on the important details. One of the reasons why developers are drawn to the .NET Framework compared to the others is that it’s supported by a major company and not a community project where if it doesn’t work you need to fix the tools yourself. Let’s not get into this topic now, I’ll do a whole ‘nuther article on this very topic soon.

LAMP developers are fond of saying if their website doesn’t look right in Internet Explorer then you should get yourself a "real" browser. Yes, IE has its own notion of standards compliance, and (quite reasonably) a lot of LAMP developers just don’t want to work too hard on their code to accommodate that.

So "Will .NET code run on FireFox?" can be answered with ".NET can generate a user interface targeted to any client". The real question is how well does it do that for various clients? This is what Gerry was saying.

Getting ASP.NET to do what you want

When a website created by ASP.NET does not look right in a non-IE browser, it might be because the developer did not check the box which tells ASP.NET to target other browsers. It could also be that the targeting code for specific features for specific browsers is just wrong. ASP.NET will automatically generate the client code but the developer needs to make sure that’s done properly.

Before ASP.NET 2.0 Microsoft was doing its "bad boy" thing and not recognizing non-IE browsers properly, given the information available from the client browser in the UserAgent environment variable. This caused ASP.NET to return code that wasn’t suitable to the client. Further, the tables for targeting non-IE browsers weren’t updated, so the problems lingered and public rants about Microsoft non-compliance continued as the norm. (They’ve had so many chances to fix that image problem…)

Thankfully, the definitions for browser recognition are exposed for the developer, open to modification, and much easier to modify because (today) it’s all in XML. Do a search for "browserCaps" and App_browsers ".browser" files for a wealth of information on this.

Just so you have an idea of what one of these "browserCaps" or .browser things is, here is one example of the XML that can be used for ASP.NET to detect the Opera browser and which features are supported by specific major and minor versions:

<browserCaps>
  <use var="HTTP_USER_AGENT" />
  <filter>
    <!– Opera –>
    <case
         match="Opera[ /]         (?’version'(?’major’\d+)(?’minor’\.\d+)
         (?’letters’\w*))">
      browser=Opera
      version=${version}
      majorversion=${major}
      minorversion=${minor}
      frames=true
      tables=true
      cookies=true
      javascript=true
      ecmascriptversion=1.1
      isMobileDevice="true"
      <filter match="[4-9]" with="${major}">
        ecmascriptversion=1.3
        css1=true
        css2=true
        xml=true
        <filter match="[5-9]" with="${major}">
          w3cdomversion=1.0
        </filter>
      </filter>
      <filter match="^b" with="${letters}">
        beta=true
      </filter>
    </case>
  </filter>
</browserCaps>

As you can see, there are a lot of features that need to be checked for each browser and the ASP.NET runtime must generate tags and script which are supported by any given Opera client that hits the website. That Opera definition is actually a small one, and it’s an older browserCaps definition which was replaced in ASP.NET 2.0 by ".browser" files. Here are a couple links to info on this change.

Even given the above XML, there could be a question as to whether ASP.NET supports Opera. The answer depends on

• the version of Opera you’re using
• whether it has any bugs
• what it advertises about what features it support
• whether the definition in browserCaps is accurate
• whether ASP.NET properly generates code matching the features it believes it needs to target
• whether the developers of the browser interpret the standards differently from the developers of the controls that generate code for that browser
• and finally, whether the developer has hardcoded something that is not cross-browser compatible which the ASP.NET runtime won’t even try to interpret.

I’m sure there are more possible conditions that but that should help you to understand the vast number of factors involved in getting a browser to do something as simple as printing a single letter in the right place with the right color, right font, right size, etc.

Who maintains the browser definitions

Some people contribute to supporting these browser-specific configuration files, and post them for distribution. Unfortunately Microsoft is not as vigilant about this. Microsoft undoubtedly has people hard at work to update the ASP.NET runtime to properly generate browser-specific code, but because they didn’t update browserCaps and still don’t keep on top of .browser files, the ASP.NET runtime often never gets the chance to use those updates. Rob Eberhardt is one of the people who helped to maintain browserCaps definitions as a community service. About this situation he brutally but honestly says:

"just like ASP’s browscap.ini before it, nobody official is updating this info. Microsoft pawns the job off on Cyscape.com, which doesn’t care about doing the world a service (it’s busy selling its competing BrowserHawk product instead). As a result, machine.config is already woefully out-of-date and unaware of newer browsers like Mozilla/Firefox, Netscape 7, Safari, and Konqueror, so it tells Request.Browser that they are "Netscape 5" (though Safari and Konqueror are wholly unrelated rendering engines)."

What he’s saying is that Microsoft left the update of browserCaps to this Cyscape company, but since they offer a for-sale developer product that detects browsers, they had no interest in providing browserCaps definitions free to the world – that is, free, current, and accurate. Ironically (?) I just did a search on the Cyscape site and couldn’t even find the words "browsercaps" or "webconfig" in their knowledgebase. I’ll give them the benefit and guess they probably stopped browserCaps maintenance and completely disowned the project when ASP.NET 2.0 went to .browser files.

Rob and others took it upon themselves to provide some updates, but such endeavors require being vigilant about every browser and the nuances of each new release. That’s just too much for unpaid individuals, and over time we’ve seen these individuals eventually discontinue their generous uncompensated efforts. (This fate befalls a lot of open source efforts.)

That brings up a side point: You need to be careful when loading definitions from some website, even generously contributed and popularly accepted. This isn’t entirely for security reasons (though that can be a factor) but in this case primarily because more recent updates from Microsoft might contradict what’s in the XML from the open community. Who’s right? Which one is more recent? *sigh* We really need to spend more time on applications and less on this sort of minutia.

Today, some people do post new .browser definitions, and some get so excited about being able to support a new browser that they just want to share it with the world. But I don’t know of a common repository where one can find the latest definitive collection of .browser files – especially from Microsoft. If you know where a live project like this is going on, please let me know!

Well, that’s enough for now on why ASP.NET does or doesn’t work for any given browser. I’ll post another article soon on what you can do about it when it doesn’t work, and why it may be important for you to be pro-active about fixing it for your website.

Here are a couple more links on this topic.
ASP.NET Server Controls and Browser Capabilities
Gary Keith‘s older browscap.ini page