Skip to content

Unify divergence screen capture with snapshot's full-window scope (separate-window overlays invisible to repair; #1256 follow-up) #1264

Description

@thymikee

Follow-up from a live investigation for #1256 (merged) — the "actionable SystemUI overlay preservation" question. Ran a fresh #1256-branch daemon (418fa7e5 + snapshot-helper) against emulator-5560 (Pixel API 36) with the test-app.

Finding 1 — the get-divergence capture is app-window-scoped; separate-window overlays aren't captured

  • In-app-window systemui (status bar) IS captured and correctly filtered by fix: Android status/nav-bar systemui chrome leaks into non-raw captures (#1251) #1256: the plain app-home --raw capture is 77 app + 29 com.android.systemui nodes (clock, battery, mobile_*, statusIcons, status_bar* — exactly the chrome leaf-ids fix: Android status/nav-bar systemui chrome leaks into non-raw captures (#1251) #1256 filters).
  • Separate-window actionable overlays (volume dialog, expanded quick-settings) are NOT captured by the divergence at all. Verified airtight:
    • Volume dialog held up across the capture (background key-repeat; VolumeDialog window confirmed present) → divergence screen.refs = 20 app-content refs, zero volume/systemui nodes.
    • Quick-settings shade persistent (up before and after the replay) → divergence screen.refs = 0.
    • A plain snapshot at the same moments does capture them (26 systemui/volume nodes incl. a hittable volume_new_ringer_active_icon_container).

So the divergence surfaces the app-under-test's window (+ its in-window decor like the status bar), not independent system overlay windows.

Finding 2 — the synthetic id in the unit test isn't the live id

The snapshot-chrome-android-statusbar test splices a synthetic volume_dialog_container / volume_dialog_slider. Live, the volume dialog is: volume_dialog_container (✓ matches), volume_dialog, volume_dialog_top_container, volume_ringer_and_drawer_container, volume_new_ringer_active_icon_container (hittable). There is no volume_dialog_slider id in the live tree.

Implication (not a regression)

The #1256 fix is correct — it stops passive status-bar chrome (which does overlay the app window) from leaking into divergence refs. But the unit test that asserts "a synthetic volume_dialog_* overlay survives the non-raw walk" is a valid filter-logic unit test, not evidence of a live integration path: live, such separate-window overlays never reach the filter (app-scoped capture), so "actionable SystemUI overlay survives in divergence refs" is moot for them.

Suggested

  1. Reword the test's comment to state it exercises the filter in isolation, not a live capture path.
  2. Fix the synthetic volume_dialog_slider id (use volume_new_ringer_active_icon_container or a real seekbar id), or drop the specific id claim.

Evidence JSONs archived under ~/.agent-device-bench/wave3/E4/.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions