Edit history of message was rendered directly without passing
it through rendered_markdown.js. Due to this several visual
features for dynamic elements like time, spoilers, mentions
etc were not available.
To fix above issues we pass the content of edit-history
through rendered_markdown before showing edit history modal.
Fixes: #16029.
Improves rendering of drafts to make it look more closer
to normal messages. This is done by passing the draft content
through rendered_markdown so that dynamic elements in the content
get updated before showing drafts modal.
Previousy, we used to show or hide the digest weekday setting after
saving the emails setting, but now we show/hide as soon as we check
or uncheck the email setting checkbox like we do for other settings.
Notifies user when messages are not being marked as read through a
banner that lets them mark all messages in the narrow as read. Note
that the banner is only displayed if the user's actions, like
scrolling, would've actually marked the messages as read.
This avoids distracting the user when viewing a thread they've already
read.
tabbott has verified that if new messages come in, the banner will reappear.
Fixes: #18768.
There are a few instances where we check if messages can be marked
read and mark that list as read when scrolled to bottom. Using
this would be nicer and also this function can be extended later to
display a banner when messages are not being marked.
Show/hide scroll to bottom button when the last message is
not visible in the current scroll position.
We adjust the bottom offset of the button based on compose box
height.
Fixes#19862
We save the preferred theme in localstorage so that user doesn't
have to re-select the theme on every reload. Users on slow
computers might see flash of a theme change, if it happens.
For filters that cannot be applied locally, we don't know if the
messages are still a part of the filter. So, we remove the
existing message that were updated and let `maybe_add_narrowed_messages`
treat them all as new messages to the filter.
This fixes the bug where existing messages that were present in
the narrow were not updated.
We want to avoid submit handlers here, because we may
have embedded widgets that have their own forms or
buttons.
We use "finalize" here to distinguish the two Create
buttons related to streams. You hit one button to
start the UI and then the second button to finalize
the process.
I also fix the bad test idiom of clicking on the
sea-green button.
When viewing a narrow such as a search or `sender:` view, where
consecutive messages in the view may not be consecutive in their
original stream/topic context, we should avoid displaying the messages
with a shared sender/recipient bar header, as that creates the
incorrect perception that they are consecutive.
Back in 2013 (bc8bc8567b), we
implemented this via the collapse_messages flag, but it appears more
recent refactoring (no more recent than
dbffb2a614) made it always true.
The original logic was incorrect, in that it only considered full-text
search views, and not other views with this property.
I originally planned to use the existing logic for
can_mark_message_read designed for this purpose, but I think there
might be product reasons why might want the logic to be independent.
Previously the emoji_status set by the user would only be seen in a
few places, it was decided that it would be useful to show the
emoji_status in a couple of other additional places as well.
As such this commit uses the status_emoji template to show the status
emoji in the compose_pm typeahead and the mentions typeahead.
Status emoji changes do not live update these, but neither do user
renames, so there's bigger problems if that's a concern.
Fixes: #19865.
Previously the emoji_status set by the user would only be seen in a
few places, it was decided that it would be useful to show the
emoji_status in a couple of other additional places as well.
As such this commit uses the status_emoji template to show the status
emoji in the compose_pm pills. Due to the fact that we use the same
pills system to render in the user_group, we need to add a
conditional to prevent rendering there since the user status is not
valuable there.
Status emoji changes do not live update these, but neither do user
renames, so there's bigger problems if that's a concern.
Previously the emoji_status set by the user would only be seen a few
places, it was decided that it would be useful to show the
emoji_status in a few additional other places as well.
Use the status_emoji template to show the status emoji in the
message_body and also implement live update behavior.
With refactor and minor edits by Yash RE.
Co-authored-by: YashRE42 <33805964+YashRE42@users.noreply.github.com>
Previously the emoji_status set by the user would only be seen in the
buddy list, it was decided that it would be useful to show the
emoji_status in other places as well.
As such this commit uses the status_emoji template to show the status
emoji in the PM list and also implements live update behavior.
With refactor and minor edits by Yash RE.
Co-authored-by: YashRE42 <33805964+YashRE42@users.noreply.github.com>
Previously, when the user clicked the `Add streams` icon in the
streams list sidebar, we provided a popover offering to create or
subscribe. This was confusing for users who did not have permission
to create streams.
Redirect users that don't have stream creation permissions
directly to browse streams without going through this popover.
Fixes: #20676.
Previously, if the user changes any stream color and updates it back
to the default color without reopening the change color popover, the
second color change didn't take effect.
Fix bug by destroying the colorpicker object and rebuilding it again
every time a color change is triggered by the confirm button.
Fixes: #21055
Previously, we would call `rerender_messages_view()` in order to
rerender messages after user renames or avatar updates. This would
lead to rerendering the entire message list for every change,
regardless of whether any specific message had changed or not.
This used to be acceptable because user renames and avatar updates
were rare events, however, as we plan to show user status emoji near
user names and updates to those would be more frequent than is
affordable, this commit implements
`rerender_messages_view_for_user(user_id)` which only rerenders
messages which have actually been changed.
This commit is, thus, both an optimisation for the existing code and a
prep-commit for the user status emoji.
Previously, we used to only calculate sender_is_bot, sender_is_guest,
small_avatar_url and background_color on the message_container via
build_message_groups (ie via .render, which also gets called from
.rerender_with_target_scrolltop).
This would mean that if we tried to use `_rerender_message` to update
just a single message (which is something we'd like to do, in order to
make rerenders more efficient), these values would not update.
(This could lead to avatars not light-updating properly).
As such, this commit moves assignment of these values into
`set_calculated_message_container_variables`.
There is no problem in behavior of browser back button we open stream settings
overlay using UI elements since they are appropriately linked to "#streams/all",
"#streams/subscribed" and "#streams/new", but someone can directly go to a
link with "#streams" and in this case we want to fix the browser back button.
This commit replaces "#streams" entry with "#streams/subscribed" which is the
default section opened, such that pressing back when on "#streams/subscribed"
does not go to "#streams" and instead go back actually.
When we open settings overlay we first go to "#settings" hash and
then to "#settings/profile" or hash according to the last opened
section. Now when a user presses back button from "#settings/profile"
it goes to "#settings" which agains then changes to "#settings/profile"
and thus the browser back button does not work as expected.
This commit fixes this by replacing the "#settings" entry in history
with "#settings/profile" or to the hash as per last opened section,
using replaceState and thus there is no entry of "#settings" in history.
Fixes#19820.
Apparently, we were only dispalying the edit history option in the
message actions popover if the topic/content were changed. Fix this by
adding a small adjustment to the conditional to include stream
changes correctly.
I also clean up all the mutations of `user_ids`
in the calling code. We now have:
pill_user_ids
active_user_ids
user_id_set
user_ids
The new function is exported in anticipation of using
it from stream_create.js.
This commit adds a method of marking an overlay as being meant to be
left open despite click events triggering that would normally close it.
This is to prevent the case where a user drags an image and "unclicks"
in an area where normally clicking would close the overlay.
This commit attempts to revert the lightbox state (at least
the pan/zoom part of it) when the lightbox is closed. The open()
function has been turned into a factory function so that the zoom
control which is instantiated on initialization of the lightbox can be
passed in to the on_close handler of overlay.open().
This PR changes how the Pan & Zoom feature of images displayed in the
attachment lightbox are handled.
The existing method of using a canvas element is replaced by the Panzoom
library (timmywil/panzoom). This library is lightweight and has 0
transitive dependencies.
This fixes#20759 where the issue is that the viewport of a zoomed image
was not expanding to fill the available space on the page. Switching to
this new library also solves several other UX issues:
* Images are no longer blurred when in Pan & Zoom mode.
* The zoom behavior itself uses focal point zooming: zooming occurs
where the cursor is on the image instead of at the center of the
image, reducing the need for extra panning.
* CSS transitions are used for a more visually pleasing experience
when switching images, toggling zoom off, etc.
* The library has the potential to open other file types which
leaves that option open for us in the future.
It seems like orange is the loudest possible color to
denote a quasi-neutral-idle state, so we hope to
replace it with another color.
This commit does not change any styling.
I removed the sentences in the doc, since they are
kind of too vague to be useful. If we want to say that
the idle state is correlated with the half-orange
circles in the buddy list, then we want to say that
more specifically.
Steve Howell
Purushottam Tiwari
NerdyLucifer
Sahil Batra
Dinesh
Tim Abbott
Aman Agrawal
yogesh sirsat
jai2201
YashRE42
AnushaNathRoy
Mr.mad
Ganesh Pawar
Anders Kaseorg
Austin Riba