Deep Tracing of Internet Explorer

November 17th, 2009

After reading a recent post by Steve Souders concerning a free tool called dynaTrace Ajax, I was intrigued. It claimed to provide full tracing analysis of Internet Explorer 6-8 (including JavaScript, rendering, and network traffic). Giving it a try I was very impressed. I tested against a few web sites but got the most interesting results running against the JavaScript-heavy Gmail in Internet Explorer 8.

I typically don't write about most performance analysis tools because, frankly, most of them are quite bland and don't provide very interesting information or analysis. dynaTrace provides some information that I've never seen before - in any tool on any browser.

dynaTrace Ajax works by sticking low-level instrumentation into Internet Explorer when it launches, capturing any activity that occurs - and I mean virtually any activity that you can imagine. I noticed very little slow down when running the browser in tracing mode (although it's sometimes hard to tell, considering the browser). However all of the tracing is recorded and saved for later, making it easy to record sessions for later analysis.

Above is the result of a recorded session, logging in to Gmail, reading a mail, and logging back out again. All aspects of the session are saved: Network requests, JavaScript source, all DOM events, etc. I had a hard time finding information that wasn't saved by the tool.

This is the full timeline view of loading a single the Gmail inbox. All network traffic, JavaScript parsing and execution, browser events, and CPU load can be seen.

You can select a segment of the timeline and get a view that looks like the following:

In the above you can see a clearer picture of the exact interactions happening. A phenomenal amount of inline JavaScript execution followed by page layout calculation coinciding with loading of some data over the network. You can mouse over the individual blocks on the timeline to get more information (such as if the JavaScript execute was the result of a timer or what Ajax requests were firing to cause the network traffic). Additionally you can click the blocks to dive in and take a deeper view of the trace.

Digging in to the execution of an XMLHttpRequest on a page we get to see some of the full execution stack trace - and this is where the tools starts to become really interesting. The tool is capable of tracing across JavaScript, through the native XMLHttpRequest, through the network request, and back to the handler that fires when the request is done. This is phenomenal. This is the first tool that I've seen that's capable of tracing through native methods to give you a picture of what activity triggers which actions and the complete ramifications of what happens (in both CPU usage and execution time).

Note that in the stack trace view you can click any piece of code and see its location anywhere inside the source code (and this even works after you've already closed the browser and have moved on - all source code is saved for later analysis).

While it's interesting to trace through code to look for problems the bigger question is usually: Where are slowdowns occurring? This is where the HotPath view comes into play:

This looks like a typical execution count view - like the one that you might see in Internet Explorer's built in tool or in Firebug - except for one important point: This view includes JavaScript parsing and layout rendering times. This is huge! No other tool provides information on how long it takes to parse all the JavaScript code on your site or how long it takes to do all the rendering. Clicking those entries allows you to see a breakdown of every time JavaScript was parsed or a layout was rendered - from which you can trace back to get even more information about what caused those actions. I don't want to seem too excited but I really am, this is just an incredible amount of information - and it gets even better:

Not only can you see the execution count for your defined JavaScript methods but you can also see execution time for the built-in DOM methods! Wondering what native method calls are slowing down your application? Wonder no more. From the HotSpot view you can filter by DOM or regular JavaScript and see exactly where execution time is going and what methods are so slow.

dynaTrace provides an additional view, called PurePath that attempts to figure out problematic scripts:

Just another way to try and get a full picture as to where your application is slowing down and what may be causing the problem.

In all I'm hugely impressed with this (free!) tool and am already using it to do more testing and performance analysis on my code. I don't think any browser has ever had a tool capable of this type of analysis, let alone Internet Explorer 6 and 7, which are still a very real part of any developer's workflow.

I chatted with some of the dynaTrace guys and asked them to add in memory profiling and to support more browsers. If they can provide this quality of instrumentation for CPU and execution time I hope they can do the same for memory usage, the next un-tapped realm of JavaScript performance analysis.

Tags: analysis, performance, tracing, ie, tools

50 Comments on 'Deep Tracing of Internet Explorer'

The Browser Operating System

February 22nd, 2009

A very interesting paper was just published by Microsoft Research that details a browser construction that acts more like an operating system, partitioning off resources only to those who need it.

Although our architecture may seem to be a straightforward application of multi-principal OS construction to the browser setting, it exposes intricate problems that didn’t surface in previous work, including dealing with legacy protection for cross-origin script source, display protection, and resource allocations in the face of cross-principal web service composition common on today’s web. We detail our solutions to the first two problems and leave resource allocation as future work.

In our browser design, we take the general stance that security (maintaining the multi-principal OS principles by having Browser Kernel exclusively manage the resource protection and sharing) comes before backward compatibility. We will not trade significant security risks for compatibility. Nevertheless, we will also not settle on a design that breaks many parts of the web to secure just a few sites. We present design rationales for such decisions throughout our design.

We have built an IE-based prototype that realizes Gazelle’s multi-principal OS architecture and at the same time utilizes all the backward-compatible parsing, DOM management, and JavaScript interpretation that already exist in IE. Our prototype experience indicates that it is feasible to turn an existing browser into a multi-principal OS while leveraging its existing capabilities.

With our prototype, we successfully browsed 19 out of the 20 Alexa-reported, most popular sites that we tested. The performance of the prototype is acceptable, and a significant portion of the overhead comes from IE instrumentation, which can be eliminated in a production implementation.

I wouldn't get too excited about being able to see an implementation soon - this was done by Microsoft Research (it doesn't appear as if anyone from the IE team was directly involved - this was mostly an academic pursuit). Regardless, it makes for a very-interesting read with regards to much of the technology that inhabits a web browser (DOM, CSS, etc.) and the security concerns that surround them.

Tags: microsoft, ie, browsers

21 Comments on 'The Browser Operating System'

DOM insertAdjacentHTML

November 24th, 2008

While looking for improvements to injecting HTML fragments into a document (which I mentioned, in passing, when I looked at using Document Fragments) I decided to spend some more time with Internet Explorer's insertAdjacentHTML method.

This method has been in Internet Explorer since version 4.0 - as well as is in the current release of Opera - and allows you to inject fragments of well-formed HTML into a variety of locations in a document.

The locations work as such (I list the equivalent terminology):

The method is only available on DOM elements (which makes sense) and is easy to use:

At first glance the method appeared to work well and seemed to be relatively fast. Two questions remained, though: How fast is it in comparison to using the Document Fragment technique I outlined before and does it work for all the strange use-cases that exist?

• I created a test case to compare the three types of injection: The type we've been using in jQuery prior to the upcoming 1.3 release, the new Document Fragment technique we'll be using in jQuery 1.3, and a case using insertAdjacentHTML (where applicable). While both the Document Fragment and insertAdjacentHTML cases were significantly faster than the old techniques used in jQuery the Document Fragment technique ended up being marginally faster in IE 6 (50ms vs. 80ms for insertAdjacentHTML).
• There's a huge problem with insertAdjacentHTML: It doesn't work on all HTML elements in IE 6 (specifically it doesn't work on table, tbody, thead, or tr elements). Having gaps in the functionality is very undesirable (attempting to use insertAdjacentHTML on those elements causes an exception to pop up in IE 6).
• It doesn't work on XML documents. Of course neither does innerHTML (at least not until browsers start to implement HTML 5 more completely). We're stuck doing the traditional techniques used in libraries like jQuery.

So why spend all this time talking about a method that is relatively half-baked in the main browser that implements it? Because it's going to be part of the HTML 5 specification. This means that we're going to see a larger number of browsers start to implement this method (and hopefully it'll encourage existing vendors to implement it more completely and efficiently).

Having browsers implement this method will dramatically reduce the amount of code needed to write a respectable JavaScript library. I'm looking forward to the day in which this method is more-widely available (along with querySelectorAll) so that we can really buckle down and do some serious code simplification.

Tags: dom, w3c, html5, ie

14 Comments on 'DOM insertAdjacentHTML'

Deadly Expandos

November 10th, 2008

If I had to rate my least favorite browser bugs I'd have to put this one near the top. A holdover from the old DOM0 days it's a practice where elements with a given name or ID are added as an expando property to another DOM node.

Here are my two favorite examples of this bug in action:

The first is a simple form that does a search on a site. Additionally a link is provided that, when clicked, fills in a search value and submits the form.

Before running the example you can spot the problem with a quick run to the address bar:

The .submit() method (which is available on all Form elements) is overwritten by the input element of the same name. This ends up being a very common problem - with frameworks using id="submit" as a default in their code.

Worst of all this fails in all browsers (preventing you from accessing the overwritten method).

The second example is even more devious. In this case we're going to loop over all the DOM elements in the page and alert out their contents.

This will work in most browsers - but not Internet Explorer. To understand why we return to the address bar.

Oops. All browsers turn elements with specific IDs into expandos of the returned NodeSet. But Internet Explorer goes a step farther and decides to overwrite the built-in .length property as well, breaking current forms of iterating over the DOM elements.

At least within jQuery you'll see a number of cases where, instead of doing the normal array traversal, we do the following in order to work around the issue:

It's a little more obtuse but at least it's guaranteed to work against cases of broken NodeSet iteration.

Garrett Smith has a highly technical write-up on the variety of issues that stem from this form of expansion. In short: No browser is immune from these problems. It's unfortunate that this whole system couldn't just be done away with (to avoid these types of issues in the first place) but legacy pages will likely necessitate their inclusion for many, many, years to come.

Tags: dom, browsers, ie

15 Comments on 'Deadly Expandos'

JavaScript in Internet Explorer 8

March 6th, 2008

Our day has finally come. CSS coders got some love with Internet Explorer 7 - us JavaScript folk got absolutely nothing. In fact, at last count, all we got were a couple new bugs to deal with (file:// requests not working via XMLHttpRequest and <object>.getElementsByTagName("*") always returning no elements).

Internet Explorer 8 is our release.

The first beta was pushed out today and it shows huge promise. It's already achieved way more than I would've expected and it's made me hungry for more. If you had bet me that Microsoft would be mentioning the phrases "ARIA", "SVG", and "MathML" in their release notes I would've lost.

Here are my thoughts on a bunch of the browser features:

W3C: querySelector

A super-fast way of finding elements based upon a CSS selector. The second browser to implement the selectors API has hit the market (behind a WebKit nightly release).

It's important to realize that any selectors here are completely reliant upon the browser's native selector implementation. IE8 is only shooting for CSS 2.1 support - which means that you really shouldn't be holding your breath for CSS 3 selectors. As I mentioned previously these blackbox APIs are going to be a source of never-ending hair-pulling and struggle going into the future.

HTML 5 Party!

I was hoping for some HTML 5-compliant features to land - well, hoping isn't the right term, perhaps 'feverishly expecting the worst' is more correct. However we can see that we've been graced with 4 full feature implementations from the spec - fantastic!

HTML 5: window.location.hash

Already supported fairly well by most browsers. Modifying window.location.hash changes the page URL and adds the page to the history (allowing for back-button simulation in Ajax applications). IE went a step further and broadcasts the hashchanged event (the first browser to do so, as far as I know).

HTML 5: DOM Storage

A feature that I discussed previously in which data can be persisted in a way that supersedes the use of primitive cookies storage. This has been in Firefox since version 2 but is absent from Opera and Safari.

HTML 5: postMessage

As I discussed previously postMessage serves as a way of communication across frames with simple text strings. IE 8, Opera 9, Firefox 3, and WebKit nightlies all support this feature - making it the only one with complete browser support.

HTML 5: Offline Events

As I've written about previously this is an easy way of detecting connectivity within the confines of JavaScript. With it we can write graceful offline Ajax applications. Firefox 3 and IE 8 appear to be the only browsers to support this feature.

XDomainRequest

This is an interesting feature for doing cross-domain requests but doesn't appear to conform to the existing Cross-site XMLHttpRequest work which is in Firefox 3. Even at that it appears to be quite crude - forfeiting any form of filtering or security controls for a simple boolean "yes/no" header.

Seeing this new API concerns me. The Cross-site XMLHttpRequest work may be in some flux, as some API points are still being hammered down, but it's doubtful that the resolution will end with something identical to what's being described by Microsoft.

DOM bug fix love

getAttribute/setAttribute have seen a major overhaul - in short: They now behave like they should and as they do in every other browser. The notorious issue of accessing relative/absolute href/src attributes is also resolved - which is just great. They also saw fit to add hasAttribute.

Also newly fixed/added:

• .ownerElement and .ownerDocument - Finally we have a unified way of dealing with iFrames.
• getElementById returns elements by id - ONLY. Been such a long time coming, thank goodness.
• Doing getAttribute("checked") now returns "checked" instead of true.
• <button/> values are actually submitted now, instead of their inner text values.
• Dynamically created (or modified) radio buttons are now checkable.

I simultaneously feel both joy and anger in seeing these fixed. Happy that they're being released and anger for the fact that I had to struggle through them and that they now consume some portion of my brain.

W3C: Events

This is one area that is completely absent from this beta. We are still stuck with IE's attachEvent system - no addEventListener in sight. I don't know how serious they are about supporting Acid3 but it includes a test for addEventListener so they may want to consider it extra strongly.

I can partially understand their desire to keep their existing API but I don't understand why they have no interest in, also, adding addEventListener, etc. to complement what's there. I assume it's because they would now have to support concepts like event capturing.

I'm really disappointed with this. This should've been a top priority fix before implementing new psuedo-XHR systems like XDomainRequest.

JavaScript Language

The IE team has made some big improvements in improving garbage collection issues, memory management, and performance - all of which will be greatly appreciated in everyday applications.

Although, I mis-spoke slightly earlier: While IE8 is been great for JavaScript developers I was implying "JavaScript + DOM" developers. For pure JavaScript it's completely frustrating: There doesn't appear to be any new pure-JavaScript features in this release. I can only hope that we'll see more in a future beta release.

ARIA Support

This one completely blew me away. ARIA is a fantastic specification for empowering web applications with the ability to clearly communicate their intentions to a screen reader. The biggest hurdle with the effort, up until this point, has been the lack of IE support - obviously this will no longer be the case. Firefox, IE, and Opera all support ARIA now. The WebKit team doesn't appear to have interest in implementing this feature, which is a real shame.

Embedded SVG

Support for embedding namespaced elements within XHTML is now possible. This means that you can now do inline markup for SVG and MathML, amongst others, and have it "just work" (as long as you have their associated plugins installed). It's probably a bit much hoping for native SVG support, but I'll take what I can get.

Firebug for Internet Explorer

We finally have a heavily-Firebug-inspired tool inside Internet Explorer. To quote Joe Hewitt (creator of Firebug): "I couldn't be happier that Microsoft completely copied Firebug for IE8." I have to agree - a tool like this has been a long time coming and it's greatly appreciated. Only the Internet Explorer team would've ever been the ones to build this tool - there's simply too much information here that's unavailable to typical IE extensions.

Browser mode toggling

At first glance this feature makes the most sense for seeing if your IE 7 page will work ok in IE 8. In actuality, however, this will end up being very useful for developing a standards-compliant page (in IE 8, FF, Safari, Opera) and then toggling to see what the result is like in IE 7. This is so much better than the IE 6 to IE 7 jump where you have to keep your browser in a virtual machine in order for it to run side-by-side (according to Microsoft, at least - even though there were standalone solutions).

Bug Feedback

The Internet Explorer team is collecting feedback from select beta testers and publishing the bugs on a publicly-accessible site. This a huge step in the right direction (going from no communication to some is great). "Common" users are forced to vote for their "favorite" bugs to try and catch the eye of an IE developer. It's a strange situation but one that shows progress, at least.

Conclusion

In all I'm positive about this release, even with all the ups-and-downs. Seeing features like querySelector, ARIA, and postMessage helps to warm my frosty, bitter, heart. While there's still some major faux-paus in this release (no new JS langauge features?, no W3C events?, no CSS3 selectors?) I think we can, at least, be excited to see what happens in the next beta.

If nothing else the Internet Explorer team has done a great job of tackling many of the expectations of the development community - if they continue this trend I don't think anyone will be left disappointed.

Tags: ie, browsers, html5, dom, javascript

56 Comments on 'JavaScript in Internet Explorer 8'

Unbreaking the Web

March 4th, 2008

I'm really excited about Microsoft's switch today to make standards mode rendering the default rendering style, going forward - even at the cost of "breaking the web." I think this is going to have serious positive ramifications for the whole web ecosystem, which is just fantastic. I can't imagine this decision coming lightly and I greatly respect them for making it, even turning about after plenty of criticism.

There's one little jewel tucked away in Microsoft's press release, that helps to shed some light on why this massive change of heart may have come about:

“While we do not believe there are currently any legal requirements that would dictate which rendering mode must be chosen as the default for a given browser, this step clearly removes this question as a potential legal and regulatory issue,” said Brad Smith, Microsoft senior vice president and general counsel.

Ah ha! It all becomes clear, now:

The straw that broke the camel's back? Even if that's not the case, whatever the final reasoning was, I'm just glad that this conclusion has been come to. The web will soon be a much better place for everyone.

Tags: ie, microsoft, browsers

19 Comments on 'Unbreaking the Web'

HTML5 Shiv

January 24th, 2008

Assuming that it'll be a while before most browsers attempt to implement most of HTML 5 (a perfectly reasonable assumption) we need to start thinking of ways to tackle the creation and rendering of HTML 5 components in the meantime. Obviously, using the tools of JavaScript and CSS we can accomplish a lot.

However, there is one notch in our weapon: Internet Explorer doesn't know how to render CSS on elements that it doesn't recognize. For example, the following "blah" element (a fictional element) doesn't have any styling:

Result:

Thankfully, Sjoerd Visscher mentioned an interesting technique that could be used to force IE to use the specified CSS styling. Specifically, once you create a new DOM element (of the same name as the one in the document) all styling is applied. You don't even have to inject the element in order for this to occur. Observe the following:

Result:

This is very important. This now means that we can provide CSS styling for undefined HTML 5 element and allow Internet Explorer to handle it gracefully.

<figure/> element

Let's take a look at a simple example. Pretending that we wanted to set about implementing the HTML 5 figure element. The element is quite simple, only requiring some basic CSS markup (I'm not completely sure how a figure is supposed to look so I took some liberties here).

Result:

Using some basic CSS, and a single JavaScript DOM statement, we've now implemented at least part of the HTML 5 spec. While it won't solve everything, it is a promising technique, at the very least.

I did have some issues when I was testing this technique, especially with the styling of elements that are already defined elsewhere in the structure. For example, let's say you wanted to implement the legend child element of a caption. This ends up being really hard since the functionality and styling of legends are already defined for fieldsets by Internet Explorer. In my simple tests they became unstylable outside the context of a fieldset.

This is definitely a decent start, building our HTML 5 shiv, but it needs some more work and much more exploration. I hope to see this continued in the upcoming months as interest in, and availability of, HTML 5 begins to heat up.

Tags: css, javascript, ie, html5

21 Comments on 'HTML5 Shiv'