Cap content-area height on every page, fix scroll bugs, sidebar accordion

- Apply the taskbar's max-height/overflow-y:auto treatment to
  #wpbody-content unconditionally, so tall native/Aurora pages (Add
  Plugins, Add User, Profile, Fonts, file editors, Settings, Activity Log,
  Database Explorer, Comments) scroll internally within their frame
  instead of growing past the viewport and scrolling the whole document.
- Fix a Chrome scroll-anchoring bug this surfaced on Add Plugins (page
  loaded scrolled ~1700px into content instead of at the top) via
  overflow-anchor: none.
- Fix a phantom document-level scrollbar with dead space below the frame
  by locking html/body's own overflow, since the sidebar/toolbar are fixed
  and content is only ever meant to scroll internally.
- Make the sidebar's native-menu sections a single-open accordion:
  expanding one now collapses whichever else was open.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

PROJECT_STATUS.md

@@ -1,6 +1,6 @@
 # Aurora Admin v2 — Project Status
 
-_Last updated: 2026-07-03 (late session — Site Editor support, permissions bug fix, Comments sub-app, taskbar rewrite)_
+_Last updated: 2026-07-03 (latest session — universal content-area scroll cap, sidebar accordion, scroll-anchoring fix)_
 
 ## What this project is
 
@@ -113,6 +113,17 @@ get back up to speed instead of relying on prior chat history.
     over the page gradient. `--aurora-sidebar-gap` is a shared CSS var
     (`shell-frame.css`) that the toolbar's `left` offset and `#wpcontent`'s
     `margin-left` both add too, so nothing overlaps when the gap changes.
+  - **Native-menu accordion**: only one WP-native-menu section's submenu is
+    open at a time (`Sidebar.vue`'s `openId` ref) — expanding one collapses
+    whichever else was open, instead of the list growing indefinitely as
+    more sections get expanded. Was previously a `Set` of independently
+    toggleable ids (each section remembered its own open/closed state);
+    replaced with a single id so opening any section closes the rest.
+    Starts on whichever section matches the current page (each nav is a
+    full page load in this multi-page admin, so this is computed once at
+    mount, not reactively). The separate "Aurora" branded nav section below
+    it keeps its own independent expand/collapse state
+    (`localStorage['aurora-nav-expanded']`) — not part of this accordion.
 
 ## Theme system (rewrite — supersedes the old dark_mode 3-state model)
 
@@ -362,6 +373,41 @@ page navigation via a taskbar.
   calc(100vh - toolbar-h - 40px)`, and per spec `min-height` always wins over
   a smaller `max-height`; fixed by adding `min-height: 0` to the
   taskbar-specific override.
+- **Universal content-area height cap** (this session): the taskbar-only
+  `max-height`/`overflow-y: auto` treatment above is now applied to
+  `#wpbody-content` unconditionally (not just when `html.aurora-has-taskbar`
+  is set), capped to `calc(100vh - toolbar-h - 40px)`. Several native and
+  Aurora pages with a lot of content (Add Plugins, Add User, Profile,
+  Appearance > Fonts, the file editors, every Settings page, Activity Log,
+  Database Explorer, Comments) used to grow taller than the viewport and
+  force the *whole document* to scroll — janky since the sidebar/toolbar
+  are fixed, so scrolling just moved the content away from them with a lot
+  of dead space. Now the content card's own box is capped and scrolls
+  internally, same as the toolbar/taskbar reservations already did.
+  - **Scroll-anchoring bug this surfaced**: making `#wpbody-content` a real
+    scroll container exposed a second, unrelated bug on Add Plugins — its
+    plugin-card grid renders via JS well after first paint, inserting a lot
+    of content *above* whatever was already visible in the now-scrollable
+    box. Chrome's scroll anchoring "corrects" for that by silently jumping
+    `scrollTop` down to compensate, so the page loaded already scrolled
+    ~1700px into the content instead of at the top. Fixed with
+    `overflow-anchor: none` on `#wpbody-content` (and the taskbar/dashboard-
+    frame variant) — the standard fix for this class of bug, opting the
+    container out of anchoring entirely.
+  - **Phantom document-level scrollbar**: independently, Add Plugins also
+    left the outer `<html>`/`<body>` scrollable with ~1200px of empty dead
+    space below the frame, even though every element inside `#wpbody-content`
+    measured as properly capped to the viewport — narrowed down to some
+    interaction between the plugin grid's async rendering and the browser's
+    own scrollable-overflow bookkeeping (root cause not fully pinned down;
+    forcibly shrinking or hiding `#wpbody-content` reduced but didn't
+    eliminate it, and no single oversized/mispositioned descendant could be
+    found). Since the intended design already has the sidebar/toolbar fixed
+    and every page's real content scrolling *internally* within its own
+    frame, the document itself was never supposed to scroll at all — fixed
+    directly by adding `overflow: hidden` to `html.aurora-ready`/`body`,
+    which removes the dead scroll space outright regardless of what was
+    causing it.
 - **Block editor / Site Editor framing**: neither editor renders inside
   `#wpcontent`'s normal box model — each has its own fixed, full-viewport
   root (`.interface-interface-skeleton` itself on `post.php`/`post-new.php`;
@@ -475,10 +521,10 @@ page navigation via a taskbar.
 
 ## Current state
 
-No task in progress. Earlier this session rebuilt the entire theming system
+No task in progress. An earlier session rebuilt the entire theming system
 (fixed color presets, gradient backgrounds, "independently-painted gradient"
 seam bugs) and added the macOS-style window chrome + taskbar feature
-end-to-end (pushed as commits `4a547d2`/`b0b0a99`). Later the same session:
+end-to-end (pushed as commits `4a547d2`/`b0b0a99`). Later that same session:
 root-caused and fixed the Menu Creator/Activity Log/Role Editor "Sorry, you
 are not allowed to access this page" bug (was `remove_submenu_page()`
 corrupting WP's own capability lookup); added a 6th sub-app, Comments; fixed
@@ -487,8 +533,18 @@ taskbar from a single sessionStorage slot to a list supporting multiple
 minimized windows; and extended the window-chrome/taskbar framing to the
 Site Editor (`site-editor.php`), including tracking down a CSS
 over-constraint bug (`top`+`height`+`bottom` all set on a fixed-position box
-silently ignoring `bottom`) that was making its frame run past the viewport.
-All of it was live-verified in Chrome against the LocalWP site. This batch
-of changes was uncommitted at the point this doc was last updated — commit
-and push it as one of the next steps if not already done by the time this is
-read.
+silently ignoring `bottom`) that was making its frame run past the viewport
+(pushed as commit `8153d43`).
+
+This session: capped every native/Aurora page's content area to the
+viewport with internal scrolling instead of letting tall pages grow past it
+and scroll the whole document (see "Universal content-area height cap"
+above), which surfaced and fixed two more bugs along the way — a Chrome
+scroll-anchoring jump on Add Plugins, and a phantom document-level
+scrollbar with a large empty gap below the frame. Also made the sidebar's
+native-menu sections a single-open accordion instead of letting multiple
+stay expanded at once. All of it was live-verified in Chrome against the
+LocalWP site (build hot-patched into
+`/Users/kris/Local Sites/aurora/.../aurora-admin/app/dist` for iteration —
+the repo's source files are the actual edits; that copy is just the
+compiled build artifact, not a separate edit surface).

