[Sentry: APP-HV3] Web crash creating Skia WebGL surface on expense report — null shader precision format

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-HV3

Impact (snapshot at filing)

• Users (last 7d): 21
• Users (total since first seen): 44
• Events: 338
• First seen: 2026-07-16
• Last seen: now (ongoing)
• Platform: web (Chrome on Windows and macOS)
• App version(s): 9.4.50-3 and earlier
• Affected route(s) (parameterized): /e/:reportID (view name ExpenseReport)
• Mechanism: auto.browser.browserapierrors.setTimeout

Stack trace (top frames)

@shopify/react-native-skia/lib/module/views/SkiaPictureView.web.js:248 (b)
    renderer.current = new WebGLRenderer(canvas, pd)
@shopify/react-native-skia/lib/module/views/SkiaPictureView.web.js:26 (new s)
    this.onResize();
@shopify/react-native-skia/lib/module/views/SkiaPictureView.web.js:45 (s.onResize)
    const surface = CanvasKit.MakeWebGLCanvasSurface(canvas);
canvaskit-wasm/bin/full/canvaskit.js (MakeWebGLCanvasSurface)
canvaskit-wasm/bin/full/canvaskit.js (MakeWebGLContext)
canvaskit-wasm/bin/full/canvaskit.js (_MakeGrContext)
canvaskit-wasm/bin/full/canvaskit.js:256
    a = X.getShaderPrecisionFormat(a, b); Q[d >> 2] = a.rangeMin;

Suspected cause

WebGLRenderingContext.getShaderPrecisionFormat() returns null when the WebGL context is lost or unavailable. CanvasKit dereferences the result without a null check, so the read of .rangeMin throws and the crash surfaces as an unhandled error.

Every sampled event runs low on memory at the time of the crash (95% to 97% heap usage), which fits a browser dropping the WebGL context under memory pressure and Skia then trying to build a surface on a dead context.

Suggested fixes, in order of preference:

1. Guard the Skia canvas on web. Check that a WebGL context is actually available before mounting SkiaPictureView, and render a non-Skia fallback when it is not.
2. Handle the webglcontextlost event on the canvas and skip surface creation while the context is gone.
3. If neither is practical in app code, raise the missing null check upstream in canvaskit-wasm.

Reproduction

Unknown from the events alone. To approximate it: open an expense report on web, then force the browser to drop the WebGL context (for example with the WEBGL_lose_context extension, or by opening enough memory-heavy tabs to trigger context eviction).

Related

• Parent tracker: [Tracking] Top Sentry crashes monthly check-in #91302

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022086528394619993074
• Upwork Job ID: 2086528394619993074
• Last Price Increase: 2026-08-09

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @abzokhattab (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022086528394619993074

[MelvinBot]

Proposal

🤖 Automated analysis — confidence: High for the root cause, Medium for the exact fix. The crash is an async CanvasKit error that no try/catch or React error boundary can intercept, which is why it surfaces as unhandled.

What is the root cause of that problem?

canvaskit-wasm@0.40.0 reads .rangeMin off the result of WebGLRenderingContext.getShaderPrecisionFormat() without a null check. Under memory pressure (every sampled event is at 95–97% heap) the browser drops/loses the WebGL context, getShaderPrecisionFormat() returns null, and CanvasKit dereferences null → unhandled crash. This is exactly the top of the Sentry stack (MakeWebGLCanvasSurface → MakeWebGLContext → _MakeGrContext → getShaderPrecisionFormat).

On the expense report route this is reached when a report action's HTML contains a <victorychart> tag: VictoryChartRenderer → SkiaWebChart → WithSkiaWeb → victory-native's <Canvas> → SkiaPictureView.web.js → CanvasKit.

A guard already exists for this exact crash class (SkiaWebChart/isSkiaWebSupported.ts), but it has two gaps that let the memory-pressure case through:

1. Lost-context is treated as "supported". When the probe returns null and the context is lost, it deliberately returns true to mount Skia anyway (isSkiaWebSupported.ts:34-37) — a lost context is precisely the memory-pressure state.
2. TOCTOU race. The probe validates a separate, long-lived context, not the fresh context CanvasKit creates inside WithSkiaWeb. A context lost between the probe passing and CanvasKit init cannot be caught by any synchronous guard (index.tsx:60-65).

Because the failure is asynchronous inside CanvasKit and no synchronous probe can guarantee the render context survives, a probe alone can reduce but not eliminate this signature.

What changes do you think we should make in order to solve the problem?

Primary (most complete): patch the missing null check in canvaskit-wasm@0.40.0 via patch-package — return early / skip surface creation when getShaderPrecisionFormat() returns null instead of dereferencing it. This kills the null-deref regardless of when the context drops, so it also covers the TOCTOU race the guard can't. App already patches this stack the same way (patches/@shopify/react-native-skia/, plus patches/victory-native/), so this fits the established pattern. Raise the same fix upstream in canvaskit-wasm (issue option 3).

Secondary (defense in depth): harden isSkiaWebSupported — reconsider returning true on a lost probe context under memory pressure, and re-run the probe / listen for webglcontextlost on CanvasKit's own canvas so surface creation is skipped when the context is gone (issue option 2). This narrows the window but, on its own, does not close the async race.

What alternative solutions did you explore? (Optional)

Evidence, mechanism, and things to verify

Full path to the crash on /e/:reportID:
EXPENSE_REPORT_RHP → MoneyRequestReportView renders report actions through HTMLEngineProvider → a <victorychart> tag dispatches to VictoryChartRenderer (HTMLRenderers/index.ts:73) → SkiaWebChart runs isSkiaWebSupported() once at mount → mounts WithSkiaWeb → victory-native <Canvas> → SkiaPictureView.web.js → CanvasKit.MakeWebGLCanvasSurface on the dead/new context → getShaderPrecisionFormat() returns null → .rangeMin deref → crash.

Versions: @shopify/react-native-skia@2.4.14, transitive canvaskit-wasm@0.40.0 (matches the crashing frame).

No error boundary wraps the chart, and the guard's own doc comment notes CanvasKit's failure is an async crash "that no try/catch can stop" — consistent with an unhandled Sentry error.

To verify before implementing:

• Confirm the guard (SkiaWebChart) is actually deployed in 9.4.50-3. Git history in this checkout is squashed, so its ship date couldn't be dated here. If the guard post-dates the crash and the events continue, the two gaps above are confirmed live; if it pre-dates, the crash is the residual memory-pressure tail the guard can't cover — either way the canvaskit patch is warranted.
• Confirm via a Sentry breadcrumb that the crashing route is the <victorychart> report-embedded path (vs. the Search analytics charts, which also use Skia but aren't on /e/:reportID).

Reproduction is impractical to automate: it needs a real WebGL context loss under memory pressure (e.g. the WEBGL_lose_context extension), so this is a code-based analysis, not a UI-reproduced one.

Related issues

• Expensify/App#97104 — sibling Sentry crash (APP-7MV, "failed to create webgl context") on /search and /home, same WebGL-context-under-pressure family. A canvaskit/skia-level fix here would likely help both.
• Parent tracker: [Tracking] Top Sentry crashes monthly check-in #91302.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/98101) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.