[HOLD for payment 2024-07-24] [$250] [Critical] [UX Reliability] Input in the pushed in page moves around causing wrong message typed

[mountiny]

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: 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 Expensify/Expensify Issue URL: Issue reported by: @mountiny
Slack conversation: https://expensify.slack.com/archives/C05LX9D6E07/p1718793199252419

Action Performed:

Break down in numbered steps

There is many flows where this can be experienced. Wherever we push a page with input to autofocus. In this video I have:

1. Go to workspace chat
2. Submit expense
3. Scan a receipt
4. Click on Description row
5. Start typing quickly

Expected Result:

Describe what you think should've happened

The message you type is correctly applied

Actual Result:

Describe what actually happened

It seems like after first of second character the cursor jumped to the front of the input

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Platforms:

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

• [ ] Android: Native
• [ ] Android: mWeb Chrome
• [x] iOS: Native
• [ ] iOS: mWeb Safari
• [ ] MacOS: Chrome / Safari
• [ ] MacOS: Desktop

Screenshots/Videos

https://github.com/Expensify/App/assets/36083550/c4f61ccc-075d-4ee4-87e2-a2fd4102c150

he logs and traces are in slack convo Add any screenshot/video evidence

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~013581c71c8dab48d3
• Upwork Job ID: 1803380011113187610
• Last Price Increase: 2024-07-03

Issue Owner

Current Issue Owner: @muttmuure

[melvin-bot[bot]]

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

[hannojg]

👋

[melvin-bot[bot]]

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

[melvin-bot[bot]]

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

[hannojg]

No new update yet here specifically. The problem basically being similar to the one in:

• https://github.com/Expensify/App/issues/37896

so we want to tackle that issue first

[hannojg]

Still prioritising the aforementioned issue - do we want to put this one on hold for the other issue?

[jacobkim9881]

@hannojg 😃 I found a cause for the issue but it seems the issue's root cause is from other repository. I would like to report.

[hannojg]

Sure, feel free to share what you've found

[jacobkim9881]

https://github.com/Expensify/App/blob/c0d3e79466d7b6abde4409a9247cccd55f579f0e/src/pages/tasks/TaskDescriptionPage.tsx#L125

I found the issue noticeably decreased after off the props. And the props activate a component from other repository, which somebody can handle.

[jacobkim9881]

Which decides a comp between 2:

https://github.com/Expensify/App/blob/7eeede6ea989c653ea92506d84d7aa053ccd2a4a/src/components/TextInput/BaseTextInput/index.native.tsx#L71

And RNMarkdownTextInput comp is from @expensify/react-native-live-markdown that is from other. Shame I couldn't PR!

[hannojg]

Okay, so it seems that you pined the issue down to react-native-live-markdown. Great, thanks for the insight!

Two things I want to let you know about:

• At Expensify we want to fix the problems "upstream" and actively contribute to the open source space. That means we don't stop when we found an issue in an open source library, letting it fix someone else. We contribute to the project, by figuring out what the problem is. So the next step here is to look into the code of react-native-live-markdown and fix the bug! 😊
• react-native-live-markdown is a library owned and developed by expensify (in partnership with SWM). So you can think of react-native-live-markdown being another folder in the expensify app.

What I am trying to say is that we need to continue to investigate whats exactly causing the issue when using react-native-live-markdown. (This is something I have on my todo list now, as the issue is assigned to me).

[hannojg]

What do you mean by

Shame I couldn't PR!

there is nothing stopping from you from checking out the code of react-native-live-markdown 😊

[jacobkim9881]

Okay, so it seems that you pined the issue down to react-native-live-markdown

Yes. I assume we can find the root cause from there 😃 So we can continue to found the issue upstream! So we still have more chances to fix. That's nice!

react-native-live-markdown is a library owned and developed by expensify (in partnership with SWM). So you can think of react-native-live-markdown being another folder in the expensify app.

So it would be easy to get helps since it's partner shipped with SWM. That's cool! I found it in node_modules.

[jacobkim9881]

there is nothing stopping from you from checking out the code of react-native-live-markdown 😊

Would like to continue 😄

[jacobkim9881]

So I found performance better noticeably in the input tag without this comp:

https://github.com/Expensify/react-native-live-markdown/blob/d05065948bf36414705fe9148b25686adfab2181/src/MarkdownTextInput.tsx#L53-L55

