-
Notifications
You must be signed in to change notification settings - Fork 29.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Markdown Preview pane Scrolling Unhelpfully #143984
Comments
Just in case it's not clear from the video, here's a textual description of the issues:
Both of these are unhelpful, and both of these aren't broken (work properly) when you don't use any markdown-preview-styling extensions. |
I can confirm issue still present in VSCode version 1.65.1. |
I just realized there's a setting that I use that may be contributing to this issue: "editor.scrollBeyondLastLine": false I prefer this setting because its what I'm used to, coming from other code editors in the past. This setting is why "scrolling to the bottom" is such a concretely-defined thing for me. I'm sorry I didn't mention it earlier. |
Does this reproduce in the latest VS Code insiders build with all extensions disabled? If so, can you please share a markdown file and steps I can use to reproduce this issue |
Why would I test this with all extensions disabled? |
Please test with insider too and provide steps to reproduce the problem |
Okay, so I just re-tested this in the latest Insiders build. The bug is still present. Here's my version information:
Here are the instructions for recreating the bug:
|
Bug still present. Current version information:
|
Bug still present. Current version information:
|
I'm experiencing similar bug (with all extensions disabled), but a lot worse than what's in the video. The scrolling of the preview pane jumps like insane. This only happens since about a month ago.
By the way, translate "Electron" to "電子" is really stupid here. |
Bug still present. Current version information:
|
Getting the same bug here:
Somewhat annoying 😞 |
I'm experiencing scroll issues when I have this setting enabled: {
"editor.stickyScroll.enabled": true
} With scoped sticky scrolling disabled, the problem goes away. It would be nice to have the markdown preview pane not be interrupted by nested markdown headings that appear sticky in the editor. |
Does this issue occur when all extensions are disabled?: No, but I don't think the extension is at at fault. Please read the rest of the story.
So here's what happened. I began working last week on a new pet project, a silly idea for an esoteric programming language. Before I develop an interpreter around my ideas, I thought I'd lay my ideas out in full by writing out the documentation on how the project will function once it's completed.
I'm writing out my ideas in Markdown, intended for easy reading in the GitHub repo for my project. Because GitHub is the only site I ever write Markdown for as of now, I installed an extension that restyles my Markdown preview pane to GitHub's dark mode styling: Dark Github Markdown Preview.
While writing, I noticed some strange behavior in the preview pane related to scrolling. For ease of description, I used OBS to record a video of my findings:
I'm not completely sure, but I think this may actually be a VSCode issue, not an issue with the extension. You see, when I disable this extension and return the preview pane to it's default, built-in styling, these issues disappear. When I took a look at the repo for this extension, though, it seemed to be just a
.css
reskin. Unless I'm a dunce and I missed something significant, there isn't really much code in this extension, and therefore the faulty scrolling would be the fault of VSCode, where the scrolling code exists.My theory is that the scrolling code (both scrolling the preview pane when the source pane is scrolled, and scrolling the preview pane to the currently-updated spot when you type in the source pane) inside VSCode doesn't take into account the possibility that the preview pane could be restyled to different fonts, spacings, or styles. Maybe the auto-scrolling code operates based on hardcoded values for font-sizing/spacing/line-height rather than the actual size of the text as displayed, taking into account user-installed style modifications?
The text was updated successfully, but these errors were encountered: