#8500 closed bug (fixed)
radios and checkboxes revert to default (HTML) state when wrapped in IE
Reported by: | gnarf | Owned by: | gnarf |
---|---|---|---|
Priority: | low | Milestone: | 1.6 |
Component: | manipulation | Version: | 1.5.2 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
calling .wrap() on something that contains a radio or checkbox will cause it to revert to the state in the HTML that created it.
Change History (17)
comment:2 Changed 12 years ago by
So far the closest to a feature detect I've gotten is this:
var div = document.createElement(div), input; div.innerHTML = "<input type='checkbox' />"; input = div.getElementsByTagName( "input" )[ 0 ]; // IE6 actually sets checked to true here, and if it doesn't work, the // appendChild doesn't clear the checked state - it should be fairly safe input.click(); // interestingly - if you set input.checked = true it will work - odd eh? // and maybe we should call this "appendResetsChecked" jQuery.support.noAppendChecked = input.checked && !div.appendChild(input).checked;
comment:3 Changed 12 years ago by
http://jsperf.com/append-checked -- Might not be the right way to test the effects, but they don't seem that drastically bad here...
comment:5 follow-up: 7 Changed 12 years ago by
See also #1736, where someone was asking for the ability to preserve arbitrary expando properties. I think it's better to just deal with the critical ones like checked as you've done here.
But... doesn't this problem iron itself out if the attr rewrite sets the checked attribute when someone uses $(":checkbox").attr("checked", true);
? That way when the element is cloned and/or serialized it will reflect the current check state.
Of course, if someone uses $(":text").attr("value", "abc");
that would also change the serialized state of the element. I think that $(":text").val("abc");
should only set the dynamic state (value
property) and leave the value
attribute unmolested.
comment:6 Changed 12 years ago by
Nope, setting the checked attribute doesn't seem to be enough for IE6:
comment:7 Changed 12 years ago by
Replying to dmethvin:
See also #1736, where someone was asking for the ability to preserve arbitrary expando properties. I think it's better to just deal with the critical ones like checked as you've done here.
Agreed
But... doesn't this problem iron itself out if the attr rewrite sets the checked attribute when someone uses
$(":checkbox").attr("checked", true);
? That way when the element is cloned and/or serialized it will reflect the current check state.
Yeah, but thats not going to catch the actual user clicking on a radio to change it, unless you are suggesting they add a handler to every checkbox to set the attr to what it is, which could be a valid solution too...
Of course, if someone uses
$(":text").attr("value", "abc");
that would also change the serialized state of the element. I think that$(":text").val("abc");
should only set the dynamic state (value
property) and leave thevalue
attribute unmolested.
comment:8 Changed 12 years ago by
Component: | unfiled → attributes |
---|---|
Owner: | set to gnarf |
Priority: | undecided → low |
Status: | new → assigned |
comment:9 Changed 12 years ago by
The test case seems to work fine now: http://jsfiddle.net/timmywil/eGgvw/21/
comment:11 Changed 12 years ago by
Component: | attributes → manipulation |
---|---|
Version: | 1.5.1 → 1.5.2 |
I didn't see the real problem before. This is a manip bug (IE6/7 can't handle keeping checked on appendChild).
Gnarf's duck punch above works to fix #8060. Patch incoming. http://jsfiddle.net/timmywil/MwtCW/8/
comment:13 Changed 12 years ago by
Resolution: | → duplicate |
---|---|
Status: | assigned → closed |
comment:15 Changed 12 years ago by
Resolution: | duplicate → fixed |
---|
comment:16 Changed 12 years ago by
Milestone: | 1.next → 1.6 |
---|
I apologize for duping http://bugs.jquery.com/ticket/769 but to hopefully redeem myself I will correct with a punchable plugin for those that need this in IE6: http://jsfiddle.net/eGgvw/13/