You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[HOLD for payment 2024-11-29] [$250] Search - The cursor is displayed on different sides in the search text box #52382
Version Number: 9.0.60-0 Reproducible in staging?: Y Reproducible in production?: 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/5200040 Issue reported by: Applause Internal Team
Action Performed:
Sign in to the STG website with a Gmail account.
Tap on the search icon in the top right corner.
Expected Result:
The cursor must always appear at the beginning of the search text box.
Actual Result:
The cursor is displayed inconsistently on several sides of the search box each time the function is opened.
Issue happens only on iOS mWeb/Chrome.
Please re-state the problem that we are trying to solve in this issue.
The caret of the input is on the right. In my cases, it's moves to the left at the end.
What is the root cause of that problem?
I remember we had this kind of issue before on iOS safari which happens when we auto focus immediately while the input is sliding. I don't remember which issue that is, but if I remember correctly, they fix it by adding a delay. From my testing, this happens specifically because of the list heavy rendering which interrupt the caret moving. If we remove the list, then everything is smooth.
changed the title [-]Search - The cursor is displayed on different sides in the search text box[/-][+][$250] Search - The cursor is displayed on different sides in the search text box[/+]on Nov 13, 2024
[Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source 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: n/a
[Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.
Regression Test Proposal Template
[BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.
True, I think what I'm trying to capture though is... was the bug found as part of the regression testing during a deploy, or was the bug released to production and then someone found it in production?
i think it's fine but maybe remove the (deploy blocker) suffix because it's a little misleading as in this case it was reported on staging but not a deploy blocker since it was found testing another flow
Activity
melvin-bot commentedon Nov 12, 2024
Triggered auto assignment to @jliexpensify (
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.bernhardoj commentedon Nov 12, 2024
Proposal
Please re-state the problem that we are trying to solve in this issue.
The caret of the input is on the right. In my cases, it's moves to the left at the end.
What is the root cause of that problem?
I remember we had this kind of issue before on iOS safari which happens when we auto focus immediately while the input is sliding. I don't remember which issue that is, but if I remember correctly, they fix it by adding a delay. From my testing, this happens specifically because of the list heavy rendering which interrupt the caret moving. If we remove the list, then everything is smooth.
App/src/components/Search/SearchRouter/SearchRouter.tsx
Lines 392 to 418 in cd3f30f
What changes do you think we should make in order to solve the problem?
I'm trying to improve the performance, but no luck. In the meantime, we can hide the caret of the textinput while the modal is animating.
App/src/components/Search/SearchRouter/SearchRouterInput.tsx
Lines 83 to 87 in 9b62f29
What alternative solutions did you explore? (Optional)
Remove the autoFocus props and delay the focus by using
useAutoFocusInputhook.App/src/components/Search/SearchRouter/SearchRouterInput.tsx
Lines 83 to 87 in 99da1ac
jliexpensify commentedon Nov 13, 2024
ios <> Android swap
[-]Search - The cursor is displayed on different sides in the search text box[/-][+][$250] Search - The cursor is displayed on different sides in the search text box[/+]melvin-bot commentedon Nov 13, 2024
Job added to Upwork: https://www.upwork.com/jobs/~021856557909155722434
melvin-bot commentedon Nov 13, 2024
Triggered auto assignment to Contributor-plus team member for initial proposal review - @s77rt (
External)31 remaining items
s77rt commentedon Nov 24, 2024
BugZero Checklist:
Bug classification
Source of bug:
Where bug was reported:
Who reported the bug:
[Contributor] 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: Add SearchRouter component and context to display it #48785 (comment)
[Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source 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: n/a
[Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.
Regression Test Proposal Template
[BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.
Link to issue:
Regression Test Proposal
Precondition:
Test:
Do we agree 👍 or 👎
kadiealexander commentedon Nov 29, 2024
Payouts due:
bernhardoj commentedon Nov 29, 2024
Requested in ND.
JmillsExpensify commentedon Nov 29, 2024
$250 approved for @s77rt
tgolen commentedon Dec 2, 2024
@s77rt Thanks for classifying the bug!
For this one:

It really should have been marked as staging (or at least staging+prod, but that option might be going away soon).
You can see from the original description it was reproduced on both environments, and the screenshots show it was found on staging.
s77rt commentedon Dec 2, 2024
@tgolen If it's reproducible on production, it's reproducible on staging. Otherwise we'd close the issue.
tgolen commentedon Dec 2, 2024
True, I think what I'm trying to capture though is... was the bug found as part of the regression testing during a deploy, or was the bug released to production and then someone found it in production?
tgolen commentedon Dec 2, 2024
Maybe the prompts should be reworded?
s77rt commentedon Dec 2, 2024
Ah totally my bad. I just realised it said reported. I have been reading this as reproduced for a while 😅
s77rt commentedon Dec 2, 2024
i think it's fine but maybe remove the
(deploy blocker)suffix because it's a little misleading as in this case it was reported on staging but not a deploy blocker since it was found testing another flowJmillsExpensify commentedon Dec 5, 2024
$250 approved for @bernhardoj