Keep input responsive while highlighting heavy code threads - #1160
Draft
jorgemanrubia wants to merge 2 commits into
Draft
Keep input responsive while highlighting heavy code threads#1160jorgemanrubia wants to merge 2 commits into
jorgemanrubia wants to merge 2 commits into
Conversation
highlightCode() ran Prism over every <pre data-language> in one synchronous pass. On a heavy thread with many or large code blocks, that single uninterruptible task monopolizes the main thread, freezing input and scrolling until it finishes — the symptom reported for slow comment threads on Safari. Measured in headless chromium on a rendered thread of code blocks: - 50 blocks x 40 lines: 0 frames painted during highlighting (frozen) -> 6 - 100 blocks x 60 lines: 0 frames painted (frozen), 271ms single blocking task -> 15 frames painted, no >50ms JS task Process blocks in time-budgeted chunks (8ms) and yield to the event loop with a MessageChannel macrotask between chunks, so the browser can paint and handle input while highlighting continues. highlightCode() now returns a Promise; fire-and-forget callers (the documented Stimulus connect() usage) are unaffected. highlightElement() stays synchronous, and its data-highlighted guard keeps concurrent runs from double-highlighting a block.
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
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.
A comment thread with many or large code blocks could lock up the page on load: the view would take a long time to appear and then input and scrolling were frozen until it finished. The reporter saw this on iOS and macOS Safari and suspected the Prism syntax highlighter.
They were right about where the cost lives.
highlightCode()— the helper host apps call to syntax-highlight rendered Action Text content — walked every code block and ran Prism over all of them in a single synchronous pass. The more (or bigger) the code blocks, the longer that one uninterruptible task held the main thread, and while it ran the browser could neither paint nor process input. On a heavy thread that window stretches into seconds, which is exactly the freeze that was reported.A previous change (#1087) removed an O(controllers × blocks) blow-up and made the helper idempotent, but the remaining work was still done all at once. This change spreads it out: the helper now processes blocks in small time-budgeted chunks and hands control back to the browser between them, so the page stays responsive while highlighting catches up. The visible code appears progressively instead of after one long stall.
Measured in headless Chromium on a rendered thread of code blocks, counting frames the browser managed to paint while highlighting ran:
highlightCode()now returns a Promise so callers can await completion if they want to; the documented fire-and-forget usage in a Stimulusconnect()keeps working unchanged.Fixes Basecamp card #10020780336: Rendering issue, possibly due to Prism syntax highlighter?