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: |
Description
Passing undefined to $.fn.text()
triggers getter functionality instead of the setter functionality. For example the following code throws an exception:
#!js var text; $("<div/>").text(text).append($("<span/>"))
Attachments (0)
Change History (16)
Changed May 26, 2011 02:31AM UTC by comment:1
component: | unfiled → manipulation |
---|---|
priority: | undecided → low |
resolution: | → invalid |
status: | new → closed |
Changed May 26, 2011 02:49AM UTC by comment:2
Pull request with fix: https://github.com/jquery/jquery/pull/392
Changed May 26, 2011 02:50AM UTC by comment:3
Why is it expected behavior? It breaks chaining and causes unexpected exceptions.
Changed May 26, 2011 03:16AM UTC by 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/>"))
http://jsfiddle.net/rwaldron/sTesj/
The code above will work fine without breaking the existing api.
Changed May 26, 2011 03:31AM UTC by comment:5
As noted on the pull request: http://api.jquery.com/text/ The documentation specifies the valid input to the method and their expected outcome.
Changed May 26, 2011 05:54AM UTC by comment:6
FWIW, I would recommend using this work around instead:
#!js 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 http://bugs.jquery.com/ticket/5571, 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 08:59PM UTC by comment:8
I agree that this is a bug, arity > 1 shows the intention
Changed November 04, 2011 04:43PM UTC by comment:10
#10671 is a duplicate of this ticket.
Changed November 10, 2011 03:42PM UTC by comment:11
#10749 is a duplicate of this ticket.
Changed November 10, 2011 04:08PM UTC by comment:12
keywords: | → 1.8-discuss |
---|---|
resolution: | invalid |
status: | closed → reopened |
Reopening for 1.8 discussion -- should we have uniform behavior for .method(undefined/null)
?
Changed November 10, 2011 04:08PM UTC by comment:13
status: | reopened → open |
---|
Changed December 13, 2011 02:59PM UTC by comment:14
keywords: | 1.8-discuss |
---|---|
resolution: | → fixed |
status: | open → closed |
We landed this space-saving bug fix in https://github.com/jquery/jquery/commit/6c2a501de40a5f6b3ad382e2d309e5a10fce04d0
Changed December 13, 2011 02:59PM UTC by comment:15
milestone: | 1.next → 1.7.2 |
---|
Changed April 11, 2012 06:49PM UTC by 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.
This is expected behaviour.