@Koala0090: I am trying to replicate this phenomenon on zhwiki as well as on enwiki, but the cursor still follows the input and does not shift. I am using Chrome 83.0.4103.116 on macOS 10.15.5. If possible, please help retry this issue.

@VulpesVulpes825 Thanks for your reply.
It seems it works normally on English Wikipedia. However the proplem still remains on Chinese Wikipedia.

Test under:
Chrome: 83.0.4103.116, Windows 10

@Koala0090: I suspect this might be caused by one of the gadgets you used on zhwiki, as this issue does not exist on enwiki.

This is probably caused by some interaction of a gadget on zh.wp with our syntax highlighting feature. Your example has just plain text, so it's hard to tell, but this bug seems very similar to issues we saw with syntax highlighting in the past on other wikis.

We are not planning to work on this soon, sorry.

You can toggle the syntax highlighting feature in the menu as seen below, it would be helpful if you could check whether the issue occurs when it's turned off:

I am pretty sure I meet the same problem on French Wikipedia. This is indeed fixed disabling Syntax highlighting.

This seems related to page size and line size. I mean: the offset between actual text-typing position and visible cursor position seems to be higher when you are near the end of a big line near the end of a big page, than near the start of a short line in top of a page.

pre, .mw-code, .mw-highlight {
    line-break: anywhere;
    white-space: pre-wrap;
    word-break: break-all;
}

MediaWiki:Common.css&oldid=69058327#L-1275
This rule (particularly the line-break attr) in the site css mainly contributes to this problem.

Change 745877 had a related patch set uploaded (by Func; author: Func):

[mediawiki/extensions/CodeMirror@master] Set the line-break attr to initial

https://gerrit.wikimedia.org/r/745877

Test wiki created on Patch demo by Xiplus using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/beec768a59/w/

Change 745877 merged by jenkins-bot:

[mediawiki/extensions/CodeMirror@master] Set the line-break attr to initial

https://gerrit.wikimedia.org/r/745877

In T252965#7564935, @Func wrote:

This rule (particularly the line-break attr) in the site css mainly contributes to this problem.

I noticed that this task was created before the css rules existed. So this task maybe shouldn't be closed.

Thanks for the patch.

In T252965#7565683, @Func wrote:

I noticed that this task was created before the css rules existed. So this task maybe shouldn't be closed.

Thanks, I'll leave it open for now and wait for folks to confirm whether it works as expected or not.

The patch will be deployed to Chinese Wikipedia on Thursday, December 16, per the usual schedule (https://www.mediawiki.org/wiki/MediaWiki_1.38/Roadmap), so please test after that date.

I come out with a minimum repeatable case in my device, I load the edit page in safemode, so no site css or js can affect the output.

Then I merge some content into one span but keep other spans empty, the appearance now consistent with edit textarea.

I can repeat this using Chrome 96.0.4664.45 in windows 10, but not Firefox 95.0 (it's totally fine with this paragraph).
So I think there may have something wrong when rendering, which can depend on browsers.

Test wiki on Patch demo by Xiplus using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/beec768a59/w/

@Func has this issue been resolved?

@Func: Could you please answer the last comment? Thanks in advance!

I can still reproduce the case I found with Timeless skin and the latest Chrome in my laptop screen size, and I have more information to share now:
In the screenshot below, the 2em of padding was added to .CodeMirror by Timeless. We can see the edge of elements matching the selector .CodeMirror * is uneven, and somehow the position of line breaking was different compared to the edit area.

I also figured out the bug described in the task description.
CodeMirror would replace some continuous spaces with nbsp, see /src/line/line_data.js#L195.
Unfortunately, the width of nbsp can vary between fonts, and the default monospace font on Windows 10 is not exactly "monospace" at least when the system/browser/website language is set to Chinese.
Simple example:

{|
|foo ||  || bar
|}

As I mentioned, I believe the bug in the original report only affects CodeMirror 5.