Live Preview Scroll Position Resets With Changes

[dbarsamian]

Describe the bug
When a document is edited and overflows past the length of the window, the live preview does not maintain the same scroll position as the editor window, resulting in the preview not displaying the portion of the document being edited.

To Reproduce
Steps to reproduce the behavior:

1. Open a new or existing document.
2. Edit the document until it exceeds the length of the window.
3. Scroll both the editor and live preview to the bottom of the document.
4. Add new content in the editor

Expected behavior
The live preview should display the changes being made.

Screenshots

(Note the position of the scrollbar in the right-hand preview.)

Screen.Recording.2021-09-08.at.8.38.44.PM.mov

Device (please complete the following information):

• OS: macOS Monterey 12.0 Beta 21A5506j
• As of commit fdbdf9e

[dbarsamian]

This appears to be an issue with using a WKWebView inside an NSViewRepresentable, which rules out using a web view for the live preview. As an alternative, I'm testing MarkdownUI for the live preview. The largest hurdle is that MarkdownUI conforms to the CommonMark Spec, which does not include strikethrough syntax.

Commit 97a7966 implements this, and I'll continue to test this to see if it's a viable alternative or if another solution is needed.

[dbarsamian]

As mentioned in commit fe718e5, I found a (buggy) way to fix my persistent scrolling issue. I describe how I implemented this in the source's documentation, but as a short summary:

• When the WebView's navigation delegate detects a navigation action, evaluate it.
• If it's valid (i.e. not navigating outside the app) then evaluate some JavaScript to capture the current scroll position.
• When the navigation delegate says the web view has finished loading, evaluate some JavaScript to restore that captured scroll position.

This results in almost perfectly functional scroll restoration. I say "almost" because it isn't without bugs, which is why I'm leaving this issue open for now. If the user types too fast, or the JavaScript takes longer than expected to evaluate for some reason, then the live preview will briefly appear at the top of the document for a frame or two, then snap to the correct scroll position. If the user types fast enough, the live preview may go back to the top without resetting, since the view updates every time the document is updated.

Since I want to keep working on other parts of this app and get it in people's hands, I'm going to just accept this solution for now. In the edge cases I outlined then the live preview won't act as expected, but as far as I can tell, this is the only solution that get's around WKWebView's limitations on macOS native. (If I had made this a Catalyst app, then I could have used the UIKit version of WKWebView, which has a reference to a scrollView. 🙄)

[dbarsamian]

See video below for example of the feature/bug in action:

Screen.Recording.2022-01-06.at.2.48.23.AM.mov