markdown: fix scroll sync regressions introduced in #287050

[AshtonYoon]

Fixes #307762

Bug 1: Editor jumps when scrolling the preview (preview.ts)

The merge retained this.#isScrolling = false inside the early-return guard of scrollTo(), which the original PR intentionally removed. This resets the timer on the first call, letting subsequent editor scroll events re-trigger forward sync while reverse sync is still in progress.

 if (this.#isScrolling) {
-    this.#isScrolling = false;
     return;
 }

Bug 2: Preview → editor sync requires editor to be scrolled first (index.ts)

The PR switched onUpdateView to a timer-based reset but left initialization and resize handlers still using scrollDisabledCount += 1 with no timer. Since the scroll handler no longer decrements, scrollDisabledCount stays at 1 after page load and blocks all preview-to-editor sync.

Fix: apply the same timer-reset pattern (200ms) to all four remaining increment sites.

[mootari]

At this point scrollDisabledCount should probably become a flag since (afaict) it only ever gets set to 0 or 1?

[Copilot]

Pull request overview

Fixes markdown preview/editor scroll sync regressions introduced by #287050, restoring correct forward/reverse scroll synchronization behavior in the Markdown preview.

Changes:

• Prevents editor “jumping” during preview-driven scroll sync by not resetting the in-progress scrolling guard in scrollTo().
• Ensures preview → editor sync works immediately after load by applying a timer-based reset to all remaining scrollDisabledCount increment sites (restore/fragment/line/resize paths).

Show a summary per file

File	Description
extensions/markdown-language-features/src/preview/preview.ts	Removes an incorrect #isScrolling reset inside scrollTo()’s early-return guard to prevent re-entrant sync.
extensions/markdown-language-features/preview-src/index.ts	Applies the timer-reset pattern consistently to initialization/fragment/line/resize handlers so preview → editor sync isn’t permanently blocked.

Copilot's findings

Comments suppressed due to low confidence (3)

extensions/markdown-language-features/preview-src/index.ts:120

• This repeats the same scroll-disable/timer-reset block used in other places in this file. To keep behavior consistent and avoid missing one site in the future, consider refactoring this into a shared helper and reusing it here.

					scrollDisabledCount = 1;
					if (scrollDisabledTimer) { clearTimeout(scrollDisabledTimer); }
					scrollDisabledTimer = window.setTimeout(() => { scrollDisabledCount = 0; }, 200);

extensions/markdown-language-features/preview-src/index.ts:127

• Same duplicated scroll-disable/timer-reset logic as the other initialization paths. Consider using a shared helper (and potentially a constant for the delay) instead of repeating the block in multiple branches.

					scrollDisabledCount = 1;
					if (scrollDisabledTimer) { clearTimeout(scrollDisabledTimer); }
					scrollDisabledTimer = window.setTimeout(() => { scrollDisabledCount = 0; }, 200);

extensions/markdown-language-features/preview-src/index.ts:163

• The scroll-disable/timer-reset logic is duplicated across multiple handlers (restore/fragment/line/resize). A helper would reduce duplication and make it less likely for future edits to accidentally diverge between sites.

	scrollDisabledCount = 1;
	if (scrollDisabledTimer) { clearTimeout(scrollDisabledTimer); }
	scrollDisabledTimer = window.setTimeout(() => { scrollDisabledCount = 0; }, 200);

• Files reviewed: 2/2 changed files
• Comments generated: 1

[Copilot]

The scroll-disable/timer-reset sequence is duplicated here and again at the fragment/line handling and resize handler. Consider extracting a small helper (e.g. disableScrollFor(ms)) and/or a named constant for the 200ms delay to avoid future inconsistencies and reduce copy/paste.

This issue also appears in the following locations of the same file:

• line 118
• line 125
• line 161