Problems with Internet Explorer (10)11 and ASP.NET

28. November 2013

Recently we’ve received a support request about an issue concerning the DirectSmile Card and Gift Shop. Customers who use IE11 will continously be prompted to log in again when trying to order.

After some investigation (it was more like searching the needle in the haystack) we’ve been able to pin this issue down to a more general problem with Microsofts ASP.NET framework: When Microsoft introduced the new Internet Explorer 11 (and this happened also to the version 10) they have changed the user agent string delivered by the browser to the server. This string will be parsed by the ASP.NET framework to identify the browser and it’s capabilities (eg cookie support). This is also a problem for the document web-preview in DirectSmile Integration Server as the AJAX-calls will fail when using IE11.

Unfortunately the regular expression Microsoft uses for the parsing was not prepared for version 10 and 11 – with version 10 it simply failed that there are now two digits (9 –> 10) written. And with version 11 the whole string has been changed so the complete regular expressions needs to be changed.

So when a shop customer logs in the browser is recognized to not support cookies – therefor the IIS will switch to cookieless session states which result in a URL with an extra session ID. As the membership provider who is in responsibility for managing the logins does not support cookieless sessions, the customer will continously be prompted to log in.

Fortunately there is already a hotfix which will hopefully become part of the regular server updates soon: – you won’t need to update all settings by hand.

So after installing this patch your software should work again for Internet Explorer 11

For more technical details I recommend these nice article from Scott Hanselman:


Beloved Internet Explorer and massive Style-Tags

5. Januar 2012

Today a colleague and I stumbled over an interesting limitation of the Internet Explorer:

In one of our web-projects we’re producing dynamic web-output and also added usage of jQuery-UI for nice pretty radio buttons. The context of the dynamic output could include nice web-formulars with many of these nice pretty radio buttons. Unfortunately every single group of radio items creates dynamically a new <STYLE>-Tag – nothing special we thought.

Unfortunately the Internet Explorer owns a limitation of CSS-entries: A maximum of 32 entries is allowed inside a single web-page. All following elements will be ignored.

Using Google I soon found entries from Microsoft concerning this problem – but again they’re working against me: It’s a feature not a bug 😦

Maybe a community-link could help:

Well… finally we could say that it’s not a fault of our software but a IE-bug… my colleague works now on a solution of pre-rendering the new styles and collecting them in a single <STYLE>-Tag.

Be careful using jQuery’s .click()

19. Dezember 2011

Today I would like to share my current experience with jQuery event handler registration and why you should not use jQuery’s .click()-function:

In my current project I need to use lots of javascript and of course startet from begin to use jQuery as one of the most useful (if not THE most useful) javascript-frameworks. Currently my script uses plenty of event-handlers all added via .bind() from jQuery. Additional I use a nice little script for contextmenues which I found to be very useful and easy to integrate (

Unfortunately this contextmenu uses .click() to bind the handler for the menu-entries. For the first weeks this did noch caused any issue – unless last weeks Internet Explorer update (maybe it could be of interested that we primarly develop for IE and currently do not regard the other browsers). So today one of my colleagues came up and reported to me that the context menu is not working anymore.

So what seems to have happened is that Microsoft decided to fix their event-handling: My code defines a global mouse-down-event which eleminates data which my contextmenu needs. Of course it make sense that a mouse-down is called before a mouse-click as the click-event only is kind of virtual event and combines mouse-down and mouse-up. But as it always worked fine for me and I did not took a closer look into the context-menu-script…

Here the code as it was before:


And as I modified to prevent the global mouse-down-event:

row.find('a').bind('mousedown', function (e) {
                        return false;
                    }).bind('mouseup', item.action);
Happy Shopping!!