sbox hidden ScreenPanel can steal mouse input from player controller

The root cause is MouseVisibility.Auto — when any panel in the tree has pointer-events set to anything other than none, s&box treats the cursor as "in UI mode" and stops locking mouse input to the game. A hidden panel (opacity 0, display none, or visibility hidden via C#) still participates in pointer event routing if its CSS pointer-events is not explicitly none.

The fix

CSS approach (preferred): Set pointer-events: none on the root panel of any overlay that is closed/hidden:

// MyOverlay.razor.scss
.my-overlay {
    pointer-events: none; // default — mouse passes through to game

    &.open {
        pointer-events: all; // only capture when actually open
    }
}

// MyOverlay.razor @code
protected override int BuildHash() => HashCode.Combine(_isOpen);

bool _isOpen;

void Open()
{
    _isOpen = true;
    SetClass("open", true);
    Mouse.Visibility = MouseVisibility.Visible;
}

void Close()
{
    _isOpen = false;
    SetClass("open", false);
    Mouse.Visibility = MouseVisibility.Hidden; // locks mouse back to game
}

Mouse.Visibility values:

• Hidden — mouse locked to game, Input.AnalogLook works, UI gets nothing
• Auto — mouse visible only when pointer-events: auto panels exist on screen ← this is the trap
• Visible — mouse always visible, UI mode

Key insight

MouseVisibility.Auto checks whether any panel in the entire UI tree has pointer events enabled — not just visible ones. A full-screen panel with pointer-events: all and display: none in C# (Enabled = false) still counts because the CSS pointer-events property is evaluated independently of visibility.

The diagnostic clue you mentioned — keyboard movement works but mouse look doesn't — confirms this exactly: PlayerController is alive and receiving Input.AnalogMove, but Input.AnalogLook is being consumed by the UI layer.

Correct pattern for in-game overlays

// In your ScreenPanel's root Razor component
// Always start with pointer-events: none in SCSS
// Toggle the "open" class to enable pointer events
// Explicitly set Mouse.Visibility on open/close — don't rely on Auto

Never use MouseVisibility.Auto for in-game overlays. Use Hidden when closed and Visible when open, toggled explicitly.

Fix pattern:

1. Keep menu screens and in-game overlays in separate input modes. Startup/customization menus can force Mouse.Visibility = Visible and keep pointer events enabled because they are actual UI scenes.

2. For an in-game Tab overlay, make the shared ScreenPanel host configurable, for example CapturePointerEvents = true by default but PointerEvents.None when the overlay is closed.

3. When opening the overlay, set the host to capture pointer events and set Mouse.Visibility = Visible.

4. When closing the overlay, set the host/root to PointerEvents.None and set Mouse.Visibility = Hidden so s&box locks mouse input back to gameplay.

5. Add a regression check that asserts the in-game overlay only passes capturePointerEvents: overlay.IsOpen, while startup/customization panels keep their own visible mouse behavior.

The key is that a hidden full-screen Panel with PointerEvents.All still counts as clickable UI for MouseVisibility.Auto. Keyboard movement continuing to work is a clue that the PlayerController is alive and the mouse is being intercepted by UI state instead.