the very bug (as i see it) is the following:
there is a major inconsistent behaviour between the native browser selector implementation of at least firefox and the sizzle selector implementation regarding attribut value searching.
quoting the jquery documentation here:
http://api.jquery.com/category/selectors/
If you wish to use any of the meta-characters (#;&,.+*~':"!^$[]()=>|/ ) as a literal part of a name, you must escape the character with two backslashes: \\. For example, if you have an an input with name="names[]", you can use the selector $("input[name=names\\[\\]]").
i conclude that the jquery (sizzle) implementation is WRONG.
but whenever a find-call with a
document context occurs and finds the native (firefox) implementation of "document.querySelectorAll" (happens in jq 1.4.2 line 3530) the CORRECT behaviour is invoked.
referring to the question of "superficial": the "single" escaping technically results (and therefore is equal) to "no" escaping: the reason why jquery docs require you to double escape things is: just by defining a string with a single backslash results in an escaping of the very next char in the string declaration itself. but if you actually want ONE backslash being in the declared string, one has to escape the backslash itself, thats why one ends up with TWO backslashes.
the test-/show-case is the jquery homepage that holds a bunch of images using firefox and firebug. we use jQuery instead of $ just to make sure we dont run into firebugs (potential) own $-implementation.
open firebug and write to the console:
jQuery("img[src*=\\.gif]")
according to the documentation the "." has to be escaped, so we write this absolutely correct. we receive the jquery-logo image object here.
now write
jQuery("img[src*=\\.gif]", document.body)and we receive an empty set now, which is wrong. the first (working) expression causes jquery to utilize "document" as the default context and then switches to the firefox default implementation which correctly handles the escaping. the second (not working) expression causes jquery to utilize sizzle which will not handle the escaping (or the internal un-escaping in the end) correctly.
so to make it work with any non-native-selector implementation or with any non-document-context we must write
jQuery("img[src*=.gif]", document.body)as i see it the whole escaped-string-procession is not properly working in sizzle, when i trigger the sizzle implementation and put a breakpoint to jq 1.4.2 line 3274, thats where the ATTR-filter object is declared, i see that whatever i put into my original query, the one blackslash (which is there because of we declared it with a double backslash) is still there when the "check" variable is created and used:
img[src*=\\.gif]
img[src*=\\]gif] (that one never finds anything, but i just wanted to know how the string arrives deep in there)
but when i try the following:
img[src*=\\]\\[gif]
i wanted to search for images with "][" inside the src attribute, BUT at the breakpoint this actually arrives as
img[src*=\\]
so i think there should be an issue filed in jquery bug tracker or in sizzle, because the browser-native-implementation(s) seem to handle it the expected way, jquery itself does not.
in my eyes this is very bad because i cannot skip the escaping unless i know when does what impelemtation interpret it in what way. a browser upgrade my break my workaround (of not escaping things) or a jquery upgrade. thats why i say: this is urgent.
this is my very first activity whithin the project, so i try to find out tomorrow how to propery file a bug if its not there already, but if someone reads it knowing where to put this to help fast fixing, please do so :)
