Document Viewer (document-open) — Design Gap
The gap
No document-viewer or PDF frame exists in any of the four known Figma files — the
Design-Source Gap Inventory's live search
surfaced only a generic i-action icon component. The inventory also records why
this gap is doubly unscoped: the migration guide's own recommendation for document viewing was
Option A — keep it fully native, zero days, do not migrate during the straggler
period. DocumentOpenPage.razor exists anyway, so the app now carries a
Blazor viewer that was neither designed nor scoped to be built.
Which native viewer? An observation to record. The coverage map lists two
generic native viewers, PDFJSPage and WebViewPage (renamed
AuthenticatedWebViewPage, AB#2591 — same page class, chrome fixed, path
unchanged). Live navigation on 2026-08-12 (build 34737cb4) from the Documents
list to the United Pilot Contract opened WebViewPage — the AutoLogin WebView
rendering the cached PDF — not PDFJSPage. Any parity work that
assumes the pdf.js viewer is the native baseline is comparing against the wrong screen, at
least for this path.
The Blazor page is deliberate about what it does: pdf/htm/html documents are fetched through
the authenticated download (the same cache-then-download read as the legacy path) and rendered
inline in an iframe via a blob URL, inside AlpaScreen chrome; “webpage”
DocTypes and unknown file types are handed to the legacy native pipeline, because the STS
auto-login machinery cannot drive an iframe. A failed inline fetch falls back to an error
state with an OPEN NATIVELY button. All of that is engineering policy written in a page
comment — none of it has a design.
What ships today
| Aspect | Native (XAML) | Blazor (this build) |
|---|---|---|
| Surface | AuthenticatedWebViewPage (observed live as WebViewPage pre-AB#2591) — AutoLogin WebView rendering the cached PDF (PDFJSPage was not on this path) |
/document-open?fileId=… — blob-URL iframe inside AlpaScreen chrome with back chevron and document title |
| Resolution | Legacy tap path; never opens documents by public URL (member content is session-gated) | By fileId via IScaffoldDocumentsQueries; same authenticated cache-then-download read |
| Non-inline types | — | “webpage” and unknown DocTypes handed to the legacy SharedActionsService pipeline (native AutoLogin WebView / file viewer), page steps back on return |
| States | WebView chrome only | Spinner + “Opening document…”, and an error state with an OPEN NATIVELY fallback button |
Side by side
Captured 2026-08-12 on an iPhone 17 Pro Max simulator (iOS 26.4), build commit
34737cb4, against live data — the same document on both sides: the United Pilot
Contract UPA23.3, fileId 60106.
Native (XAML, shipped today)
AuthenticatedWebViewPage — not PDFJSPage (screenshot predates the AB#2591
rename; page class was WebViewPage when captured)
The cached PDF rendered by the AutoLogin WebView. Banner chrome comes from the WebView
page, not from a document-viewer design; there is none.
Blazor (this build, for review)
DocumentOpenPage — inline blob iframe
/document-open?fileId=60106. The same contract fetched through the
authenticated download and rendered in the page's iframe via a blob URL —
AlpaScreen title bar, back chevron, document title. The member never
leaves the Blazor experience for inline-capable types.
Verification
Walked live on an iPhone 17 Pro Max simulator, build 34737cb4:
The Blazor behavior claims (blob-URL rendering, the legacy handoff for webpage DocTypes, the
OPEN NATIVELY fallback) are from DocumentOpenPage.razor's markup and header
comment, confirmed in source. The native viewer identification is the live observation above —
the page class reached was WebViewPage, since renamed AuthenticatedWebViewPage
(AB#2591) — the "webpage"/unknown-DocType handoff still lands on the same page under its new name.
Open questions
| # | For | Question |
|---|---|---|
| 1 | Product | Does document viewing stay in Blazor at all? The migration guide's standing recommendation was keep it fully native; DocumentOpenPage deviates from that plan. Ratify the deviation or retire the page — the answer decides whether a design is even needed. |
| 2 | Design | If the Blazor viewer stays, is AlpaScreen chrome (title bar + back chevron) the designed treatment for a full-bleed document, or does a reading surface warrant its own chrome — collapsing bars, a share/download action, page indicators? |
| 3 | Design | The loading spinner and the error state with its OPEN NATIVELY button ship undesigned. The error state is the one members see when an inline fetch fails — what should it look like, and is “OPEN NATIVELY” the right copy for a member who has no concept of native vs Blazor? |
| 4 | Engineering | Which native viewer is canonical? This path reached WebViewPage (renamed AuthenticatedWebViewPage, AB#2591), not PDFJSPage. Establish when (if ever) PDFJSPage is used, so parity comparisons and any retirement decision target the viewer members actually hit. |
| 5 | Design | Does the D65 content-only pinch-zoom ruling apply inside the blob-iframe viewer? A PDF is the strongest zoom case in the app; the decision doc predates this viewer. |
References
ALPAMobile.Presentation/Components/Pages/DocumentOpenPage.razor— the Blazor viewer, its DocType policy and fallback statesALPAMobile/Pages/AuthenticatedWebViewPage.xaml— the native viewer actually reached on this path (renamed fromWebViewPage.xaml, AB#2591 —WebViewPageitself is deleted)ALPAMobile/Pages/PDFJSPage.xaml— the pdf.js viewer, not reached here- Design-Source Gap Inventory — the no-frame finding and the migration-guide deviation
- D65 — Content-Only Pinch Zoom
- XAML → Blazor Coverage Map — both native viewers classified as “not screens”