Writing Flow: restore early return for no block selection in tab nav hook

[Mayank-Tripathi32]

What?

Closes #69037
Fixes tab navigation error in Site Editor preview frame

Why?

Tab navigation from preview frame causes console errors after #65204 removed an early return condition. Issue doesn't exist in WP 6.7.1 without Gutenberg.

How?

Restores early return in useTabNav hook:

if (event.defaultPrevented || (!hasMultiSelection() && !getSelectedBlockClientId())) {
    return;
}

This prevents unnecessary processing when no selection exists, fixing the error while maintaining functionality.

Testing Instructions

• Open Site Editor
• Tab through UI until preview frame is focused
• Tab forward/backward from preview frame
• Verify no console errors appear

Testing Instructions for Keyboard

• Open Site Editor
• Use Tab key to navigate through interface elements
• When preview frame is focused (visible focus outline), press Tab and Shift+Tab
• Verify seamless navigation without console errors
• Confirm focus moves correctly to next/previous UI elements

ScreenCast

Test.Focus.mov

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: Mayank-Tripathi32 <mayanktripathi32@git.wordpress.org>
Co-authored-by: stokesman <presstoke@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: singhakanshu00 <akanshusingh@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[Mayank-Tripathi32]

Failing test seems irrelevant to changes as both failed with status exit

[stokesman]

This looks good to me. This rest of this comment is for easier reference and explanation. The early return was removed here. This restores it though moves it to an even earlier location. It’s new location should be inconsequential to the result of the hook. The only concern that I could imagine would be a potential micro-optimization. If it were placed after the other condition for early return that tests for the Tab key. That one might be a lighter test and if so should run first. I doubt it would make any significant difference but I wanted to be thorough in noting what’s different.

[t-hamano]

The only concern that I could imagine would be a potential micro-optimization. If it were placed after the other condition for early return that tests for the Tab key.

Do we want to try this? If we follow the original process, it should look like this:

if ( event.keyCode !== TAB ) {
	return;
}

const isShift = event.shiftKey;
const direction = isShift ? 'findPrevious' : 'findNext';

if ( ! hasMultiSelection() && ! getSelectedBlockClientId() ) {
	return;
}

const nextTabbable = focus.tabbable[ direction ]( event.target );

[stokesman]

Do we want to try this? If we follow the original process, it should look like this:

Your example is true to the prior execution. My nitpick with that would be that the early return we are restoring should go before the isShift and direction assignments since they could go unused. That was small bother for me with the prior code.

if ( event.keyCode !== TAB ) {
	return;
}

if ( ! hasMultiSelection() && ! getSelectedBlockClientId() ) {
	return;
}

const isShift = event.shiftKey;
const direction = isShift ? 'findPrevious' : 'findNext';
const nextTabbable = focus.tabbable[ direction ]( event.target );

[Mayank-Tripathi32]

Do we want to try this? If we follow the original process, it should look like this:

if ( event.keyCode !== TAB ) {
	return;
}

if ( ! hasMultiSelection() && ! getSelectedBlockClientId() ) {
	return;
}

const isShift = event.shiftKey;
const direction = isShift ? 'findPrevious' : 'findNext';
const nextTabbable = focus.tabbable[ direction ]( event.target );

This seems to work perfectly, should we go ahead with this?

[t-hamano]

@Mayank-Tripathi32 Let's give it a try.