Previously, if the client recieved an "update_messages" event with
"message_id" not present locally, then the event was completely
ignored. But, this can happen when moving messages especially
when doing a partial move due to time limit error.
This commit updates the code to have the code which requires the
message to be present locally run only if it is present instead
of just ignoring the event completely such that the updates for
moving the messages can be done.
Previously, we didn't notify the starred messages code path when
processing the event that a message was deleted, resulting in the
displayed counter potentially being stale until the app is reloaded.
Fixes#25190.
The logic for whether one needs to scroll down to view messages sent
by the current client was incorrectly not checking whether a message
feed was visible at all.
This replaces one of the our larger remaining blocks of code with
explicit logic for message_lists.home with logic that should correct
if we support maintaining a different set of rendered message lists.
This should have identical behavior to the previous implementation
given that all_rendered_message_lists is either just
message_lists.home or that plus the current narrowed message list;
can_apply_locally() is always true for the home message list, and the
list === message_lists.current check is equivalent to the more complex
narrow_state.active() check.
Because we don't call this function with home_msg_list, I believe the
existing msg_list !== message_lists.current check would have always
been false when the new check is false, but this is more explicit
about the logical intent.
The import of recent_topics_ui.js from unread.js generates an import
loop. To remove this, we need to move the logic for rerendering recent
topics after update_message_for_mention out of the low-level unread.js
data module.
Since the logic was conditional on `content_edited` being true, and
that parameter is only passed in the message_events.js code path, we
can do this by just making the function return a boolean for whether
this rerender may be required, and moving the rerender logic to that
calling module.
Ever since we started bundling the app with webpack, there’s been less
and less overlap between our ‘static’ directory (files belonging to
the frontend app) and Django’s interpretation of the ‘static’
directory (files served directly to the web).
Split the app out to its own ‘web’ directory outside of ‘static’, and
remove all the custom collectstatic --ignore rules. This makes it
much clearer what’s actually being served to the web, and what’s being
bundled by webpack. It also shrinks the release tarball by 3%.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
