fix: eliminate rendering pane flash on keypress#1362
Open
iJaack wants to merge 1 commit intoMacDownApp:masterfrom
Open
fix: eliminate rendering pane flash on keypress#1362iJaack wants to merge 1 commit intoMacDownApp:masterfrom
iJaack wants to merge 1 commit intoMacDownApp:masterfrom
Conversation
Replace the full-page reload approach (loadHTMLString:baseURL:) with in-place DOM updates via JavaScript when updating an already-loaded document. The previous code called [self.preview.mainFrame loadHTMLString:html baseURL:baseUrl] on every content change, which tears down and rebuilds the entire WebView — causing a visible white flash between renders. The original developer attempted DOM replacement via Objective-C DOMDocument APIs (see the removed #if 0 block) but abandoned it because JavaScript libraries like MathJax and Prism lost their state. This fix takes a different approach: 1. Extract only the <body> content from the rendered HTML 2. Replace document.body.innerHTML via stringByEvaluatingJavaScriptFromString: 3. Re-trigger Prism.highlightAll(), MathJax.Hub.Typeset(), and hljs.highlightElement() after the DOM swap This preserves the <head> (stylesheets, scripts) and only updates the body content, avoiding the full page reload. JavaScript libraries are explicitly re-invoked so syntax highlighting, math rendering, and other JS-dependent features continue to work. Full page reloads are still used for: - Initial document load - Base URL changes (e.g. saving an untitled document) Fixes MacDownApp#1104
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Problem
The rendering pane flashes/flickers on almost every keypress (reported in #1104). This happens because
renderer:didProduceHTMLOutput:calls[self.preview.mainFrame loadHTMLString:html baseURL:baseUrl]on every content change, which tears down and rebuilds the entire WebView — causing a visible white flash between the old content disappearing and new content appearing.Previous attempt
The original developer tried DOM replacement via Objective-C
DOMDocumentAPIs (the#if 0block inMPDocument.m) but abandoned it because JavaScript libraries like MathJax and Prism lost their rendering state after the DOM swap.PR #1216 proposed a double-buffering approach (rendering into a hidden second WebView and swapping), which adds complexity and memory overhead.
This fix
Takes a simpler approach — in-place DOM updates via JavaScript:
<body>content from the rendered HTMLdocument.body.innerHTMLviastringByEvaluatingJavaScriptFromString:Prism.highlightAll()for syntax highlightingMathJax.Hub.Typeset()/MathJax.typeset()for math rendering (v2 + v3)hljs.highlightElement()for highlight.jsThis preserves the
<head>(stylesheets, scripts already loaded) and only updates body content — no page reload, no flash.Full page reloads still happen for:
Changes
MacDown/Code/Document/MPDocument.m— 1 file, +58/-36 lines#if 0DOM replacement block with a working JavaScript-based approachFixes #1104
Supersedes #1216