Skip to main content

Bug Tracker

Side navigation

#3016 closed bug (patchwelcome)

Opened June 10, 2008 03:28PM UTC

Closed December 24, 2010 02:46AM UTC

Last modified November 10, 2013 06:29PM UTC

Textarea loses current value when cloned

Reported by: Jones Owned by:
Priority: low Milestone:
Component: manipulation Version: 1.4.3
Keywords: firefox textarea value clone Cc:
Blocked by: Blocking:
Description

If you clone an element with a textarea in it and append this to another element, the value of the textarea is lost (or - if in the html a value for the textarea was set - the default value is set).

I found this behaviour only in firefox. I've attached a file with an example (and a dirty workaround I used).

Attachments (1)
  • test.html (1.5 KB) - added by Jones June 10, 2008 03:29PM UTC.
Change History (24)

Changed January 04, 2010 05:08PM UTC by Sly777 comment:1

This problem is not fixed. I get this problem on version 1.3.2.

Changed February 19, 2010 03:36PM UTC by szrudi comment:2

will this be fixed? as I see it's a bug for more than 2 years now..

Changed March 11, 2010 02:11AM UTC by Eddie comment:3

I have the same problem :-( Currently using a really ugly workaround...

I don't know too much about Trac, but maybe this bug report does not show up anymore, since it is assigned to Milestone 1.3. But I have no rights to change that...

Eddie

Changed June 20, 2010 07:07PM UTC by dmethvin comment:4

component: coremanipulation

Changed September 26, 2010 11:43PM UTC by dmethvin comment:5

summary: Problems with textareas, its value, clone and firefoxTextarea loses current value when cloned

Changed September 26, 2010 11:44PM UTC by dmethvin comment:6

milestone: 1.31.4.3

Changed October 01, 2010 01:45PM UTC by jitter comment:7

This is actually a firefox bug and it's know and sits there unfixed since 2004

https://bugzilla.mozilla.org/show_bug.cgi?id=230307

Changed October 15, 2010 07:27PM UTC by snover comment:8

keywords: firefox, textarea, value, clonefirefox textarea value clone
milestone: 1.4.3
priority: majorlow
status: newopen
version: 1.2.61.4.3

Safari and Chrome both do the same thing as Firefox here and clone the state of the element without any value changes. Opera and IE clone current state of the control, including any value changes. Fun…

Changed October 24, 2010 05:01PM UTC by addyosmani comment:9

#5524 is a duplicate of this ticket.

Changed December 24, 2010 02:46AM UTC by dmethvin comment:10

resolution: → patchwelcome
status: openclosed

This is similar to #1736 (if not an outright dup) and seems equally difficult to fix in a general way. If someone needs the partial input typed by a user at the point of cloning it would make more sense to copy over the .value at that point. If someone has a better idea let us know.

Changed November 07, 2011 02:51PM UTC by jakobhilden@gmail.com comment:11

Bug still exists in jQuery 1.6.2

Maybe this would be a solution? https://github.com/spencertipping/jquery.fix.textarea-clone

Changed November 07, 2011 02:57PM UTC by rwaldron comment:12

@jakobhilden@gmail.com see the previous comment by dmethvin

Changed January 06, 2012 05:17PM UTC by rwaldron comment:13

#11136 is a duplicate of this ticket.

Changed April 29, 2012 08:48PM UTC by Mark Wilden comment:14

I need this because I simulate nested forms by cloning parts of a big form, wrapping them in their own form, and submitting. I'm going to have to use @jakobbhilden's approach (thanks!).

My feeling is that if cloning other elements and getting their values works as expected, so should it word for textareas. So yes, the value should be copied when the element is cloned. Otherwise, it's simply not a "clone".

Changed November 02, 2012 09:27PM UTC by Val Schuman <jquery@schuman.ws> comment:15

Experiencing this bug in Chrome now. How come this ticket is closed?

Changed November 08, 2012 09:08PM UTC by anonymous comment:16

Replying to [comment:15 Val Schuman <jquery@…>]:

Experiencing this bug in Chrome now. How come this ticket is closed?

Same here.

Changed November 08, 2012 09:12PM UTC by mikesherov comment:17

It's closed as "patchwelcome", which means we're not going to fix it ourselves because we believe it to be too difficult, as dmethvin says:

"If someone needs the partial input typed by a user at the point of cloning it would make more sense to copy over the .value at that point. If someone has a better idea let us know."

Changed December 14, 2012 05:49AM UTC by bugs.jquery.com@simoneast.net comment:18

It doesn't actually look "too difficult" based on the fix by Spencer Tipping here:

https://github.com/spencertipping/jquery.fix.clone/blob/master/jquery.fix.clone.js

It is quite confusing when standard text inputs are cloned with their live value whereas textareas are not. :-(

Changed January 07, 2013 02:57PM UTC by Anonymouse comment:19

Wierd bug... I'd suggest this should be fixed not because I'm lazy but because as others have said it's inconsistent behaviour when compared to how clone() handles other elements.

clone() should clone, not clone most of it but leave little bits out here and there. Also the current clone() man page doesn't make any mention of this behaviour, which could be confusing.

Changed February 15, 2013 05:08AM UTC by anonymous comment:20

I consider this a bug that should remain open, as others have said. I don't know the ins and outs of jQuery's clone function, but this was my workaround,...

I simply set all textarea values within the "to-be-cloned" container into an obscurely-named "data-" attribute of each area before the clone, then restored the area values from the attributes immediately after (and removed the obscurely-named attribute). Sure, there's a performance/memory penalty but well worth it for all of my uses.

Changed April 29, 2013 05:47PM UTC by anonymous comment:21

I definitely think this should be fixed. I can verify that this did solve the problem for me.

https://github.com/spencertipping/jquery.fix.clone/blob/master/jquery.fix.clone.js

My use case involves cloning but not appending: the user is filling out a form which, when saved to the database, will be used to create a printable document. They can preview the document at any time. To generate the preview, I clone the form, set its action and target so that it will update an iframe with the printable version, and call .submit().

Changed September 25, 2013 01:00AM UTC by cpaloia@gvea.com comment:22

I believe that this bug is still in place. I was trying to clone divs from one form to another. All of the inputs were using the current value, but the textarea wasn't. In my case, I was able to just use appendTo instead of clone, but I think this is something that should be looked at.

I am using jQuery v1.10.2

Changed November 10, 2013 04:57PM UTC by jfeasel comment:23

This is still a problem with the latest 2.x and 1.x code, in Chrome 30 and Firefox 25; check this jsfiddle demonstrating it: http://jsfiddle.net/bLxsC/

Changed November 10, 2013 06:29PM UTC by dmethvin comment:24

The current behavior is documented at api.jquery.com and of course here. A plugin is available to provide the requested behavior. The ticket is marked patchwelcome, with the caveat that fixing this edge case inside jQuery causes a performance hit for the 90% of the time when it isn't needed.