Skip to content

PLATFORM_BUGS.md

Latest commit

 

History

History
47 lines (32 loc) · 8.4 KB

PLATFORM_BUGS.md

File metadata and controls

47 lines (32 loc) · 8.4 KB
Raw

Platform Bugs

This is the current ledger of browser and operating-system behavior that affects Pretext. Exact means the linked report contains our repro or the same failure. Related means the report helps explain the browser behavior but does not prove our exact case. Unfiled means we have a local repro or compatibility requirement but no exact public issue.

Tracker statuses were last checked on June 22, 2026. The checked-in browser snapshots and the commands used to refresh them remain the source of truth for current accuracy; see DEVELOPMENT.md.

Open, exact platform bugs

Platform Bug Tracker status Effect on Pretext Current handling
Chrome on macOS Canvas measureText() reports Apple Color Emoji wider than DOM text at small font sizes. The discrepancy is size-dependent and disappears at larger sizes. Chromium #489494015, open Raw canvas widths can force premature emoji line breaks. prepare() capability-detects the canvas/DOM difference once per font and subtracts it per emoji grapheme. The correction is cached and stays out of layout().
Firefox on macOS The same Apple Color Emoji canvas/DOM width split, with a different size curve from Chrome. Mozilla's investigation points at the bitmap font being measured at different effective device-pixel ratios. Mozilla #2020894, UNCONFIRMED Raw canvas widths can force premature emoji line breaks. The same capability-detected correction handles Firefox without a Firefox version check.
Chrome on macOS Canvas and DOM resolve system-ui to different SF Pro optical variants at some sizes. The affected size bands have moved between browser releases. Chromium #489579956, open Canvas widths can be wrong by enough to invalidate line-count predictions. system-ui remains unsupported for accuracy. Use a named font.
Firefox on macOS Canvas and DOM resolve system-ui / -apple-system to different physical fonts. The magnitude and direction have moved between browser releases. Mozilla #2020917, UNCONFIRMED Canvas widths are too far from DOM widths for reliable line-count prediction. system-ui remains unsupported for accuracy. Use a named font.

Retina retest: June 22, 2026

We reran the exact attached repro inputs in headed browsers on a Retina display at devicePixelRatio = 2:

  • Chrome 149.0.7827.156: the emoji curve still matches the filed bug exactly (+2px to +4px below 24px, then zero). The system-ui bug also remains, but this release's mismatches moved to 20px, 22px, 24px, 26px, 28px, 30px, and 32px instead of the original size bands.
  • Firefox 152.0.1: the emoji curve still matches the corrected Mozilla report exactly (+1.5px to +5px below 28px, then zero). Both system-ui and -apple-system mismatched at every tested size from 10px through 32px; the curve no longer matches the original report, but named-font controls still agree.
  • Headless runs at devicePixelRatio = 1 made both browsers look clean. That is not a valid regression check for these bugs because the Apple Color Emoji issue depends on the Retina DPR split and the font-resolution bug also disappeared in those runs.
  • With the capability-detected emoji correction enabled, the headed Chrome and Firefox accuracy sweeps were both 7680/7680. Temporarily disabling only that correction reduced Chrome to 7660/7680 and Firefox to 7652/7680, so the workaround is still necessary.

Safari does not reproduce either filed canvas/DOM bug: its emoji canvas and DOM widths agree, and its system-ui canvas and DOM widths agreed across the project's 10-28px scan. The public recommendation still says to avoid system-ui on macOS because the same application may run in Chrome or Firefox.

Safari/WebKit issues and compatibility behavior

Behavior Classification and issue links Evidence in this project Current handling
A Range crossing wrapped text can report an extra zero-width rectangle on the preceding line, inflating getClientRects() / getBoundingClientRect() geometry. Related: WebKit #296765, NEW, with Apple Radar 157274174. It is the same wrapped-Range geometry family, but not an exact report for every URL-query or pre-wrap extraction failure we have seen. Safari 26.4 still produces extractor-sensitive results around preserved whitespace, hard breaks, and some URL/query boundaries even when DOM height and span extraction are exact. This affects diagnostics, not the runtime line breaker. Cross-check suspicious Safari Range results with the span extractor before changing Pretext.
Safari needs a 1/64px line-fit allowance instead of the 0.005px Chromium/Gecko allowance. Unfiled; WebKit #145393 is useful implementation background because it documents WebKit's LayoutUnit as 1/64px, and WebKit #144990 is a resolved historical float-precision wrapping bug. Neither is an exact report for our current case. On Safari 26.4, replacing 1/64px with 0.005px reintroduced one 18px Verdana Arabic/Latin mismatch in the 7,680-case sweep. Keep the Safari line-fit epsilon in the engine profile.
Safari's word-break: keep-all punctuation boundary differs from Chromium and Gecko for no-space mixed CJK text. Exact, fixed upstream: WebKit #312099 landed as 311090@main. The broader break-all/keep-all punctuation report WebKit #298022 remains open. CSS Text says word-break does not affect punctuation opportunities, and WPT word-break-keep-all-006 tests exactly that. Safari 26.4 still fails; the recorded Safari 26.5 stable and preview runs also fail while Chrome and Firefox pass. Keep breakKeepAllAfterPunctuation until the fixed WebKit build ships in Safari, then retest and remove it. Keep the policy in preprocessing, not layout().
Safari fits overlong shaped runs more accurately from measured segment prefixes than from isolated grapheme widths. Unfiled; no exact WebKit issue found. A 2,564-case quarter-pixel kerning/ligature sweep had 307 raw-height misses with prefix fitting and 1,018 with isolated grapheme sums. Keep preferPrefixWidthsForBreakableRuns for Safari, capped at 96 graphemes to avoid a superlinear prepare() path.

The three Safari engine-profile decisions above—line-fit allowance, keep-all punctuation policy, and prefix fitting—were rechecked on shipping Safari 26.4. Safari Technology Preview was not installed, so they should not be described as verified against WebKit tip-of-tree.

Investigated, but not platform bugs

  • Chromium's Korean closing-quote behavior is still modeled by carryCJKAfterClosingQuote, but the minimal repro behaved the same in Chrome 149 and Firefox 148. It follows the browser's overflow-wrap: break-word handling of the normal unbreakable unit before emergency grapheme breaking, so we did not file it as a Chromium bug.
  • The old Safari-only preferEarlySoftHyphenBreak branch was redundant with the later strict soft-hyphen boundary fix. It was removed after Safari 26.4 retesting; there is no remaining platform bug to track.
  • Safari emoji widths are wider than font-size at some small sizes because of Apple Color Emoji's non-linear scaling, but canvas and DOM agree. Comparing either one to font-size is the bug in the measurement model, not a Safari bug.
  • The long-form Chinese and Japanese corpus fields in RESEARCH.md remain browser/model canaries, not isolated browser defects with defensible tracker repros.

Historical, unfiled platform investigation

The repository briefly contained iOS Safari scrolling crash probes for very tall virtualized pages and rapid scrollbar/flick interaction. They were removed in commits 837f080 and 2fbae37 after the investigation, and no Apple/WebKit issue link was recorded. This is not part of Pretext's current text-layout surface; retain it here only so the old commits are not mistaken for a current workaround.