Skip to content

jQuery.find problem with IE7 (and a solution)

11 April 2012

There was a problem that recently sprang up in IE7 using jQuery find function. This seems to be an IE7 problem rather than jQuery’s one but until IE7 is used, developers are concerned. I hope this will help somebody.

So, to shorten the story I’ll bypass details replacing them with a setup description. You may also jump directly to solution

The Set Up

We have:

  • a web page having
  • a template table (pure html) with one only row having number of input fields – text and hidden
  • a XML, filled with some data and
  • some javascript (and jQuery of course)

Step One – filling the XML with desired data

Just in case we check to be sure that the template table exists:

Because IE is base browser used, XML is an  ActiveXObject filled from an URL (rows 393-395 in the snippet below ). Next we have to display received data into a table. For the purpose we create a new one from the template (row 396) and assign an unique id (row 397). Finally we fill the new table with XML data (row 398).

Here is the function filling the table. Two parameters are passed – the new table and the XML object (data)

To bypass some details let’s assume that data is OK and some nodes are found.

In the loop, for each XML node, a new table row is created  multiplying first row. (there was one only row in template, remember?). Each row has few children – input elements and among them there is one with id=”tdKupCount”. Below is shown that the cloned row has (and jQuery finds) this input.

At the end, when all nodes has been traversed, the first (template) row is removed because  it is not needed anymore.

All this happens on document load.  Here the set up is completed – table is created and filled with data and function returns.

The problem

At this point jQuery .find() cannot find anymore the input, but . . .

. . . the same row returns the input when accessed via document.getElementById

Let’s assign the element to a variable, so as to inspect it deeper, for it is related to the way .find() works.

Below is shown that _e is Element Node and getAttributeNode returns an Attribute Element, which has a value equal to searched id.

Some of input type=”text” react to the onchange event. Element caused the event is passed as parameter to a function. There, using it we get the parent row (row 156) as a jQuery object. Having the (current) row on hand we try to find desired (different than srcElement) input (row 158 in the listing below)

Testing the result we see the same as above – jQuery find() failed while getElementById succeeded.

The questions is Why

To answer it we dug into jQuery and step by step we found the problem in Sizzle.filter listed below.

Here current element (which in this iteration is the sought one) is passed together with sought id string. Exploring both variables in the function – node and elem – we spot the problem, shown below.

NodeValue is undefied while elem.id is correct. If it have to be taken as an attribute only getAttribute method returns value while getAttributeNode.nodeValue does not.

It doesn’t matter why and when this happens. Tests shown that this is not the case each time but surprise is unwelcome. We need find() to work with IE7 even if some of the methods cannot cope successfully with elements. So …

The Solution

From this view point the solution was easy: get id’s value either using node.nodeValue OR elem.getAttribute method as shown below.

This way instead of false we get what we need with least changes.

Advertisements

From → jQuery

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: