[$250] [INP] Slow Form-SubmitButton

[rlinoz]

In an effort to improve the #quality of our app we started looking at INP (interaction to next pain) and looking at our slowest INPs we have [data-sentry-label=“Form-SubmitButton”]

Let's investigate why it is slow and fix it.

Issue Owner

Current Issue Owner: @OlGierd03

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022034008884287958380
• Upwork Job ID: 2034008884287958380
• Last Price Increase: 2026-03-17

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @ShridharGoel (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022034008884287958380

[MelvinBot]

I have failed to help you. I let you down and for that I am sorry. Please try again later. This may be due to a Claude outage (check here).

Failure details: https://github.com/Expensify/Expensify/actions/runs/23215718760

[jainam884]

Proposal

Please re-state the problem that we are trying to solve in this issue.

The interaction tagged as Form-SubmitButton has high INP. When a user taps submit while focused in a form field, the submit path feels delayed before the form transitions into the submit/loading flow.

What is the root cause of that problem?

In FormProvider.submit(), we currently wait for KeyboardUtils.dismiss() to resolve before calling onSubmit.

App/src/components/Form/FormProvider.tsx

Lines 236 to 266 in 858f99c

	// Return early if the form is already submitting to avoid duplicate submission
	if (!!formState?.isLoading || isLoading) {
	return;
	}
	// Prepare values before submitting
	const trimmedStringValues = shouldTrimValues ? prepareValues(inputValues) : inputValues;
	// Touches all form inputs, so we can validate the entire form
	for (const inputID of Object.keys(inputRefs.current)) {
	touchedInputs.current[inputID] = true;
	}
	if (hasServerError) {
	return;
	}
	// Validate form and return early if any errors are found
	if (!isEmptyObject(onValidate(trimmedStringValues))) {
	return;
	}
	// Do not submit form if network is offline and the form is not enabled when offline
	if (network?.isOffline && !enabledWhenOffline) {
	return;
	}
	KeyboardUtils.dismiss().then(() => onSubmit(trimmedStringValues));
	}, [enabledWhenOffline, formState?.isLoading, inputValues, isLoading, network?.isOffline, onSubmit, onValidate, shouldTrimValues, hasServerError]),
	1000,
	{leading: true, trailing: false},

When the keyboard is visible, dismiss() resolves only after keyboard-hide events/viewport resize handling, so submit kickoff is blocked behind keyboard dismissal instead of starting immediately.

App/src/utils/keyboard/index.ts

Lines 23 to 38 in 858f99c

	const dismiss = (shouldSkipSafari?: boolean): Promise<void> => {
	return new Promise((resolve) => {
	if (!isVisible) {
	resolve();
	return;
	}
	const subscription = Keyboard.addListener('keyboardDidHide', () => {
	resolve();
	subscription.remove();
	});
	Keyboard.dismiss();
	});
	};

App/src/utils/keyboard/index.website.ts

Lines 37 to 67 in 858f99c

	const dismiss = (shouldSkipSafari = false): Promise<void> => {
	return new Promise((resolve) => {
	if (shouldSkipSafari && isMobileSafari()) {
	resolve();
	return;
	}
	if (!isVisible || !isMobile()) {
	resolve();
	return;
	}
	const handleDismissResize = () => {
	const viewportHeight = window?.visualViewport?.height;
	if (!viewportHeight || !initialViewportHeight) {
	return;
	}
	const isKeyboardVisible = initialViewportHeight - viewportHeight > CONST.SMART_BANNER_HEIGHT;
	if (isKeyboardVisible) {
	return;
	}
	window.visualViewport?.removeEventListener('resize', handleDismissResize);
	return resolve();
	};
	window.visualViewport?.addEventListener('resize', handleDismissResize);
	Keyboard.dismiss();
	});
	};

Assumption: on web, clicking submit can also trigger input blur validation and then full submit validation in the same interaction window, adding extra main-thread work around the same tap.

What changes do you think we should make in order to solve the problem?

1. In FormProvider.submit(), replace KeyboardUtils.dismiss().then(() => onSubmit(values)) with KeyboardUtils.dismissKeyboardAndExecute(() => onSubmit(values)).
2. Make submit-click blur prevention the default for forms (shouldPreventDefaultFocusOnPressSubmit = true in FormProvider/FormWrapper) so a submit click does not trigger an extra blur validation pass before submit.
3. Add a small submit-path performance measurement (validate time vs submit kickoff time) behind the same submit label so we can verify the INP drop after deployment.

What alternative solutions did you explore? (Optional)

I considered only optimizing individual forms that appear in Sentry traces, but this is a shared form-submit path used widely, so a central fix in FormProvider is safer and gives broader impact.

I also considered deferring validation with timers/idle callbacks, but that would delay error feedback and create inconsistent behavior across platforms.

[mendarb]

Proposal

Please re-state the problem that we are trying to solve in this issue.

The Form-SubmitButton interaction has a high INP score (>500ms at p75). When users tap submit on any form, the browser blocks painting for too long before showing visual feedback, creating a sluggish feel.

What is the root cause of that problem?

The submit handler in FormProvider.tsx performs multiple synchronous blocking operations before yielding to the browser:

1. onValidate → errors → onValidate dependency cycle: onValidate (line ~144) includes errors in its dependency array (line 205). Each validation call may setErrors, which changes errors, which recreates onValidate, which recreates submit, which recreates registerInput — causing all form inputs to re-render in a cascade before the next paint.

2. Synchronous validation in submit path: submit (line ~255) calls onValidate(trimmedStringValues) synchronously and checks its return inline. The validation iterates all input values, runs prepareValues (string trimming), performs HTML tag regex matching on every field, and calls setErrors — all blocking the main thread during the press event.

3. registerInput recreated too often: It depends on errors, inputValues, draftValues, formState?.errorFields, onValidate, and submit (line ~460). Any change to any of these triggers a new callback, forcing every registered input to receive new props and re-render.

4. Un-memoized FormAlertWithSubmitButton: It is a plain function component (no React.memo), so it re-renders every time FormWrapper re-renders, even when its own props are unchanged.

5. withNavigationFallback HOC on Button: Every Button render goes through this un-memoized HOC layer (line 551 of Button/index.tsx), adding overhead via the useIsFocused() hook.

What changes do you think we should make in order to solve the problem?

1. Break the onValidate → errors cycle: Replace errors in onValidates dependency array with a ref (errorsRef.current). Validation only needs the current error values for comparison, not reactivity — a ref avoids the cascade.

2. Defer validation off the critical path: Wrap the onValidate call inside submit with InteractionManager.runAfterInteractions() so the button press visual feedback paints first, then validation runs. Show immediate visual feedback (loading state) before starting validation.

3. Wrap FormAlertWithSubmitButton in React.memo and stabilize its callback props (onSubmit, onFixTheErrorsLinkPressed) with useCallback in FormWrapper.

4. Memoize the SubmitButton JSX in FormWrapper using useMemo instead of the current inline const SubmitButton = isSubmitButtonVisible && (...) which creates a new element tree every render.

5. Stabilize registerInput by moving inputValues and errors reads to refs where they are only used for current-value lookups, not as reactive dependencies.

What alternative solutions did you explore? (Optional)

• Using startTransition from React 18 was considered but INP measures time to next paint, and startTransition still blocks the main thread — it just marks the update as non-urgent for React scheduler, which does not help with INP.
• Moving validation to a Web Worker was considered but impractical since it needs access to React state and Onyx stores.

[melvin-bot]

📣 @mendarb! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[czarflix]

I’m working on reproducing this on staging, will update shortly.

[melvin-bot]

📣 @czarflix! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>