fix(contextmenu): fix submenu hover gap — move bridge pseudo-element to parent li

[a652]

Summary

Fix the submenu disappearing issue when moving the mouse from a parent menu item toward its submenu. The submenu was nearly impossible to click due to a 4px gap where hover was lost.

Related Issue

Changes

• Remove broken ::before bridge from .wk-ctx-submenu (was on the wrong element — cannot cover a gap outside its own boundary)
• Add correct ::after bridge on the parent li:has(> .wk-ctx-submenu), extending its hover area 8px rightward to bridge the 4px gap
• Mirror fix for .wk-contextmenus-flip-submenu (left-opening submenu) case

Testing

• Unit tests added/updated
• Manually verified

Reproduced the bug on latest main: hovering over 「更多」 in the chat list right-click menu and moving the mouse rightward caused the submenu to disappear immediately. After fix, the submenu stays open when crossing the gap.

Root cause explanation:

Parent <li> │ 4px gap │ .wk-ctx-submenu
             ↑
   Mouse crosses here → old ::before (on submenu) can't reach this area
   New ::after (on parent li) extends rightward and covers it ✓

Checklist

• I have read CONTRIBUTING.md
• PR description is in English
• Added tests for my changes
• Updated documentation
• Followed commit message conventions (Conventional Commits)

[Jerry-Xin]

This PR is in scope and fixes existing ContextMenus behavior in packages/dmworkbase.

✅ Highlights

• The bridge is now attached to the hovered parent li, which correctly preserves li:hover while crossing the submenu gap: packages/dmworkbase/src/Components/ContextMenus/index.css:125.
• The left-opening submenu case is mirrored correctly for flipped menus: packages/dmworkbase/src/Components/ContextMenus/index.css:141.
• The change is isolated to CSS hit-area behavior; I found no security, data-flow, performance, or architecture regressions.

No blocking issues found.

[lml2468]

Review — PR #45 fix(contextmenu): submenu hover gap

Verdict: APPROVE ✅

Analysis

Root cause understanding — correct.
The old ::before was on .wk-ctx-submenu itself. A pseudo-element cannot extend outside its parent's box, so it could never bridge the 4px gap between the parent <li> and the submenu. Moving the bridge to the parent <li> via ::after is the right fix because:

1. .wk-contextmenus li already has position: relative — the ::after anchors correctly
2. right: -8px; width: 8px extends the hit area 8px beyond the <li> boundary, fully covering the 4px gap (left: calc(100% + 4px) on the submenu)
3. Hovering the ::after maintains li:hover, which keeps li:hover > .wk-ctx-submenu { display: block } active

DOM structure verified (read index.tsx at head SHA):

<li> → <ul className="wk-ctx-submenu"> (direct child)

So li:has(> .wk-ctx-submenu) targets correctly.

Flip case — correctly mirrored: left: -8px for .wk-contextmenus-flip-submenu.

Browser compat — :has() is baseline since late 2023 (Chrome 105+, Firefox 121+, Safari 15.4+). No concern for 2026.

No layout side-effects — the ::after is position: absolute so it does not displace any siblings, and the component only supports 1-level nesting (no recursive submenu rendering), so there is no stacking edge case.

Non-blocking note

💬 The pseudo-element has no explicit background: transparent or pointer-events declaration. It works as-is (both default correctly for hit-testing), but a comment /* invisible hover bridge */ one-liner on the content: "" line would help future readers understand the intent at a glance. Completely optional.