[$175] Rules - Description bar is not correctly centered after user focus back on

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

Version Number: 9.5.32-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #105457
Email or phone of affected tester (no customers): winnaire@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Pixel 7 pro / Android 16
App Component: Workspace Settings

Action Performed:

Open https://staging.new.expensify.com/
Open Workspace, and Select 'Rules'
Tap on 'Add rule' at top left
Locate 'Or just describe it below' section and tap to expand keyboard
Insert 'Text the approver's phone whenever a report is submitted' and tap on 'Next'
While keyboard is still expanded swipe to top so the previous section is out of range
Tap anywhere in keyboard to insert a keyword and focus again on previous section

Expected Result:

The user should be scrolled to where the caret position is

Actual Result:

The user is not correctly to where the caret is positioned

Workaround:

Unknown

Platforms:

Screenshots/Videos

Bug7305366_1793839636267.PR_105457_fail.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7305366

Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~022118216495827355883
Upwork Job ID: 2118216495827355883
Last Price Increase: 2026-11-05

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/ca69491c512b80c4d72c7be1f293b96f778d4075ad3364e38cb317985c7263ae

https://platform.applause.com/services/links/v1/external/7a191a3636b184cdfa5a4e2cf4fe89de38b5001c929373f66b7c7be69ae91663

Proposal

What is the root cause of that problem?

Medium confidence: the description restores its visibility on focus, but not when typing resumes in an already-focused field. Scrolling away with the keyboard open need not blur the input, so subsequent typing does not trigger the existing scroll handler. This explains why the caret can remain off-screen.

Code evidence and alternatives checked

DescribeRuleForm.tsx:299–301 scrolls to the input container’s top. The input configuration:343–370 preserves the keyboard on submission and attaches scrolling only to onFocus, not editing or selection changes.
The native edit handler:248–265 updates text separately from focus handling.
Refusal handling:181–200 scrolls to the answer once. Removing that scroll would not repair visibility after manual scrolling. The QA-linked Scroll New rule to a refused rule so the keyboard doesn't cover it is not established as the introducing PR.
A delayed-scroll race or genuine blur/refocus failure remains possible. Native event tracing and reproduction after animations settle would distinguish these from the retained-focus explanation.

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

Add local visibility recovery when the description is edited while focused, limited to the scrolling form. Reveal the caret when obscured, preserve intentional scrolling until editing resumes, and coalesce requests to avoid jumping on every keystroke. Keep the existing initial-focus and refusal scrolling; preserve form value/draft handling.

Validation required

Add a regression test that edits without firing another focus event. The current input mock:123–145 forwards only focus and cannot exercise this scenario.
Verify the exact sequence on Android and iOS, both before submission and after refusal. Include long multiline text, rapid typing, and the non-scrolling Describe modal. Scrolling to the box’s top alone must not be assumed to reveal every caret position.
Web verification was blocked by a Control-plan upgrade dialog before reaching the description. No caret failure or fix was verified; desktop web also cannot establish native software-keyboard behavior. No code changes were made.

What alternative solutions did you explore? (Optional)

Another focus-only handler cannot cover retained-focus typing. Dismissing the keyboard changes the intended editing flow rather than fixing caret visibility. A shared scrolling overhaul is broader than this issue currently warrants.

Related issues: New rule scrolls in two jumps when the describe box gets focus and App does not scroll down to Describe field when field is focused concern initial focus; they are related, not confirmed duplicates of this resumed-editing case.

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/106059) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

view run

🤖 Web test steps verification results: ⚠️ partial

Verified app access and Workspace Rules navigation on dev NewDot web. Add rule opened a Control-plan upgrade dialog, blocking form and caret checks; native keyboard behavior cannot be verified on desktop web.

Step	Status
Open app Authenticated Home screen rendered.	✅
Workspace > Rules Created a workspace, enabled Rules, and opened the Rules page.	✅
Add rule Clicked Add rule, but reached a Control-plan upgrade dialog rather than the rule form. No upgrade was authorized.	⚠️
Focus 'Or just describe it below' Blocked by the upgrade dialog; description field was not reached.	⚠️
Enter "Text the approver's phone whenever a report is submitted" and press Next Blocked because the rule form was not reached.	⚠️
Scroll away while preserving focus and keeping the keyboard expanded Blocked before description entry. Native keyboard expansion is also unverifiable on desktop web.	⚠️
Type again and verify caret visibility Blocked before description entry; caret behavior was not observed.	⚠️

view run · view recording

@situchan

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

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

Problem: In Workspace > Rules > Add rule, after typing a description and scrolling away while the keyboard stays open, tapping back into the description and typing again leaves the caret off-screen instead of scrolling the form to it.

Root cause: In src/pages/workspace/rules/DescribeRuleForm.tsx, scrolling is attached only to focus: the description input has onFocus={scrollToInput}, and scrollToInput scrolls the form to the input container's top (inputTopOffsetRef from the container's onLayout). Scrolling away with the keyboard open does not blur the input, so typing again fires no focus event and no scroll runs — the caret can sit hidden below the keyboard or above the viewport. Even on focus, the scroll targets the container top, not the caret line.

Fix:

Reuse the existing scroll machinery on edit as well as focus: call scrollToInput from onChangeText/onSelectionChange on the description input, coalesced (e.g. via requestAnimationFrame or a short debounce) so it does not jump on every keystroke.
Scroll to the caret, not just the container top: use the selection start from onSelectionChange to compute the caret line's offset and scroll that line above the keyboard, falling back to the existing container-top scroll when no selection is available.
Only scroll when the caret is actually obscured (below the keyboard top or above the viewport), so intentional manual scrolling is preserved until editing resumes. Keep the existing initial-focus scroll and the refusal scroll untouched.

Verification: Reproduce the exact steps (add rule, type a description, scroll away with the keyboard open, tap back in and type) and confirm the caret stays visible; confirm normal typing does not jump; confirm the refusal flow still scrolls to the refused rule. Add a regression test that edits the description without firing another focus event and asserts the scroll runs.

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

Proposal for Issue #106059 — Rules description bar not centered after focus ($175)

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

In Workspace → Rules → "Create a rule" form, when the user taps on a text input (e.g. the rule name or description field), the form scrolls to make the input visible (scrollToInput). However, the description bar does not remain centered/near the input — after the field gains focus and the form scrolls, the field's label/title bar is positioned off-screen or mis-aligned vertically, so the user can't see what they're typing into.

What is the root cause of that problem?

In src/pages/workspace/rules/DescribeRuleForm.tsx:

Line 301: const scrollToInput = () => formRef.current?.scrollTo(inputTopOffsetRef.current);
Line 363: onFocus={scrollToInput}

The scrollToInput function is called only on onFocus. The problem is that onFocus fires once — when the input first gains focus. But the form may be scrolled by the system (keyboard avoidance), or the user may scroll manually. When the user taps another input lower on the form, the onFocus fires for that field, BUT:

The scroll offset stored in inputTopOffsetRef (line 297) is set by onLayout of the input's container — but onLayout gives coordinates relative to the parent ScrollView, not accounting for the current scroll position of the keyboard avoidance view.
The scrollTo(inputTopOffsetRef.current) uses the raw layout offset. If the keyboard is already visible (from a previously focused field), the form has already been scrolled by the keyboard-avoidance system. Scrolling to the raw inputTopOffset value without adjusting for the keyboard height leads to the input being positioned at the top of the visible area (or even partially hidden behind the keyboard) rather than centered.

The core issue: scrollToInput does not account for the visible viewport height after keyboard avoidance has already shifted the scroll position. It scrolls to a fixed offset calculated from the field's position within the form, not from the field's actual visible position.

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

Use scrollToInput correctly — instead of scrolling to a fixed offset, use formRef.current?.scrollTo({y: inputTopOffsetRef.current, animated: true}) and additionally ensure the input is centered in the visible area by accounting for the keyboard height.

Specifically:

Track the keyboard height (via KeyboardAvoidingView behavior or a useKeyboardHeight hook which is already available in the codebase).
In scrollToInput, compute the target scroll position so that the input field is vertically centered in the area above the keyboard:

