PDF.js worker loaded without cache-buster

Since the 5.0.x update, embeds on CDN-fronted sites (we’re on Cloudflare) get stuck on “Loading…” forever, with no console error. I traced the root cause:

pdf.min.js is enqueued with a ?ver= query string, so a plugin update gives it a fresh cache key and the CDN pulls the new build. But pdf.worker.min.js is loaded via GlobalWorkerOptions.workerSrc (and worker_src in the localized config) with no ?ver= cache-buster, so its URL stays identical across versions. Combined with cache-control: max-age=31536000, the CDN keeps serving the worker it cached under the previous plugin version.

So after an update the browser runs the new pdf.min.js (apiVersion 2.16.105) against a stale cached pdf.worker.min.js from the old version. The PDF.js API/worker version handshake never completes, getDocument() hangs indefinitely, and the viewer sits on “Loading…” forever.

Confirmed on our site: the origin pdf.worker.min.js was 1,111,587 bytes (current build), but the CDN edge was serving a ~766 KB copy cached months earlier (cf-cache-status: HIT). Appending any cache-bust query to the worker URL made getDocument() succeed immediately and the PDF
rendered. Purging the CDN cache also fixes it.

Suggested fix: version the worker (and cmap) URLs the same way pdf.min.js is versioned, e.g. pdf.worker.min.js?ver=PLUGIN_VERSION in worker_src / workerSrc, so each release invalidates the cached worker automatically. Otherwise every CDN/cache user silently breaks on each update until
they manually purge.

This looks like it’s behind the recent wave of “PDFs not loading / stuck on Loading…” reports.

• This topic was modified 2 days, 15 hours ago by MACscr.