What causes tainted canvas errors when using images as WebGL textures?

An image drawn from another origin without CORS approval tainted the canvas/texture — assets on a CDN or different subdomain loaded without crossOrigin, then uploaded to WebGL.

How do I catch this when it only happens for some players?

Capture it automatically from the player's device with the full stack trace, the device and OS, the build, and a breadcrumb trail of what they did. That turns a vague complaint into a specific, reproducible issue you can fix without owning the hardware it happens on.

How to Fix “WebGL: INVALID_OPERATION: texImage2D: tainted canvases may not be loaded” in Web Games

Quick answer: Load cross-origin images with crossOrigin='anonymous' and serve them with Access-Control-Allow-Origin headers — both sides are required — or same-origin the assets.

Canvas security taints any surface touched by unapproved cross-origin pixels, and WebGL refuses tainted sources. The fix is a two-sided CORS handshake. Here it is.

How to fix it

1. Set crossOrigin before src

img.crossOrigin = "anonymous"; img.src = url; — order matters; setting it after src misses the request. Frameworks and loaders usually expose an equivalent option.

2. Serve the CORS header

The CDN/bucket must respond with Access-Control-Allow-Origin covering your origin — one-sided fixes fail: the attribute without the header errors, the header without the attribute still taints.

3. Watch the canvas-composition path

Atlases assembled by drawing images into a 2D canvas taint that canvas too — every source image needs the same treatment before the atlas uploads to WebGL.

4. Same-origin as the simple out

Hosting game textures on the page's own origin removes the entire problem — keep cross-origin for genuinely shared/CDN'd content only.

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every HTML5 error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.

Most of the time the fix is small. Seeing the failure clearly is the part that actually costs you.