深度解析 Chromium WebUI 的生命周期与 IsJavascriptAllowed 崩溃之谜

在 Chromium (或基于其二次开发的浏览器等内核) 开发中，WebUI 是我们最常打交道的模块之一。诸如 chrome://settings、chrome://history 这些内置页面，都是通过 WebUI 机制实现前端 (HTML/JS) 与底层 C++ 的双向通信。

然而，在处理后台异步任务向前端推送状态时，我们很容易踩到一个极其经典的深坑——导致浏览器直接触发 int 3 指令，出现类似下面的宕机堆栈：

00 chrome!base::ImmediateCrash [inlined]
01 chrome!logging::CheckFailure [inlined]
02 chrome!content::WebUIMessageHandler::CallJavascriptFunction<...>(...)
03 chrome!content::WebUIMessageHandler::FireWebUIListener(...)
...
04 chrome!settings::AboutHandler::UpdateManualUpgradeStatus(...)
05 chrome!UpgradeService::UpdateManualUpgradeStatus(...) // 后台异步服务触发

为什么一个看似普通的 FireWebUIListener 调用，会直接把浏览器搞崩溃？这背后隐藏着 Chromium 团队对生命周期与状态同步极其严苛的设计哲学。

崩溃的元凶：CHECK(IsJavascriptAllowed())

顺着堆栈找到源码，我们会发现崩溃发生在 WebUIMessageHandler 的一段模板代码中：

template <typename... Values>
void CallJavascriptFunction(std::string_view function_name, const Values&... values) {
  // 致命的断言！如果为 false，直接 base::ImmediateCrash 宕机！
  CHECK(IsJavascriptAllowed()) << "Cannot CallJavascriptFunction before explicitly allowing JavaScript.";

  web_ui()->CallJavascriptFunctionUnsafe(function_name, values...);
}

触发崩溃的原因非常直接：IsJavascriptAllowed() 返回了 false。

这引发了三个核心问题：

1. 这个状态位是什么？
2. 为什么它会变成 false？
3. 为什么 Chromium 不选择默默 return 忽略这个调用，而是非要用 CHECK 把浏览器弄崩溃？

为什么需要状态锁？WebUI 的三大通信痛点

WebUI 的前端运行在渲染进程（Renderer），后端 C++ 运行在浏览器进程（Browser）。这种跨进程的异步通信面临着严重的“时序错乱”挑战：

1. 过早调用（JS 未就绪）： 页面刚打开，DOM 和 JS 都还没加载完。如果后台 C++ 此时立刻推送数据，Renderer 进程会因为找不到对应的 JS 回调而报错或丢失状态。
2. 过晚调用（幽灵鞭尸）： 用户刷新了页面或关掉了标签页，旧的 JavaScript Context 已经被销毁。如果 C++ 的某个异步后台任务（如网络请求或下载进度）几秒钟后才完成，它还傻乎乎地去调用 CallJavascriptFunction 更新 UI，相当于在向一个不存在的“幽灵”喊话。
3. 安全风险（跨站信息泄露）： 如果发生导航切换到其他普通网页，残留的后台 Handler 还在发特权数据，极易引发安全漏洞。

解决方案：强制“握手”与“拔网线”机制

为了解决这些痛点，Chromium 在 WebUIMessageHandler 中设计了一套极其严格的生命周期握手机制。

阶段一：前端主动“举手”（Allow Javascript）

当一个 C++ Handler 被创建时，它的麦克风是静音的（IsJavascriptAllowed() == false）。 只有当前端的 JS 彻底加载完毕，并通过 cr.sendWithPromise('aboutPageReady') 等消息告诉 C++：“我准备好了”时，后端的对应方法必须显式调用：

void AboutHandler::HandlePageReady(const base::Value::List& args) {
  AllowJavascript(); // 解除封印，允许向前端发送消息
}

阶段二：框架强制“拔网线”（Disallow Javascript）

一旦页面发生刷新、导航离开或标签页被关闭，底层的 WebUIImpl 会监听到 RenderFrameHost 的销毁事件。 它会立刻遍历挂载在这个页面上的所有 Handler，强制调用虚函数：

void WebUIMessageHandler::DisallowJavascript() {
  javascript_allowed_ = false; // 强行拔掉网线
  OnJavascriptDisallowed();    // 通知子类做清理工作
}

此时，IsJavascriptAllowed() 会立刻变回 false。

为什么非要用 CHECK 崩溃？

如果 C++ 代码在 IsJavascriptAllowed() == false 的情况下依然试图调用 CallJavascriptFunction，这意味着什么？

这意味着开发者的生命周期管理存在严重的逻辑 Bug。

想象这样一个场景（正如导致我们崩溃的那个 Bug）：

1. 页面打开，前端就绪，后台全局单例服务（如 UpgradeService）保存了 AboutHandler 的指针（Observer）。
2. 用户关掉了设置页面。底层框架敏锐地“拔掉了网线”。
3. 但全局服务还在后台勤勤恳恳地下载更新，并且在进度更新时，试图调用那个还未被析构但已失效的 AboutHandler 去通知 UI。

如果 Chromium 仅仅是在底层 return 忽略这个调用，开发者可能永远不会知道：

• 他的后台任务正在对一个失效的页面做无用功。
• 他的全局 Observer 列表里可能堆积了大量无效的指针（潜在的内存泄漏或 Use-After-Free）。

“Fail Fast（尽早失败）” 是 C/C++ 底层系统编程的黄金法则。让程序在不该发生的事情发生时立刻触发 int 3 宕机，带上完整的调用栈，逼着开发者去修复隐藏在异步回调里的生命周期管理漏洞。

正确的防御姿势

理解了这个机制，修复方案就呼之欲出了。在 WebUI Handler 中处理后台异步回调时，必须在向前端喊话之前，先看看麦克风还在不在自己手里：

void AboutHandler::UpdateManualUpgradeStatus(const std::string& status, int progress) {
  // 【关键防御】如果页面已刷新或关闭，底层框架已禁止 JS 通信，直接返回
  if (!IsJavascriptAllowed()) {
    return;
  }

  // 确认安全后，再向前端推送消息
  base::Value::Dict event;
  event.Set("status", status);
  event.Set("progress", progress);
  FireWebUIListener("update-status-changed", event);
}

或者，更彻底的做法是：重写 OnJavascriptDisallowed()，在网线被拔掉的瞬间，主动注销所有的全局监听器：

void AboutHandler::OnJavascriptDisallowed() {
  // 页面失效时，主动告诉后台服务：别再给我发消息了！
  UpgradeService::GetInstance()->RemoveManualUpgradeObserver(this);
}

结语

Chromium 的代码虽然庞大复杂，但每一处看似“不讲理”的 CHECK 崩溃背后，往往都藏着精心设计的防御体系。理解 IsJavascriptAllowed 的底层逻辑，不仅能帮我们修掉棘手的崩溃，更能让我们在编写异步 C++ 代码时，时刻对对象的生命周期与状态机保持敬畏。