I’ve got two recent IE-related items I wanted to let you know about:
- SuperPreview for Internet Explorer, and
- a technique to help track down difficult-to-debug ‘operation aborted’ messages.
If you’re developing for IE8 (and if not, why not?), you likely still need to keep those users on IE6 humming along. As a result, you’re spending a lot of time testing your site across browsers, and since you can’t install multiple IE versions on a single machine, that’s been a challenge to do efficiently. Well, until now….
You might have heard about the SuperPreview feature that was announced as part of Expression Web 3 – that’s the tool that gives you a side-by-side view of a site as it would be rendered by IE6, IE7 or IE8, and even (gasp!) Firefox. Below for instance, is the National Junior Classical League site’s home page (see my Maximus Geekus post for its significance) rendered in Firefox and IE 8 side-by-side.
You can select various visual elements on the page, and they will highlight in both frames, as well as on in the optional DOM view below. In the specific case above, you’ll notice small popup windows on each page; these are indicating a difference in the rendering of the specific element. Here it’s rather minor – a one pixel offset for the top left corner of the menu option.
SuperPreview actually has two incarnations:
- SuperPreview for Windows Internet Explorer is a FREE download that allows you to compare renderings in IE6 and IE7 or IE8. It doesn’t include the FireFox capability, but otherwise is essentially a subset of what the Expression Web SuperPreview feature (below) offers.
- Expression Web 3 SuperPreview is part of the overall Expression Web product, and includes options to compare renderings in FireFox as well as the IE versions that the free download supports. Expression Web 3 has a 60-day trial that you’re more than welcome to give a spin as well.
This one comes from the IE Team blog, and is essentially a mechanism you can use to help diagnose errors that manifest themselves with the less-then-helpful “Operation aborted” message boxes. It’s a problem that was much more prevalent pre-IE8, but still can rear its ugly head, even in deceptively simple looking script such as what generated the error below:
The root cause (explained here) has to do with the manipulation of the DOM that causes an element to be added or removed before its ancestor element is closed. For instance, in the example above, we’re trying to add a new DIV to the BODY, but if the parser hasn’t yet seen the </body> tag, that element isn’t closed and the error occurs.
As you can see, the blog post referenced above was nearly 18 months ago, and there was a bit of work in IE8 to eliminate the major source of these errors, but not all avenues that lead to the error were closed. Travis Leithead, a Program Manager for the IE team, tackles the issue anew in yesterday’s IE blog and gives you some script to help.
I thought I’d give it a shot with the trivial example above, and although it does what is advertised…
I ran into a couple of gotchas that I wanted to pass along:
- The diagnostic script (as noted in the blog post) requires IE8 standards mode, so make sure your page is rendered as such – perhaps by including an appropriate DOCTYPE if you don’t already have one.
You can tell what the mode is on the IE Developer Tools title bar to the right, where it lists “Document Mode:” If you’re not running in IE8 standards mode, you’ll get an “object not found” error on one of the lines of the diagnostic script – specifically
var nativeAC = Element.prototype.appendChild;
- I had to open the Developer Tools (F12) first, then navigate to the page, then start the debugger in order to catch the error.
- After capturing the error and stopping the debugger, I couldn’t reload the erroneous page in the same browser tab – it seemed to hang with a “Connecting…” message. That behavior is noted in the first comment to Travis’ blog post as well. Hopefully, the IE team will comment there to clarify the steps.