PDF Signing Mixed Dimension Clipping

• use contract-signing-triage

First Identifiers To Collect

• workspace_id
• contract_id
• contract_version_id
• cluster
• affected signer name or recipient
• whether preview looks correct while signing looks wrong
• whether the PDF has mixed page widths or unusually wide first pages
• whether support can reposition fields in setup as a temporary workaround
• Jira / incident links if already created

For the Brick&Bolt incident, the key identifiers were:

• workspace 653475
• contract 1852736
• contract version admin id 6351472
• Rootly incident 3046
• incident channel #incident-20260325-medium-brick-bolt-content-not-visible-during-signing-phase

Investigation Workflow

Step 1: Confirm The Symptom Family

Look for language like:

• left side not visible during signing
• can scroll down and right, but not left
• fields on the left are inaccessible
• preview is fine but signing is broken
• mixed-size PDF or pages of varying dimensions

If this is the symptom family, treat it as a client-side signing-view rendering problem first, not a backend signing pipeline failure.

Step 2: Rule Out The Wrong Failure Mode Quickly

Do not start with GCP logs or Groundcover unless the report also includes API failures, task failures, or UI error banners.

In the March 25, 2026 incident, the strongest signal was the absence of backend failures:

• no API failure was described
• no task failure was needed to explain the symptom
• the failure point was the PDF viewer container and page rendering behavior

If preview is correct and only signing is wrong, prioritize frontend viewer behavior.

Step 3: Check For Mixed-Dimension PDF Geometry

This issue most often correlates with:

• pages of different widths
• oversized first pages
• blueprint-style or drawing-heavy PDFs
• documents where normalization or print-to-PDF changes behavior

The shipped frontend work treated this as a mixed-dimension rendering problem, not just a one-off field-position bug.

Step 4: Check Whether This Is Pre-Fix Or A Regression

Important dates:

• incident opened on March 25, 2026
• frontend fix merged on March 27, 2026 in angular-frontend PR #14899
• support confirmed the fix had reached production on March 30, 2026

Use these references:

• customer-impact ticket: SPD-42773
• shipped frontend work: SPD-42617
• commit: 0878f4b5dd86a517135136bbcbf01dcfab8d01ad

If a production report happens after March 30, 2026 and shows the same behavior, assume one of these until disproved:

• regression against the mixed-dimension fix
• incomplete rollout
• stale browser state or cached assets
• a new geometry variant not covered by the original fix

Step 5: Apply The Safe Mitigation

Use the least-destructive mitigation first:

• move signature fields toward the right side where possible
• ask the signer to use View Details from the three-dot menu for hidden content

If that is insufficient, consider PDF normalization only with explicit caveats.

The incident thread documented these risks for blueprint or drawing-heavy PDFs after print-to-PDF or similar normalization:

• scale invalidation
• loss of detail in thin lines or labels
• aspect-ratio distortion
• flattening of layers and metadata

If the customer relies on blueprint fidelity, prefer waiting for the permanent fix over forcing a normalized PDF unless they accept those tradeoffs.

Customer-Shareable RCA

Use this wording as the starting point and adapt only if the facts differ:

We identified a rendering issue in the signing interface for PDFs with non-uniform page dimensions. In affected documents, parts of the page on the left side could become inaccessible during signing even though the document content itself was intact. We implemented a frontend fix to improve how mixed-dimension PDFs are rendered in the signing experience and deployed it to production on March 30, 2026.

If the customer asks about temporary workarounds, add:

As an interim workaround before the fix reached production, signature fields could be moved toward the right side and hidden content could be viewed through the document details menu. For drawings or blueprint-style PDFs, we avoided recommending print-based normalization unless the customer accepted possible scaling or fidelity tradeoffs.

Relevant Code Paths

Prioritize these files in angular-frontend:

• libs/pdf-sign/collection-ui/src/lib/components/pdfsign-render/pdfsign-render.component.html
• libs/pdf-sign/collection-ui/src/lib/components/pdfsign-render/pdfsign-render.component.ts
• libs/pdf-sign/collection-ui/src/lib/components/pdfsign-render/pdfsign-render.component.scss
• libs/pdf-sign/collection-ui/src/lib/services/sign-field-navigator.service.ts
• libs/pdf-sign/collection-ui/src/lib/services/pdf-sign-collection.store.service.ts
• libs/pdf-sign/core/src/lib/utils/pdf-sign-utils.ts

These files cover:

• mixed-dimension detection
• viewer zoom and fit-to-page behavior
• cached page viewport dimensions
• auto-navigation scroll math
• mobile versus desktop scale and font handling
• the shared scroll container selector .ng2-pdf-viewer-container

What The Shipped Fix Changed

PR #14899 described the production fix as:

• forcing the mixed-dimension signing renderer into a stable zoomed mode
• updating auto-navigation to use effective page height per page
• handling mobile and desktop scale differently so content stays legible
• fixing dynamic resize, font scaling, and field span behavior on mixed PDFs

That means a fresh incident should not be reduced to "just a CSS centering bug." Check all of these dimensions:

• full-page rendering
• left-side reachability
• next-field auto-navigation
• mobile readability
• desktop scaling for oversized first pages

Regression Checklist

When verifying a suspected recurrence, test at minimum:

• different-dimension PDFs
• different zoom levels
• different screen sizes

Acceptance criteria from the original pod-sign request:

• the problematic mixed-dimension PDFs render completely in the signing flow
• no new regressions appear in sign flows while zooming or resizing
• auto-navigation still lands on the correct field

Related Incident Notes

• The original Slack investigation explicitly treated this as different from prior PDF visibility incidents that had similar symptoms but different causes.
• The support workaround was approved before the permanent fix landed.
• The incident was mitigated after support verified the production fix on March 30, 2026.

Escalation Triggers

Escalate to the signing/frontend owners when:

• the same left-clipping behavior appears on current production after March 30, 2026
• auto-navigation is still wrong on mixed-size PDFs after the fix
• the bug reproduces only on certain screen sizes or only on mobile
• the document cannot be safely normalized because blueprint fidelity matters
• the report starts resembling a new geometry or scaling class not covered by PR #14899