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.
Bluetooth widget device list reshuffles under pointer during discovery, causing misclicks
Reported by daffelito · filed Aug 31, 2026 · open at source
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?
- AreaOutside the audited area· Decided by agents · verified
- 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?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
What happened
The Bluetooth bar widget's device list ("Available"/discovered section) reorders itself while Bluetooth discovery is scanning. Model.js sorts the discovered-devices section alphabetically by label on every scan report, and the ListView model (root.scrollRows) is fully rebuilt each time. When a new device is discovered mid-scan, it can sort into the list above an existing row, which shifts every row below it down — including the one currently under the pointer. In practice this means: hover a device near the bottom of the list to click Connect/Forget, a new device appears from the scan, the list reflows, and the click lands on the wrong row (or misses entirely).
Expected
The row under the pointer should stay in place while the pointer is over the list, even as discovery keeps finding new devices. New arrivals should not visually displace rows the user is currently interacting with.
Steps to reproduce
- Open the Bluetooth bar widget in an area with several nearby discoverable devices (busy Bluetooth environment reproduces it fastest).
- Let discovery scan run so the "Available" section has multiple rows.
- Move the pointer toward a device near the bottom of the list, intending to click it.
- While hovering, wait for a new device to appear in the scan (or for an existing one's properties to update, which also triggers the resort).
- Observe the list reflow/reorder under the pointer before the click registers.
Where I looked
/usr/share/omarchy/shell/plugins/panels/bluetooth/Model.js, sortedByLabel() / deviceLists() — resorts discovered on every call./usr/share/omarchy/shell/plugins/panels/bluetooth/Panel.qml — scrollRows rebuilds from deviceGroups on every change; the backing ListView's model binds directly to it, so the view has no protection against mid-interaction reflows.
Workaround
Locally cloned the plugin (omarchy plugin clone omarchy.bluetooth) and froze the ListView's model snapshot while the pointer hovers it (via HoverHandler), only resyncing to the live scrollRows on hover-exit. Happy to open a PR with this approach against the upstream plugin if useful, adapted to whatever list-stability convention the maintainers prefer.
System
- Omarchy version: 4.0.1-1
- Hyprland: 0.56.2
View raw text
## What happened
The Bluetooth bar widget's device list ("Available"/discovered section) reorders itself while Bluetooth discovery is scanning. `Model.js` sorts the discovered-devices section alphabetically by label on every scan report, and the `ListView` model (`root.scrollRows`) is fully rebuilt each time. When a new device is discovered mid-scan, it can sort into the list above an existing row, which shifts every row below it down — including the one currently under the pointer. In practice this means: hover a device near the bottom of the list to click Connect/Forget, a new device appears from the scan, the list reflows, and the click lands on the wrong row (or misses entirely).
## Expected
The row under the pointer should stay in place while the pointer is over the list, even as discovery keeps finding new devices. New arrivals should not visually displace rows the user is currently interacting with.
## Steps to reproduce
1. Open the Bluetooth bar widget in an area with several nearby discoverable devices (busy Bluetooth environment reproduces it fastest).
2. Let discovery scan run so the "Available" section has multiple rows.
3. Move the pointer toward a device near the bottom of the list, intending to click it.
4. While hovering, wait for a new device to appear in the scan (or for an existing one's properties to update, which also triggers the resort).
5. Observe the list reflow/reorder under the pointer before the click registers.
## Where I looked
`/usr/share/omarchy/shell/plugins/panels/bluetooth/Model.js`, `sortedByLabel()` / `deviceLists()` — resorts `discovered` on every call.
`/usr/share/omarchy/shell/plugins/panels/bluetooth/Panel.qml` — `scrollRows` rebuilds from `deviceGroups` on every change; the backing `ListView`'s `model` binds directly to it, so the view has no protection against mid-interaction reflows.
## Workaround
Locally cloned the plugin (`omarchy plugin clone omarchy.bluetooth`) and froze the `ListView`'s model snapshot while the pointer hovers it (via `HoverHandler`), only resyncing to the live `scrollRows` on hover-exit. Happy to open a PR with this approach against the upstream plugin if useful, adapted to whatever list-stability convention the maintainers prefer.
## System
- Omarchy version: 4.0.1-1
- Hyprland: 0.56.2
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
- Fixed bypr/9400· confirmed
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.
- Out of scopeDecided by agents · verified · 2026-10-09 10:14 UTC