When processing a server event or an empty message fetch,
we were incorrectly updating the closed new conversation
button attribute, "data-conversation-type" to be "direct"
without checking to see if the current narrow filter was
actually a direct message view.
Adds a helper function that checks the current filter for
contains_only_private_messages and then calls
compose_closed_ui.update_buttons_for_private when true.
That's the same check that's used in
message_view.handle_post_view_change when
compose_closed_ui.update_buttons_for_private is called,
so we're consistently using the same check when updating
the closed compose box buttons for this state.
Since we set a new timeout on every connection error, we can
unconditionally clear the timeout when load_messages is called.
This fixes the error when `load_messages` is called irrespective
of `delay_secs` timer.
This commit makes the following changes:
- Prevents the codepath in load_messages in message_fetch and
get_events in server_events from interfering with each other.
- The banner label now displays the time interval after which the
connection will be retried.
- The loading indicator now shows on the banner when the retry is in
progress via the JS logic.
Co-authored-by: Sayam Samal <sayam@zulip.com>
Fixes#33924.
Fixes#33570
When navigating to a narrow based on locally available unread
data with `old_unreads_missing`, we verify the calculated
first unread message id with server and if there is an unread message
prior to the one we calculated locally, we convert the current
narrow into a `near` narrow and show a banner with a button to
allow user to navigate to the correct first unread message.
This commit serves as the base commit for redesigning the alert banners
by migrating them to use the new banner component. We use a new name
to refer to these banners — "Popup banners", which is more descriptive
about their behavior.
The Popup banners are appended to the container in a stacking order,
i.e., the most recent popup banner appears on the top and the oldest one
is sent to the bottom of the stack. These banners also inherit the
animations from the alert banners for visual appeal.
This commit also fixes the bug where clicking on the "Try now" button
in the popup banner resulting from an error in the `/json/messages`
endpoint resulted in call to restart_get_events in server_events.js
instead of load_messages in message_fetch.ts.
Fixes#31282.
Extracts message_fetch and get_events algorithms for calculating the
exponential backoff into a shared helper function.
These match the algorithm that were designed for the Python API, except
that we use a ratio of 2 rather than sqrt(2) in the message_fetch code
path.
This commit adds `allow_empty_name: true` to the following
endpoints to receive empty strings as topic name when such
topics are available:
* `GET /messages`
* `GET /messages/{message_id}`
* `GET /messages/{message_id}/history`
Also, it adds `empty_topic_name` client capability for spectators.
These changes are part of the broader effort to enable
support for empty string as a topic name.
Since we allow calling `add_messages` without checking fetch status,
it can lead to non-contiguous message history due to latest message
being added to a message list without previous messages being
fetched.
To fix it, we only allow adding new messages via message_fetch
which properly sets `anchor` to the last message in the list
before fetching and adding messages to the list.
We update the fetch status before reaching here, so it was
incorrect to return before adding messages to the message
list data since it is always cached.
Since the initial fetch has a lot of messages, it can add many topics
to the left sidebar which can move the selected topic out of the view.
Note that `has_scrolled` is triggered even for the scrolls not triggered
by user since it is not easy to differentiate between the two events.
So, it is okay to ignore it initially.
If the initial fetch for the narrow didn't return enough data for
the view to becomes scrollable, we should try to populate the narrow
with more messages.
Since `all_messages_data` is no longer the data for combined feed,
we need to treat combined feed like any other view and continue
fetching messages if required.
`Filter.public_terms` will return the same result even if the
narrow is combined feed. Since we are no longer passing
empty narrow parameters for combined feed, this condition is
not required.
The operand for the canoncial "channel" operator can be an ID, but
it must be an integer and not a string, so we take care of that
directly in handle_operators_supporting_id_based_api.
