[WC-3431]: Doc Viewer Checkbox Fix

[samuelreichert]

Pull request type

Bug fix (non-breaking change which fixes an issue)

---

Description

Fix PDF standard font rendering in Document Viewer

Problem: PDFs containing glyphs from ZapfDingbats (e.g. checkmarks generated by .NET PDF libraries) rendered as blank rectangles in Document Viewer. The browser's native PDF viewer displayed them correctly.

Root cause: standardFontDataUrl and cMapUrl were relative paths. The PDF.js worker is loaded from //unpkg.com (cross-origin), so fetch() in the worker context has no document origin to resolve relative URLs against — throwing TypeError: Failed to parse URL.

Fix: Prepend window.location.origin to both URLs, making them absolute and resolvable from any worker origin.

Tested with:

• Customer W9 PDF (C corporation checkbox now shows as checked ✓)
• Plain PDF with no form fields (no regression ✓)

[r0b1n]

I would think fonts will live under that subpath as well. This needs checking.

[github-actions]

AI Code Review

⚠️ Approved with suggestions — low-severity items only, safe to merge

---

What was reviewed

File	Change
packages/pluggableWidgets/document-viewer-web/src/components/PDFViewer.tsx	Absolute origin prepended to cMapUrl and standardFontDataUrl; trailing slash added to standard_fonts/
packages/pluggableWidgets/document-viewer-web/typings/global.d.ts	New file — declares Window.mx?.appUrl
packages/pluggableWidgets/document-viewer-web/typings/modules.d.ts	New file — declares *.css module
packages/pluggableWidgets/document-viewer-web/CHANGELOG.md	[Unreleased] ### Fixed entry added
openspec/changes/archive/2026-06-12-document-viewer-render-forms-fix/	OpenSpec archived change artifacts

Skipped (out of scope): dist/, pnpm-lock.yaml

---

Findings

⚠️ Low — Module-scope window access throws in non-browser environments

File: packages/pluggableWidgets/document-viewer-web/src/components/PDFViewer.tsx line 11
Note: window.mx?.appUrl is evaluated at module-load time (not inside a component or effect). In Jest tests — and in any future SSR/Node context — window may be undefined. Currently, the test suite doesn't appear to exercise this module directly, but if a test imports PDFViewer.tsx it will throw. The design doc acknowledges the SSR risk but doesn't guard against it.

A defensive guard prevents silent test failures and future breakage:

const origin: string = (
    typeof window !== "undefined"
        ? (window.mx?.appUrl ?? window.location.origin)
        : ""
).replace(/\/$/, "");

⚠️ Low — window.mx type is narrower than the actual Mendix global

File: packages/pluggableWidgets/document-viewer-web/typings/global.d.ts line 3
Note: The mx type declared here ({ appUrl?: string }) doesn't match the broader window.mx shape used elsewhere in the repo (e.g. window.mx.remoteUrl in packages/shared/charts). If another file in this package ever needs a different mx property, the two declarations will conflict. Consider either augmenting a shared @mendix/widget-plugin-platform-utils type (if one exists) or documenting that this is intentionally minimal.

---

Positives

• Root cause correctly identified: the worker's cross-origin fetch context can't resolve relative URLs, and the fix addresses that directly rather than working around it (e.g. useWorkerFetch: false).
• window.mx.appUrl fallback correctly handles reverse-proxy and sub-path deployments that window.location.origin alone wouldn't cover — this is the right choice for Mendix.
• Trailing slash added to standard_fonts/ — fixes a subtle directory URL issue that the original code silently had.
• CHANGELOG entry is properly placed under [Unreleased] with the correct ### Fixed heading.
• typings/global.d.ts uses export {} to ensure it's treated as a module augmentation, not a script — correct pattern.
• tsconfig.json already includes ./typings, so the new declaration files are picked up without any config change.