Scott Hanselman

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

August 18, 2011 Comment on this post [56] Posted in ASP.NET | ASP.NET Ajax | ASP.NET MVC | Bugs
Sponsored By

__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.


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.


  • 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.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
August 19, 2011 0:47
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 menu control, it renders different HTML in IE and chrome!
August 19, 2011 0:53
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.
August 19, 2011 2:07

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...
August 19, 2011 2:20

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?
August 19, 2011 2:27
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.
August 19, 2011 3:03
Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regbrowsers.exe -i
August 19, 2011 3:07
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?
August 19, 2011 3:57
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.
August 19, 2011 6:51
Cant they fix this bug in the .NET 4.0 browser definition while they are at it?
August 19, 2011 7:33
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.
August 19, 2011 12:15
Don't use postback or webforms these were great in 2002, but we have moved on.
August 19, 2011 12:35
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"/>
August 19, 2011 12:50
Wow! New fresh look for your site! Love it!
August 19, 2011 12:55
Thanks! I'm thrilled with it.
August 19, 2011 14:03
Nice look and good picture in the right top corner !
August 19, 2011 16:17
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?
August 19, 2011 16:43
Never mind, now it's suddenly working :-) Thanks!
August 20, 2011 0:22
For those of us who have to update manualy, can't these also go in the web.config file, rather than App_Browsers?
August 20, 2011 0:48
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.
August 20, 2011 14:24
thanks scott great post,
August 21, 2011 2:54
you saved my day,
Thank you
August 24, 2011 8:17
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"?
August 24, 2011 8:37
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>
August 24, 2011 15:35
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
August 25, 2011 13:13
Soo when will the machine-wide microsoft support pages go live?
August 25, 2011 17:30
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.
August 30, 2011 18:57
Any news on the updates? They still don't appear to be available.
September 02, 2011 23:41
They are live now.
November 10, 2011 16:42
Is there any plan from microsoft for providing IIS for other OS like Linux, SUN etc?
October 12, 2012 21:42
Any idea when the fix will be available for windows update or what it will be called?
October 16, 2012 16:50
Hey Scott - Any idea of when it will be avilable for Windows update or what the patch will be called?
October 17, 2012 2:34
This was on Windows Update in November/Dec of 2011.
October 17, 2012 3:29
"This was on Windows Update in November/Dec of 2011."

Thanks for the information Scott. I was wondering if you can confirm whether the update will fix the same issue for a .Net 2.0/Windows 2003 application?

Thanks, PPD
October 17, 2012 21:15
PPD - Yes, look above, there's a 2.0 KB article linked here.
October 28, 2012 16:33
I installed the update and I am still seeing Surface RT's IE10 demonstrate some strange behavior. In general the __doPostBack is working for update panels, but dropdownlists are not getting their SelectedIndexChanged to fire. Is there anything different with the Surface RT's user agent (versus the Windows 8 that folks have been using for a while now) that might be causing this? Here is the user agent that I am seeing from my new (sparking and awesome) Surface RT:

Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; ARM; Trident/6.0; Touch)

I notice the 6.2 instead of 6.1, could that be part of the issue here?
October 29, 2012 22:10
I installed the update on a production web server that is running Windows Server 2008 R2 SP1. I am finding opposite behavior there - the dropdownlists are working fine with regards to their SelectedIndexChanged event firing, but on that server an imagebutton that is inside an updatepanel will not fire, and IE 10 displays a pop-up that says:

Sys.WebForms.PageRequestManagerServerErrorException: An unknown error occurred while processing the request on the server. The status code returned from the server was: 500

BUT, there is no request that made it to the server in the logs, and no 500 response going back at all. Some other places in our app have an imagebutton inside an updatepanel and they also do not work but they do not display an error message either.

I also tried including the ie.browser field in our app's App_Browsers directory but that did not make any change.