which uses this: https://github.com/Expensify/react-native-live-markdown/blob/d05065948bf36414705fe9148b25686adfab2181/src/MarkdownTextInputDecoratorViewNativeComponent.ts#L4

The only comp used is from react-native. I can continue though it's from another repo? 😄

[mountiny]

Hey @jacobkim9881! thanks for help on this one. I recommend you to first read through the contributing guidelines we have for the Expensify App repo https://github.com/Expensify/App/blob/main/contributingGuides/CONTRIBUTING.md. We have a format for new proposals which you should use if you want to submit a proposal.

If the issue is in the https://github.com/Expensify/react-native-live-markdown/blob/d05065948bf36414705fe9148b25686adfab2181/src/MarkdownTextInputDecoratorViewNativeComponent.ts#L4 you can also submit a proposal here with clearly identifying the rootcause and how you propose to fix it. If that will be correct, you can do the work and get paid for it through Upwork. Thanks!

[jacobkim9881]

Hey, @mountiny! Thank you for the guidance! Let me give proposals to issues in other time.

you can also submit a proposal here with clearly identifying the rootcause

I would like to submit proposals if I find the solution. Thanks for letting me know again!

[jacobkim9881]

@mountiny I have a question. If I contribute in anyway, is there a chance I can get paid? Though I couldn't get paid, am happy to be helped in anyway!

[melvin-bot[bot]]

@hannojg, @mountiny, @muttmuure, @mkhutornyi Eep! 4 days overdue now. Issues have feelings too...

[mountiny]

If you substantially help to find the root cause of this issue (by pinpointing the line causing the issue and how to fix it for example), we usually issue partial payment even if you do not fix the issue yourself.

[jacobkim9881]

@mountiny Thanks for the answer! That sounds sweet. Hope I can fix or find root causes next time.

[BartoszGrajdek]

I believe this issue could be related to live markdown. @mountiny can we add it temporarily to the Live Markdown project? I'll try to revisit it later this week to at least pinpoint the root cause if no one finds it.

[mountiny]

Added it to the project, but I think this is urgent issue enough to still deserve daily updates if possible

[BartoszGrajdek]

Agreed, I'll also try working on it tomorrow! 👀

[mkhutornyi]

Not overdue

