[PR #2518] fix: preserve prefilled field value on click and prevent unsign on re-edit #2362

Open
opened 2026-02-26 20:33:33 +03:00 by kerem · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/documenso/documenso/pull/2518
Author: @Jahangirbabar2000
Created: 2/19/2026
Status: 🔄 Open

Base: mainHead: fix/prefill-text-erased-on-click-2512


📝 Commits (2)

  • f0cf5cd fix: preserve prefilled field value on click in signing view (#2512)
  • bfc4a12 fix: prevent field unsign on click, open edit dialog with current value

📊 Changes

6 files changed (+61 additions, -22 deletions)

View changed files

📝 apps/remix/app/components/dialogs/sign-field-number-dialog.tsx (+3 -2)
📝 apps/remix/app/components/dialogs/sign-field-text-dialog.tsx (+3 -2)
📝 apps/remix/app/components/general/document-signing/document-signing-text-field.tsx (+4 -2)
📝 apps/remix/app/utils/field-signing/number-field.ts (+14 -7)
📝 apps/remix/app/utils/field-signing/text-field.ts (+16 -7)
📝 packages/lib/universal/field-renderer/render-generic-text-field.ts (+21 -2)

📄 Description

Description

When a document is created from a template via the /api/v2/envelope/use endpoint with prefillFields, the prefilled value is displayed correctly in the signing view. However, when the recipient clicks on the field to edit it, the prefilled value is erased and replaced with the field's label text. This fix ensures the prefilled value is preserved when the field enters edit mode, allowing the recipient to review and modify it as intended.

Fixes #2512

Changes Made

  • document-signing-text-field.tsx: Changed fieldDisplayName to prefer textDisplay (prefilled value) over labelDisplay, so the signing view renders the prefilled value instead of the label.
  • sign-field-text-dialog.tsx: Added initialValue prop and used it as the form's default value, so the edit dialog opens with the prefilled text instead of an empty string.
  • sign-field-number-dialog.tsx: Same fix for number fields — added initialValue prop and used it as the form's default value.
  • text-field.ts: When opening the text dialog, reads the prefilled value from field.customText or fieldMeta.text and passes it as initialValue to the dialog.
  • number-field.ts: Same fix for number fields — reads from field.customText or fieldMeta.value and passes it as initialValue to the dialog.
  • render-generic-text-field.ts: In sign mode, when a field is not yet inserted, renders the prefilled value from fieldMeta.text (text fields) or fieldMeta.value (number fields) instead of falling back to the label. When a field is inserted, always renders the signed value (field.customText) safely as a string, preventing accidental fallback to the prefill.

Additionally, a follow-up fix was needed to prevent a regression where clicking a field after entering a value would unsign it and revert to the prefilled value:

  • text-field.ts: Removed the early return that unsigned the field on click when already inserted. Clicking a text field now always opens the edit dialog with the current signed value (field.customText) or prefilled value (fieldMeta.text) as fallback. Submitting updates the value; cancelling leaves it unchanged. Empty submit still unsigns when applicable.
  • number-field.ts: Same change — removed unsign-on-click behavior. The dialog opens with the current value for editing instead of unsigning the field.
  • render-generic-text-field.ts: When field.inserted is true, textToRender is now always set to a safe string from field.customText, so the displayed value is always the signed value and never falls back to the prefill for an inserted field.

Testing Performed

  • Created a template with a text field via the UI.
  • Used the /api/v2/envelope/use endpoint to create an envelope with a prefilled text field (label: "Test Label", value: "This should stay").
  • Opened the signing link as the recipient and confirmed the prefilled value is displayed.
  • Clicked on the field and confirmed the prefilled value is preserved and editable in the dialog.
  • Entered a new value, submitted, then clicked the field again — confirmed the dialog opens with the new value, not the original prefill.
  • Cancelled the dialog after opening — confirmed the existing value is unchanged.
  • Cleared the field value and submitted — confirmed the field is properly unsigned.
  • Verified that non-prefilled fields still correctly show the label as placeholder text.
  • Tested the same flow for number fields.
  • Tested on Chrome (latest).

Checklist

  • I have tested these changes locally and they work as expected.
  • I have added/updated tests that prove the effectiveness of these changes.
  • I have updated the documentation to reflect these changes, if applicable.
  • I have followed the project's coding style guidelines.
  • I have addressed the code review feedback from the previous submission, if applicable.

Additional Notes

This bug only affects fields prefilled via the API. Fields created and filled through the UI are unaffected since they don't use the prefill code path. The root cause was the field component unconditionally initializing its editable state from fieldMeta.label on click/focus, without checking for an existing value first.


🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/documenso/documenso/pull/2518 **Author:** [@Jahangirbabar2000](https://github.com/Jahangirbabar2000) **Created:** 2/19/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/prefill-text-erased-on-click-2512` --- ### 📝 Commits (2) - [`f0cf5cd`](https://github.com/documenso/documenso/commit/f0cf5cd4b6aec3dfcf24544afa599d80db21a1be) fix: preserve prefilled field value on click in signing view (#2512) - [`bfc4a12`](https://github.com/documenso/documenso/commit/bfc4a12df4bec8870e207199e7d9e83c93fa2cbe) fix: prevent field unsign on click, open edit dialog with current value ### 📊 Changes **6 files changed** (+61 additions, -22 deletions) <details> <summary>View changed files</summary> 📝 `apps/remix/app/components/dialogs/sign-field-number-dialog.tsx` (+3 -2) 📝 `apps/remix/app/components/dialogs/sign-field-text-dialog.tsx` (+3 -2) 📝 `apps/remix/app/components/general/document-signing/document-signing-text-field.tsx` (+4 -2) 📝 `apps/remix/app/utils/field-signing/number-field.ts` (+14 -7) 📝 `apps/remix/app/utils/field-signing/text-field.ts` (+16 -7) 📝 `packages/lib/universal/field-renderer/render-generic-text-field.ts` (+21 -2) </details> ### 📄 Description ## Description When a document is created from a template via the `/api/v2/envelope/use` endpoint with `prefillFields`, the prefilled value is displayed correctly in the signing view. However, when the recipient clicks on the field to edit it, the prefilled value is erased and replaced with the field's `label` text. This fix ensures the prefilled value is preserved when the field enters edit mode, allowing the recipient to review and modify it as intended. ## Related Issue Fixes #[2512](https://github.com/documenso/documenso/issues/2512) ## Changes Made - **`document-signing-text-field.tsx`**: Changed `fieldDisplayName` to prefer `textDisplay` (prefilled value) over `labelDisplay`, so the signing view renders the prefilled value instead of the label. - **`sign-field-text-dialog.tsx`**: Added `initialValue` prop and used it as the form's default value, so the edit dialog opens with the prefilled text instead of an empty string. - **`sign-field-number-dialog.tsx`**: Same fix for number fields — added `initialValue` prop and used it as the form's default value. - **`text-field.ts`**: When opening the text dialog, reads the prefilled value from `field.customText` or `fieldMeta.text` and passes it as `initialValue` to the dialog. - **`number-field.ts`**: Same fix for number fields — reads from `field.customText` or `fieldMeta.value` and passes it as `initialValue` to the dialog. - **`render-generic-text-field.ts`**: In sign mode, when a field is not yet inserted, renders the prefilled value from `fieldMeta.text` (text fields) or `fieldMeta.value` (number fields) instead of falling back to the label. When a field is inserted, always renders the signed value (`field.customText`) safely as a string, preventing accidental fallback to the prefill. Additionally, a follow-up fix was needed to prevent a regression where clicking a field after entering a value would unsign it and revert to the prefilled value: - **`text-field.ts`**: Removed the early return that unsigned the field on click when already inserted. Clicking a text field now always opens the edit dialog with the current signed value (`field.customText`) or prefilled value (`fieldMeta.text`) as fallback. Submitting updates the value; cancelling leaves it unchanged. Empty submit still unsigns when applicable. - **`number-field.ts`**: Same change — removed unsign-on-click behavior. The dialog opens with the current value for editing instead of unsigning the field. - **`render-generic-text-field.ts`**: When `field.inserted` is true, `textToRender` is now always set to a safe string from `field.customText`, so the displayed value is always the signed value and never falls back to the prefill for an inserted field. ## Testing Performed - Created a template with a text field via the UI. - Used the `/api/v2/envelope/use` endpoint to create an envelope with a prefilled text field (`label: "Test Label"`, `value: "This should stay"`). - Opened the signing link as the recipient and confirmed the prefilled value is displayed. - Clicked on the field and confirmed the prefilled value is preserved and editable in the dialog. - Entered a new value, submitted, then clicked the field again — confirmed the dialog opens with the new value, not the original prefill. - Cancelled the dialog after opening — confirmed the existing value is unchanged. - Cleared the field value and submitted — confirmed the field is properly unsigned. - Verified that non-prefilled fields still correctly show the label as placeholder text. - Tested the same flow for number fields. - Tested on Chrome (latest). ## Checklist - [x] I have tested these changes locally and they work as expected. - [ ] I have added/updated tests that prove the effectiveness of these changes. - [ ] I have updated the documentation to reflect these changes, if applicable. - [x] I have followed the project's coding style guidelines. - [ ] I have addressed the code review feedback from the previous submission, if applicable. ## Additional Notes This bug only affects fields prefilled via the API. Fields created and filled through the UI are unaffected since they don't use the prefill code path. The root cause was the field component unconditionally initializing its editable state from `fieldMeta.label` on click/focus, without checking for an existing value first. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/documenso#2362
No description provided.