narrow: Fix combined feed selecting random messages on narrow.

[amanagr]

Opened for further discussion after #30008 (comment)

#30008 (comment) still needs to be fixed.

https://chat.zulip.org/#narrow/stream/6-frontend/topic/fetching.20message.20history

Reproducer:

• Have some unreads in the Combined feed view.
• Scroll up and select a message that was not part of initial fetch.
• Reload.
• Go a another narrow.
• Come back to combined feed to find your at a random message. This message is actually last message of the current fetch of combined feed view which was returned via first_unread_message_id.

[sentry-io]

🔍 Existing Issues For Review

Your pull request is modifying functions with the following pre-existing issues:

📄 File: web/src/narrow.js

Function	Unhandled Issue
activate	TypeError: this[0] is undefined get_offset_to_win... Event Count: 5 Affected Users: 2

---

_{Did you find this useful? React with a 👍 or 👎}

[timabbott]

Can you explain the consequences of removing it from $list and deleting it from rendered_message_lists? Will it get added back to that structure if visited again later?

[timabbott]

OK, read this more, and I understand rendered_message_lists.delete; I see that we'll potentially save this replaced message list for the combined feed. But not sure I understand the other half of what msg_list.view.$list.remove(); does.

[amanagr]

    // Since we change `current` message list in the function, we need to decide if the
    // current message list needs to be cached or discarded. 
    // 
    // If we are caching the current message list, we need to remove any other message lists
    // that we have cached with the same filter. 
    //
    // If we are discarding the current message list, we need to remove the
    // current message list from the DOM.

Added this comment at the top of the function.

[timabbott]

OK, but here's what I don't understand: What happens when we visit the Combined Feed at some future point after doing that rendered_message_lists.delete operation? Does it just populate its message_list_data object from all_messages_data just like the very first time and end up in the same state as if we'd not done these deletions, or are there potential weirder consequences?

[amanagr]

So, in that case we have combined feed with first_unread cached as we only delete when we are preserving another list.

• If user just clicks on combined feed in left sidebar, we narrow to first unread.
• If user clicks browser back / escape key, we narrow with a then_select_id. If cached list.msg_id_in_fetched_range(opts.then_select_id), then we use the cached list, otherwise we try to populate a new list like any other. That would involve looking at all_messages_data to see if it has the then_select_id.

[amanagr]

Let me work a bit on #30008 (comment) and maybe there is a better solution here we can use.

[timabbott]

Is the next step to rework this following #30060 to reuse that code path?

[amanagr]

Is the next step to rework this following #30060 to reuse that code path?

Yeah, updated to use first_unread_unmuted_message_id.

[amanagr]

Pushed to resolve conflicts.

[timabbott]

OK, I think this is correct; this code path feels very hard to understand, and I suspect there's a way to make it cleaner, but that can come as part of work on next transitions like #15131.