Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Top Bar Click Areas Become Vertically Misaligned After Tray/Widget Changes
Reported by Rambo176 · filed Sep 9, 2026Closed upstream on 2026-09-20 by bjarneo via an automated message, as a duplicate of #10030 (R-1008). GitHub close reason: completed.
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- Not yet mapped to any requirement or component.
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
System details
Ryzen 5600x with 3060 12gb varient and 32 gb of ram
What's wrong?
Description
I'm still experiencing the top-bar click-area misalignment issue described in my previous report. Unfortunately, the issue has not been resolved yet.
The affected widgets remain visually in their correct positions, but their mouse hover/click areas become vertically offset. When the glitch occurs, I have to move the cursor almost to the absolute top edge of the screen to hover over or click the affected widgets.
This is quite difficult to use and becomes very irritating during normal daily use.
Affected widgets
The issue consistently affects a group of widgets on the right side of the bar:
- Dropbox
- Tailscale
- Agents
- Speaker / Audio
- System Tray
Meanwhile, other widgets such as:
- Network / Ethernet
- Monitor / Display
continue to respond normally at their visible positions.
System Tray behavior
The System Tray seems to be closely related to the issue.
For example:
- Telegram/Discord tray icons can also have their hover/click areas shifted.
- Right-clicking a tray icon can sometimes immediately restore the correct click areas.
- Opening a tray context menu can also make the bar responsive again.
- Quitting a tray application can cause the problem to return after a short delay.
- Sometimes a tray context menu appears as a blank/empty popup while the popup frame itself is visible.
The bar itself does not visually move when this happens.
Important observation
During the glitch, the widgets still report their expected geometry.
The bar remains:
1920x26- positioned at
x=0, y=0
and the affected widgets also report y=0 and the expected height.
So this does not appear to be a simple visual positioning problem. The visual QML geometry looks correct while the actual pointer hit/click area is vertically displaced.
Reproduction
The issue appears to be related to dynamic changes in the System Tray / bar widget layout.
It can occur after tray applications are started, stopped, or their tray items change.
Restarting the Omarchy shell fixes the issue temporarily, and changing the bar position can also restore correct interaction, but the problem can return later.
Interestingly, interacting with a tray popup (especially right-clicking a tray icon) can also temporarily restore the correct hit areas without restarting the shell.
Environment
- Omarchy: 4.0.3-1
- Hyprland: 0.56.2
- Quickshell: [please fill if needed]
- Display: HDMI-A-2
- Resolution: 1920x1080
- Scale: 1
- Refresh rate: 144Hz
- GPU: NVIDIA RTX 3060 LHR
- NVIDIA driver: 610.57.04
What I have already checked
I have investigated this extensively and ruled out several possibilities:
- The bar layer remains at the correct
0 0 1920 26geometry. - The affected widgets report correct visible geometry.
- There is only one BarPanel.
- The right-side widgets are siblings in the same Row.
- The normal module click-target path is being used.
- No fullscreen notification/overlay was found covering the bar.
- The issue is not limited to a single widget.
- Restarting the shell temporarily fixes the problem.
- Changing the bar position can also temporarily fix it.
There was also a previous Quickshell crash involving QQuickRepeater / libQt6QmlModels during dynamic model changes, which may or may not be related.
Request
Could someone please investigate this further and fix it?
This issue is quite disruptive because the bar looks completely normal, but the actual clickable areas are in the wrong location. It makes frequently used controls such as Audio, System Tray, Dropbox and Tailscale frustrating to use.
I really appreciate the work that goes into Omarchy, and I understand that this may be related to Quickshell/Qt or the interaction between the tray model, layout, and the bar's input region.
However, since the issue is still reproducible in 4.0.3, I would really appreciate it if this could be investigated and fixed as soon as reasonably possible.
I'm happy to provide additional logs, diagnostics, or reproduction steps if they would help.
View raw text
### System details Ryzen 5600x with 3060 12gb varient and 32 gb of ram ### What's wrong? ## Description I'm still experiencing the top-bar click-area misalignment issue described in my previous report. Unfortunately, the issue has not been resolved yet. The affected widgets remain visually in their correct positions, but their mouse hover/click areas become vertically offset. When the glitch occurs, I have to move the cursor almost to the absolute top edge of the screen to hover over or click the affected widgets. This is quite difficult to use and becomes very irritating during normal daily use. ### Affected widgets The issue consistently affects a group of widgets on the right side of the bar: - Dropbox - Tailscale - Agents - Speaker / Audio - System Tray Meanwhile, other widgets such as: - Network / Ethernet - Monitor / Display continue to respond normally at their visible positions. ### System Tray behavior The System Tray seems to be closely related to the issue. For example: - Telegram/Discord tray icons can also have their hover/click areas shifted. - Right-clicking a tray icon can sometimes immediately restore the correct click areas. - Opening a tray context menu can also make the bar responsive again. - Quitting a tray application can cause the problem to return after a short delay. - Sometimes a tray context menu appears as a blank/empty popup while the popup frame itself is visible. The bar itself does not visually move when this happens. ### Important observation During the glitch, the widgets still report their expected geometry. The bar remains: - `1920x26` - positioned at `x=0, y=0` and the affected widgets also report `y=0` and the expected height. So this does not appear to be a simple visual positioning problem. The visual QML geometry looks correct while the actual pointer hit/click area is vertically displaced. ### Reproduction The issue appears to be related to dynamic changes in the System Tray / bar widget layout. It can occur after tray applications are started, stopped, or their tray items change. Restarting the Omarchy shell fixes the issue temporarily, and changing the bar position can also restore correct interaction, but the problem can return later. Interestingly, interacting with a tray popup (especially right-clicking a tray icon) can also temporarily restore the correct hit areas without restarting the shell. ### Environment - Omarchy: 4.0.3-1 - Hyprland: 0.56.2 - Quickshell: [please fill if needed] - Display: HDMI-A-2 - Resolution: 1920x1080 - Scale: 1 - Refresh rate: 144Hz - GPU: NVIDIA RTX 3060 LHR - NVIDIA driver: 610.57.04 ### What I have already checked I have investigated this extensively and ruled out several possibilities: - The bar layer remains at the correct `0 0 1920 26` geometry. - The affected widgets report correct visible geometry. - There is only one BarPanel. - The right-side widgets are siblings in the same Row. - The normal module click-target path is being used. - No fullscreen notification/overlay was found covering the bar. - The issue is not limited to a single widget. - Restarting the shell temporarily fixes the problem. - Changing the bar position can also temporarily fix it. There was also a previous Quickshell crash involving `QQuickRepeater` / `libQt6QmlModels` during dynamic model changes, which may or may not be related. ## Request Could someone please investigate this further and fix it? This issue is quite disruptive because the bar looks completely normal, but the actual clickable areas are in the wrong location. It makes frequently used controls such as Audio, System Tray, Dropbox and Tailscale frustrating to use. I really appreciate the work that goes into Omarchy, and I understand that this may be related to Quickshell/Qt or the interaction between the tray model, layout, and the bar's input region. However, since the issue is still reproducible in 4.0.3, I would really appreciate it if this could be investigated and fixed as soon as reasonably possible. I'm happy to provide additional logs, diagnostics, or reproduction steps if they would help.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
No decision has been recorded yet.