fix(🌐): keep the web canvas usable when its layout effect re-runs

[dennytosp]

Fixes #3976. Rebased onto main after #4035.

WebGLRenderer.dispose() calls WEBGL_lose_context.loseContext() on the <canvas> element. Per the spec that loses the element's context permanently — a later getContext("webgl2") returns the same dead context object, and only restoreContext() revives it.

But the renderer is created and disposed inside a useLayoutEffect, and effect cleanup does not mean the element is going away. React re-runs layout effects on a preserved host node in at least two everyday cases:

• StrictMode's DEV double-invoke, on every mount in development;
• reappearLayoutEffects when a hidden Activity/offscreen subtree is revealed — which is how React Navigation and Expo Router keep inactive routes mounted.

On the re-run GetWebGLContext still hands back a non-zero handle for the dead canvas, so the Could not create a WebGL context guard never fires, and MakeWebGLContext then faults inside wasm with Cannot read properties of null (reading 'rangeMin'), taking the tree down.

The fix keeps the release, it just waits until the element is actually gone. Dropping loseContext() outright would fix the crash, but it would also give up the deterministic GPU-context release this call was there for — browsers cap a page at ~16 live WebGL contexts (#3349, #3331, #3297, #2343, #956), and falling back to GC means a mount/unmount-heavy page can transiently exceed the cap, at which point the browser force-loses the oldest context and breaks a canvas that is still mounted.

canvas.isConnected distinguishes the two cases, but only one microtask after cleanup — at cleanup time React has not detached the node yet, so the check has to be deferred. Measured on React 19.0, logging isConnected from a layout-effect cleanup:

	at cleanup	one microtask later
StrictMode re-run	true	true
root.unmount()	true	false
conditional subtree unmount	true	false

So the guard is exact: on a re-run the canvas is still in the document and keeps its context, and on a real unmount the context is released a microtask later — no behaviour change for the case the call was added for. An Activity subtree is hidden with display: none rather than removed, so it stays isConnected and keeps its context, which is the point.

CanvasKit.deleteContext, which is what #3929 actually needed to stop unmounted views retaining their detached canvas elements, is untouched and still runs synchronously. StaticWebGLRenderer.cleanupRenderResult() also keeps its unconditional call: that one is on a throwaway OffscreenCanvas that is never reused.

Test. The new case in SkiaPictureView.web.spec.tsx drives the component through StrictMode against a CanvasKit mock that models the failure the way the issue describes it: a lost context still yields a handle from GetWebGLContext, and MakeWebGLContext is what throws. On main it fails with the reported error and stack —

TypeError: Cannot read properties of null (reading 'rangeMin')
  at new WebGLRenderer (src/views/SkiaPictureView.web.tsx:50:32)
  at reappearLayoutEffects
  at recursivelyTraverseReappearLayoutEffects
  at reappearLayoutEffects
  at doubleInvokeEffectsOnFiber
  at recursivelyTraverseAndDoubleInvokeEffectsInDEV

— and it asserts both directions: the context survives the re-run, and it is still lost after a real unmount. The mock is wired into the existing getContext stub, so the four pre-existing tests now exercise a real context object instead of null; they still pass unchanged, on main as well as here.

[wcandillon]

I agree I think with the issue but I am not sure if I agree yet with the fix, is there a way maybe you could produce a small example in apps/example that would help reproduce the issue?

[wcandillon]

Thanks a lot for this! I'm closing this in favor of #4002 hope it's ok

[wcandillon]

I'm re-opening this. I need to give it some thoughts.

[wcandillon]

I will publish a fix for it in #4002