[Bug] Battery icon position keeps resetting to the front

[akfroman]

Pre-submission Checklist

• I searched existing issues (open & closed) and found no duplicates
• I'm using the latest app version

What happened?

No matter where I move the battery icon, after time, it resets and moves to be the first icon in the menu bar, including before the Thaw icon.

Steps to Reproduce

Move the battery icon and wait

Expected Behavior

When I move the battery icon, it should stay where it is.

App Version

2.0.0 rc1

macOS Version

26.5.2

Display Setup

Multiple monitors

Logs / Console Output

thaw_2026-07-16_06-57-39.log

Additional Context

No response

[lathe-agent-oa]

Pulled apart your attached log (thaw_2026-07-16_06-57-39.log, 06:57:39–07:01:31) — this looks like a known identity-resolution failure chain, and your report is a useful new manifestation of it.

What the log shows:

1. Identity instability on the Stats battery widget. Repeated SourcePID changed for windowID 33: 958 -> 94863, reverting to previous PID (06:58:34, 07:01:16, 07:01:31). windowID 33 is eu.exelban.Stats:Battery, and PID 958 is Control Center (the log elsewhere says Skipping Control Center window: PID 958). So the widget was at some point geometrically attributed to Control Center's PID, and the revert-guard then keeps re-pinning that earlier attribution instead of accepting the correction.

2. Every windowID-set change triggers a full re-apply. cacheItemsIfNeeded: window IDs changed (18 cached vs 17 current) → applySavedLayout: dispatching bulk apply (windowID change) — twice in the last 15 seconds of the log alone.

3. The re-apply then can't place the widget. Moving <eu.exelban.Stats:Battery…> to left of <com.microsoft.rdc.macos:Item-0> → Attempt 7 events succeeded but item not at destination, retrying → Profile layout: failed to move eu.exelban.Stats:Battery: EventError.cannotComplete → move: all 8 attempt(s) exhausted without verifying … reached left of. Synthetic moves are dispatched and report success as events, but placement never verifies — the item is left where the failed sequence dropped it, which matches your "resets to the front."

Observed vs inferred: 1–3 are verbatim from your log; the inference is that the pinned misattribution in (1) is what breaks move targeting/verification in (3).

This intersects three open threads:

• Parked (off-screen) items whose title is their bundle identifier are unresolvable — one-way door into the hidden section #795 documents the same geometric-proximity misresolution for parked (hidden) items; your log is the visible-item variant — misattribution to an adjacent/system window while on screen.
• fix(menubar): keep menu bar move events out of screen corners #774 (open PR) addresses synthetic-move unreliability on multi-display setups, which matches the EventError.cannotComplete / exhausted-attempts pattern here (you're on multiple monitors).
• fix(menubar): skip saved-layout bulk apply while sourcePIDs are unresolved #785 (open PR) gates saved-layout bulk applies while item identities are unstable — your log shows exactly that unstable-identity + bulk-apply combination. rc.1 also predates the multi-display layout fix merged after it (fix(menubar): defer saved-layout apply/persist on unsettled or cross-display geometry and clear stuck profile flag #743), so a future rc.2 should already behave better.

Possible workaround meanwhile: in Stats → Settings, enable "Combined modules" — it merges Stats' widgets into one menu bar item, which reduces the identity churn that starts this chain.

One clarifying question: is the icon that resets Stats' battery widget, or macOS's own (Control Center) battery icon? The log evidence points at eu.exelban.Stats:Battery, but confirming would help whoever picks this up.

[akfroman]

It is the macOS battery icon that keeps moving. The Stats icon stays in place in the hidden section.

[lathe-agent-oa]

Thanks — that clarification sharpens the picture, and it makes your log more telling, not less.

You have two battery items in the bar: macOS's own (com.apple.controlcenter:Battery, both it and BentoBox-0 appear in your log) and Stats' battery widget. The repeated warning in your log — SourcePID changed for windowID 33: 958 -> 94863, reverting to previous PID, where PID 958 is Control Center — is Thaw's identity resolver flip-flopping a single battery window's ownership between Control Center and another process. With two visually adjacent battery icons, the geometric matching (nearest AX frame) has two nearly identical candidates, so which window gets which identity is unstable. That would also explain why the failed moves in the log name eu.exelban.Stats:Battery while the icon you see moving is the macOS one: if the identities are crossed, Thaw can be dragging or verifying against the wrong battery window.

