[GUI][rc12 candidate] Mobile sidebar cannot be reopened because its toggle is hidden

[YaoxiangLi]

Summary

At a 390 x 844 CSS-pixel viewport, the fp-tools sidebar is automatically translated completely off-screen, but the only stExpandSidebarButton that could reopen it has a 0 x 0 layout box because its ancestor stToolbar is hidden by fp-tools CSS. The main page looks clean, but users cannot navigate to any command.

This is separate from the closed desktop heading-overlap issue #41. Desktop sidebar spacing is correct in this candidate.

Tested candidate

• PR: Fix match-motifs logging and native desktop apps #49
• Candidate source commit: dfd283e9a1d64f5728b310af6e0b2c373337de5a
• Windows workflow run: 32452692335
• Artifact ID: 9436464405 (fp-tools-gui-windows-x64)
• Executable size: 359674812 bytes
• Executable SHA-256: c8cfbd635a2835980f69fa45ed8cb03787ffa2069706a174b91e811a742c389d
• UI version: 0.2.0rc12
• OS: Windows x64
• Browser: Chrome, normal zoom
• Failing viewport: 390 x 844 CSS px
• Control viewports: native 1440 x 960, maximized native window, and 1920 x 911 Chrome all render correctly

Reproduction

1. Start the PR Fix match-motifs logging and native desktop apps #49 frozen Windows executable's GUI server.
2. Open the local URL in Chrome.
3. Set the viewport to 390 x 844 (the same mobile width already used by scripts/audit_desktop_gui.py).
4. Reload the Home page.
5. Observe that the main content is responsive and the sidebar is off-screen.
6. Try to open the navigation sidebar.

There is no visible or clickable sidebar-open control, so atac-correct, call-footprints, match-motifs, diff-footprints, bulk-footprinting, and every other page are unreachable.

Measured DOM result

{
  "viewport": {"width": 390, "height": 844},
  "sidebar": {
    "left": -300,
    "right": 0,
    "width": 300,
    "height": 844,
    "transform": "matrix(1, 0, 0, 1, -300, 0)"
  },
  "expand_button": {
    "display": "flex",
    "visibility": "visible",
    "width": 0,
    "height": 0,
    "left": 0,
    "top": 0
  },
  "expand_button_ancestor_toolbar": {
    "data-testid": "stToolbar",
    "display": "none",
    "width": 0,
    "height": 0
  }
}

Playwright finds exactly one [data-testid="stExpandSidebarButton"], but clicking fails because there is no visible match. All sidebar navigation buttons remain positioned between approximately x = -275 and x = -26, entirely outside the viewport.

Likely cause

src/fp_tools/gui_app.py globally hides the complete Streamlit toolbar:

[data-testid="stToolbar"],
[data-testid="stDecoration"] {
    display: none !important;
}

In the bundled Streamlit version, stExpandSidebarButton is a descendant of stToolbar. At narrow widths Streamlit moves stSidebar left by its full 300 px width, so hiding that toolbar also removes the only recovery control.

The stylesheet also hides stSidebarCollapseButton, so there is no alternative app-provided sidebar toggle.

Expected

At supported narrow/mobile widths, users must have a visible, keyboard-focusable control that opens the sidebar, or an equivalent compact navigation surface. The sidebar itself should open above the main content and remain scrollable without text collisions.

Suggested fix

Preserve a visible sidebar-expand control at narrow widths while continuing to hide unrelated Streamlit toolbar actions. For example, avoid hiding the toolbar wholesale, or add a mobile rule that restores the expand-button container and button dimensions/position. Also provide a visible collapse control while the mobile sidebar is open.

Regression test

Extend scripts/audit_desktop_gui.py at its existing 390 x 844 viewport:

1. Assert the sidebar starts either visible or has a visible stExpandSidebarButton with nonzero dimensions.
2. Click the expand button.
3. Assert stSidebar.getBoundingClientRect().left >= 0.
4. Click a lower navigation item such as bulk-footprinting and assert its page heading appears.
5. Assert navigation labels do not overlap and the sidebar can scroll.
6. Close/reopen the sidebar and repeat after a page rerender.

The current 390 px audit checks page responsiveness but does not exercise navigation reachability.

Acceptance checklist

• A visible sidebar-open control exists at 390 x 844.
• The control is keyboard accessible and has an accessible name.
• Opening the sidebar makes all navigation rows reachable via scrolling.
• The sidebar can be closed again.
• Desktop 1280/1920 layouts and native window layouts remain unchanged.
• A frozen-Windows browser regression exercises the open, navigate, close flow.

[YaoxiangLi]

Fixed in merged PR #53 and verified in the frozen Windows and Apple Silicon GUI audits for v0.2.0rc13.