新开的标签页为什么点不动：自动化里的 tab 归属与上下文绑定

新开的标签页为什么点不动：自动化里的 tab 归属与上下文绑定

做浏览器自动化时，有个特别容易误判的场景：点一个链接，页面跳到了新标签页，内容看得见、文字读得出来，可一旦要点击或输入，工具就报错。更折腾的是，报错信息看起来跟"元素找不到"完全无关，很容易把人引到选择器、坐标、等待时间这些方向上去，白查半天。这篇记录一次完整的定位过程，以及后来定下的写法。

## 一、现象：读得到，写不了

流程本身很简单：在案例列表页点「查看详情」，站点用 `target="_blank"` 打开了一个新标签页；接下来需要在新页面里点一个 Star 按钮。

用观察命令去看新标签页，一切正常：标题、按钮文本、引用号都在，甚至能准确定位到那个 `button "Star 72"`。可只要一执行点击，就返回一句类似这样的错误：

```

Select an owned task tab; borrow user tabs explicitly

```

或者另一个变体：

```

Cooperation requires an owned tab

```

换成同步上下文、切换活动标签页、给标签页绑定协作状态，全都不行。而同一个工具在别的标签页上点按钮一直是好的。这说明问题不在页面结构，也不在元素本身。

## 二、把"读"和"写"拆开看

关键的一步是意识到：读取和写入走的是两条不同的权限路径。

观察类命令只需要能访问到那个标签页的渲染树，属于只读操作，工具对标签页来源不挑剔，因此新标签页照样能读出完整内容。而写入类命令要先建立一次"同步上下文"，把这次动作的观察快照、目标 tab、控制策略绑在一起；这个绑定过程要求目标 tab 是任务自己创建的、处于受控状态的标签页。

由页面上的链接 spontaneous 打开的新标签页，在扩展侧看来是"用户行为产生的"，不在任务的拥有范围内，于是同步这一步直接拒绝。表现出来就是：读得到、点不动，而且报错指向的是 tab 归属，不是元素。

顺带解释了另一个迷惑点：明明点了链接、页面也跳了，可"等待同步"返回的仍是上一个标签页的 id。工具的共享 tab 指针并没有跟着浏览器焦点走，它只认可自己管理的那一个。

## 三、根因：上下文是绑定到具体 tab 的

再往下挖一层，是同步上下文的结构。一次同步会返回几个东西：上下文 id、观察 id、tab id、控制策略。后续的点击必须带上这次同步发出的上下文 id，而该上下文从一开始就绑定了某个具体的 tab。

所以"切标签页"这个动作并不能改变上下文的归属，重新同步一次也不行——只要目标 tab 本身不受控，同步就会在入口被挡住。之前反复尝试 `tab select`、`cooperate enable` 全部无效，原因都在这里：它们改变的是焦点，不是所有权。

## 四、可复用的解法

既然所有权才是门槛，解法就不需要绕什么弯：不要让页面替你开标签页，改成自己显式创建。

1. 从页面里把目标 URL 读出来（链接的 `href` 或者接口给出的地址）。

2. 用标签页创建命令，以这个 URL 新建一个受控标签页；拿回它返回的 tab id。

3. 对这个新 tab id 做一次同步，取得上下文 id。

4. 再观察一次，从观察文本里找按钮的引用号。

5. 点击时同时带上上下文 id 和这个 tab id。

整套流程里最容易被省略的是第 2 步——觉得"反正页面上已经打开了这个地址"，就直接拿旧 tab 去同步。恰恰是这一步决定了后面能不能写。

一个附带的好处：因为上下文与 tab 明确绑定，多个任务并行时不会互相踩到对方的观察快照，重试也更安全。

## 五、两条写进脚本的纪律

第一，遇到"读得到写不了"，先查 tab 归属，再查元素。判据很简单：同样的观察命令能出结果，而任何写命令都报 owned tab / cooperation 相关错误，基本就是这个问题，不用去折腾选择器和等待。

第二，凡是页面可能新开标签页的流程，一律走"读出 URL → 显式创建 → 同步 → 动作"，不复用浏览器自己打开的 tab。多一步调用，省掉一整轮误判。

还有个容易顺手踩的坑：观察文本里的引用号每次重新观察都可能变，跨轮次复用会报未知引用；所以上面的顺序里，观察必须放在同步之后、点击之前，中间不要插入别的操作。

## 六、小结

自动化工具里的"看见"和"能操作"是两件事，中间隔着一层上下文绑定。报错指向 tab 的时候就顺着 tab 查，别被页面内容迷惑。把"新标签页一律重建"写成固定套路之后，这类问题从一次半小时的排查变成了三行固定代码。