Page MenuHomePhabricator

VisualEditor: Cursor position does not match point of insertion (when inline annotation has padding)
Open, LowPublic

Description

Steps to reproduce bug:

  • Edit a page and add the following content: Hello "<code>world</code>".
  • Place cursor before the first quote, then use the arrow keys to move right (after the quote, before W for world).
  • Insert a character.

Expected:

The place where the character appears, and the position of the blinking cursor should be the same. In actually, this is not the case.

The cursor is blinking inside the code annotation (close to the W, within the padded area of the code block).

The added character appeared outside the code annotation (close to the quote, outside the padded area of the code block).

Screenshot of problem (from May 2013):

Screen_Shot_2013-05-21_at_3.48.57_PM.png (320×846 px, 45 KB)

Video capture (July 2018):

Details

Reference
bz48680

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:21 AM
bzimport set Reference to bz48680.

orbit wrote:

Yeah, this is reproducible. No adjustment to margin or padding of the alien (the code element) is able to fix this issue though. We're using native browser selection rendering, and this is a side-effect.

One possible future fix would be to allow the cursor to be placed at the first and last offset of protected nodes (contenteditable would have to be set to true) to give the desired cursor rendering. Any keypress would have to first fixup the selection.

I think this is likely a minor occurrence and making such a dramatic change to protectedNodes is out-of-scope for now.

Krinkle renamed this task from VisualEditor: Cursor position should account for padding in alien inline blocks to VisualEditor: Cursor position should account for padding on inline annotations.Jul 6 2018, 7:43 PM
Krinkle renamed this task from VisualEditor: Cursor position should account for padding on inline annotations to VisualEditor: Cursor position does not match point of insertion (when inline annotation has padding).
Krinkle updated the task description. (Show Details)

Back in 2013, a similar issue exited with links and their labels. Both issues were cause due to a limitation that exists in browsers by default (there is only 1 logical position, and where it happens to be is browser-dependent).

However, the link annotation issue has since been fixed by the introduction of virtual positions within the VisualEditor surface to decide whether the user is inside or outside a node. Perhaps the same could be applied to the code annotation?