Deep within the .NET framework installation is a folder full of what are called browser definition files. For example this folder for version 4 forward is here:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\Browsers
It is full of xml configuration files with an extension of .browser. These files tell ASP what Javascript and HTML to render for each browser and version.
When IE 10 was released there was an issue with certain things not working. An example was a DropDownList control not posting back. It turns out that there was a bug in the browser definition file for IE in the .NET framework. This link describes this:
http://www.hanselman.com/blog/BugAndFixASPNETFailsToDetectIE10CausingDoPostBackIsUndefinedJavaScriptErrorOrMaintainFF5ScrollbarPosition.aspx
Microsoft created a hotfix that updates these files and fixes the bug when you run it on the server hosting the site. I was really hesitant about deploying a hotfix to a production web server. My preference is to wait for hotfixes to be put into at least a cumulative update if not a service pack (This doesn't appear to have happened at the time of this writing). So, I added the updated IE browser definition file directly to the Visual Studio web project by adding a special ASP.NET folder named App_Browsers. I then added the updated .browser file from the link above to this new folder. After I published the site, the issues I had disappeared.
UPDATE:
I ran into similar problems with IE 11. However, I could not find the browser files for IE 11 anywhere. It looks like Microsoft prefers you to go the hotfix route. So I installed the following hotfix on the web server, and everything then rendered correctly.
http://www.microsoft.com/en-us/download/details.aspx?id=39257
KB2836939
Showing posts with label Internet Explorer 10. Show all posts
Showing posts with label Internet Explorer 10. Show all posts
Tuesday, January 14, 2014
Tuesday, December 31, 2013
Disabling ASP LinkButton controls in newer versions of Internet Explorer
Since IE 10, I have noticed that when a LinkButton control is disabled (Enabled="False"), the rendered link is not grayed out like it used to be and seemingly should be. The link is disabled for all intents and purposes, but just appears to be enabled. This can cause confusion to users if you rely on this mechanism. The quick fix has always been "compatibility view" in IE, but this is being phased out over time by Microsoft as we get newer version of Internet Explorer.
Interestingly enough, the html rendered is the same. You still get an anchor tag with the disabled attribute set to "disabled". It is the browser that is reacting differently to this tag. IE no longer styles by default an anchor tag with this particular attribute the way you expect (i.e. "grayed out"). You are forced to provide the css to render in this scenario. The following css should style your LinkButton like the good ole days.
Interestingly enough, the html rendered is the same. You still get an anchor tag with the disabled attribute set to "disabled". It is the browser that is reacting differently to this tag. IE no longer styles by default an anchor tag with this particular attribute the way you expect (i.e. "grayed out"). You are forced to provide the css to render in this scenario. The following css should style your LinkButton like the good ole days.
a[disabled="disabled"] {
color: gray;
text-decoration: none;
}
a[disabled="disabled"]:hover {
color: gray;
text-decoration: none;
}
Now, maybe you can finally turn off compatibility view!
Monday, October 28, 2013
Ignore the route when adding a web service to an MVC project
You may want to add a web service to an MVC project in order to to implement AJAX call backs. Remember that MVC is always trying to interpret URLs using it's routing configuration. So, if the routing configuration encounters a URL referring to your web service, the framework won't know what to do with it.
You could just put it into another web project. This works fine with IE 10, but Chrome will blow up. I think it has something to do with cross domain configuration (and lack thereof). Do yourself a favor, and stick it in the MVC project, and remember to add this to your RegisterRoutes method:
You could just put it into another web project. This works fine with IE 10, but Chrome will blow up. I think it has something to do with cross domain configuration (and lack thereof). Do yourself a favor, and stick it in the MVC project, and remember to add this to your RegisterRoutes method:
routes.IgnoreRoute("YourAjaxEnabledService.svc/DoWork")
Labels:
.NET,
AJAX,
Internet Explorer 10,
JavaScript,
jQuery,
MVC,
MVC 4
Tuesday, May 28, 2013
Internet Explorer 10 breaks debugging with Visual Studio 2010
"Welcome to your new browser!" Today, automatic updates installed the latest version of IE and I noticed that I got the following error when debugging from Visual Studio 2010:
After some research on the web, it looks like everyone gets this after installing IE 10. The solution is to register the new IE10 debugger dll. Apparently, this would happen if you installed Visual Studio after you installed your browser (which is normally what happens). So use this command as an admin:
After some research on the web, it looks like everyone gets this after installing IE 10. The solution is to register the new IE10 debugger dll. Apparently, this would happen if you installed Visual Studio after you installed your browser (which is normally what happens). So use this command as an admin:
regsvr32 "%ProgramFiles%\Internet Explorer\msdbg2.dll"If you are using a 64 bit box, then use the command prompt here:
C:\Windows\SysWOW64\cmd.exeOtherwise, just use the standard command prompt. Remember to run it as administrator.
Subscribe to:
Posts (Atom)
