Get hands-on training for JIRA Software, Confluence, and more at Atlassian Summit Europe. Register now ›

GreenHopper uses JavaScript a lot, from drag & drop up to dynamic card resizing. That works pretty well, naturally excluding Internet Explorer. So I spent the majority of the last sprint with figuring out the culprits and bringing GreenHopper up to speed in IE.

Drag & Hang & Drop

First thing to notice was that the drag and drop on the Planning Board was painfully slow. Trying drag an issue to another position would bring the processor to 100% load immediately. Two things happen: The issue box is moved along, and the other rows move out of the way to make space for it to be dropped.
A profiling run reveals some unexpected method calls:
gh-ie7-planningboard.png
screenSizeHandler is used for some size adjustments and should only be fired when the browser window size is changed. It’s a pretty expensive operation at around 100ms on IE7, and it’s getting called 24 times here.
Some further tests show that apparently, IE7 fires an onResize event not only when the viewport size changes, but also when the BODY size changes – which of course happens during the drag operation when the other lines move out of the way.
After setting a simple flag for IE to not fire that method when dragging, performance goes up significantly and drag / drop is smooth:
gh-ie7-planningboard-fixed.png

Waiting for the Task Board

The second big issue we had was the load time of the task board. After the page was loaded, the browser would spend some seconds, again on 100% processor load, before it became usable.
Profiling shows that IE7 spends a lot of time with CSS selectors. Yet, the problem with IE7 was actually not in the iteration over the respective DOM tree elements, but interestingly enough with the extension Prototype does to them. The stack shows that in order to read an attribute, which Prototype needs for the class-based CSS selector used here, it actually extends all elements of the tree it needs to check:
gh-ie7-taskboard.png
Now we’re not actually interested in having the elements returned by the selector query extended, since we just want to do native operations on them. With a small change, our (custom) Prototype lib doesn’t do that anymore (for IE), and the performance gain is immense:
gh-ie7-taskboard-fixed.png
For an application that makes quite heavy use of JavaScript, like GreenHopper, client-side tuning will be an ongoing process, especially for Internet Explorer.

Fresh ideas, announcements, and inspiration for your team, delivered weekly.

Subscribe now

Fresh ideas, announcements, and inspiration for your team, delivered weekly.

Subscribe now