app/src/shell/components/Sidebar.vue

@@ -63,21 +63,16 @@ const isSectionActive = (item) => {
   return (item.submenu || []).some((sub) => normalize(sub.url) === current.value);
 };
 
-// Which sections are manually expanded. Active section starts expanded.
-const expanded = ref(new Set());
+// Accordion: only one section's submenu open at a time, so expanding one
+// closes the rest instead of the list growing indefinitely. Starts on
+// whichever section is active (each nav is a full page load in this
+// multi-page admin, so there's no need to react to URL changes afterward).
+const openId = ref(props.menu.find((item) => isSectionActive(item))?.id ?? null);
 
-const isExpanded = (item) => {
-  return expanded.value.has(item.id) || isSectionActive(item);
-};
+const isExpanded = (item) => openId.value === item.id;
 
 const toggle = (item) => {
-  const next = new Set(expanded.value);
-  if (next.has(item.id)) {
-    next.delete(item.id);
-  } else {
-    next.add(item.id);
-  }
-  expanded.value = next;
+  openId.value = openId.value === item.id ? null : item.id;
 };
 
 // Aurora's own branded nav section (Settings, Menu Creator, Admin Notices,

app/src/shell/shell-frame.css

@@ -103,6 +103,18 @@ html.aurora-ready body {
      background instead of a seam between "sidebar" and "page". */
   background-attachment: fixed;
   font-family: var(--aurora-font-family);
+  /* The sidebar/toolbar are position:fixed and every page's real content
+     now scrolls internally within its own frame (#wpbody-content or
+     .aurora-dashboard-frame, both capped to the viewport with their own
+     overflow-y: auto below) — so the document itself is never meant to
+     scroll. Some native pages (Add Plugins' plugin-card grid is the one
+     that surfaced this) leave a huge dead scrollable area at the document
+     level — a WP/browser quirk around lazily-rendered content reserving
+     scroll space against the page rather than the inner container — which
+     showed up as being able to scroll the whole window down to a big
+     empty gap below the frame. Locking the document's own scroll removes
+     that dead space outright, regardless of what's causing it. */
+  overflow: hidden;
 }
 
 /* !important here defeats WordPress's own responsive #wpcontent margin
@@ -196,6 +208,24 @@ html.aurora-ready #wpbody-content {
   margin: 16px var(--aurora-gutter-r) 24px 24px;
   padding: 32px;
   min-height: calc(100vh - var(--aurora-toolbar-h) - 40px);
+  /* Cap the card's own height to whatever's left below the toolbar and let
+     *it* scroll internally, instead of growing to fit tall native pages
+     (Comments, Plugins, Add User, Settings, Activity Log, Database
+     Explorer, ...) and forcing the whole document to scroll — the sidebar/
+     toolbar are fixed, so a tall #wpbody-content just meant a lot of empty
+     scroll distance below the fold with nothing visibly moving except the
+     content. Same fix as the taskbar-present case below, just unconditional. */
+  max-height: calc(100vh - var(--aurora-toolbar-h) - 40px);
+  overflow-y: auto;
+  /* Chrome's scroll anchoring tries to keep whatever's in view visually
+     stable when content shifts above it. Several native pages (Add Plugins'
+     plugin-card grid, most visibly) render their real content via JS well
+     after the initial paint, inserting it above stuff that was already
+     visible in this now-scrollable box — anchoring then "corrects" by
+     jumping scrollTop down to compensate, landing the page scrolled to
+     the middle/bottom on load instead of the top. Opting this container
+     out of anchoring is the standard fix for that class of bug. */
+  overflow-anchor: none;
   box-sizing: border-box;
   /* WP core sets #wpbody-content { float: left; width: 100% }, which (with
      box-sizing left alone) ignores the margin above and overflows past the
@@ -250,6 +280,7 @@ html.aurora-has-taskbar .aurora-dashboard-frame {
       var(--aurora-sidebar-gap) * 2
   );
   overflow-y: auto;
+  overflow-anchor: none;
 }
 
 /* The block editor's skeleton is already positioned with fixed insets