FE-1723: Cap the size of Petrinaut's Open submenu and elide long net titles

[claude]

Requested by Ciaran Morinan · Slack thread

🌟 What is the purpose of this PR?

Before: the hamburger menu's Open submenu has one entry per saved net and sizes itself to its longest entry, so one net titled with a full sentence stretched it across the viewport — and the title wrapped over several lines instead of ending in an ellipsis.

After: that submenu is at most min(600px, 70vw) wide and min(800px, 80vh) tall, it scrolls when there are more nets than fit, and a title too long for the row ends in an ellipsis with its relative timestamp still visible.

🔗 Related links

• FE-1723: Cap the size of Petrinaut's Open submenu and elide long net titles (internal)

🚫 Blocked by

• Nothing

🔍 What does this change?

SelectableList items that carry subItems accept a new optional menuClassName, applied to that item's submenu content alongside the list's own class; Petrinaut passes one on the Open item carrying the two caps and white-space: nowrap. Nothing else changes appearance, since no shared style is touched and no other consumer passes the prop.

Pre-Merge Checklist 🚀

🚢 Has this modified a publishable library?

This PR:

• modifies an npm-publishable library and I have added a changeset file(s)

A single patch changeset for @hashintel/ds-components.

📜 Does this require a change to the docs?

The changes in this PR:

• are internal and do not require a docs change

🕸️ Does this require a change to the Turbo Graph?

The changes in this PR:

• do not affect the execution graph

⚠️ Known issues

None.

🐾 Next steps

If other menus want the same treatment, menuClassName is the hook; capping the shared recipe instead stays a design-system decision.

🛡 What tests cover this?

No new test — the change is CSS on one menu. Existing ds-components snapshots cover the primitive's unchanged appearance.

❓ How to test this?

1. Open Petrinaut in a host that shows the net-management menu items.
2. Save a net whose title is a full sentence, then open the hamburger menu and hover Open.
3. Confirm the submenu stops at roughly 600px wide, the title ends in an ellipsis, the timestamp is still readable, and the list scrolls rather than growing past 80% of the window height.

📹 Demo

Verified in the ds-components nested-menu story with the same style applied through menuClassName; screenshots and measurements are in the Slack thread.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01VkuGK4P2VXYGTXBTZbC67H

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
hash	Ready	Preview	Sep 15, 2026 2:55pm UTC
petrinaut	Ready	Preview	Sep 15, 2026 2:55pm UTC

2 Skipped Deployments

Project	Deployment	Actions	Updated
hashdotdesign-tokens	Ignored	Preview	Sep 15, 2026 2:55pm UTC
petrinaut-docs	Ignored	Preview	Sep 15, 2026 2:55pm UTC

[cursor]

PR Summary

Low Risk
Opt-in API and CSS on one Petrinaut submenu; existing menus keep the same class strings when menuClassName is omitted.

Overview
Adds an opt-in menuClassName on SelectableList / Menu items that have subItems, merged onto that item’s nested Menu.Content so only that submenu can get extra styles without changing shared recipes.

Petrinaut’s hamburger Open entry uses it with Panda styles: white-space: nowrap so long saved-net titles ellipsize, and max-width / max-height caps (with && so they beat the default content max-height) so the list scrolls instead of filling the viewport.

Ships a @hashintel/ds-components patch changeset; other menus are unchanged unless they pass the new prop.

^{Reviewed by Cursor Bugbot for commit 87ea955. Bugbot is set up for automated code reviews on this repo. Configure here.}

[alex-e-leon]

LGTM

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[claude]

Standing down on five red checks — none of them are this diff's, and no code change is needed.

Linting passed, Tests passed, Deployments passed, Benches passed on 3783bd8 — these were cancelled, not failed, and they are on a superseded commit. All four workflow runs (34983224191, 34983224138, 34983224081, 34983224129) conclude cancelled. Each one's setup job was cancelled at 14:44:42–14:44:44Z, seconds after 87ea955 was pushed, and Lint, Test, Bench and Deploy all declare concurrency: ${{ github.workflow }}-${{ github.event.pull_request.number }} with cancel-in-progress: true, so the older run is cancelled by design.

The … passed jobs are aggregate gates (if: always()) whose first step asserts [[ ${{ needs.setup.result }} = success ]]. With setup cancelled that step exits 1 — "Process completed with exit code 1." — and every later check step reports skipped. So no lint, test, bench or deploy body ran at all; the child jobs (Package, Global, Unit, Integration, the build matrices) all show started_at == completed_at. main at this PR's base 01f59f9 is green on all four workflows.

The run set on the live head is the real one, and its suites are executing rather than being skipped — Benches passed is already green there.

copilot-pull-request-reviewer — this is GitHub's own Copilot Code Review agent (run path dynamic/agents/copilot-pull-request-reviewer), not a repo workflow and not a test of this change. It failed inside its own Processing Request (Linux) step. 25 of this repository's last 50 Running Copilot Code Review runs failed the same way on unrelated commits, including three earlier today, so it is a pre-existing flake in that agent rather than anything here. No fix exists on our side. I could not read the step's log text: GitHub redirects job logs to a blob host that this session's egress policy blocks, so the diagnosis above rests on the job's step results, annotations and the repo-wide run history.

No commits pushed for any of this.

---

Generated by Claude Code