[Feature]: Support 1688 Extension - Product Image Download

[zhangxiao918]

Feature Description

Support accessing the 1688 official browser extension's "Product Image Download" feature to obtain complete product image resources.

Use Case

As an OpenCLI user, I need to batch download images from 1688 product pages (e.g., 1688.com/offer/XXXXX.html). The 1688 extension provides an official image download feature that can obtain all product images (including main images, videos, etc.), but OpenCLI's browser automation cannot access the UI elements created by the extension.

Proposed Solution

• The "Product Image Download" button on 1688 product pages triggers the extension to create a popup window
• The popup contains a "Direct Download" button that calls the official API to download all product images
• However, this popup runs in an isolated extension environment, and state/eval commands cannot access its DOM

Alternatives Considered

None.

[zhangxiao918]

Additional Technical Analysis / 补充技术分析

Core Problem / 核心问题

The 1688 extension's popup is NOT a standard DOM element. It's likely running in one of these isolated contexts:

1. Shadow DOM - Web Components的隔离作用域
2. Chrome Extension Popup - 浏览器扩展创建的独立窗口
3. Chrome Native UI - 浏览器原生的UI层

Why OpenCLI Can't Access It / 为什么OpenCLI无法访问

Method	Result	Reason
state	❌ Not found	Shadow DOM creates isolated DOM tree
eval	❌ Not found	Script context is separate
screenshot	✅ Visible	Rendering layer is still captured

Broader Implication / 更广泛的意义

Instead of treating this as a "1688 plugin issue", it should be addressed as a fundamental browser automation limitation - Shadow DOM / Extension Context traversal.

这个问题不应该只被视为"1688插件问题"，而应该作为浏览器自动化的基础技术限制来对待——即Shadow DOM /扩展上下文的遍历问题。

[Astro-Han]

Thanks for the detailed write-up, this looks like a real gap.

One small suggestion on framing: the underlying need may be broader than supporting the 1688 extension popup itself.

From what I can tell, the main user goal is to get the complete media assets of a 1688 product page, while the current blocker is that the official extension's download UI appears to run in an isolated extension context, so OpenCLI's normal page-level state / eval access cannot reach it reliably.

Because of that, maybe it makes sense to think about this as:

• exporting complete product media from a 1688 item page
• rather than specifically automating the third-party extension popup UI

A possible implementation direction, if maintainers think it fits the project:

1. Inspect whether the full asset list is already available in page state or network responses for the product page.
2. If not, compare that with the requests triggered by the official download workflow.
3. If there is a stable underlying API or response payload, expose it through a dedicated command such as:
   • opencli 1688 assets <url-or-offer-id>
   • or opencli 1688 download <url-or-offer-id>

This might be a bit more robust than targeting the popup UI directly, and it seems more aligned with OpenCLI's command-oriented model.

Just a suggestion for narrowing the technical direction.

[zhangxiao918]

Thank you very much for your suggestion. Regarding the 1688 browser extension, this is an official plugin developed by 1688 itself, which interfaces directly with their official API. This means that when the plugin is active, it is able to retrieve all multimedia assets—specifically images and videos—associated with the current product, as these resources are accessed directly through official tools.

[BruceLoveDecimal]

我这边更新了一版，思路跟@Astro-Han略同，先不去优先自动化 1688 插件里的 iframe / popup UI，而是先直接批量导出商品页里的素材。

目前这版实现的方向是：

1. 先从商品页自身的页面状态和 DOM 中提取素材
2. 把结果整理成结构化的 assets
3. 再基于这些素材做 download

好处是实现成本更低、路径更稳定，也更符合 OpenCLI 现有 command-oriented 的模型。目前已经可以先完成一批常见商品的主图 / 视频导出。

至于 iframe、扩展上下文、shadow DOM的问题，可以继续讨论哈

[zhangxiao918]

感谢您的思路，主要还是因为官方插件里的素材都按照规则整理好了。 不需要手动再做任何的调整，而且一些无用的内容不会体现在官方插件的下载内容中。

其实这个问题不应该只被视为"1688插件问题"，而应该作为浏览器自动化的基础技术限制来对待——即Shadow DOM /扩展上下文的遍历问题。

[holymarsbright]

为什么我通过opencli调用搜索1688里的供应商时，返回的供应商只有几个，再多就返回不了