Solved: IE event – “this.parentNode.parentNode is null or not an object”

… it bloody-well is! This post was very nearly “Things that piss me off 5: Internet Explorer” (that one may yet come) but I thought a more descriptive title would help more people struggling with the same problem to find it.

Anyway: background.  I am writing a new feature for a Content Management System to allow users to upload files. With a simple bit of javascript I added a “+” button to allow them to add new rows to the form, allowing them to upload multiple files. It looks a bit like this:

Screenshot of Upload Images feature
Screenshot of Upload Images feature

Anyway, it would obviously be nice to allow the user to remove a row if they’ve added one or two too many. The obvious solution seems to be to add a “-”  button beside each. Easy, right?

Unfortunately Internet Explorer, as per usual, ballses everything up. Because each – button is created dynamically I have to add an EventListener using JavaScript code. No problem so far.

That event listener is a simple, one-line:

this.parentNode.parentNode.removeChild(this.parentNode);

As each row (the label, field itself (including button) and “-” link) is inside a div, the above code should remove that div and therefore remove the row. And it does… in Firefox. Try it in Internet Explorer and you get a message telling you “Error: ‘this.parentNode.parentNode’ is null or not an object”.

Whhhaaa?!

Don’t you just hate when you can easily find something your code claims it can’t? Am I the only one who screams “It’s right f**king there!!” at my monitor? In this case, the problem seems to boil down to IE’s supid, proprietary, fucked up way of attaching Event listeners. When you use Mozillas the W3C standard addEventListener method to attach a listener to an event, “this” in the event handler refers to the object which the event is called on. Obvious, yes?  However when you use IE’s attachEvent instead, IE doesn’t seem to act in the same way. Apparently, instead, IE sets “this” in an event handler to the window object instead of the calling/event object! Another good job from Micro$oft!

Apparently it’s can be overcome, but that involves a lot of code and I refuse in principle to do that much inelegant hacking for something so simple. It’s much easier (and principled) to do this:

IE error message: "Sorry, your browser doesn't support this function. This is probably because you're using Internet Explorer. www.getFirefox.com"
Not really a long-term solution, but bloody satisfying nonetheless.

Firefox 3 – Initial Impressions

I haven’t come across anything truly groundbreaking in Firefox 3, possibly because I’ve become accustomed to much of the feature set through the Betas and RCs, but there are one or two improvements that are quite useful (as well as a couple of regressions unfortunately).

Wee Niggles

First the bad. When you view Page Info from the context menu it doesn’t give a link to the CSS file in the Media tab any more. I was sure it was there in 2 and a quick google confirmed this. This really sucks – I can’t see why they’ve taken it out.

Secondly, when I was looking through the options to try and return the aforementioned CSS links, I discovered Firefox had decided it was going to automatically download any future updates when they were discovered (I promptly switched the option to “Ask me…”). Bad Firefox.

Magic Address Bar

The good is good though. It doesn’t seem like it at first, but to my mind the biggest improvement of all is the address bar. Sure they’ve added a “Most Visited” folder to your bookmarks toolbar which (shockingly, given the title) contains a list of the sites you visit most frequently, but the address bar has some great, if not immediately obvious, usability improvements.

Continue reading “Firefox 3 – Initial Impressions”