Page 1 of 1 in the InternetExplorer category
# Thursday, 05 December 2013

When Internet Explorer 10 launched, it caused some problems with the antiquated browser detection feature of ASP.Net, and thus you needed to make sure that you installed the right patches or performed the right fixes in order to get everything working properly. And I talk about the IE10 incident here on my blog.

And now Internet Explorer 11 has just been auto updated to many users, and again I was seeing problems with my websites. At a MUCH worse scale this time I might add, not only were scripts not being sent ASP.Net didn't think IE11 was capable of receiving cookies which just royally broke the website.

Sometimes your site might seem ok, but buttons are not working and everything that seems to be tied to Javascript seems to be malfunctioning, looking into the Javascript debug console you see something similar to this message :-

'__doPostBack' is undefined

or something like

'WebForm_DoPostBackWithOptions' is undefined.

Once again Scott Hanselman talks about the problem, and mentions the obvious solution of ensuring your server patches were up to date.

But I couldn't get my client's servers patched for some reason, so I hunkered down and tried to manually patch the browser definition file. At first I thought I could just insert the new version into the existing IE browser definition file like it was done for IE10 the last time. Then I actually saw the IE11 user agent string:-

Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko

The MSIE moniker which was used to identify Internet Explorer was DELIBRATELY removed, because IE11 is more than capable of handling HTML5 now and they didn't want any poorly coded Javascript library to incorrect identify IE11 as being an older, less HTML5 capable browser and tell users to use some other browser instead. Very good intentions I must say, too bad ASP.Net brefore 4.5 happens to be one of those legacy systems that do User Agent sniffing and because it didn't see anything it knew was defaulting IE11 to something which couldn't handle Javascript, Cookies, and many many other things.

At first I thought about writing a regular expression pattern which could parse the new User Agent and identify the browser properly. But there were 2 problems with that idea. The first was that I was CRAP at writing complex regular expressions, the second was the fact that why should I even bother with browser sniffing? Every damn browser supports Javascript now, and websites pretty much NEED Javascript anyway. So I set about to make it so that the default browser definition enabled all modern features.

I did so by overriding the default browser defintion at my web site level. First I created a app_browsers folder in the root of the web site, then I create a file called newdef.browser with the following content

UPDATE Jan 30th 2013 : You might not see changes right away when you drop the file in, you might want to try restarting the IIS web pool, if you can't do that, try toggling the compilation/debug attribute under system.web in the root web.config file by alternating it between true and false to restart it.

<?xml version="1.0" encoding="utf-8"?>
<browser refID="Default">
  <capability name="browser" value="Generic UpLevel" />         
            <capability name="type"                            value="Generic" />
            <capability name="ecmascriptversion"               value="3.0" />
            <capability name="javascript"                      value="true" />
            <capability name="javascriptversion"               value="1.7" />
            <capability name="w3cdomversion"                   value="1.0" />
            <capability name="supportsAccesskeyAttribute"      value="true" />
            <capability name="tagwriter"                       value="System.Web.UI.HtmlTextWriter" />
            <capability name="cookies"                         value="true" />
            <capability name="frames"                          value="true" />
            <capability name="javaapplets"                     value="true" />
            <capability name="supportsCallback"                value="true" />
            <capability name="supportsDivNoWrap"               value="false" />
            <capability name="supportsFileUpload"              value="true" />
            <capability name="supportsMaintainScrollPositionOnPostback" value="true" />
            <capability name="supportsMultilineTextBoxDisplay" value="true" />
            <capability name="supportsXmlHttp"                 value="true" />
            <capability name="tables"                          value="true" />

What the file does is that it overrides the default browser definition of a crummy featureless browser to a more up to date one which supports all the cool stuff like cookies, Javascript, etc. etc. I basically just copied all the capability tags from the Chome browser definition file.

WARNING : If for some poor unfortunate reason that you actually RELY on ASP.Net's browser detection feature to detect ancient browsers this will effectively BREAK the function so do so at your own risk!

