IE9 crashes when dragging, scrolling, and updating styles

Internet Explorer 9 was released 4 years ago in 2011 which sounds like a short time, but it really is an eternity in the world of web development. IE has had 3 releases since then and the 4th is on the horizon, but the upgrade cycle of many companies doesn’t reflect that fast pace. So we must continue to support IE9, and in doing so we will uncover more obscure bugs that will never see fixes.

This was the case recently when working on a grid view in JavaScript. A customer reported IE9 would crash, as in close the browser window down, when dragging a column to reorder them. They could drag the column in either direction and repeat the crash reliably. No error message, no where to clue where to start other that the drag action.

Since there were no error messages to go off of I used WinDbg after reading a MSDN blog post on debugging Internet Explorer. I had a virtual machine downloaded from After getting WinDbg hooked up to IE I set off to replicate the crash and had no trouble in doing so. The error message stack trace ended inside mshtml.dll, which is also known as Trident, the IE rendering engine.

Internet Explorer architecture

Internet Explorer architecture

WinDbg delivered the crash stack:

6D6DD5BB 81 3F D0 AD A3 6D cmp dword ptr [edi],6DA3ADD0h

mshtml.dll!CDispScroller::SetScrollOffsetInternal()	Unknown
mshtml.dll!CDispScroller::SetScrollOffset(class CSize const &,int,bool,enum tagCOORDINATE_SYSTEM)	Unknown
mshtml.dll!CDragDropManager::DragOver(unsigned long,struct _POINTL,class CSize const &,unsigned long *)	Unknown
mshtml.dll!CDoc::DragOver(unsigned long,struct _POINTL,class CSize const &,unsigned long *)	Unknown
mshtml.dll!CDoc::DragOver(unsigned long,struct _POINTL,unsigned long *)	Unknown
mshtml.dll!CDropTarget::DragOver(unsigned long,struct _POINTL,unsigned long *)	Unknown

Looking at the ScrollOffsetInternal function I suspected it might be in the CSS positioning of the grid area. It was able to scroll left and right as the user dragged for a wider-than-browser grid. I removed all positioning from the element and was still able to get the crash. I lost the crash log that had the right clue, which is the one I got when I removed the positioning classes. The log mentioned CSS colors, paint, and I remembered that there was a hover on the columns as you dragged over them to indicate which one was active. I removed the class, and couldn’t crash the browser! However I lost that visual cue, and though I discovered the issue I wanted to keep the existing functionality in place.

The problem was in the timing. When we hit the drag enter event we would check to see if the element is a valid target, then add the class which changed the look. The crash happened when dragging an element, scrolling the element container, and updating the drag enter target’s parent class when it was outside the container. That update caused an attempt at a paint, which ultimately took down the browser on a null exception. WinDbg even let me walk through the assembly instructions to see Trident was trying to perform a math operation at the time. The solution was easy, just update the CSS on the next event and not in the same one. So now we drag and scroll, then update the style using setTimeout pushing that action off to the JavaScript event stack.

The older technology gets and the more you continue to have to use it necessitates learning new tools to take the investigation into your own hands. Don’t be afraid of debugging tools like WinDbg. It didn’t give me the answer outright, and Trident is closed source but the stack trace gave me some logic to follow. It gave me the clues I needed to deduce the problem and come up with a solution that not only works, but one that I understand why I had to add that setTimeout.

Adding Pinterest sharing to your iOS app

Update: Ric Santos pointed out in the comments that the iOS 8 share sheet includes Pinterest

I’ve been working on a new version of the iOS app, Wedding Dress Look Book by The Knot, and I wanted to add in sharing features for the most popular networks. This a wedding dress browsing and sharing app, it has to be the top three social networks, Facebook, Twitter, and of course, Pinterest. I know that Pinterest doesn’t have a public sharing API yet, but I use there app on my iPhone, and I have a good idea of how it works. For Facebook and Twitter I find out that iOS supports URL Schemes, which allow me to just open an app as I would open Safari. Just change the protocol, http for regular URLs, to the name of the app. I found a site that has a list of all sorts of apps that support this, fb:// for Facebook, twitter:// for the Twitter app etc. Unfortunately they didn’t have Pinterest, but an easy guess of pinterest:// launched the app right away, though I didn’t know of the options, and I still couldn’t find any documentation. I started to think about how the Pin It bookmark works, the URL scheme must be inside that JavaScript file that Pinterest loads onto the site in mobile Safari. After running the file,, through a Javascript Beautifier we can see Pinterest developers speak lolcat with plenty of hazSite and hazIOS. That was it!

