[Bug] Kylin V10 / Chromium 128: three client-side failures (dsh-resource protocol, PDF worker features, session-log download)

[dx41]

Environment

• dsh 0.2.1-rc.2, dsh web profile, Linux arm64 (Kylin V10 SP1)
• Browser: the distro's bundled Chromium 128.0.6613.119 Built on Kylin (this build reports a x86_64 UA on an aarch64 host, i.e. it is a custom/older branch)
• Three unrelated-looking failures all trace back to this browser being older than what the client code assumes. All three are reproducible on a stock Chrome 130+ only in the sense that they don't happen there; the code paths are still non-portable.

I patched all three locally against the built artifacts (node_modules/**/lib/client*.js) to keep working, but the proper fixes belong in source. Diffs below are conceptual — I can send PRs if the project wants them.

---

1. dsh-client-resources: protocolOf() returns undefined for valid dsh-resource:// addresses

packages/client/resources derives the protocol key with new URL(address).hostname. For non-special schemes the WHATWG URL parser is not required to populate hostname, and this Chromium build returns "" for dsh-resource://file/x. The address is then classified as "not a resource", every record stays in status none, and the right sidebar shows "文件资源服务不可用" — with no console error, a clean host log, and no recovery on refresh. Meanwhile every workspaceFiles.* RPC works fine, which makes it very hard to localize.

Proposed fix — parse the authority from the string and keep URL only as a fallback:

function protocolOf(address) {
  const match = /^dsh-resource:\/\/([^/?#]*)/i.exec(address)
  if (match !== null) {
    const authority = match[1]
    const host = authority.slice(authority.lastIndexOf('@') + 1)
    return host === '' ? undefined : host.toLowerCase()
  }
  let parsed
  try { parsed = new URL(address) } catch { return }
  if (parsed.protocol !== 'dsh-resource:') return undefined
  return parsed.hostname === '' ? undefined : parsed.hostname.toLowerCase()
}

This is behaviour-identical to the current code on conforming parsers (I checked DSH-RESOURCE://File/x, dsh-resource:///x, dsh-resource://user@file/x, /home/a.md, and bare paths).

---

2. dsh-client-ui-sidebar-documentpreview: PDF worker throws n.toHex is not a function

Opening any .doc/.docx yields "无法显示 PDF：n.toHex is not a function". The conversion succeeds — the PDF bytes arrive — the failure is inside pdf.js 6.3.289.

pdf.js depends on several recent JS built-ins: Uint8Array.prototype.toHex / toBase64, Uint8Array.fromHex / fromBase64, Math.sumPrecise, Map.prototype.getOrInsert(Computed), RegExp.escape, Error.isError, and Promise.try. Upstream pdf.js installs these itself in src/shared/util.js, but the bundler treats those statements as side-effect-free and drops them, so the shipped chunk contains the call sites only.

Two details that matter for a fix:

• The failing call is in the worker, not the main thread. PDFDocument.fingerprints does calculateMD5(...).toHex(), and the worker source is an inline 1.27 MB string in the chunk that is turned into a blob at runtime:

  url = URL.createObjectURL(new Blob([_dsh_pdf_worker_default, '\nself.postMessage(...)'], { type: 'text/javascript' }))
  worker = new Worker(url, { type: 'module', name: 'dsh-pdf' })

  Patching the main thread alone is useless; wrapping Worker is fragile. What works is prefixing the polyfill into that string (var _dsh_pdf_worker_default = "<polyfill>(self);" + "<original>").
• Promise.try is used unguarded by the worker message pump, so it must be in the set even though it happens to exist in Chrome 128.

Suggestion: ship the polyfills as a tiny module that is concatenated in front of the worker string and also evaluated at chunk top-level, rather than relying on pdf.js's own side effects surviving tree-shaking.

---

3. dsh-session-log-export: "Download session log" silently downloads nothing

session-log-export/lib/client.js ─ downloadUrl():

const anchor = document.createElement('a')
anchor.href = url
anchor.download = filename
anchor.click()          // anchor is never appended to the document

The host side is fine (HEAD /api/session.export?... → 200 + content-disposition: attachment; filename="dsh-session-<id>.zip", and a manual GET returns the ZIP). But the <a> is detached, and several Chromium forks ignore click() on a detached anchor. Result: no download, no error, no browser download-history entry — the FE reports success because it only checked the HEAD.

const anchor = document.createElement('a')
anchor.href = url
anchor.download = filename
anchor.rel = 'noopener'
anchor.style.display = 'none'
;(document.body ?? document.documentElement).append(anchor)
try { anchor.click() } finally { anchor.remove() }

This one is a one-liner and is correct in every browser, not just this one.

[PerryLink]

The lookup really does depend on the browser's URL parser.

packages/client/resources/src/client/resources.ts:56-68 is exactly that shape: parse with new URL(address), reject a different scheme, then parsed.hostname === '' ? undefined : parsed.hostname.toLowerCase() (:67). The comment above it (:66) even says "A non-special scheme's host is opaque to the URL parser and keeps its case" — so this path was written knowing the host slot is implementation-flavoured.

Two facts that matter for your report:

• The file is byte-identical at 687f282e (rc.2), b830ec95 (rc.5) and master ce7073d5 — same blob 614387cfd76c35deb481cfa92a8ebb147e3d5f8e. So nothing has changed between the version you patched and today, and no fix is hiding in a newer build.
• The empty-hostname behaviour you hit is a deviation: for a non-special scheme written with //, the WHATWG parser is supposed to populate the host. A build that returns "" makes the guard trip before any other check, and every dsh-resource:// address classifies as "not ours".

Portable fix, and it removes the browser from the equation: check the scheme prefix yourself, then take the authority as address.slice(RESOURCE_SCHEME.length + 3) up to the first /, and lowercase it. A handful of lines, no URL involved.

The other two failures in your report (PDF worker features, session-log download) I can't judge — they depend on that build's feature set, and I would only be guessing. If you file them, keep them as separate items with their own reproductions; bundled with the protocol one they will be read as one issue.

Read-only source inspection at master ce7073d5; I did not run that Chromium build.