Most elements, apart from chevrons, now have explicit
font sizes.
In some cases I chose integer values that were close
to the calculated values you would get with all the
ratio calculations.
And then I tweaked how the hashtag/lock icons get
aligned.
The alignment for those icons if off in this version; it'll be fixed
in an upcoming commit.
The fonts there used to be 14.2px due to an arcane
calculation. Now we explicity set a value.
If you expand Private Messages, the font inside now
is explicitly set to 13px. It used to be 12.8px due
to a complex calculation.
The previous commits made the "arrow" class no longer
necessary for these left sidebar elements.
The "arrow" class was always a bit dangerous, as bootstrap
has a class by the same name for a different concept.
We weren't really using consistent styling for "arrow"
across all our chevrons, so even without bootstrap in
play, it was just creating complexity.
This is a fairly big commit, but at the end
it simplifies a lot of things.
It's difficult to fix highly coupled code in
incremental steps because, well, it's highly
coupled code.
The main thing this does is give each type of
chevron in the left sidebar its own class
* all-messages-arrow (NEW)
* stream-sidebar-arrow
* topic-sidebar-arrow
Before this change, the "All messages" chevron
was using stream-sidebar-arrow, which was a
strange name for something that's not actually
in the stream sidebar. Obviously this was
cargo culted.
There was not much JS to change here--we just
fix the click handler for "All messsages".
And then there's a one-line change to the template,
and the rest is re-organizing the CSS.
Using a more specific class avoids confusion related
to the .arrow class, which is not only a popover concept,
but also a Zulip concept in the left sidebar.
The way we build chevrons is super messy and highly
coupled. This comment reflects an audit I did on the
code in its current state.
Subsequent commits will make things a bit easier to
understand.
The topic-sidebar-arrow chevron never shows
here--it was just cargo-culted code from
the topic lists.
It's also a landmine--we don't want to
accidentally build a topic-related sidebar
menu for PMs.
We could arguably just use zero-unreads everywhere,
but we definitely don't want zero-topic-unreads
inside our PM list.
I prefer to just have these two concepts:
zero-pm-unreads
zero-topic-unreads
And it's super easy to share CSS properties for both.
The antialiasing decisions we made for the webapp should be constant
over the entire page, not limited to particular subsections or themes.
If we wanted antialiasing, we should do it on the entire page, not
individual random widgets. But it's not clear we actually want to do
it on the entire page. The `-moz-osx-font-smoothing: grayscale`
setting now happens by default in OSX Mojave (40% world market share
right now and growing), so there's no reason to override it. And
without retina displays, generally, subpixel rendering provides better
results than antialiasing (which overrides subpixel rendering).
Thanks to Anders Kaseorg for advice on this issue.
When the user logs in as an admin, and clicks on the 'edit user'
button under the url path #organization/user-list-admin, the modal
that was displayed didn't contain the user's email address under the
list of information. This commit adds the email input as a readonly
element, which at the very least provides helpful confirmation that
you have the right user.
Fixes part of #11453.
The night logo synchronization on the settings page was perfect, but
the actual display logic had a few problems:
* We were including the realm_logo in context_processors, even though
it is only used in home.py.
* We used different variable names for the templating in navbar.html
than anywhere else the codebase.
* The behavior that the night logo would default to the day logo if
only one was uploaded was not correctly implemented for the navbar
position, either in the synchronization for updates code or the
logic in the navbar.html templates.
Add a background highlight to vote count button if currently
logged in user votes on that option.
Tweaked by tabbott to use better variable names and Rishi for better
styling.
This just puts the style more clearly that one shouldn't be using
`this` to refer to the outer MessageListview object, because that
breaks unexpectedly when inside a loop.
This is the real guts of how we render messages.
It only excludes the border effects, which we
leave in single_message.handlebars.
This is a pure code move, and should remove a lot of nesting that
would otherwise clutter one's view.
The bool `include_sender` will always be `true`
for status messages. Here is the relevant
excerpt from MLV:
message_container.status_message = // ...
message_container.include_sender = true;
We don't need the `include_sender` check in the template.
We could probably also fix the above code, but it's
semantically correct. I mostly care about simplifying
the template.
This is a pure code move. All three places where we use
this partial had the exact same markup, except one place
where I think `auto-select` was inadvertently left off.
This is a pretty coherent chunk of template code
related to these icons:
- edit pencil
- reactions
- chevron
- star
Moving it to a partial will simplify future diffs
where we re-work the message HTML.
This is a pure code move.
Some changes here:
* more whitespace
* avoid else, and just re-state the condition
* avoid long if blocks, just re-state the condition
* use standard `{{#if foo}}` construct
The refactoring of conditionals here will make more
sense in subsequent commits.
This is a pure data function, so it shouldn't be in popovers.js file
(Steve Howell added test coverage here, and tabbott removed an
accidental functional change.)
This fixes an issue where blank lines between blocks were causing
auto-numbering of list to stop before the blank line resulting
in two separate numbered list instead of one.
Edited significantly by tabbott to explain the tricky details in the
comments.
Fixes: #11651.
After discussion, we decided that the red color is too distinct
and does not convey the idea of "almost offline".
This changes the new "unavailable" status circle's color from dark
red to grey, the same color used by the "offline" status circle.
Fixes#11589.
Adds SCSS style for the "unavailable" user status and enables its
usage in `buddy_data.js`.
The style is a red circle with a horizontal line. The values might
look a bit 'magic' but they were considered carefully ` height` of
1px was too thin, 2px was too thick, thus 1.5px was chosen.
Fixing this involves fixing the backend to handle unchanged field
submissions of the Zoom credentials without trying to re-validate the
credentials (for performance) as well as to fetch the already-sent
secret.
Visually, #zoom_help_text acts like
.organization-settings-parent div:first-of-type when the Zoom option
is selected, but isn't treated as such.
No visual change with the #google_hangouts_domain change; just there to make
the code more readable/defensible.
If you topic-edited a single message within a narrow, we would update
all our unreads/sidebar/etc. data structures, and would rerender the
message if appropriate. However, for the corner case of being inside
a topic narrow when you did this, we didn't have logic to remove the
message from the narrow (which is the appropriate situation when you
just topic-edited a message in a narrow).
When topic-editing multiple messages including the currently selected
message (the more common case), we would end up changing the narrow,
resulting in this issue being masked.
Fixes#11601.
The correct behavior here is that we want to ensure there is
whitespace in between the syntax being added and the content on either
side. Our smart_insert logic handled this for the cases that were
common with inserting emoji (etc.), but didn't handle the more complex
cases with "quote and reply".
Fixes#11702.
Accomplished by adding a function to clear the status message with
an empty string. The html is then updated to reflect changes without a
refresh.
Currently, it's a small hassle to clear a status message. This option
makes things a bit easier.
Fixes#11630.
This new helper allows us to do the same operation
on every message in our message_store. We will
use this in a future commit to clear the `is_tall`
flags on all messages, after a resize.
We should be somewhat cautious about using this,
but simple operations should be really fast, even
if you have lots of messages in the store.
Previously, if you were in the process of editing the last message in
a narrow and a new message came in, we'd rerender that second-to-last
message, causing your editing widget to lose focus (and thus the next
few keys you typed to be interpreted as keyboard shortcuts, which
had a good chance of resulting in your navigating somewhere random).
This rerendering was essentially unnecessary; the only change to state
going into the rendering process was the next_is_same_sender CSS class
being toggled on the messagebox in the message. So, at most, we
should have been just toggling that CSS class (and this commit makes
us do precisely that).
It seems like we could further improve this code by just removing the
next_is_same_sender CSS class entirely and removing this block, but
I'm leaving that for follow-up work.
Fixes#11656.
This fixes an issue where closing stream search was not working if
user had not entered a search term and tried to close the search box
by clicking on the close icon; the problem was that we'd end up
re-opening the widget immediately after through event propagation.
Fixes: #11636.
The is_editable field includes topic edits, so we need a separate
field for whether to display these icons which are all for content
editing.
Fixes#11666.
Adblock Plus's "Block social media icons tracking" setting blocks
images with for social media platforms in their names from loading, so
we rename the Google logo to bypass this.
Adblock Plus's "Block social media icons tracking" setting blocked
integration logos for social media platforms from loading, so the logos
are renamed to bypass this.
Fixes#11590.
When copying a message by clicking on "copy and close" button in
message edit box an alert appears that says "Copied!"; Background
of the message is set corresponding with the day mode but not the
night mode. This changes the background of the alert message to
the dark color in night mode.
Also adds tests to ensure that we do not accidentally overwrite
the 'beginning' variable that contains the message content upto
that point. These should prevent similar errors in the future.
The bug was added in 8119258c4d.
The bug here was that when we rerendered messages following local echo
through the echo.process_from_server code path, the eventual call to
_rerender_header() made the implicit assumption that all messages in a
message group had the same date. As a result, it created a totally
new/fake message group and called the rendering logic on that group
without calling the functions for setting up recipient row dates,
which would always result in no recipient bar date being added. This
bug was latent/invisible before, because when introduced, the locally
echoed messages were always being added to a recipient group from
today, where the recipient bar's date area was by default empty anyway.
This latent bug was revealed when we modified the structure of the app
to do date dividers between individual messages within a message
group, rather than strictly between message groups.
When we're handling a single message that was locally echoed, there
will very likely be 0 messages not removed by
`echo.process_from_server`, and we can skip the unnecessary call to
`message_events.insert_new_messages`. This is a small performance
optimization and logical simplification when sending messages.
This commit achieves two things:
1. Changes the UI of the "Create stream" form to make the
textarea previously used to get the stream description
a simple input field of type text (to suggest a single
line description).
2. Adds an extra check on the frontend side to make sure that
when users create a new stream via. the "Create stream"
option in the settings panel, they can't enter any newline
characters (i.e. we disallow the enter key from being
registered when typing out the stream description).
We must also make sure that they cannot copy-and-paste over
descriptions containing newline characters.
resolves#11617
For consistency, we should keep all the code that works with
@mentions in markdown.js. In this case, message_list_view was
rewriting the contents of the mentions in cases where users'
names had been changed since we rendered their mention.
This change should help people discover to distinguish
silent mentions in text as a part of Zulip syntax while
differentiating them from regular mentions.
To test formatting we want a hard coded date, so we
can verify the date arithmetic with stable dates.
To make the test less brittle, we disable the
feature to remove old drafts.
This was an emergency fix. We should probably just
remove the last N drafts instead of having the 30-day
limit. Or we should have a better way to stub the cutoff
date.
The background color of the portico pages aren't true white,
so this commit adjusts it to match the actual portico page
background color to eliminate differences.
This is mostly adding markup, calling some convenient
functions in buddy_data.js, and adjusting CSS.
To make the circles update dynamically, I mostly
orchestrate this though activity.js for now. It's
possible we'll want to adjust that eventually to
happen through something like a `presence_events`
dispatcher, but that's essentially what
a good part of `activity.js` does now.
We're soon gonna have user circles in four different places,
and the fourth place, Private Messages, will have different
size/position CSS.
Now each component does positioning and sizing in its
main CSS file:
user info, group info -- popovers.scss
buddy list, group PMs -- right-sidebar.scss
(We also use the more explicit syntax for padding each
side.)
We now have a function get_user_circle_class
that returns one of these values:
"user_circle_green"
"user_circle_orange"
"user_circle_empty"
And we put that in the templates.
And then CSS renders the circle of the appropriate
color.
The unit tests now explicitly capture whether
we are rendering the correct kind of circle.
This is a pure code move.
We want to use user circles in the left sidebar,
so this code will no longer belong in
right-sidebar.scss.
This code is just related to drawing the circles.
We can still position in size in other CSS files
(with more context-specific selectors).
This fixes a longstanding UI issue when you have way too many recent
private message conversations, as you can now scroll down the list to
find what you're looking for.
Fixes#5384.
Date separator exists inside the message_row, which causes the
message controls to be visible even when hovering on date
separator. These two rules are redundant and cause this buggy
action. Other rules handle the behaviour of message controls
being visible on message box hover. Hence these can be removed.
Previously, if you scrolled down all the way in the left sidebar, and kept
your mouse hovered over a link, you had a feeling that there was still "more
stuff", since you could see the top of "Back to Zulip" peeking out over the
top of the URL Chrome (and maybe some other browsers) add in the bottom left
corner.
This just adds a bit of margin so that "Back to Zulip" is above that when
scrolled all the way down.
The function that was called here has no side
effects. If you don't use its value, it's just
wasted computation. The real action happens
in the subsequent calls to `rebuild_recent`.
Having it say "Clear" when you delete an existing status was a nice touch,
but it's confusing when you first open the modal and the text of the button
says "Clear".
I think the right medium-term solution here is for this modal to have "Save"
and "Cancel" buttons, and for there to be a small UI element in the user
popover itself that allows you to clear your current status.
We now use `fix_positions` to avoid cropping the emoji
picker. You can see cropping pretty easily on a short
screen if you click the smiley icon for reactions on a
message. It's a bit tricky to repro, since some
of the current top/bottom placements are correct, but
it's definitely reproducible.
I think there are opportunities to both simplify
and optimize `popovers.compute_placement`, so that it
plays nicer with `fix_positions`. For example, I would
bias it even more strongly toward favoring right/left
placement. But there are complicating factors--it is
also used by the hotspot code.
And I wanted to especially preserve the current
behavior when you launch the picker from the compose
box. That's one place where it looks pretty bad if
you select "right" instead of "bottom".
The fix_positions argument here fixes the horizontal
position of the stream popover.
It also fixes the vertical position, both in the default case, and
also doing an appropriate adjustment for the case that the color
picker is open.
This contains a few changes by tabbott to, rather than hiding the
arrow unconditionally, only do so when it would no longer point at the
right part of the screen.
Fixes#2374.
Fixes#6059.
Fixes#7290.
We use the `fix_positions` options every time
we launch a user popover, whether it is from
the message pane avatar or the buddy list
chevron.
For the message pane case, we can eliminate
some complexity related to trying to put
the menu above or below the avatar. We now
always suggest "right", and if there are
constraints due to being close to the edge
of the screen, the fix_positions code
will take care of it.
The patch to bootstrap will make the position smarter, but we still
want to preserve the 100px default vertical offset we chose for visual
reasons.
Tweaked by tabbott to preserve the visual design.
Changed <h5> to <p>, and removed the special formatting of
.empty_search_text to make this more in line with the formatting we
generally use with empty narrows.
This removes the left border extending the stream label from the
recipient bar in from the drafts in drafts modal. Those borders are
important in the message feed for containing several messages, but
here we're only ever going to show individual drafts, and this change
avoids potential color clashes with the blue box surrounding the
recipient blocks.
This removes the change in background to a darker one for active draft,
also removes the change in recipient_row_date color to blue; adds a blue
border around the draft box.
Since the bootstrap popovers are destroyed asynchronously so opening a
emoji popover in quick succession like by clicking the reaction button
on another message was causing a race condition which was causing some
operations to be applied on a destroyed emoji popover. This commit
fixes it by making sure to apply any operations only to the currently
active popover.
Fixes: #9851.
I'm torn about this, since there is good content here. But ultimately I think
* This page is a lot of work to write and maintain.
* In most cases, the right thing is for people to find the page that
explains the full feature. E.g. if you don't know what an "administrator"
is, the page I hope you find is "Roles and Permissions". For bots, it's
"Bots and Integrations". Writing a punchy short summary for a glossary
that does better than that is possible, but not fast.
* People find things via search, e.g. by Googling "What is X in Zulip",
rather than looking for a glossary.
* This page was written more than 3 years ago, before we had 100+ help
articles. So it may have served a purpose in the past that no longer
exists.
Adds three helper functions - `row_with_focus`, `row_before_focus` and
`row_after_focus` to get the focused, previous and next to focused
draft rows respectively.
`delete_id` in `drafts.js` referred to the next draft row which was
to be focused when deleting using hot keys. The var name was absurd
and is hence renamed.
Adds a `remove_draft` function which deletes the draft and updates the ui
by removing it from the list of drafts.
Also adds comments to increase readability.
Show "sent to different narrow" notification and other such notification by
notifications.notify_local_mixes for non locally echoed message sent by
current client.
With significant new comments added by tabbott.
Fixes: #11488.
Previously, this was only available in the Zulip development
environment.
Further work is needed on documenting this and how to use it for
managing work to follow up on.
The width of the messages div is set to 600px, while the
digest-email-container can be 500px at the most. Increasing the width
of the digest-email-container makes the /digest slightly more
readable.
The padding changes move the number a bit to the right and down, towards
where the bottom right corner of an unread count box would have been. This
makes the number look better aligned with the unread count boxes above it.
We swallow the error if our python_to_js_filter code is
unable to parse some python regex properly. This ensures
that the web app stays responsive.
We would fail to show an accurate local echo for these
regexes, however, the backend would act as the final
authority for handling the realm pattern conversion.
Since on replacing the first 'P<>' group, we remove this text from
the string, we have to make the RegExp start looking from index 0
again to properly convert later 'P<>' groups to JS regex syntax.
We want the search widget, when visible, to be
outside the scroll container for the stream list.
One obvious use case is if you start scrolling, and
then realize it might be less effort to search.
Also, for user search, it already worked this way.
We have to add a couple resizing hooks here, but
it's not necessary to change the actual resize
calculation, since we move the section inside
of #streams_header, which is already accounted
for.
The only markup change here is to add
a `stream_search_section` class. I don't
know why we use `notdisplayed` here instead of
jQuery, or what `input-append` is for, but I
considered them outside the scope of this change.
We can also remove some crufty CSS that was
compensating for it being inside the container.
First, we are not removing Group PMs from the
right sidebar, where most people see it.
There is a setting called:
[ ] User list in left sidebar in narrow windows
There are probably very few people that turn that on,
and even when they do, the setting only takes effect
when your window is less than a certain width.
This feature bitrots very quickly, because very few
core maintainers use it.
It's already kind of broken. It gets very crowded,
and we get CSS bugs when we move the right sidebar
into the left sidebar. (We can fix those bugs, but
they crop up unexpectedly due to the nature of CSS.)
We historically tried to maintain a ratio between
stream list, single-user buddy list, and group-user
buddy list, but the group-user buddy list gets
particularly crowded out, and it's basically useless
now.
We want to revisit the entire feature eventually, but
this commit at least gives the normal buddy list some
breathing room.
Also, if you need to see the info in the group PM
list, you can basically expand "Private Messages" to
see your recent group PM conversations. And if you
want to see who's actually online, that info is
already implicit from the normal buddy list.
If users have the option to put user lists in
the left sidebar for narrow windows, they will
now get 15px more of real estate in the left
sidebar.
I just removed the `-15` fudge factor.
We were double-counting the keyboard icon's
margin (8px) when figuring out how much room
we had for the two users lists.
Now we just use the safe outer height of
the anchor tag.
This change only impacts users who have the setting
to put the user lists in the left sidebar when they
have a narrow window.
First, we move ".right-sidebar-items" as an entire
group.
Second, we append the items to "#left-sidebar"
instead of ".narrows_panel".
The name `bottom_sidebar` was misleading, because it
includes the entire "normal" left sidebar.
It includes the 4 narrow links at the top plus the
stream/topic list.
We now call is narrows_panel.
Note that the left sidebar sometimes also includes
the user list (with a display setting turned on).
And it will eventually include other views.
We also remove an intermediate value in the resize
calculations.
This adds date dividers within a single message group when the only
reason we had previously been splitting apart two message groups is a
change of date. The overall effect is a cleaner message list user
experience.
The downside of this change would be that the recipient bars no longer
will always show a new date for date changes; to fix that, we rewrite
how the floating recipient bars both set the date field on the
floating recipient bar itself, as well as ensure that non-floating
recipient bars don't show duplicate dates.
In a future design update where we modify how message recipient bars
look, we may very well be able to simplify this logic by removing some
of the dynamic nature of the recipient bar calculations. But this is
a good implementation of what remains.
Tweaked significantly by tabbott from Steve Howell's original, both to
extract these changes from a larger PR as well as to modify the
first_visible_message logic to handle some tricky corner cases.
Fixes#10171.
On clicking the edit button for a stream description, the stream's
unrendered description should be made editable as text instead of
the stream's rendered description (which would be displayed as HTML
instead of text).
This completes the effort to use backend-rendered stream descriptions
here. Fixes#11272.
Use the results of commit #73d26c8 to remove the method
`render_stream_description` in static/js/stream_data.js and instead
use the rendered_description attribute now being sent by the backend.
This will be a valuable optimization and a step towards removing the
need for the marked.js markdown parser and speeding up the client end.
This changes the border-radius to 6px for the tabbed display, which is not
in line with the current Zulip style for border-radius (4px). However 6px
really looks a lot better for this (possibly because it's a bigger box than
most of our other boxes?)
The message_edit_history UI was incorrectly inheriting its content
div's structure from message_edit_content, i.e. the form for editing
message content, and not message_content, i.e. the class for rendering
the content of messages in the message feed (which we also use for
drafts).
Fix this by changing the inheritance, while also adding a (currently
unused) class for any future customizations.
Fixes: #5629.
This extract functions `get_mention_candidates_data` &
`filter_mention_name` to make code reusable and cleaner and further use
the logic in silent mention syntax.
Having a tiny bit of margin below the stream list
makes it possible to see the bottom of the scrollbar.
It also makes it so that the scrollbar activates
for a tiny range of list sizes where before the
last element would have been right up against the
bottom of the page, but we wouldn't scroll.
We need to move the update_group_date_divider call to run when a
message group is created. This achieves a few things:
* Fixes calling this multiple times useless for long message groups.
* It will soon no longer be correct to assume that every message
within a group has the same date, and in that case, we want to process
the date of the first message in the group, not of the last.
We only generate message_containers in one place, and that code path
already calls update_timestr. And update_timestr's effect only
depends on the message. Thus, this code was useless.
Steve Howell
Tim Abbott
okmanl
Alexandra Ciobica
varunvaruns9
vinitS101
overide
Boris Yankov
Rishi Gupta
Mohit Gupta
Wyatt Hoodes
synicalsyntax
Rohitt Vashishtha
Vaibhav
Anders Kaseorg
Hemanth V. Alluri
alex
sahil839
Challa Venkata Raghava Reddy
Vishnu Ks
Harshit Bansal
Pragati Agrawal
YashRE42
Puneeth Chaganti
Natsu Kagami
Amadeo234