Preserve Webview Scroll Position

[mjbvz]

Fixes #22995

Bug
If you switch away from an editor that users a webview, the scroll position is currently not preserved. This effects our release notes and the markdown preview. The root cause is that the webview is disposed of when the view is hidden.

Fix
Add some presisted state to track scrollProgress through the webview. Use this state in the standard html editor and in the release notes.

TODO

• Make sure html preview handles case where content changes. I believe this should reset the scroll position
• Handle dragging editor tab to create duplicate view. This should also copy over the scroll position

[mention-bot]

@mjbvz, thanks for your PR! By analyzing the history of the files in this pull request, we identified @jrieken and @joaomoreno to be potential reviewers.

[joaomoreno]

Fixes #13256

[chrmarti]

@mjbvz The editor input can be used for multiple editors (e.g., through Split Editor). You probably want to store the scroll position separately from the input. See WalkThroughPart.load/saveTextEditorViewState() for a similar approach to what the BaseTextEditor and its subclasses do.

[mjbvz]

Thanks for taking a look @chrmarti. I think I was actually closer to that behavior with my first draft of the implementation (which used private member on HtmlEditor) but since I wasn't using mementos I ran into problems when splitting views. Moving the state to the input fixed this but as you noted, this also introduce some other weird behavior when multiple previews are active.

Let me try the memento based approach and see how that works

[chrmarti]

What makes it harder than expected is that editors and inputs are both reused. Editors are reused for inputs of the same type in the same editor column IIRC. Switching between editor tabs in the same column can trigger setInput() calls on a single editor with different inputs. So one editor can cover multiple editor tabs.

[mjbvz]

@chrmarti Thanks for the help. I prototyped the approach using mementos but I don't think it is correct here either, at least for the normal html preview. The scroll position should always be associated with the content, not just with the resource url. At present, we also do not want to restore the previous scroll position in an html preview after you restart VS Code

The approach that saved view state on the Input felt more correct to me when I was actually using it. The problem with it seems to be that the same input can be shared between editors in multiple panes however. Can we sit down together next week to discuss this more?

[mjbvz]

Ok, merging the initial memento based implementation as we discussed