#4218 closed bug (fixed)

Opened February 23, 2009 09:47AM UTC

Closed December 08, 2009 06:31PM UTC

Last modified December 08, 2009 06:31PM UTC

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

Reported by:	stephen.friedrich	Owned by:	john
Priority:	major	Milestone:	1.4
Component:	selector	Version:	1.4a1
Keywords:		Cc:
Blocked by:		Blocking:

Description

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.

Attachments (4)

ajax-test.html (2.1 KB) - added by stephen.friedrich February 23, 2009 11:13AM UTC.

Here's a test file to reproduce the behaviour
ajax-test2.html (5.2 KB) - added by manus June 22, 2009 04:19PM UTC.

contains some tests for different selectors; hope this helps!
jQuery.patch (1.4 KB) - added by stephen.friedrich May 07, 2009 08:08AM UTC.

Patch for jQuery 1.3.2 that fixes this problem
jquery-1.3.2.js (117.8 KB) - added by stephen.friedrich May 07, 2009 08:10AM UTC.

Patched (debug) version of jQuery 1.3.2

Change History (24)

Changed February 23, 2009 10:09AM UTC by stephen.friedrich comment:1

Oh, forgot to add: This happens only on Firefox.

IE seems to work fine.

Changed March 05, 2009 02:06PM UTC by vlopez comment:2

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

Changed March 10, 2009 08:02PM UTC by vlopez comment:3

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

Thank you.

Changed May 01, 2009 03:19PM UTC by laixer comment:4

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

Changed May 01, 2009 04:20PM UTC by laixer comment:5

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.

Changed May 06, 2009 01:06PM UTC by lavoie.alexandre comment:6

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

Changed May 07, 2009 06:38AM UTC by laixer comment:7

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...

Changed May 07, 2009 08:07AM UTC by stephen.friedrich comment:8

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.

Changed May 07, 2009 01:54PM UTC by laixer comment:9

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

Changed May 11, 2009 01:22PM UTC by vlopez comment:10

Works fine to me! Thank you Stephen.

Changed May 12, 2009 03:13AM UTC by laixer comment:11

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

Changed June 19, 2009 05:12AM UTC by manus comment:12

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.

Changed June 19, 2009 06:43PM UTC by manus comment:13

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?

Changed June 22, 2009 06:30PM UTC by manus comment:14

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

Changed July 16, 2009 11:18PM UTC by triplepoint comment:15

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.

Changed July 17, 2009 02:43AM UTC by manus comment:16

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.

Changed July 17, 2009 02:50AM UTC by manus comment:17

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."

Changed August 06, 2009 08:07PM UTC by triplepoint comment:18

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

Changed September 24, 2009 07:50AM UTC by towers comment:19

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.

Changed September 24, 2009 09:30AM UTC by towers comment:20

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')) )) {