[$250] Editing a comment: the cursor is jumping to the end of the message when we type in the middle of the text making it impossible to edit the text

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number:
Reproducible in staging?: Needs Reproduction
Reproducible in production?: Needs Reproduction
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?:
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: @mountiny @quinthar
Slack conversation (hyperlinked to channel name): expensify_bugs

Action Performed:

1. Write a message and send it
2. Go edit the message
3. Move the cursor to the middle of the text
4. Start to type

Expected Result:

User able to type where the cursor

Actual Result:

The cursor jumps to the end of the text after a first character

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

Screen.Recording.2024-12-18.at.15.15.47.mov

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021869733355861718010
• Upwork Job ID: 1869733355861718010
• Last Price Increase: 2024-12-19

Issue Owner

Current Issue Owner: @ntdiary

[MelvinBot]

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

[melvin-bot]

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

[allroundexperts]

Seems related to the grammar extension that they're using.

[mountiny]

I do have Grammarly installed

[allroundexperts]

Can you try without that?

[mountiny]

I dont know how to write without that

[mountiny]

I cannot reproduce it now even with it on, so I will keep monitoring if it happens again

[m-natarajan]

@mountiny @allroundexperts Able to reproduce this issue in production

Recording.860.mp4

[bernhardoj]

I think this is the same as this one

[melvin-bot]

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

[melvin-bot]

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

[mountiny]

Based on QA this is reliably repro on new accounts https://expensify.slack.com/archives/C049HHMV9SM/p1734614105597379?thread_ts=1734531561.566439&cid=C049HHMV9SM

[mountiny]

Marking this as CRITICAL quality issue as it makes the UX really bad

[ntdiary]

Marking this as CRITICAL quality issue as it makes the UX really bad

@mountiny, If this is urgent, please feel free to reassign another c+. :)

[mountiny]

Thanks! SWM will have a look in the mean time 🙌

[tomekzaw]

Someone from SWM will take a look at this shortly cc @BartoszGrajdek @Skalakid

[allroundexperts]

I can take this as I have context on it already!

[tomekzaw]

Cannot reproduce this both on new.expensify.com and staging.new.expensify.com, both on Chrome and Safari on macOS.

[Skalakid]

Are there any additional steps that we need to do to reproduce that? On which browser does it occur?

[bernhardoj]

This is the same issue with a better repro step (and I had a proposal there).

[mountiny]

@bernhardoj can you move the proposal over here? Seems like it has stalled in that issue

[bernhardoj]

Proposal

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

The cursor is at the beginning of the message if we open the admins room from the workspace profile page.

What is the root cause of that problem?

The root cause of the issue is similar to #46095. This is caused by the active focus traps that prevents the focus event to be received by the composer. You can read more detail on that root cause here.

The different thing in this issue is, we already pause the focus trap if the screen isn't focused.

App/src/components/FocusTrap/FocusTrapForScreen/index.web.tsx

Line 41 in 8981081

paused={!isFocused}

In this case, the screen that has the active focus trap is the workspace full screen navigator. When we open the workspace profile share page, the workspace full screen navigator focus trap is paused. When we click the #admins room link, the RHP is closed and focus trap automatically unpause the previous focus trap, which is the workspace full screen navigator focus trap.
https://github.com/focus-trap/focus-trap/blob/f85c73ac36553d952a8e03d1033b35544247caa0/index.js#L28-L36
https://github.com/focus-trap/focus-trap/blob/master/CHANGELOG.md#400

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

We don't want the workspace full screen navigator focus trap to be unpaused when the RHP is closed because the screen is still blurred. We have 2 options.

First, instead of pausing the focus trap when the screen is blurred, we can deactivate it. We can return isFocused here (or we can do it only for FullScreenNavigator to be very safe).

App/src/components/FocusTrap/FocusTrapForScreen/index.web.tsx

Lines 35 to 36 in 8981081

	return true;
	}, [isFocused, shouldUseNarrowLayout, route.name, focusTrapSettings?.active]);

If the focus trap is deactivated, unpause doesn't do anything.
https://github.com/focus-trap/focus-trap/blob/f85c73ac36553d952a8e03d1033b35544247caa0/index.js#L1037-L1040

Second, we can add a new option to the focus-trap repo to not automatically pause/unpause the focus-trap when a focus-trap is activated/deactivated.

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

N/A

[ntdiary]

I can take this as I have context on it already!

@allroundexperts, If you’re still available, please feel free to take it over. :D

[allroundexperts]

Yep, thank you. @mountiny can you assign this to me?

[mountiny]

How does the @bernhardoj proposal look like! @allroundexperts @tomekzaw @Skalakid

[melvin-bot]

@allroundexperts, @stephanieelliott, @mountiny Whoops! This issue is 2 days overdue. Let's get this updated quick!

[allroundexperts]

@bernhardoj's proposal looks good to me. I prefer going via the second route, but I am not sure if we want to wait too much.

[mountiny]

Thanks @bernhardoj Can you please work on the implementation?

The focus-trap repository does not look like a repo that would frequently handle PRs from the community. I agree it would be nice to have this fixed upstream. Can you please look into this as a follow up (first lets fix this in App) and then try to propose your fix in the upstream repo and hope it would get accepted?

Thanks!

[bernhardoj]

PR is ready

cc: @allroundexperts

I'll open the upstream PR later and link it on the App PR. Done

[stephanieelliott]

Hey @bernhardoj cross posting @allroundexperts comment from the PR -- can you give an ETA on when you'll be able to address this? This is a critical bug, so we are trying to get it unblocked ASAP:

@bernhardoj Can you maybe try to merge main and then we can trigger a rebuild? It's not working for me on Android web.

[stephanieelliott]

Hey @bernhardoj bump on the above ^^

[bernhardoj]

Sorry, I was OOO, addressed the comment.