This commit extracts the edited notice computation logic of
edited_in_left_col, edited_alongside_sender and edited_status_message
to a new function - set_edited_notice_locations and calls it right
after the method merge_message_groups.
This is a preparatory commit, and is done since theses three variables
were previously wrongly initialized in the beginning for live messages
received.
We also introduce a modified flag to decide whether to display the
edited notice or not. This is useful since now we are computing
the edited notice values even when messages are not edited, and
hence we show the notices only when the modified flag is true.
This correctly avoids pageup/pagedown scrolling past already rendered
content, while also always making progress, which the previous logic
introduced in d8ec141de2 might do, at
least in degenerate cases with very small render windows.
I'm not sure this change has any effect in practice with current
render window values, but it does fix a bug if I set the maximum
render window size to 20.
The previous batch of improvements to this code path in
6562ea94e4 introduced a race bug where:
- You navigate to a narrowed view; Zulip renders cached data from
`all_messages_data` that we know is current, but
`fetch_status.has_found_newest` is initialized to `false`
nonetheless.
- The bottom is visible, triggering the check for whether the view
should be marked as read.
- `fetch_status.has_found_newest` is still `false`, and so we
incorrectly refuse to mark as read.
- We finish fetching data from the server, do the background rerender
for that (with no changes), but that doesn't trigger a re-check for
whether the bottom is visible.
There's several ways to address this, but most correct to me is to not
check fetch_status in this particular code path.
The same reasoning applies to the navigate.js call sites.
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.
Fixes#26774.
We don't need the today argument anymore since every value passed to
it was a new Date() except the tests where we are using MockDate now.
Rules followed:
1. Bold and highlighted background if the mention was processed
as a mention that includes you.
2. Bold personal mention (but not highlighted) if you were mentioned
but not subscribed at the time.
3. Otherwise not bold, no highlighting.
As we plan to keep the mention pill CSS the same if a user
was mentioned via that personal/wildcard/usergroup mention
irrespective of whether the user is subscribed or not, we use
usermessage flags to determine when to add 'user-mention-me' class.
Fixes#27654.
For more clarity, the 3 related functions `is_search` in `filter.js`,
`message_list.js` and `message_list_data.js` are all renamed to
`is_keyword_search`.
Fixes#27489
For sticky message headers, we should not use the `first_message_in_group`
for narrowing to the topic since can be out of view for the user.
This commit removes the 'development' guard and makes
the UI changes related to the 'Follow Topics' project visible
outside the development environment.
Cleans up the older UI elements related to mute and unmute topics.
This commit updates code to italicize "(guest)" shown for guest
users in header row. We do not italicize "(guest)" in tooltip
shown on hovering over the header row for now.
We pass the user objects to template file instead of passing
the complete string to it to handle this correctly.
This commit adds code to add "(guest)" to user names of guest
users in the following places -
- right sidebar
- user pills, including the pills in search suggestion typehaead
- typeaheads for user
- sender names in message feed
- user profile popover and modals.
- user name in not subscribed warning banner.
Note that the indicator is shown only if enable_guest_user_indicator
setting is set to true.
As a result of this change, we now translate "deactivated" text
shown in user pills for deactivated users.
Fixes part of #26700.
This commit removes the widget to change the visibility policy
for topics in unsubscribed streams.
Earlier, users were able to change the visibility policy in an
unsubscribed stream, which can lead to confusion.
For example, a person might think that they would get notifications
about new messages in the topic of the unsubscribed stream,
which of course they wouldn't.
This should cause no functional changes.
This is part of a multi-step effort to move away
from using stream names to reference streams, now
that it's impossible for a user to write a message
with an invalid stream name (since switching to
the dropdown).
This commit replaces the mute/unmute topic button in the message
header bar with a button that allows the user to set the
visibility_policy of the topic to muted, unmuted, followed or inherit.
The button in the message header bar has an icon corresponding to the
current visibility policy of the topic.
In a muted stream:
A click on the button opens a popover with 'Mute', 'Default', 'Unmute',
and 'Follow' options.
In a not muted stream:
A click on the button opens a popover with 'Mute', 'Default', and
'Follow' options. 'Unmute' option is available only when the
visibility_policy is set to 'Unmute'.
The current visibility_policy of the topic is highlighted in the
popover.
This commit improves the edited/moved tippy tooltip to now include a
second italic line: "Click to view history" This line is visible
only when 'realm_allow_edit_history' is true for any organization
settings. Additionally, the first line is changed to display
"Last edited today at 00:00 AM" The date is in lowercase if it
doesn't contain a number for example 'today' unless the first
alphabet is uppercase.
'tippy-zulip-delayed-tooltip' was used as a common class to
implement tippy tooltips in addition to other elements in the
'edited_notice.hbs' file. However, now we need to make some
changes in tippyjs inside the onShow function to decide whether
to show the second line of a tooltip or not. Therefore, we need
to use a unique class for the edited_notice tooltips. Hence, removed
the 'tippy-zulip-delayed-tooltip' class from the edited_notice.hbs
file and used the 'message_edit_notice' class instead.
Fixes: #23075
When a message list view rerenders a locally echoed message the
message recipient header is also rerendered, which then removes
the "sticky_header" class if it was present. If rerendering the
message triggers a non-user initiated scroll event, then the
"sticky_header" class is updated.
But it is possible that the rerendering of the message will not
trigger a scroll event, which means the recipient header is no
longer updated and the next calculation for the message list
view's _scroll_limit for the top of the feed will not include the
sticky header and the currently selected message may be scrolled
partially or completely under the message header recipient bar.
In message_list_view.rerender_messages, adds a check, after calling
_rerender_header in a loop, for the current message list and calls
update_sticky_recipient_headers if the message feed is visible.
Adds a comment to _rerender_header that we expect it to only be
called in rerender_messages so that the "sticky_header" class is
updated if needed.
This commit fixes the bug where the edited notice is not displayed
for edited/moved messages when the edit_history is disabled for
the organization. However, this is incorrect because the edited
notice should still be shown for messages that are edited/moved,
even if the edit_history is disabled. This issue occurred because
the edit_history variable was not set in the message object when
the edit_history is disabled. Therefore, in this case, we check
for the availability of last_edit_timestr. If it is available, we
display the edited notice. Since we cannot determine if the message
was moved or edited, we show the edited notice for both cases.
In an upcoming commit, we will fix a bug that caused the
message_list_data system to append rather than prepending when
previously all the messages in a message list were hidden due to
topic/user muting.
We've had a series of bugs where tooltips get leaked when a message list
is rerendered. For some tooltips, we used a 'mutation observer' to remove the tooltip
in this situation, but this was expensive and messy. We replace this with a Tippy
plugin to keep track of this class of tooltips, with a central hook to remove them
during rendering.
Message lists are rerendered in the background in a variety of situations;
a simple way to trigger it is clicking the mute/unmute topic/stream button in
the topic menu/stream menu and the clickable area overlaps with the
message list tooltips area. If a tooltip was visible at the time, the tooltip loses its
reference due to the re-rendering removing its DOM element, appearing at the top-left corner.
To prevent this behavior for all message list tooltips, we need to
store all instances of the message list tooltips and then destroy
them if the instances does refer to something else then document.body
using the 'destroy_all_message_list_instances' function just
before re-rendering.
Whenever the message list is rendered, all the message list tooltips
will be destroyed if they do not refer to document.body. This
prevents the double appearance of those tooltips if the reference
is removed from the DOM.
This plugin allows us to remove the mutation observers and net delete code
while hopefully fixing this bug for the whole app.
This is a more natural place for this extra padding than below the
navbar. Padding below navbar was primarily needed to hide the
message content above the sticky header while scrolling the message feed.
We are still able to do with this change without partially hiding the
loading message indicator.
Fixes#25159
Updated mute_or_unmute_topic to take visibility policy as parameter
and set topic visibility_policy to the passed visibility_policy.
In zulip.css, updated CSS to set opacity as per visibility_policy.
Updated click handlers for recipient_row mute/unmute icons to
work as per stream.
Fixes#25124
When user marks messages as unread, we used to rerender them but
that was not required since we only need to add `unread` class
to their `message_row` to achieve the same effect.
When selecting a previously selected message after a re-render,
we don't need to mark it as read. This caused a bug where
user cannot mark the selected message in a narrow as unread.
Also, added an additional check to only select messages if the
message is re-rendered in the currently visible message list since
you cannot select a message in a view which is not visible.
If the sticky recipient bar hides the date separator completely,
the recipient bar needs to show the correct date for the message
next to it, otherwise the user will see the wrong date for the
message.
To fix this, we show the date on the date separator as soon as
the sticky message header starts to overlap with the date separator.
Previously, editing topic of "(no topic)" messages was allowed
irrespective of time limit or the "edit_topic_policy" setting.
Since we are working in the direction of having "no topic" messages
feel reasonable, this commit changes the code to not consider them
as a special case and topic editing restrictions apply to them as
well now like all other messages.
We still highlight the topic edit icon in recipient bar without
hovering for "no topic" messages, but it is only shown when user
has permission to edit topics.
Following important changes are being made here:
* color_class lib is removed since it not used anywhere now.
* We don't need the `dark_background` class since the background
color is already adjusted based on color scheme. So, all
instances of it being used is removed.
