③更新每条任务 Page.bringToFront 抢前台改为:每账号首任务提一次 + 后台态拖拽/上传疑似节流失败(DRAG_NOT_FIRST/UPLOAD_STILL_PROCESSING/ UPLOAD_TIMEOUT)自动升级前台重试一次。含①③不对称技术原因 (Windows 遮挡节流)、文档同步项与不做启动参数的红线说明。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
5.2 KiB
5.2 KiB
id, title, phase, deps, status, created
| id | title | phase | deps | status | created | ||
|---|---|---|---|---|---|---|---|
| T-571 | ③更新抢前台降频:每账号只提一次 Chrome 前台 + 拖拽/上传失败自动升级前台重试 | 7 |
|
TODO | 2026-07-09 |
问题 / 背景
③更新蝦皮时,apply_task(app/editor.py:1248)每条任务调 open_product(account, item_id),走默认 bring_to_front=True(editor.py:756):create_tab_info(background=False) 以激活态建 tab + Page.bringToFront(editor.py:777)把整个 Chrome 窗口提到 OS 前台。用户切到其他软件后,每开始一条任务(几十秒一条)Chrome 就抢一次前台,批量几百条 = 焦点被抢几百次,正在输入的内容可能误入 Chrome。
①采集已是 bring_to_front=False(T-562,editor.py:830)。①③不对称有技术原因,不能无脑把③改 False:①只读;③要做真实 UI 交互(cdp.drag 34 步拖拽换首图、上传等待、点更新)。CDP Input.dispatchMouseEvent 注入渲染进程不需要 OS 焦点,但 Windows 上 Chrome 有遮挡检测(occlusion tracking):窗口被完全遮挡或最小化 → visibilityState: hidden → rAF 暂停、JS timer 节流到 1 次/秒,Shopee 拖拽排序库/上传组件可能失灵(DRAG_NOT_FIRST、UPLOAD_STILL_PROCESSING 假超时)。部分可见则正常。
结论:「不抢前台」与「交互必成」在完全遮挡时真冲突 → 用「每账号一次 + 失败升级」组合化解。
方案(改哪个文件、改成什么)
方案 1:抢前台从「每任务」降为「每账号一次」
apply_task增加bring_to_front参数(默认True保持函数级向后兼容),透传给open_product。- ③
ApplyWorker(app/gui/workers.py更新循环)维护「本轮已提过前台的账号集合」:同一账号第一条任务bring_to_front=True(换账号提示一次,有「正在处理该店」的信号意义),该账号后续任务传False。 - worker 重开/新一轮更新 → 集合重置(每轮每账号仍提一次)。
方案 2:拖拽/上传失败自动升级前台重试(兜底)
apply_task(或replace_cover调用层)当封面替换结果 reason ∈ {DRAG_NOT_FIRST,UPLOAD_STILL_PROCESSING,UPLOAD_TIMEOUT} 且本次是后台态(bring_to_front=False)时:Page.bringToFront提前台 → 同一 tab 内重试一次replace_cover;- 重试仍失败 → 按既有失败口径返回,不无限重试;
- 升级重试要发 on_step 事件(如
cover_retry_foreground),run_logs 可见「已提前台重试」。
- 只对上述三个「疑似后台节流」的 reason 升级;其他失败(
OLD_COVER_BACKUP_MISSING、UPLOAD_DUPLICATE_IMAGE、UPLOAD_CROP_REQUIRED等)与前台与否无关,不升级、不重试。 - 升级重试前须重新读取页面图片状态(
_image_rects/_upload_state),不能拿失败前的旧 rects 继续拖。
文档同步(必须一起改,防止被当 bug 改回)
docs/04-architecture.md/docs/routes.md里「③更新打开商品页保持前台」的表述更新为「每账号首任务提一次前台 + 失败升级」;注明 ①(T-562 完全不抢)与 ③(低频抢 + 升级)的不对称是有意设计及技术原因(遮挡节流)。
不做(本任务边界内明确排除)
- 不加
--disable-backgrounding-occluded-windows等 Chrome 启动参数(典型自动化指纹,触碰「不绕过 Shopee 风控」红线的灰区,收益不值)。 - ⑤设置开关「更新时保持 Chrome 前台」本期不做,若后续有用户环境后台老失败再提任务。
验收要点
- 同一账号连续 N 条任务:仅第一条调用
Page.bringToFront(单测 mockopen_product/CDP 断言调用次数=账号数,不是任务数)。 - 换账号 → 新账号第一条再提一次前台。
- 后台态封面替换返回
DRAG_NOT_FIRST/UPLOAD_STILL_PROCESSING/UPLOAD_TIMEOUT→ 自动提前台重试一次;重试成功计成功;重试失败按原失败口径。 - 前台态(该账号首任务)失败 → 不重复升级(已在前台,无升级意义),按原口径。
- 其他失败 reason(重复图/需裁剪/备份缺失等)→ 不触发升级重试。
- 升级重试有 run_logs 事件可见。
apply_task默认参数不变,直接调用的旧代码行为不回归。- 既有 ③ 更新链路测试(
tests/test_gui.py/tests/test_editor_login.py相关)不回归。 - 验证命令(unittest,不引入 pytest):
py -3.10 -m unittest tests.test_gui tests.test_editor_loginpython -m ruff check app tests main.pypy -3.10 -m compileall app main.pypy -3.10 -m unittest discover -s testsgit diff --check
边界(不改什么)
- 不改①采集就绪/前台策略(T-562 保持)、④登录页
activate_tab行为。 - 不改
replace_cover/change_title/click_update的交互逻辑本身(只在外层加升级重试编排)。 - 不改 Chrome 启动参数、CDP 选择器、DB schema、AI/cmhub 链路。
- 不做⑤设置开关。
执行记录
(做完在这里写:改了什么文件、跑了什么验证命令及结果、遇到的阻塞、关键决策。)