### System details

Ryzen 5600x with 32gb of ram and 3060 12gb varient 

### What's wrong?

I am experiencing a recurring issue in the Omarchy status bar where the visual positions of right-side modules remain correct, but their mouse click/input regions become offset after an application with a System Tray icon is exited from the tray.

The issue is reproducible with multiple tray applications, including:

- Discord
- Telegram

The problem is therefore not specific to either application. Both appear to act as triggers for the same System Tray item registration/unregistration lifecycle.

Affected right-side modules can include:

- System Tray
- Dropbox
- Tailscale
- Agent / Agent Plugin
- Speaker / Audio
- Other interactive right-side modules

A shell restart can temporarily restore correct click behavior, but the issue can recur when another tray item is subsequently removed.

---

# Environment

- Omarchy: 4.0.4-1
- Hyprland: 0.56.2
- Quickshell: current Omarchy-provided version
- GPU: NVIDIA RTX 3060
- Monitor: 1920×1080 @ ~144 Hz
- Monitor scale: 1
- `GDK_SCALE=1`

The current Omarchy/Hyprland configuration was audited before this investigation.

No modifications were made to the Omarchy status bar or Quickshell code during this investigation.

---

# Reproduction

A simplified reproduction is:

1. Start Omarchy normally.
2. Open Discord.
3. Discord registers a StatusNotifierItem/System Tray item.
4. Discord's tray icon appears in the System Tray.
5. Right-side status-bar modules initially work normally.
6. Exit/Quit Discord from its System Tray menu.
7. Discord unregisters its StatusNotifierItem.
8. The System Tray updates and its width changes.
9. The remaining right-side modules visually reflow into their new positions.
10. Some click/input regions no longer correspond to the visible module positions.

The same behavior has also been reproduced with Telegram.

This strongly suggests that the application itself is not the root cause; the common trigger is removal/unregistration of a System Tray item.

---

# Observed Behavior

The important characteristic is:

> Visual geometry appears correct, but input/click geometry can become stale or offset.

For example, after a tray item disappears:

