Bug Tracker

Modify

Ticket #7128 (closed bug: fixed)

Opened 4 years ago

Last modified 3 years ago

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:
Blocking: #9261 Blocked by:

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

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

Change History

Changed 4 years ago by adipose

comment:1 Changed 4 years ago by adipose

Added file as html

Changed 4 years ago by adipose

comment:2 Changed 4 years ago by snover

  • Priority changed from high to low
  • Summary changed from Jquery selector broken on values set with javascript? to 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 4 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 4 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 4 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 4 years ago by snover

  • Status changed from new to open

comment:7 Changed 4 years ago by addyosmani

#6826 is a duplicate of this ticket.

comment:8 Changed 4 years ago by snover

  • Blocking 6954 added

comment:5 Changed 4 years ago by snover

#6948 is a duplicate of this ticket.

comment:6 Changed 4 years ago by snover

  • Blocking 6954 removed

comment:6 Changed 4 years ago by snover

#6954 is a duplicate of this ticket.

comment:7 Changed 4 years ago by snover

#6939 is a duplicate of this ticket.

comment:8 Changed 4 years ago by snover

#5810 is a duplicate of this ticket.

comment:9 Changed 4 years ago by snover

#3399 is a duplicate of this ticket.

comment:10 Changed 4 years ago by snover

  • Priority changed from low to blocker
  • Version changed from 1.4.2 to 1.4.3
  • Milestone changed from 1.4.3 to 1.next

Many more duplicates are listed in #3399.

comment:11 Changed 4 years ago by snover

  • Summary changed from value attribute selector is inconsistent between qSA and Sizzle due to use of DOM properties to attribute selector is inconsistent between qSA and Sizzle due to use of DOM properties

comment:12 Changed 4 years ago by snover

  • Milestone changed from 1.4.4 to 1.5

Retargeting for 1.5.

comment:13 Changed 3 years ago by addyosmani

#6470 is a duplicate of this ticket.

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

  • Milestone changed from 1.5 to 1.6

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

comment:16 Changed 3 years ago by timmywil

  • Blocking 7485 removed

comment:17 Changed 3 years ago by timmywil

#5930 is a duplicate of this ticket.

comment:18 Changed 3 years ago by john

  • Milestone changed from 1.6 to 1.next

comment:19 Changed 3 years ago by timmywil

#8960 is a duplicate of this ticket.

comment:20 Changed 3 years ago by timmywil

#9062 is a duplicate of this ticket.

comment:21 Changed 3 years ago by timmywil

#8740 is a duplicate of this ticket.

comment:22 Changed 3 years ago by timmywil

  • Blocking 9261 added

comment:23 Changed 3 years ago by timmywil

  • Milestone changed from 1.next to 1.7

comment:24 Changed 3 years ago by timmywil

#9623 is a duplicate of this ticket.

comment:25 Changed 3 years ago by john

  • Owner set to timmywil
  • Status changed from open to assigned

comment:26 Changed 3 years ago by timmywil

#9171 is a duplicate of this ticket.

comment:32 Changed 3 years ago by timmywil

  • Status changed from assigned to closed
  • Resolution set to fixed

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

Please follow the  bug reporting guidlines and use  jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

View

Add a comment

Modify Ticket

Action
as closed
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.