Safari: Shift+click can't select across text blocks

[mcsf]

Description

Clicking while pressing the Shift key is a convenient way to create a selection between two points. Since the introduction of partial multi-selection in #38892, users can expect to use this method of selection across blocks, just as they would in a word processor. It doesn't work in Safari, though.

Step-by-step reproduction instructions

1. In Safari, in a post with multiple paragraphs, place the caret inside one.
2. While holding the Shift key, click in the middle of an adjacent paragraph.

Expected: a partial selection across the two paragraphs
Observed: a collapsed selection in the second paragraph

Screenshots, screen recording, code snippet

A comparison between Firefox (expected behaviour) and Safari (unexpected). In both browsers, shift-clicking inside the same paragraph works (unsurprisingly), but shift-clicking across blocks just moves the collapsed selection when using Safari.

Screen.Recording.2022-10-06.at.18.04.14.mov

Environment info

Gutenberg trunk, etc.

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[dcalhoun]

I explored this issue some. I did not identify the bug origin or a solution, but will capture what I did discover for posterity. Contributors more familiar with the code may already be aware of some of this information, but I'll share it nonetheless.

When moving the cursor into the second block (i.e. Shift + Click), both Chrome and Firefox trigger at least one invocation of handleSelectionChange where anchorNode is the first paragraph and the focusNode is the second paragraph. This leads to an the onSelectionChange invocation with the start argument as undefined.

Contrastingly, in this same context, Safari only ever triggers handleSelectionChange where anchorNode and focusNode are both set to one of the first or second paragraph — meaning there is never an event where anchorNode and focusNode are different. This results in the selection always being collapsed.

The relevant handleSelectionChange invocation appears to originate from the ownerDocument event handler:

gutenberg/packages/rich-text/src/component/use-input-and-selection.js

Lines 314 to 317 in cb8ed51

	ownerDocument.addEventListener(
	'selectionchange',
	handleSelectionChange
	);

I have not yet identified why Safari does not trigger an event with different anchorNode and focusNode in Gutenberg. In a rudimentary test outside of Gutenberg, Safari does successfully trigger the expected event with different nodes.

Removing myself as an assignee as I likely will not have time focus on this in the near future.

[mcsf]

As an added data point: this works in both Firefox and Chrome, but not for the same reasons.

In Chrome, the active element is the iframe's body element, as you might expect, and so selection is adjusted according to the rules in handleSelectionChange in the section led by the comment "If the selection changes where the active element is a parent of the rich text instance (writing flow), call onSelectionChange for the rich text instance that contains the start or end of the selection."

In Firefox, the active element is the second paragraph (i.e. the one into which we shift-clicked), which throws off the expectation that the current element is contained by the active one, thus the selection is not updated in that section of the handler, but somewhere else.

[mrfoxtalbot]

I just run into this problem as I was testing the editor in Safari. I am going to add my own testing video:

Screen.Capture.on.2023-07-27.at.18-17-57.mp4

[richtabor]

Confirmed.

[ellatrix]

The root problem is Safari refusing to select if there's a tabindex set. It's strange that selecting otherwise works, it only happens with Shift + Click. https://codepen.io/iseulde/pen/GRwLVyx