It is important to note that I am seeing different results when I hit the same app running on a Windows 7 web server versus the WinServer 2008 R2 web server. The Win7 server is now working just perfectly, but we can't seem to get the new ie.browser file fix to take effect on the WinServer 2008R2 box. We have ensured that the update has been installed and rebooted. We can see that the ie.browser file has been updated in the CONFIG directory in the .NET Framework directory. Maybe we should try to patch with the version meant for the RTM build?
October 29, 2012 23:25
I'm also having issues after applying the ie.browser, i've tried the machine and the application specific configurations and nothing seems to help.

Anyone else having the issue still?

I'm also seeing it occur on win2008 but not on win 7 hosted instances. Win2008 is fully patched and the issue is NOT fixed yet.

October 30, 2012 0:01
Hi Ed, sounds like you and I are seeing the exact same thing - the patch seems to work nicely on Win7, but not on Win2008. What exact version of Win2008 are you on? We are on Win2008 R2 Standard with SP1 X64. Our Win7 that exhibits good behavior after applying the fix is Win7 Ultimate SP1 X64.
October 30, 2012 5:07
Here is more information...

I have two WinServer 2008 R2 Standard SP1 X64 servers, and one of them exhibits the problem while the other does not. Believe it or not, I installed the patch on the server that exhibits the problem and I have not installed it on the server that does not exhibit the problem. Let's call the server that works properly and does not have the patch, Server A, and the bad one we will call Server B.

I inspected the HTML source of my page and then made IE10 request the WebResource.axd and ScriptResource.axd URL's that are in the HTML source. I did this for both Server A and Server B, using each's HTML source of course. I found that WebResource.axd is serving the same javascript from both servers. But ScriptResource.axd is serving a different file. Server A seems to be serving a file that is nicely formatted for development while Server B seems to be serving a minified field. They are hard to compare because of this - my VisualDiff can't do it and neither can I manually.. But I can see right off the bat that the files are different because the first few lines differ in terms of the comments that are there in the files. Server A's file starts out like this:

// Copyright (C) Microsoft Corporation. All rights reserved.
// MicrosoftAjaxWebForms.js
// Microsoft AJAX ASP.NET WebForms Framework.


and then Server B's file looks like this:

// Copyright (C) Microsoft Corporation. All rights reserved.
// MicrosoftAjaxWebForms.js

and then it continues on one line due to the minified formatting. But notice that Server B is missing a comment line before the Type.registerNamespace, etc.

I think the next thing I need to do is find the source (no pun intended) of these files so that I can determine what object or layer of code is serving the wrong file.
October 31, 2012 0:23
I think I figured out what is happening. The web.config setting of compilation debug="true/false" specifies if ASP.NET Ajax Toolkit serves the debug or minified versions of its javascript files. For some reason the minified versions are having problems with IE10. The easy fix is to modify web.config to use debug, but of course that may have other ramifications that are undesirable. Another way to accomplish the same thing without causing trouble is to explicitly set ScriptManager.ScriptMode = ScriptMode.Debug if the browser is IE10. That's what we are going to do for now. I hope this helps somebody else.
October 31, 2012 18:44
When I try and run that hotfix I get: KB2600088 does not apply, or is blocked by another condition on your computer. So I guess it's not compatible with Windows 8
November 01, 2012 19:22
Thanks for the Info Alan, even with debug false we are still seeing the issue.

It's not even returning webresources.axd at all when the browser is IE 10 on win 8.
November 05, 2012 23:07
I can't install .net framework 4.5 on Windows Server 2003. When I use the menu control show me
Server Error in '/' Application.