const scrollToInput = () => {
    const keyboardHeight = keyboardHeightRef.current;
    const inputTop = inputTopOffsetRef.current;
    const formHeight = formRef.current?.getScrollHeight?.() ?? 0;
    const visibleHeight = Dimensions.get('window').height - keyboardHeight;
    const targetOffset = Math.max(0, inputTop - (visibleHeight / 2));
    formRef.current?.scrollTo({y: targetOffset, animated: true});
};

Also call scrollToInput on onContentSizeChange or onKeyPress so that if the field is already focused (no new onFocus fires) the form re-scrolls correctly.

What specific scenarios should be covered by automated tests?

When an input gains focus and keyboard appears, the input should be visible and centered in the viewport above the keyboard
When switching between inputs in the form, each one should be properly scrolled into view
When the keyboard is dismissed and a field is tapped again, the input should be centered

What alternative solutions did you explore?

Using KeyboardAvoidingView with behavior="padding" — Already in use but alone doesn't provide centering; it only ensures the field is visible. The issue specifically asks for better positioning than just "visible."
Using scrollToFocusedInput from React Native's ScrollViewTextInput — Not available in this codebase's setup.

PR

PR will be linked here once created.

Proposal

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

On mobile (Rules > Add expense rule > Describe your rule), when the user submits an impossible rule (for example, delete all expenses) so the assistant renders a long refusal alert below the input, then swipes up to read the refusal and starts typing again in the still-focused description input, the screen does not scroll the description input back into the visible center area above the keyboard. The user ends up typing blindly while the input bar remains off-screen or partially hidden.

What is the root cause of that problem?

In src/pages/workspace/rules/DescribeRuleForm.tsx:301, FormProvider sets shouldScrollChildToFocus={false} and relies on a manual scrollToInput callback (lines 255-261):

const scrollToInput = useCallback(() => {
    setTimeout(() => {
        formRef.current?.scrollTo({y: promptInputBottomRef.current, animated: true});
    }, 100);
}, []);

On line 365, scrollToInput is only passed to onFocus={scrollToInput} on the rulePrompt InputWrapper:

<InputWrapper
    InputComponent={TextInput}
    inputID={INPUT_IDS.RULE_PROMPT}
    value={promptText}
    onChangeText={setPromptText}
    onFocus={scrollToInput}

When the rule generation returns a refusal (response.reason), the useEffect at lines 195-201 runs formRef.current?.scrollToEnd({animated: true}) while the TextInput retains focus and the soft keyboard stays open (FormScrollView uses keyboardShouldPersistTaps="handled").
When the user manually scrolls up to inspect the refusal message and then types on the already-open keyboard (or taps inside the already-focused TextInput), onFocus does not fire again because the input never blurred. As a result, scrollToInput() is never triggered when typing resumes.

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

In src/pages/workspace/rules/DescribeRuleForm.tsx, trigger scrollToInput() when the user edits text in the prompt input (in addition to onFocus), so typing after manually scrolling away immediately centers/scrolls the description input back into view above the keyboard:

const handlePromptChange = useCallback(
    (text: string) => {
        setPromptText(text);
        scrollToInput();
    },
    [scrollToInput],
);

And pass onChangeText={handlePromptChange} (and onPress={scrollToInput} if supported / onFocus={scrollToInput}) to the INPUT_IDS.RULE_PROMPT InputWrapper at line 360-366:

<InputWrapper
    InputComponent={TextInput}
    inputID={INPUT_IDS.RULE_PROMPT}
    value={promptText}
    onChangeText={handlePromptChange}
    onFocus={scrollToInput}

What alternative solutions did you explore? (Optional)

We also considered adding keyboardDismissMode="on-drag" on FormScrollView, which would blur the input when the user drags the scroll view so tapping it again fires onFocus. However, keeping the keyboard open while scrolling and calling scrollToInput() in handlePromptChange avoids unnecessary keyboard close/reopen animations and works even when the user types directly on the open keyboard after scrolling.

@ronanchnlps-bit

📣 @ronanchnlps-bit! 📣
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:

Make sure you've read and understood the contributing guidelines.
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.
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.
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>

Proposal

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

On mobile devices (Android and iOS) under Workspace > Rules > Add rule, when a user enters a description into the "Or just describe it below" input and taps Next, refocusing or typing in the field while the keyboard is up leaves the description input out of center or partially obscured behind the soft keyboard.

