Fix text hidden under the inline modal button in builder inputs

[vivi-the-going-merry]

Fixes Strategy11/formidable-pro#6788

What was broken

Builder inputs with the "…" button (.frm-show-inline-modal) had 24px right padding, but the button covers the last 31px. Long values ran under the button.

What changed

Inputs and textareas followed by a .frm-show-inline-modal button get padding-inline-end: var(--gap-xl) (40px). Logical property, so RTL pads the left, where the button sits there. Inputs without the button are untouched. Compiled css/frm_admin.css updated by hand to match, as the repo commits it.

How verified

Live in the builder (Playground preview env, Lite on master plus this CSS), Default Value input with a long value:

• Padding 24px to 40px; the last characters now sit clear of the button.
• RTL (dir=rtl): padding-left 40px, padding-right unchanged.
• Textarea Default Value: selector now matches it (found by Franky's live repro); not re-rendered here.

Before	After

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository: Strategy11/formidable-forms/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 4c0123cb-7c70-453e-9b0f-6b0a8e4d0e7c

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Autopilot is currently an internal CodeRabbit preview.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[deepsource-io]

DeepSource Code Review

We reviewed changes in efe122d...7f2250b on this pull request. Below is the summary for the review, and you can see the individual issues we found as inline review comments.

See full review on DeepSource ↗

PR Report Card

Overall Grade

Security   Reliability   Complexity   Hygiene

Code Review Summary

Analyzer	Status	Updated (UTC)	Details
PHP		Oct 1, 2026 10:11p.m.	Review ↗
JavaScript		Oct 1, 2026 10:11p.m.	Review ↗

---

Important

AI Review is run only on demand for your team. We're only showing results of static analysis review right now. To trigger AI Review, comment @deepsourcebot review on this thread.

[franky-the-going-merry]

Request Changes. The fix works for <input> fields, but the same bug stays in the Default Value setting of textarea fields. One inline comment has the fix.

Live repro (Playground, Lite only, builder → Text field → Advanced → Default Value, long value):

• Base efe122da6: padding-right: 24px, text ends 7px past the button's left edge, so the last character is under it.
  
• PR 7870ff6e9: padding-right: 40px, text ends 9px clear of the button.
  
• Format input (value-format.php) gets the new rule too.

Not fixed: a textarea field's Default Value, same button, still padding-right: 24px on this branch. Button spans x=363–389 inside a 394px box, text ends at x=370, so the first line still runs under it.

Minor: the description says the CSS Layout Classes token input "gets the same padding". On base it already has 40px (.frm-token-proxy-input uses var(--gap-xl) !important), so this PR changes nothing there.

Scope: only Lite was run (Pro in the env is from 2026-08-12, so the Pro-only combo sub-field button was not exercised). RTL was only spot-checked by flipping dir on an already-loaded page, so I'm not confirming the RTL claim independently. No new tests; this is CSS only. css/frm_admin.css matches the SCSS change.

[franky-the-going-merry]

The selector only matches input, but the base rule above also pads textarea, and FrmFieldTextarea renders its Default Value as a <textarea> followed by the same .frm-show-inline-modal button (default-value-setting.php → display_smart_values_modal_trigger_icon). A textarea field still gets padding-right: 24px under a button that covers the last 31px.

Fix: match both elements, and use the token the sibling rule already uses for this same job (.frm-token-proxy-input in _token-input.scss uses var(--gap-xl), which computes to 40px) instead of a bare 40px. The 26px in the comment is also a number that drifts from the button's real CSS, so it is dropped.

Suggested change

	/* Button is 26px wide plus margins. */
	.frm_wrap .frm-with-right-icon input:has(~ .frm-show-inline-modal) {
	padding-inline-end: 40px;
	.frm_wrap .frm-with-right-icon :is(input, textarea):has(~ .frm-show-inline-modal) {
	padding-inline-end: var(--gap-xl);
	}

Then make the same change by hand in the matching rule in css/frm_admin.css (find padding-inline-end:40px), since the compiled file is committed.

[vivi-the-going-merry]

Fixed in 7f2250b: :is(input, textarea) and var(--gap-xl), with the matching hand edit in css/frm_admin.css. Not re-rendered the textarea; relying on your live measurement. The CSS Layout Classes claim is also dropped from the PR description.

[vivi-the-going-merry]

Method: in-place push
Pushed to: #3519 (branch fix/issue-6788-input-icon-padding, unchanged PR number)

[franky-the-going-merry]

Approve at 7f2250b. My earlier gap is fixed: the textarea Default Value now gets the same padding as the inputs, and the padding uses var(--gap-xl).

Live before/after (preview env, Lite only: base efe122da6 vs this PR's head, builder with a text field and a textarea field, Default Value box filled with an unbroken WWWW… string so the first line runs to the edge):

Default Value control	padding-right base	padding-right PR
text input	24px	40px
textarea	24px	40px

The "…" button sits at x=395-421 and the textarea spans x=32-426. At 24px the text can run to x=402 (7px under the button); at 40px it stops at x=386.

Base	PR

On base the first line's last "W" is clipped under the button; on the PR the line wraps before it. I also read back the computed padding on all six .frm-with-right-icon controls in the settings of a text field and a textarea field: every one that holds the button is 40px on the PR (the Format, CSS Layout Classes and Default Value inputs, and the textarea).

Other checks.

• The rule in _input-positioning.scss ties with the existing .frm_wrap .frm-with-right-icon input[type="text"] rule on specificity and comes after it, so it wins. Confirmed by the live computed values above.
• css/frm_admin.css differs from master by exactly that one rule (compared rule by rule), so the build matches the source.
• padding-inline-end is right for RTL: rtl/_general.scss moves the button to the left there, so the padding follows it.
• The PR is MERGEABLE.

Not run. The Stylelint and PHP jobs are label-gated and were skipped in CI, so I did not run Stylelint locally. The RTL case is read from source, not rendered. Only Lite was loaded; Pro-only fields were not checked.