Opened 14 years ago
Closed 12 years ago
#3879 closed bug (fixed)
appending or cloning a checked checkbox or radio button doesn't maintain the default state
Reported by: | Pyro979 | Owned by: | snover |
---|---|---|---|
Priority: | blocker | Milestone: | 1.5 |
Component: | manipulation | Version: | 1.4.4 |
Keywords: | append checked selected defaultValue defaultSelected defaultChecked | Cc: | |
Blocked by: | Blocking: |
Description
This looks like a similar bug to #769, but I am experiencing this in IE7.
var check=$(document.createElement("input")).attr("type","checkbox"); check.attr("checked",true);
$("#id_main1").append(check);
The appended checkbox is no longer checked. There is an obvious workaround I can (and did) write meanwhile. But this is a pretty serious bug in my opinion.
Attachments (1)
Change History (34)
comment:1 Changed 14 years ago by
comment:3 Changed 14 years ago by
Milestone: | → 1.3.1 |
---|---|
Owner: | set to john |
Is this a bug that's new in jQuery 1.3 or did it also exist in jQuery 1.2.6?
comment:5 Changed 14 years ago by
This is an old bug with IE6/7 appendChild, it clears the checked state of a checkbox. I thought there was a ticket related to the same issue with .clone()
but I can't find it.
comment:7 Changed 13 years ago by
We're running in to this issue as well. Anyone know the status of fixing this? In the interim, we can set the checked state as part of the HTML construction, i.e. $('<input type="checkbox" checked="checked"/>') as a workaround.
While @Wildman may be correct re the spec, even IE6 supports using boolean flags with the .attr(...) function. That is to say, once the checkbox is added to the DOM, <obj>.attr('checked', true) works as expected. However, as noted in the bug, prior to adding to the DOM, the attr(...) function does not work - even when chained at the end of the append() function.
comment:9 Changed 13 years ago by
Component: | core → manipulation |
---|
comment:10 Changed 13 years ago by
Created a jsfiddle testcase http://jsfiddle.net/boushley/R3Wxx/ is running against 1.3.2 and http://jsfiddle.net/boushley/R3Wxx/1/ is running against 0 GIT. I can reproduce it from IE 7.
comment:11 Changed 13 years ago by
Status: | new → open |
---|
Tested and passing in:
- FF3.0.12,3.6.11,4b6
- Chrome 5,6,7,8
- Safari 5
- IE 6,7,8
- Opera 10.60
comment:12 Changed 13 years ago by
Resolution: | → worksforme |
---|---|
Status: | open → closed |
Per addyosmani request, a third method:
comment:14 Changed 13 years ago by
Milestone: | 1.3.1 |
---|---|
Resolution: | worksforme |
Status: | closed → reopened |
comment:15 Changed 13 years ago by
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
To clarify, my cases are meant to show proven, tested workaround to this unfixable, unsolvable problem.
comment:16 Changed 13 years ago by
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
comment:18 Changed 13 years ago by
Summary: | appending a checked checkbox doesn't maintain the cheked state → appending a checked checkbox or radio button doesn't maintain the checked state |
---|
comment:21 Changed 13 years ago by
Keywords: | checked selected defaultValue defaultSelected defaultChecked added; checkbox removed |
---|---|
Summary: | appending a checked checkbox or radio button doesn't maintain the checked state → appending or cloning a checked checkbox or radio button doesn't maintain the default state |
comment:22 Changed 13 years ago by
I can confirm that this is still an issue in 1.4.2, and assuming that it's still open, in 1.4.3+.
The workaround suggested by icfantv still works.
comment:23 Changed 13 years ago by
Priority: | major → low |
---|---|
Resolution: | → patchwelcome |
Status: | reopened → closed |
Version: | 1.3 → 1.4.4 |
I don’t know if there is really anything that can be done about this in a way that is satisfactory; if someone wants to try their hand at a patch, we would be happy to review it.
comment:24 follow-up: 25 Changed 13 years ago by
I wish this ticket weren't closed. I've actually noticed the exact same issue in Chrome.
comment:25 Changed 13 years ago by
Replying to julien:
I wish this ticket weren't closed. I've actually noticed the exact same issue in Chrome.
As snover mentioned, patches are welcome.
comment:26 Changed 12 years ago by
Didn't see a test case using clone: http://www.jsfiddle.net/fletch/CLq3P/
Works fine in Firefox 3.6 and Chrome 8, does not work in IE8.
comment:27 Changed 12 years ago by
Milestone: | → 1.5 |
---|---|
Resolution: | patchwelcome |
Status: | closed → reopened |
comment:28 Changed 12 years ago by
Owner: | changed from john to snover |
---|---|
Status: | reopened → assigned |
comment:29 Changed 12 years ago by
Let me say right away that I'm not sure that I'm doing this correctly, and whether or not this is the "proper" way to fix this bug. But this seems to work. I can probably benefit from some more optimization
comment:30 Changed 12 years ago by
Just added a jQuery.support.checkboxAppendPermanence check into support.js. This should improve performance since we won't need to do any of this "checked" re-assigning when it works fine. Don't know if I put it into the right spot.
comment:31 Changed 12 years ago by
Pyro979, there is already an outstanding open pull request for this issue; you don’t need to write code to fix this ticket.
comment:32 Changed 12 years ago by
Priority: | low → blocker |
---|
comment:33 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Ensure that buildFragment clones elements properly in all browsers. Fixes #3879, #6655. Also improves form element clone tests and fixes bugs in $.fn.clone exposed by these new test cases related to the values of checkboxes and radio buttons in IE.
Changeset: b14f02899e74c429effadd88527ffde17650149a
check.attr("checked", true) should not work at all because it is check.attr("checked", "checked") see W3C XHTML