[Search v2.2] mWeb/Chrome Search-Navigate back to the top of messages instead of the selected message

[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.41
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Issue reported by: Applause - Internal Team

Issue found when executing PR #49641

Action Performed:

1. Go to Search option from bottom tab
2. Tap on "Chat" type from LHP
3. Tap on any message from the rendered results
4. When the chat is opened, refresh the browser
5. Tap on the back button

Expected Result:

The app goes back to the message I tapped on before

Actual Result:

The app redirects to the top of messages instead of returning to the previously selected message

Workaround:

Unknown

Platforms:

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

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6618990_1727574225145.49641-mWeb.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @trjExpensify (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]

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

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

[luacmartins]

I think we can demote this to NAB

[cdOut]

Hi, I'm Tymoteusz from Software Mansion and I worked on search-related issues before, I will gladly work on this one.

[cdOut]

Would we want to scroll to the exact same position or would scrolling to the selected chat report be sufficient?

[luacmartins]

I think we'd want to scroll to the selected message

[lakchote]

Not overdue @cdOut is working on this.

[lakchote]

Latest update is here.

[lakchote]

@cdOut how is it going?

[cdOut]

Sorry for the late update, I've had to go back to my other ongoing issues with Guided Setup that have higher prio after some backend changes were merged for them. I'll update later today or early tomorrow with the state of the PR for this issue.

[lakchote]

@cdOut friendly bump

[cdOut]

Here's the update, I've created a POC to check whether to only utilize the selected message link id or to save the offset in session storage. I'm currently testing whether we don't have any possible situations where we lose the saved onyx search data after reload so we wouldn't be able to scroll to an unloaded item. Will report back tomorrow.

[melvin-bot]

@lakchote, @cdOut Whoops! This issue is 2 days overdue. Let's get this updated quick!

[cdOut]

There was a bunch of new code that is also plugged into the SelectionList ref so I had to refactor it quite a bit, draft should be ready early next week.

[lakchote]

Draft by @cdOut should be ready early this week.

[melvin-bot]

@lakchote, @cdOut Whoops! This issue is 2 days overdue. Let's get this updated quick!

[lakchote]

@cdOut any update for the draft PR?

[Kicu]

@lakchote hey! Sorry for the delays here, someone else will take over the task, read through the partial solution that @cdOut left and push this forward.

I will write an update by eod today.

[289Adam289]

Hi! I can take over this task. Please assign me

[Kicu]

@lakchote @luacmartins

We spent a bit of time looking at this task with @289Adam289 and we have some considerations, mainly a question: is this really a bug?

reasoning 1

In general preserving scroll position on a webpage after full refresh is not so obvious.
We are lazy loading data in Search, which means that before clicking on a report you might've scrolled down to for example search result number 200+.
After user clicks report, and then hits "refresh", then clicks back button on the report what should happen? should we somehow make sure that the same 200 search items are fetched?

I personally as a user of websites would not expect that, after refreshing page with lazy loaded data, that my scroll will be preserved.

reasoning 2

In addition to above, we tried to find a similar pattern in E/App and we couldn't find cases where scroll position would be preserved like this.
Please as an example take a look that the exact same behaviour happens on chat list page.

scroll not preserved after refresh on chat list

Screen.Recording.2024-11-04.at.16.54.25.mov

[luacmartins]

Those are really good points @Kicu. I agree with those and as such, I think we can just close this issue. @lakchote what do you think?

[luacmartins]

I'm gonna close this issue for now. Please reopen if needed.