FocusZone: Focus should wrap consistently with ms-wide defined behaviors

[jspurlin]

Environment Information

• Package version(s): 7.22.2

Please provide a reproduction of the bug in a codepen:

Load the following codepens (resize the window so that you have multiple rows of controls, if needed) and either put focus on the first row or last row and press up/down arrow (relatively speaking).

Base FocusZonePen: https://codepen.io/jspurlin/pen/xxKbGVR?&editable=true

FocusZone with data-no-vertical-wrap={true}: https://codepen.io/jspurlin/pen/QWLwELj?&editable=true

Actual behavior:

• In the first codepen focus stays in the current row and jumps to the prev/next element until it wraps.
• In the second codepen the focus wraps to the very last/first item in the FocusZone

Expected behavior:

Focus behavior align with the Microsoft-wide guidelines for navigating rows/columns of content:

• Right/Left arrows wrap to the next/prev row, regardless of number of cells
• Down/Up arrows wrap to the next/prev column, regardless of number of cells
• If the last row/cell is reached and Right arrow is pressed, nav goes back to the first row/cell, and vice versa
• If last column/cell is reached and Down arrow is pressed, nav goes back to first column/cell, and vice versa.

I thought https://github.com/OfficeDev/office-ui-fabric-react/pull/9534 was going to improve this experience, but that was not the case.

The proper fix here is probably going to be somewhat involved because it's changing the core behavior of FocusZone

Priorities and help requested:

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

Requested priority: Normal

Products/sites affected: Office Online

[JasonGore]

To clarify, both CodePens have an issue with columnar navigation. Row major keyboard navigation is fine in both cases, but the columnar navigation is incorrect in both cases. This diagram helped me understand the disparity in behavior between row and column navigation:

[JasonGore]

A fix for this issue should also address #10145.

[dzearing]

@jspurlin Where is the spec? Can we make a public spec? Or check it into Fabric? FocusZone was defined before this functionality was defined, so the wrapping is new logic and it would be good to have these things in a spec.

I also don't really agree with the right hand picture. If you have "wrapping" on in multi fixed column cases, it should simply cycle through that column. It gets way too weird in non-fixed scenarios if you do anything else.

1234 5678 9

Say you're on item 3. Press up arrow. When not wrapped, it should stay at 3 (and let the event bubble)

When wrapped, it should move to 9 Press up from 9. Because we haven't pressed a horizontal arrow, we do not reset horizontal alignement, and move focus to 7.

Is this correct?

Alternatively, we could "reset horiz alignment" when wrapping, so that pressing up from 9 goes to 5 instead.

I want to keep in mind that not all grids are uniform, and that resetting horizontal alignment on non-horizontal actions can cause "pulling" the focus to one side or another.

[jspurlin]

@dzearing in the example you gave it should jump to 6. Even in office there are cases where the contents aren't always a full rectangle.

The general rule is if you are wrapping by hitting:

• The top/bottom of the zone it should go to the last/first control prev/next column (and that wraps when go are at the top-left-most/bottom-right-most controls)
• The left/right of the zone it should go to the last/first control of the prev/next row (and that wraps when go are at the top-left-most/bottom-right-most controls)

Here's the publicly available version of the documentation: https://docs.microsoft.com/en-us/windows/uwp/design/input/keyboard-interactions

[jspurlin]

@JasonGore / @dzearing any update on this work?

[smhigley]

I just took a look at both codepens, and the behavior is super weird. My own expectation would be to either treat a set as linear (so both left & up are the same, and right & down are the same), or two-dimensional, where arrow keys do not wrap to a different row/column (and items wouldn't reflow to different rows/columns).

My understanding of the linked UWP keyboard page supports that view -- those graphics of the row wrapping behavior and column wrapping behavior are both for linear sets, and they are mutually exclusive. That is, if a set were to have items added first horizontally and wrapping to new rows, then arrow keys would follow the same path. If a set were to have items added first vertically and then wrapping to new columns, arrow keys would follow that path. Both docs examples do not show true table/grid relationships, and should not have two-dimensional keyboard navigation.

The linked codepens also show a layout that should not have two-dimensional navigation. Up/down arrows in those examples should perform the same actions as left/right, and there should be no column navigation at all.

An actual grid should not let right/left arrows wrap to new rows, or up/down arrows wrap to new columns. Does that sound like what you would expect for keyboard behavior? Also paging @betrue-final-final in case he has more context on the UWP page :)

[msft-fluent-ui-bot]

Because this issue has not had activity for over 150 days, we're automatically closing it for house-keeping purposes.

Still require assistance? Please, create a new issue with up-to date details.