bug fix on input radio #11227

landvibe · 2017-10-14T10:55:46Z

The PR#7333 made this issue.
And now there is no validation warning that PR#7333 is mentioning.
I think React 16 resolved the validation warning issue, so I reverted it to the previous of PR#7333.
I also added a test case for #7630

facebook#7630

jquense · 2017-10-26T18:05:49Z

packages/react-dom/src/client/ReactDOMFiberComponent.js

-        // Update the wrapper around inputs *after* updating props. This has to
-        // happen after `updateDOMProperties`. Otherwise HTML5 input validations
-        // raise warnings and prevent the new value from being assigned.
+        // Update the wrapper around inputs *after* updating props.


this comment isn't correct anymore since you've moved the updateDOMProperties call below it. We would need to confirm that the original issue with validations firing doesn't occur. Can you write a dom fixture that demonstrates the issue and that it doesn't occur after this change?

@nhunzaker Any suggestions on how to write that, or what conditions triggered it?

jquense · 2017-10-26T18:09:28Z

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

make radio's checked updated before the name

landvibe · 2017-10-27T15:22:23Z

@jquense

I tested https://jsfiddle.net/97gr5e65/1/ made by @aweary.
And I realized React 16 did not resolve the validation warning.
So I don't think it is a good idea to edit @@nhunzaker's code.
And I started over.

After some debugging, I found an interesting point.
When we edit a radio's name with checked===true, browser makes another radio's checked false.
In the middle of an update, it is possible to have multiple checked===true.

Let me explain it with the test case I added.
There are two radio inputs.

initial state:
radio1: {
name: 'firstName',
checked: false,
}
radio2: {
name: 'firstName',
checked: true,
}

promising state after update:
radio1: {
name: 'secondName',
checked: true,
}
radio2: {
name: 'secondName',
checked: false,
}

step1, update radio1:
radio1: {
name: 'secondName',
checked: true,
}
radio2: {
name: 'firstName',
checked: true,
}

step2-1, update radio2's name:
radio1: {
name: 'secondName',
checked: false, // whoops...
}
radio2: {
name: 'secondName',
checked: true,
}

I think if we update checked first, it would be ok
So I added updateChecked function.

nhunzaker · 2017-10-28T19:34:55Z

Hey everyone. Sorry! I was out of town and lost track. I'll start checking this out.

nhunzaker

Tested in:

IE9-11
Safari Desktop 7.1, 8, 11
Safari iOS 9
Firefox 47, 56
Chrome 42, 62

This checks out!

@jquense I made a test fixture to manually verify this: nhunzaker@f18c4c4

@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?

nhunzaker · 2017-11-07T00:37:59Z

packages/react-dom/src/client/ReactDOMFiberComponent.js

+  // When a checked radio tries to change name, browser makes another radio's checked false.
+  if (tag === 'input') {
+    ReactDOMFiberInput.updateChecked(domElement, nextRawProps, 'radio');
+  }


I'm trying to figure out why this is necessary (but it is definitely effective).

updateNamedCousins in ReactDOMInput should take care of this, but it looks like it doesn't run in the test case you've provided.

@jquense updateNamedCousins gets called in restoreControlledState, but for what ever reason it only fires on the button, which I guess is clicked and responsible for the last trigger. The radio input never gets targeted by restoreControlledState.

It feels like there's something deeper here that we need to fix.

I think updateNamedCousins is called only on the button because of this code ReactTestUtils.Simulate.click(buttonNode);
I checked that updateNamedCousins is not called when I run your fixture.

nhunzaker · 2017-11-07T00:43:49Z

packages/react-dom/src/client/ReactDOMFiberInput.js

