[HOLD - App #26239] [$500] Mobile-Safari Auto Focuses Composer in Report on Existing chat

[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: 1.3.83-5
Reproducible in staging?: Yes
Reproducible in production?: Yes
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: @jeet-dhandha
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1697136130670869

Action Performed:

1. Open any Chat (which has some messages) in Mobile Safari.
2. Verify Composer is Auto-focused.
3. Test on iOS, Android, Mobile-Chrome for Step 1, Verify that it doesn't auto-focus on chat with messages.

Expected Result:

Composer in Mobile safari should not get auto-focused.

Actual Result:

Composer in Mobile-Safari get's auto-focused.

Workaround:

Unknown

Platforms:

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

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

Screenshots/Videos

Android: Native

focus-mweb-chrome.mov

Android: mWeb Chrome

iOS: Native

focus-iOS.mov

iOS: mWeb Safari

focus-mweb-safari.mov

RPReplay-Final1697147908.MP4

MacOS: Chrome / Safari

MacOS: Desktop

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01d1e885de54d568ec
• Upwork Job ID: 1712590372450942976
• Last Price Increase: 2023-10-12

[melvin-bot]

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

[melvin-bot]

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

[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

[melvin-bot]

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

[graylewis]

I'm unable to replicate this on my iOS simulator on production or staging

[jeet-dhandha]

Proposal

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

• Currently mobile safari is focusing on Composer even if the shouldAutoFocus flag is false. Other mobile devices such as iOS, Android and mWeb Chrome does not have this issue.
• We aren't focusing composer as user might just want to read the existing conversation.

What is the root cause of that problem?

• For mWeb-Safari we have below code which handles the focus issue.

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

Lines 40 to 44 in bbbfc9c

	// For mobile Safari, updating the selection prop on an unfocused input will cause it to automatically gain focus
	// and subsequent programmatic focus shifts (e.g., modal focus trap) to show the blue frame (:focus-visible style),
	// so we need to ensure that it is only updated after focus.
	const isMobileSafari = Browser.isMobileSafari();

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

Lines 126 to 129 in bbbfc9c

	const [selection, setSelection] = useState(() => ({
	start: isMobileSafari && !shouldAutoFocus ? 0 : value.length,
	end: isMobileSafari && !shouldAutoFocus ? 0 : value.length,
	}));

• But ComposerWithSuggestion also uses a Component called Composer whose index.js also has selection state which is causing the issue.

App/src/components/Composer/index.js

Lines 175 to 178 in bbbfc9c

	const [selection, setSelection] = useState({
	start: initialValue.length,
	end: initialValue.length,
	});

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

• If we update Composer with the code mentioned above in ComposerWithSuggestion then it will fix the issue.
• And instead of shouldAutoFocus we will use autoFocus prop.
• Also after this PR is merged,
  • fix: auto focus and scroll to bottom on large-text in composer #28790
• we will need to update index.js of UpdateMultilineInputRange by adding below code which will disable unwanted selection, as updateMultilineInputRange will be called each time Composer is mounted.

export default function updateMultilineInputRange(input, shouldAutoFocus = true) {
    if (!input) {
        return;
    }

    if (input.value && input.setSelectionRange) {
        const length = input.value.length;
+       // To disable unwanted focus on Composer when `shouldAutoFocus` is false.
+       if (!shouldAutoFocus && Browser.isMobileSafari()) {
+          // eslint-disable-next-line no-param-reassign
+          input.scrollTop = input.scrollHeight;
+          return;
+       }

        input.setSelectionRange(length, length);
        // eslint-disable-next-line no-param-reassign
        input.scrollTop = input.scrollHeight;
    }
}

What alternative solutions did you explore? (Optional)

• N/A

[jeet-dhandha]

Before Fix:

Screen.Recording.2023-10-13.at.9.17.45.AM.mov

After Fix (Including above mentioned PR changes):

Screen.Recording.2023-10-13.at.9.14.52.AM.mov

[parasharrajat]

Feels like we have a dependency on #28790 for above proposal.

[alexpensify]

@parasharrajat - are you suggesting that we should move this to be on HOLD until that GH is resolved?

[parasharrajat]

No, there might be more proposals.

[jeet-dhandha]

@parasharrajat My solution will work in current main branch but if we merge the mentioned PR, then the issue will rise again and will then be counted as regression. So to avoid that i mentioned it here.

[melvin-bot]

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

[thienlnam]

I think we should hold all these for #26239 which should ideally fix the root cause for all these focus issues upstream

[alexpensify]

Cool, moving this to weekly for now

[jeet-dhandha]

• Mobile Safari currently focuses on Input elements when their selection is set to greater than 0, which we don't want to happen.
• My solution basically uses the hack we have been using for Mobile Safari where we set Selection to {start: 0, end: 0} to not trigger the :focus of input.
• We are fixing this upstream here,
• setSelectionRange will reset the m_latestFocusTrigger variable, causing the subsequently focused element to match the :focus-visible selector WebKit/WebKit#15092
• But till then user's will still need this workaround, as upstream PR might take longer.

Also #28790 this PR is merged so we can move on with this issue.

[thienlnam]

I wouldn't consider this a severe enough bug to need to get a fix out immediately - let's just wait for the upstream fix so we don't have to have a bunch of back and fourths

[alexpensify]

Monthly Update: #26239 is waiting on Safari 17.4 to go into production. We are still at 17.3. Setting a reminder to check in next month.

[alexpensify]

Monthly Update: We are at 17.3.1. Setting a reminder to check in next month.

[alexpensify]

@ntdiary - I believe that we are at Version 17.4.1 now, can we confirm if we can take this one off hold? Thanks!

[ntdiary]

@ntdiary - I believe that we are at Version 17.4.1 now, can we confirm if we can take this one off hold? Thanks!

Yeah, our upstream PR has been released in 17.4. :)

[alexpensify]

We are back open for proposals here. Thanks!

[parasharrajat]

@alexpensify Could you please remove the Hold from the title and reconfirm details in OP? It been so long, it might be outdated.

[parasharrajat]

@Expensify/applause can you please recheck this issue? Is it still valid based on the latest regression steps?

[alexpensify]

I'm going to put this back on hold for #26239. It looks like there will be some cleanup in the other GH.

[alexpensify]

Weekly Update: The other GH is going through a clean-up process.

[alexpensify]

Weekly Update: The other GH is still being updated

[alexpensify]

Weekly Update: The other GH is on hold for another update

[alexpensify]

Weekly Update: Same as last week, waiting on the other GH.

[alexpensify]

Weekly Update: #26239 is moving along, we can test this one again once it's in Staging or production.

[alexpensify]

Heads up, I will be offline until Tuesday, May 28, 2024, and will not actively watch over this GitHub during that period.

If anything urgent is needed here, please ask for help in the #expensify-open-source Slack Room-- thanks!

[alexpensify]

#26239 is in production. @Expensify/applause can you please recheck this issue? Is it still valid based on the latest regression steps? Thanks!

cc: @ntdiary who worked on the PR above.

[alexpensify]

Weekly Update: Waiting for a retest.

[alexpensify]

Weekly Update: I need to bump the Slack room, no movement here yet for the retest

[alexpensify]

Weekly Update: Waiting on a retest.

[parasharrajat]

It has been quite a long time waiting for retesting. @alexpensify Could you please help to push this forward? I see no use in keeping this issue open.

[m-natarajan]

Issue is not reproducible anymore.

RPReplay_Final1718808213.MP4

[alexpensify]

Already did @parasharrajat. 😄

Thank you everyone for the help here. I'm going to close since the other GH fixed this one!