~ knotless Search/
↑↓ move↵ open⇧↵ all results

chadtmiller.com/knotless
Switch repository
Loading…

git that lives in your Atmosphere account

knotless.dev
1 collaborator

knotless 0.13.0 Latest 2 packages, 1 image

1
10

WebKit paints the diff's highlighting with live ranges again

Closed
Closed chadtmiller.com asked to merge into main from chadtmiller.com/knotless:web/webkit-highlight-ranges
1 reviewer 1 approved
Reviewers
review.knotless.devRequired reviewer for main Approved
chadtmiller.comopened , edited

What changes

On WebKit (Safari, and every browser on iOS, Chrome's included), the highlighting of diffs, files and Markdown code is painted with live Ranges again, as before 3mz2x6sda73g4. Chromium and Firefox keep StaticRanges. A rangeOver helper picks which kind, by user agent: AppleWebKit without Chrome/, Chromium or Edg/, so iOS Chrome (CriOS) counts as WebKit.

Why

On an iPhone, a pull's Files tab draws some files with every line's text, and its hunk headers, boxed in a brown tint, in plain white with no syntax colours. Others on the same page draw right. It happens in the dark theme as well as Blacksky.

A probe on the runner fetched getPullDiff for two files of pull 3mz34u63zhe2b and replayed paint() over them:

  • web/src/app.css, drawn right: syntax ranges only, 60 of them, all valid.
  • DiffFile.svelte, drawn boxed: syntax ranges plus xins and xdel, 104 in all, every one within its text node.

So the data is sound and Chromium paints it right. What the boxed files share is the changed-word highlights, the only ones with a background-color (and color: var(--fg), the white). WebKit paints those over all the text, not only their ranges. Those ranges became StaticRanges in 3mz2x6sda73g4, so going back to live ranges on WebKit is the change that undoes it.

How it was checked

  • The probe above. Its branch is scratch/svelte-ranges, to delete once this lands.
  • Playwright's Linux WebKit, via just look --webkit (branch harness/look-webkit), paints no custom highlights at all, so it can't show either the bug or the fix.
  • Confirm on an iPhone once this deploys: a pull's Files tab with changed lines.

Shortcomings

  • Inferred, not seen in WebKit's own tools. If the boxes stay, the next suspect is xins/xdel's priority = 1 in WebKit, then content-visibility.
  • On WebKit, a big pull is as slow to read as it was before 3mz2x6sda73g4.
  • User-agent sniffing: a WebKit that claims Chrome/ would get static ranges.

Changeset: none

🤖 Generated with Claude Code

https://claude.ai/code/session_017Ya96d9VuMseV86YwEZPoh

chadtmiller.com added 3 commits
review.knotless.devreviewed Approved

This adds a rangeOver helper. It returns a live Range on WebKit (Safari and all iOS browsers, including CriOS) and a StaticRange elsewhere. paint and target now use it. The UA test is right for the cases it names: CriOS and EdgiOS have neither Chrome/ nor Edg/, so they count as WebKit. The AbstractRange types are compatible with the leftover StaticRange[] annotation at highlight.ts:74, because StaticRange adds no members. clear still calls h.delete(r) on the same objects, so cleanup is unchanged.

The fix is inferred, not seen in WebKit, and the body says so. The live ranges only restore the earlier behaviour. I didn't check CI results.

Optionally, change highlight.ts:74 to AbstractRange to match the new paint return type.

Some checks were not successful

1 failed

1 failed check lookFailure in 34s