[Bug]: opencli browser 在 Bilibili 多步骤操作中会间歇性跳回 about:blank

[upsightx]

Description

在使用 opencli browser 对 Bilibili 视频页执行多步骤操作时，浏览器会话有时会在若干独立命令之间意外丢失，页面直接变成 about:blank。

这个问题会导致类似下面这种正常流程变得不稳定：

• 打开视频页
• 检查页面状态
• 滚动到评论区
• 定位评论输入框
• 输入评论
• 点击发布

我实际排查后发现，Bilibili 页面本身虽然存在懒加载和多层 Shadow DOM，但这些都可以通过正确的定位方式处理；真正更影响使用的是：opencli browser 在多次独立调用之间，偶发性地把当前页面上下文丢掉，回到 about:blank。

Steps to Reproduce

1. 打开一个 Bilibili 视频页：

   opencli browser open https://www.bilibili.com/video/BV1E7wtzaEdq

2. 然后分多次执行后续命令，例如：

   • opencli browser state
   • opencli browser eval '...'
   • opencli browser scroll down
   • opencli browser eval '...'

3. 在执行到后面的某一步后，再次查看页面状态。

4. 部分情况下，当前页面会变成：

   about:blank
   

更贴近真实使用的复现流程是：

1. 打开视频页
2. 检查评论区结构
3. 滚动到 #commentapp，触发评论组件懒加载
4. 递进进入多层 Shadow DOM，定位评论输入框
5. 再执行下一条 browser 命令
6. 页面有概率直接跳成 about:blank

Expected Behavior

期望 opencli browser 在多次独立命令之间，能够稳定保持同一个页面会话，而不是在正常自动化流程中随机丢失页面上下文。

如果页面或会话确实失效，也希望 OpenCLI 能明确提示原因，而不是静默地落到 about:blank。

OpenCLI Version

1.7.4

Node.js Version

22.x

Operating System

Windows

Logs / Screenshots

我观察到的现象是：

• opencli browser open 能成功打开 Bilibili 视频页
• 但后续某次 opencli browser eval / state / scroll 之后，再检查时会看到：

  url: about:blank
  title:
  

补充上下文：

• Bilibili 评论区本身是懒加载 + 多层 Shadow DOM，结构大致是：
  #commentapp -> bili-comments -> #contents -> #reply-commentbox -> bili-comment-box -> bili-comment-rich-textarea -> .brt-editor
• 只要先滚动到评论区、等待组件挂载，再进入 Shadow DOM，评论输入和发布按钮其实都能正确定位
• 我把整条流程压成一次连续命令后，可以成功做到：
  • 定位评论输入框
  • 输入 hi
  • 点击发布
  • 观察到输入框被清空
• 所以目前看，真正的主要问题不是页面结构太复杂，而是 opencli browser 在多次独立调用之间的会话保持不稳定

[Astro-Han]

Hi，感谢详细的排查，信息量很大。

你观察到"压成一次连续命令就正常"这个现象基本锁定了原因：extension 有一个 30 秒的窗口空闲超时（WINDOW_IDLE_TIMEOUT = 30000，在 extension/src/background.ts:132）。每次 opencli browser 命令执行完进程就退出了，如果下一条命令超过 30 秒才到，extension 会关掉自动化窗口并清除 session，下次命令进来就新建一个 about:blank 窗口。

另外，CLI 端每次调用都是无状态的（新建 Page 对象，targetId 不会跨进程保留），所以即使窗口还在，CLI 也无法告诉 extension "继续操作上次那个 tab"，只能靠 extension 侧的 workspace session 去匹配。

改进方向可能包括：

1. browser:* workspace 用更长的 idle timeout（比如 5 分钟），和 adapter 的 30 秒区分开
2. 窗口因超时被关闭后，下次命令给出明确提示，而不是静默创建新窗口

目前的 workaround：尽量在 30 秒内执行下一条命令，或者用单次调用串联多步操作。