[BUG] documentpreview 打包的 pdfjs-dist 6.3.289 缺失 getOrInsertComputed polyfill，.pdf/.docx/.pptx 预览全量崩溃

[niljie]

[BUG] documentpreview 打包的 pdfjs-dist 6.3.289 缺失 getOrInsertComputed polyfill，.pdf/.docx/.pptx 预览全量崩溃

项	值
组件	@deepseek-ai/dsh-client-ui-sidebar-documentpreview
受影响版本	0.2.1-rc.4 / 0.2.1-rc.5 / 0.2.2-alpha.2 全部存在
环境	DSH 0.2.1-rc.4，桌面端 dsh-worker 0.0.80，macOS arm64（系统 WKWebView）
严重级别	高（基础预览功能，三个办公格式全挂）
是否已有修复版本	否（rc.5 与 0.2.2-alpha.2 的产物字节与 rc.4 完全一致）

溯源（避免重复提单）

• [Bug] Kylin V10 / Chromium 128: three client-side failures (dsh-resource protocol, PDF worker features, session-log download) #10605（Kylin V10 / Chromium 128 三连问题）中一句带过本问题：「PPTX 预览失败是另一个问题（捆绑 pdf.js 依赖 Map.prototype.getOrInsertComputed）」
• 【已修复并验证】远程用 Web 时文件预览失败（鸿蒙 ArkWeb）：已定位根因并真机验证补丁 #11242（鸿蒙 ArkWeb 预览失败，已修复并验证）引用过上述判断

→ 根因此前已被识别，但缺少专门条目，也缺少「三个已发布版本全部存在 + 可直接应用的补丁」这两项证据。

现象

在侧边栏打开 .pdf，或打开 .docx / .pptx（走 Office→PDF 转换）时，面板显示：

无法显示 PDF：this.#methodPromises.getOrInsertComputed is not a function.
(In 'this.#methodPromises.getOrInsertComputed(name, () =>
this.messageHandler.sendWithPromise(name, data))', 'this.#methodPromises.getOrInsertComputed' is undefined)

根因

• lib/client.pdf.js 打包了 pdfjs-dist 6.3.289；
• 该版本依赖 TC39 提案 API Map.prototype.getOrInsertComputed；
• 打包产物中该 API 40 处调用、0 处定义，即 pdf.js 的 polyfill 在构建阶段丢失；
• Map.prototype.getOrInsertComputed 目前 Node 24.20.0 / WKWebView / Chrome 均未提供，故该故障与运行环境无关，属于必现。

证据

三个官方已发布版本的 lib/client.pdf.js 完全相同：

版本	字节数	getOrInsertComputed 调用/定义	pdfjs
0.2.1-rc.4	7,108,803	40 / 0	6.3.289
0.2.1-rc.5	7,108,803	40 / 0	6.3.289
0.2.2-alpha.2	7,108,803	40 / 0	6.3.289

md5 均为 da97b3701763f6ba711e0bd60c7397ea（已排除内部打包改动，与 npm tarball 逐字节一致）。

对照：.xlsx 预览正常，因为它走 client.excel.js 的原生表格渲染，不经过 PDF 链路。故障面精确为 .pdf / .docx / .pptx。

修复建议（任一）

1. 改用 pdfjs-dist/legacy/build/pdf.mjs（legacy 构建自带 polyfill）；
2. 构建时显式注入 polyfill：

   Map.prototype.getOrInsertComputed ??= function (key, compute) {
     if (!this.has(key)) this.set(key, compute(key));
     return this.get(key);
   };

3. 升级到适配当前引擎的 pdfjs-dist 版本。

临时绕过（已在本机验证可行）

在 lib/client.pdf.js 顶部注入上述 polyfill 后，.pdf/.docx/.pptx 预览恢复正常（完整 diff 见随附 hotfix-pdfjs-polyfill.patch）。

验收建议

1. 侧边栏能正常预览 .pdf / .docx / .pptx；
2. CI 增加一条「渲染 1 页 PDF」的冒烟用例，防止同类「打包丢 polyfill」回归。

附带补丁（对官方 0.2.1-rc.4 tarball 可直接应用）

--- /tmp/pv/0.2.1-rc.4/package/lib/client.pdf.js	1985-10-26 16:15:00
+++ /Users/admin/Library/Application Support/com.dshworker.desktop/runtimes/0.0.80-24.20.0-mac-arm64/app/node_modules/@deepseek-ai/dsh-client-ui-sidebar-documentpreview/lib/client.pdf.js	2026-11-03 19:59:30
@@ -1,3 +1,14 @@
+/* DSH local hotfix: pdfjs-dist 6.x expects Map.prototype.getOrInsertComputed,
+   which no current engine (WKWebView / Chrome / Node 24) provides, and the bundled
+   build ships no polyfill. Injected here so PDF/DOCX/PPTX preview can render. */
+(() => {
+  const def = (name, fn) => {
+    if (typeof Map.prototype[name] === "function") return;
+    Object.defineProperty(Map.prototype, name, { value: fn, writable: true, configurable: true });
+  };
+  def("getOrInsertComputed", function (key, compute) { if (!this.has(key)) this.set(key, compute(key)); return this.get(key); });
+  def("getOrInsert", function (key, value) { if (!this.has(key)) this.set(key, value); return this.get(key); });
+})();
 //! Bundled PDF.js license notices
 // LICENSE
 // 

