ChoiceGroup: does not behave correctly within a FocusZone

[haonliu]

Environment Information

• Package version(s): 6.121.0
• Browser and OS versions: win10 chrome

Please provide a reproduction of the bug in a codepen:

https://codepen.io/anon/pen/ZVZojB

Actual behavior:

users cannot change choice group's selected choice using arrow key inside focus zone

Expected behavior:

users should be able to change choice group's selected choice using arrow key inside focus zone

Priorities and help requested:

Are you willing to submit a PR to fix? (Yes, No) yes

Requested priority: (Blocking, High, Normal, Low) high

Products/sites affected: (if applicable)

[mikewheaton]

This looks to be related to the buttons above and below the ChoiceGroup. Here's a CodePen without those buttons that doesn't have the issue: https://codepen.io/mikewheaton/pen/YdMvKB

[dzearing]

@mikewheaton I think your codepen might be hiding the issue. There is definitely an issue here. Just to illustrate, I forked your codepen and moved the FocusZone around both ChoiceGroups.

https://codepen.io/dzearing/pen/bOyLdG

If you arrow up and down, you will see some really bad behavior.

Now, I will caveat all of this in asking a different question: why is a vertical FocusZone wrapping a ChoiceGroup? They will fight each other. FocusZone wrapping should really be for menu scenarios, so I'd be really interested in the actual usage scenario.

I think this is a bug with ChoiceGroup; here's what's happening:

When ChoiceGroup is the only thing within the FocusZone, There is only one element marked as data-is-focusable=true. This seems to be because ChoiceGroup is managing this. When you up and down arrow through options, the keypress events are not being stopped via stopPropagation, and therefore FocusZone ends up handling them, looking for the next focusable entity to move them to.

I think removing the data-is-focusable attribute componently may end up resolving this. The default tabbing behavior of radio buttons is pretty much how FocusZone works, so this wouldn't affect normal scenarios. But when in a FocusZone, it would interpret input elements as focusable (even without the data attribute) and handle the arrowing, moving focus to the next thing.

Needs some testing, but I think this is probably the best fix.

[haonliu]

@dzearing Thanks for the detailed explanation. Our actual usage scenario is that we are using a details list to list a bunch of items, and in each row of the list there is a choice group. Since Details list has FocusZone inside, the choice end up living inside the focus zone.

[dzearing]

@haonliu Ah thank you! I was nervous it was that combo. We will see how we can address.

[flyingUnderTheRadar]

Any update on this @dzearing

[haonliu]

Is there any update on this? @mikewheaton @dzearing

[dzearing]

I believe I have a fix ready for you. In PR now. Need to cycle with @JasonGore on why data-is-focusable was originally added.