Implement fallback of scroll stabilizer to reduce scroll jumping while editing #251
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For keeping extension sustainabillity, Marp for VS Code has not any scroll-sync logic and relies to VS Code's built-in preview script. Scroll sync is working correctly in almost cases, but sometimes the preview pane brings unexpected scroll when updated webview by editing.
When updating preview, VS Code is trying to restore the previous scroll position by calling
scrollTo
on loading. A timing of execution this script is same as other extensions contributed scripts included Marp. However, they will run in unpredictable order because they are injected through<script async>
. If VS Code ran built-in initialization script before Marp's preview script, a calculated scroll position for stabilization would be wrong due to its styles are based on what have not applied Marp specific styles. On the other hand, the built-in scroll stabilization will work to Marp slides perfectly if ran Marp preview script before built-in script. This is reason why user occasionally see to unexpected scroll.This PR implemented a fallback logic of scroll stabilizer to reduce scroll jumping while editing. It does not always apply the updated scroll position. If built-in preview script has not run on running Marp script, the scroll position will override with the built-in logic. And the fallback will be disabled temporally if changed the number of pages.
It would not resolve #248 completely, but can reduce furastrating jumps while editing text. It might be related to #173 too.