[zy2949804763]

Thanks for the detailed report. I implemented the legacy-build option suggested here and prepared a source patch with regression coverage:

• PDF compatibility fix: 40182201
• Separate Windows clipboard test correction: f0a456aa

Both commits are based on upstream 8bd073392eef6f54e921a093b95076248eb08cbb.

The first commit switches the engine, text viewer and embedded worker to matching PDF.js legacy builds, updating the raw-worker declaration and bundler resolver together. The existing real-library smoke used legacy builds while production used modern builds; it now consumes the production worker source. A new built-chunk regression runs in an isolated realm without native Map upsert or typed-array hex methods. That regression fails on the published 0.2.2-alpha.2 chunk and passes after rebuilding the patch.

Dependency-level comparison with pdfjs-dist 6.3.289 on Node 24.18.0:

Main thread	Worker	Result
Modern	Modern	hashOriginal.toHex is not a function
Modern	Legacy	getMetadata() throws getOrInsertComputed is not a function
Legacy	Legacy	Loading, metadata and text extraction pass

The mixed-build case only isolates the main-thread failure; it is not the proposed configuration. The worker-side failure is why a Map-only polyfill may be insufficient.

Validation on Windows: full build and aggregate type checks passed; 609 document-preview package tests passed; all 7 full-application document-preview replay scenarios passed with matching Playwright Chromium 149.0.7827.55, including real Word/PPT conversion and PDF previews. The second commit accounts for Windows-native CRLF in clipboard expectations while retaining exact text comparisons. No snapshots were refreshed.

Limits: macOS/WKWebView has not been tested. The broader Web suite stopped with 20 passing tests and one failure in a chat-scroll fixture that invokes POSIX Bash, which the shipped Windows profile disables. I am not claiming the entire Web suite is green.

Sharing the commits here in accordance with the current external-PR policy, in case they are useful for review or cherry-picking.

[PedroCostinha]

Hi! I would avoid treating a manual modification of the generated or minified PDF.js bundle as the permanent fix.

A more maintainable solution would be to check which PDF.js distribution is intended for the application's supported JavaScript runtimes.

Depending on the bundling configuration, using the supported legacy build or loading a compatible polyfill before the library initializes may be appropriate.

I would also add a smoke test that opens a minimal PDF in each supported desktop runtime, rather than relying only on browser-based unit tests.

Since PDF parsing is shared by several document preview workflows, regression coverage should include PDF, DOCX, and PPTX.

The key is to fix compatibility at the dependency integration layer so it survives clean builds and future upgrades.

[niljie]

@zy2949804763 thanks — here is the macOS arm64 verification for 4018220 (the environment this report covers, and the one your comment notes is untested).

Verified 4018220 on macOS arm64 (the environment in the report, which the first comment notes is untested).

• Built artifacts from 4018220 (base 8bd0733) with --scope artifacts --profile local: 8/8 gates passed.
• New built-chunk regression passes on the rebuilt chunk, and fails when I swap in the published 0.2.2-alpha.2 chunk — so the test genuinely catches this regression.
• pdf-smoke.client.spec.ts (real library, text extraction through the production worker) passes.
• Node 24 (same missing APIs as WKWebView): modern/modern → hashOriginal.toHex is not a function; modern engine + legacy worker → same family; legacy/legacy → loads, 2 pages, text extracted. Matches the matrix above and confirms a Map-only polyfill is insufficient.
• Environment note: Chrome 156 does provide Map.prototype.getOrInsertComputed and Uint8Array.prototype.toHex, which explains why this only surfaces on WKWebView / older engines and is invisible in a Chrome-based smoke run.

Caveat: this is Node + vitest, not the desktop shell's WKWebView. Closing that loop still needs a desktop build; I have no further blockers on the fix itself.

Not urgent at all — just leaving a pointer for whoever owns this path: /cc @imccyu @Stevring @yudshj (recent authors of packages/client/ui-sidebar-documentpreview). Thanks for the preview work otherwise; the file tree and the Excel viewer have been solid for us. If someone can glance at the legacy-build commit and say whether it fits your direction, great — and if you need anything else from the macOS/WKWebView side (repro, logs, a desktop build run), I'm glad to help.