[Due for payment 2026-11-03] Agents - Custom instructions field is blocked by the keyboard

@brunovjk

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

Version Number: 9.4.53-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #98380
Email or phone of affected tester (no customers): jose.sat94+10jul@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Samsung Galaxy S21/Android 15, iPhone 13/18.6.2
App Component: Other

Action Performed:

Launch Expensify app.
Log in with valid credentials.
Go to Account > Agents.
Click New agent, then Build custom agent.
Tap the Custom instructions field.
Try to enter text.

Expected Result:

The Custom instructions field should remain fully accessible above the keyboard, allowing the user to enter and edit instructions.

Actual Result:

The keyboard overlaps the Custom instructions field, preventing the user from typing. As a result, the agent cannot be created and the test cannot continue.

Workaround:

Unknown

Platforms:

Screenshots/Videos

Bug7232149_1786571781978.BUG.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~022087766009921103773
Upwork Job ID: 2087766009921103773
Last Price Increase: 2026-08-13

Issue Owner

Current Issue Owner: @brunovjk

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

Proposal

Please re-state the problem

On native (Android/iOS App), opening the keyboard in the Custom instructions field of the Build custom agent flow leaves the field covered by the keyboard, so the user can't see what they're typing and can't finish creating the agent.

What is the root cause?

The "Build custom agent" screen is AddAgentPage. Its ScreenWrapper gates keyboard/height handling on landscape only:

shouldEnableMaxHeight={shouldUseScrollableLayout}

AddAgentPage.tsx:169 — shouldUseScrollableLayout is only true in landscape/wide, so in normal portrait it is false.

ScreenWrapper only bounds its KeyboardAvoidingView when shouldEnableMaxHeight is set — otherwise maxHeight is undefined:

const maxHeight = shouldEnableMaxHeight ? windowHeight : undefined;

ScreenWrapperContainer.tsx:128

With maxHeight unset, the flex1 markdown input fills 100% height and the KeyboardAvoidingView can't shrink the content when the keyboard opens, so the keyboard overlaps the field.

Every comparable full-page markdown-input RHP screen sets shouldEnableMaxHeight unconditionally and does not hit this bug — e.g. RoomDescriptionPage.tsx:102, WorkspaceOverviewDescriptionPage.tsx:76, TaskDescriptionPage.tsx:105, PrivateNotesEditPage.tsx:134.

The sibling edit screen EditPromptPage.tsx:75 uses the same shouldEnableMaxHeight={shouldUseScrollableLayout} gating, so it is very likely affected the same way and should be fixed together.

Note: The bug was found during QA of #98380, but that PR only changes markdown rendering on the profile page and is not the cause.

What changes do you think we should make?

Enable shouldEnableMaxHeight unconditionally on the ScreenWrapper for both agent instruction screens, matching every other markdown RHP page:

AddAgentPage.tsx: shouldEnableMaxHeight={shouldUseScrollableLayout} → shouldEnableMaxHeight
EditPromptPage.tsx: same change

The existing shouldUseScrollableLayout gating on shouldUseScrollView / submitFlexEnabled / minHeight42 should stay as-is — only the shouldEnableMaxHeight prop needs to be always-on. Verify the flex1 input still fills the screen in portrait and that the keyboard no longer overlaps the field on Android and iOS native.

What alternative solutions did you explore?

Wrapping the form body in a ScrollView on portrait as well (like RoomDescriptionPage) would also work, but it's a larger change; toggling shouldEnableMaxHeight is the minimal fix that brings this screen in line with the established pattern.

Confidence & scope

Confidence: Medium. Root cause is backed by direct code evidence and a consistent contrast against 4+ analogous screens. Not runtime-verified on a native device (this is a native-only bug — it does not repro on web/mWeb per the report), so please validate the fix on Android and iOS native before merge.

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

@brunovjk

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

VERDICT: POST
ROOT_CAUSE_ONELINER: Both AddAgentPage.tsx and EditPromptPage.tsx only enable keyboard avoidance (shouldEnableMaxHeight + shouldUseScrollView) in landscape mode, so in portrait mode the keyboard overlaps the "Custom instructions" input with no scroll or avoidance.
PROPOSAL_TYPE: FIRST
AUTOPOST_SAFE: YES

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

Proposal

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

On iOS and Android portrait layouts, focusing the full-height Custom instructions markdown field in the agent create/edit flow leaves part of the editor behind the software keyboard. The user must be able to see and edit the focused text and reach the submit action without changing the existing desktop/landscape layout.

What is the root cause of that problem?

Both agent instruction screens use the same layout combination:

ScreenWrapper.shouldEnableMaxHeight is enabled only for the landscape/scrollable variant;
FormProvider.shouldUseScrollView is also landscape-only;
the markdown field and every container around it use flex1.

In portrait, shouldEnableMaxHeight is therefore false while the form body expands to the available flex height. ScreenWrapperContainer only applies the window-height bound to its KeyboardAvoidingView when shouldEnableMaxHeight is true. Without that bound, the keyboard-avoiding container does not get a finite height to shrink against, so the flex-filled editor remains under the keyboard.

The same pattern exists in both:

AddAgentPage.tsx;
Agents/Fields/EditPromptPage.tsx.

Fixing only the create screen would leave the edit flow with the identical native bug.

This is separate from whether the form itself uses a ScrollView. The portrait design intentionally keeps the instruction editor stretched to fill remaining space; the missing requirement is a bounded outer keyboard-avoiding viewport.

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

Enable max-height handling unconditionally on both agent instruction screens:

<ScreenWrapper
    // ...
    shouldEnableMaxHeight
>

Replace shouldEnableMaxHeight={shouldUseScrollableLayout} in AddAgentPage and EditPromptPage.

Keep the existing landscape-only form behavior unchanged:

retain shouldUseScrollView={shouldUseScrollableLayout};
retain the current submitFlexEnabled behavior;
retain styles.minHeight42 only for the scrollable layout.

That preserves the intended large/landscape form while allowing KeyboardAvoidingView to resize the portrait flex editor correctly.

Do not add a fixed editor height or keyboard-specific magic offset. Those approaches would be fragile across device sizes, safe-area insets, predictive-text bars, hardware keyboards, and split/floating keyboards. The shared ScreenWrapper is already responsible for those platform differences.
Apply the fix to the sibling edit page in the same PR because it has the same structure and otherwise remains a guaranteed regression surface.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

Portrait native create-agent screen renders ScreenWrapper with shouldEnableMaxHeight=true while FormProvider.shouldUseScrollView=false.
Portrait native edit-prompt screen has the same contract.
Landscape native keeps shouldUseScrollView=true and the current minimum-height behavior.
Web/wide behavior remains unchanged.
A focused multiline instruction field remains visible when the keyboard height changes, including the submit/footer area.
Rotate portrait → landscape → portrait while focused and verify the editor retains its text and recalculates layout without overlap.
Test both iOS and Android native because their KeyboardAvoidingView behavior and safe-area handling differ.
Hardware-keyboard/no-soft-keyboard mode does not leave unnecessary bottom space.

A component-level test can assert the prop composition, while the overlap itself should be covered by the native interaction/QA test because JSDOM cannot model the software keyboard.

What alternative solutions did you explore? (Optional)

Make the portrait form scrollable: viable but broader than necessary and changes the intended full-height editor UX.
Apply keyboard padding directly to the TextInput: rejected because the keyboard belongs to the screen layout, not the field, and offsets vary by platform/device.
Fix only AddAgentPage: rejected because EditPromptPage contains the same bug-producing layout.

@GCyganek

@GCyganek It looks like we already have PR #97782 to address this issue, right?

@truph01

@truph01 not really, my PR only fixes landscape mode, I tried not to change portrait mode behaviour on it and from what I just tested this issue is still reproducible on my PR

@brunovjk

@brunovjk what is left here?

@lorretheboy

For your update @brunovjk, your mentioned issue is still under investigation... I will ping u once it is tackled. Thanks

The contribuitor, @lorretheboy, is still working at the PR. Thank you.

It is ready for another review now #102934

Still in review

same, reviewing today

@brunovjk

@brunovjk

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.5.23-3 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

Agents - Content overlaps with Custom instructions field in landscape mode #102934

If no regressions arise, payment will be issued on 2026-11-03. 🎊

The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the Contributor+ Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]. If no checklist is needed for this issue, you can click: [no checklist button]

@brunovjk

@brunovjk Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

Navigation Menu

Repository navigation

[Due for payment 2026-11-03] Agents - Custom instructions field is blocked by the keyboard #98529

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Proposal

Please re-state the problem

What is the root cause?

What changes do you think we should make?

What alternative solutions did you explore?

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 specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

What alternative solutions did you explore? (Optional)

82 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Due for payment 2026-11-03] Agents - Custom instructions field is blocked by the keyboard #98529

Description

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Activity

applause-bot commented on Aug 13, 2026

MelvinBot commented on Aug 13, 2026

Proposal

Please re-state the problem

What is the root cause?

What changes do you think we should make?

What alternative solutions did you explore?

melvin-bot commented on Aug 13, 2026

j3ffffff commented on Aug 13, 2026

melvin-bot commented on Aug 13, 2026

skrohan5016-coder commented on Aug 14, 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 specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

What alternative solutions did you explore? (Optional)

truph01 commented on Aug 17, 2026

GCyganek commented on Aug 17, 2026

82 remaining items

JS00001 commented on Oct 19, 2026

brunovjk commented on Oct 19, 2026

lorretheboy commented on Oct 19, 2026

JS00001 commented on Oct 22, 2026

JS00001 commented on Oct 26, 2026

melvin-bot commented on Oct 27, 2026

melvin-bot commented on Oct 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions