The radio Checked has not been changed in DocumentFragment
Categories
(Core :: DOM: Forms, defect)
Tracking
()
People
(Reporter: mapaler, Unassigned)
Details
Attachments
(1 file)
|
2.01 KB,
text/html
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0
Steps to reproduce:
1.Open the page
2.Click a small number
3.Click a big number
4.Any repeated clicks numbers
5.Backward or Forward
Actual results:
The option stays on the biggest one.
Expected results:
Select the option that corresponds to the number in the parameter.
If a set of radios is inside DocumentFragment, when you set one of it Checked to True, there are 2 trues at the same time.
When you add back to <Body> later, only the largest one is displayed.
Chrome doesn't have this bug.
|
||
Comment 2•4 years ago
|
||
Kagami, could you take a look at this? This seems to be related to input elements which aren't attached to a document.
|
|
||
Updated•4 years ago
|
|
||
Comment 3•4 years ago
•
|
||
As you observed in comment #1, this is because disassociated radio buttons are not properly grouped and thus automatic unchecking never happens: bug 1685926. Let's track this there. (This adds a real example, thanks for reporting!)
(In reply to Kagami [:saschanaz] from comment #3)
As you observed in comment #1, this is because disassociated radio buttons are not properly grouped and thus automatic unchecking never happens: bug 1685926. Let's track this there. (This adds a real example, thanks for reporting!)
*** This bug has been marked as a duplicate of bug 1685926 ***
Why do I still have unexpected behavior in my sample code over v115?
When radios are in a fragment, multiple checkeds can exist at the same time, and when the page is reinserted, only the last one remains.
|
|
||
Comment 5•2 years ago
|
||
Because bug 1685926 is still live. 😭
Description
•