This shows a date on a message header whenever the date of that
message is different than the date of the previous message.
The previous logic was bugged and didn't display dates in headers at
date transition points.
This commit replaces the placeholder "clipboard" button with a reaction button.
This is done on any message that can't be edited. Also, on messages sent by
the user the actions popover (toggled by the down chevron icon) contains
an option to add a reaction.
When clicked, a popover with a search bar and a list of emojis is displayed.
If the right sidebar is collapsed (the viewport is small), the popover is placed
to the left of the button.
Focus is set to the search bar. Typing in the search bar filters emojis.
Emojis with which the user has reacted to this message are highlighted.
Clicking them sends an API request to remove that reaction.
Clicking on non-highlighted emojis sends an API request to add a reaction.
When the popover loses focus it is closed.
The frontend listens for reaction events. When an add-reaction event is
received, the emoji is displayed at the bottom of the message with a
count initialized to 1. If there was an existing reaction to the message with
the same emoji, the count is incremented.
Old messages fetched from the server contain reactions.
They are displayed (along with title and count) at the bottom
of each message.
When clicking the emoji reaction at the bottom of the message, if the
user has already reacted with that emoji to this message, the reaction
is removed and the count is decremented. Otherwise, a reaction is added
and the count is incremented.
Hovering over the emoji reaction at the bottom of the message displays
a list of users who have reacted with this emoji along with the
emoji name.
Hovering over the emoji reactions at the bottom of the message displays
a button to add a reaction.
Fixes#541.
This fixes a bug where Zulip would throw a TypeError if the user were
to try to narrow to a stream they had never been subscribed to. With
the new "preview" feature on the subscriptions page, this will now
happen much more often.
Previously, we were checking if a particular user was the current user
in dozens of places in the codebase, and correct case-insensitive
checks were not used consistently, leading to bugs like #502.
When the date changes between an existing group and a new group the
existing date separator needs to be updated. This is done by rerendering
the existing group.
(imported from commit a3775815e33872b0ec07704dc7ccf5fd2671fa21)
Now that we are not directly using message in the message list view
rename the uses of message that are message_containers.
(imported from commit 5c355703a8934a74864f5de6ecb1e2fd851e5d41)
The messages being passed to the handlebars templates were global
messages which we were adding per list details to, show name bar etc.
This causes rendering bugs when you try to rerender a message, because a
different list may have changed it. This commit moves the global message
data to a msg attribute on the message_container which will contain the
per list attributes.
(imported from commit 26b1f0d2c72d6288a6d3e7ed5f8692426f2a97ad)
When clear_table is called message_groups must also be cleared.
Otherwise render will try to incrementally update the DOM which will
fail when the expected existing nodes are not found.
(imported from commit 5ec3ce01717741b17c719fabded316619cdc4b25)
The handlebars template adds a text node with a newline after every
message. So we need to filter the jQuery object to include only the
message rows.
(imported from commit 07513b485e805570e450fb93c07091be89bcbd50)
Passing anything other than an array of DOM elements to
_post_process_messages is an error. In this case we were passing an
array of arrays of DOM elements.
(imported from commit 9e3be18598c406f3578a867dab36731ffeeac921)
The goal is to have a more data centric piece that can be unit tested.
We also try to minimise the number of one off jQuery DOM updates and
rerender handlebars fragments instead. This will prevent the
message_group and DOM from drifting apart and not being able to rerender
correctly.
(imported from commit 03f09803f2bc0c3b8187f76f2cfe90be9f7512a3)
To make the rendering process a bit simpler to read this commit is
refactoring the message group creation into its own function.
(imported from commit b53ce96ed8fee3064d7cf891fc248d0c3d821d1a)
Catch any exceptions that happen in the process of triggering
the message_rendered.zulip event. This addresses #2356.
(imported from commit ce771483cd2533d312fbd68e9c2753c80b3c8d49)
rerender_messages() does extra work such as making rerendering in narrows
safe, as well as updating recipient bars. That should be the only valid entry
point for rerendering individual messages
(imported from commit f91aeb2070b1056ab95e01d68a342558c2813ae8)