Bug and Fix: ASP.NET fails to detect IE10 causing _doPostBack is undefined JavaScript error or maintain FF5 scrollbar position

__doPostBack error in IE10

Browser version numbers continue to march on. IE9 is here, IE10 is coming, Firefox 5 and 6 are here with 7 and 8 in the wings, Opera's on 11, and Chrome is on, I dunno, somewhere between 14 and 50. Regardless, we'll all be on version 99 before The Singularity.

There is a bug in the browser definition files that shipped with .NET 2.0 and .NET 4, namely that they contain definitions for a certain range of browser versions. But the versions for some browsers (like IE 10) aren't within those ranges any more. Therefore, ASP.NET sees them as unknown browsers and defaults to a down-level definition, which has certain inconveniences, like that it does not support features like JavaScript.

If you want to see this for yourself, create a new, blank Web site (e.g. in Visual Studio 2010), add a control that requires JavaScript for postback (good example: <asp:LinkButton>), and then run the site using IE9 (where it works) and IE10 (where it won't). View the page source and compare the HTML and JavaScript sent to each browser.

A similar bug affects Firefox versions 5 and above, where support for using JavaScript to reposition the scrollbar in the browser is not detected. This basically breaks the MaintainScrollbackPositionOnPostBack property for Web Forms pages.

These "misdetection" bugs affect Web Forms pages in both ASP.NET 2 and ASP.NET 4. If you are using ASP.NET Web Pages, or if you're using ASP.NET MVC or ASP.NET Web Pages and are not using the Browser object to detect JavaScript support, you will not be affected.

Fixes

There are two ways to fix this: one is a machine-wide fix, the other is a way to fix individual sites.

Machine-wide fixes

We're releasing a hotfix that will fix these, which you'll be able to get to via some KB articles. These KBs with fixes are live and are the best way to update your system. The fixes solve the browser-detection issue forever for all sites on a machine. These will be rolled up into future versions of the framework and will eventually also be on Windows Update.

What the fixes do is update the ie.browser and firefox.browser files in \Windows\Microsoft.NET\Framework\<version>\Config\Browsers with new and future-proofed versions of these browser definitions. Nothing else is affected.

Site-only fixes

App_BrowsersIf you don't have access to the whole machine and/or just want to update a single project, use NuGet to install the App_BrowsersUpdate package. Your site structure in Solution Explorer will then look like the image at right. Note that NuGet uses .NET 4, so for systems that have only .NET 2, you'll need to get the ZIP file and put the new browser files in App_Browsers manually.

Updating the whole machine is the preferred way to fix this.

Summary

  • ASP.NET might not recognize the most current versions of some browsers, and will consequently treat them as down-level browsers. (Basically: no JavaScript.)
  • The fix is to get updated browser-definition files.
  • You can install a machine-wide fix or just fix individual projects.

If you're interested in more detail than you need, I’ve uploaded the updated versions of firefox.browser and ie.browser files that are expected to ship with the next version of ASP.NET. The files and source is up at my BitBucket repo if you are interested in the details.

Thursday, August 18, 2011 8:47:46 PM UTC
I am curious about why ASP.NET do this type of validation and how is the behavior when a new browser is released

I don't understand the adapters too, when you use ASP.net menu control, it renders different HTML in IE and chrome!
Thursday, August 18, 2011 8:53:57 PM UTC
Felipe - ASP.NET as I understand it will NOT be doing this kind of stuff going forward. It's all about Feature Detection. Doing browser detection was great in 2002 but it's not anymore, so ASP.NET is now being future proofed and we should also focus on Feature Detection.
Thursday, August 18, 2011 10:07:25 PM UTC
Scott,

does this bug affect SharePoint as well? Just tried opening a SP 2010 site with FF6 and all worked fine, at least I couldn't notice any difference...
Thursday, August 18, 2011 10:20:23 PM UTC
Scott,

Thank you for the post! We ran into the scroll position problem in Firefox several months ago and figured it was related to browser detection.

Is there a way to completely "disable" browser detection such that ASP.NET treats every request as coming from a state of the art browser with full support for everything?
Thursday, August 18, 2011 10:27:40 PM UTC
Robert - If they aren't using the "maintainscrollbarposition" feature, then no.
Bill - This fix is that. If you look at the browser files they just say "FireFoxPlus" meaning all versions forever. That said, I'll double check.
Thursday, August 18, 2011 11:03:23 PM UTC
Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regbrowsers.exe -i
Thursday, August 18, 2011 11:07:42 PM UTC
So, when doing the manual install. I've copied the browser files into the appropriate machine-wide locations. Do I then execute the <code>aspnet_regbrowsers.exe -i </code> command for EACH of the Framework\v2.0.50727, Framework\v4.0.30319,Framework64\v2.0.50727, Framework64\v4.0.30319directories to build all the ASP.BrowserCapsFactory.dll versions, or is one .DLL good enough for everyone?
Thursday, August 18, 2011 11:57:05 PM UTC
Marc - Right, until the KBs come out you want to do that for each using the right folders which sounds like what you're doing. You're an advanced user, of course.
Friday, August 19, 2011 2:51:39 AM UTC
Cant they fix this bug in the .NET 4.0 browser definition while they are at it?
https://connect.microsoft.com/VisualStudio/feedback/details/682952/java-can-no-longer-send-cookies-for-login
Friday, August 19, 2011 3:33:52 AM UTC
What about setting Page.ClientTarget = "uplevel" in the master page of the site? Is that a viable solution? How does it differ from the machine-wide fixes? It has the advantage of not having to upgrade every single server you are deploying to.
Friday, August 19, 2011 8:15:29 AM UTC
Don't use postback or webforms these were great in 2002, but we have moved on.
Darren
Friday, August 19, 2011 8:35:30 AM UTC
Greg: If you want to tell WebForms to effectively "lay off" then setting Uplevel works, although you want to do it in Page_Init which is earlier than the Master Page. At this point, WebForms will assume everyone is a newer browser than you're on your own.

davh: I'm looking into that. Have you tried Greg's uplevel trick? You can also make a browser file or as you said, change the <forms cookieless="UseCookies"/>
Friday, August 19, 2011 8:50:53 AM UTC
Wow! New fresh look for your site! Love it!
Friday, August 19, 2011 8:55:11 AM UTC
Thanks! I'm thrilled with it.
Friday, August 19, 2011 10:03:12 AM UTC
Nice look and good picture in the right top corner !
Ed
Friday, August 19, 2011 12:17:41 PM UTC
I ran into the Firefox v5/6 maintain scroll position problem yesterday, so I installed the .NET 4.0 fix via NuGET. Unfortunately Firefox (I'm using v6) still doesn't scroll back to where I was :-(

Any help for this?
Friday, August 19, 2011 12:43:14 PM UTC
Never mind, now it's suddenly working :-) Thanks!
Friday, August 19, 2011 8:22:09 PM UTC
For those of us who have to update manualy, can't these also go in the web.config file, rather than App_Browsers?
Friday, August 19, 2011 8:48:00 PM UTC
Josh - No, web.config browser updates stopped in .NET 2 AFAIK. Do you not want to add app_browsers? You could also use the UpLevel trick. Or, honestly, just wait until this is autoupdated on your server.
Saturday, August 20, 2011 10:24:31 AM UTC
thanks scott great post,
Saturday, August 20, 2011 10:54:41 PM UTC
you saved my day,
Thank you
Ashaq Ali
Wednesday, August 24, 2011 4:17:52 AM UTC
The zip file only has ie.browser in the net20 folder. Should firefox.browser not be added for 2.0?

Also, no mention of ASP.NET 3.0 or 3.5 - are they safe from this, or does "2", mean "2, 3, and 3.5"?
Splangy
Wednesday, August 24, 2011 4:37:02 AM UTC
Splangy - The FireFox issue doesn't exist on .NET 2.0. Also, yes, 2 means CLRv2 which is 2.0, 3.0 and 3.5 as they all use the .NET 2 CLR>
Wednesday, August 24, 2011 11:35:58 AM UTC
Not exactly the same as the problem Scott describes, but I ended up here while googling for a solution to my problem, so someone else might find this useful:

If your Firefox 6 keeps reloading your MicrosoftAjax.js-enabled page when the URL contains a #, check out This post on StackOverflow
Thursday, August 25, 2011 9:13:57 AM UTC
Soo when will the machine-wide microsoft support pages go live?
Thursday, August 25, 2011 1:30:00 PM UTC
Hi Scott,

I added the files manually in the App_Browsers folder and re-compiled and generally all seems to be well, but I have started seeing errors like this one in my log:

System.ArgumentException: Version string portion was too short or too long. at System.Version.TryParseVersion(String version, VersionResult& result) at System.Version.Parse(String input) at System.Web.Configuration.HttpCapabilitiesBase.get_MSDomVersion() at System.Web.UI.WebControls.TreeView.EnsureRenderSettings() at System.Web.UI.WebControls.TreeView.OnPreRender(EventArgs e) at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

I added some extra logic to capture the user agent in the log to figure out what browser is causing the error and the result is:

Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)

not that I'm very concerned with supporting IE 5.5 at this point but my question is do you think I did something incorrectly?

I'm also using CSSAdapters and some other .browser files, is it possibly a conflict?

Since I still also support .NET 3.5 I have 2 .csproj files and the 3.5 version includes the alternate version of the ie.browser file while the .NET 4 version includes the .NET 4 version of the file. Could it be a problem having both versions physically in the App_Browsers folder even though only the correct one is referenced in the .csproj file?

Thanks for any tips or suggestions.
Tuesday, August 30, 2011 2:57:44 PM UTC
Any news on the updates? They still don't appear to be available.
Friday, September 02, 2011 7:41:08 PM UTC
They are live now.
Thursday, November 10, 2011 12:42:38 PM UTC
Is there any plan from microsoft for providing IIS for other OS like Linux, SUN etc?
Comments are closed.
Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer’s view in any way.