This commit removes the keep_focus_on_search option from the
DropdownWidgetOptions type, and updates logic to always set
keep_focus_on_search when the search box is visible in the
dropdown.
Fixes: #34828.
This overscroll-behaviour was changed earlier to fix sliding of
message_feed_container but later separate PR addressed root cause
for the issue. This overscroll change did end up preventing
swipe gesture navigations.
This commit reverts 448cd70c56.
Existing class "rendered_markdown" has been added so
that the emoji remains in agreement with how
messages are displayed in message area.
Fixes part of #30781.
When offline, has_found_newest never ends up being true, and we'd end
up falling through to an interleaved banner. We rewrite this logic
with an explicit idea of whether we're online, and the following fixes:
- Never display the interleaved view confirmation banner in a
conversation view.
- Avoid displaying that banner inaccurately when the actual problem
is that we're offline.
- If we're offline, always call do_mark_unread with a list of IDs,
such that if its helpers supported local echo (they don't), we
will locally echo to the extent possible.
Note that following this change, being offline results in "mark
unread" being a noop until you're online again. Better than a weird
banner.
See https://chat.zulip.org/#narrow/channel/9-issues/topic/mark.20unread.20strange.20when.20disconnected/near/2201703 for more context.
This commit adds code to use
`web_left_sidebar_unreads_count_summary` from personal
settings in web app.
Co-authored-by: Akarsh Jain <akarsh.jain.790@gmail.com>
Fixes part of #28759.
Earlier, when we had unread banner in message list and user marks
all messages as read for topic, unread banner would persist even
though we had no unread messages in current message list.
This commit hides unread banner when there are no unreads just like
we show banner when unread messages appear in message list.
Fixes:zulip#33866.
Previously, the settings edit UI used a different phrasing, and "Slack
compatible" used a dash only in the documentation.
We settle on "Slack-compatible", since that's what we use for the
similar incoming webhook format.
Zulip production suite / ${{ matrix.name }} (zulip/ci:bookworm, --test-custom-db, Debian 12 production install with custom db name and user, bookworm) (push) Has been cancelled
Zulip production suite / ${{ matrix.name }} (zulip/ci:jammy, , Ubuntu 22.04 production install and PostgreSQL upgrade with pgroonga, jammy) (push) Has been cancelled
Earlier, 'all_topics_in_cache' used to return `false`
in the case where we were unsure if some topics were
present even before the user subscribed to the channel
and hence missing in the cache.
Returning `false` led to visible 'show all topics',
even if all the topics were already displayed. This was
helpful if the API call to fetch channel history failed,
as users had the option to make another request.
That resulted in a bug where "show all topics" was flashing
in channels with less number of topics. We used to display
"show all topics" initially and then hide it after the API
call confirmed that there were no new topics to display.
To fix this bug, we return `true`. So, the "show all topics"
is not displayed beforehand. We let the API call fetch the history
and rebuild the topic list based on the updated data.
Instead of show then hide. We now prefer, show if needed.
To fix the issue of API call failure and users having no option
to see all topics, we did prep work in the last commit
to add retry mechanism to the concerned API call.
Earlier, in `get_server_history` the API call to fetch stream-topic
history didn't have a retry logic.
This commit adds a retry mechanism.
If the request to fetch stream topic history fails, we now retry
the request up to a fixed number of times before giving up.
This improves UX in case of temporary network issues.
When a user is added to a channel, we send
the user that was added a Notification Bot
DMs to let them know about it.
In this commit, we add an option for whether or not
this message is sent.
If more than 100 users are added at once, we
do not send notification bot DMs since it would
be a performance-costly operation.
We also send this threshold value of 100 in the
initial state data to the clients.
Fixes part of #31189
Previously, when sending messages to resolved topics, the warning
suggesting to resolve that topic used wrong check to verify if the
user is allowed to resolve the topic. This commit fixes that.
Some browsers trigger a 'keydown' event with `key === undefined`
on selecting autocomplete suggestion. These are not real keypresses
and can be safely ignored.
See: https://issues.chromium.org/issues/41425904
Earlier, not handling it was resulting in error later in the codepath.
We make the text "minutes" agree with the number
in the input field.
In the future, we could make the units configurable
as in the invitation modal.
Fixes#34692.
