This was introduced in #28767 with the intention to skip scrolling
the selected message.
So, the actual bug that the PR fixed would have been just fixed
by opening the compose box early.
This matches the algorithm that we designed for the Python API, except
that we use a ratio of 2 rather than sqrt(2) in the message_fetch code
path, because it's a heavier request.
We increase the number of failures before showing a user-facing error
to roughly preserve the same time period before a user-facing error is
shown.
Previously, these endpoints just did exponential backoff, without
looking at the rate-limiting headers returned by the server, resulting
in requests that the client could have been certain would fail with an
additional rate-limiting error.
Fix this by using the maximum of the existing exponential backoff with
the value returned by the rate-limiting header.
Fixes#28807.
This should help reduce the risk of hitting rate limits when users
have a very large number of messages to fetch via this mechanism.
Inline the `messages` variable that was only used in one place while
we're touching this.
This function incorrectly and misleadingly did an immediate initial
call, despite both of its callers doing immediate calls themselves (in
one case, with a different parameter passed).
This led to unnecessary server load when reloading the app via event
system triggered reloads, since every client would call `/` twice.
I was not able to reproduce obviously badly broken behavior from these
logic bugs, but after the renaming of message_viewport helpers in the
last few commits, it's clear that this logic was trying to check if
we're actually at the start/end of the possibly message feed, not just
the rendered portion, and doing so incorrectly.
The previous logic for both scrolling down and using pagedown would
incorrectly mark an entire conversation as read when reaching the
bottom of a render window, even if there were more messages loaded or
to fetch from the server.
Fix this error in the calculation by asking the correct data
structures if we're actually at the bottom.
To avoid the navigate.js keyboard shortcut code paths circumventing
this new logic, or needing to duplicate it, they now call
process_visible, rather than its helper.
Since we always call `deactivate` from `hashchange`,
`browser_history.state.changing_hash` is always `true` and hence
`save_narrow` just retuns without doing anything.
So far, there were 2 separate turndown rules for code blocks; one for
general ones, and the other for Zulip message code blocks.
Now the filter rule has been generalised to handle both cases together.
As a side effect, the bug where partially copied Zulip code blocks
lost formatting on pasting has been fixed.
The update_selection function name was rather misleading, since that
function call is in fact what renders the message list object for the
view.
Also add comments about a few subtle/confusing details that I noticed
while debugging this code path today.
As discussed in the new comments, we had a bug where the
system-initiated animated scroll that happens when the compose box
opens as a result of narrowing would race with the internal
rerendering that occurs when the message_fetch request asking the
server for additional data returns.
The correct fix for this is just to open the compose box, if we're
going to do so, before setting the user's scroll position in the
narrowing/rendering process.
This ends up being a UI improvement (in that the compose box is
available for typing a bit earlier) as well as avoiding both the risk
of this race as well as the bad UX of adjusting the user's scroll
position multiple times as part of entering the view.
This does not address an as-yet-unknown bug wherein the animated
scroll that occurs when opening the compose box, when racing with a
background rerender, results in a bogus ending scroll position, though
it's easy to see how that might occur given that rerendering does
clear the DOM briefly.
Needed for typescript, because we want to preserve
types, so instead of mutating a message object,
we can instead calculate return these values
for a message object before it's created in full.
This commit also renames apply_markdown
to render, see this comment
https://github.com/zulip/zulip/pull/28652#discussion_r1470514780
Since notifications have limited space for the contents of a message,
a quote from a previous message, or elsewhere, can take up most of the
notification, leaving little room for the actual message, and reducing
the usefulness of the notification.
To fix this, we collapse blockquotes and "user said" paragraphs to make
space for the actual message.
From `get_current_nth_hash_section` `get_nth_hash_section()` is
extracted to allow for reuse for any hash. The indexing is also changed
to 0-based and negative indexing also works now.
This is a prep commit for the next, where `get_nth_hash_section()` will
be used in a new function with negative indexing.
Also, makes small updates to `next_plan_forms_support.html`.
Removes unneeded "btn" and "btn-default" classes, and updates
the placeholder text for the input as not marked for translation.
Also, renames `ad_hoc_query.html` to `activity_table.html`,
`realm_summary_table.html` to `installation_activity_table.html`,
and `activity_details_template.html` to `activity.html`.
Removes the style attribute in the installation activity template
and uses a CSS class, "installation-activity-header", to center the
h3 and p tags instead. This removes an exception from the custom
lint check.
So far, when ordering typeahead suggestions, any query matches that did
not occur at the start of the target string were considered equally. So
for example, for the query "ok", "squared_ok" and "smoking" were
allotted equal priority, which does not make sense.
Now, matches from a word boundary (space, hyphen, underscore or slash)
are given priority (after exact matches and beginning matches), so that
in the above example, "squared_ok" is regarded as a better match than
"smoking".
Since recipients' sorting is complex, and needs word boundary matches
separately for decoupled sorting post triage, `triage_raw` is extracted
from `triage` to return the raw matches.
Fixes: #24127.
This commit adds a new option to the three-dot topic menu in the
left sidebar to mark all the messages of topic as unread, provided
the topic's messages are already read before choosing this option.
This is done with the help of bulk_update_read_flags_for_narrow
method to remove the read flag on bulk of messages.
Fixes#25085
This commit renames the bulk_mark_messages_as_read method to
bulk_update_read_flags_for_narrow, and takes in an additional
parameter - op, which takes in values of add or remove, indicating
whether to add or remove the read flag for bulk messages.
This is a preparatory commit to bulk mark multiple messages as unread.
Moves CSS styles for support view buttons to
`web/styles/portico.activity.css`.
Also removed the "sea-green" and "small" classes from a few buttons
as no CSS rules were being applied and most of those buttons will
be removed when these forms are refactored to use a modal.
We used bootstrap "fade" class to show the password strength
only after password_quality module is imported. Adding "fade"
class was only hiding the bar by setting opacity and the
transition defined in bootstrap was not used as it was
overridden by transition in progress_bar.css. So, we just
hide and show the bootstrap by using "hide" class and remove
the use of "fade" as part of the bootstrap removal project.
This commit introduces a "reset to default notifications" button to
the personal panel in stream settings. On clicking, it unmutes the
current stream and resets all its notification configurations to
default user settings.
Fixes zulip#27624.
We currently use btn-link class only in buttons used for
changing email and password in account settings panel and
for we already bootstrap CSS rules for those so we can
safely remove the CSS rules in bootstrap-btn.css.
This commit re-adds the bootstrap CSS rules for the specific
btn-link elements in invite modal to zulip.css. This is part
of the bootstrap removal project.
Updates the total row for the installation and remote activity
charts to be in the table footer. Makes the footer class sticky
to the bottom of the view so that it is always visible on the
chart.
Also, updates the installation activity column for revenue to
be formatted as a dollar string, since this formatting was being
applied in the updated total row.
This commit tries to improve the CSS related to the emoji picker by
restructuring relevant parts of `reactions.css` and `dark_theme.css`.
Via this commit, the redundant classes -- "reaction", "status-emoji",
"composition" are also removed from `emoji_popover_emoji.hbs`.
If needed, specific styling -- according to the type of emoji picker,
can now be applied using the `data-emoji-destination` attribute of the
`.emoji-picker-popover`.
Due to a logical bug in the `process_enter_while_filtering` function,
the `toggle_reaction` was being called when pressing enter while
filtering the emojis in the status emoji picker.
This commit fixes the above bug, while also adding some cleanups to the
`emoji_picker.js` by combining multiple click handlers and aggregating
all the logic related to an emoji being selected into a common function.
Fixes#28464.
When any stream name includes some other language's letters is scrolled down in
the recent views, the height of compose-controls bar would change.
Fix this by setting a precise line-height for these elements.
Fixes: #27837.
This commit moves the "Download config of all active outgoing
webhook bots in Zulip Botserver format." text to be shown in the
"Active bots" section since the text is relevant for active bots
only. This commit also updates the code to show the text only
if user has atleast one active outgoing webhook bot since the
text is relavant only for outgoing webhook bots.
Since the keyup event for keys including shift triggers the typeahead,
shift tabbing into the topic recipient field would show the typeahead
momentarily, which is distracting.
As we need typeahead to trigger on shift for certain use cases in the
compose box, but not in the topic recipient field, we now do not trigger
typeahead on shift keyup events in the topic recipient field.
Fixes: #24152.
Aman Agrawal
Tim Abbott
N-Shar-ma
evykassirer
Karl Stolley
Lauryn Menard
Anders Kaseorg
roanster007
Prakhar Pratyush
Sahil Batra
Pratik Chanda
vighneshbhat9945
Sayam Samal
vighneshbhat9945