单表面与多窗假设

【踩坑实录】单表面与多窗假设

▍现象
邮件客户端工程：主窗口渲染正常、收发核心链路能跑，但一批关键功能集体死亡——撰写邮件的独立窗口弹不出来或弹出来全黑、账户配置向导的完成按钮无反应、高级配置窗打不开。工程记录的定性原文：内核构建成功、主窗渲染正常，仍然不等于一个可用的邮件客户端。

▍定位过程
把死掉的功能列出来找共性：撰写窗（独立顶层窗）、向导完成按钮（弹出授权窗）、高级配置窗（独立窗）、验证下拉（弹出面板）——全是独立顶层窗口家族。而移植架构是单 EGL 表面：一切内容合成到一块表面上。结论水落石出：单表面架构下，一切独立顶层窗口都是死窗。这是 Gecko 平台层的结构性约束，不是 bug。

▍对策
工程没有笼统标记弹窗不支持，而是把死窗家族逐个登记、逐个选型三条改道路径：一，标签化（撰写窗改为标签页装载——主窗内的标签承载原独立窗的内容，工程的改道主路径）；二，绕过（账户向导用配置种子直注绕过向导流程——向导的意义是引导配置，种子直接完成配置，向导可跳过）；三，替代通道（确认与提示类弹窗改文件双向确认）。每条通道单独验证输入输出链。

▍根因抽象
桌面应用的窗口假设是随时可以开新顶层窗；单表面环境的窗口预算是一。所有多窗设计都要过一遍翻译：哪些窗能进标签（内容型）、哪些能被绕过（流程型）、哪些要替代（交互型）。

▍方法论沉淀
移植前的窗口普查（静态与动态的顶层窗来源全列），按三条改道路径分诊。拖着不改的结果就是一个个死窗在验收时爆炸——邮件工程的窗口边界登记表是同类工程的参考模板。

单表面改道的完整家族记录在邮件工程实录，apps 板块 56 篇欢迎对照。