You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
🤖 Fix diff whitespace loss when HTML extraction fails (#363)
## Problem
When Shiki produces malformed HTML (without expected `<span
class="line">` wrappers), `extractLinesFromHtml` returns empty strings
for those lines. These empty strings bypass validation and get rendered
as `<span dangerouslySetInnerHTML={{ __html: "" }} />`, which results in
empty spans that lose all whitespace and content from the original code.
The validation only checked for line count mismatch (line 93), but
didn't detect when non-empty input lines became empty strings after HTML
extraction.
## Solution
### 1. Added defensive validation for empty HTML extraction
Detects when any non-empty input line results in empty extracted HTML:
```typescript
const hasEmptyExtraction = lines.some(
(extractedHtml, i) => extractedHtml.length === 0 && chunk.lines[i].length > 0
);
if (hasEmptyExtraction) {
return createFallbackChunk(chunk);
}
```
When detected, we fall back to plain text rendering (`escapeHtml`),
which preserves all whitespace correctly with the existing `white-space:
pre` CSS.
### 2. Increased max diff size from 4KB to 32KB
Bumped `MAX_DIFF_SIZE_BYTES` from 4KB to 32KB to allow syntax
highlighting for larger diffs. This should reduce the frequency of
fallback rendering for normal-sized diffs.
## Testing
- Added regression test for whitespace preservation with indented code
- All 720 tests pass
- Verified with real-world diff from issue report
## Certainty Level: LOW ⚠️
**I was unable to reproduce the original bug.** When testing the
provided diff with both TypeScript highlighting and fallback modes,
whitespace was preserved correctly in all cases.
What I found:
- Shiki always produces `<span class="line">` wrappers in my tests
- The code path where `extractLinesFromHtml` returns empty strings
(lines 158-160, 165-167) appears unreachable with normal Shiki output
- The fallback already preserves whitespace correctly
**This fix is defensive:** It adds a safety check that should prevent
empty HTML from being rendered if extraction ever fails unexpectedly.
However, I cannot confirm this addresses the specific issue reported.
**Next steps if bug persists:**
1. Capture the actual Shiki HTML output when bug occurs
2. Check for CSS conflicts or browser-specific rendering issues
3. Investigate if the bug occurs in a different code path (e.g.,
different language, very long lines, or specific Shiki version edge
cases)
## Impact
- Improves robustness by preventing empty HTML from being rendered when
extraction fails
- Allows syntax highlighting for larger diffs (up to 32KB instead of
4KB)
- May not fix the original reported issue, but reduces surface area for
potential bugs
_Generated with `cmux`_
0 commit comments