[melvin-bot[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[bot]]

@hannojg, @mountiny, @muttmuure, @mkhutornyi Eep! 4 days overdue now. Issues have feelings too...

[mkhutornyi]

Same

[BartoszGrajdek]

Hi! Sorry for the delay, but I had a couple of other tasks at hand. 🙇🏻

I tried reproducing this issue but didn't manage to. I've tested it with several iOS simulators (iOS 16.0-17.5).

@mountiny can you confirm if this is still reproducible for you? If so do you mind sharing what device & iOS version are you using? 🙏🏻

Looking into the problem specifically - it's very similar to some of the bugs we've had before in composer & it most likely stems from E/App code itself not react-native-live-markdown lib, but I'm not 100% till I'm able to reproduce it. 👀

[hannojg]

(I should be done with my other task today and then can start looking into this as well!)

[melvin-bot[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[bot]]

@hannojg @mountiny @muttmuure @mkhutornyi this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[hannojg]

Alright, sorry guys, today is the day - just started looking into the issue!!

[hannojg]

Note: I also wasn't able to reproduce on the simulators either, but was on a physical device. You may not see it in the video immediately but the first character I typed was an N and then an a which then got deleted. So it seems like the selection / value of the input are being reset for some reason. Looking into it!

https://github.com/Expensify/App/assets/16821682/113b53bd-0a37-48e1-a82d-e0f8e3e0a84e

[hannojg]

Update: I pinpointed the issue to react-native-live-markdown and specifically this code:

https://github.com/Expensify/react-native-live-markdown/blob/5d4e1060d79ba12dec052e295c16541bf9f0aec0/ios/MarkdownCommitHook.mm#L115-L186

I completely commented out all code in MarkdownTextInputDecoratorComponentView, so it's not that. When disabling the code shown above the bug doesn't happen.

If I have to guess I say there might be a race condition between the user typing new text and us updating the shadow node with stale data by then. Have to look more detailed into what could cause the bug tomorrow to come up with a fix.

Probably also good to discuss with your team @BartoszGrajdek @tomekzaw

Here is a screenshot of the text updates in the commit hook, looks like we operate on some stale data. This is me trying to type Hallo:

As in the logs visibly in the UI I see:

1. "H"
2. ""
3. "H"
4. "A"
5. "Al"
6. ...
7. "Allo"
8. "All"
9. "Allo"

Although I typed "Hallo" in one go

[tomekzaw]

cc-ing @j-piasecki who's the man behind clever MarkdownCommitHook

[mountiny]

Thanks for pushing this ahead Hanno! I am still able to reproduce on physical device

[hannojg]

Okay, I found a fix for this, lets discuss if you agree @j-piasecki 😊 :

The issue is very specifically on this line:

https://github.com/Expensify/react-native-live-markdown/blob/5d4e1060d79ba12dec052e295c16541bf9f0aec0/ios/MarkdownCommitHook.mm#L143-L151

The problem is that it not only runs on the first render, but every time there is a mismatch between the props and the native state (and the AttributedStringBox::Mode::Value). Lets imagine the following flow:

• Value prop is ""
• User types "H"
• native dispatches an event to JS that text changed to "H"
• The commit hook gets triggered, sees that the state is "H" but the prop is still "" (as the event hasn't reached JS yet), so it sets the value back to ""
• The "H" I just typed got deleted
• (Later the JS eventually receives the "H")

Note: There are multiple flows to this race condition.

You can see one example here:

The fix from my perspective is to really only run this code on the first render. Borrowing from TextInputShadowNode we can add a check like textInputState.getRevision() == State::initialRevisionValue to the if condition.

With this in place I can't reproduce the bug:

https://github.com/Expensify/App/assets/16821682/7cb22d52-c6d9-4e3e-bb99-37d0bd01e6c9

• I will create a PR with a patch so vit can test
• I will create an issue and PR in rn-live-markdown:
  • https://github.com/Expensify/react-native-live-markdown/pull/419

[hannojg]

I think btw this is also the reason we are seeing this bug:

• https://github.com/Expensify/App/issues/44185

[mountiny]

Great job @hannojg as always, looking forwards the PR with the patch so we can make a build for testing

[hannojg]

Draft PR is here @mountiny

• https://github.com/Expensify/App/pull/44913

In this PR I bumped rn-live-markdown as SWM already merged the PR. Let me know if that works, because there is another PR for bumping rn-live-markdown first where a few bugs have been addressed (so that one needs to be merged first, I linked it in the PR)

[tomekzaw]

cc-ing @Skalakid and @BartoszGrajdek here as one of the recently merged PRs to live-markdown turns out to cause a regression on web and they should have the context

[hannojg]

Note: the fix was implemented in rn-live-markdown and we are waiting for this PR to be merged to fix it:

• https://github.com/Expensify/App/pull/44958

[melvin-bot[bot]]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot[bot]]

The solution for this issue has been :rocket: deployed to production :rocket: in version 9.0.7-8 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:

• https://github.com/Expensify/App/pull/44958

If no regressions arise, payment will be issued on 2024-07-24. :confetti_ball:

For reference, here are some details about the assignees on this issue:

• @hannojg does not require payment (Contractor)
• @mkhutornyi requires payment (Needs manual offer from BZ)

[melvin-bot[bot]]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [ ] [@mkhutornyi] The PR that introduced the bug has been identified. Link to the PR:
• [ ] [@mkhutornyi] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [ ] [@mkhutornyi] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [ ] [@mkhutornyi] Determine if we should create a regression test for this bug.
• [ ] [@mkhutornyi] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [ ] [@muttmuure] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[melvin-bot[bot]]

Payment Summary

Upwork Job

• Contributor: @hannojg is from an agency-contributor and not due payment
• ROLE: @mkhutornyi paid $(AMOUNT) via Upwork (LINK)

BugZero Checklist (@muttmuure)

• [ ] I have verified the correct assignees and roles are listed above and updated the neccesary manual offers
• [ ] I have verified that there are no duplicate or incorrect contracts on Upwork for this job (https://www.upwork.com/ab/applicants/1803380011113187610/hired)
• [ ] I have paid out the Upwork contracts or cancelled the ones that are incorrect
• [ ] I have verified the payment summary above is correct

[mountiny]

@mkhutornyi can you please summarize the payment here? which PRs did you review?

[melvin-bot[bot]]

@hannojg, @mountiny, @muttmuure, @mkhutornyi Whoops! This issue is 2 days overdue. Let's get this updated quick!