Regression: jQuery 1.3 only accepts upper case node names in HTML

[stephen.friedrich]

I develop a web app with JSF using JBoss RichFaces and its ajax-Framework Ajax4Jsf (a4j).

When trying to upgrade from jQuery 1.2.6 to 1.3 I noticed that after executing an a4j-Request, jQuery no longer worked correctly on that page: Selectors returned an empty list, where they shouldn't.

After researching and with some help from the irc chat I narrowed the problem: DOM elements that are replaced by a4j have lower case node names. jQuery 1.2.x did not care about upper/lower case difference in nodeNames.

However jQuery 1.3 converts the selector to upper case in HTML files, see for example line 1681 of jQuery 1.3.2:

if ( isTag && !isXML ) {

part = part.toUpperCase();

}

Yet, when trying to match against a DOM element's nodeName, a case sensitive match is done, so that elements with lower case nodeName do not match, see for example line 1689:

elem.nodeName === part

I'll try to come up with an example file, but I have to research how a4j does the dom replacement to mimick this use case.

[stephen.friedrich]

Oh, forgot to add: This happens only on Firefox. IE seems to work fine.

[stephen.friedrich]

Here's a test file to reproduce the behaviour

[vlopez]

I have the same problem. Please answer this ticked! I want to use the new version but I can't cause of this.

[vlopez]

Does anybody know a solution for this? I realy need use the new version of jQuery for better performance on my site. Thank you.

[laixer]

I just ran into this same issue today... Are there any plans to address this?

[laixer]

Okay, I did some investigating and as far as I can tell, the problem is that the isXML() function returns false for XHTML documents, when it should return true.

[lavoie.alexandre]

Same problem here, is there a workaround for the moment? Still moving a project to production and need the jQuery 1.3 with RichFaces!

[laixer]

doesn't seem like we're going to get a response from the jquery team for this one... i'm probably going to fix this myself within the next couple of weeks because I need it for a production application as well. I'll let you know if I find a fix...

[stephen.friedrich]

Please find attached a patch that _works for me_. I changed some comparisons to be case insensitive.

I attach both the patch file, so that you can quickly see my changes as well as the complete patched jQuery debug version file.

I _don't_ suggest that these are the changes that should be commited to jQuery's svn: I just can't fully determine what effects these changes have especially when using jQuery in XML context.

[stephen.friedrich]

Patch for jQuery 1.3.2 that fixes this problem

[stephen.friedrich]

Patched (debug) version of jQuery 1.3.2

[laixer]

Thank you Stephen, I'm trying out now. So far so good.

[vlopez]

Works fine to me! Thank you Stephen.

[laixer]

I haven't encountered any problems since I've used your patch. Thanks!

[manus]

I also ran into this bug recently and am so glad it is known and documented. Hopefully all this selector madness is fixed in Sizzle 1.0. Also, kudos to Stephen for the test & patch, though you're right in your guess that it's more complicated than is seems. I was playing around with your test file and came up with a small (nonexhaustive) suite of tests, which I'm attaching -- Stephen's patch only fixes a couple specific ones.

[manus]

A related interesting bug, and possibly another symptom of the root cause, is the 'element.className' selector behavior after DOM refresh (test case #7 in the file I attached). AFAICT, the result here is the only one that changes between FF 2 and 3.0. (Should I file this as a separate bug?)

It's also interesting that no version of jQuery passes all the tests. :/ Am I missing something?

[manus]

contains some tests for different selectors; hope this helps!

[manus]

I just updated the file so it can be tested on Opera as well, which also shows some irregularities.

[triplepoint]

There are several bugs related to this one, notably #4400, #3985 and #4895.

These additional bugs all deal with XHTML generated by client-side XSL. Firefox (and only firefox) uses the native case for the tag names in the generated XHTML, instead of the all-caps javascript standard for HTML. So jQuery selectors fail.

This is a similar situation to the ajax-inserted content described in this bug.

There's an additional failure example that we found in the contextMenu plugin:

$('#some_id').find('LI:not(.disabled) A')

will fail, while

$('#some_id').find('LI:not(.disabled)').find('A')

Does not.

I'm not sure if this additional case throws any light on the selector failures, hope it helps.

[manus]

Thanks for the investigation and for finding those related bugs!

I think there's a bunch of selector madness going on, not just in Firefox. Take a look at the attached ajax-test2.html in FF or Opera, and you'll see failures in both. There are also differences in results between FF 3.0.x and 3.5.

Also, the additional failure case you noticed can be seen in test cases 9-12 (11 & 12 use find()). Specifically, comparing before and after outputs from test case 11 shows that the case of the resulting tagnames in the derived selector are different. Weird!

Anyway, this ticket is apparently on John Resig's radar & to-do list:  http://groups.google.com/group/jquery-dev/browse_thread/thread/e39fd327abc66bdd (sorry to cross-post)

...so hopefully he'll get a chance to check it out more closely.

[manus]

Sorry, I meant:

"... comparing before and after outputs from test case 11 shows that the case of the resulting tagnames of the found elements are different."

[triplepoint]

Any progress on this bug from anyone? The selector breakage in Firefox is a Big Deal.

[towers]

Hi, I have test the patch with 'quicksearch' plugin and now it works fine.

But, the 'jCarousel' does not works with this patch in FF 3.0 :(

Is there a new solution? or other solution newer?

Greetings.

[towers]

I just have found the solution to this problem in 'jCarousel' plugin.

The line 111:

if (e.nodeName == 'UL'

e.nodeName == 'OL') {

must be changed to:

var FF = /Firefox/.test(navigator.userAgent);

if (( !FF && (e.nodeName == 'UL'

e.nodeName == 'OL') )

( FF && (jQuery.nodeName(e,'UL'))

(jQuery.nodeName(e,'OL')) )) {

Greetings.

[towers]

The paste has not work in the before post, the second if is:

if ( ( !FF && (e.nodeName == 'UL'

e.nodeName == 'OL') )

( FF && (jQuery.nodeName(e,'UL'))

(jQuery.nodeName(e,'OL')) ) ) {

(between e.nodeName == 'UL' and e.nodeName == 'OL' there is an OR operator, and between 'OL') ) and ( FF && there is other OR operator, and between (jQuery.nodeName(e,'UL')) and (jQuery.nodeName(e,'OL')) other OR).

[john]

Fixed.  http://github.com/jeresig/sizzle/commit/0e0177d990c72c00aa16ee8ca8bf96630d46726f