Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Tray menu renders empty after extended uptime: icon failures are swallowed silently

Open
  • Is something wrong?
#1,567 1 comment 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
desktop

Research direction

Start with src/OpenClaw.Tray.WinUI/Windows/TrayMenuWindow.xaml.cs:571 and Helpers/FluentIconCatalog.cs:118, then inspect WindowManager's cached window fields and popup lifecycle. Reproduce on the shipped 2026.9.4.0 binary using EnumWindows and GetGuiResources before and after restart. Done means the icon failure is diagnosable, the empty tray menu and PopupWindowSiteBridge accumulation are addressed or precisely explained, and the UI validation is reported.

Written by the indexing model from the issue text.

Description

clawsweeper:needs-info clawsweeper:needs-maintainer-review clawsweeper:no-new-fix-pr impact:ux-friction issue-rating: 🦪 silver shellfish P2

Summary

After roughly 90 minutes of continuous uptime, right-clicking the tray icon opens the menu window but it renders empty: no icons, no menu rows. The UI thread is still pumping (Responding=True), so this is not a hang.

Restarting the process restores it immediately.

Evidence: before/after restart

Metric Fresh process After ~90 min
Orphaned Microsoft.UI.Content.PopupWindowSiteBridge windows 0 3 (parked at -32000,-32000)
GDI objects 64 211 (+1.6/min)
USER objects 67 93
Working set 228 MB 416 MB

PopupWindowSiteBridge is the host window WinUI 3 creates for Popup/Flyout. These three survive after the tray menu closes and are never destroyed. Extrapolating the rate, GDI objects reach ~700 after about 7 hours.

Root cause

Icon construction failures are silently swallowed. src/OpenClaw.Tray.WinUI/Windows/TrayMenuWindow.xaml.cs:571:

var iconElement = ResolveIcon(icon);
if (iconElement != null)          // line 572
{
    ...
    Grid.SetColumn(iconElement, 0);
    grid.Children.Add(iconElement);
}

When null, nothing is added, nothing is thrown, nothing is logged. The row renders with an empty icon column.

Icons all funnel through src/OpenClaw.Tray.WinUI/Helpers/FluentIconCatalog.cs:118:

public static FontFamily SymbolThemeFontFamily =>
    (FontFamily)Application.Current.Resources["SymbolThemeFontFamily"];

59 call sites across the tray menu, chat, settings and nav all depend on this one property. It indexes the resource dictionary directly with no null check, no try/catch, and no fallback.

Supporting observation: OpenClaw.Tray.WinUI.pri contains the key name SymbolThemeFontFamily (next to BrandMark / TitleText / NavBackButton) but not the literal Segoe Fluent Icons. The font mapping is expected to be injected by the WinUI runtime during Application.Start, which is exactly where the native popup/GDI accumulation happens.

The same resource failure is visible in the log, repeating on every run:

[WARN] LocalizationHelper: Resource lookup failed for 'Chat_Composer_Slash_Loading' (language='<default>'): NamedResource not found

Suggested direction

  1. Add a fallback to SymbolThemeFontFamily: on lookup failure, fall back to new FontFamily("Segoe Fluent Icons"), or resolve to null and let Build return an icon without an explicit FontFamily so the default font fallback applies.
  2. Icon construction failure should not be silent. At minimum log one WARN on first failure so this is diagnosable.
  3. Track down the popup resource leak. PopupWindowSiteBridge windows are not destroyed when a Flyout closes, and WindowManager holds _chatWindow / _hubWindow / _trayMenuWindow as cached singletons with no invalidation strategy. Give them a resource-health check.

Impact

Long-running users see an empty menu with no error surfaced, which is very hard to self-diagnose. A restart clears it.

Required proof pools

  • UI (tray UX)

Validation

Report, not a code change. Window enumeration via EnumWindows plus GetGuiResources on the shipped 2026.9.4.0 binary, before and after restart.

Dominant language
C#
Stars
2.1k
Forks
315
Avg merge
2d 1h
Merged PRs (30d)
127

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openclaw/openclaw-windows-node

All issues in openclaw/openclaw-windows-node

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.