Bug Tracker

Modify

Ticket #8609 (closed bug: fixed)

Opened 3 years ago

Last modified 2 years ago

Result of .find(" ") is undefined

Reported by: per.lindberg@… Owned by:
Priority: low Milestone: 1.6
Component: traversing Version: 1.5.1
Keywords: Cc: ajpiano, kswedberg
Blocking: Blocked by:

Description

The result of a call to .find() with an empty parameter (undefined, empty string or only whitespace) is undefined. This fact should absolutely be added to the official documentation!

Even worse: the result varies with the browser! In jQuery 1.5.1 I get different results in Firefox 3.6.15 and most other browsers (e.g. Chrome 10.0.648.134). (not so in jQuery 1.4.2). See the code below.

Perhaps should jQuery be fixed so that an empty parameter (including a string with only whitespace) ALWAYS gives the whole set. In any case, the behaviour should be added to the official API documentation.

<!DOCTYPE html PUBLIC

"-W3CDTD XHTML 1.0 StrictEN" " http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html> <head>

<meta http-equiv="content-type" content="text/html;charset=UTF-8" /> <title>The mad programmer strikes again!</title> <script type="text/javascript" src="../tools/jquery/jquery-1.5.1.min.js"></script>

<script type="text/javascript">

Illustrate bug in .find(" ") - different result in FF and e.g. Chrome jQuery(function() {

var myFilter = " "; var table = $("#my-table"); table.find('tr:gt(0)').each(function() {

var cells = $(this).find('td'); var filteredCells = cells.filter(myFilter); alert("Cells: " + cells.size() + " " + filteredCells.size());

});

});

</script>

</head>

<body>

<table id="my-table" style="display: block;">

<tr><th>Class</th><th>Count</th></tr> <tr><th>Luxury</th><td>7</td></tr> <tr><th>Premium</th><td>30</td></tr> <tr><th>Normal</th><td>35</td></tr> <tr><th>Economy</th><td>20</td></tr> <tr><th>Budget</th><td>12</td></tr>

</table>

</body> </html>

Change History

comment:1 Changed 3 years ago by addyosmani

  • Cc ajpiano, kswedberg added
  • Priority changed from undecided to low
  • Status changed from new to open
  • Component changed from unfiled to traversing

We've discussed your ticket and we feel it might be of benefit to not return undefined here. Rather if it were to return a jQuery object with nothing that would probably make more sense. In terms of the other areas this applies to, we may also need to update .find(), .filter() and .not() as well.

Marking your ticket as valid from that perspective for further discussion/comments before we decide to actually change behavior.

comment:2 Changed 3 years ago by timmywil

.find returns an empty selection for any invalid argument. The small change to filter and not is included in this pull request:

 https://github.com/jquery/jquery/pull/206

Version 0, edited 3 years ago by timmywil (next)

comment:3 Changed 3 years ago by addyosmani

  • Status changed from open to closed
  • Resolution set to worksforme

Confirmed with timmywil that .find() currently already returns an empty selection and does so for .find()[an empty string] or .find(' ')[nothing but whitespace in a string].

With respect to the changes for .filter() and .not() these are currently in a pull request that has been linked back to this ticket just for reference.

We'll be closing this ticket now given that there is nothing more to be done here. Thanks!

comment:4 Changed 3 years ago by per.lindberg@…

I'm terribly sorry, I made a big error in my ticket title and text. My problem is NOT primarily with .find() but with .filter(). Calling foo.filter(' ') - that is, with a space as parameter - gives DIFFERENT results on FF and e.g. Chrome. Please run my example, and you'll see!

(I guess that it's also interesting to think about related functions such as .find() in this context, of course. And in any case, the behaviour of all these functions should be standardized and documented.)

What should filters such as null, "" and " " return? Perhaps that should be regarded as "no filter", and therefore return all elements?

So please consider re-opening this ticket. The problem is actually with .filter() which IS behaving weird in 1.5.1.

comment:5 Changed 3 years ago by dmethvin

What should filters such as null, "" and " " return?

This seems like a garbage-in, garbage-out situation to me. I don't think we want to firmly specify the behavior of all invalid inputs and then be bound to make bad input work that way forevermore. There is a definite cost to making jQuery check all inputs.

comment:6 Changed 3 years ago by anonymous

I don't think we want to firmly specify the behavior of all invalid inputs [...]

The official documentation should - at least - provide a strict definition what is valid input, and what is NOT valid input. And that the result of invalid input (however that turns out to be defined) is undefined.

Otherwise, users will start to guess and presume. That will result in brittle code and ultimately badwill for jQuery.

I had to spend a whole week to find a bug in a package written by someone who - it turned out - had presumed things about .filter().

comment:7 Changed 3 years ago by timmywil

Dave, actually we already do for pretty much every jquery function and its even shorter than checking for null because it's just <pre>!arg</pre>. Its already been fixed in the pull request and it was just a matter of adding one word. I'm surprised we weren't already doing this for filter and not, because we really do have it for just about every other function. And like I said, it's super easy. Not all inputs tho. Just the falsey ones when they make no sense to jquery.

comment:8 follow-up: ↓ 10 Changed 3 years ago by dmethvin

A .filter(" ") (a single space) won't meet the !arg test. Were we trying to fix that?

I disagree on specifying what is NOT valid input. Other than bad selectors being invalid input.

Last edited 3 years ago by dmethvin (previous) (diff)

comment:9 Changed 3 years ago by timmywil

No I agree we don't need to worry about that one. Sizzle handles that for us anyway.

comment:10 in reply to: ↑ 8 Changed 3 years ago by per.lindberg@…

Replying to dmethvin:

I disagree on specifying what is NOT valid input. Other than bad selectors being invalid input.

You have a point here; a a complete list of all possible invalid inputs can be made very long indeed.

As log as there's a strict definition of what IS valid input, then logically everything else is NOT. And -important!- a note that the result for invalid input is UNDEFINED.

comment:11 Changed 3 years ago by john

  • Status changed from closed to reopened
  • Resolution worksforme deleted

comment:12 Changed 3 years ago by john

  • Status changed from reopened to closed
  • Resolution set to fixed
  • Milestone changed from 1.next to 1.6

Actually this was landed and fixed - and will be in 1.6.

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.