Bug: Scroll position gets lost in presentation mode

[jbridgy]

Context

Initially MM v2.8.9.15 is in non-presentation mode (may be named normal mode).
By default the non-presentation mode shows the editor and the internal HTML preview.
Essentially the presentation mode shows only the internal HTML preview.
The F11 key and the following button (in the title bar) toggle between non-presentation and presentation mode.

Bug

The current scroll position gets lost in presentation mode a few seconds after scrolling in a large document if the PreviewSyncMode is EditorAndPreview (default: EditorToPreview).

It seems that the preview is continuously synchronized with the editor although synchronization is needed only once when the presentation mode begins and should be suspended until the presentation mode ends.

The behavior can be reproduced with any document containing text for multiple screen pages.
Example:

1. Make sure that the Preview sync mode is Editor And Preview with button in lower right corner.
2. Open ...\Markdown Monster\SampleMarkdown.md with Help > Show Markdown Feature Sample Document.
3. Press F11.
4. Scroll down or up slowly until the scroll thumb makes an undesired leap. Usually this will happen after a few seconds.

Related minor issues

1. Sometimes it is not possible to enter the presentation mode when the external preview is shown ...
2. Leaving the presentation mode generally does not return exactly to the previous view state. Afterwards always the editor and the internal preview are shown (default view).

Related mini-feature request

It would be nice if the transition presentation mode --> normal mode could be achieved also by the Esc key which is the longstanding de facto standard for returning to the previous state (and is deeply burned into my muscle memory).

Motivation

I think the presentation mode is especially useful for proofreading when only a small monitor is available. So the external preview (preferably on a second monitor) is not practical or not applicable.
The competitor typora shines in this case because it allows you to edit in the presentation mode.

[RickStrahl]

Fixed.

Added explicit check for presentation mode, but also needed to check sync mode on every back scroll operation in the script code to detect state changes. This was also broken previously (ie. if you switched modes).

[RickStrahl]

I believe this fix also fixes #1020 as I can not longer duplicate that.

[jbridgy]

When you switch from default mode (editor and internal preview) to presentation mode (internal preview only) by F11 then the scroll position in the preview is synchronized. That is fine.
However when you switch back to normal mode by F11 (please make Esc work also) then the following happens with MM v2.8.10:

1. The scroll position of the internal preview is changed to the beginning of the document.
   It should be identical to the position in the presentation mode. After all it is still the internal preview.
2. The scroll position of the editor is unchanged.
   It should be synchronized with the internal preview (as it would have happened in default mode when PreviewSyncMode is EditorAndPreview).

The suggested symmetric synchronization would be practical for example when you want to proofread a long document. In this use case you switch to the presentation mode for the complete reader experience. As soon as you find some issue in your document you would like to fix it quickly with the editor, without needing to find the position again that was just shown in the presentation mode.

[RickStrahl]

Unfortunately there's only so much I can do with this. I've been playing around with this for a while today and I've made some progress here.

To recap what's actually happening:

The reason that the original issue of the preview jumping is cropping up, it's due to the fact that the editor - while active - is invisible and the WebView2 control that underlies stops accepting events consistently (or at all) while invisible. So the normal behavior is, that in sync mode when you navigate the preview, the editor navigates to keep in sync. What's happening now is that the editor line update is sent and while the code eventually runs it's either delayed or pointing at an incorrect location.

So I turned that off yesterday and that fixes the jumping problem but it introduces a whole new set of issues because now the two panes are not synced in any way and there's no easy way to trigger the editor to update from the preview manually (this usually fires off scroll events).

So I'm thinking of making a different change which is to make the editor not quite invisible but leave a tiniest sliver of the editor visible. This seems to fix the problem including having the editor come up near the preview scroll location when switching back.

Here's what that looks like:

I played with making this as small as possible but if the size is too small it starts behaving as if it's completely hidden with a 0 width.

It's certainly not perfect, but actually a big improvement over previous behavior in general as location is maintained (assuming sync is on).

[jbridgy]

Narrowing the editor to a hairline instead of making it invisible is a nice idea and would be good enough. However sometimes MM v2.8.11 hangs when you return to non-presentation mode. The problem seems to occur between restoring the editor to its normal width and refreshing its contents, that is, in the end you see a blank editor as in the following example:

Also note that SampleMarkdown.md is marked as modified (*). With this file it happens always when you return to non-presentation mode. So far I did not encounter this issue with my own files. Why is SampleMarkdown.md treated differently?

[RickStrahl]

Not sure I can't duplicate the lock up you describe. IAC I don't think think that's not directly related to the presentation mode switch but to editor activation. Please file a separate issue for that if it keeps occurring.

I must have switched between modes yesterday around 1000 times and I didn't run into any failures. I have seen that in other situations (usually when the app is idle for a long period of time and then reactivated and windows are activated) but even then that is rare. IAC. It needs a separate issue...

Closing this one