tray.sh in-place fast-path silently broken on 1.13576+ (yukonSilver rebuild refactor) → #515 duplicate-icon race re-arms

[aaddrick]

Summary

patch_tray_inplace_update in scripts/patches/tray.sh stopped applying on Claude Desktop 1.13576+ (the "yukonSilver"-era refactor; verified against the current detect-host.sh target 1.15962.0). Because tray patches warn-and-continue (the #429 class), it ships through green CI — the in-place fast-path is simply gone, which re-arms the #515 KDE/Plasma duplicate-icon StatusNotifier race documented in docs/learnings/tray-rebuild-race.md.

Surfaced while investigating #746 (Cinnamon empty-icon). Note: this is not the root cause of #746 — the core icon-selection patch still applies on both 1.15200.0 and 1.15962.0 — but it's a real latent regression found in the same area.

What changed upstream

Extracted the real 1.15962.0 app.asar and ran tray.sh's extraction against the shipped minified index.js.

1. The destroy/recreate guard restructured. Old shape the injection anchored on:

;if(TRAY&&(TRAY.destroy(),TRAY=null)…

New shape (state resets hoisted into the if):

const t=X.join(toi(),e),i=!xrt;if(A9=[],e9=!1,vE&&(vE.destroy(),vE=null),!A){JhA();return}

The regex anchor ;if\(TRAY&&\(TRAY\.destroy\(\) no longer matches.

2. Context menu is now a prebuilt object, with a null decoy. Old: setContextMenu(BUILDER()). New: the menu is built once (yh=S5A()) and set by name, and the first setContextMenu call site is a menu-clear:

…vE.setContextMenu(null)…           // invalidation clear  ← FIRST in file order
…yh=S5A(),…vE.setContextMenu(yh)…   // the real one; builder is S5A()

The resolver's head -1 latched the null clear, so the builder never resolved → the #680 WARNING: could not resolve tray menu function fires and the fast-path is skipped.

Not a regression: patch_menu_bar_default

Worth recording so it isn't "fixed" twice: upstream now reads menuBarEnabled through a settings getter backed by a defaults map that already ships menuBarEnabled:!0 (true):

Di=A=>{const e=tg().preferences??{}; …; return {...Bpt,...e,...A}[A]}
Bpt={menuBarEnabled:!0, …}

So the legacy !!var → var!==false rewrite is a no-op by design, not a behavior regression — the tray still defaults on.

Fix

On branch claude/review-open-issues-prs-d4cjs6 (commit 6091615):

• Menu-function resolver walks every setContextMenu argument, skips the null clear, and takes the first that resolves to a VAR=BUILDER() assignment (→ S5A).
• Injection switched from the backslash-heavy regex to locating TRAY.destroy() and walking back to the ;if( that opens its statement — lands correctly in both old and new shapes.
• patch_menu_bar_default now distinguishes the upstream-defaults-map case from a genuine miss, warning loudly only if neither the legacy anchor nor menuBarEnabled:!0 is present.
• New tests/tray-patches.bats (7 cases): builder resolution past the null decoy, injection placement + valid JS, idempotency, loud-fail on a missing destroy site, and the three menu-bar-default branches. Full suite 329/329.

Verified end-to-end against the real 1.15962.0 asar (patched output passes node --check, fast-path lands before the destroy block, idempotent on re-run).

Remaining

The whole point of the fast-path is StatusNotifier timing on Plasma, so runtime confirmation of the #515 race avoidance still needs a KDE Plasma host before merge. Flagging for on-device verification.

---

Written by Claude via Claude Code

[github-actions]

Automated draft — AI analysis, not maintainer judgment. This bot won't close issues, apply labels beyond triage routing, or claim fixes are shipped. Findings below are starting points; the code citations are what to verify first.

Looks like the fallback setContextMenu grep in patch_tray_inplace_update latches on the literal string null from a null-clear call that precedes the real menu-variable calls, causing menu_func to go unresolved, the fast-path to be silently skipped, and the #515 KDE Plasma duplicate-icon race to be re-armed on 1.15962.0.

• Worth checking first: the null-clear vE.setContextMenu(null) inside GBe() appears at reference-source line 514245 — before the real vE.setContextMenu(yh) calls at lines 514252 and 514312 — confirming the file-order that makes head -1 in the fallback grep latch on null rather than the intended yh. (reference-source/.vite/build/index.js:514245-514245)
• Looks like the fallback setContextMenu grep in patch_tray_inplace_update captures the literal string null from the null-clear call vE.setContextMenu(null) because null lexically matches [\$\w]+ and the null-clear at reference-source line 514245 precedes every real setContextMenu(yh) call, so head -1 latches on null as menu_var. (scripts/patches/tray.sh:127-128)
• Appears that with menu_var resolved to the string null, the builder-resolution grep (?<![\$\w])null=\K[\$\w]+(?=\(\)) can never match because null is a JS keyword and cannot appear on the left-hand side of an assignment — so menu_func remains empty, the WARNING block fires, and the function returns without applying the fast-path, re-arming the fix: update Linux tray icon in place on OS theme change #515 StatusNotifier race. (scripts/patches/tray.sh:135-136)
• Appears that the 1.15962.0 destroy/recreate block now opens with comma-expression state resets — if(A9=[],e9=!1,vE&&(vE.destroy(),(vE=null)),!A) — rather than the old ;if(TRAY&&(TRAY.destroy(),TRAY=null) shape that the tray.sh anchor was written against, as confirmed by reference-source line 514296. (reference-source/.vite/build/index.js:514296-514296)
• Likely that even if the menu-function resolution were fixed, the Node.js destroy anchor ';if\\(' + reEsc(T) + '&&\\(' + reEsc(T) + '\\.destroy\\(\\)' — which requires if(vE&&(vE.destroy( to open the condition — would not match the 1.15962.0 upstream shape where state resets precede the tray guard, making this a latent hard-fail (exit 1) currently masked by the early return from the first bug. (scripts/patches/tray.sh:227-229)

Related: #515 — exact, #429 — exact, #680 — related

Full investigation artifacts (investigation.json, validation.json) are attached to the triage workflow run.

[icb088]

Hi,
not sure if this is the right issue but I've detected that the tray icon under debian 13 gnome was changed after updating to Claude 1.15962.1 (1e236d) - instead of the "normal" claude icon (also used as desktop icon) there are now three dots (the context menu is still working like before) ...
Is this a bug or a feature ;) ?
BR, Christian