Tree widget: large tree crashes on mobile

[JoanaSmit]

Package
@itwin/tree-widget-react (VisibilityTree)

Describe the bug
Expanding large tree:

IC-expand-tree.MOV

Scrolling large tree:

IC-scroll-tree.MOV

App-scroll-tree.MOV

To Reproduce
Steps to reproduce the behavior:

1. Open iModel with a large tree on a mobile device
   • Sample iModel
   • Reproducible on the Field app and the IC iModel viewer on a mobile device
2. Expand a few nodes or scroll fast
3. Web view process crashes

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the applicable information):

• OS: iOS / Android
• Chrome, Safari, Field App
• @itwin/tree-widget-react 3.14.0
• iTwin.js Version 5.2.2

[JoanaSmit]

Copied from: iTwin/iTwinUI#2658

[grigasp]

I thought this is only reproduced on a Field App. Being able to reproduce on a web app should make things a bit easier, although I couldn't repro it on a desktop browser and its devtools show no memory leaks. @saskliutas, can you please try to repro this on your iPad?

[saskliutas]

I just got an IPad to work on this. Is this still reproducible? I have tried to reproduce using provided link on IPad A16 but everything works as expected. Also tried different IPhone simulators and all worked fine.

If this is still reproducible does it affect only few select devices? Or some additional conditions must be met?

[Modeeeeeee]

Reproducibility

Hey @saskliutas was still able to reproduce this on iPhone 16 Pro Max @ iOS 26.2.1 today (2026-03-09)running with packages at versions iTwin.js @ 5.2.2 and tree-widget-react @ 3.14.0

For now from the logs my guess is that the WebView is out of memory:

2026-03-09 12:55:35,479+0200 0x0x206e16200  ERROR Field                Error shown: ["Message": "We are sorry, something went wrong and the iModel view needs to be reloaded. Please try again.", "InternalError": "ModelWebApp reloaded (probably due to running out of memory)."]
2026-03-09 12:55:35,497+0200 0x0x16fc1f000  INFO  Field                Feature tracked: MODEL_FRONTEND_RELOADED {"wasModelOpen":"true"}
2026-03-09 12:55:35,497+0200 0x0x171c57000  INFO  Field                Feature tracked: ERROR_SHOWN {"InternalError":"ModelWebApp reloaded (probably due to running out of memory).","Message":"We are sorry, something went wrong and the iModel view needs to be reloaded. Please try again."}

Investigation

I am currently actively looking into what might cause this on our end, I will try to look for more logs and maybe investigate memory usage if possible.

For now the main way how to reproduce this bug is scrolling pretty rapidly in a tree view, and it works pretty much constantly

[Modeeeeeee]

Adding a comment about what I checked today (2026-03-09)

I was able to reproduce the bug on physical devices, but not on simulators
I've tested both - FieldApp and QA BiC portal (only iPad)

FieldApp testing was done with such setups:
iPhone 16 Pro Max @ iOS 26.2.1
iPad (A16) @ iPadOS 26.3.1

Both sessions I tried with iTwin.js @ 5.2.2 and different versions of tree-widget-react (3.14.0 and 3.17.8)
In both cases the application has crashed on both iPad and iPhone

Using qa-infrastructurecloud portal I was not able to crash my iPad, I tried scrolling a huge list for good 10 minutes and was not able to replicate this. Currently I asked QA in our team (Field) to try replicate the bug while I will try to debug memory usage and possibly try to use a newer iTwin version tomorrow

[Modeeeeeee]

Okay, so first of all, this comment is a confirmation that the bug is also reproducible in the web using mobile devices

Today (2026-03-10) our QA has tried to test BIC tree viewer, but when opening the nodes it crashed like in the videos provided by JoanaSmit

Here is a newer repro from today:
System Info: iOS 26.3 iPhone 15

MicrosoftTeams-video.mp4

[Modeeeeeee]

@saskliutas
(Summarized by Copilot)

ado_id: 1711734
type: github-issue
package: "@itwin/tree-widget-react"
version: 3.17.8
tags: [field-app, github-issue, crash, memory, performance]

🐛 WKWebView content process terminated (OOM crash) when scrolling large ModelsTree

Package

@itwin/tree-widget-react 3.17.8 (via ModelsTreeComponent / VisibilityTree)

Related: @itwin/itwinui-react 3.20.2, @itwin/presentation-hierarchies-react

Environment

• Platform: iOS 18.5 (iPhone 15, iPad 9th gen) — WKWebView
• iTwin.js: 4.x
• React: 18.x
• Consumer: Embedded mobile WebView (not desktop browser)

Description

When a user expands and rapidly scrolls through a model tree with thousands of nodes, the WKWebView web content process is killed by iOS due to memory pressure. The user sees a "We're sorry, something went wrong" error and is navigated back to the model list.

The root cause is a microtask storm originating in ModelsTreeIdsCache.js — the internal data-loading layer creates hundreds of thousands of Promise microtasks in under a second, causing unbounded memory growth that triggers an OS-level SIGKILL.

Reproduction Steps

1. Open a model with a large tree hierarchy (5,000+ nodes across multiple levels).
2. Expand the model tree in the Visibility panel.
3. Scroll through the expanded tree quickly (fast flick gesture).
4. Result: The web content process terminates. On iOS, this manifests as webContentProcessDidTerminate in the WKWebView delegate.

Reference model: A Bentley QA model with ~10K nodes across deeply nested categories (available on request).

Root Cause Analysis

We captured a Safari Web Inspector timeline recording (13.68s) during a reproduction of the crash. Below is what the recording reveals.

1. Microtask Storm (primary crash trigger)

Between t=9.0s and t=9.7s, 210,672 Promise microtasks are dispatched in 600ms:

9.0–9.1s:      329 microtasks
9.1–9.2s:   22,410 microtasks
9.2–9.3s:   38,138 microtasks
9.3–9.4s:   33,273 microtasks
9.4–9.5s:   61,337 microtasks  ← PEAK
9.5–9.6s:   33,678 microtasks
9.6–9.7s:   21,417 microtasks

The storm is triggered by 7 sequential setTimeout(fn, 0) batch timers (IDs 6851–6863), each running ~40ms and spawning ~30,000 microtasks. This pattern is consistent with the Promise.all() chains in ModelsTreeIdsCache.js:

// ModelsTreeIdsCache.js line 183
return { loadingMapEntries: Promise.all(loadingMapEntries).then(() => { }) };

// ModelsTreeIdsCache.js line 200
return Promise.all(existingPromises);

When hierarchyLevelSizeLimit is set to a high value (we use 10,000), queries for element IDs are batched in chunks (lines 169–182), and each batch creates its own Promise.all(). The result is O(N) microtasks where N = total node count across all expanded levels.

2. Memory Growth During Storm

Time	JS Heap	Page Memory	Total	Notes
t=8.62s	252 MB	316 MB	589 MB	Before scroll
t=9.13s	287 MB	364 MB	672 MB	Storm begins
t=9.63s	315 MB	373 MB	709 MB	Process killed

• JS heap growth rate: +68 MB/s during the storm
• Total memory growth rate: +120 MB/s
• A full GC at t=8.78s ran for 148ms and reclaimed zero bytes — all microtask-created objects are still live/reachable

3. Main Thread Blocking

Time	Duration	Event	Description
t=5.57s	915ms	requestAnimationFrame	Full React reconciliation of all tree nodes
t=9.72s	1,140ms	frame blocked	Microtask storm + timer batch
t=11.31s	167ms	gotpointercapture	Scroll-start handler

98% of frames are dropped during the crash window (194/198 frames exceed the 16.7ms budget).

4. Heap Snapshot (1,035,974 live objects)

Object Type	Count	Self-size	Concern
string	193,261	53.4 MB	JSON tree-data strings never freed
Function (closures)	233,260	7.3 MB	Per-node render closures re-created
FunctionExecutable	85,917	10.5 MB	Compiled function objects
JSLexicalEnvironment	53,990	2.9 MB	Closure scope chains

The 233K live closures suggest per-node function objects are created during tree data loading/rendering and are never released — even for nodes that have been scrolled out of view. There is no eviction of off-screen node data.

Suggested Fix

Option A — Time-slice the data loading

Break the Promise.all() chains in ModelsTreeIdsCache to yield back to the browser event loop between chunks:

// Instead of:
return Promise.all(loadingMapEntries);

// Yield between chunks:
async function loadInChunks(entries: Promise<void>[], chunkSize = 50) {
  for (let i = 0; i < entries.length; i += chunkSize) {
    await Promise.all(entries.slice(i, i + chunkSize));
    // Yield to the browser to prevent microtask starvation
    await new Promise(resolve => requestAnimationFrame(resolve));
  }
}

This would reduce microtasks per frame from 210,000 to <500.

Option B — Implement virtual data loading with eviction

Only load and retain data for nodes within (or near) the visible scroll viewport. Evict node data for nodes far from the current scroll position. The GC currently reclaims nothing because all loaded data remains reachable.

Option C — Cap microtask depth per batch

Add an internal safeguard that limits the number of concurrent Promise chains, regardless of hierarchyLevelSizeLimit.

Workaround

Reducing hierarchyLevelSizeLimit from 10,000 to a lower value (e.g., 1,000) mitigates the issue but doesn't eliminate it — it only reduces the scale of the microtask storm. The underlying unbounded-Promise-chain pattern remains.

Impact

This is a crash on iOS devices (WKWebView). The web content process is terminated by the OS, not by a handled JavaScript exception. It is reproducible with any model containing a sufficiently large tree hierarchy.

Desktop browsers are less affected because they have higher memory limits, but the same performance degradation (915ms rAF, 98% frame drops) still occurs.

Timeline Recording Data

We can provide the full Safari Web Inspector timeline recording (149 MB JSON, 13.68s capture) on request for detailed profiling.

[saskliutas]

Small update: looks like I managed to reproduce this on my iPad in a browser. After scrolling tree for sometime page just reloads.

Just to clear up some things: previous comment suggest that issue is coming from ModelsTreeIdsCache.js. I looked into it and lines highlighted as culprits are not hit during crash. (it needs to be filtered tree for that code path to take actions).

Additionally it looks like this is not related to visibility checkboxes and determining status as I managed to crash page with visibility controls disabled.

[saskliutas]

Looks like the issue is coming from iTwinUI Tree component. Created issue iTwin/iTwinUI#2679