This fixes the user’s name to not fall on the next line. Instead it
appears on the same line and overflows properly into an ellipsis so it
theoretically should never overflow on to the next line.
This reverts commit 7bf10ec74f.
Apparently, SockJS 1.1.1 is broken with the browser used in our legacy
desktop app, resulting in messages being silently not sent.
This adds some configuration options to settings.py, namely
PASSWORD_MIN_LENGTH and PASSWORD_MIN_QUALITY, which control
when the frontend validator invalidates the password.
Closes#2628
Emoji styling was broken in Firefox browser due to its lack of support
for the zoom property.
This replaces the zoom property with the transform property that now
scales the emojis down to 70% of their original size.
This reverts commit e4761782e0.
This caused performance problems and jolting of the main UI, because
it broke the important invariant that the height of a Zulip message
should not depend on the content of slow-to-load assets such as
images.
This fixes two issues:
* If you had around 10 distinct emoji reactions on a message (enough
to force a line wrap if the add-your-emoji button was visible),
Zulip would add that button into a new row on hover, jolting the
message feed. This fixes that problem by leaving a blank last line
for the add-your-emoji button.
* We were incorrectly showing the padding for the emoji reactions
region even if there were no emoji reactions, causing messages to
have too much padding.
Add the Zulip logo to the top of the messages feed to show that there
are no more messages to load, or that it is loading more (if the
spinner is still around).
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.
When we change a stream name, we now use the stream id as the
key to find messages we need to live update. This eliminates
some possible race conditions from two users renaming a stream.
This commit introduces message_live_update.js.
The new call stack is this:
subs.update_subscription_properties
subs.update_stream_name
message_live_update.update_stream_name
message_list.update_stream_name
The issue is that we were trying to validate the mentions before
checking that the recipient stream was valid, leading to problems
checking the membership of the stream.
Fixes#3040.
Stream descriptions are now displayed along with the name. The
autocomplete results include streams with matches in the stream
descriptions. Added styling for description in compose.css.
Fixes#2398.
When somebody changes their name, we will now update
the buddy list right away. The old code was trying
to do this through a code path that was designed for
true presence updates, but it was also passing in an
empty array, instead of undefined, which caused it to
fail to invoke the intended part of the codepath to
redraw the buddy list.
Now we just call the new activity.redraw() function,
which does the right thing for the buddy list.
The group PM list was live-updating before this change,
and it continues to live-update as part of the new
activity.redraw() function.
Using the offsetHeight getter is ~2.5x faster than
getBoundingClientRect() on what can be an expensive operation to do in
the hundreds of times.
Note: Tim thinks that this may have been different a few years ago,
since we tested fairly carefully before settling on
getBoundingClientRect, but benchmarks pretty clearly show offsetHeight
is faster today, so we should use that.
The escape key used to be intercepted if the subscription pay display
was set to “block”, but now since we use the class “show” and lack to
hide and show the overlay, the query needs to change.
We attempted a number of different approaches to solving this problem:
First, we tried using HTML5 local storage to keep track of which
browser should have created the desktop notification. This failed
because one needs locking, and it doesn't appear there is an working
locking implementation for HTML5 local storage that could allow us to
do this across tabs. See #2936 for details.
Ultimately we went with setting the message ID as a tag. Tags are
intended to be used for updating existing desktop notifications, which
means this implementation causes new notifications to flicker in and
out sometimes when multiple tabs are open, but that certainly beats
having duplicates.
Fixes#99.
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.
Update integration to use the latest Google API client.
Move Google Account authorization code to a separate file.
Move relevant files from 'bots/' to 'api/integrations/google/'.
Add documentation for integration.
Jackson
Tim Abbott
JefftheBest1
Yago González
Steve Howell
Robert Hönig
Vamshi Balanaga
cosmicasymmetry
Anirudh Jain
brockwhittaker
Tommy Ip
Bojidar Marinov
synicalsyntax
Brock Whittaker
Harshit Bansal
Sampriti Panda
Rishi Gupta
Akhil
Umair Khan
vaibhav
Alicja Raszkowska
andrewallen00
Alya Abbott
Callum
Arpith Siromoney
Prabod Rathnayaka