### System details

Ryzen 5600x with 3060ti and 32 gb of ram 

### What's wrong?

There appears to be a race condition in the Omarchy bar's System Tray handling that can cause some right-side bar widgets to have incorrect click/hit areas.

The visual position of the widgets remains correct, but their effective clickable area can shift toward the absolute top edge of the screen. As a result, clicking directly on the visible widget may not work.

The issue can affect:

- System Tray
- Dropbox
- Tailscale
- Agents
- Audio / Speaker

Interestingly, some other right-side widgets such as Network and Monitor can remain clickable normally.

### Observed behavior

The problem is intermittent but reproducible during System Tray activity.

Examples of behavior observed:

1. After the issue appears, clicking a visible Tray/Dropbox/Tailscale/Agents/Audio widget may not trigger it.
2. Moving the mouse to the absolute top edge can make the click register.
3. Right-clicking a Telegram or Discord tray icon can immediately restore normal click behavior.
4. Closing the tray menu does not necessarily reintroduce the problem.
5. Quitting a tray application can cause the problem to return after a short delay.
6. Restarting/reloading the Omarchy shell fixes the issue.
7. Changing the bar position also temporarily fixes the issue.
8. Telegram and Discord tray menus can sometimes appear as a blank popup (popup frame visible but menu entries missing).

### Environment

- Omarchy: 4.0.2-1
- Hyprland: 0.56.2
- Quickshell: current Omarchy-provided version
- Wayland
- Single monitor
- 1920x1080 @ 144 Hz
- NVIDIA RTX 3060

### Source-code investigation

A detailed source-code investigation was performed using OpenCode.

The relevant path appears to be:

```text
SystemTray.items
    ↓
Tray.qml Repeater/model changes
    ↓
Tray implicitWidth changes
    ↓
RightModules Row relayout
    ↓
ModuleSlot geometry changes
    ↓
moduleClickTargetAt()
    ↓
slot.mapToItem(...)
    ↓
incorrect effective click target

The relevant source locations identified during the investigation include:

Tray.qml:167-181 — SystemTray model/bucketing
Tray.qml:286-310 — Tray Repeaters
Tray.qml:215-216 — Tray implicit width
Bar.qml:1134-1138 — RightModules Row
Bar.qml:1543-1584 — ModuleSlot geometry
Bar.qml:762-782 — click target calculation

The investigation also found that tray menu opening currently does this:

resetTrayMenu()
activeTrayItem = item
activeTrayAnchor = anchorItem
trayMenuOpen = true

while the menu model is obtained asynchronously through:

activeTrayItem.menu
    ↓
QsMenuOpener
    ↓
QsMenuOpener.children
    ↓
Repeater

Relevant locations:

Tray.qml:516-519 — trayMenuOpener.menu
Tray.qml:50-52 — currentChildren
Tray.qml:644 — menu Repeater
Tray.qml:117-132 — openTrayMenu()

This means the popup can become visible while QsMenuOpener.children is still being populated.

Suspected root cause

The strongest current explanation is a QML model/layout lifecycle race involving the System Tray and tray menu popup.

During dynamic tray model changes, Tray Repeaters can be regenerating while the right-side bar Row is being laid out.

At the same time, openTrayMenu() can make the popup visible before the asynchronous DBus menu model has finished populating.

This can result in:

Tray model transition
Repeater regeneration
Right-side Row relayout
Popup becoming visible
Additional QML polish/layout work
Temporary/inconsistent geometry
Incorrect click-target mapping

The blank Telegram/Discord menu appears to be another manifestation of the same lifecycle race: the menu Repeater can initially receive an empty QsMenuOpener.children model.

Important clarification

The source-code relationship is strongly established, but the exact runtime transition of the internal PanelWindow/QWindow input mask could not be directly inspected because the running Quickshell instance was not started with the QML debugger.

Therefore:

The QML model/layout race is strongly supported by source analysis.
The exact internal hit-region/mask transition is not directly runtime-proven.
The observed user-facing behavior strongly correlates with the source-code lifecycle described above.
Proposed minimal fix

A minimal fix would be to defer opening the tray popup until QsMenuOpener.children has been populated.

Conceptually:

activeTrayItem = item
activeTrayAnchor = anchorItem

function tryOpen() {
    if (trayMenuOpener.children &&
        trayMenuOpener.children.count > 0) {
        trayMenuOpen = true
    } else if (trayMenuOpener.menu) {
        trayMenuOpener.childrenChanged.connect(
            tryOpen,
            Qt.SingleShotConnection
        )
    }
}

tryOpen()

This should allow the menu Repeater to receive a populated model before the popup becomes visible and avoid triggering popup-related layout/polish while the model is still transitioning.

Why this may address both symptoms

Blank menu:

DBus menu
    ↓
QsMenuOpener.children populated
    ↓
Repeater receives populated model
    ↓
menu delegates render

Bar click-area issue:

Tray model settles
    ↓
right-side Row finishes layout
    ↓
popup opens
    ↓
layout/polish occurs on stable geometry
Requested fix / investigation

Please investigate and fix this race condition in the official Omarchy bar implementation.

Ideally the fix should:

prevent blank System Tray menus;
keep bar widget hit areas aligned with their visual positions;
handle asynchronous DBus menu population safely;
preserve submenu behavior;
avoid modifying unrelated bar widgets;
avoid introducing blocking waits or event-loop stalls;
remain compatible with future Omarchy updates.

A minimal fix in Tray.qml appears preferable to changing Quickshell core or the general bar hit-testing system.

Reproduction

The issue can generally be reproduced by repeatedly adding/removing or interacting with tray applications such as Telegram/Discord and then testing the right-side bar widgets.

Useful observations:

Bug active
    ↓
Right-click Telegram/Discord tray icon
    ↓
bar click areas immediately recover

and:

Bug active
    ↓
Quit tray application
    ↓
bug may return after a short delay

The tray menu may also occasionally appear as a blank popup.

Additional note

The Agent widget appears to be an affected sibling rather than the cause. It does not use the System Tray/DBusMenu path and is simply positioned in the same right-side Row.