Vertical tabs settings popup items (View as / Density) are unclickable

[leozeli]

Summary

When the vertical tabs settings popup is open, clicking any option — View as (Panes / Tabs), Density (Compact / Expanded), Pane title as, and other toggle items — has no visible effect. The popup opens correctly but its interactive items do not respond to clicks.

Steps to reproduce

1. Enable vertical tabs (Settings → Features → Vertical Tabs).
2. Click the settings (gear) button at the top of the vertical tabs panel.
3. The settings popup opens showing "View as", "Density", "Pane title as", etc.
4. Click any option — e.g. switch from "Panes" to "Tabs" under View as, or toggle Compact / Expanded under Density.

Expected: The selected option activates and the panel updates accordingly.
Actual: Nothing happens. Cursor shows a pointer on hover, but clicking produces no response.

Root cause

render_vertical_tabs_panel renders the settings popup a second time as a panel-level overlay, in addition to the workspace-level rendering (wrapped in Dismiss) that already exists in the workspace view render function.

Both render calls pass the same &VerticalTabsPanelState, so every Hoverable button in the popup shares the same MouseStateHandle instance. Hoverable records a pending click on LeftMouseDown via self.state().click_count = Some(n), then fires the handler on LeftMouseUp via click_count.take().

Because warpui's Stack uses EventDispatchMode::Broadcast by default, both overlay instances receive every mouse event. The dispatch order is:

1. Panel-level copy (dispatched first): receives LeftMouseUp, calls click_count.take() — consumes the value — then bails because is_mouse_over_element returns false (covered by the higher-z-index workspace overlay). No action dispatched.
2. Workspace-level copy (inside Dismiss): receives LeftMouseUp, calls click_count.take() — finds None because step 1 already consumed it — skips the handler. No action dispatched.

Result: clicks are silently dropped and the popup items appear completely unresponsive.

Fix

Remove the redundant panel-level popup render from render_vertical_tabs_panel. The workspace-level Dismiss rendering already handles positioning, click-outside-to-close, and z-ordering correctly.

Environment

• OS: Arch Linux, Hyprland 0.54.3 (Wayland)
• Branch: master (reproduced from initial public release commit)

[oz-for-oss]

@leozeli

Here's what I found while triaging this issue:

The reproduction is actionable. Code inspection supports that the same settings popup can be rendered twice while open, which plausibly explains why clicking its options appears to do nothing. No additional reporter information is needed right now.

Maintainer details

I concluded that vertical tabs view-options popup controls appear unclickable because the same settings popup is rendered twice with shared hover/click state..

Triage

This looks like an actionable vertical-tabs bug rather than a reporter configuration issue. The reported steps are specific, and code inspection supports the proposed failure mode.

Reproducibility

High. The issue provides a concrete feature-gated path (Vertical Tabs enabled, open the gear popup, click any popup option), and the current render path contains the duplicated popup/state-sharing pattern described in the report. I did not run a local GUI reproduction in this container.

Likely root cause

The reporter's root-cause hypothesis is supported by the current code:

• app/src/workspace/view/vertical_tabs.rs:1453 renders render_settings_popup(state, app) as an overlay inside render_vertical_tabs_panel when state.show_settings_popup is true.
• app/src/workspace/view.rs:22019 separately renders render_settings_popup(&self.vertical_tabs_panel, app) as a workspace-level overlay wrapped in Dismiss for the same state.
• app/src/workspace/view/vertical_tabs.rs:4315 builds popup controls from MouseStateHandles stored on VerticalTabsPanelState, so the duplicated popup instances share click state.
• crates/warpui_core/src/elements/hoverable.rs:628 stores click_count on mouse down and crates/warpui_core/src/elements/hoverable.rs:647 consumes it on mouse up before rejecting covered/outside elements.
• crates/warpui_core/src/elements/stack/mod.rs:104 uses broadcast dispatch in non-debug builds, which makes duplicate overlay event delivery plausible.

The narrow fix suggested by the report—removing the redundant panel-level popup render and relying on the workspace-level Dismiss overlay—matches the code shape.

Duplicate check

No duplicate was flagged from the supplied recent/open issue list. #9505 is adjacent because it involves vertical-tabs UI blocking clicks on Linux/Wayland, but the reported failing surface and reproduction path differ, and there were not two strong duplicate candidates.

Suggested owners

• @zachbai for the vertical-tabs implementation per .github/STAKEHOLDERS.
• @vorporeal if maintainers want a UI-framework-level review of the shared Hoverable state / Stack dispatch interaction.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz