This function throttles the function and only allows the on scroll
event to fire the popovers.hide_all() function once on scroll start
(determined as > 250ms after the last scroll event fire on .app.
This should resolve some performance issues surrounding constantly
firing queries and potentially changing the document tree.
Fixes the leaked popover issue where a popover for a dead element was
unable to be removed because it wasn’t connected to a parent that
existed in the DOM. Now they are cleaned up on every call to
popovers.hide_all().
Fixes: #3077.
Previously, the emoji reactions popovers were keyed off the
edit_content area, which is problematic because that area was
created/deleted on hover, resulting in orphaned popovers (which
wouldn't close properly normally). That had been hackishly addressed
in the original PR with the overbroad `$('.popover').remove();`. To
remove that, we fix the actions popover to always be based on an
element that exists in the page.
There probably more to do here, but this is good enough to merge emoji
reactions and iterate from here.
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 is a major change to the /#subscriptions page, converting it to
by a side-by-side list of streams and their settings in an overlay.
There are no new features added/removed, but it's a huge changeset,
because it replaces the old navigation logic and moves the stream
creation modal to appear in the right side of this overlay.
Previously we showed an "Edit" item in the actions popover menu when a user
could edit the content or topic of a message, and nothing otherwise. We now
show "Edit", "Edit Topic", or "View Source" in the popover menu for every
message, depending on the editability of the message, and present an
appropriate version of message_edit_form when the menu item is clicked.
Finishes #1604 and #1761.
We compute the editability of messages in several places around the
frontend; standardize the definitions and store in
message_edit.get_editability. This commit should not change app behavior.
This is a new mechanism to replicate the behavior of Emoji Box
drag-to-resize without the adverse effects of the last iteration — such
as not being able to drag to select text in the compose box.
- Expand a box full of emojis into the
compose window for users to graphically select emojis.
- Append an emoji to the end of the message when a user
clicks the emoji in the emoji box.
- Trap the escape key to always close the emoji box
before closing anything else if the box is open.
- Fixes: #147.
This adds a support a notification at the top of the screen that
alerts a user they’ve muted a stream and gives them the option to
unmute if it was an accident.
The notification disappears automatically after 4s, but if a user
moves their mouse over the notification, the timer resets to 2s after
the user moves their mouse off the notification, to make it easy for
users to read the full message and decide what to do.
This is controlled through the admin tab and a new field in the Realms
table. This mirrors the behavior of the old hardcoded setting
feature_flags.disable_message_editing. Partially resolves#903.
First user-fasing problem is that when user click to "Collapse" button
of message from narrowed list, buttons "Uncollapse" and "[More...]" does
not work. Second, is that when user collapse/uncollapse some message
from narrowed list, the collapsing/uncollapsing of the same message in
home list does not work in appropriate way.
In "popovers.js" there is the function that is called on click to the
buttons "Collapse" or "Un-collapse". It should show and hide body of a
message. If a message list is narrowed, it should show/hide message in
home list too. So, the first problem is that "toggle_row()" in this
function call methods "collapse(row)" or "uncollapse(row)" from
"condense.js" twice (for row and home_row) using condition
"if (message.collapsed)". When it happen the first time, the variable
"message.collapsed" is changed. That is why next call of "toggle_row()"
work incorrectly.
The second problem is that the function in "condense.js" that is
called on click to the button "[More...]" contains no code for
collapsing/uncollapsing message from home list. It just calls
"collapse(row)" or "uncollapse(row)" for row from narrowed list.
Now, functions "collapse(row)" and "uncollapse(row)" get row from
current list and change both messages (from current list and home
list). On-click functions call them just once for making all of needed
message changes. So, when user collapse or uncollapse message from
home or narrowed list it works correctly.
Fixes: #516
Like the Stream Subject lists, Private messages are now shown
when the user clicks on the "Private message" link. User can drill in
to get more than 5 conversations. Selecting PMs from the user or group
PM lists on the right sidebar also opens the list & highlights the
selected conversation.
[Edited by tabbott@mit.edu to fix some small bugs.]
Collapsing a message in a narrow should also collapse that message in the
home view. Previously this would only happed with the message was
rerendered.
(imported from commit fa82888eba51eb2f4f2b93521d4b7daee852898d)
Remove the options to narrow by topic/person from the menu,
because there are better ways to do this in the UI, and
remove the time travel option, because the "Link to this
conversation" achieves mostly the same effect.
(imported from commit b7e0cfe64c0760e5a7bf7a8c9c05ed1a5b747300)
Before this change, we were using sequentially generated ids
on the client side to identify streams. Now we just use
the ids from the server. The goal here is to reduce the
confusion of having two different ids attached to a stream.
Also, not that it matters a ton, but this also means that
the browser basically has an immutable id for each stream
that is future-proof to reloads, multiple create_sub calls, etc.
It also a bit easier to grep for ".stream_id" than ".id".
(imported from commit 057f9e50dfee127edfe3facd52da93108241666a)
This doesn't actually prevent a user from making the API call into our
servers to actually go and edit a message, so this isn't a bulletproof
solution for realms where messages ABSOLUTELY MUST NOT be edited.
(imported from commit 5bf043a201e2952189b45f93b8c5ca7648f6aee7)