The trigger fits too: macOS recreates the Control Center battery window on power-state changes (plug/unplug, percentage display updates), which shows up in your log as cacheItemsIfNeeded: window IDs changed (18 cached vs 17 current) — and each of those recreations fires applySavedLayout: dispatching bulk apply (windowID change) with a possibly-crossed identity map. A recreated system item that fails placement lands at a default slot, which matches "resets to the front."

All of that is inference on top of the log, so two cheap experiments would confirm or kill it:

1. Separate the two battery icons — move Stats' battery widget several positions away from the macOS one (or temporarily disable the Stats battery module). If the misattribution theory is right, the macOS battery should stop resetting once the two aren't adjacent.
2. Watch for correlation with power events — does the reset happen right after plugging/unplugging or a battery-percentage change? That would confirm the window-recreation trigger.

If experiment 1 fixes it, that's strong evidence for the adjacent-window identity-confusion class tracked in #795 — worth noting there. One honest caveat: the title-identity fallback proposed in #797 would not cover this case (Control Center window titles aren't bundle-id-shaped), so if this reproduces it argues for a stronger stable-identity mechanism for system items specifically.

[akfroman]

1. The battery icons were never next to each other. At least visually, maybe they were logically. But disabling stats seemed to stop the resets. Here's a screenshot of the desired layout.

2. Changing power events does not seem to trigger the icon position reset.

[lathe-agent-oa]

Both experiments came back against my hypothesis, and the replacement fits your log better.

What they rule out: the two battery icons were never adjacent, so on-screen nearest-neighbor confusion between them isn't the mechanism, and no correlation with plug/unplug kills the Control-Center-window-recreation trigger. Both were my hypotheses and both are wrong.

What survives is that disabling Stats stops the resets. Combined with your earlier note that the Stats icon "stays in place in the hidden section," that points at a failure already tracked in #795.

SourcePIDCache resolves ownership by finding an AX element near the CG window's coordinates. An item parked in the hidden section sits at large negative x — in #795's log, bounds=(-5724.0, 0.0, 68.0, 33.0) — where no AX child is available to match, so the pass settles on whatever candidate is nearest in its own coordinate space, which can be an unrelated on-screen item. In #795 that nearest candidate was 993pt away and belonged to a different app entirely.

Seen from outside, that is what SourcePID changed for windowID 33: 958 -> 94863, reverting to previous PID looks like: one window's ownership oscillating between Control Center (958) and another process. The two batteries never need to be near each other on your menu bar, because the distance that matters is inside the resolver's geometry, not on screen. It also explains the Stats dependency without power events: the churn comes from Stats' own widget re-registration rather than from Control Center.

Observed: the log lines above, and your two experiment results. Inferred: that a parked Stats battery is the item being misresolved, and that the resulting crossed identity is why moves target and verify against the wrong battery window. The 993pt figure is from #795, not from your log.

Three things would confirm or kill this:

1. Which section is Stats' battery widget in — hidden, always-hidden, or just further right in visible? I read your earlier comment as "parked in Thaw's hidden section," but I would rather check than build on a misreading.

2. The discriminating test: re-enable Stats, but put its battery widget in the visible section, anywhere. If the resets stop while Stats is running and visible, the parked-item explanation holds. If they continue, it is wrong and something else about Stats is responsible.

3. A fresh diagnostic log with Stats re-enabled, ideally spanning a reset.

If (2) comes back clean, your report is a second machine independently showing the #795 class, which matters more than the battery symptom itself: #795 currently rests on one machine and one widget.

One caveat I owe you. The fix in #797 would not help here. It resolves parked items whose window title is their own bundle identifier, and Control Center's windows are not titled that way. If this holds up, it argues for a stable-identity mechanism for system items rather than more geometry.