```text
Visual:

[Tray] [Dropbox] [Tailscale] [Agent] [Speaker]
                         ↑
                    Looks correct

But the effective click areas can remain associated with previous geometry:

Visual position:
             [Dropbox] [Tailscale] [Speaker]

Potential input position:
         [Dropbox] [Tailscale] [Speaker]
              ↑
       shifted relative to visual item

As a result:

clicking an icon may do nothing
clicking may activate an adjacent module
the click target may appear vertically/horizontally displaced
restarting the shell can temporarily restore correct behavior
Forensic Investigation

The relevant Omarchy/Quickshell code was inspected without modifying it.

The investigation focused on:

System Tray model lifecycle
StatusNotifierItem registration/unregistration
Tray.qml
Repeater delegate lifecycle
ModuleSlot geometry
ModuleList layout
right-side module reflow
click-target registration
coordinate mapping
layer-shell/input-region handling
Suspected Event Chain

The observed behavior appears to follow this sequence:

StatusNotifierItem unregisters
        ↓
D-Bus StatusNotifierItemUnregistered
        ↓
Quickshell SystemTray removes item
        ↓
UntypedObjectModel changes
        ↓
SystemTray.items changes
        ↓
Tray.qml bucket() recalculates
        ↓
pinnedItems / drawerItems / allItems change
        ↓
Repeater delegates are destroyed/created
        ↓
Tray implicitWidth changes
        ↓
ModuleSlot implicitWidth changes
        ↓
ModuleList / Loader width changes
        ↓
Right-side Row reflows
        ↓
Visual scene graph reaches correct final positions
        ↓
Potential stale click/input geometry
        ↓
Click offset / wrong target / no response
Relevant Code Findings
1. Dynamic System Tray model

The System Tray is backed by a dynamic model.

When a StatusNotifierItem unregisters, the underlying model changes and the corresponding tray delegate can be destroyed.

This means that removing a tray icon is not just a visual state change; it changes the geometry of the Tray component itself.

2. Tray.qml dynamically rebuilds its item groups

The investigation found that Tray.qml uses the tray model to produce its pinned/drawer/all item collections.

Relevant area:

Tray.qml:167-181

The bucket() logic is re-evaluated when the tray model changes.

This causes the Repeater(s) responsible for tray delegates to update.

3. Tray width propagates into the entire right-side layout

The resulting dependency chain is approximately:

SystemTray.items
 → bucket()
 → Repeater
 → Tray implicitWidth
 → ModuleSlot implicitWidth
 → ModuleList width
 → right-side Row layout

Relevant bar layout area:

Bar.qml:1719-1814

Therefore, removing a single tray icon can change the geometry of every module positioned after the System Tray.

4. Click target registration does not appear to explicitly synchronize with every geometry change

WidgetButton.qml registers its click target around:

WidgetButton.qml:44-55

The investigation did not find an explicit mechanism that re-registers/recomputes the click target whenever the containing module slot changes geometry as a consequence of a dynamic tray model update.

This is significant because the Tray can cause a cascading layout reflow without the actual widget itself being recreated.

5. Click coordinate mapping

The bar uses moduleClickTargetAt around:

Bar.qml:992-1012

The mapping relies on coordinate conversion using mapToItem(...).

The concern is that the mapping can temporarily reference geometry from before the complete layout propagation has settled.

This provides a plausible explanation for the observed state where:

the rendered scene graph has the correct final position
but pointer hit testing/click target mapping can temporarily use stale geometry
6. Tray containmentMask

The investigation also found containmentMask definitions on the Tray's horizontal/vertical tray roots:

Tray.qml:242-253
Tray.qml:327-335

However, the investigation did not find these being used by the bar host as an authoritative input-region synchronization mechanism.

This may be relevant because there does not appear to be one single authoritative geometry source that atomically updates:

Module geometry
        ↓
MouseArea geometry
        ↓
click target coordinate mapping
        ↓
layer-shell input region

when the dynamic tray layout changes.

Why Visual Rendering Can Be Correct While Clicks Are Wrong

The likely explanation is that visual rendering and pointer input are not necessarily synchronized through the exact same update path.

A simplified sequence is:

QML binding updates
      ↓
Item x/y/width changes
      ↓
Scene graph renders new position

while pointer handling involves additional geometry/hit-testing and coordinate mapping:

Wayland pointer event
      ↓
surface-local coordinates
      ↓
QML hit testing
      ↓
MouseArea / click target
      ↓
coordinate mapping

If the Tray model change causes a cascading layout update, there may be a period where the rendered geometry has reached its new state while one or more input-related mappings have not yet been fully synchronized.

This would explain the specific symptom:

"The icons look correct, but clicking them behaves as if they were somewhere else."

Why Discord and Telegram Are Probably Not the Root Cause

The same behavior has been reproduced with both Discord and Telegram.

The common operation is:

Application has a StatusNotifierItem
        ↓
Tray icon exists
        ↓
Application exits
        ↓
StatusNotifierItem unregisters
        ↓
SystemTray model shrinks
        ↓
Tray geometry changes

Therefore, Discord and Telegram are more likely triggers than the underlying cause.

The same issue could potentially occur with any application that dynamically registers/unregisters a StatusNotifierItem.

Most Likely Root Cause
Most likely root cause: dynamic System Tray model changes causing a bar layout/input synchronization race.

More specifically:

When a StatusNotifierItem is removed, the System Tray model changes and causes the Tray's implicit width and the entire right-side bar layout to reflow. The visual scene graph reaches the new geometry, but click-target/input-region coordinate mapping may not be updated atomically with the layout change. This can leave interactive right-side modules with stale or displaced hit-testing geometry.

This is currently an evidence-based root-cause hypothesis, not a proven Quickshell C++ root cause.

Alternative Possible Causes

The investigation identified several technically plausible alternatives:

1. Quickshell layer-shell input-region update

PanelWindow may not update the underlying Wayland layer-shell input region at exactly the same time as QML content geometry changes.

This could produce:

visual geometry = new
input region = old
2. QML Repeater delegate lifecycle

Repeater delegates may be destroyed/recreated as the tray model changes before the entire parent layout has completed propagation.

3. Coordinate-space mismatch

A discrepancy could exist between:

bar surface coordinates
QML scene coordinates
module coordinates
click-target coordinates

during dynamic reflow.

4. Event-loop ordering

The following operations may occur across different event-loop/binding evaluation stages:

D-Bus signal
 → C++ model update
 → QML binding update
 → delegate destruction
 → implicit size calculation
 → Row re-layout
 → input geometry update

The exact ordering/timing has not been instrumented.

Confidence
MEDIUM-HIGH

Strong evidence:

Issue is reproducible.
Discord and Telegram both trigger it.
The common operation is StatusNotifierItem removal.
Tray model removal causes dynamic geometry changes.
The right-side bar depends on Tray width.
The visual layout reaches the correct final position.
Click behavior can nevertheless become offset.
Existing code uses dynamic QML model/delegate/layout chains and coordinate mapping.

Remaining uncertainty:

The exact event-loop/binding timing has not been instrumented.
The exact Quickshell layer-shell input-region behavior has not been instrumented.
We have not modified the code to add tracing because this investigation was intentionally read-only.

Therefore the precise low-level synchronization failure is not yet conclusively proven.

Relation to Existing Omarchy Issues

The behavior appears related to previously reported Omarchy issues involving top-bar click/input misalignment, including:

#10030 — Top-bar widgets intermittently stop responding to mouse clicks
#10725 — System Tray / Bar Click Areas Become Misaligned After Tray Model Changes
#10956 — Top Bar Click Areas Become Vertically Misaligned After Tray/Widget Changes
#11306 — Top Bar Click/Input Offset After Monitor Geometry Changes
#11693 — Intermittent click offset on right-side status bar modules

The current reproduction appears particularly relevant to the combination of:

System Tray model change
        +
right-side module reflow
        +
click/input coordinate mismatch

However, this report is not claiming that the existing issues have the exact same root cause. The purpose of this investigation is to provide a concrete reproduction and code-level hypothesis that may help correlate them.

Important: No Local Modification Was Made

The investigation was performed as a read-only forensic analysis.

No changes were made to:

Bar.qml
Tray.qml
WidgetButton.qml
Quickshell configuration
Omarchy configuration
Hyprland configuration
System Tray implementation
layer-shell configuration

No workaround was applied.

Suggested Diagnostic Direction

If maintainers want to investigate further, useful instrumentation would be around the exact transition:

StatusNotifierItemUnregistered
        ↓
SystemTray model removal
        ↓
Tray delegate destruction
        ↓
Tray implicitWidth change
        ↓
ModuleSlot geometry change
        ↓
ModuleList/right-side Row reflow
        ↓
click-target geometry update
        ↓
layer-shell input-region update

In particular, comparing these values immediately before and after a tray item is removed could help identify where the stale geometry originates:

Tray x/y/width/height
ModuleSlot x/y/width/height
right-side Row geometry
WidgetButton geometry
click-target geometry
mapToItem() results
PanelWindow input region
layer-shell surface geometry
Conclusion

The current evidence points to a generic System Tray removal → dynamic bar reflow → input/click geometry synchronization problem, rather than a Discord- or Telegram-specific issue.

The critical symptom is:

The rendered right-side modules move to the correct new positions, but their interactive click/input regions can become offset after a StatusNotifierItem is removed.

The strongest current hypothesis is that the dynamic System Tray model/layout propagation and the bar's click/input-region synchronization are not atomic.

Further instrumentation of the model → QML layout → click-target → layer-shell input-region pipeline would be needed to establish the exact low-level failure point.