What is the root cause of that problem?

In DescribeRuleForm.tsx, the FormProvider retains input focus after submission (SUBMIT_ONLY behavior). When validation messages or helper text appear beneath the input, the scroll offset within FormWrapper / ScrollView shifts, but the component does not trigger a scroll-into-view adjustment when the input is refocused, causing the cursor and text box to remain misaligned with the visible viewport above the keyboard.

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

In DescribeRuleForm.tsx:
- Attach an onFocus handler to the description TextInput that invokes scrollIntoView or scrollToFocusedInput on the parent ScrollView ref.
- When the form transitions states or displays feedback below the input, ensure the active input's bounding layout is recentered within the visible viewport above the virtual keyboard.
- Adjust keyboardShouldPersistTaps / dismiss behavior so that keyboard transitions gracefully adjust scroll offsets.

What alternative solutions did you explore? (Optional)

Dismissing the keyboard unconditionally on Next, which disrupts fluid keyboard-driven input and violates the intended mobile rule creation UX.

@situchan

@situchan Eep! 4 days overdue now. Issues have feelings too...

@MelvinBot

@MelvinBot implement your proposal

🤖 Web test steps verification results: ⚠️ partial

Baseline only on unmodified dev NewDot web; no fix was implemented or verified. Implementation is blocked: Add rule requires a paid upgrade, and the existing form scrolling API cannot establish obscured-caret visibility; simply scrolling on every edit would not safely fulfill the proposal’s multiline requirement.

Step	Status
Open app Authenticated Home displayed.	✅
Open Workspace > Rules Rules page displayed Add rule.	✅
Add rule Blocked by the Control-plan upgrade dialog; no upgrade accepted. Screenshot upload was unavailable.	⚠️
Focus description Field inaccessible behind the upgrade gate.	⚠️
Enter description and press Next Form inaccessible.	⚠️
Scroll away while retaining focus Blocked; desktop web also cannot establish native software-keyboard behavior.	⚠️
Resume typing and verify multiline caret visibility Not verified. A Rules-enabled test workspace and native keyboard/caret validation are needed before safely completing this fix. No PR created.	⚠️

view run · view recording

@MelvinBot

@MelvinBot do not block implementation on testing. I'll test myself.

Implemented in draft PR: Keep the rule description visible when editing resumes, assigned to you.

27 targeted tests, typecheck, lint, and Storybook smoke passed. Full-suite timeout and pre-existing compiler diagnostics are documented in the PR. Manual testing is left to you.

view run

Navigation Menu

Repository navigation

[$175] Rules - Description bar is not correctly centered after user focus back on #106059

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Proposal

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

Proposal for Issue #106059 — Rules description bar not centered after focus ($175)

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

What is the root cause of that problem?

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

What specific scenarios should be covered by automated tests?

What alternative solutions did you explore?

PR

Proposal

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

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

Proposal

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

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[$175] Rules - Description bar is not correctly centered after user focus back on #106059

Description

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Activity

applause-bot commented on Nov 5, 2026

MelvinBot commented on Nov 5, 2026

Proposal

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

MelvinBot commented on Nov 5, 2026

melvin-bot commented on Nov 5, 2026

melvin-bot commented on Nov 5, 2026

khizzcr7 commented on Nov 5, 2026

camesenin commented on Nov 5, 2026

melvin-bot commented on Nov 5, 2026

vanshshah11 commented on Nov 5, 2026

Proposal for Issue #106059 — Rules description bar not centered after focus ($175)

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

What is the root cause of that problem?

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

What specific scenarios should be covered by automated tests?

What alternative solutions did you explore?

PR

zaidrain06 commented on Nov 7, 2026

Proposal

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

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

jeffrey-graham commented on Nov 7, 2026

melvin-bot commented on Nov 7, 2026

melvin-bot commented on Nov 7, 2026

TassioSales commented on Nov 8, 2026

Proposal

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

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

melvin-bot commented on Nov 10, 2026

situchan commented on Nov 11, 2026

MelvinBot commented on Nov 11, 2026

situchan commented on Nov 13, 2026

MelvinBot commented on Nov 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions