Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-4535GitHub issuePublicReceived

Bar hover feedback loop: tray and indicators oscillate when indicators are in the right section

Reported by fivves · filed Aug 6, 2026Closed upstream on 2026-08-10 by commit 567e24cd90eb (closed by dhh). GitHub close reason: completed.

Received and recorded verbatim. Nothing has been checked yet.

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

Bar hover feedback loop: tray and indicators oscillate when indicators are in the right sectionrevision 1 · captured 2026-10-04 11:56 UTC via poll

Description

Hovering the empty bar space immediately left of omarchy.tray causes the tray drawer and omarchy.indicators to rapidly expand and collapse in a self-sustaining feedback loop. The bar stutters at an intense rate until the cursor leaves the area. No crash, purely visual.

Reproducible with an otherwise stock config — the only requirement is moving omarchy.indicators into the right bar section via the built-in drag-and-drop settings UI.

Steps to reproduce

  1. Open the bar settings drag-and-drop UI and move omarchy.indicators into the right section (it ships in center by default).
  2. Park the cursor in the empty bar space immediately left of omarchy.tray (the leftmost widget of the right section).
  3. Observe: both widgets expand/collapse in rapid oscillation until the cursor moves away.

Expected behavior

Nothing. Hovering empty bar space should not expand widgets elsewhere on the bar.

Root cause

The inactive indicators reveal is coupled to a full-bar hover overlay, and that expansion shifts the tray under the cursor:

  1. Indicators.qml (~line 18): revealInactiveIndicators includes bar.centerSectionRevealHeld === true, so the hidden utility icons expand whenever the center section is hovered.
  2. Bar.qml: CenterModules { anchors.fill: parent } (~line 1036). The center section is a full-bar overlay, and its HoverHandler (~line 1234) fires for ANY empty bar space, setting centerSectionHovered → centerSectionRevealHeld (120ms debounce timer at ~line 554).
  3. The inactive indicator block is inserted to the LEFT of the active block inside the right section's right-anchored Row, so expanding the indicators grows the whole right section leftward — shoving omarchy.tray (leftmost) sideways.
  4. With the cursor parked just left of the tray:
  • empty space is hovered → indicators expand → section slides left → the tray's drawer/chevron edge slides under the cursor
  • the tray's HoverHandler fires (drawer starts its 600ms expansion) AND the cursor is now over a widget, so the center overlay un-hovers
  • 120ms later centerSectionRevealHeld drops → indicators collapse → section slides right → tray slides out from under the cursor
  • cursor is over empty space again → repeat forever

Bar widths have no Behavior, so section shifts are instant; only the tray's 600ms revealProgress animation runs, restarting every cycle — that's the visible stutter.

Why the default layout doesn't hit it

The shipped default config puts indicators in the center section and the tray in right, so indicator expansion never moves the tray. The loop only appears once both share a section edge, which the drag-and-drop UI explicitly supports.

Suggested fixes

  1. The center hover area shouldn't cover regions other sections can grow into — suppress centerSectionRevealHeld while a section resize is in flight, or narrow the center overlay's hover region so it doesn't abut expandable section edges.
  2. Reserve the inactive indicators' width up front (like the tray reserves drawerExtent for its drawer) so expansion never shifts the layout.
  3. Only reveal indicators on direct hover — loses the "peek by hovering the middle" feature.

Workaround

A custom module override of omarchy.indicators with the centerSectionRevealHeld term dropped from revealInactiveIndicators. Indicators still expand on direct hover; the loop is gone.

View raw text
## Description

Hovering the empty bar space immediately left of `omarchy.tray` causes the tray drawer and `omarchy.indicators` to rapidly expand and collapse in a self-sustaining feedback loop. The bar stutters at an intense rate until the cursor leaves the area. No crash, purely visual.

Reproducible with an otherwise stock config — the only requirement is moving `omarchy.indicators` into the right bar section via the built-in drag-and-drop settings UI.

## Steps to reproduce

1. Open the bar settings drag-and-drop UI and move `omarchy.indicators` into the right section (it ships in `center` by default).
2. Park the cursor in the empty bar space immediately left of `omarchy.tray` (the leftmost widget of the right section).
3. Observe: both widgets expand/collapse in rapid oscillation until the cursor moves away.

## Expected behavior

Nothing. Hovering empty bar space should not expand widgets elsewhere on the bar.

## Root cause

The inactive indicators reveal is coupled to a full-bar hover overlay, and that expansion shifts the tray under the cursor:

1. `Indicators.qml` (~line 18): `revealInactiveIndicators` includes `bar.centerSectionRevealHeld === true`, so the hidden utility icons expand whenever the center section is hovered.
2. `Bar.qml`: `CenterModules { anchors.fill: parent }` (~line 1036). The center section is a full-bar overlay, and its HoverHandler (~line 1234) fires for ANY empty bar space, setting `centerSectionHovered` → `centerSectionRevealHeld` (120ms debounce timer at ~line 554).
3. The inactive indicator block is inserted to the LEFT of the active block inside the right section's right-anchored Row, so expanding the indicators grows the whole right section leftward — shoving `omarchy.tray` (leftmost) sideways.
4. With the cursor parked just left of the tray:
   - empty space is hovered → indicators expand → section slides left → the tray's drawer/chevron edge slides under the cursor
   - the tray's HoverHandler fires (drawer starts its 600ms expansion) AND the cursor is now over a widget, so the center overlay un-hovers
   - 120ms later `centerSectionRevealHeld` drops → indicators collapse → section slides right → tray slides out from under the cursor
   - cursor is over empty space again → repeat forever

Bar widths have no `Behavior`, so section shifts are instant; only the tray's 600ms `revealProgress` animation runs, restarting every cycle — that's the visible stutter.

## Why the default layout doesn't hit it

The shipped default config puts indicators in the `center` section and the tray in `right`, so indicator expansion never moves the tray. The loop only appears once both share a section edge, which the drag-and-drop UI explicitly supports.

## Suggested fixes

1. The center hover area shouldn't cover regions other sections can grow into — suppress `centerSectionRevealHeld` while a section resize is in flight, or narrow the center overlay's hover region so it doesn't abut expandable section edges.
2. Reserve the inactive indicators' width up front (like the tray reserves `drawerExtent` for its drawer) so expansion never shifts the layout.
3. Only reveal indicators on direct hover — loses the "peek by hovering the middle" feature.

## Workaround

A custom module override of `omarchy.indicators` with the `centerSectionRevealHeld` term dropped from `revealInactiveIndicators`. Indicators still expand on direct hover; the loop is gone.

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.