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
`PerAccountStore` shouldn't be an owner of the `MessageListView`
objects.
Its relationship to `MessageListView` is similar to that of
`AutocompleteViewManager` to `MentionAutocompleteView` (zulip#645).
With two owners, `MessageListView` can be disposed twice:
1. Before the frame is rendered, after removing the `PerAccountStore`
from `GlobalStore`, `removeAccount` disposes the `PerAccountStore` ,
which disposes the `MessageListView` (via `MessageStoreImpl`).
`removeAccount` also notifies the listeners of `GlobalStore`.
At this point `_MessageListState` is not yet disposed.
2. Being dependent on `GlobalStore`, `PerAccountStoreWidget` is rebuilt.
This time, the StatefulElement corresponding to the `MessageList`
widget, is no longer in the element tree because `PerAccountStoreWidget`
cannot find the account and builds a placeholder instead.
3. During finalization, `_MessageListState` tries to dispose the
`MessageListView`, and fails to do so.
We couldn't've kept `MessageStoreImpl.dispose` with an assertion
`_messageListView.isEmpty`, because `PerAccountStore` is disposed before
`_MessageListState.dispose` (and similarily
`_MessageListState.onNewStore`) is called. Fixing that will be a future
follow-up to this, as noted in the TODO comment.
A regression test for zulip#810 has been appropriated. The original issue
is relevant because the scenario this integration test targeted still
applies after this change.
See discussion:
https://chat.zulip.org/#narrow/channel/243-mobile-team/topic/MessageListView.20lifecycle/near/2083074
Signed-off-by: Zixuan James Li <[email protected]>
0 commit comments