Skip to content
This repository has been archived by the owner on Jun 2, 2022. It is now read-only.

Live Preview Scroll Position Resets With Changes #3

Open
dbarsamian opened this issue Sep 9, 2021 · 3 comments
Open

Live Preview Scroll Position Resets With Changes #3

dbarsamian opened this issue Sep 9, 2021 · 3 comments
Labels
bug Something isn't working

Comments

@dbarsamian
Copy link
Owner

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 dbarsamian added the bug Something isn't working label Sep 9, 2021
@dbarsamian
Copy link
Owner Author

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 added a commit that referenced this issue Jan 6, 2022
- Fixed issue #3 by evaluating some JavaScript at key points during WKWebView's navigation lifecycle. See WebView.swift for the implementation.
@dbarsamian
Copy link
Owner Author

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
Copy link
Owner Author

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

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant