Wireframe replay: all windows share one `$window_id` (= session id), so any `Dialog`'s full snapshot wipes the Activity for the rest of the session

[kleyow]

Environment

• com.posthog:posthog-android:3.60.5 (core com.posthog:posthog:6.13.0)
• Session replay in wireframe mode (config.sessionReplayConfig.screenshot = false)
• Reproduced against 3.43.1, 3.60.4, and 3.60.5 — the behaviour is identical across all three (details below verified against the 3.60.5 AAR bytecode).

Summary

An Android Dialog is a separate window with its own decor view. posthog-android snapshots each window independently and correctly, but every window's events are emitted under one $window_id, which is just the session id. PostHog's player keeps one document per window id, and an rrweb full snapshot resets that document (mirror.reset() + document.open()/close()). So the moment a dialog emits its full snapshot, it replaces the Activity's tree in the player, and the Activity never re-sends a full snapshot to recover — every subsequent mutation targets node ids that no longer exist and is dropped. In wireframe mode (one ~50-node tree + diffs) this loses the rest of the session; the more an app uses dialogs, the emptier its replays.

Mechanism (verified against 3.60.5 bytecode)

SDK side — each window is tracked separately, but there is no window id.

• PostHogReplayIntegration holds private final Map<View, ViewTreeSnapshotStatus> decorViews — one entry per decor view (i.e. per window).
• ViewTreeSnapshotStatus carries a per-window private boolean sentFullSnapshot (+ getSentFullSnapshot()/setSentFullSnapshot()) and its own lastSnapshot: RRWireframe.
• generateSnapshot$posthog_android_release(WeakReference<View>, WeakReference<Window>, boolean) reads getSentFullSnapshot() and sets it — so each window emits one full snapshot, then diffs against its own private tree. Internally consistent per window.
• There is no window-id concept anywhere in the replay integration — grepping every class in com/posthog/android/replay/ for window_id/windowId returns nothing. The $window_id property is set once, in core com.posthog.PostHog, to PostHogSessionManager.getActiveSessionId() — i.e. the session id, identical for every window in the session.

Player side — a full snapshot is absolute, so the dialog wipes the Activity.

• One Replayer per $window_id; since every window shares the session id, the Activity tree and every dialog tree land in the same document/timeline.
• A full snapshot there runs this.mirror.reset() then rebuilds, and the Document node does doc.close(); doc.open() — the entire prior document is thrown away.
• The Activity's own sentFullSnapshot is still true, so it never re-sends a full tree the player could anchor to. Its later mutations reference dead ids, and applyMutation drops orphaned adds silently (parentIdInCurrentBatch ? queue.push(mutation) : undefined); removes only log a warning that's suppressed by default. The mobile→web transformer turns each update into a remove plus a re-add, so one update to a stomped node yields two orphans.

Evidence

Measured on 24 production wireframe sessions (>10 interactions each). Each session's mutations were replayed twice — once against a single merged document (what the player does), once against one document per window (what a correct window id would give):

model	dropped mutations
merged (current player behaviour) — median	97%
merged — 21 of 24 sessions	≥ 45%
per-window control — 22 of 24 sessions	0%

The per-window 0% is the load-bearing number: the SDK's per-window streams are internally consistent, and the shared window id is what destroys them in the merge.

A minimal synthetic before/after over PostHog's own mobile→web transformer shows the same fingerprint — a stomped capture is 80% unappliable merged / 0% per-window, a healthy one is 0%/0%.

(Raw session payloads are user data and are deliberately not attached; the repro below reproduces it from scratch.)

Minimal reproduction

A single Activity that shows a Dialog a few seconds after it's on screen. Point it at any project, open the replay: the Activity content vanishes the instant the dialog appears and never returns. In the payload, both the Activity's and the dialog's full snapshots carry the same $window_id.

// App.kt
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        val config = PostHogAndroidConfig(apiKey = "<YOUR_PROJECT_API_KEY>", host = "https://us.i.posthog.com").apply {
            sessionReplay = true
            sessionReplayConfig.screenshot = false // wireframe mode
        }
        PostHogAndroid.setup(this, config)
    }
}

// MainActivity.kt
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // A recognisable Activity tree so the stomp is obvious in the replay.
        val root = LinearLayout(this).apply { orientation = LinearLayout.VERTICAL }
        repeat(12) { i -> root.addView(TextView(this).apply { text = "Activity row $i" }) }
        setContentView(root)

        // Show a Dialog AFTER the Activity has been snapshotted. Its full snapshot,
        // under the same $window_id, wipes the Activity from the player's document.
        Handler(Looper.getMainLooper()).postDelayed({
            AlertDialog.Builder(this)
                .setTitle("A dialog")
                .setMessage("This dialog's full snapshot replaces the Activity in the replay.")
                .setPositiveButton("OK", null)
                .show()
        }, 4000)
    }
}

AndroidManifest.xml: android:name=".App", MainActivity as launcher. Dependency: implementation("com.posthog:posthog-android:3.60.5").

Observed: the replay shows the 12-row Activity until ~4s, then the dialog appears and the Activity content disappears for the remainder — matching the production symptom.

Proposed fix

1. (Real fix) Emit a distinct $window_id per decor view. This matches the semantics the player already implements — one Replayer per window id, which knows how to segment between windows — and makes dialogs render as their own segment instead of overwriting the Activity. The SDK already tracks windows separately (decorViews), so it has the identity to hand; it just isn't put on the events.
2. (Minimal mitigation) When the set of tracked windows changes, reset the other windows' sentFullSnapshot so the stomped tree re-sends a full snapshot and the player recovers. Cheaper, but still only one window renders at a time.

Option 1 is the correct fix. Neither 3.43.1, 3.60.4 nor 3.60.5 behaves differently here, so this isn't addressed by any recent release. Happy to help verify a fix — we filed #721 (→ #722, shipped in 3.60.5) from the same app and can re-run our per-window measurement against a patched build.

[kleyow]

Confirming this also reproduces on the latest release, android-v3.61.1 (with core posthog 6.34.0) — checked against the published AAR bytecode, so it's not fixed by anything since 3.60.5:

• PostHogReplayIntegration.decorViews is still Map<View, ViewTreeSnapshotStatus> (per decor view), unchanged.
• Still zero window_id / windowId references anywhere in com/posthog/android/replay/ — no per-window id is emitted.
• Core com.posthog.PostHog still carries the single $window_id (the session id), identical for every window.

The 3.60.6 → 3.61.1 replay changes are unrelated (a Compose screenshot-discard fix in 3.61.1; a stop-after-internal-stop fix in 3.60.7). So the mechanism above holds byte-for-byte on the current release.

[dustinbyrne]

thanks for the report @kleyow, we'll take a look

[dustinbyrne]

I've (🤖) looked into this issue in depth, and here are my findings.

Bottom line

The report correctly identifies the immediate failure: Android emits independent Activity and Dialog snapshot histories into one PostHog replay stream, so a Dialog full snapshot replaces the Activity document and later Activity mutations refer to nodes that no longer exist.

However, giving every decor view a separate $window_id is not sufficient with the current replay architecture. The safest complete fix is:

Keep one PostHog $window_id, but make Android emit one coherent wireframe scene containing the Activity and its Dialog layers.

The existing $window_id = $session_id fallback is not inherently wrong. The actual invariant is:

One PostHog window ID must represent one internally consistent document history.

Android violates that invariant today because each decor view has private snapshot state while all of those histories are routed as one document.

Where $window_id fits

There are three separate layers here:

1. Android emits mobile replay events such as FullSnapshot and IncrementalSnapshot, containing wireframe trees.
2. PostHog attaches $window_id to the surrounding $snapshot envelope. It is PostHog routing metadata, not an rrweb event property. Replay processing maps it to an internal windowId and uses it to select/segment streams.
3. rrweb receives the selected event stream. rrweb does not know about $window_id; when it receives a full snapshot, it resets its current document and node mirror.

I also added a local Android integration characterization test around the production snapshot path. It confirms this sequence:

PostHog envelope ID: session-123
    Activity FullSnapshot

PostHog envelope ID: session-123
    Dialog FullSnapshot

PostHog envelope ID: session-123
    Activity IncrementalSnapshot

The Activity and Dialog use separate ViewTreeSnapshotStatus instances, but their final PostHog envelopes have the same routing ID. rrweb therefore sees:

Activity full
Dialog full          ← replaces the Activity document
Activity mutation    ← refers to nodes no longer present

Options considered

1. Small integrity fix: foreground-document handoff

Capture only the topmost/focus-owning decor in wireframe mode:

Activity becomes active → Activity FullSnapshot
Dialog becomes active   → Dialog FullSnapshot
Activity draws behind it → ignored
Dialog closes           → Activity FullSnapshot
Activity changes        → Activity IncrementalSnapshot

All envelopes retain the existing session-derived $window_id.

Advantages

• Android-only change.
• No wire-format, frontend, backend, or rrweb change.
• Prevents orphaned mutations.
• A static Dialog remains displayed until the restoration snapshot.
• Relatively small implementation.

Limitations

• It does not show the Activity behind a partial or translucent Dialog.
• Background animations are omitted.
• Non-focusable overlays are not represented.
• It fixes corruption, but it is not complete Dialog support.

This is a reasonable emergency mitigation, but not the complete solution.

2. Recommended: one composite wireframe scene

Treat the Activity and Dialogs as layers of one visible Android scene.

When a Dialog opens, emit one full snapshot containing ordered roots:

FullSnapshot
└── wireframes
    ├── Activity root
    ├── optional dim scrim
    └── Dialog root

