Fix forum topic read state on close - #13
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a6a26cfc92
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (messageViewer != null && canRead()) { | ||
| loader.viewport().viewMessages(false, true, null); |
There was a problem hiding this comment.
Respect focus before forcing topic reads
When prepareForTopicSwitch() is invoked while the controller is unfocused, this direct call bypasses the viewport callback's allowViewRequest() check and marks every tracked message as read because canRead() does not test focus. This can occur, for example, when the asynchronous DeleteForumTopic response in MessagesController calls setForumTopic(null) after the user has already navigated away, potentially marking messages loaded while the screen was in the background as read. Guard the forced submission with the manager's focused state while retaining it for the blur/destroy paths, which deliberately flush before clearing that state.
Useful? React with 👍 / 👎.
Причина
При потере фокуса
MessagesManagerсначала выставлялisFocused = false, а затем пытался сохранить состояние. Из-за проверокallowViewRequest()иsaveScrollPosition()финальныйViewMessagesи topic-specific scroll anchor отбрасывались.Кроме того, viewport мог уже снять флаг
recentпосле асинхронного запроса, поэтому повторный flush не всегда включал видимые сообщения.Исправление
forceRead=trueПроверка
git diff --check