Bug and Fix: ASP.NET fails to detect IE10 causing _doPostBack is undefined JavaScript error or maintain FF5 scrollbar position
Sponsored By
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.
- .NET 4 - http://support.microsoft.com/kb/2600088
- .NET 2.0
- http://support.microsoft.com/kb/2600100 for Win7 SP1/Windows Server 2008 R2 SP1, Windows Vista/Server 2008, Windows XP/Server 2003
- http://support.microsoft.com/kb/2608565 for Win7/Windows Server 2008 R2 RTM
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
If 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.
- .NET 4 Browser Update NuGet Package - http://nuget.org/List/Packages/App_BrowsersUpdate
- install-package App_BrowsersUpdate
- .NET 2.0 Browser Update NuGet Package - http://nuget.org/List/Packages/App_BrowsersUpdate.net20
- install-package App_BrowsersUpdate.net20
- Note that NuGet is VS2010 specific so if you don't have nuget.exe and .NET 4, you can also copy the .NET 2 updated browser files into ~\App_Browsers manually from this zip file.
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.
- Hotfixes are availble with download links.
- .NET 4 - http://support.microsoft.com/kb/2600088
- .NET 2.0 - http://support.microsoft.com/kb/2600100
- The files will also be part of the next batch of .NET 4 fixes, which are anticipated to ship around January 2012 via Windows Update.
- The next version of the .NET framework will include all the updated files.
- Hotfixes are availble with download links.
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.
About Newsletter
Hosting By
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.
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...
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...
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?
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?
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.
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.
Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regbrowsers.exe -i
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?
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.
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
https://connect.microsoft.com/VisualStudio/feedback/details/682952/java-can-no-longer-send-cookies-for-login
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.
Don't use postback or webforms these were great in 2002, but we have moved on.
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"/>
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"/>
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?
Any help for this?
For those of us who have to update manualy, can't these also go in the web.config file, rather than App_Browsers?
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.
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"?
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 - 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>
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
If your Firefox 6 keeps reloading your MicrosoftAjax.js-enabled page when the URL contains a #, check out This post on StackOverflow
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.
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.
Is there any plan from microsoft for providing IIS for other OS like Linux, SUN etc?
Any idea when the fix will be available for windows update or what it will be called?
Hey Scott - Any idea of when it will be avilable for Windows update or what the patch will be called?
"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
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
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?
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?
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?
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?
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.
Thanks,
Ed
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.
Thanks,
Ed
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.
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.
Type.registerNamespace('Sys.WebForms');
and then Server B's file looks like this:
//----------------------------------------------------------
// Copyright (C) Microsoft Corporation. All rights reserved.
//----------------------------------------------------------
// MicrosoftAjaxWebForms.js
Type.registerNamespace("Sys.WebForms");Sys.WebFor
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.
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.
Type.registerNamespace('Sys.WebForms');
and then Server B's file looks like this:
//----------------------------------------------------------
// Copyright (C) Microsoft Corporation. All rights reserved.
//----------------------------------------------------------
// MicrosoftAjaxWebForms.js
Type.registerNamespace("Sys.WebForms");Sys.WebFor
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.
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.
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
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.
It's not even returning webresources.axd at all when the browser is IE 10 on win 8.
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
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
Is it available in windows update or we have to do it manually......
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.
Brad - Try adding meta http-equiv="X-UA-Compatible" value="IE=9"
to the head?
to the head?
Scott,
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:
<BODY><ASP_SMARTNAV_RDIR url="/Example.aspx"></ASP_SMARTNAV_RDIR></BODY>
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:
<BODY><ASP_SMARTNAV_RDIR url="/Example.aspx"></ASP_SMARTNAV_RDIR></BODY>
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 ;)
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 ;)
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?
I have a lot of .NET1.1 application on win2003.
Do you have by a chance hot fix for those?
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?
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?
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!!
NOW WHAT?
"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!!
NOW WHAT?
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?
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?
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!
I have the same issue that my asp.net 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
Any help I will be thank full to you
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
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
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)
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.
I don't understand the adapters too, when you use ASP.net menu control, it renders different HTML in IE and chrome!