[HOLD for payment 2024-11-28] [HOLD for payment 2024-11-26] [$250] mWeb - Part of the screen is covered with black rectangle, scrolling is stuck on MC page

[lanitochka17]

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: 9.0.57-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: N/A
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/5176953
Issue reported by: Applause - Internal Team

Action Performed:

1. Navigate to https://staging.new.expensify.com/
   Sign in page
2. Type email address and tap Done to exit keyboard
3. Tap continue to go to MC page
4. Try to swipe up and down and observe the page

Expected Result:

Expensify animation is shown under Sign in module on the MC entering page

Actual Result:

Part of the screen is covered with black rectangle on MC page. Scrolling gets stuck after swiping up and down a few times

Workaround:

Unknown

Platforms:

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

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6654754_1730755095269.RPReplay_Final1730753829.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021853886233861740474
• Upwork Job ID: 1853886233861740474
• Last Price Increase: 2024-11-12

Issue Owner

Current Issue Owner: @isabelastisser

[melvin-bot]

Triggered auto assignment to @isabelastisser (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.

[bernhardoj]

Proposal

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

Part of the screen is not visible when going to the magic code input page.

What is the root cause of that problem?

This only happens if we open a keyboard first on the login/email page. The sign in page enable shouldEnableMaxHeight which uses the height from useWindowDimensions. In useWindowDimensions, every time we focus on an input, we set the height immediately from cachedViewportHeightWithKeyboardRef value.

App/src/hooks/useWindowDimensions/index.ts

Lines 51 to 58 in 10454f0

	const [, cachedViewportHeight, setCachedViewportHeight] = useDebouncedState(windowHeight, CONST.TIMING.RESIZE_DEBOUNCE_TIME);
	const handleFocusIn = useRef((event: FocusEvent) => {
	const targetElement = event.target as HTMLElement;
	if (tagNamesOpenKeyboard.includes(targetElement.tagName)) {
	setCachedViewportHeight(cachedViewportHeightWithKeyboardRef.current);
	}
	});

cachedViewportHeightWithKeyboardRef holds the height of the window when a keyboard is shown.

App/src/hooks/useWindowDimensions/index.ts

Lines 97 to 102 in 10454f0

	useEffect(() => {
	if (!isCachedViewportHeight || !window.matchMedia('(orientation: portrait)').matches || windowHeight >= initalViewportHeight) {
	return;
	}
	cachedViewportHeightWithKeyboardRef.current = windowHeight;
	}, [isCachedViewportHeight, windowHeight]);

For example, if the window height is 700, but when the keyboard shows it becomes 400, then cachedViewportHeightWithKeyboardRef value is 400. In our case, when we go to the magic code input, we auto-focus on the input and the height from cachedViewportHeightWithKeyboardRef is set as the useWindowDimensions height.

It was first added in #33546 to update the height quickly without waiting for window.visualViewport resize event (which rn-web uses to update the dimensions). However, in our case, the soft keyboard doesn't show (it's a known issue on safari if the focus isn't directly triggered by user action), so resizing it doesn't make sense.

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

I don't think we can know whether a keyboard will show from a focus event or no, so I'm suggesting removing shouldUseCachedViewportHeight from SignInPage.

App/src/pages/signin/SignInPage.tsx

Lines 295 to 298 in 10454f0

	<ScreenWrapper
	shouldShowOfflineIndicator={false}
	shouldEnableMaxHeight={shouldEnableMaxHeight}
	shouldUseCachedViewportHeight

shouldUseCachedViewportHeight is currently being used in SignInPage and WorkspaceInviteMessagePage. It wasn't applied globally because it causes issues on some pages. So, they only add it for WorkspaceInviteMessagePage. But then, in this issue, we add shouldUseCachedViewportHeight for SignInPage too.

Is it safe to remove shouldUseCachedViewportHeight from SignInPage?

The proposal there explain why we need to use shouldUseCachedViewportHeight, but the root cause is actually unclear. Also, if we look at the PR: #44999, it actually addressed the visual viewport scroll issue, instead of the wrong visual viewport height which is mentioned on the proposal. (btw, the issue is that a blank space appears above the keyboard)

And yes, the issue is about the visual viewport scroll. The visual viewport scroll issue is well explained in this other issue.

And it also happens on iOS safari, which isn't fixed yet. (more explanation below)

ios.mp4

So I believe we can safely remove shouldUseCachedViewportHeight since that doesn't fix the issue where it was added and just causes a worse issue.

---

For the iOS safari viewport scroll issue, we actually already has a solution for that, for all web, that is to scroll it back to 0,

App/src/hooks/useTackInputFocus/index.ts

Lines 31 to 39 in 10454f0

	const resetScrollPositionOnVisualViewport = useCallback(() => {
	if (Browser.isChromeIOS() && window.visualViewport?.offsetTop) {
	// On Chrome iOS, the visual viewport triggers a scroll event when the keyboard is opened, but some time the scroll position is not correct.
	// So this change is specific to Chrome iOS, helping to reset the viewport position correctly.
	window.scrollTo({top: -window.visualViewport.offsetTop});
	} else {
	window.scrollTo({top: 0});
	}
	}, []);

except for iOS chrome which was added in #44999.

However, there looks like a bug on iOS safari where if the visual viewport offsetTop is smaller than 59, then scrollTo doesn't do anything. We can apply the same workaround as iOS chrome, but it causes multiple scrolling.

safari.mp4

Another workaround for iOS safari only is to scroll to -1.

 else if (Browser.isMobileSafari() && (window.visualViewport?.offsetTop ?? 0) > 1) {
    window.scrollTo({top: -1});
} else {

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

@isabelastisser, @eh2077 Eep! 4 days overdue now. Issues have feelings too...

[eh2077]

I think I agree with @bernhardoj 's investigations on the issue. But I'll need to test the solutions they proposed to avoid unnecessary back-and-forth.