+      DOMPropertyOperations.setValueForProperty(
+        node,
+        'checked',
+        checked || false,


Kind of a bummer that we have to || false here. It can't hurt, but I wonder if this is necessary (just with a quick test via https://codepen.io/nhunzaker/pen/qVadLo).

I also think it's unnecessary.

nhunzaker · 2017-11-07T00:49:20Z

packages/react-dom/src/__tests__/ReactDOMInput-test.js

@@ -669,6 +669,45 @@ describe('ReactDOMInput', () => {
    expect(cNode.checked).toBe(true);
  });

+  it('should have correct checked value when radio names changed', () => {


Do you mind rephrasing this to should check the correct radio when the selected name moves?

OK. yours is better

landvibe · 2017-11-07T08:18:48Z

@nhunzaker
I think updateChecked is more efficient than updateNamedCousins.
updateChecked just calls setValueForProperty once, but updateNamedCousins calls it group.length times per each updated node

new commit with your fixture

nhunzaker · 2017-11-13T13:22:22Z

packages/react-dom/src/client/ReactDOMFiberInput.js

+  targetType: ?string,
+) {
+  var node = ((element: any): InputWithWrapperState);
+  if (!targetType || targetType === node.type) {


In updateNamedCousins, we check for radio buttons like:

function updateNamedCousins(rootNode, props) { var name = props.name; if (props.type === 'radio' && name != null) { // ... } // ... }

Can you use that check here? That would allow us to remove the targetType argument and reading from the DOM.

I added the code in updateProperties because updateWrapper also calls updateChecked

nhunzaker

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.

landvibe · 2017-11-13T23:36:07Z

@nhunzaker applied your comment

nhunzaker

Looks good! I'm waiting on a build to do some final testing before merging. Thank you for sticking with me!

nhunzaker · 2017-11-19T15:41:21Z

Verified in:

IE 9/10/11
Edge 14/15/16
Chrome 62, 49, 41
Safari 7.1, 8, 9.1, 10.1, 11
iOS 7, 8, 9, 10.2, 11.1
Chrome for Android (latest)
Firefox 56, 52 (ESR), 47 (Former ESR)
Opera 41, 49

😅 (When am I finally going to automate this...)

Thank you for sending this out. I apologize it took this long. This is a fantastic find!

fixed a bug on radio input

4ce1fb0

facebook#7630

facebook-github-bot added the CLA Signed label Oct 14, 2017

landvibe mentioned this pull request Oct 15, 2017

Umbrella: React DOM Bugs #11097

Open

29 tasks

Merge branch 'master' of https://github.com/facebook/react

0e15659

jquense reviewed Oct 26, 2017

View reviewed changes

landvibe added 2 commits October 28, 2017 00:18

roll back previous commit

6f3a000

make radio's checked updated before the name

moved comment

aad2f64

merge from upstream/master

03b1b30

nhunzaker suggested changes Nov 7, 2017

View reviewed changes

landvibe added 2 commits November 7, 2017 15:44

Merge branch 'master' of https://github.com/facebook/react

69cbb05

added a fixture for radio bug

25c0fc4

fixed prettier error

e03b117

nhunzaker reviewed Nov 13, 2017

View reviewed changes

nhunzaker suggested changes Nov 13, 2017

View reviewed changes

read type from props, not node

9ee15eb

nhunzaker approved these changes Nov 17, 2017

View reviewed changes

nhunzaker merged commit 70abda5 into facebook:master Nov 19, 2017

nhunzaker mentioned this pull request Nov 19, 2017

Radio buttons are not correctly checked when using multiple lists of radio buttons #7630

Closed

This was referenced Dec 4, 2017

Update react-dom in / from 16.1.1 to 16.2.0 dropseed/jump#28

Closed

Update react in / from 16.1.1 to 16.2.0 dropseed/jump#29

Closed

renovate bot mentioned this pull request Feb 22, 2018

Update react monorepo packages to v16.2.0 mozilla/ensemble#28

Closed

This was referenced Mar 1, 2018

Update react-dom in / from 16.0.0 to 16.2.0 pcardune/redux-firebase-mirror#27

Open

Update react-test-renderer in / from 16.0.0 to 16.2.0 pcardune/redux-firebase-mirror#28

Open

dependabot-preview bot mentioned this pull request Mar 15, 2018

Update react requirement to 16.2.0 shankarshastri/GreenKeeperTest#4

Closed

This was referenced Mar 21, 2018

Update react to 16.3.2-abandoned sbardian/DebtTrackerAPI#15

Closed

Update react-dom to ^16.0.0-abandoned sbardian/DebtTrackerAPI#18

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

bug fix on input radio #11227

bug fix on input radio #11227

landvibe commented Oct 14, 2017 •

edited

Loading

jquense Oct 26, 2017

jquense commented Oct 26, 2017

landvibe commented Oct 27, 2017

nhunzaker commented Oct 28, 2017

nhunzaker left a comment

nhunzaker Nov 7, 2017

landvibe Nov 7, 2017

nhunzaker Nov 7, 2017

landvibe Nov 7, 2017

nhunzaker Nov 7, 2017

landvibe Nov 7, 2017

landvibe commented Nov 7, 2017 •

edited

Loading

nhunzaker Nov 13, 2017

landvibe Nov 13, 2017

nhunzaker left a comment

landvibe commented Nov 13, 2017

nhunzaker left a comment

nhunzaker commented Nov 19, 2017

bug fix on input radio #11227

bug fix on input radio #11227

Conversation

landvibe commented Oct 14, 2017 • edited Loading

Choose a reason for hiding this comment

jquense commented Oct 26, 2017

landvibe commented Oct 27, 2017

nhunzaker commented Oct 28, 2017

nhunzaker left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

landvibe commented Nov 7, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nhunzaker left a comment

Choose a reason for hiding this comment

landvibe commented Nov 13, 2017

nhunzaker left a comment

Choose a reason for hiding this comment

nhunzaker commented Nov 19, 2017

landvibe commented Oct 14, 2017 •

edited

Loading

landvibe commented Nov 7, 2017 •

edited

Loading