Thursday, 05 December 2013 23:29:33 (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [0]  | 
# Wednesday, 03 July 2013

“The site isn’t working with Internet Explorer 10!!!” yells my client through the IM window, to which I gave a WTF expression since I developed it under IE10 and it worked beautifully.

Wondering what kind of problem it could be I got him to open up a remote session so I could see what the problem was, sure enough the site was a mess, layouts were wrong, backgrounds were missing, it was as if the browser forgotten to download a few CSS files, so I hit F12 to bring up the developer tools and then I saw the problem.


For some reason his IE10 was in IE7 mode, which was outside of the support scope of the project (Thankfully!). So I switched it back to IE10, and everything looked and worked fine again.

So if someone is complaining that the site looks and works horribly in IE10 when it shouldn’t be, you might want to check if any of these compatibility settings are in effect!

Wednesday, 03 July 2013 00:13:12 (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [0]  | 
# Tuesday, 24 July 2012

As I was surfing around the web using my Windows 8 machine, I noticed a few problems with some of my websites. After poking around a bit I realized that the symptoms I was seeing were pretty much the same as the iOS Safari WebView problem I discovered previously. And sure enough... it's the browser capability files again. More info available on Scott Hanselman's blog.

You really should go and read up on the post, but in summary. If you run a ASP.Net webserver, you really should install these patches like RIGHT NOW so that users on IE10 will not experience any problems.

They should be up on Windows Update, but better safe than sorry.

If you don't have control of the server and can only upload files to your web application's folder, download this file from Scott's site. In the zip you'll find a projects/net[version] folder, along with some *.browser files. Copy the appropriate file to an app_browser folder in the root of your website and you'll be fine. Note that ASP.Net 3.0/3.5 is consider to be running on ASP.Net 2.0.

Tuesday, 24 July 2012 22:46:45 (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [0]  | 
# Friday, 28 October 2011

If you use Internet Explorer, lately around the web you might have been receiving a LOT of "Only secured content is displayed"  messages such as the one below.


After you get such a message, the site might not work properly, or you might not be able to interact with certain features on the site.

Why is this happening? Well, the culprits include, but are not limited to...


Yes.. the simple LIKE type buttons.

In order to better protect the privacy of their users, the scripts for these buttons are now being retrieved via HTTPS instead of deciding which to use depending on the protocol the source page is using.  This means there's now a mixed scheme content scenario that's occuring.

I'll try to explain it in simple terms. If you visit a website using the url of

And that page chooses to draw in content from another source using HTTPS such as

The page now contains content from a secured location as well as an insecured location. And IE treats that as a potential privacy concern, and hence pops up the message you see at the top of this article.

The Solution

There'll be people who argue that it's GOOD that IE decides to warn users about such mixed mode content, and there'll also be people who argue that IE is BAD for not allowing it since the other browsers have no such problems (I'll get to them later) But... if you want to get rid of these warnings (which might be a good or bad thing) here's what you do.

Go to Internet Options (Under the GEAR menu for IE9, Under Tools menu for older versions)


Select the Security tab, then hit the Custom Level button.


In the giant list that appears find Display mixed content and change it from Prompt to Enable


Click on the OK button to accept the changes and you'll be rid of the mixed mode warnings.

What about the other browsers?

Now... what about the other browsers how do they handle mixed mode content?

Google Chrome takes a more conservative approach to it's warnings in the sense that if your main page is viewed using HTTP and then gets something from a more secured HTTPS connection, it won't complain about anything since the extra content is MORE secure than the original content. But... if you're on a HTTPS page, which then calls for something from a HTTP source such as images, plugins, widgets, etc. etc. you get the warning below.


(Site identity removed because I'm not implying that the site isn't secure and I don't want people to get that idea) Clicking on the broken lock presents a non intrusive indicator (crossed out https) to show that everything the site is showing isn't fully encrypted. Even comes out with a explanation of the current mixed mode situation. Of course a normal user probably couldn't care less about how much of the page they're viewing is encrypted. And thus we come to Firefox's method of handling mixed scheme content.

It's what I'd like to call the "Users don't give a damn about this stuff anyway!" method.


First of all there's NO indication on the address bar that anything is amiss with the page at all when a HTTPS page contains mixed mode content from a less secured source. Clicking on the help indicator would give you some information, but as there's no broken HTTPS indicator like in Chrome, a user would have no incentive to click it and find out if anything's amiss

Ok... So there is one DIFFERENCE between a mixed content page, and a fully secured page


A fully secured page show's it's domain name in the address bar, but how many users would know that if it wasn't pointed out to them?

Of all the 3 browsers and how they deal with mixed scheme content. I must say I personally prefer Google Chrome's non intrusive method of telling users about mixed scheme content. Though the crossed out HTTPS icon might scare users into thinking the page is not secured.

Friday, 28 October 2011 16:55:55 (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [0]  | 
Page 1 of 1 in the InternetExplorer category