Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
bug fix on input radio #11227
So i'm not sure that the unit tests will catch this ( @nhunzaker might know) effectively give that it's a browser specific warning? I think we should move the original unit test in #7333 to a DOM fixture and ensure that it works. I think we also need understand why this was fixed inadvertantly in v16 before merging
I tested https://jsfiddle.net/97gr5e65/1/ made by @aweary.
After some debugging, I found an interesting point.
Let me explain it with the test case I added.
promising state after update:
step1, update radio1:
step2-1, update radio2's name:
I think if we update checked first, it would be ok
- Safari Desktop 7.1, 8, 11
- Safari iOS 9
- Firefox 47, 56
- Chrome 42, 62
This checks out!
@landvibe Great work spotting this! Do you mind if I push this fixture to your PR?
Still, we need to figure out why
restoreControlledState isn't firing in this instance. Right now, I see that as the root of the problem.
Alternatively, could we just call
updateNamedCousins where this PR now has
updateChecked? Is there an advantage to one over the other?
Sorry for the delay. I had to spend some time figuring out what
updateNamedCousins is actually doing. It looks like this is necessary for controlled radios so that you can programmatically prevent them from changing via state (like not toggling state in a change handler).
This looks good, I'd just like for the conditions for applying
updateChecked to mirror that of
updateNamedCousins, which I've laid out in the comments.
Thank you for sending this out. I apologize it took this long. This is a fantastic find!