#1

Steps to reproduce

Create a document in Obsidian. Start typing somewhere in the middle of a long line at a rapid pace.

Expected result

All characters show up where they are typed.

Actual result

At some point, while typing, the cursor randomly jumps to the end of the current line and the characters are subsequently entered there.

Environment

  • Operating system: MacOS 11.0.1. This issue also existed on 10.14 and 10.15.
  • Obsidian version: Obsidian v0.10.7. This issue has existed since at least version 0.9.1.

Additional information

This issue occurs both with vim key bindings enabled and disabled. This is NOT limited to entering visible text. In vi input mode, the random cursor jumping also occurs when entering control characters, e.g. hitting the ‘.’ key to repeat the last action. If I want to delete 5 words, I might type ‘dw…’, but after (for example) the second ‘.’, the cursor jumps to the end of the line, so the third and fourth ‘.’ remove a blank line and the first word of the next line.

It seems like some documents are more prone to exhibiting this issue than others. The longer the document, the more likely the issue is to manifest. I seldom to never see this with short documents. During heavy editing of documents of several thousands words or more, I may see the issue occur several times a minute. When typing slowly, the issue seldom to never occurs.

#2

I can’t reproduce.

Grab a fresh installer from the website and reinstall obsidian.

If it still happens, post a screen recording. Also, remember to reproduce with default css and no third party plugins.

If say it happens without vim mode, then post the screen recording without vim mode enabled.

Does it happen if you don’t have any sync/backup system running on your system?

#3

I don’t use third party plugins or custom CSS.

I will see if I can reproduce the issue on demand.

#4

Interestingly I have been unable to reproduce this issue in v0.10.9. There are two possibilities: 1) the issue was somehow resolved in 0.10.8 or 0.10.9, or 2) the issue manifests itself after Obsidian has been running for some amount of time. I will continue to test with this version and see if the issue presents itself again.

#5

I still have not been able to reproduce the original behavior, but a related behavior (that I forgot to mention) is still manifesting itself in v0.10.13.

The problem: After heavy editing of a moderately-sized document (and the document size may not have any bearing on the bug, but might be a natural consequence of a lot of writing and editing), Obsidian will start to have cursor control problems.

In vi mode, the following happens (cursor position indicated by a caret ^).

Suppose I have the sentence:
This is a sentence illustrating the bug.

If I hit ‘0’ (beginning of line), the cursor position looks like this:
^This is a sentence illustrating the bug.

If I hit $ (end of line), the cursor position looks like this:
This is a sentence illustrating ^the bug.

If I start at the beginning of the line, and hit ‘l’ (move cursor right), the cursor sequence looks something like this (I’m omitting some positions for clarity and conciseness):

This is a sentence illustrating the ^bug.
This is a sentence illustrating the b^ug.
This is a sentence illustrating the bu^g.
This is a sentence illustrating the bug^.
This is a sentence illustrating ^the bug.

In other words, the cursor will advance to the end of the line, but then hitting ‘l’ one more time causes the cursor to jump to the middle of the line somewhere (the position is always the same for a given line).

I tried to do a screen capture of this (in MacOS), but somehow in the process of starting the screen capture and going back to Obsidian to reproduce the behavior, it stopped happening.

Nonetheless, this behavior occurs interchangeably (but unpredictably) with the original cursor jumping bug associated with this bug report.

#6

I should note that I have never seen either issue manifest until I’ve made literally thousands of edits over hours of editing and writing, which makes reproducing the issue difficult.

#7

@WhiteNoise The bug graveyard seems appropriate at this time. I have not seen the issue even once since v0.11.