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: http://support.microsoft.com/kb/2836939/en-us – 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:

http://www.hanselman.com/blog/IE10AndIE11AndWindows81AndDoPostBack.aspx
http://www.hanselman.com/blog/BugAndFixASPNETFailsToDetectIE10CausingDoPostBackIsUndefinedJavaScriptErrorOrMaintainFF5ScrollbarPosition.aspx

Werbeanzeigen

Touch & Gestures in JavaScript with Windows 8

29. Januar 2013

Recently I had to implement touch & gesture support in JavaScript for a Windows 8 touch device (Asus Ultrabook). As I prior had to add Android support to my existing iOS-library I picked a nice framework: hammer.js which supports iOS & Android… but even then they recently updated to support Windows RT on a Surface this did not work out on our new Asus Ultrabook which we bought especially for developing touch support with JavaScript.

So I had to study how Microsoft did implement their touch support. Pretty fast I stumbled over their well documented library. But unfortunately I had to discover that (again) Microsoft did something on their own: Even if Android and iOS did manage to support nearly the same eventtypes („touchstart“, „touchmove“, „touchend“) so you can easily use the same code for both device types, Microsoft introduced two proprietary event types: MSPointer and MSGesture.

So this lead to the point where I had to extend the nice hammer.js framework with new code which handles the special Microsoft events. You can find a fork on github which I will try to add it to the original framework soon when I’ve finished testing.

The main thing about the gesture support is that you have to create a MSGestureObject for each element you want to handle gestures – otherwise you will only get PointerEvents and will need to handle all interpretation by yourself. After you registrated such an object you will get the events with a plentyfull of information about the current gesture and it’s changes – like rotation and scaling. But here comes the disappointment: The online documentation only names it as rotation but unfortunately it’s more like a translation of the CSSMatrix which is also a proprietary object of Microsoft to handle CSS-transformations. So as I wanted to extend a framework which delivers a wrapper-event with these information I had to pull back and calculate the scaling and rotation by myself instead of using the quite cool but in this scenario unuseful features.

During my work I stumbled over several issues with the MSPointer & MSGesture events which I would like to share:

Event Bubbeling
One issue is that the event bubbeling in IE10 works bottom-up – on iOS or Android it’s top-down… so after realizing this (and it unfortunately took quite long) I finally got an answer why I retrieved events from the wrong HTML elements – something which can be real disturbant when you try to register the MSGestureObject only for these elements you want events for.

Dual Events
Another problem is that even when MSGesture-events are fired the browser still continues to throw the MSPointer-events – fortunately this is something positive as you can now record your own „touches“-array… As the MSGestureEventObject comes with already calculates scale and rotation, they simply miss an array of touches with the coordinates of the finger-tips… As the hammer.js and my own implementation take big usage of these arrays I had to implement my own array with the MSPointerEvents.

Still MouseEvents
On our Ultrabook we had also the problem that the touch device also fires a Mouse-event each time you tap or drag something… as this is normally not to be expected the initial author of the hammer.js-framework simply ignored this and interpreted each mouse event as a touch-event… I expected Windows 8 to hold back the mouse events as I’m really only touched the screen.

Debugging
Finally there is to say that there does not really exists a nice debug-tool for the IE10 in touch-mode (or Metro-Style or however it is called)… so I had to turn back to classic „debug.print“/“console“-debugging by writing my own debug-console to the DOM… Every iOS-developer without Safari 6 (see my last post) will know what I mean.

Identify
UPDATE: Currently I’m struggeling with identifying whether the IE10 comes as Metro or desktop version… unfortunately there is no clear way to identify. The best practice is that you can only hope the desktop version is not started as 64-bit application and so you can lookup the userAgent-string. See this stackoverflow question for more details.

Our next question is how a Microsoft Surface behaves with Windows 8? On Windows RT it seems to simply send „touch“ events as there is a contributor of the hammer.js-framework who added Surface-support without interpreting new event types. But unless I do not have a Surface-device in my hands I will not be able to say something about it. But when I get hold of such a device I will post an article of course.