CP-13553: Refactor Docuseal PDF page loading and previews#65
Merged
Conversation
DocuSeal previously rendered only the first 15 pages of a PDF synchronously at upload time and then lazily generated pages 16+ on demand when the editor or submitter view actually requested them. The on-demand path lived in PreviewDocumentPageController and had a long history of bugs — tempfile races, intermittent failures, filename-extension mismatches between writer and reader — especially when DocuSeal is iframed into ATS. This removes the 15-page cap (MAX_NUMBER_OF_PAGES_PROCESSED) and the lazy on-demand controller entirely. Every page now renders during the upload request. Larger PDFs take a few extra seconds at upload, but every page is guaranteed to exist by the time the editor opens, so the whole on-demand failure surface disappears. Also deletes two unused job classes (GeneratePreviewImagesJob and GenerateAttachmentPreviewJob) that had no callers anywhere in the app, plus the now-obsolete spec for the deleted generate_pdf_preview_from_file helper. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The template builder used to fall back to a /preview/<token>/<n>.jpg URL for any page that wasn't already in document.preview_images, and applied loading="lazy" to each page <img>. Both pieces only existed to paper over the missing pages 16+ from the old upload cap. Since the backend now renders every page at upload time, the fallback URL is never needed. sortedPreviewImages becomes a simple map-filter over the already-rendered images, and basePreviewUrl is unused so it's removed too. Also drops loading="lazy" from page.vue and preview.vue. Native lazy loading does not trigger reliably inside the ATS iframe — images would sometimes refuse to fetch until the user scroll-spammed past them. With every page now reachable as a direct S3 URL on initial render, the browser can just load them up front. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Mirrors the previous commit but for the Rails-rendered submit-form and completed-submission views. Drops the page_blob_struct / lazyload_metadata machinery that built fallback URLs pointing at the now-deleted /preview controller, and removes loading="lazy" from the page-list <img> tags for the same iframe-reliability reasons as the editor change. Single-image attachment thumbnails (signatures, user-uploaded files) keep their loading="lazy" attributes — those aren't part of a scrollable page list and don't hit the same iframe-rendering quirk. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The old Submissions.preload_with_pages had two pieces that no longer make sense after removing the lazy preview controller: 1. It preloaded `:blob` on the document attachments themselves. The views only ever accessed `document.blob` indirectly through the now-deleted lazy controller's `attachment.download` call. Bullet was correctly flagging the preload as unused. 2. It skipped preloading preview_images for documents with 200+ pages and relied on the views' lazy-URL fallback to fill the gap. With the fallback gone, large documents were rendering zero pages in the Rails form preview because preview_images.loaded? returned false and the index ended up empty. This always preloads `preview_images_attachments: :blob` regardless of page count, and drops both unused `:blob` preloads on the document attachments. Also removes the now-unused PRELOAD_ALL_PAGES_AMOUNT constants in lib/submissions.rb and lib/submitters.rb. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Does what it says on the box.
bernardodsanderson
requested changes
May 12, 2026
Collaborator
bernardodsanderson
left a comment
bernardodsanderson
left a comment
There was a problem hiding this comment.
This looks great! Just a few asks here. Another thing I was wondering is if we need/want to backfill rake task for all the forms created before this PR is live?
Co-authored-by: Bernardo Anderson <bern.anderson@proton.me>
Comment on lines
98
to
114
| @@ -113,26 +113,13 @@ export default { | |||
| } | |||
| }, | |||
Collaborator
There was a problem hiding this comment.
Suggested change
| }, |
Member
Author
There was a problem hiding this comment.
Is this the change you wanna make? 🤔
Collaborator
There was a problem hiding this comment.
Basically, delete the baseUrl
baseUrl: {
type: String,
required: false,
default: ''
},
Collaborator
There was a problem hiding this comment.
I tried selecting the whole thing to delete it 😞
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Overview
This includes a bunch of tweaks to the underlying infrastructure in the way Docuseal serves up Documents in the Editor and Preview pages.
Gone is the lazy loading mechanic and 15 page cap to the preview. The lazy loading mechanic was BUGGY AF due to our iFrame situation and the 15 page cap was just kind of nonsensical to begin with. Please look at each commit as each one of them has context that makes it clear why and what the changes are.
Video overview: https://www.loom.com/share/26defd1e361f41699614516a220bb8ac