Skip to content

fix(swiflowui): stop wasm32 Int traps in formatControlNumber and DataTable scroll math#257

Merged
zzal merged 1 commit into
mainfrom
fix/wasm32-int-traps
Jul 19, 2026
Merged

fix(swiflowui): stop wasm32 Int traps in formatControlNumber and DataTable scroll math#257
zzal merged 1 commit into
mainfrom
fix/wasm32-int-traps

Conversation

@zzal

@zzal zzal commented Jul 19, 2026

Copy link
Copy Markdown
Owner

Audit backlog B2 (Part-3 High + Medium): the wasm32-Int-is-32-bit trap class, invisible to host tests.

  • formatControlNumber (FieldChrome.swift): the whole-number fast path was gated at 1e15 — a 64-bit round-trip bound. Any whole min/max/step in (2^31, 1e15) passed on a NumberField or Slider (an epoch-ms bound, a 10-billion max) trapped at Int(v) in the release browser while all host tests stayed green. Cutoff is now 2^31 on every platform, so host assertions pin the exact strings wasm emits — same doctrine as cssPixelInt.
  • DataTable.onScroll: raw Int(top)/Int(height)/Int(viewportHeight) on JS-derived doubles, in the same file that created cssPixelInt for these exact quantities (NaN scrollTop trapped on every platform; ≥2^31 px trapped wasm32). Now routed through cssPixelInt, as is the virtual-runway padding arithmetic (first * rowHeight in Int).
  • New FormatControlNumberTests pin the Int32 boundary strings (2147483647 stays integer-rendered; 2^31 and 1e10 fall back to the Double rendering instead of trapping).

Whole-package swift test: 1904 tests, 352 suites, green.

Stacked on #256 (shares the CHANGELOG Fixed section); rebases to a single commit once #256 merges.

🤖 Generated with Claude Code

@github-actions

Copy link
Copy Markdown

📦 Bundle size

Artifact Baseline This PR Δ
App.wasm 5.06 MB 5.23 MB +3.45%
App.wasm (gzip) 1.80 MB 1.87 MB +3.56%
JS runtime 54.5 KB 54.5 KB +0.00%
JS runtime (gzip) 11.3 KB 11.3 KB +0.00%
Total (gzip) 1.81 MB 1.88 MB +3.54%

✅ Within budget (≤5% growth allowed).

Baseline: Swift 6.3, WASM SDK 6.3-RELEASE, measured 2026-06-18.

…Table scroll math

formatControlNumber gated its String(Int(v)) fast path at 1e15 — a
64-bit round-trip bound. On wasm32 Int is 32-bit, so any whole-number
min/max/step in (2^31, 1e15) — an epoch-ms bound, a 10-billion max —
trapped in the browser while every host test stayed green. The cutoff
is now 2^31, identical on every platform so host tests pin wasm
behavior (the cssPixelInt rule).

DataTable's onScroll did raw Int() on scrollTop/clientHeight three
functions away from the cssPixelInt helper the file wrote for exactly
these quantities; the virtual-runway padding multiplied row counts in
Int the same way. Both now route through cssPixelInt.

Whole-package swift test: 1904 green (adds FormatControlNumberTests
pinning the Int32 boundary strings).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@zzal
zzal force-pushed the fix/wasm32-int-traps branch from 66e5a98 to 8b4da68 Compare July 19, 2026 22:45
@zzal
zzal merged commit 649198a into main Jul 19, 2026
6 checks passed
@zzal
zzal deleted the fix/wasm32-int-traps branch July 19, 2026 22:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant