Strange "jumpy" behavior in PR review text editor

[JulienPalard]

Description

On a PR, on the changed files view, if I hit the "+" to add a comment it pops a text editor, which behave strangely.

It does not happen with the same editor in the other places, like when typing an issue.

It looks to only happen when I use my Compose Key, or at least it's very more noticable when I use it.

It's very hard to describe so here's two videos of it:

In this first one I type "l'été" once per line, always typing the same keyboard keys: L ' Compose ' e t Compose ' e, I type it slower towards the end to show it does not happen when I type slowly. Maybe one of the errors may be me mis-typing, I admit, but not more than one, the other are produced by the editor.

Capture vidéo du 2023-03-26 21-55-08.webm

I do not use any arrow key, the left-right movement you see is the bug, not me moving the cursor.

On this one I focus on almost only typing é in a single line (after typing été once), always using the following keyboard hits: Compose ' e.

Capture vidéo du 2023-03-26 21-59-34.webm

Trying to describe it with words: the cursor jumps around what's I'm typing instead of staying at the end, so when I types, sometimes, a letter don't get "appended" but "inserted almost at the end", typically when typing été I could end up with tée.

Another good way to reproduce it is to type Compose > > as it's very easy to type quickly, it should produce » but when typed many times it produces, for example, »»»>»>>>»>>»»»»»>>»>>»>>»>>. Compose o o is a good reproducer too, maybe easier to type.

Typing the same sequence (Compose->->) in an issue correctly produces »»»»»»»»»»»»»»»»»».

The Compose key is very easy to enable on Gnome, from the Preferences → Keyboard settings panel. Without gnome, but still on Debian or Debian-based distros, it can be enabled using dpkg-reconfigure keyboard-configuration. On Windows there's no compose key, people have to learn each codepoint numbers, haha. On macOS I don't know.

Gitea Version

1.19.0

Can you reproduce the bug on the Gitea demo site?

Yes

Note: I use the compose key since a very long time (many years) and I never noticed this behavior in any other textarea (inside or outside of gitea).

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

Debian (both server and client).

Client is : Firefox 110.0.1 from Debian testing packages.

How are you running Gitea?

Using binary distrib, and reproduced in try.gitea.io.

Database

PostgreSQL

[wxiaoguang]

Will be resolved by https://github.com/go-gitea/gitea/issues/23290 fundamentally in 1.20

(I am working on it)

[silverwind]

CodeMirror may have some issues related to dead keys like the Compose key, this might be one of them. Will ultimately be fixed by moving to textarea.

[silverwind]

@JulienPalard try to reproduce on https://codemirror.net/5/ in the demo instance. If it does, report at https://github.com/codemirror/codemirror5. Chances are good that they'll fix it.

[JulienPalard]

Can't reproduce on the codemirror demo instance.

[wxiaoguang]

The official demo doesn't use "contenteditable". Gitea uses "contenteditable" to support spelling check. Another trade-off.

CodeMirror works well for code editing, but CodeMirror/EasyMDE doesn't seem suitable to be used as a comment editor.

---

As a workaround, you could try the "Revert to simple textarea" tool button, then you get a native editor.

[delvh]

Given that #23876 is merged, can this issue be closed now? I think we only depend on the browser native mechanisms now. Hence, this shouldn't occur anymore, right?

[silverwind]

Yes, we should close all EasyMDE related issues with https://github.com/go-gitea/gitea/pull/23876. I estimate there are 30-40 of them. See open issues linked to https://github.com/go-gitea/gitea/issues/10729 as a start.