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 restyles the message_controls options to center them horizontally
while fixing them closer to the right side of the edge, along with just
replacing the edit button with a preview source button once editing is
disabled.
This moves the edit button to underneath the timestamp such that when
you hover over a message now the timestamp hides itself and the edit
button appears (if editing is allowed).
Fixes#1733 and other annoying issues with this field.
This fixes the following issues:
1. Photos are no longer resized larger than their native resolution.
2. Photos with transparency now have a checkerboard behind them to
signal an alpha of less than one.
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.
The lightbox will now distinguish between whether or not something is a
photo and a YouTube video by the class name of the message inline
preview. It embeds the YouTube video in the lightbox as an iFrame
rather than previewing the video screenshot.
- 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 an event listener (by way of delegation) to the
.message_inline_image elements that pops up the overlay and hides it
when the overlay exit is clicked.
Fixes#654.
There are no modern browsers that do not have built in JSON parsing
abilities. We do not need $.parseJSON as it now just serves as a call
to JSON.parse.
This is controlled through the admin tab and a new field in the Realms table.
Notes:
* The admin tab setting takes a value in minutes, whereas the backend stores it
in seconds.
* This setting is unused when allow_message_editing is false.
* There is some generosity in how the limit is enforced. For instance, if the
user sees the hovering edit button, we ensure they have at least 5 seconds to
click it, and if the user gets to the message edit form, we ensure they have
at least 10 seconds to make the edit, by relaxing the limit.
* This commit also includes a countdown timer in the message edit form.
Resolves#903.
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.
Assigns hotkey 'w' to search streams.
Only show search box when active. Activate with hotkey or by clicking
STREAMS.
Filter matches at the beginning of words in stream name.
Behaviour is otherwise almost identical to user search.
Casper tests.
Apparently, there are like 5 independently developed jquery-caret
plugins, none of which are great. The previous one we were using was
last modified in 2010. This new one comes from
https://github.com/acdvorak/jquery.caret and at least doesn't use
deprecated jQuery syntax and has a repository on GitHub.
This plugin is way larger than it needs to be for what it does, but we
can deal with that later.
Move recenter_pointer_on_display, suppress_scroll_pointer_update,
fast_forward_pointer, furthest_read, and server_furthest_read to
a new pointer module in pointer.js.
Previously, the Zulip subscriptions page's error bar would always be
at the very top of the scrollable view, and thus would likely be out
of view when an error happened. This fixes it by having the error bar
always placed below the search box (and thus visible regardless of
where in the scrollable streams view we are).
Fixes: #515.
[commit message and comments expanded by tabbott]
Our restructuring of the messages (especially grouping) seems to be the culprit for message copy and paste
(imported from commit 14632a67f55efea4f1b53cc718a4f655ac83b387)
This addresses #2351. While I could see the argument for
wanting to edit a message without changing your selection,
I think it's just very surprising behavior and inconsistent
with the rest of the UI.
(imported from commit 3bb4faca0656258b76bfaafbd7f4a645810578f6)
The reload initiation is required to run before other parts of the site
are started so that page_params will be setup correctly. This moves that
initiation out of an on ready handler to an explicit initialize call
near where the rest of the app is started.
(imported from commit b8994311299327aa3cfa57e3d9e92124a47123f4)
This helps the common case of not liking our default of having audible
and desktop notifications enabled, and not making users adjust the
settings on every existing stream to fix it.
(imported from commit be75edb2c1385d1bd9a289416e2dffd8007f5e0a)
They have weird properties like not sending anything for unchecked
boxes, which makes it hard to wrap a client-agnostic API around.
(imported from commit fef73a57a55b218b55dab6be3453dd6eac73c789)
`#tab_bar_underpadding` overlaps some with `.message_header`,
so adding `#tab_bar_underpadding.bottom + .message_header.height`
gave us a nonsense message viewport top.
Doing the calculation this way is more robust, as long as:
1) `$(".floating_recipient").offset().top` continues to give us a sensical number
and is the last element just before the top of the viewport.
2) nothing appears between the composebox and viewport.
In this commit I also removed the other couple of places where the #tab_bar_underpadding
was being used as a viewport reference, that no longer makes sense.
(imported from commit c7f35e41309900c581d5e2329c1becf161d501d3)
Now that we no longer use tables for our message list, we can
more logically group messages together.
(imported from commit 9923a092f91a45fe3ef06f2f00e23e4e3fb62a37)
This experiment has been disabled for everyone for a while: if we
bring something like this back, it is not likely to be exactly the same,
and will be different enough to require a different implementation.
As it is, the summarization code was making a few code paths (rendering
especially) more complex, and is worth removing for simplicity's sake.
(imported from commit 6ac8cdc9f7077a5a1da01ab4268aba3db0bc43f8)
If you have a lot more individual users in your realm than group
PMs in your recent history, we were squeezing out the Group PMS.
We now max out the ratio for any sub-section in the right sidebar,
as well as bumping up the min.
(imported from commit f7c44367f2a518d27406993cb6358cc96d1aae92)
Also:
* Change fixed element positioning and fix bugs
* Move settings dropdown back to the right and add left padding to left sidebar
(imported from commit fcf903b59617687f94618a01ce7544b69f408130)
This reverts commit 462a3eb5e6b83f9d8091b83e3f8dc458236938ed.
We're reverting this to see if it is the cause of our recent CSS
performance issues.
(imported from commit 6a0b041cfcb6770bbfda0d354444bad2d64459ab)
The leading theories this will test are:
1) MessageList._items becomes unsorted and the binary search starts
returning the wrong index from selected_idx.
2) MessageListView.render is not rendering the message or it is not
being inserted into the cache.
(imported from commit 926b7d7bf9df338320a8cba6241038176ce4b47d)
There are 2 uses of all_msg_list previous to this commit:
(1) The contiguous block of messages to be used for constructing the
initial state of narrows.
(2) A way to look up an arbitrary message by ID that may or may not be
in the home view to check if we have it locally.
We eliminate all applications of use case (2), replacing them with
queries on message_store, since they are in fact wrong -- any messages
that are outside the contiguous time period of all_msg_list would not
appear in all_msg_list and thus would incorrectly not be returned.
(imported from commit e2e2efe919242331bbc44abc6c50b16e3ab1336e)
When users select messages starting with stream header we should format
the text as using the custom copy handler.
(imported from commit 4f9851939484d046619c3e53c71c47ad64797670)
This is no longer required, now that we're no longer scrolling the
main body of the page.
(imported from commit c2aa0d403c8fd0679b3110fe8e7684d46a7557fa)
This got broken in the local echo refactoring -- we accidentally
switched the update_starred function to be a toggle, which meant that
the message would be marked as starred and then unmarked as starred
moments later, due to the two update_starred calls for the initiating
browser (one from when the click happens, the second from when the
event returns from the server).
(imported from commit 8f83729fe5477cf052124c1c56ed9189b85b885c)