Bug 300782 – iOS Safari reload loop under memory pressure with WebGL/texture‑heavy pages

• Status: NEW
• Component: WebGL

[Jaume Calm]

Version:
iOS/iPadOS Safari. Multiple devices and OS versions; reproducible broadly, not device/version specific but generally easier on lower end devices with less memory.

Hardware/OS:
iPhone and iPad (various models)

Issue:
Pages with heavy WebGL usage and many textures get terminated by iOS memory pressure and immediately reloaded by Safari, causing an endless reload loop until the message "A problem repeatedly occurred on ...". 
We guess the loop reoccurs because startup re-allocates large GPU/JS memory before the user can interact. No explicit OOM error is surfaced to JS, nor "webglcontextlost" is observed shortly before termination.

How to reproduce:
Open https://app.vectary.com/p/7bSHzvpPakDkEKFdIKtYDI and https://app.vectary.com/p/6qMjY22PRp0hLCV6W5JktQ on safari. Open more tabs if needed, and shortly after you will encounter it.

Related Bugs/Reports we found:
Memory exceedance → page reload during WASM compilation in WebGL games (iOS 18.4): bugs.webkit.org/show_bug.cgi?id=291677
Potential WebGL memory leak causing freezes/reloads in Safari iOS 15: bugs.webkit.org/show_bug.cgi?id=229606
Out-of-memory crashes with Mapbox GL JS on iOS (tab crash/reload): bugs.webkit.org/show_bug.cgi?format=multiple&id=172790

Request
- Guidance on reliable JS‑visible signals prior to process termination (to enable automatic “lite mode”).
- Review of iOS WebKit behavior to avoid reload loops (e.g., deliver context loss reliably before kill, or delay auto‑reload after kill to allow fallback).
- Any recommended limits or APIs to query memory budget for WebGL on iOS.

Any input will be appreciated, since this affects production 3D experiences with legitimate texture budgets; users get stuck in an infinite reload loop and cannot access the content.

Best regards,
Jaume Calm

[Radar WebKit Bug Importer]

<rdar://problem/163178758>

[Joe Pea]

This problem has been haunting WebGL devs for a long time. It is also a know fact that iOS Safari limits memory usage, it isn't a physical memory limit. Similar Android devices can load like 4 or 16 times more memory without crashing. Basically every time this crash happens on a flagship iPhone, a flagship Android typically does fine, even if the devices have similar specs. The solution is typically to reduce texture sizes, or use less textures. In other cases, making too many DOM nodes can also trigger the issue, but that is less common.

This seems to happen even with memory that has not yet been garbage collected, so even if actual app memory is low, growing garbage can trigger this, which makes it a bit impractical to deal with in some scenarios because apps cannot force Garbage Collection.

It would be great if, instead of clearing the developer tools when this crash happens, the devtools would stay open with all data persisted. At the moment, when the crash happens, devtools gets entirely cleared, which means any information in a Timeline recording will be gone. It would be useful, especially as Timeline gets better features over time, to be able to see what was being called, what was growing memory, before a crash.

At the moment, we're left totally in the dark because after Safari clears the tab (and devtools), there's completely nothing left to look at.

[Kimmo Kinnunen]

Thanks for the feedback and pings.

If you have a reproduction case where iOS Safari OOMs with 4 or 16 times less memory, please add it here or open a new bug. This particular description sounds like a bug..