Open the following test case in VE core:
<p>abc<span rel="ve:Alien" about="m1">ALIEN1</span><span rel="ve:Alien" about="m1">ALIEN2</span><span rel="ve:Alien" about="m1">ALIEN3</span>def</p>
Place the cursor before 'd' and press left, the cursor moves between ALIEN2 and ALIEN3, even though ALIEN1/2/3 is one node.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| ce.Surface afterKeyDown shouldn't assume .contenteditable is boolean | VisualEditor/VisualEditor | master | +4 -1 |
I think what we need to do is observe if the cursor ends up sandwiched between two DOM nodes which have .data('view') of the same CE node. If that happens we should select the CE node (focus it).
I think the check and fixup should be in afterDocumentKeyDown, and it should check for isArrow.
The more obvious approach - manually jumping the right distance in onDocumentKeyDown and then doing preventDefault - isn't actually possible, because when you press (say) leftarrow, the correct cursor behaviour may in fact be to jump right, or even to some logically distant place, because of bidirectionality and bidi visual cursoring. We don't believe it's feasible to calculate and emulate this behaviour.
Change 247519 had a related patch set uploaded (by DLynch):
ce.Surface afterKeyDown to better cope with adjacent grouped nodes
Change 247519 merged by jenkins-bot:
ce.Surface afterKeyDown shouldn't assume .contenteditable is boolean