Triggered auto assignment to @puneetlath (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

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

💬 A slack conversation has been started in #expensify-open-source

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

@chrispader @kirillzyusko @hannojg something to look into, i dont think this is a blocker so demoted.

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

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

I can reproduce. It seems related to FE, looking for proposals.

Proposal

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

The input field for the message to invite workspace members doesn’t auto-focus.

What is the root cause of that problem?

The updateMultilineInputRange() function tries to focus the input but fails silently due to a known React Native bug.

Details can be found in the upstream issue facebook/react-native#47576.

In the new architecture, native view commands are dispatched immediately to the UI thread

But mounting operations are only flushed at the end of the current task in the event loop / runtime scheduler

That causes problems when invoking native view commands on views that were just created

On Android, this works correctly because we queue the native view command in the same queue as mount operations, so they're always processed in the right order.

This shares the same cause as #51728.

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

Like #51728, I suggest holding this for React Native upgrade, as this doesn't affect the app's functionality.

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

There is no need to add tests, as this is caused by an upstream bug.

What alternative solutions did you explore? (Optional)

A number of similar issues are worked around by focusing with a delay, which is already implemented in the useAutoFocusInput hook. However, it doesn't work currently because the first failing focus attempt causes future programmatic focus to fail as well. To make useAutoFocusInput work, we need to empty the updateMultilineInputRange() function on iOS.

const updateMultilineInputRange: UpdateMultilineInputRange = (input, shouldAutoFocus = true) => {/* Do nothing */}

Thank you for the proposal, @QichenZhu. I think your RCA makes sense, and holding for the RN upgrade isn’t a bad idea. I tested your alternative solution, and it fixes the issue, but I haven’t checked for regressions elsewhere. @puneetlath, could you advise on the next steps? Thank you!

🎀👀🎀 C reviewed

Current assignee @puneetlath is eligible for the choreEngineerContributorManagement assigner, not assigning anyone new.

Thank you @QichenZhu for a proposal

I like it and I think we can go with that. The only thing that we need to come to agreement is whether we should wait for next RN upgare (will it be fixed in 0.76) or we need to create a workaround/fix and remove it when update to RN 0.76 will happen?

Thanks for the feedback! The fix will be released in 0.77. We can also submit a pick request to ask them to include it in older versions like 0.75 or 0.76 if needed.

Well, I think it's up to Expensify team on which approach to choose.

One thing I can say from my side is that we are still on RN 0.75 and have a pending PR with RN 0.76, so if the fix is available only in RN 0.77 then I think it may take up to several months to close this issue 👀

P. S. just had a look on PR with the fix - @QichenZhu can't we apply these changes as a patch? I think we are building from sources, so c code shouldn't be a problem? Or are you aware about potential issues/problems?

can't we apply these changes as a patch?

@kirillzyusko Yes, it’s possible.

I’ve tried to backport the fix to 0.75 and drafted a patch in my proposal for another issue.

Since 0.75 and 0.77 span two major versions and this involves changes to the scheduler, it will need thorough testing.

I think it would be safer to patch 0.76, which is closer to 0.77, or we could request the RN team to handle it.

Let’s wait for the Expensify team’s decision.

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

Not overdue, just waiting for Puneet's review.

Is this the only flow that is affected by this bug? If so, it feels not really worth patching to me and it'd be fine to wait for the fix to go-live upstream.

Is this the only flow that is affected by this bug? If so, it feels not really worth patching to me and it'd be fine to wait for the fix to go-live upstream.

I think there are others, like this one, mentioned by @QichenZhu, but also on hold for the React Native 0.76 upgrade. I think it’s worth holding here as well. I’ll keep an eye on this and test the issue afterward. Thought @sakluger @puneetlath?

That sounds good to me. I put it on hold.

Still on hold for Upgrade to React Native 0.76