Bug Tracker

Opened 12 years ago

Closed 11 years ago

Last modified 8 years ago

#1991 closed bug (invalid)

case sensitivity in find() vs children()

Reported by: hubquery Owned by:
Priority: minor Milestone: 1.2.2
Component: core Version: 1.2.1
Keywords: Cc:
Blocked by: Blocking:

Description

I was using jQuery to parse XML (actually a text string returned from an XMLHttpRequest) and found some odd behaviour when dealing with elements that weren't all lowercase. Basically find() seems to only select lowercase elements, regardless of whether the selector string is lowercase or not, while children() selects elements with no case sensitivity.

Here's an example that should illustrate the problem:

var s = document.createElement("script");
s.setAttribute("type", "text/javascript");
s.addEventListener("load", doParse, true);
s.setAttribute("src", "http://code.jquery.com/jquery-latest.js");
document.getElementsByTagName("head")[0].appendChild(s);

function doParse(){
 var n = "<Test><Items><item/><Item/><Item/></Items></Test>";
 var $n = $(n);
 console.log($n.html());

 console.log($("item", $n)); // expected 1, found 1

 console.log($("Item", $n)); // expected 2, found 1

 console.log($n.find("Items").children("Item")); // expected 2, found 0

 console.log($n.children("Items").children("Item")); // expected 2, found 3
}

Attachments (2)

jquery_test.html (2.3 KB) - added by davidserduke 12 years ago.
test case
1991.diff (1.4 KB) - added by davidserduke 12 years ago.
possible patch

Download all attachments as: .zip

Change History (7)

comment:1 Changed 12 years ago by hubquery

As discussed in this thread, this issue breaks down as:

  • children() is case insensitive
  • find() is case sensitive
  • but selectors in find() are being lowercased, so there's no way to match elements with uppercase characters using find()

Ideally then, the selector string used for find() should remain in its original case.

There may be a flag needed for dealing with differences between HTML (case-insensitive - could convert the selector to upper- or lower-case as appropriate) and XML/XHTML (case-sensitive, should leave the selector as is).

Changed 12 years ago by davidserduke

Attachment: jquery_test.html added

test case

comment:2 Changed 12 years ago by davidserduke

I put together a test case with two buttons. One shows what the author has written up as the problem. The other shows what he needs to do instead. The second one also shows a "bug" (or lack of feature) in jQuery.

The author has an XML string as is using jQuery to create an XML version. Unfortunately, at this point, jQuery does not have this capability. So instead what jQuery is creating is non-standard html. That is the main reason for the odd results. This can be seen in the test case.

Instead of using jQuery's $(string) to create the xml one can be created using a function like parseToXML (which is shown in the test case). This will create a true xml doc and not just non-standard html. The second button shows how jQuery operates on this using similar calls to the authors original description. There is still some issues but not nearly as many.

In [4032] I have moved the case-sensitivity parse of the nodeName comparison to jQuery.nodeName(). So by removing the toUpperCase() calls in that function, jQuery will start being case sensitive on those compares. Of course that would mess up html where it is NOT suppose to be case sensitive. Perhaps a switch or something as the author suggests is the way to go.

Changed 12 years ago by davidserduke

Attachment: 1991.diff added

possible patch

comment:3 Changed 12 years ago by davidserduke

I attached a patch that appears to fix this problem of case sensitivity being different for html and xml. It tests to see if the element is part of an xml doc to decided which test is appropriate.

comment:4 Changed 12 years ago by davidserduke

There is too much of a speed hit doing it this way to warrent commiting this patch.

comment:5 Changed 11 years ago by dmethvin

Resolution: invalid
Status: newclosed

Since jQuery's $("html") function is only documented to parse html, I'll close this as invalid.

Note: See TracTickets for help on using tickets.