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.
Emoji picker insert fails in Zen/Firefox: Shift+Insert pastes PRIMARY, not clipboard
Reported by sarniva · filed Sep 5, 2026Closed upstream on 2026-09-21 by bjarneo via an automated message, as a duplicate of #10192 (R-963). 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
What happened
Pressing SUPER+CTRL+E with Zen Browser focused opens the emoji picker fine, but selecting an emoji never inserts it into Zen. The same shortcut works in terminals, Chromium, and editors.
Steps to reproduce
- Focus Zen Browser (native Wayland, class
zen) with a text field focused (e.g. address bar). - Press SUPER+CTRL+E, pick any emoji.
- Nothing is pasted. The emoji is on the clipboard, so manual Ctrl+V works — only the automatic paste fails.
Root cause
omarchy-menu-emoji-insert copies the emoji to the Wayland CLIPBOARD and pastes with wtype Shift+Insert. Firefox-based browsers map Shift+Insert to the PRIMARY selection, not the clipboard, so the paste finds nothing. Verified with wl-paste vs wl-paste --primary.
Same likely applies to Firefox and LibreWolf (Omarchy tags all three firefox-based-browser).
Suggested fix
In omarchy-menu-emoji-insert: copy to both clipboard and primary (wl-copy --primary in addition), and send Ctrl+V (wtype -M ctrl v -m ctrl) when the focused window is Firefox-based, keeping Shift+Insert elsewhere. That is the workaround I run locally and it works in Zen plus all other apps.
System details
- Omarchy 4.0.2-1, Hyprland 0.56.2 (Wayland), Arch kernel 7.1.9-arch1-2
- Zen Browser native (
/opt/zen-browser-bin/zen-bin, xwayland: 0) - Full diagnostics in /tmp/omarchy-debug.log (
omarchy debug --no-sudo --print)
View raw text
## What happened Pressing SUPER+CTRL+E with Zen Browser focused opens the emoji picker fine, but selecting an emoji never inserts it into Zen. The same shortcut works in terminals, Chromium, and editors. ## Steps to reproduce 1. Focus Zen Browser (native Wayland, class `zen`) with a text field focused (e.g. address bar). 2. Press SUPER+CTRL+E, pick any emoji. 3. Nothing is pasted. The emoji is on the clipboard, so manual Ctrl+V works — only the automatic paste fails. ## Root cause `omarchy-menu-emoji-insert` copies the emoji to the Wayland CLIPBOARD and pastes with `wtype Shift+Insert`. Firefox-based browsers map Shift+Insert to the PRIMARY selection, not the clipboard, so the paste finds nothing. Verified with `wl-paste` vs `wl-paste --primary`. Same likely applies to Firefox and LibreWolf (Omarchy tags all three `firefox-based-browser`). ## Suggested fix In `omarchy-menu-emoji-insert`: copy to both clipboard and primary (`wl-copy --primary` in addition), and send Ctrl+V (`wtype -M ctrl v -m ctrl`) when the focused window is Firefox-based, keeping Shift+Insert elsewhere. That is the workaround I run locally and it works in Zen plus all other apps. ## System details - Omarchy 4.0.2-1, Hyprland 0.56.2 (Wayland), Arch kernel 7.1.9-arch1-2 - Zen Browser native (`/opt/zen-browser-bin/zen-bin`, xwayland: 0) - Full diagnostics in /tmp/omarchy-debug.log (`omarchy debug --no-sudo --print`)
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/6892· confirmed
- Fixed bypr/12377· confirmed
- Fixed bypr/8573· 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.
No decision has been recorded yet.