[HOLD][$250] iOS - Task - Description field not focused and keyboard not opened automatically

[lanitochka17]

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

Action Performed:

1. Open the app and log in
2. Navigate to any chat
3. Tap + > Assign task
4. Add a tittle and proceed to the confirmation
5. Select the description

Expected Result:

The description field is focused and the keyboard is opened automatically

Actual Result:

The description field is not focused and the keyboard is not opened. It takes a few taps to get the keyboard, and it can not be dismissed

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

Bug6649928_1730252709936.IMG_0770.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021851889241444905343
• Upwork Job ID: 1851889241444905343
• Last Price Increase: 2024-12-05

Issue Owner

Current Issue Owner: @hoangzinh

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[github-actions]

👋 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.

[lanitochka17]

Production:

ScreenRecording_10-30-2024.09-09-50_1.1.MP4

[Nodebrute]

Edited by proposal-police: This proposal was edited at 2024-10-30 15:03:43 UTC.

Proposal

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

Description field not focused and keyboard not opened automatically

What is the root cause of that problem?

We recently duplicated the logic of updateMultilineInputRange into useAutoFocusInput and began passing the isMultiline parameter into useAutoFocusInput to enable this logic. While we made these changes in ExitSurveyResponsePage.tsx, we haven't yet updated NewTaskDescriptionPage.tsx to reflect the latest changes.

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

remove updateMultilineInputRange usage from here

App/src/pages/tasks/NewTaskDescriptionPage.tsx

Lines 85 to 90 in 8038216

	ref={(el) => {
	if (!inputRef.current) {
	updateMultilineInputRange(el);
	}
	inputCallbackRef(el);
	}}

       ref={inputCallbackRef}

and update this line here to pass true

    const {inputCallbackRef} = useAutoFocusInput(true);

What alternative solutions did you explore? (Optional)

Or we can add here This will also fix the issue

   if (!el) {
  return;
      }

[melvin-bot]

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

[melvin-bot]

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

[Beamanator]

Calling this NAB as it's pretty easy to work around and I am going to try to get the deploy out early today

[truph01]

Edited by proposal-police: This proposal was edited at 2024-10-31 13:16:24 UTC.

Proposal

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

The description field is not focused and the keyboard is not opened. It takes a few taps to get the keyboard, and it can not be dismissed

What is the root cause of that problem?

• On the page, we have a text input and a ref which calls updateMultilineInputRange:

App/src/pages/tasks/NewTaskDescriptionPage.tsx

Lines 85 to 90 in 8038216

	ref={(el) => {
	if (!inputRef.current) {
	updateMultilineInputRange(el);
	}
	inputCallbackRef(el);
	}}

• In updateMultilineInputRange, with IOS native, we immediately focus on the input. With other platforms, we do 2 things, setting the selection to the last character and scroll the input to the last line:

App/src/libs/updateMultilineInputRange/index.ios.ts

Line 23 in 780e09e

input.focus();

• Because we focus the input too early, the input is not focused properly which I think is already a known issue which is why we delay an input focus. The similar RCA is mentioned here.

• Also, the issue can be reproduced in prod as well, not only staging, so it is not related to the recently changes in this PR.

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

• As I said above, in updateMultilineInputRange, we do 2 things, setting the selection to the last character and scroll the input to the last line. In PR, we scroll the input immediately and only setting the selection to the last character if the transition ended. It will make sure we only call focus function to focus on input if the transition ended. So we can make use of it to fix this bug.

• To do it, just need to update this:

const {inputCallbackRef} = useAutoFocusInput(true);

and this:

const {inputCallbackRef} = useAutoFocusInput(true);

What alternative solutions did you explore? (Optional)

[hoangzinh]

Thanks for the proposals, everyone. Does anyone know why it has only happened recently? I believe it worked before.

[truph01]

@hoangzinh As I mentioned, the bug appears in prod as well

[QichenZhu]

Edited by proposal-police: This proposal was edited at 2024-11-20 01:39:10 UTC.

Proposal

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

Task description field is not focused automatically on iOS.

What is the root cause of that problem?

The root cause is in 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.

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

1. There is a potential upstream fix synchronise dispatching of view commands through RuntimeScheduler facebook/react-native#47604. I tried partially backporting it to our repo and it worked. So we can put this on hold until the fix is released and then upgrade RN, or request the upstream to cherry-pick the fix into old versions.

Note

The code below is just a feasibility test, not the final version.

