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.
Our html collects extra spaces in a couple of places. The most prominent is
paragraphs that look like the following in the .md file:
* some text
continued
The html will have two spaces before "continued".
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.
I was hoping this would make things faster... it does, but sadly only
by about 70ms, 5% of this file's test runtime.
It sure does make this file rather less action-at-a-distance, though,
as well as fixing some duplication.
If we make a practice on the Zulip server of always explicitly setting
the desired priority, then when an old server doesn't set the priority
we can reasonably have the bouncer make a guess.