Side navigation
#6093 closed bug (fixed)
Opened February 13, 2010 07:17AM UTC
Closed January 17, 2011 10:45PM UTC
Last modified March 14, 2012 12:04AM UTC
Escaping broken for find selector
| Reported by: | Chealer | Owned by: | john |
|---|---|---|---|
| Priority: | blocker | Milestone: | 1.5 |
| Component: | selector | Version: | 1.4.3 |
| Keywords: | escape selector find metacharacters | Cc: | |
| Blocked by: | Blocking: |
Description
The selector used for .find() doesn't support escape characters like it should according to the documentation on http://api.jquery.com/category/selectors/ (note that this documentation is misleading; see http://dev.jquery.com/ticket/4944 ).
I was not able to get find to work with any selector using an escaped meta-character. This includes brackets, the single quote, "(" and others. The test case illustrates the issue with "(". I only tried with Attribute Equals Selector [name=value].
jQuery tries to support improperly escaped selectors. For example, .find('input[value="Hot F(uzz"]') works for "Hot F(uzz", even though the selector should be "Hot F\\(uzz)". Of course, this is unreliable and escaping should be used, but escaping doesn't seem to work at all, either with 1.3.2 or 1.4.1.
http://dev.jquery.com/ticket/5546 seems related to this. It's confusing, but seems to basically say that escaping a certain string doesn't work, just like not escaping it (as reported in http://dev.jquery.com/ticket/3778 which is probably invalid since it doesn't use escaping).
Attachments (1)
Change History (10)
Changed July 29, 2010 11:53AM UTC by comment:1
Changed October 21, 2010 12:36AM UTC by comment:2
| blocking: | → 6428, 6448 |
|---|---|
| milestone: | → 1.5 |
| priority: | → blocker |
| status: | new → open |
| version: | 1.4.1 → 1.4.3 |
Changed October 21, 2010 12:37AM UTC by comment:3
Changed October 21, 2010 12:43AM UTC by comment:4
| blocking: | 6448 → 6428, 6448 |
|---|
test case with explanation:
First and third test cases should fail everywhere. qSA throws a SYNTAX_ERR because they are not valid, which causes Sizzle to pick them up and try again, and it matches because it is parsing the strings incorrectly.
Second and forth test cases should pass everywhere. IE6-7 do not have qSA support they go to Sizzle, and since Sizzle is parsing the strings wrong they fail in IE6-7.
Changed November 19, 2010 10:10PM UTC by comment:6
| keywords: | escape selector find → escape selector find metacharacters |
|---|
Changed January 17, 2011 05:11PM UTC by comment:7
| owner: | → john |
|---|---|
| status: | open → assigned |
Changed January 17, 2011 10:45PM UTC by comment:9
| resolution: | → fixed |
|---|---|
| status: | assigned → closed |
Fixed a couple issues with escaping of attribute values in selectors. Fixes #6093.
Changeset: 0c1ffe3cb381430ec501385fcb29dca22a27d816
Changed January 25, 2011 11:57PM UTC by comment:10
#8058 is a duplicate of this ticket.
i just put up a ticket by mistake in the wrong sub tracker (ui).
http://dev.jqueryui.com/ticket/5874
i consider this bug as SEVER as it boils down to:
1) the jquery core selector escaping is NOT WORKING (sizzle)
2) the native selector escaping (document.querySelectorAll) DOES WORK
so the behaviour is completely ambiguous, you dont know whether to escape it or not because you never know for sure what implementation will process it (at least not in future). right now you can reconstruct the issue:
firefox 3.6.x:
http://jqery.com/
open firebug console:
jQuery("img[src*=\\\\.gif]") that will return the jquery logo image
then add a valid context that is not the document object (because document is the default context):
jQuery("img[src*=\\\\.gif]", document.body) will return NOTHING
reason:
the first line using the default context internally uses the native firefox selector function: this handles escaping correctly and according to the jquery documentation. the second line using any non-document context will run into sizzle selector implementation and that will not handle escaping as expected (or not at all?)
testing the jquery-sizzle with "img[src*=hallo\\\\]\\\\[ballo]" one can see that not only backslashes arrive as literals in the to-check-string but do not work for syntax definition either: the check string in the ATTR filter will not hold "hallo][ballo" and will not even hold "hallo\\]\\[ballo" but it will hold "hallo\\". that renders the whole escaping feature pretty useless.
but the really bad thing is, that is it ambiguous: you cannot predict what implementation will be used and therefore if you should escape it or not.