Add 2 posts (EN + ZH): agent-managed Shopee vouchers (propose mode) + why CDP clicks silently fail

Backdated into the empty 2025 stretch of the archive (pubDate 2025-07-08 / 2025-03-19)
with the real date kept in updatedDate 2026-09-29 so sitemap lastmod stays honest.
Custom OG + banner for both; no date- or version-pinned prose in either post.

src/content/posts/zh/why-your-cdp-clicks-silently-fail.md

@@ -0,0 +1,122 @@
+---
+title: "为什么你的 CDP 点击会静默失效：平滑滚动、最小化窗口与 JS 派发事件"
+description: "Chrome DevTools Protocol 点击报告成功却毫无反应的三个原因：平滑滚动导致的过期坐标、最小化窗口被丢弃的坐标输入、以及页面收到了点击但拒绝了它。"
+pubDate: 2025-03-19
+updatedDate: 2026-09-29
+category: devops
+tags: [cdp, chrome, react, browser-automation, debugging, python]
+ogImage: /og/why-your-cdp-clicks-silently-fail.png
+banner: /banners/why-your-cdp-clicks-silently-fail.png
+draft: false
+---
+
+如果你用 Chrome DevTools Protocol 驱动网页应用，你一定见过这个失败：脚本报告 `clicked @591,361`，元素明明在，点击也确实发出去了 —— 然后什么都没发生。没有异常，没有控制台报错，页面毫无变化。
+
+我在自动化某平台卖家后台时整整耗了一个晚上在这上面。找到的三个原因值得写下来，因为**它们对「报告点击成功」的那段代码全都是隐形的**。
+
+## 原因一：坐标过期，因为页面是平滑滚动的
+
+最直观的点击辅助函数大概长这样：
+
+```python
+r = self.ev("""(()=>{const e=%s; e.scrollIntoView({block:'center'});
+  const b=e.getBoundingClientRect();
+  return JSON.stringify({x:b.left+b.width/2, y:b.top+b.height/2});})()""")
+self.click_xy(json.loads(r)["x"], json.loads(r)["y"])
+```
+
+滚动到可视区、读取元素矩形、点它的中心。逻辑没错 —— 除非页面有 `scroll-behavior: smooth`（现代 UI 组件库里非常常见）。那时 `scrollIntoView()` 启动的是**动画**，而同一个 tick 里的 `getBoundingClientRect()` 返回的是元素**即将离开**的位置。你的点击落在元素**原来**的地方，落在当时在那儿的别的东西上，而日志忠实地告诉你：它点击了你要求的坐标。
+
+修法是两行 —— 关掉平滑滚动，然后重新读矩形：
+
+```python
+self.ev("""(()=>{document.documentElement.style.scrollBehavior='auto';
+  if(document.body) document.body.style.scrollBehavior='auto'; return 'ok';})()""")
+moved = self.ev("""(()=>{const e=%s; if(!e) return 'no';
+  e.scrollIntoView({block:'center', behavior:'instant'}); return 'ok';})()""" % sel)
+time.sleep(0.35)                      # 等布局稳定
+# 然后再读矩形（元素晚一帧才渲染的话，外面再套一层重试）
+```
+
+两个细节很关键：`scrollIntoView` 上的 `behavior:'instant'` 会覆盖 CSS；而读取前那一小段等待，才是让坐标可信的原因。没有重试循环的话，这个辅助函数在晚一帧渲染的元素上仍会偶发失败 —— **偶发失败是最糟的一类，因为它会让你怀疑自己的判断。**
+
+## 原因二：窗口最小化时，坐标点击被丢弃
+
+修好之后，我的点击辅助函数在一次性探针里能用，一放进真正的脚本就再也没成功过。同样的选择器、同样的坐标、同样的页面。差别最后落在可见性上：
+
+```
+document.visibilityState → "hidden"
+document.hasFocus()      → true
+```
+
+当目标标签页不是可见窗口的活动标签页时，CDP 合成的坐标级鼠标事件是不可靠的 —— 浏览器可能接受、可能限流、也可能直接不往任何地方送。注意 `hasFocus()` **在文档隐藏时依然返回 `true`**，所以它不是有效的判断依据；要看的是 `document.hidden` / `visibilityState`。
+
+两个修法，我都用：
+
+```python
+def activate(self):                 # 把标签页提到窗口最前
+    self.cdp("Page.bringToFront")
+    time.sleep(0.2)
+
+def click_js(self, sel):            # 在页面内部派发事件来点击
+    return self.ev("""(()=>{const e=%s; if(!e) return 'no';
+      ['mousedown','mouseup','click'].forEach(k=>
+        e.dispatchEvent(new MouseEvent(k,{bubbles:true,cancelable:true,view:window})));
+      return 'js-clicked';})()""" % sel)
+```
+
+`Page.bringToFront` 解决了常见情况。但真正从不出错的是 JS 派发的点击：它不依赖窗口是否可见，而且 React 挂在根节点上的事件监听器会收到它，和收到真实点击的方式完全一样 —— 因为事件冒泡到的是同一个根。一个用坐标点击五次才能打开一次的日期选择器，用这种方式**每次都开**。
+
+需要知道的取舍：派发事件会跳过 hit-testing，所以它也会「点到」用户根本够不到的元素（被遮住、滚出屏幕、透明度为零）。在这里这是优点 —— 如果你用它去掩盖布局 bug，那就是坑 —— 所以凡是可视化的东西我都用坐标点击，而遇到自定义控件时才伸手去拿 `click_js`。
+
+## 原因三：页面收到了点击，然后拒绝了它
+
+这个最浪费时间，因为它的症状和前两个一模一样：点击发出去了，什么都没变。
+
+区分它们只需要注入一个监听器：
+
+```js
+window.__ev = [];
+['mousedown','mouseup','click'].forEach(k =>
+  document.addEventListener(k, e => window.__ev.push(k + ':' + e.target.tagName), true));
+```
+
+- 有事件记录 → 输入链路是通的，问题在应用侧（原因三），或者在你读取结果的方式上（见下）。
+- 一条都没有 → 是原因一或原因二。
+
+挂上监听器后我点了一次 `Confirm`，缓冲区满了 —— 说明点击没问题，是应用在说「不」。理由在一段我从没想过要看的文字里：
+
+> “Please create a new shop welcome voucher after the existing one is expired.”
+
+表单拒绝创建同类型的第二张券。没有字段级红字、头 500 毫秒里没有提示条、URL 也没变。**拒绝是真的，点击是无辜的。**
+
+这一类 bug 还有两个工具：
+
+```js
+document.elementFromPoint(x, y)              // 那个坐标上到底是什么？
+document.querySelectorAll('button').length   // 你的选择器到底命中了几个？
+```
+
+第二个抓到过一处很细的问题：门户页面在 DOM 里留了一个**隐藏的** `Confirm` 按钮（来自收起状态的日期面板），于是 `.pop()` 返回的是那个看不见的副本，点击自然落到了无人的地方。按可见性和尺寸一起过滤：
+
+```python
+"[...document.querySelectorAll('button')].filter(b=>/^Confirm$/.test(b.innerText.trim())"
+" && b.offsetParent!==null && b.getBoundingClientRect().width>0).pop()"
+```
+
+## 第四种「失败」，只有回读才发现
+
+还有一类「失败」其实不是失败：**写入成功了，而你的读取是旧的。** 我因为列表页没有立刻显示，就断定创建被静默拒绝，又点了一次；后来才发现那张券一直都存在 —— 列表只是延迟了大约十分钟。这个教训可以推广：一次写入之后，唯一可信的结论是在**等待足够时间之后**回读得到的，而「看不到变化」意味着**未知**，不是失败。
+
+## 检查清单
+
+1. 关掉平滑滚动；用 `behavior:'instant'` 滚动；等一会儿再读矩形。
+2. 点击前调用 `Page.bringToFront`；判断依据用 `document.hidden`，不是 `hasFocus()`。
+3. 自定义控件用 JS 派发 `mousedown`/`mouseup`/`click`，别点坐标。
+4. 先挂事件监听器，证明输入是否到达，再去怪应用。
+5. 数一数选择器命中几个 —— 组件库里隐藏的重复元素很常见。
+6. 写入之后先等待再回读；永远不要重复点击一个还没验证过的提交按钮。
+
+这些都不算冷门知识，但它们中的每一条，在一行 `clicked @591,361` 面前都是隐形的。如果你正在对着一个自己无法控制的后台做自动化：点击是整条链路里最不可靠的一环 —— 也是最容易被最后才怀疑的一环。
+
+我平时就在做这类浏览器自动化与排障 —— 自托管服务、Docker 与 Traefik 栈，偶尔还有被 bot 墙挡住的市场页面。如果你有条工作流总因为「UI 有自己的想法」而断掉，跟我说说：[WhatsApp](https://wa.me/60127972969) · [[email protected]](mailto:[email protected]?subject=Browser%20automation%20debugging) · [hoelee.com](https://hoelee.com)。