Bug Tracker

Opened 7 years ago

Closed 6 years ago

#7128 closed bug (fixed)

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

Reported by: adipose Owned by: timmywil
Priority: blocker Milestone: 1.7
Component: selector Version: 1.4.3
Keywords: equal selector Cc:
Blocked by: Blocking: #9261

Description

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

Attachments (2)

test.php (882 bytes) - added by adipose 7 years ago.
test.html (917 bytes) - added by adipose 7 years ago.

Download all attachments as: .zip

Change History (34)

Changed 7 years ago by adipose

Attachment: test.php added

comment:1 Changed 7 years ago by adipose

Added file as html

Changed 7 years ago by adipose

Attachment: test.html added

comment:2 Changed 7 years ago by snover

Priority: highlow
Summary: Jquery selector broken on values set with javascript?value attribute selector is inconsistent between qSA and Sizzle due to use of DOM properties

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.

comment:3 Changed 7 years ago by 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?

comment:4 Changed 7 years ago by 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"; })

comment:5 Changed 7 years ago by 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?

comment:6 Changed 7 years ago by snover

Status: newopen

comment:7 Changed 7 years ago by addyosmani

#6826 is a duplicate of this ticket.

comment:8 Changed 7 years ago by snover

Blocking: 6954 added

comment:5 Changed 7 years ago by snover

#6948 is a duplicate of this ticket.

comment:6 Changed 7 years ago by snover

Blocking: 6954 removed

comment:6 Changed 7 years ago by snover

#6954 is a duplicate of this ticket.

comment:7 Changed 7 years ago by snover

#6939 is a duplicate of this ticket.

comment:8 Changed 7 years ago by snover

#5810 is a duplicate of this ticket.

comment:9 Changed 7 years ago by snover

#3399 is a duplicate of this ticket.

comment:10 Changed 7 years ago by snover

Milestone: 1.4.31.next
Priority: lowblocker
Version: 1.4.21.4.3

Many more duplicates are listed in #3399.

comment:11 Changed 7 years ago by snover

Summary: value attribute selector is inconsistent between qSA and Sizzle due to use of DOM propertiesattribute selector is inconsistent between qSA and Sizzle due to use of DOM properties

comment:12 Changed 7 years ago by snover

Milestone: 1.4.41.5

Retargeting for 1.5.

comment:13 Changed 7 years ago by addyosmani

#6470 is a duplicate of this ticket.

comment:14 Changed 7 years ago by snover

Blocking: 7485 added

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

comment:15 Changed 7 years ago by john

Milestone: 1.51.6

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

comment:16 Changed 6 years ago by timmywil

Blocking: 7485 removed

comment:17 Changed 6 years ago by timmywil

#5930 is a duplicate of this ticket.

comment:18 Changed 6 years ago by john

Milestone: 1.61.next

comment:19 Changed 6 years ago by timmywil

#8960 is a duplicate of this ticket.

comment:20 Changed 6 years ago by timmywil

#9062 is a duplicate of this ticket.

comment:21 Changed 6 years ago by timmywil

#8740 is a duplicate of this ticket.

comment:22 Changed 6 years ago by timmywil

Blocking: 9261 added

comment:23 Changed 6 years ago by timmywil

Milestone: 1.next1.7

comment:24 Changed 6 years ago by timmywil

#9623 is a duplicate of this ticket.

comment:25 Changed 6 years ago by john

Owner: set to timmywil
Status: openassigned

comment:26 Changed 6 years ago by timmywil

#9171 is a duplicate of this ticket.

comment:32 Changed 6 years ago by timmywil

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.