microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
163.05k stars 28.8k forks source link

markdown files preview does not save scroll position #63690

Closed AbdullahWali closed 2 years ago

AbdullahWali commented 5 years ago

Issue Type: Bug

  1. Open markdown file preview
  2. scroll down
  3. switch tabs and then come back to the markdown tab => Scroll position is reset to top

VS Code version: Code 1.28.2 (7f3ce96ff4729c91352ae6def877e59c561f4850, 2018-10-17T00:23:51.859Z) OS version: Windows_NT x64 10.0.17134

System Info |Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (8 x 1992)| |GPU Status|2d_canvas: enabled
checker_imaging: disabled_off
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
native_gpu_memory_buffers: disabled_software
rasterization: enabled
video_decode: enabled
video_encode: enabled
webgl: enabled
webgl2: enabled| |Memory (System)|15.86GB (7.51GB free)| |Process Argv|| |Screen Reader|no| |VM|0%|
Extensions (4) Extension|Author (truncated)|Version ---|---|--- rdetools|Blo|0.1.10 sftp|lix|1.7.7 python|ms-|2018.10.1 cpptools|ms-|0.20.1
vscodebot[bot] commented 5 years ago

(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

skprabhanjan commented 5 years ago

@mjbvz , looking into this :)

skprabhanjan commented 5 years ago

@AbdullahWali and @mjbvz , It seems to retain the scroll position when i am trying. I am not able to reproduce this bug. Could you please help me more with this ?

mjbvz commented 5 years ago

@AbdullahWali Can you please share a markdown file that has this issue

Robhox commented 5 years ago

I could reproduce the bug with any md file (on macOS and windows). The scroll position is not saved for the Mardown Preview (which you can get by pressing ⇧⌘V or Ctrl+Shift+V in a md file). The side-by-side preview is working fine.

I'm looking at this issue right now to fix it

skprabhanjan commented 5 years ago

@Robhox , Thanks for the update. Are you looking into this or should I continue solving this ?

Robhox commented 5 years ago

@skprabhanjan I'm already looking into it and would love to solve it if it's ok for you

skprabhanjan commented 5 years ago

@Robhox , sure go ahead , seems like your first contribution , so will leave this to you :)

Robhox commented 5 years ago

@skprabhanjan Did you had any ideas how to fix this issue? I'm struggling to find where the position is saved when you switch tabs.

skprabhanjan commented 5 years ago

@Robhox , Need to check it , Will get back to you after checking it :)

warpdesign commented 5 years ago

Also, the markdown preview seems to be reloaded/regenerated when the user switches back to a preview tab, so during ~800ms there's a blank area which I find quite annoying too.

IgorKrupenja commented 5 years ago

Reproducible on 1.38.1, sample file inside ZIP: Untitled-1.md.zip

murphyke commented 4 years ago

This is another variation of the same situation: if you open a side-by-side preview, then open another tab in the preview sub-window, then switch back to the preview tab, the scroll position in the preview will have been lost.

thadras commented 4 years ago

Want to report that this issue seems to reproduce for the case of using the following experimental setting as found via issue #84520:

"workbench.experimental.editorAssociations": [
    {
        "viewType": "vscode.markdown.preview.editor",
        "filenamePattern": "*.md"
    }
]

Whereby, I find it convenient to be able to open md files within the preview context. However, it appears that doing so somehow interferes with the applications scroll state when switching between tabs. As such, the file's preview tab will lose its scroll position when navigating away from and returning to the md file.

Note, I have built the VSCode application from the latest git, and out-of-box the issue does not reproduce without the experimental setting. Hence, it seems that using preview viewtype as default for md files contributes to the loss of scroll position when switching between tasks.

Given the help wanted label, I am reviewing the vscode in hopes of gaining a better understanding of the internals, but the learning curve will take some effort to surmount.

devuxer commented 4 years ago

I've had this problem with VSCode as long as I can remember. I just installed version 1.44.0 on my Thinkpad, and it's still definitely happening. As I read through the release notes, I like to try out the new features as I read. With a document this long, it definitely causes some frustration having to keep finding my place again after each try. Hoping someone can figure out what's causing this 🙏

n-p-e commented 4 years ago

The extension descriptions page (extension sidebar -> click on any extension that has a long description) has a similar issue. The page seems to reload when switching to another tab and switching back, resetting the scroll position.

Edit: Running VSCode 1.44.2 on the latest Windows (10.0.18363).

Screenshot_2020-04-18_22-22-03

gjsjohnmurray commented 4 years ago

See also #27498

leosdad commented 3 years ago

This is very annoying and distracting especially when there is a new VS Code release, the descriptions are very long. So I'll try any new feature and when I go back to the release notes are reloads from the top and I have to scroll down again.

Please take a look at it whenever possible.

DavidMGini commented 3 years ago

Ping This is still annoying

mjbvz commented 2 years ago

Closing as the original issue about the markdown preview has been fixed for a while now:

recording

If there's a specific file / scenario where it isn't working properly, please open a new issue with steps to reproduce

leosdad commented 2 years ago

Hi @mjbvz,

Thanks for the feedback. However I'm not sure why it was closed, VS Code release notes still do not retain the scroll position. Instead they jump to a random point each time they get the focus back, while the scroll bar goes crazy. IMHO this is even worse than the previous situation when at least the wrong position was predictable (i.e. the start of the page) :)

2021-10-07_09-40-26

Best regards,