The newly implemented Selection API's direction's value always "none" regardless of the selected node. https://www.w3.org/TR/selection-api/#ref-for-dom-selection-direction-1
There’s an internal isDirectional flag, and if it’s false the direction will return "none". Likely we either don’t set it correctly, or go through a code path that does not preserve it. We need some tests that make selections using simulated mouse movement or keyboard to keep this working!
<rdar://problem/128812268>
Pull request: https://github.com/WebKit/WebKit/pull/29156
After some more research I learned that this bug only affects selections made by dragging the mouse.
Here’s why this is trickier than it sounds: When you drag from left to right, you might assume that’s a "directional" selection. But if you check out Mac editing behavior, outside the web context, you’ll see that this kind of selection behaves as a "non-directional" selection when it comes to extending the selection. For example, using shift-arrow keys will extend the selection from the appropriate boundary no matter which of the two arrow keys you use. Once you start using those arrow keys, the selection starts behaving as directional, with the end you didn’t move serving as the base and the one that you did move serving as the extent. All of this is consistent with getSelection().direction returning "none" before using the arrow keys and then returning a particular direction after using the arrow keys. The selection specification says that we a selection made with the mouse must indicate its direction. But to get correct Mac-style editing behavior we must make this more subtle distinction, that while there was a direction when making the selection, it must not be considered for purposes of the correct implementation of the arrow keys. This means that the Selection API is inadequate for correctly implementing Mac-style platform selection! My first attempt to fix this by marking selections directional did the wrong thing, and it’s not obvious what to do about this new kind of "half-directional" state. A design question, not an implementation one. And should this be exposed in the Selection API?
I think I figured it out.