本文介绍如何通过 Electron 的 will-frame-navigate 事件，在无法控制 iframe 源内容的前提下，安全、可靠地拦截其内部触发的 mailto: 链接，防止系统默认邮件客户端意外启动，保障全屏 Kiosk 模式下的应用沉浸性与流程可控性。
本文介绍如何通过 electron 的 `will-frame-navigate` 事件，在无法控制 iframe 源内容的前提下，安全、可靠地拦截其内部触发的 `mailto:` 链接，防止系统默认邮件客户端意外启动，保障全屏 kiosk 模式下的应用沉浸性与流程可控性。
在构建全屏、无边框的 Electron Kiosk 应用时，常需嵌入第三方网站（如信息展示页、表单系统）于 <iframe> 中。尽管可通过 sandbox 属性禁用弹窗、脚本执行等高风险行为，但 mailto: 协议链接仍会绕过沙箱限制——点击后直接调用系统默认邮件客户端，导致用户完全脱离当前应用，破坏 Kiosk 的封闭性与操作连续性。
关键在于：webContents.will-navigate 事件仅捕获主页面导航，对 iframe 内部的跳转（包括 mailto:、tel:、file: 等协议）完全静默。而 Electron 提供了专用于子帧（sub-frame）导航的互补事件：will-frame-navigate。该事件在任何 iframe（无论是否 sandboxed、是否跨域）触发导航前触发，且支持同步拦截。
✅ 正确实现方式如下（主进程代码）：
// 假设 win 是你的 BrowserWindow 实例
win.webContents.on('will-frame-navigate', (event, url) => {
// 拦截所有 mailto: 协议请求
if (url.startsWith('mailto:')) {
event.preventDefault(); // 阻止默认行为（启动邮件客户端）
console.log('[Blocked] mailto link prevented in iframe:', url);
// 可选：向渲染进程发送通知，或触发自定义处理逻辑（如弹出轻量表单）
// win.webContents.send('mailto-blocked', { url });
}
});⚠️ 注意事项：
- 该事件仅在 Electron 12+ 中稳定可用（推荐 ≥ v16），旧版本需升级；
- will-frame-navigate 是同步事件，event.preventDefault() 必须在此处调用，异步延迟无效；
- 它同样适用于其他危险协议（如 javascript:、file://），可扩展为统一协议白名单策略；
- 若需保留部分 mailto: 功能（如收集邮箱后内嵌发信），建议结合 ipcRenderer.invoke() 在渲染进程主动发起受控通信，而非依赖原始链接跳转。
? 总结：will-frame-navigate 是 Electron 提供的关键“子帧守门员”事件，是解决第三方 iframe 协议泄露问题的官方、轻量、零侵入方案。配合合理的日志记录与降级反馈，即可在不修改外部网站的前提下，全面加固 Kiosk 应用的协议层安全边界。
