Added autoComplete prop/field passthrough in Portal

[kevinansfield]

no issue

• autoComplete='off' was used in our honeypot fields but it was never applied because the <InputForm> and <InputField> components didn't pass/accept an autoComplete prop

[coderabbitai]

Walkthrough

• InputField: Adds a public autoComplete prop with default '' and preserves existing switch-based assignments; initialization moved from local variable to prop default.
• InputForm: Passes field.autoComplete to InputField without other changes.
• Tests: Refactors setup to accept overridable props, adds assertions for autoComplete default behavior and explicit values, retains existing rendering and onChange tests.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The title clearly states the central change, which is the addition of an autoComplete prop passthrough in the Portal components. It is concise, free of unnecessary details or noise, and accurately reflects the main purpose of the pull request.
Description Check	✅ Passed	The description explains the reason for the change by noting that the autoComplete attribute was not previously applied because InputForm and InputField lacked passthrough support. This directly corresponds to the changes introduced in the pull request and remains focused on the relevant components and behavior.

✨ Finishing touches

• 📝 Generate Docstrings

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch autocomplete-passthrough

---

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

🧪 Early access (Sonnet 4.5): enabled

We are currently testing the Sonnet 4.5 model, which is expected to improve code review quality. However, this model may lead to increased noise levels in the review comments. Please disable the early access features if the noise level causes any inconvenience.

Note:

• Public repositories are always opted into early access features.
• You can enable or disable early access features from the CodeRabbit UI or by updating the CodeRabbit configuration file.

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

[troyciesco]

i think the cursor bot has a point here in that adding the autoComplete prop but always overwriting it for a few input types feels like it's introducing a point of friction worth addressing in this PR. maybe the autoCompletes in this switch should still use the prop if it's passed?

[cursor]

Bug: AutoComplete Prop Overwritten for Specific Inputs

The autoComplete prop is unconditionally overwritten within the switch statement for input IDs like input-email, input-name, and input-otc. This causes any autoComplete value passed via props to be ignored for these specific input types, defeating the purpose of the prop passthrough.

apps/portal/src/components/common/InputField.js#L120-L140

Ghost/apps/portal/src/components/common/InputField.js

Lines 120 to 140 in f845f51

	let pattern;
	switch (id) {
	case 'input-email':
	autoComplete = 'off';
	autoCorrect = 'off';
	autoCapitalize = 'off';
	break;
	case 'input-name':
	autoComplete = 'off';
	autoCorrect = 'off';
	break;
	case 'input-otc':
	autoComplete = 'one-time-code';
	autoCorrect = 'off';
	autoCapitalize = 'off';
	inputMode = 'numeric';
	pattern = '[0-9]*';
	placeholder ??= '• • • • • •';
	break;
	default:

 

---

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

apps/portal/src/components/common/InputField.js (1)

121-142: Address the autoComplete prop overwriting issue.

As noted in the past review, the switch statement unconditionally overwrites the autoComplete prop for input-email, input-name, and input-otc cases (lines 123, 128, 132). This defeats the purpose of making autoComplete a public prop, since callers cannot override these hardcoded values.

Consider using the passed prop value as the default and only falling back to hardcoded values when the prop is not explicitly provided:

    switch (id) {
    case 'input-email':
-       autoComplete = 'off';
+       autoComplete = autoComplete || 'off';
        autoCorrect = 'off';
        autoCapitalize = 'off';
        break;
    case 'input-name':
-       autoComplete = 'off';
+       autoComplete = autoComplete || 'off';
        autoCorrect = 'off';
        break;
    case 'input-otc':
-       autoComplete = 'one-time-code';
+       autoComplete = autoComplete || 'one-time-code';
        autoCorrect = 'off';
        autoCapitalize = 'off';
        inputMode = 'numeric';
        pattern = '[0-9]*';
        placeholder ??= '• • • • • •';
        break;
    default:
        break;
    }

This allows callers to explicitly override the defaults when needed (e.g., for honeypot fields) while maintaining sensible defaults for typical use cases.

Based on past review comments.

🧹 Nitpick comments (1)

apps/portal/src/components/common/InputField.test.js (1)

39-47: Add test for autoComplete override on specific input types.

The current tests verify basic autoComplete behavior, but they don't test the interaction with the switch statement that handles specific input IDs like input-email, input-name, and input-otc.

Consider adding a test to verify that the prop can override (or currently cannot override, which would document the limitation) the hardcoded autoComplete values for these specific input types:

test('applies autoComplete prop for email input type', () => {
    const {inputEl} = setup({id: 'input-email', autoComplete: 'username'});
    expect(inputEl).toHaveAttribute('autoComplete', 'username');
});

This would help verify whether the fix suggested in InputField.js (using autoComplete || 'off' instead of unconditional assignment) works as intended.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c86642d and f845f51.

📒 Files selected for processing (3)

• apps/portal/src/components/common/InputField.js (1 hunks)
• apps/portal/src/components/common/InputField.test.js (2 hunks)
• apps/portal/src/components/common/InputForm.js (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)

• GitHub Check: Setup
• GitHub Check: Build & Push
• GitHub Check: Setup

🔇 Additional comments (3)

apps/portal/src/components/common/InputField.js (1)

100-100: LGTM: autoComplete prop added correctly.

The prop is properly declared with a sensible default value of an empty string.

apps/portal/src/components/common/InputForm.js (1)

25-25: LGTM: autoComplete properly wired through.

The field.autoComplete value is correctly passed to the InputField component, enabling the passthrough behavior as intended.

apps/portal/src/components/common/InputField.test.js (1)

4-24: LGTM: Setup function refactored well.

The setup function now properly accepts and merges props, enabling flexible test configuration. Good refactor.