attribute selector is inconsistent between qSA and Sizzle due to use of DOM properties

[adipose]

If I set an input value with javascript, the jquery selector does not select it unless I use an incorrectly formatted selector.

This occurs in Chrome 7.0.517.24, Firefox 3.6.10, Firefox 4.0b6, Opera 10.62 and Safari 4.0 (Win32).

IE8, however, does work properly.

Correct selector: $("[value=a]") does not work. Incorrect selector: $("&[value=a]") does work. $("@[value=a]") does work. etc.

See the attached example. It works at first, but after the javascript changes the value, it gets wrong results (except in IE8).

[adipose]

Added file as html

[snover]

The value attribute in HTML actually corresponds to the defaultValue DOM property.

Presumably, the reason the “incorrect” selectors work is because the browser’s native querySelectorAll function fails (due to their invalidity) and jQuery falls back to using Sizzle’s slow path.

The real bug here sounds like the fact that Sizzle inspects DOM 2 HTML properties instead only using getAttribute, and perhaps also that IE8 is doing something else it shouldn’t be.

[adipose]

"The value attribute in HTML actually corresponds to the defaultValue DOM property."

Is this to say, a jquery selector that inspects value will only ever look at the defaultValue DOM property?

When using .filter(), one can select based on value and not just defaultValue. Is this also a bug?

What is the proper way to select by value if value has been changed?

[snover]

The jQuery attribute selector [value="foo"] should always inspect the HTML attribute value (which corresponds to the DOM property defaultValue), not the DOM property value which corresponds to the user- or script-modified state of the control.

To select by the current value, you would do something like:

$('input:text').filter(function () { return this.value === "foo"; })

[adipose]

Thank you, I did not realize this, before.

However, I would like to point out that

$('input').filter("[value=foo]")

Works. Is this supposed to work, or will it break once the other bug is corrected?

[addyosmani]

#6826 is a duplicate of this ticket.

[snover]

#6948 is a duplicate of this ticket.

[snover]

#6954 is a duplicate of this ticket.

[snover]

#6939 is a duplicate of this ticket.

[snover]

#5810 is a duplicate of this ticket.

[snover]

#3399 is a duplicate of this ticket.

[snover]

Many more duplicates are listed in #3399.

[snover]

Retargeting for 1.5.

[addyosmani]

#6470 is a duplicate of this ticket.

[snover]

(In #7485) This is something on the roadmap for 1.5. .attr will be rewritten along with Sizzle to stop matching on the DOM properties, so this will all be happily consistent again.

[john]

This is getting bumped to 1.6 when the $.attr rewrite happens.

[Timmy Willison]

#5930 is a duplicate of this ticket.

[Timmy Willison]

#8960 is a duplicate of this ticket.

[Timmy Willison]

#9062 is a duplicate of this ticket.

[Timmy Willison]

#8740 is a duplicate of this ticket.

[Timmy Willison]

#9623 is a duplicate of this ticket.

[Timmy Willison]

#9171 is a duplicate of this ticket.

[Timmy Willison]

Override Sizzle attribute retrieval with jQuery.attr. Fixes #5637, #7128, #9261, #9570, #10178.

Bug fixed on the side: $(window).is('a') was throwing an exception. Fixes #10178.

Changeset: 92405d4f5ffe9ec1f26f280303783014948438c5