Editor: WritingFlow: Consider selection collapsed for Shift+Arrow at navigable edge

[aduth]

Closes #6164

This pull request seeks to resolve an issue with Shift+Arrow behavior of non-collapsed selections. Specifically, when a user selects text while holding Shift and pressing arrow keys, proceeding to press the reverse of those arrow keys while continuing to hold Shift should progressively collapse the selection.

Before	After

Implementation notes:

I had considered trying to incorporate this into the logic of isVerticalEdge and isHorizontalEdge from the dom module, but it relies on "is Shift held" as a condition to be known, which is made available only by the event handled within WritingFlow. Optionally, it could also be considered to pass as an argument.

Testing instructions:

Verify the intended fix, that selecting text in a particular direction should inherit browser behavior when that is followed by arrow keys in the reverse direction of the selection.

(It may help to reference the included end-to-end tests to explain the behavior)

Verify expected behavior with WritingFlow continues to work, particularly:

• Arrow presses while the Shift key is not held should navigate correctly within text and between text blocks
• Variations of selection direction (multi-selection should still occur while holding shift and selecting beyond the edges of a block)

[aduth]

I'm struggling to understand why the end-to-end tests are failing in Travis. The full suite passes for me when run locally.

[aduth]

I'm struggling to understand why the end-to-end tests are failing in Travis. The full suite passes for me when run locally.

I discovered the reason for this being attributable to the fact that Shift+ArrowUp with an uncollapsed selection in the first line of text behaves differently in Mac Chrome than it does anywhere else (including Linux Chrome as tested by Travis).

(Animation shows Shift+ArrowUp in Mac Chrome on the left, Windows Chrome on the right)

It means I need to rethink the behavior changes, since Shift+ArrowUp shouldn't just collapse an uncollapsed selection, it may need to trigger a multi-selection to the previous block if the uncollapsed selection occurs entirely within the first line of a paragraph.

[ellatrix]

@aduth I created an alternative PR: #14450. I think it might be better if keep the logic in isVerticalEdge. isHorizontalEdge has similar logic using isSelectionForward.

[aduth]

Closing in favor of #14450