Skip to main content

Bug Tracker

Side navigation

#8609 closed bug (fixed)

Opened March 23, 2011 02:42PM UTC

Closed April 10, 2011 08:42PM UTC

Last modified March 09, 2012 05:16PM UTC

Result of .find(" ") is undefined

Reported by: per.lindberg@facilitylabs.com Owned by:
Priority: low Milestone: 1.6
Component: traversing Version: 1.5.1
Keywords: Cc: ajpiano, kswedberg
Blocked by: Blocking:
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>

Attachments (0)
Change History (12)

Changed March 23, 2011 06:12PM UTC by addyosmani comment:1

cc: → ajpiano, kswedberg
component: unfiledtraversing
priority: undecidedlow
status: newopen

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.

Changed March 23, 2011 07:52PM UTC by timmywil comment:2

_comment0: .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/2061300909991165604

.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

Here's some proof for find: http://jsfiddle.net/timmywil/YDbUu/

Changed March 23, 2011 07:54PM UTC by addyosmani comment:3

resolution: → worksforme
status: openclosed

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!

Changed March 24, 2011 09:14AM UTC by per.lindberg@facilitylabs.com comment:4

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.

Changed March 24, 2011 02:46PM UTC by dmethvin comment:5

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.

Changed March 24, 2011 04:07PM UTC by anonymous comment:6

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

Changed March 24, 2011 07:10PM UTC by timmywil comment:7

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.

Changed March 24, 2011 07:33PM UTC by dmethvin comment:8

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

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.

Changed March 24, 2011 08:59PM UTC by timmywil comment:9

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

Changed March 25, 2011 09:04AM UTC by per.lindberg@facilitylabs.com comment:10

Replying to [comment:8 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.

Changed April 10, 2011 08:41PM UTC by john comment:11

resolution: worksforme
status: closedreopened

Changed April 10, 2011 08:42PM UTC by john comment:12

milestone: 1.next1.6
resolution: → fixed
status: reopenedclosed

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