Prevent displaying the topic resolved banner when the channel
picker (compose_select_recipient_dropdown_widget) is opened in
the case of forwarding messages. This is done to prevent the
overlap of the channel picker and the banner, as it hides some
part of the banner text.
Fixes: #33449
Earlier, buddy list tooltip would get stuck if tooltip was displayed
when redraw for presence update got triggered. This happened due to
tooltip target element was changed but reference element for
mutation wasn't updated.
We are adding video support to the function in upcoming commits and we
need to rename the function for that to be more generic.
We've also added a proper return type in the name of DropboxMediaInfo
TypedDict for the `dropbox_media` function.
We currently don't use either of those operators in email
topic links, which breaks the links on topic moves.
Quoting Tim for choosing `near` vs `with`:
"I guess for each case we should decide if we want /near/ links
to /with/ links. We likely want /with/ in some cases, to make
sure we land in the right conversation but not forcing the scroll
position to be on that particular message, which /near/ does."
"I feel like email notifications might want /near/ if the trigger
is a mention or something else that is specific to the message,
rather than the conversation, but probably /with/ otherwise."
We abstract away "near" vs "with" from the function names and
allow callers to specify whether they want a conversation_link,
ie, use the "with" operator. The default choice is "near".
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.
Our custom code fence parser for Python-Markdown does not nest
fenced code blocks inside list items, but it can be done with
4-space indented code blocks, as long the list item itself also
uses 4-space indentation.
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.
Even though we have separate packages for `help-beta`, we have opted to
put the prettier plugin and config for astro files in the main project
itself, so that linting needs to be configured only at one place.
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.
Although this code was not actually vulnerable as written, we never
want to be disabling this Ruff rule, in order to discourage later
introduction of vulnerabilities.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
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.
