Skip to main content

Bug Tracker

Side navigation

#9427 closed bug (fixed)

Opened May 26, 2011 02:27AM UTC

Closed December 13, 2011 02:59PM UTC

Last modified April 11, 2012 06:49PM UTC

Passing undefined to .text() does not trigger setter

Reported by: Xavi Owned by:
Priority: low Milestone: 1.7.2
Component: manipulation Version: 1.6.1
Keywords: Cc:
Blocked by: Blocking:

Passing undefined to $.fn.text() triggers getter functionality instead of the setter functionality. For example the following code throws an exception:

var text;
Attachments (0)
Change History (16)

Changed May 26, 2011 02:31AM UTC by rwaldron comment:1

component: unfiledmanipulation
priority: undecidedlow
resolution: → invalid
status: newclosed

This is expected behaviour.

Changed May 26, 2011 02:49AM UTC by Xavi comment:2

Changed May 26, 2011 02:50AM UTC by Xavi comment:3

Why is it expected behavior? It breaks chaining and causes unexpected exceptions.

Changed May 26, 2011 03:16AM UTC by rwaldron comment:4

It's expected that the developer knows to test their own variables before passing them to methods that have overloaded signatures.

var text;
$("<div/>").text( text || "" ).append($("<span/>"))

The code above will work fine without breaking the existing api.

Changed May 26, 2011 03:31AM UTC by rwaldron comment:5

As noted on the pull request: The documentation specifies the valid input to the method and their expected outcome.

Changed May 26, 2011 05:54AM UTC by Xavi comment:6

FWIW, I would recommend using this work around instead:

var text;
$("<div/>").text( text + "" ).append($("<span/>"));

It handles 0 and null better and saves 1 byte.

Also, FWIW, this bug also affects $.fn.html, $.fn.attr, $.fn.width, $.fn.height, and number other functions.

I replied to, but it might be worth repeating my argument here. Basically, I feel that the getter/setter functionality should be determined by arguments.length instead of the argument values. IMO, this leads to a more consistent API and is less surprising to the user.

There is the argument that undefined is an invalid value, so breaking the chain makes sense since it acts like a form of error reporting. I disagree with this logic. As a form of error reporting, breaking the chain doesn't always work and leads to confusing error messages. (See ticket for more detailed explanation).

Changed July 14, 2011 07:45PM UTC by timmywil comment:7

#9826 is a duplicate of this ticket.

Changed July 14, 2011 08:59PM UTC by TJ Holowaychuk comment:8

I agree that this is a bug, arity > 1 shows the intention

Changed October 01, 2011 09:38PM UTC by rwaldron comment:9

#10396 is a duplicate of this ticket.

Changed November 04, 2011 04:43PM UTC by timmywil comment:10

#10671 is a duplicate of this ticket.

Changed November 10, 2011 03:42PM UTC by rwaldron comment:11

#10749 is a duplicate of this ticket.

Changed November 10, 2011 04:08PM UTC by dmethvin comment:12

keywords: → 1.8-discuss
resolution: invalid
status: closedreopened

Reopening for 1.8 discussion -- should we have uniform behavior for .method(undefined/null) ?

Changed November 10, 2011 04:08PM UTC by dmethvin comment:13

status: reopenedopen

Changed December 13, 2011 02:59PM UTC by dmethvin comment:14

keywords: 1.8-discuss
resolution: → fixed
status: openclosed

Changed December 13, 2011 02:59PM UTC by dmethvin comment:15

milestone: 1.next1.7.2

Changed April 11, 2012 06:49PM UTC by DNS comment:16

text + ""
text || ""

Note that these two have different behavior in cases other than those you've considered. If text is an empty array, for example, the previous effective value would have been [], while in jQuery 1.7.2 it becomes "[object Object]".

It appears that .text([]) is a no-op in jQuery pre-1.7.2. Some of my code was unknowingly relying on this behavior, and broke when I upgraded to 1.7.2. I'm fixing the code in question, which shouldn't be passing [] to text() in the first place. But I figured you might want to know about this, since it does represent an undocumented change, however minor.