Writing Flow: Consider tabbable edge if no adjacent tabbable

[aduth]

This pull request seeks to resolve an error which occurs when making a forward shift selection in the last paragraph of a post, or a backward shift selection in the title.

Uncaught TypeError: Cannot read property 'closest' of undefined

Implementation notes:

closestTabbable may be undefined if there are no more tabbable fields in the desired direction. Since the intent of isTabbableEdge is to discern between there being other tabbables in the same block, it is reasonable to expect this should return true if there are no more tabbables. Where used, this may lead to expandSelection, but this already accounts for the case where there is no adjacent block.

Testing instructions:

Verify backward shift-selection from title results in no errors.
Verify forward shift-selection from last paragraph of content results in no errors.

[jorgefilipecosta]

Hi @aduth these changes fix the errors, but I noticed a behavior change when comparing against the master.
On the last paragraph on master when we press shit+down, we select we get an error, but the remaining text of the paragraph gets selected, in this branch no selection happens.

When pressing arrow+up, we multi-select to the previous paragraph in both branches so in this case, no changes happen.

[aduth]

Heh, I think this is one of those odd circumstances where the presence of the error was actually providing a desirable behavior.

As implemented, this is expected: When pressing Shift+Down, we prevent the browser default behavior, and only expand the selection if an adjacent block exists:

gutenberg/editor/components/writing-flow/index.js

Lines 202 to 203 in 480990a

	event.preventDefault();
	this.expandSelection( selectedBlockUID, isReverse );

gutenberg/editor/components/writing-flow/index.js

Lines 140 to 147 in 480990a

	expandSelection( currentStartUid, isReverse ) {
	const { previousBlockUid, nextBlockUid } = this.props;
	const expandedBlockUid = isReverse ? previousBlockUid : nextBlockUid;
	if ( expandedBlockUid ) {
	this.props.onMultiSelect( currentStartUid, expandedBlockUid );
	}
	}

Because no next block exists, it's expected that (a) the browser default is prevented and (b) nothing else happens.

We could revise this so that the browser default is only prevented if the selection can be expanded. That said, it's a bit inconsistent to set expectations for users that Shift+Down can trigger the "select to end of block" behavior for the last block, but no other blocks (where multi-select takes effect instead). What do you think?

In the meantime, since this is "Working as Intended" so far as the current implementation is concerned, I'm inclined to merge as is.

[aduth]

Also noting that #6467 introduces a new "Writing Flow" end-to-end test suite, which would be a good place to assert whatever behavior we decide upon as being intended.

[mtias]

Nice to see the e2e writing flow test setup.