[HOLD for payment 2024-06-20] [$250] iPhone 13 PRO/chrome - Continue button is cut off at the bottom in sign in screen

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number:
Reproducible in staging?: Needs reproduction
Reproducible in production?: Needs reproduction
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @danielrvidal
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1713929851923959

Action Performed:

Precondition: User should have saved credentials in keychain or password

1. Go to staging.new.expensify.com on IOS Chrome
2. Tap on the key icon to choose saved credentials

Expected Result:

Continue button is visible

Actual Result:

Keyboard covers half of the continue button

Workaround:

unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0197bc982a483fb96d
• Upwork Job ID: 1787806860579430400
• Last Price Increase: 2024-05-21
• Automatic offers:
• eh2077 | Reviewer | 102437874
• suneox | Contributor | 102437878

Issue Owner

Current Issue Owner: @miljakljajic

[melvin-bot]

Triggered auto assignment to @miljakljajic (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[MelvinBot]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[melvin-bot]

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

[miljakljajic]

I wasn't able to reproduce this. I'll see if anyone in QA can.

[melvin-bot]

@miljakljajic Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

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

[melvin-bot]

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

[miljakljajic]

Kavi was able to reproduce, adding external label to be worked on.

[melvin-bot]

@miljakljajic @eh2077 this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[melvin-bot]

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

[eh2077]

Not overdue, still waiting for proposals

[suneox]

Proposal

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

The virtual viewport on the Webkit-based browsers is not reset when focusing on the input

What is the root cause of that problem?

We have 2 issues here:
Issue 1: We have a blank space when focus to input the same with this issue

#41108	#19642

I have resolve #19642 only for isMobileSafari by the condition avoid scroll on virtual viewport at this line and not support isMobileWebKit so it not include Webkit-based browsers

Issue 2: We don't handle scroll the button into the view when focusing on the input

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

Fix issue 1:
We will change condition at this line from isMobileSafari to isMobileWebKit

    const isAvoidingViewportScroll = useTackInputFocus(shouldEnableMaxHeight && shouldAvoidScrollOnVirtualViewport && Browser.isMobileWebKit());

Fix issue 2:
We should keep current submit container ref then after input focus we will trigger scroll to the button into the view after reset the virtual viewport

+   const submitContainerRef = useRef<View | HTMLDivElement>(null);
+   const handleFocus = useCallback(() => {
+       InteractionManager.runAfterInteractions(() => {
+           htmlDivElementRef(submitContainerRef).current?.scrollIntoView?.({behavior: 'smooth', block: 'end'});
+       });
+   },[])

    return (
        <>
            <View
                accessibilityLabel={translate('loginForm.loginForm')}
                style={[styles.mt3]}
            >
                <TextInput
                    ref={input}
+                   onFocus={handleFocus}
                    ....

            isVisible && (
+               <View style={[shouldShowServerError ? {} : styles.mt5]} ref={viewRef(submitContainerRef)}>

What alternative solutions did you explore? (Optional)

Issue 1: Create new function check isChromeIOS and handle reset scroll on the virtual viewport when focusing on the input something like that

    onFocus={() => {
        const isChromeIOS = () => {
            const userAgent = navigator.userAgent;
            return /CriOS/i.test(userAgent); // Checks if 'CriOS' (Chrome for iOS) is present
        }
        if (isChromeIOS()) {
          InteractionManager.runAfterInteractions(() => {
            window.scrollTo({top: 0});
          });
          // OR window.visualViewport?.addEventListener('scroll', resetScrollPositionOnVisualViewport);
        }
    }}

Issue 2: Instead of keep submitContainerRef we can update forward ref for FormAlertWithSubmitButton and keep submit button ref

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot]

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

[eh2077]

@suneox 's proposal looks good to me. I think we can go with their main solution.

🎀👀🎀 C+ reviewed

[melvin-bot]

Triggered auto assignment to @madmax330, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[melvin-bot]

📣 @eh2077 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job

[melvin-bot]

📣 @suneox 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job
Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

[suneox]

@eh2077 The PR is ready to review

[eh2077]

Still working on the PR

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

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

• handle login scroll on virtual viewport #42603

If no regressions arise, payment will be issued on 2024-06-20. 🎊

For reference, here are some details about the assignees on this issue:

• @suneox requires payment automatic offer (Contributor)
• @eh2077 requires payment automatic offer (Reviewer)

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@suneox / @eh2077] The PR that introduced the bug has been identified. Link to the PR:
• [@suneox / @eh2077] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@suneox / @eh2077] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@suneox / @eh2077] Determine if we should create a regression test for this bug.
• [@suneox / @eh2077] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@miljakljajic] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[eh2077]

Checklist

• [@suneox / @eh2077] The PR that introduced the bug has been identified. Link to the PR: I don't think there's a PR responsible for it as this is just an edge use case we missed
• [@suneox / @eh2077] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment: N/A
• [@suneox / @eh2077] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion: N/A
• [@suneox / @eh2077] Determine if we should create a regression test for this bug. No, we don't a regression test for it

[eh2077]

Not overdue, we're just waiting for @miljakljajic to handle the payment

[miljakljajic]

payment completed