[HOLD] [$1000] mWeb - mWeb - Keyboard opens automatically after going back from attachment

[kbecciv]

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

---

Action Performed:

1. Go to any chat
2. Send any image as attachment.
3. Click on image to view it.
4. Click back arrow to go back to chat.
5. Keyboard opens automatically

Expected Result:

Keyboard should not open automatically.

Actual Result:

Keyboard opens automatically

Workaround:

Unknown

Platforms:

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

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number:
Reproducible in staging?:
Reproducible in production?:
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
Notes/Photos/Videos: Any additional supporting documentation

WhatsApp.Video.2023-07-23.at.11.21.06.PM.mp4

Screen_Recording_20230724_103858_Chrome.mp4

Expensify/Expensify Issue URL:
Issue reported by: @Talha345
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1690147484102679

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~011c973cf5ceb3c3f7
• Upwork Job ID: 1683583847311867904
• Last Price Increase: 2023-07-31

[melvin-bot]

Triggered auto assignment to @stephanieelliott (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[samh-nl]

Proposal

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

The keyboard automatically opens when returning from selecting an attachment.

What is the root cause of that problem?

When the window regains focus, as measured by this.props.isFocused, the composer is focused again:

App/src/pages/home/report/ReportActionCompose.js

Lines 268 to 274 in 64e719e

	componentDidUpdate(prevProps) {
	// We want to focus or refocus the input when a modal has been closed or the underlying screen is refocused.
	// We avoid doing this on native platforms since the software keyboard popping
	// open creates a jarring and broken UX.
	if (this.willBlurTextInputOnTapOutside && !this.props.modal.isVisible && this.props.isFocused && (prevProps.modal.isVisible || !prevProps.isFocused)) {
	this.focus();
	}

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

We should prevent this behavior for mobile web users, similar to the behavior on native where this.willBlurTextInputOnTapOutside is false. On mobile web, we can determine this using !DeviceCapabilities.canUseTouchScreen().

I do question whether the correct variable is used here and whether it should not be this.shouldFocusInputOnScreenFocus instead, as we are trying to focus here and not blur the input.

This variable has the value !DeviceCapabilities.canUseTouchScreen() (web/mWeb) and false on native, which would lead to a correct situation also.

What alternative solutions did you explore? (Optional)

We could implement specific logic for preventing this behavior when returning from selecting an attachment. However, a general solution may be more desired as this behavior seems unwanted on mobile.

[stephanieelliott]

Was able to repro.

[melvin-bot]

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

[melvin-bot]

Current assignee @stephanieelliott is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

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

[s-alves10]

@stephanieelliott @fedirjh

Refocusing on main composer opens the keyboard. I think this is an expected behavior

[Talha345]

@stephanieelliott @fedirjh

Refocusing on main composer opens the keyboard. I think this is an expected behavior

Nope, as we had the same issue on native platforms previously and we disabled it.This is not the expected behaviour.Only when the user taps the composer, only then the keyboard should open.

[samh-nl]

On native mobile this.willBlurTextInputOnTapOutside is defined as false, so the behavior should not be present there. It would seem logical to apply this consistently to mWeb also.

[situchan]

I think composer autofocus issues on mWeb can be handled in #23382.

[fedirjh]

@situchan It looks like they are separate bugs, However, for this issue, I think this is the expected behavior. cc @stephanieelliott, looking at this comment, it seems like this is the expected, Focusing the input will open the keyboard on non-native platforms.

App/src/pages/home/report/ReportActionCompose.js

Lines 269 to 271 in 64e719e

	// We want to focus or refocus the input when a modal has been closed or the underlying screen is refocused.
	// We avoid doing this on native platforms since the software keyboard popping
	// open creates a jarring and broken UX.

[Talha345]

@situchan It looks like they are separate bugs, However, for this issue, I think this is the expected behavior. cc @stephanieelliott, looking at this comment, it seems like this is the expected, Focusing the input will open the keyboard on non-native platforms.

App/src/pages/home/report/ReportActionCompose.js

Lines 269 to 271 in 64e719e

	// We want to focus or refocus the input when a modal has been closed or the underlying screen is refocused.
	// We avoid doing this on native platforms since the software keyboard popping
	// open creates a jarring and broken UX.

If you read the comment,it is mentioned that this same issue existed on native platforms and was solved using this code.If we are fixing it on native platforms,why not on mWeb?

[samh-nl]

It seems to be a regression. I suspected the wrong variable was used here (see proposal, this.shouldFocusInputOnScreenFocus adds the correct behavior on native/mWeb).

Originally this variable was used:
https://github.com/Expensify/App/blame/4884bdc5fd3cc6889bb14286e6b137bc5c075504/src/pages/home/report/ReportActionCompose.js#L180-L183

Then later it was changed to this.shouldOverrideRnFocusBehavior and that was renamed to this.willBlurTextInputOnTapOutside.

However, other usages of the old variable this.shouldOverrideRnFocusBehavior are currently using this.shouldFocusInputOnScreenFocus.

[stephanieelliott]

This feels like expected behavior to me too... I don't know enough about the RN variable to be certain though. @fedirjh based on the above, do you still agree this is not a bug?

[Talha345]

This feels like expected behavior to me too... I don't know enough about the RN variable to be certain though. @fedirjh based on the above, do you still agree this is not a bug?

@stephanieelliott Think from the perspective of a user using the platform.
They open a chat and scroll through it and every time they open an image attachment to preview it and close it,the keyboard pops up.Feels like buggy behavior to me at least.

[fedirjh]

based on the above, do you still agree this is not a bug?

I don’t think this is a bug.

Feels like buggy behavior to me at least.

The behavior should be fixed by #15992 , So I believe we should hold this one for [Tracking] Fix Composer Component Focus Issues

Edit: This is a similar issue #16596 that was held for #15992.

[melvin-bot]

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

[stephanieelliott]

I agree with @fedirjh, it feels like polish if anything. Taking Help Wanted off this one and adding it to the tracking issue.

[stephanieelliott]

Not overdue, just removed the Daily label since this is on hold

[fedirjh]

Still on hold.

[stephanieelliott]

Still on hold.

[fedirjh]

Still on hold for #15992

[stephanieelliott]

Still on hold

[stephanieelliott]

Closing this as I don't think it is a priority. It is linked to the master tracking issue for composer component polish (which has also been deprioritized), so we may reopen it when we decide to focus on that issue.