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.
DetailsSubject Repo Branch Lines +/- Customize query in gerritRelated ObjectsEvent Timeline
Comment ActionsI 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).
Comment ActionsI 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.
Comment ActionsChange 247519 had a related patch set uploaded (by DLynch):
ce.Surface afterKeyDown to better cope with adjacent grouped nodes
Comment ActionsChange 247519 merged by jenkins-bot:
ce.Surface afterKeyDown shouldn't assume .contenteditable is boolean
Subject | Repo | Branch | Lines +/- | |
---|---|---|---|---|
Customize query in gerrit
Related Objects Event TimelineComment Actions 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). Comment Actions 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. Comment Actions Change 247519 had a related patch set uploaded (by DLynch): Comment Actions Change 247519 merged by jenkins-bot: |