Windows embedded mandatory update
Windows 内嵌强更弹窗
A second native Windows window does not resize atomically with its parent, producing a detached overlay during maximization (#4566). Native modality also disables the parent controls that users need to exit.
English
Problem
A second native Windows window does not resize atomically with its parent, producing a detached overlay during maximization (#4566). Native modality also disables the parent controls that users need to exit.
Decision
Windows uses one native window and a shell-origin frame below the caption. This partially supersedes the presentation decision in the mandatory-update client; that note retains policy and installation ownership. macOS retains its native overlay.
The isolated application preload transfers a private MessageChannel endpoint directly to the shell frame. Only messages on the paired private port authorize update IPC; synthetic window events cannot invoke actions. The main process validates the current application main frame and rebinds state delivery when the main window changes. Destroyed windows receive neither state nor focus operations.
Alternatives considered
Synchronize a second native window. Parent movement, maximization and restoration expose independently scheduled geometry updates; removing the second window removes that synchronization problem.
Treat source and origin on window events as authentication. Product scripts can construct those event fields. A private port keeps action authority outside the shared product document.
Consequences
Caption menus and Web controls remain reachable. The DOM overlay blocks ordinary background input but cannot prevent product scripts from hiding or imitating presentation; it is not a tamper-proof security surface. Main-process policy and installation authorization remain separate from that display. Regression coverage requires forged-event rejection, real channel delivery, caption keyboard operation, and destroyed/replacement-window lifecycle cases.
中文
问题
Windows 的第二个原生窗口无法与父窗口原子地缩放，最大化时会出现脱离的蒙层（#4566）。原生模态还会禁用用户退出应用所需的父窗口控件。
决策
Windows 使用一个原生窗口和顶栏下方的壳源站 frame。此决策部分取代强更客户端的展示决策；该说明继续负责策略与安装归属。macOS 保留原生蒙层。
隔离的应用预加载将私有 MessageChannel 端点直接传给壳 frame。只有配对私有端口上的消息才能授权更新 IPC；合成的 window 事件不能调用操作。主进程校验当前应用主 frame，并在主窗口变化时重新绑定状态投递。已销毁窗口不再接收状态或焦点操作。
考虑过的替代方案
同步第二个原生窗口。 父窗口移动、最大化与还原会暴露独立调度的几何更新；去掉第二个窗口即可消除这一同步问题。
把 window 事件的 source 和 origin 当作身份认证。 产品脚本可以构造这些事件字段。私有端口将操作权限保留在共享产品文档之外。
后果
顶栏菜单和 Web 控件仍可触达。DOM 蒙层阻止普通背景输入，但不能阻止产品脚本隐藏或仿造展示；它不是防篡改的安全界面。主进程策略和安装授权与展示相互独立。回归覆盖要求包括拒绝伪造事件、真实通道投递、顶栏键盘操作，以及窗口销毁和替换的生命周期用例。