fix:submenu overflow popupoffset

[CooperHash]

ref: #668

background

When we set the popupOffset, we expect all submenus to have an offset from the menu item. However, when the window width is small, the menu overflows. The overflow, represented by ... as an overflow placeholder, does not have a submenu offset.

It is necessary to fix it

before fix:

menu.mov

after fix:

menu.mov

[yoyo837]

Why is the default value this?

[CooperHash]

i refer rc-menu docs's demo
if not, what value is appropriate

[yoyo837]

@zombieJ @MadCcc @afc163 Pls take a look.

[yoyo837]

And, some new test case is needed.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.58%. Comparing base (4ae012f) to head (57b5938).
⚠️ Report is 77 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #690   +/-   ##
=======================================
  Coverage   99.58%   99.58%           
=======================================
  Files          27       27           
  Lines         721      722    +1     
  Branches      196      199    +3     
=======================================
+ Hits          718      719    +1     
  Misses          3        3           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[zombieJ]

From a functional and naming standard, should this be provided? @MadCcc

[CooperHash]

i refer from this

menu/src/interface.ts

Line 30 in 4ae012f

popupOffset?: number[];

[CooperHash]

And, some new test case is needed.

i have no idea how to mock overflow

[alekseykurylev]

@zombieJ @yoyo837 When should this PR be expected in the release?

[CooperHash]

@zombieJ @yoyo837 When should this PR be expected in the release?

I haven't written the test yet, so you'll need to wait for me to finish writing it before they can review it.

[nrps9909]

I found a backward-compatibility blocker on exact head 57b5938d0bb0bb906217db350280392361cdafc6.

The generated overflow SubMenu currently receives:

popupOffset={overflowPopupOffset || [10, 15]}

That changes every existing horizontal overflow menu, even when the new prop is not configured. I added a temporary Trigger-capture regression that rendered a plain horizontal Menu with one item and expected no explicit popupAlign. On this head it fails because the Trigger receives { offset: [10, 15] }. A companion case with overflowPopupOffset={[3, 7]} correctly receives { offset: [3, 7] }.

Please preserve the existing default by passing the offset only when explicitly configured (for example, popupOffset={overflowPopupOffset}), type the public value consistently with the existing offset tuple contract, and commit both configured and unconfigured overflow regressions. The hardcoded demo value is not a safe library default.

For context, the branch's complete historical suite currently reports 9 passing suites and 1 failure, with 115 passing tests and 18 snapshots. The sole existing failure is the old Responsive StrictMode assertion observing the current React act deprecation warning; it is unrelated to the offset code. The branch has no committed test for this new API. Its old lint/tooling scripts also no longer run against the shared modern ESLint setup, although GitHub reports the branch cleanly mergeable with current master.

AI assistance disclosure: Codex was used to inspect the exact diff and existing review threads, build and run the temporary Trigger-level regression, and draft this review. I verified the failure and exact head before submission.