Markdown preview auto-scrolls unnecessarily when space exists to display the entire preview

[axefrog]

• VSCode Version: 1.20.1
• OS Version: Windows 10

When navigating to different points in my markdown document, I'm seeing that the preview will scroll down to the focused block even though the entire preview can fit in the viewport with plenty of space to spare. It seems like it's trying to anchor the focused point to a position that is roughly at a 20% distance from the top of the preview viewport, and in doing so, not considering whether the available space makes this unnecessary.

I do like the way the automatic scrolling makes sure the focused block is roughly at a 20% distance from the edge of the viewport so that you have the context of the text above and below it, but this should not happen if all of the preview content will fit in the viewport.

It should also happen relative to the direction being scrolled, not just relative to the top of the viewport. i.e. If scrolling down, bring the bottom of the selected block to a 20% distance from the bottom of the viewport, while being careful to clamp the scroll position for very large blocks so that the top of the block is not pushed further up than the current 20% distance from the top of the viewport.

Steps to Reproduce:

1. Make sure you have lots of vertical space (my screen is 1600px high)
2. Open the markdown preview in a column to the right of the markdown code
3. Create a document with a number of headings, subheadings and bullet points - enough to generate a preview that occupies one half to two thirds of the available vertical space
4. Click on some of the lower bullet points to have the preview focus the associated block of preview text
5. Notice that the editor scrolls down to "center" the focused block, even though the entire preview is able to fit in the available space, with the "center" being only about 20% from the top of the view.

Does this issue occur when all extensions are disabled?: Yes

My suggestions:

• Don't scroll if the entire preview fits in the viewport
• When automatically scrolling down, focus the current block so that its lower bound is at a distance relative to the bottom of the viewport, rather than the top, but limiting the behaviour so that the top of the block does not exceed the current 20% distance from the top of the viewport (seeing as we read from the start of the block, not the end).
• When automatically scrolling up, the current behaviour works well.

[mjbvz]

Thanks for the report.

Yes the current 'click to jump back to editor' functionality is specifically designed to position the clicked element near the top of the screen. This position is always the same because it makes it easy to find which editor line corresponds to the element you just clicked on. I prototype doing minimal scrolling instead but found this to be a very confusing experience

I'm actually in favor of removing the double click functionality entirely once #19459 is supported. The double click stuff was sort of a workaround for that issue. Hopefully some new APIs will make it possible this iteration or next

[axefrog]

Yes the current 'click to jump back to editor' functionality is specifically designed to position the clicked element near the top of the screen.

@mattbierner I wasn't reporting about this, and I don't even use that feature. Might be worth re-reading what I wrote. Everything I described above related to the behaviour that occurs when focused on the editor, and how it triggers unnecessary and unintuitive scrolling in the preview.

TL;DR:

I want to see as much of the preview as possible when I make changes, and the fact that when I click/focus text at the bottom of my markdown code it scrolls the preview all the way up to the top, obscuring most of the preview when there is ample space to display it all, is really annoying and renders the preview somewhat unusable for ongoing editing of short documents - all I want is to see a preview of my document as I edit it. If the preview only shows me the last tiny bit of the document, I may as well not have a preview.

[mjbvz]

Sorry I thought you were talking about clicking in the preview in your repo steps. However it's the exact same argument and I believe that #19459 is still a better experience to aim for

Right now, we scroll the markdown preview based on your editor selection. This is a hack because we don't have an API for getting the editor's viewport. #19459 tracks full scroll sync between the editor viewport and the preview viewport, which would eliminate the unnecessary scrolling you reported . The api for implementing this is even on our February iteration plan (see Provide API that hints at the top most visible line in the editor)