#1

(updated title to more accurately reflect findings after additional troubleshooting, see further down in the thread for more accurate description of behavior)

Original bug report follows this line

Steps to reproduce

While working in a long note (Note A) in edit mode, use Cmd+Shift+Click to open a link to Note B in a new pane.

Expected result

Note B opens in the new pane and the cursor position in the still-open Note A does not change.

Actual result

Note B opens correctly, but the cursor in Note A moves to the end of Note A or to the beginning of Note A.

This behavior is not consistent. Currently while working in a note (Note A) it is happening each time I Cmd+Shift+Click a link in edit mode, and each time it is moving the cursor to the end of Note A immediately after opening Note B in the new pane. A few days ago while working in another long note the cursor would move to the top of the note.

When the cursor moves it scrolls the screen to the top/bottom and I have to scroll back to my original position. This is frustrating when working with multiple notes from an outline for example.

Again, this doesn’t happen all the time, but seems to happen more often than not on longer notes. The current note is 2,227 words.

Environment

  • Operating system: MacOS 10.15.7
  • Obsidian version: Obsidian 0.11.0

Additional information

2 Likes
Location of the preview panel jumps back to the beginning of the page
Editing with Split View causes unwanted scroll
When toggling between preview and edit mode the page goes back to the top
Internal note link to heading / block reference jumps back to top of page
#2

I can’t repro. post a screen recording with no css and no third party plugins

#3

I disabled all plugins and CSS and went through them one at a time and I think I found the culprit.

It’s in the bullet point relationship lines CSS tweak: GitHub - kmaasrud/awesome-obsidian: 🕶️ Awesome stuff for Obsidian

Specifically in this declaration in the CSS snippet:

.cm-hmd-list-indent .cm-tab, ul ul { position: relative; }

When I comment that one line out the behavior returns to normal.

However… When I turn the Minimal theme back on the behavior then goes back to the buggy behavior described above, even with the above CSS snippet line commented out. Turning Minimal theme back off returns to the expected correct behavior.

Clearly there is some sort of interplay between styles happening here but I don’t know how a CSS style could so drastically alter the scroll position of the preview window when it is rendered.

cc: @kepano

#4

Even weirder… I just stumbled onto the fact that toggling between edit and preview modes changes behavior depending on whether or not there is a heading (#) at or near the top line. If there is an h1 or h2 (and maybe others) on the top line or within 2-4 lines of the top line it toggles to the correct location (i.e. doesn’t scroll to the top of the file when toggling preview mode on). But if I scroll just one more line (so the heading is now 5 lines from the top) and then toggle preview mode then the preview mode renders as if I was looking at the start of the file, effectively scrolling all the way to the top. Then when I toggle back to edit mode it jumps right back to the position I was in.

This turned out not to be consistent either. See below.

#5

I made a screen recording: https://drive.google.com/file/d/1oAnn0Eq8A3aIzMCvV0ONrGOyP843VvTK/view?usp=sharing

This is two minutes long because I wanted to scroll around and trigger the behavior in multiple areas within the document.

What I found is that it appears even more random than I previously thought, since in this case I found instances where even with a heading at the top it still jumped to a random position higher in the doc when toggling preview mode.

In the recording I made the scrollbar large and yellow so it is more obvious what is happening.

#6

@WhiteNoise You moved this to the bug graveyard shortly after I replied with a detailed screencast confirming the bug. What happened?

#7

the screencast is not using default theme an no plugins. We don’t provide support in those cases.

#8

@WhiteNoise Got it, my bad I had found the problem with everything deactivated but had reactivated some during my experiments just prior to that screencast.

Here is a new recording. All plugins and custom CSS are disabled, and the theme is set to None.

The behavior still occurs. I walk through it step by step in the recording, showing the CSS snippet and turning it on and off during the recording showing the difference in behavior.

Note the behavior varies depending on where the scroll position is. I discovered while making the screencasts that once a sub-bullet is the top-most line in edit mode, triggering preview mode causes it to jump immediately to the top of the document when the preview is rendered, then back when edit mode is triggered again. This may not be the only time it occurs but it was the most dramatic so I used it for the screencast. Note also that the movement varies in some cases even when the scroll is changed only by a tiny amount. (one click turn of my mouse scroll wheel)

Also apologies for being a bit rambling in my prior posts, this is just an extremely frustrating bug because it was occurring seemingly at random, and I still don’t know if there are other cases where it may occur. :frowning:

https://drive.google.com/file/d/1NcEJ1Ambhgh8X7Kkd90y-7w5EwHz_xz5/view?usp=sharing

#9

ok since this is something that appears with a custom css, is this a bug?

#10

I would think so since your app supports custom CSS and I’m not aware of any particular guidance stating what custom CSS to avoid.

If we are expected to avoid certain CSS due to behavior conflicts with your app we should be told which ones to avoid and why.

Do you have any such guidance? I may have missed it.

#11

I just checked and confirmed there is a line in the Minimal theme (line 1681) that causes the same behavior.

body.minimal-rel-preview .markdown-preview-view ul ul {
  position:relative;
}

It is triggered the same way – scroll far down the doc and place a sub-bullet on the top line then trigger preview mode causes Obsidian to render preview mode at the top of the doc instead of in the expected position, exactly as shown in the screencast.

This is why it was still being activated when I had the Minimal theme in place in the first screencast.

#12

Another finding: bug also occurs if a quoted line is at the top of the pane when triggering preview mode.

For example, toggling preview mode when the top of the pane looks like this works as expected:

image

However scrolling down just a couple of clicks on the mouse wheel to this point results in the bug being triggered when toggling preview mode: (yes this is a very subtle difference, look at the spacing between the title and first displayed line)

image

#13

Good sleuthing @davecan, I was experiencing the same issue and this post helped me figure out that it was caused by position: relative; in my custom CSS.

#14

I believe this is closely related (or identical) to Internal note link to heading / block reference jumps back to top of page

#15

I have a similar problem. I tend to read my long notes along with a linked preview pane. And they are almost never in sync (they are perfectly synced only in case of short note [read 20 lines]).

The preview pane shifts back to the top of the page while I am scrolling the edit window. And I need to manually scroll preview window back to the line I was reading/editing.

And it happens all the time when its a long note (might have images too) with or without plugins/themes. I am at version 0.12.5

I am not sure if I need to open a new bug request here (@WhiteNoise).

@davecan and @luckman212, can you please check if you face the same thing (edit and preview windows split)?

#16

@DummyME? It happens all the time? This bug report is limited to some triggers. Open a new bug report and post screen recordings? No themes, no css and no third party plugins.

#17

Yes. I can confirm this. All the time with long notes. In short notes it doesnt even matter, so.

EDIT: I forgot to turn off a few snippets.
It works fine when turned them off. My bad.

For the record, I had a snippet for Outliners from the forum, which is causing the problems.

On Discord, @SlRvb gave an alternative and a fix for existing css.

  • The Fix

    ul ul,
ol ol {
     padding-inline-start: 40px;
     margin-left: -15px;
     border-left: 2px solid var(--interactive-accent);
 }

  • The alternative:

    li {
      padding-left: 5px;
      border-left: 2px solid var(--interactive-accent);
}

li:nth-child(even) {
      border-left: 2px solid var(--text-muted);
}
#18

Let me know if you still have this issue with version 0.13

#19

Same issue
Installer Version: 0.12.10
Current Version: 13.23

Only happens when i horizontally split a pane. When I open the second one, it resets the first one, when i close the second pane, it again resets the first one lol.

#20

@xidl I think it’s better you open a new report and attach a screen recording of this happening in the help vault.