if (a.v.hazIOS) {
	a.w.setTimeout(function () {
		a.w.location = "pinit12://" + e
	}, 25);
	a.w.location = "http://" + e
} else"http://" + e, "pin" + f, a.a.pop)

Pinterest’s URL scheme is pinit12, I’m guessing 12 is a version number. A little more digging around and I came up with a list of working parameters.

URL Scheme: pinit12://

  • media: a direct link to the image or I think an encoded image (base64?)
  • url: the URL of the source website where the image was found
  • description: 500 characters max
  • is_video: self describing

Since this code isn’t officially supported it is subject to change, and thankfully there is a way to future proof your app from having a broken link. You are able to check if a URL can be opened without actually opening it in iOS. The trick then is prepping your URL, seeing if it can be opening, and only then displaying the option to share with Pinterest. Using a UIActionSheet, with ARC enabled, this is what I came up with.

int count = 1;
UIActionSheet *sheet = [[UIActionSheet alloc] initWithTitle:@"" delegate:self cancelButtonTitle:nil destructiveButtonTitle:nil otherButtonTitles:@"Email", nil];
NSString *post = [NSString stringWithFormat:@"pinit12://pin/create/bookmarklet/?media=%@",@""];
NSString *escapedStringURL = [post stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
NSURL *url = [NSURL URLWithString:escapedStringURL];
if ([[UIApplication sharedApplication] canOpenURL:url])
    [sheet addButtonWithTitle:@"Pinterest"];
[sheet addButtonWithTitle:@"Cancel"];
[sheet setCancelButtonIndex:count];

This way, in case the URL scheme changes from pinit12 in the future it won’t break your application.

It has been added as a URL scheme to, most links seem to hit that listing. Thanks @akosmasoftware!

Magic Eight Ball with the Raphaël JavaScript Library (1.5.2)

Wrigley’s Magic Weight Ball is my first project using the Raphaël JavaScript Library and it just went live. I used Raphaël JS version 1.5.2 which you can download from GitHub. The project requirements came through as only being an iPad version that responded to a shake event. Getting to use a new technology for a front-end project where you only have to support one resolution and one browser is an excellent opportunity to try new things. I knew in the back of my head that they would want a non-shakeable static version as well but they just didn’t ask for it yet. Internet Explorer still came into consideration when I was evaluating technology solutions because I was certain it would come up eventually.

When I saw the Nissan Leaf site I was blown away by the heavy JavaScript animations being used. It really reminded me of the early Flash animations and sites in a way. The Hacker News submission I saw the site from pointed out that the animations were being handled by the Raphaël JavaScript Library. This was still fresh in my mind when I got this project so I loaded up the Raphaël demos pages in a ever browser I test on, IE6-9, Safari, Firefox and Chrome and they all worked! This was the library for this project.

I finished up the iPad version of the site which requires iOS 4.2 or higher and was pretty happy with the results. It responds to a full shake event to give you another tip, the tip will bob lightly in the water when moved a little bit and the tip orients to the iPad. When the tip is touched it provides a little modal with more details. The site even supports landscape and portrait viewing.

About half way through developing the iPad version the email I was expecting arrived. “Oh no!” they said, “We need a static non-shakable version for desktop users to visit.” I was already prepared though. When I though about a desktop version I first defaulted to Flash but I wanted to give Raphaël a try first. With a IE6 PNG alpha transparency fix and a small work around for IE to get the Raphaël image src it was up and running on the desktop.

You can visit to see the result and if you happen to hit the page in an iPad you will get a slightly modified version that still responds to the shake events, always giving the best experience possible.

The weight ball interface itself is a series of 3 layered PNG images. The top most image is a 24bit eight ball and the rest of the tips, triangles and back black images are all 8bit PNG images with the a properly picked matte color. The total site size was reduced as much as possible and the designers loved the look. I reduced the number of colors where ever possible and used a pattern dither, it really seemed to look the best even though it bumped up the file size a bit.

For this animation interface the Raphaël JavaScript Library was a perfect fit and I was able to provide a cross platform and cross browser experience that I was very proud of.