Skip to content

Can't scroll new Plugins window #818

New issue
New issue
Closed
Closed
Can't scroll new Plugins window#818
Labels
factoryBuild this with the software factoryfactory:needs-humanThe factory needs a human decision on the PR

Description

@AnInfiniteNumberofMonkeys
AnInfiniteNumberofMonkeys
opened on Sep 14, 2026

I see that v.1.1.8 uses a new design for the Plugins window. IMO it's a huge step backwards—really inefficient vs. a table view. Is there any way to revert to the old design (or do I need to return to the native WP version)?

Environment 
Plugin version:    1.1.8
WordPress version: unknown
User agent:        Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/152.0.0.0 Safari/537.36
Viewport:          2369x1393
Platform:          MacIntel
Current URL:       https://oceansev.com/wp-admin/admin.php?page=openstation

Activity

  1. AnInfiniteNumberofMonkeys commented on Sep 15, 2026

    @AnInfiniteNumberofMonkeys
    AnInfiniteNumberofMonkeys
    on Sep 15, 2026
    Author

    Thank you for providing the option to restore a table view of the Plugins window in v.1.1.9. It's still far inferior to the original native Plugins window, which was brilliant. Also, I still can't scroll the table unless I switch to the native WP version.

  2. epeicher
    added
    factoryBuild this with the software factory
    on Oct 26, 2026

  3. epeicher commented on Oct 26, 2026

    @epeicher
    epeicher
    on Oct 26, 2026
    Collaborator

    Factory intake: ACCEPT (risk low, surfaces: ui)

    Scope

    Make the Installed tab of the Plugins window scroll, in both the Cards and the Table view, when the plugin list is taller than the window.

    • Reproduce first, on the job's wp-env site in Chrome: enough installed plugins to overflow the window (40 or more), the window at its default size and maximized, in Cards and in Table view. Confirm whether the list is clipped with no scrollbar, or shows a scrollbar the wheel and trackpad do not move. Do not change CSS until the failure is on screen.
    • Fix it inside the Plugins app's own styles: apps/plugins/plugins.css (the frame: .desktop-mode-plugins, .os-plugins__panel, .os-plugins__installed), apps/plugins/parts/library.styles.ts (.os-plugins__workspace, .os-plugins__library, .os-plugins__library-scroll and its [data-view="table"] variant) and apps/plugins/parts/installed-table.styles.ts (the .scroll { block-size: 100% } rule adopted into <os-table>'s shadow root). The height chain runs .os-window__body (window-chrome.css) → .os-app and .os-app-list__panel (app-runtime.css) → the Plugins frame; the shared shell and runtime CSS stay as they are unless the reproduction proves the break is there, in which case stop and say so in the PR rather than patching shell code for one app.
    • The scroll container stays .os-plugins__library-scroll in Cards view and <os-table>'s own .scroll in Table view, so the library header, the collection buttons and the selection tray keep their place and only the list moves. Keyboard scrolling (focus inside the list, arrow keys and Page Down) must work as well as the wheel.
    • Check the Browse and the OpenStation plugins tabs (.os-plugins__gallery, overflow-y: auto) scroll too while you are there; they share the frame.
    • No new test unless the cause turns out to be structural (a missing wrapper, a lost class) that jsdom can see; scroll geometry is not testable there. Build with npm run build:apps, run lint, typecheck and test:js.

    Left out: restoring the pre-1.1.8 design of the Plugins window. The Table view added in 1.1.9 is the answer to that request, and a further "classic" look would be a design decision for a separate issue. The native plugins.php screen remains available by turning the Plugins window opt-in off.

    Why

    This is a bug in one app's layout, nothing else: no public API, no stored data, no permission decision, so the risk is low and the only surface is what the user sees. The CSS chain from .os-window__body through .os-app-list__panel, .os-plugins__installed, .os-plugins__workspace, .os-plugins__library and .os-plugins__library-scroll (overflow: auto, flex: 1, min-block-size: 0) reads correctly on paper, and the only document-level wheel listener (src/mode/zoom-guard.ts) cancels ctrl+wheel alone, so the break is not visible from reading and the builder has to see it on a real site with an overflowing list before changing anything. The report covers both views (Cards in 1.1.8, Table in 1.1.9), which points at the shared frame above the two views rather than at either one. The original request to revert the redesign is left out because it is a product decision, not a fix, and 1.1.9's Table view already answered it.

  4. epeicher commented on Oct 26, 2026

    @epeicher
    epeicher
    on Oct 26, 2026
    Collaborator

    Factory: needs a human

    Why

    The builder is blocked:

    Could not reproduce the failure. Setup: job site on :8910 (built from the branch, which equals trunk 37fb2e5), 48 plugins (45 scaffolded fixtures, about 23 active), desktop_mode_mode=1 and nativePluginsEnabled=true for admin, Chrome via agent-browser, viewport 2369x1393 (the reporter's size). The Plugins window was opened with wp.os.openWindow('desktop-mode-plugins'). Wheel input was sent as real CDP Input.dispatchMouseEvent mouseWheel events at coordinates inside the list (agent-browser's own mouse wheel always fires at 0,0, so it can't be used for this).

    Measurements (clientHeight / scrollHeight, scrollTop after a wheel of 300-400px):

    Size View Scroller client / scroll height scrollTop after wheel
    default (1180x480) Cards .os-plugins__library-scroll 172 / 4201 400
    maximized Cards .os-plugins__library-scroll 1001 / 2061 300
    maximized Table table shadow .scroll 983 / 3690 300 (library-scroll stays 0)
    default Table table shadow .scroll 154 / 3690 300, then 600
    • Ends of the lists: Table, last row bottom 474.4 against .scroll bottom 475. Cards, last card bottom 463.4 against .os-plugins__library-scroll bottom 491. Both fully reachable.
    • Keyboard: Page Down with focus in the table scrolled .scroll from 0 to 134; in Cards it scrolled .os-plugins__library-scroll (stayed at the end, 4029, so that one is weak evidence).
    • Galleries: "Add Plugin" gallery 339 / 701, wheel took it to 362 (max). "OpenStation plugins" gallery 333 / 473, wheel took it to 140.
    • Height chain at default size, Cards (first element whose height is bounded by the window): .os-plugins__library-scroll 172, .os-plugins__library 396, workspace 396, installed 396, tabpanel 396, .os-app-list 438, .os-app 438, .os-window__body 438, window 478. Every level is bounded; none has clientHeight equal to its content height.
    • Window clientHeight only: no sign of an unbounded element anywhere in steps 3 to 9 of the spec's chain.

    Not checked: the selection tray with 2+ selected (criterion 9), since there was nothing to fix. Chrome 152 on macOS was not available; the browser here is whatever agent-browser ships.

    Options:

    1. Ask the reporter for specifics (browser and OS, trackpad vs mouse, whether a scrollbar shows, window and zoom state, whether Add Plugin also fails) or a screen recording, then re-run the job.
    2. Close the issue as not reproducible on trunk. The reporter may be on 1.1.8/1.1.9, so confirming they are on current trunk first is worthwhile.
    3. If a human can reproduce on their machine, give the builder the failing element's measurements and the job restarts from requirement 1.
  5. epeicher
    added
    factory:needs-humanThe factory needs a human decision on the PR
    on Oct 26, 2026

  6. epeicher commented on Oct 27, 2026

    @epeicher
    epeicher
    on Oct 27, 2026
    Collaborator

    Thanks for the report, and sorry for the trouble. We tried to reproduce the scrolling problem on the current release (1.1.17) and couldn't: with 48 plugins installed, the Installed list scrolls in both Cards and Table view, at the default window size and maximized, in Chrome on macOS at a 2369px-wide viewport.

    A couple of things would help us track it down:

    1. Does it still happen after updating to 1.1.17?
    2. Are you scrolling with a trackpad or a mouse wheel, and where is the pointer when you scroll? In the new window only the plugin list scrolls; the header with the counters and the search bar stays fixed, so scrolling over the header does nothing.
    3. Do you see a scrollbar on the right edge of the list?
    4. Does the Add Plugin tab scroll for you?
    5. Is your browser zoom at 100%?

    A short screen recording would be ideal if you can make one.

  7. AnInfiniteNumberofMonkeys commented on Oct 27, 2026

    @AnInfiniteNumberofMonkeys
    AnInfiniteNumberofMonkeys
    on Oct 27, 2026
    Author
    1. It no longer happens with v.1.1.17.
    2. Scrolling with mouse wheel, when the cursor was over the table contents (not the fixed header).
    3. No
    4. Can't remember.
    5. Yes.

  8. epeicher commented on Oct 27, 2026

    @epeicher
    epeicher
    on Oct 27, 2026
    Collaborator

    Thanks @AnInfiniteNumberofMonkeys for your prompt reply! If that doesn't happen anymore, I will close this issue.

  9. epeicher
    closed this as completedon Oct 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    factoryBuild this with the software factoryfactory:needs-humanThe factory needs a human decision on the PR

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions