WritingFlow in navigation mode doesn't scroll the page

[afercia]

Describe the bug

When the editor is switched to "navigation mode", the WritingFlow component is supposed to make the Tab and Down / Up arrow keys navigate from block to block.

Actually, the blocks are selected but the page doesn't scroll. In a page with long content, this defeats the whole purpose of WritingFlow as the selected block doesn't ever come into view.

To reproduce
Steps to reproduce the behavior:

• edit a post with some long content
• click on the title
• use the Tab or Down arrow keys to move to the first block after the title
• press Escape to switch to "navigation mode"
• keep pressing the Tab or Down arrow keys to navigate the blocks
• observe the page doesn't scroll
• observe the Sidebar: the content changes and shows the selected blocks type and settings, which is correct and proves the blocks are actually selected
• however the page doesn't scroll so keyboard users can't really see which block is selected

Note that in this context, the term "selected" refers to the Gutenberg block selection mechanism, not the DOM selection methods.

Animated GIF to better illustrate:

In the scenario above, I wonder how this block navigation mechanism is of any help for sighted keyboard users.

Expected behavior
The page to scroll and the "selected" block to be into the screen view.

Browsers details

• note: I can see some scrolling only with Safari stable 13.1
• no page scroll with Safari technology preview Release 106 (Safari 13.2, WebKit 15610.1.12.2)
• no page scroll with macOS Chrome 81
• no page scroll with macOS Firefox 76.0.1

Editor version (please complete the following information):

• WordPress version: 5.4 and trunk
• can reproduce on the WP 5.4 block editor, the trunk block editor, and the plugin Version 8.1.0

Additional context
Code responsible for this behavior:

gutenberg/packages/block-editor/src/components/writing-flow/index.js

Lines 379 to 410 in c327f19

	// In navigation mode, tab and arrows navigate from block to block.
	if ( isNavigationMode ) {
	const navigateUp = ( isTab && isShift ) || isUp;
	const navigateDown = ( isTab && ! isShift ) || isDown;
	const focusedBlockUid = navigateUp
	? selectionBeforeEndClientId
	: selectionAfterEndClientId;
	if ( navigateDown || navigateUp ) {
	if ( focusedBlockUid ) {
	event.preventDefault();
	selectBlock( focusedBlockUid );
	} else if ( isTab && selectedBlockClientId ) {
	const wrapper = getBlockDOMNode( selectedBlockClientId );
	let nextTabbable;
	if ( navigateDown ) {
	nextTabbable = focus.tabbable.findNext( wrapper );
	} else {
	nextTabbable = focus.tabbable.findPrevious( wrapper );
	}
	if ( nextTabbable ) {
	event.preventDefault();
	nextTabbable.focus();
	clearSelectedBlock();
	}
	}
	}
	return;
	}

[aduth]

Is there something of the "code responsible" (e.g. event.preventDefault) you're expecting would be preventing the scroll behavior from taking place?

I observe that outside navigation mode, there's a "scroll into view" behavior in caret selection placement of placeCaretAtVerticalEdge (source). If I recall, a custom implementation was used for multi-selection (MultiSelectScrollIntoView), likely at least in part because "multi-selection" is largely an emulated selection.

Unsure if it's a case where something like this is necessary for navigation mode, or if the default focus behavior could be expected to bring the focused block into view.

[afercia]

I tried to comment out event.preventDefault() as first thing, and didn't notice changes in the behavior.

FYI: just created another issue which highlights more WritingFlow buggy behaviors that happen only with Firefox, see #22424

The fact it works (sort of) in Safari 13.1 and there are additional broken behaviors in Firefox potentially highlights some non-standard method used to move focus or maybe an issue related to timings or who-knows-what that makes the actual behavior very inconsistent across browsers.

[tellthemachines]

I tested this in Chrome and Safari on macOS and Chrome and Firefox on Windows 11 and it's working well now. Closing this issue; feel free to reopen if it reoccurs.