https://github.com/facebook/react-native/blob/2e994fdddb05955ee8dcce1e2151288977dd1c5e/packages/react-native/ReactCommon/react/renderer/scheduler/Scheduler.cpp#L328

    auto weakRuntimeScheduler =
        contextContainer_->find<std::weak_ptr<RuntimeScheduler>>(
            "RuntimeScheduler");
    auto runtimeScheduler = weakRuntimeScheduler.has_value()
        ? weakRuntimeScheduler.value().lock()
        : nullptr;
    if (runtimeScheduler) {
      runtimeScheduler->scheduleRenderingUpdate(
        [delegate = delegate_,
          shadowView = std::move(shadowView),
          commandName,
          args]() {
          delegate->schedulerDidDispatchCommand(shadowView, commandName, args);
        });
    } else {
      delegate_->schedulerDidDispatchCommand(shadowView, commandName, args);
    }

2. Also remove tons of existing focus-with-delay workarounds in our repo, as they are no longer needed.

What alternative solutions did you explore? (Optional)

The upstream bug only affects Bridgeless mode, so disabling Bridgeless by reverting 3ddc1dd could also resolve this.

[hoangzinh]

@QichenZhu Interesting! Could you elaborate more on how this issue affects our current focus logic here? Thank you

App/src/pages/tasks/NewTaskDescriptionPage.tsx

Lines 85 to 90 in a3a270d

	ref={(el) => {
	if (!inputRef.current) {
	updateMultilineInputRange(el);
	}
	inputCallbackRef(el);
	}}

[QichenZhu]

@hoangzinh On iOS, updateMultilineInputRange() calls input.focus(), which dispatches a view command from JS to the native side but fails silently because componentView is nullptr at that time.

App/src/libs/updateMultilineInputRange/index.ios.ts

Line 23 in 788939a

input.focus();

https://github.com/facebook/react-native/blob/1611a5e8a1a9a9cb7d6d9ddb4d7316d8e634e6e3/packages/react-native/React/Fabric/Mounting/RCTMountingManager.mm#L334

Though it can be easily worked around by adding a delay, I suggest fixing the root cause because:

1. We don’t expect focus() to fail silently.
2. If it fails silently, the JS side isn’t aware and optimistically sets the internal status as focused, causing future programmatic focus attempts to fail as well.

https://github.com/facebook/react-native/blob/0705eb8b91b6c3688a73f8481c6b067899ac6eec/packages/react-native/Libraries/Components/TextInput/TextInputState.js#L62

https://github.com/facebook/react-native/blob/0705eb8b91b6c3688a73f8481c6b067899ac6eec/packages/react-native/Libraries/Components/TextInput/TextInputState.js#L106

(More details can be found in upstream issues: facebook/react-native#47359 and facebook/react-native#47576.)

[hoangzinh]

Thanks for explanation @QichenZhu. I tried to apply your suggestion here but it doesn't work for me. Do I miss anything else?

Screen.Recording.2024-11-20.at.00.36.55.mov

[QichenZhu]

@hoangzinh The code in your video is the same as mine, but the filename in the second line is strange.

Before

Screen.Recording.2024-11-20.at.2.49.19.PM.mp4

After

Screen.Recording.2024-11-20.at.2.58.55.PM.mp4

[hoangzinh]

oh right, it works on my device. @QichenZhu proposal looks good to me. Let's wait internal engineer's decision on either waiting for upgrade React native or making a patch to our app.

Link to proposal #51728 (comment)

🎀👀🎀 C+ reviewed

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

@nkuoch, @hoangzinh, @sonialiap Huh... This is 4 days overdue. Who can take care of this?

[hoangzinh]

cc @nkuoch waiting on your next review round

[melvin-bot]

@nkuoch @hoangzinh @sonialiap this issue is now 4 weeks old, please consider:

• Finding a contributor to fix the bug
• Closing the issue if BZ has been unable to add the issue to a VIP or Wave project
• If you have any questions, don't hesitate to start a discussion in #expensify-open-source

Thanks!

[nkuoch]

Let's hold for react native update

[melvin-bot]

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

[sonialiap]

@nkuoch do you have a link to an issue that I can track for the hold?

[nkuoch]

#48911

[melvin-bot]

@nkuoch, @hoangzinh, @sonialiap Eep! 4 days overdue now. Issues have feelings too...

[melvin-bot]

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

[hoangzinh]

@nkuoch can you help to put Hold title to this GH issue too? :thankyou:

[QichenZhu]

Update: The upstream team has decided not to include the fix in React Native 0.76.

I noticed others are working on #54755 and #54759, so we can see if that solves the problem.

[hoangzinh]

Thank you @QichenZhu