The mobile full-snapshot format already accepts multiple top-level wireframes, and the current mobile transformer converts them into siblings in one rrweb document.

The timeline becomes:

Full:        Activity
Full:        Activity + dim + Dialog
Incremental: Activity changes beneath Dialog
Incremental: Dialog changes
Full:        Activity after Dialog dismissal

Every envelope continues to use the same session-scoped $window_id.

This fits the existing architecture because:

• PostHog sees one replay document.
• rrweb sees one valid document history.
• A static Dialog naturally persists between show and dismiss.
• Concurrent Android roots can both be visible.
• No rrweb-core or backend schema change appears necessary.
• The current mobile wireframe format is sufficient for an initial implementation.

A practical Android implementation would introduce integration-level scene state containing:

• ordered active decor roots;
• the latest already-masked wireframe for each root;
• one scene-level sentFullSnapshot and lastSnapshot;
• a topology generation to reject stale queued work; and
• one global capture/coalescing gate.

Behavior would be:

1. Preserve the current single-Activity fast path.
2. Cache the Activity's latest wireframe.
3. When a supported Dialog has its first valid tree, assemble Activity + Dialog and emit one complete composite full snapshot.
4. While the set/order of roots is stable, update the changed root's cache and diff the complete assembled scene.
5. On Dialog removal, immediately emit an Activity-only full snapshot rather than waiting for another Activity draw.
6. Discard queued captures produced for an obsolete topology generation.

For the first version, full snapshots should be used whenever roots are added, removed, or reordered. Incrementally adding a bare decor root is currently unsafe because it has no valid mobile parent node.

There are some Android fidelity details to handle:

• Preserve alpha in background colors; the current color conversion drops it.
• Apply the theme background fallback only to the base Activity, not transparent overlays.
• Represent FLAG_DIM_BEHIND as an RGBA rectangle immediately below the Dialog.
• Keep roots in deterministic bottom-to-top order.
• Detect or safely reject duplicate node IDs.
• Emit keyboard state once for the combined document.
• Globally coalesce captures so independently drawing windows do not repeatedly walk the whole scene.

3. Player-side native window layering

The alternative is to retain a separate $window_id per decor and add all the missing layer semantics:

• explicit show/hide lifecycle events;
• base-window association;
• bounds and stacking order;
• overlapping active intervals;
• multiple synchronized Replayers; and
• player-side composition of those Replayers.

This explains why the per-decor ID approach in #754 was not enough. A static Dialog could emit only:

Dialog Meta @ T
Dialog Full @ T

That creates a zero-duration PostHog window segment. The player currently selects one Replayer at a time and has no interval or stacking information with which to display that Dialog over the Activity.

Separate IDs isolate mutation histories, but they do not describe concurrent visibility.

A smaller player variant—separate IDs plus activation/deactivation while still selecting only one Replayer—could fix lifetime and corruption, but it would have the same visual limitations as the Android-only foreground handoff while requiring cross-stack changes.

A true layered-window player could be useful as a larger native-replay platform investment, but it is disproportionate for this Android wireframe issue.

Recommendation

I recommend implementing the composite wireframe scene under the existing session-scoped $window_id.

Use the foreground-handoff design only if an urgent corruption patch needs to ship before complete Dialog support. I would not revive the per-decor $window_id approach by itself: it maps concurrently visible Android layers onto PostHog's current mutually exclusive document-selection abstraction.

I would roll this out in stages:

1. Proof: transform and replay a mobile full snapshot containing Activity and Dialog roots, then verify that both coexist and later Activity mutations remain valid.
2. Android MVP: support PhoneWindow-backed Dialogs, use complete composite full snapshots on topology changes, diff the scene while topology is stable, and leave screenshot mode untouched.
3. Fidelity: preserve alpha, add dim scrims, validate nested Dialog ordering, and verify root ordering on real devices.
4. Optimization/expansion: consider a stable synthetic scene root, incremental root add/remove, a session-level node ID allocator, and broader PopupWindow support separately.

The release gate should include at least:

• a static Dialog remains visible without touches or unrelated events;
• Activity content remains visible behind partial/translucent Dialogs;
• Activity animations update without moving above the Dialog;
• dismissal restores a valid Activity tree;
• nested Dialogs preserve their order;
• no missing-node or destroyed-Replayer warnings occur;
• one $snapshot envelope routing ID is used throughout;
• the single-Activity path remains behaviorally and operationally unchanged;
• screenshot mode remains unchanged; and
• privacy masking is applied independently to every included root.

The main unresolved implementation risk is whether the current Curtains root list reliably reflects WindowManager Z-order across supported Android versions and OEMs. That should be validated on real devices before release.

[kleyow]

@dustinbyrne Thanks Dustin.

We went with option 1 adjacent solution earlier this week since it was a time sensitive ticket.
I'll see about getting your recommended solution implemented after confirming that the option 1 limitations are a blocker on our side.

Closing.