Bug 286297 – "WebGL: context lost." on Unity WebAssembly/WebGL 2 content.

• Component: WebGL
• Status: RESOLVED FIXED

STR:

1. Visit https://oummg.com/dump/unity/safari_crash/ on an iPhone. (you can download this test case for local introspection at https://oummg.com/dump/unity/safari_crash.zip )
2. Click on the "Everything everywhere all at once" button at the top of the page.
3. Observe that the page rendering will stop.

If you have Safari Web Inspector connected from a Mac, observe that Safari WebGL implementation has crashed to a "WebGL: context lost." message with no further information.

Reproduces on:
- iPhone Xs iOS 18.1.1
- iPad Pro (12.9-inch) (3rd generation) iPadOS 17.4.1
- iPhone 12 Pro, iOS 17.6.1, CPU: Apple A14 Bionic
- iPad (10th generation), iPadOS 18.1.1

Does not reproduce on Desktop Safari Android or Desktop on Firefox or Chrome.

Updated iPhone Xs to iOS 18.2.1 (latest as of writing), and observed that the same issue also occurs there: the WebGL context gets lost during the page run.

Also noticed there is a separate issue on iPhone Safari: reloading the page does not work, but results in an exception "RuntimeError: Out of bounds memory access" coming from a WebAssembly function "GenerateDitherTextures" immediately on page load.

Generally I would attribute such an error to be a problem in compiled WebAssembly code and self-reflect, but the fact that the same RuntimeError does not reproduce on Firefox or Chrome on mobile or desktop, and that the RuntimeError does not occur on the first page visit (and the page does not alter behavior based on cached state), this seems some kind of browser problem.

Manually killing Safari by swiping up on the Safari browser in the app carousel, and then restarting the browser and re-navigating to the page with a "fresh" browser will again help the page to load and run (once). Then one has to again kill Safari to be able to rerun the page. That seems like could be a separate issue to the "WebGL: Context lost" problem.

[Radar WebKit Bug Importer]

<rdar://problem/143759792>

Our QA at Unity bisected the problem into the source commit in Unity that began to introduce this error. That change is a refactor of the Unity 2D UI shader code, which changes a large number of 'float2' variables to a 'uint2'. Maybe that might give a good clue towards the direction to look. It seems like a failing shader compilation causes the WebGL Context Loss in this case?

On even closer examination, it suggests that the offending change would have been a rename of a bunch of GLSL variables of type `int` and `int2` to `uint` and `uint2`, which triggers a WebGL Context Lost on Safari.

Created attachment 474073 [details]
Possible repro

A WebGL trace recording to reproduce the "WebGL Context Lost." error.

A live website of the above attachment is at https://oummg.com/dump/ios/crash.html . On iOS 18.2 it will show an alert() popup with "WebGL Context Lost" error. On Firefox and Chrome where the issue does not reproduce, it will show a green button on a blue background instead.

It is not 100% clear if this is identical to the original repro, because that trace was not recorded from the exact same project as the original failure. But given that they both are captured from Unity engine, and result in Safari tripping up in "WebGL Context Lost" error, there is high likelihood that they represent the same root cause.

Created attachment 474127 [details]
Reduced test case from the trace.

A further reduced test case from the trace. It looks like the root culprit is the use of modifier "flat" in a vertex shader.

That is,

"
#version 300 es
flat out highp uvec2 vs_TEXCOORD3;
void main()
{
}
"

causes a WebGL Context Lost error if attempted to compile, but

"
#version 300 es
out highp uvec2 vs_TEXCOORD3;
void main()
{
}
"

does not result in a WebGL Context Lost error.

To clarify about the repro: it looks like one has to sometimes reload the page in order for the WebGL Context Lost error to appear. I.e. the context lost might not synchronously get reported by Safari, but only on page reload. The last test case has a setTimeout loop to poll for context loss, which is not always getting triggered,until the page is reloaded.

[Kimmo Kinnunen]

