Jumping to the wrong viewport position in live preview

Steps to reproduce

  1. Open sandbox vault and make sure the preview Live Preview mode is on.
  2. Close all the opened note
  3. open search pane
  4. search for /Diagram/
  5. from the search result, select(click) the searching result in the note “Format your notes”

Expected result

in the opened note pane, no matter whether the preview Live Preview mode is on or not, the note should jumps to the location where Diagram appears.

Actual result

in the opened note pane, when the preview mode is on, the note does not show the correct location where “Diagram” appears.


  • Operating system:
  • Debug info:
    Obsidian version: v0.15.9
    Installer version: v0.14.15
    Operating system: Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:22 PDT 2022; root:xnu-8020.121.3~4/RELEASE_X86_64 21.5.0
    Login status: logged in
    Catalyst license: supporter
    Insider build toggle: on
    Live preview: on
    Legacy editor: off
    Base theme: dark
    Community theme: none
    Snippets enabled: 0
    Restricted mode: on


Additional information

there are two workarounds:

  1. after the note “Format your notes” has appeared and the content in preview Live Preview mode has been rendered properly, click the search result again, it will bring you to the right place. This trick works for the search pane, but for the item in a query result, it is not feasible. This is because: by default, the new note will be opened in the same pane and there is no chance for the user to click the query result (which is in the previous note) for the 2nd time.

  2. turn off the preview Live Preview mode. It seems, with preview Live Preview mode is off, the jump is accomplished correctly in the first time. And interestingly, by follow step 1-5, when the note shows the “wrong” location, one can turn off preview Live Preview mode immediately rather than using the 1st workaround method above and see that the note is “now” shows the correct location where “Diagram” appears.

Bug and workaround-1:
Jul-29-2022 14-22-07

Bug and workaround-2(1):
Jul-29-2022 14-27-39

Bug and workaround-2(2):
Jul-29-2022 14-22-37


@WhiteNoise one question about the mark/tag on this post: what does “tracked” mean?

that I haven’t reproduced it yet.

What do you mean by preview mode? Live Preview or reader?

sorry for the ambiguity.

it is in Live Preview mode.

this might be related to this feature request: Feature request: wait for all plugins to finish rendering the page before following header links

Yes, the two problems are connected to the elastic effect introduced by LP rendering.

When navigating with back and forward (the ‘Go back’ and ‘Go forward’ feature), Obsidian very often doesn’t go back to the correct previous view of the note.

Instead Obsidian:

  • Jumps back to the start of the note.
  • Jumps back to the location of the typing cursor.
  • Or, most often, jumps back to a random location in the note.

The longer the note, the worse Obsidian is in going back to the previous view.

Often, the backward navigation jumps to where the actual previous view is entirely outside the viewport. This requires scrolling up and down the note to find the previous location.

Steps to reproduce

  1. Press F1 and open the Sandbox vault.
  2. In the File Explorer, open the existing ‘Create a vault’ note.
  3. Copy that note’s content and append it to the note’s end to make the note longer. (With longer notes, the issues is easier to reproduce.)
  4. Type something somewhere in the note. This to make it easier to find the previous view location back after navigating.
  5. Click a link in the note.
  6. Click the ‘Go back’ icon in Obsidian’s title bar.
  7. Obsidian now jumps back to the wrong location.

A video recording of these steps is here: video.

Expected result

I expect Obsidian to go to my previous view. Otherwise I might as well follow links bidirectional links inside notes.

The current behaviour has me constantly re-scan the note to find my previous position. This is exhausting and a waste of time.

Sometimes I cannot find my previous position, which breaks a line of thought in the process.

Actual result

(See description and video recording above.)


Obsidian version: v0.15.2
Installer version: v0.13.31
Operating system: Windows 10 Home 10.0.19044
Login status: logged in
Catalyst license: supporter
Insider build toggle: off
Live preview: on
Legacy editor: off
Base theme: dark
Community theme: none
Snippets enabled: 0
Safe mode: on
Commercial license: yes
Computer hardware: Intel i5-10400 CPU (6 cores, 12 threads) @ 2.9Ghz with 24GB RAM and a 500GB SSD drive.

1 Like


1 Like

After Pasting big chucks chunks of text the pane is not scrolled to the right position


  1. Help vault > Format your notes
  2. Copy whole note
  3. Paste it a the end.


In case anyone is searching for “chunks of text” you might want to edit the title (typo I assume)

unless you meant this Chuck…


lol, thanks

If you switch from reading view to editing view in a note, the document scrolls up rather than staying in place as expected. If you switch back to reading view, the document will be in the right place, and then any subsequent switches will work properly. If you exit the note or go to another note, this fixed state resets. This happens on a fresh vault and on any note.

I’ve tested each scenario with both the new and legacy editor and recorded videos as well. Also, it doesn’t matter if the editing mode is Source or Live Preview, the behavior is the same.

New Editor:
Reading → Editing - Document jumps | Video
Editing → Reading - No issue

The behavior when using the legacy editor is a bit different.

Legacy Editor:
Reading → Editing - Document jumps, but not as much compared to the new editor | Video
Editing → Reading - No issue
Editing → Reading → Editing - No issue on first switch, but then document jumps a tiny bit on the second | Video

Debug info:
Obsidian version: v0.13.23
Installer version: v0.13.23
Operating system: Windows 10 Pro 10.0.22000
Login status: not logged in
Insider build toggle: off
Live preview: off
Legacy editor: off
Base theme: dark
Community theme: none
Snippets enabled: 0
Safe mode: on



1 Like

I am finding this an issue too. The jumping is quite disruptive when you are looking for a line n a longer note and find that you have to make some edits to it. You currently lose yourself when switching ose and have to scroll back and forth to find the line you were on, both ways. This takes time.

It would be great if the vertical position of the notes on screen could be fixed whatever other parameters are changing (e.g whether embedded images are rendered or not, other panes are open or not etc.)

I’m surprised that this problem wasn’t fixed quickly. It’s the kind of detail that will infuriate any user. I’m a college teacher, and I love to advise my students on the tools I use myself. Obsidian is a find that I was very proud of. The students thanked me for Obsidian and imovie for windows, and I haven’t been able to get them excited about anything else yet. But the problem with editing files annoys them all. I could offer them a quest and refuse to edit, but then I risk ruining my reputation, haha.

Yeah, still an issue for me on v0.15.6.

Yup, also annoying on PopOS, since at least Obsidian 0.14.15 thru 0.15.6. I wonder if there is any connection to this unsolved search/scroll bug.

This is indeed still an issue. On 1.1.9 it happens both in ‘Source mode’ view and in ‘Live Preview’.

Especially when the note is long, then navigating back/forward is almost guaranteed to bring the viewport back at a wrong location.

(Of course when the note is very short, this issue doesn’t happen since the full note is in the viewport.)

Yes, I run into variants of this every day (working on 100k-200k word notes). A common one is clicking sections in the outliner - sometimes the editor window (source mode) jumps to a position that’s close to the target section, but still 1-2 screens off in either direction. Clicking the section a second time in the outliner usually works. I just cope with it because of Obsidian’s other merits, but it is a constant low-level issue. Would be a big QoL improvement.

@Sentiment source mode should not have this problem (or it should be much much less). Open a different bug report and follow the bug report template.