Last modified: 2014-02-28 23:04:49 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T50680, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 48680 - VisualEditor: Cursor position should account for padding in alien inline blocks
VisualEditor: Cursor position should account for padding in alien inline blocks
Status: ASSIGNED
Product: VisualEditor
Classification: Unclassified
ContentEditable (Other open bugs)
unspecified
All All
: Low minor
: ---
Assigned To: Editing team bugs – take if you're interested!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-21 13:56 UTC by Krinkle
Modified: 2014-02-28 23:04 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Screenshot of problem. (45.18 KB, image/png)
2013-05-21 13:56 UTC, Krinkle
Details

Description Krinkle 2013-05-21 13:56:00 UTC
Created attachment 12363 [details]
Screenshot of problem.

Steps to reproduce bug:
* Edit document with with <p>Hello '<code>world</code>'</p>
  ([[mw:Extension:Thanks#API_Documentation]] at this time)
* Place cursor at end of sentence and move cursor back
  with arrow keys one step at a time.

Expected:
When placed after the first ' before <code>world</code>,
it is blinking in the place new text would appear:

>        \/
> Hello '|{  world  }'

Actual:
It is visible inside and behind the <code>world</code> alien block.
The <code> block has some padding, and it is appearing in front of the "w" of "world" instead of after the first apostrophe:


>           \/
> Hello '{  |world  }'
Comment 1 Christian Williams 2013-05-22 23:59:44 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links