I cannot immediately reproduce on my devices:
- iPad iPadOS 18.0 dev
- iPad Air iPadOS 18.1.1  CE
- iPhone 16 18.3 dev

https://oummg.com/dump/unity/safari_crash/ 
 - Here I see a spinning cube, I press all the buttons and they flash briefly but the cube keeps on spinnig
https://oummg.com/dump/ios/crash.html
 - Here I see the numbers, "smash" button and  blue webgl rect


Will try further.

If you are able to submit feedback report with a sysdiagnose after the crash, please do so and ping with the FB number here. https://developer.apple.com/bug-reporting/
Unfortunately, feedback report might need a Beta iOS 

We have had a regression with float vector to int vector conversion, see here: bug 283576. The symptom would be link to fail.
We have had a intermittent crash when link fails, but this should be rare (fixed in bug 285731).

Flat shading works in WebGL2. If the provoking vertex doesn't matter for the engine, https://registry.khronos.org/webgl/extensions/WEBGL_provoking_vertex/ should be used to ensure good perf on Apple and perhaps Windows devices.

Created attachment 474147 [details]
Fully minimized test case

Completed minimizing the test case. This page is hosted at

https://oummg.com/dump/ios/crash_minimal.html

This loses the WebGL 2 context, but only on page reload. STR is to visit that page, and then drag down on the page body to reload the page. Then the alert popup "GL context lost already at page startup." will trigger. (i.e. no context lost message occurs on the first visit to the page, but one must reload the page for it to happen)

While working on minimizing this test case, I observed twice that my iPad instead turned to display a fully pink screen on page reload, and the whole iPad would reboot. (showing the Apple logo and rebooting to SIM unlock menu)

This page was tested to reproduce on
 - iPad Pro (12.9-inch) (3rd generation), iPadOS 17.4.1, Model Number MTEL2KN/A and
 - iPhone Xs iOS 18.2.1 Model Number MT9G2FS/A

[Kimmo Kinnunen]

Can repro on iPhone 12 mini = A14 Bionic

The reported failures are on:
iPad Pro 12.9 3rd gen = A12X
iPhone Xs = A12 Bionic
iPhone 12 Pro, = A14 Bionic
iPad (10th generation) = A14 Bionic

Unable to reproduce on M1/2/4 based iPads, iPhone 16

[Kimmo Kinnunen]

*** Bug 286648 has been marked as a duplicate of this bug. ***

[Filipp Keks]

I have similar issue with pure WebGL2 API (ThreeJS) on same devices, iOS 18
Context suddenly lost on buffers upload. Context can not be created after page reload, requires browser kill-restart.
Can create a minimal example to reproduce, if needed

[Kimmo Kinnunen]

(In reply to Filipp Keks from comment #14)
> I have similar issue with pure WebGL2 API (ThreeJS) on same devices, iOS 18
> Context suddenly lost on buffers upload. Context can not be created after
> page reload, requires browser kill-restart.
> Can create a minimal example to reproduce, if needed

Thanks, this sounds like a different issue. A reproduction example would be appreciated, either in this bug report or a new one.

[Filipp Keks]

Here is a zip to reproduce, open index.html with iOS safari
console shows "context lost"
webgl context can not be created until browser killed
https://drive.google.com/file/d/11DlSrLWyvUI4gAmZk8duuzD1HHmgQN4S/view?usp=sharing

Let me know, if this is a different issue

[Kimmo Kinnunen]

(In reply to Filipp Keks from comment #16)
> Here is a zip to reproduce, open index.html with iOS safari
> Let me know, if this is a different issue

I cannot reproduce this. I serve it through http and it seems to load and I can interact with a scene.
I moved this investigation into bug 289601. If you have time, please comment there which devices you're seeing this with.

[Kimmo Kinnunen]

*** Bug 289601 has been marked as a duplicate of this bug. ***

[Kimmo Kinnunen]

This should be now fixed in macOS 15.5, iOS 18.5.
Please note that unless using provoking vertex extension, the flat shading as a shader variable optimisation is likely not an optimization.
Thanks again for the work on the reproduction case.