Input string was not in a correct format.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.FormatException: Input string was not in a correct format.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[FormatException: Input string was not in a correct format.]
System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal) +7471479
System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info) +119
System.Version..ctor(String version) +259
System.Web.Configuration.HttpCapabilitiesBase.get_MSDomVersion() +52
System.Web.UI.WebControls.Menu.EnsureRenderSettings() +135
System.Web.UI.WebControls.Menu.OnPreRender(EventArgs e, Boolean registerScript) +22
System.Web.UI.WebControls.Menu.OnPreRender(EventArgs e) +25
System.Web.UI.Control.PreRenderRecursiveInternal() +80
System.Web.UI.Control.PreRenderRecursiveInternal() +171
System.Web.UI.Control.PreRenderRecursiveInternal() +171
System.Web.UI.Control.PreRenderRecursiveInternal() +171
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +842

On IE6-9 working without problems but IE10 don't work
November 12, 2012 0:55
Is it available in windows update or we have to do it manually......
November 14, 2012 21:46
Is there a fix for .NET 1.1 applications as well? I am getting this problem for a legacy app. I just get a white screen when I try to navigate anywhere in IE10 only.
November 14, 2012 22:34
Brad - Try adding meta http-equiv="X-UA-Compatible" value="IE=9"
to the head?
November 15, 2012 0:17

Sorry, but that didn't seem to affect anything. This might be a different issue than what this article addresses, because I am not getting any script errors. However, when I do a redirect, it goes to a blank screen with this as the source:

November 16, 2012 10:08
bit of a gotcha for those of you who are using the 'site-only fixes' part of this page and upload their sites uncompiled:

the new browser definition file will NOT be used until the site recompiles, just uploading it isn't enough. the best way to guarantee that the site recompiles is to change a value in the web.config file (i've been using the debug setting) and re-uploading it to the site in question.

it took me a bit of stress to figure this out...

this is on our shared hosting environment (they refused to apply the hotfix) so the experience maybe different for others.

hope this helps someone out ;)
November 16, 2012 19:54
Scot, thank you for the article.
I have a lot of .NET1.1 application on win2003.
Do you have by a chance hot fix for those?
November 26, 2012 11:02
I face this problem with IPOD and Apple Safari browsers,
I already installed the hotfix, but my site still didn't display correctly in Ipod! Can you help?

Can I change the default browser file to support javascript?
December 05, 2012 3:34
Saddly, once you go through the hoops to get the hotfix the link M$ sends you the link to get the fix...Sorry, it just provides this insightful message.

"The resource you are looking for has been removed, had its name changed, or is temporarily unavailable."

I went through the process twice just to make sure.
Thanks loads for the typing exercise!!

December 06, 2012 5:27
I'm running into this issue as well. We've tried installing the new(est?) browser definition files from the link provided and we are still not seeing <asp:DropDownList>s (in specific) being rendered properly.

The __doPostBack() function is not being defined and it's not rendering the ddl w/ an autopostback attribute in the rendered <select> even though it's in the <asp:DropDownList>.

Is there any solution to this?
December 14, 2012 20:18
We changed our browser definition files as per your instructions and our link buttons work again. We were worried this was going to be a catastrophe of Mayan proportions. Thanks!
December 18, 2012 10:57
I have the same issue that my website is not working with ie10 there is no postback I have tried the solution that include browserfile.browser but it won't work for me

Any help I will be thank full to you
December 31, 2012 15:41
I can get round the problem if I can put the user's browser into IE8 mode (equivalent to pressing F12 and selecting "Internet Explorer 8"

Is there any way to do this... I tried
<meta http-equiv="x-ua-compatible" content="IE=EmulateIE8" />
but with no success - it just changes Document mode
December 31, 2012 18:10
I'm trying your "Project" based solution for Net 2.0 (as my host won't let me use the "System wide" one)

I use VS 2008, and when I added an "App_Browsers" folder it was created with a small blue/green spot in the folder icon (the same as the Web References folder). I can't find what this means, but double clicking on the folder doesn't open it. I added the ie.browser file from the zip by opening the folder in Windows Explorer.

Is this sufficient and do I have to copy this folder to the web site?

(please note also that the firefox.browser file is not in the zip)

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.