The mobile app was never able to use the shared
version of emoji.js, because, among other problems
with our code organization, the emoji.js module
is strongly based on a mutate-the-data paradigm
that doesn't play nice with React. The way
that we mutate data and violate encapsuation
here is something that we would mostly want to fix
without even trying to shared code with mobile, so
subsequent commits will try to extract some pure
functions into a shared module.
The backend validates that URL inputs are RFC valid URLs (with no
specific length limit), but the frontend appears to have a maximum
length of 50 specified, likely because of a copy-paste error.
Increase the HTML maxlength for this input to 2048, which is a length
supported for URLs by all major browsers.
Fixes#21633
The feature deactivates the bot user; Zulip has no "delete bot"
feature. So fix the label to match what it does.
We also change the icon to match the one we use for deactivating users
in the "Manage users" UI.
Fixes#21619
We need to adjust height of recent topics along with the app
otherwise the container becomes separately scrollable due to
it overflowing the app height.
This is definitely better than having linkifiers
reach directly into marked.js, but there is
probably further improvement we can do here
to clean up how these regexes get set.
This introduces a circular dependency between
markdown.js and linkifiers.js, but we will
soon break it in the other direction.
Note we now avoid linkifier checks for the case that a message
contains more obvious backend-only syntax such as attachments.
The next commit will eliminate the ugly early-return.
This gets us closer to having an API that can
be used my mobile.
The parse() function becomes a subset of
apply_markdown() that is no longer coupled
to the shape of a webapp object, and it can
be supplied with a new helper_config for each
invocation. Mobile will likely call this directly.
The setup() function becomes a subset of
initialize() that allows you to set up the
parser **before** having to build any kind of
message-specific helpers. Mobile will likely
call this directly.
The webapp continues to call these functions,
which are now thin wrappers:
* apply_markdown (wrapping parse)
* initialize (wrapping setup)
Note we still have several other problems to
solve before mobile can use this code, but we
introduce this now so that we can get a head
start on prototyping and unit testing.
Also, this commit does not address the fact
that contains_backend_only_syntax() is still
bound to the webapp config.
We were showing the push notifications tooltip in user default
settings section even if the push notifications were configured
on the server.
The bug was because the setting value was undefined in the template
used for user default settings section, so this commit fixes the bug
by correctly passing the setting value to relevant template file.
Fixes#21602.
We use `fadeOut` effect to hide the scroll to bottom button more
widely. We already use `fadeIn` effect to display the button
every time.
We deliberately don't use the `fadeOut` effect when doing
`make_compose_box_full_size` to avoid any button overlap with
compose for a short time.
The implementation closely follows `handle_deactivation()`.
Using the same existing reactivate confirmation modal.
Also, this commit will also lead to open confirmation modal
to reactivate bots in settings > bots, and currently there is no
existing confirmation modal for deactivating bots.
This commit is a follow-up of #21436.
We previously added support for showing the status_emoji to the PM
list, but we only supported individual PMs and not group PMs, this is
prep commit towards supporting group PMs.
We previously added support for showing the status_emoji to the PM
list, but we only supported individual PMs and not group PMs, this is
prep commit towards supporting group PMs.
Previously, we were experiencing a regression in the positioning of
the play icon for youtube previews, as such, this commit uses a
previously created `handle_video_preview_mouseenter` to ensure the
positioning is always correct.
This is an ugly way of doing things, because this could be handled
directly through CSS flexbox, however, it is an acceptable temporary
fix.
This commit extracts the logic used to ensure that the play icon is
correctly positioned over the video preview for embedded videos, with
the intention that we can use this to fix a regression in the play
icon positioning for youtube video previews.
We render a login button for images that failed to load for
spectators. The image failed to load most likely due to being
rate limited by the server.
Fixes#19840
f0c680e9c0 introduced a call to
message_helper.process_new_message without first calling
message_store.set_message_flags on the message.
This resulted in it being possible as a race, when loading the Zulip
app to a stream/topic/near narrow, for a message to have the
`historical` flag be undefined due to not being initialized.
That invalid state, in turn, resulted in the message_list_view code
path for rendering the message feed incorrectly displaying additional
recipient bars around the message.
We could fix this by just calling message_store.set_message_booleans
in this code path. However, this bug exposes the fact that it's very
fragile to expect every code path to call that function before
message_helper.process_new_message.
So we instead fix this by moving message_store.set_message_booleans
inside message_helper.process_new_message.
One call point of concern in this change is maybe_add_narrow_messages,
which could theoretically reintroduce the double set_message_flags
bugs detailed in 9729b1a4ad. However, I
believe that to not be possible, because that call should never
experience a cache miss.
The other existing code paths were already calling
set_message_booleans immediately before
message_helper.process_new_message. They are still changing here, in
that we now do a cache lookup before attempting to call
set_message_booleans. Because the message booleans do not affect the
cache lookup and the local message object is discarded in case of a
cache hit, this should have no functional impact.
Because I found the existing comment at that call site confusing and
almost proposed removing it as pointless, extend the block comment to
explicitly mention that the purpose is refreshing our object.
Fixes#21503.
This eliminates an annoying bundle of complexity that caused the
frontend markdown processor's interface with the rest of Zulip's new
message processing code paths being more similar to that of a new
message from the server.
It also cuts down on code duplication.
The previous message.unread block in insert_local_message was
non-functional. markdown.apply_markdown is overriding what that set by
calling message_store.init_booleans, which happens to set the same
value for the `unread` flag, and then setting individual message
booleans as it finds elements like mentions during rendering.
Improve this situation partially by deleting the message_unread block,
and adding conversion logic to translate what the markdown processor
is doing into message flags.
Then, we can call message_store.set_message_flags just like we do when
processing new messages arriving via the API. This will be helpful
shortly, when we deduplicate the calls to
message_store.set_message_flags.
As noted in the lengthy TODO, this exposes the fact that we should
really rework how the frontend markdown processor returns the
mentioned state to its caller.
There is config_data for the embedded bots only for giphy and
followup bots, so we send "config_data" field to API only for
those bots and not others. Send config_data field as {} to
the API for other bots raised InternalError earlier.
On changing bot owner, "delete" event is sent to the previous
owner if previous owner is not an admin. We were ignoring the
"delete" event in webapp previously, but now we update the
bots page in personal settings to delete the bot. Note that
we do not remove the bot from the organization list of bots
currently, since list_widget does not support removing a
row as of now.
In case of previous owner being an admin, the previous owner
receives "update" event and thus the bots list is updated
from that event.
The code for ignoring "delete" event was added in fba2708bbc,
to basically avoid failed lookup for id in the organization
list of bots. I have tested and there cannot be a case of
a failed lookup in the list as per current code for list_widget
module and we are anyways safe after a reload or after closing the
overlay as the list will be updated correctly.
Discussion thread -
https://chat.zulip.org/#narrow/stream/321-settings-system/topic/List.20render.20.2315033Fixes#20856.
The "download" attribute on the button only functions for same-origin
requests; thus, the download endpoint must be used in order for the
"Download" button to function for uploaded images which are stored in
S3, and thus served from a different origin.
This is only done for uploaded images; it does not address a similar
problem with Camo, when Camo is hosted on a different hostname.
Fixes: #19238.
Currently, when deactivating a user, we have a "Saving..." loading
indicator and any error message displayed in the heading area of the
users table.
Migrate this to instead do the loading indicator and error message
inside the modal, where it's more in context.
As detailed in this conversation:
https://chat.zulip.org/#narrow/stream/137-feedback/topic/recent.20topics.20timestamps/near/1337670
This time format change is not working out as an improvement for at
least some users, myself included.
I think we do want to use some of the refinements attempted here (and
in particular, I'm keeping the new function with its nice test suite),
but I think it's better to revert now and fix forward in a future
release.
See #19775 for added background.
Render tooltip to stream_sorter_toggle buttons using
appendTo method of tippy.js to ensure that tooltip doesn't
get hidden behind the parent container and is visible
completely.
Fixes#21329.
This commit adds a tippy tooltip to the lightbox title which enables the
user to view the filename of an image if the filename is different than
the image title.
Fixes: #21333
This commit adds a tippy tooltip for inline image previews in messages.
There exists some (reasonable) logic in `static/js/util.js` which
overrides all title attributes for links to user-uploaded content to
ensure they always display "Download <filename>". This doesn't make
sense for inline images specifically because they will be opened in a
ligthbox, so we prevent that.
There is an additional tippy instance created in `static/js/tippyjs.js`
to add tippy tooltips to inline images, which takes advantage of the now
preserved title attribute of the parent link.
Creates a helper function in `message_edit.js` that loops over
a message's edit history to see if a stream and topic pair
existed at some point in the message history.
Exports `util.lower_same` function to use for comparing
edit history topics as lowercase.
Also adds test for new function in `mesage_edit` node tests.
We check if stream and topic present in the URL match that of
the message in its current state. If message is not available locally,
we fetch it before rendering the narrow.
Fixes#15290.
It turns out that the bug this call hopes to fix only happens when the
user first loads the page to recent_topics and then navigates to a
view with a message list (any other view), but we'd make this call
every time the recent topics table was hidden.
Hence, this commit makes it such that we only make that call if (1)
the page is loaded to recent_topics and (2) we're switching from
recent_topics to a message list view for the first time. We achieve
(1) via binding a handler via ui_init.initialize_everything and (2) by
binding the handler as `.one`, so that it's unbound after its first
invocation.
Additionally, we use window.requestAnimationFrame to prevent this
forcing the browser to do a reflow unnecessarily.
Combined with other commits in this series, this fixes a major
performance problem when leaving recent topics for another view.
See #20255 for details.
The name for a BigBlueButton meeting is now generated from the stream
name and topic name.
The createTime option is used to have the user redirected to a link
that is only valid for this meeting.
Even if the same link in Zulip is used again, a new createTime
parameter will be created, as the Meeting on the BigBlueButton server
has to be recreated.
Fixes#16498.
Fixes#20509.
Fixes#20804.
The previous logic didn't make sense -- the scroll offset in recent
topics is not a scroll offset within a message list, so saving it was
useless at best.
However, it was actually much worse than that, because trying to save
the pre-narrow offset while in the process of navigating away from
recent topics had the side effect of forcing a reflow, which resulted
in very expensive browser rendering to no purpose.
Adding this commit to the rest of the series of commits fixing
rendering issues when leaving recent topics, this commit results in an
impressive 3.05 s decrease in the first renarrow, an ~ 300 ms decrease
in the second renarrow and an ~ 500 ms decrease in the third renarrow.
There are still further forced reflows which could be reduced in this
render path, but they seem to not be as severe.
This is partially a prep commit to correctly saving/restoring the
position of the blue message select box when using browser
back/forward navigation, and partially a bug fix that ensures that
switching from "all_messages" to "recent_topics" preserves one's
position in "all_messages".
Note that this is with regards to saving the visual position of the
selected message, not about saving "which message was selected".
If the target user is deactivated, `Reactivate this user` will be
shown as one of the options in the small user profile popover, where
`Manage this user` would usually be.
We rename `show_manage_user_option` to `can_manage_user` because now
it will also be used as the common condition for whether the current
user has administrative permission to active or deactivate the target
user.
The implementation closely follows the existing deactivation modal.
Fixes#21428.
chat.zulip.org discussion:
design > reactivate user from user popover
The ready method was deprecated in jQuery 3.0, because its behavior
has nothing to do with the selector; it always waits for the page to
become ready, not a specific element.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
It was broken by commit f5fbf5f0e0
“change_password: Migrate modal to dialog_widget” (#20193), because
the new_password input didn’t exist when we tried to install an event
handler for it.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Co-authored-by: Steve Howell <showell@zulip.com>
Co-authored-by: Tim Abbott <tabbott@zulip.com>
This commit adds the backend functionality to
mark messages as unread through update_message_flags
with `unread` flag and `remove` operation.
We also manage incoming events in the webapp.
Tweaked by tabbott to simplify the implementation and add an API
feature level update to the documentation.
This commit was originally drafted by showell, and showell
also finalized the changes. Many thanks to Suyash here for
the main work here, which was to get all the tests and
documentation work moving forward.
Previously, we did not clear the resolved topic warning when reopening
the compose box after sending a emssage. This was a latent bug before
the previous commit, since the resolve topic was always displayed when
the compose box was pointed at a resolved topic before the previous
commit.
The resolve topic warning can feel like clutter in the event that the
compose box is empty (which often occurs when the user has no intent
to send a message), so we configure the validation logic to only
display the notice when the compose box is non-empty.
We take some care to minimize work the function is doing, beacuse it
is called on every keystroke in the compose box.
Fixes: #21155.
The 3 instances of dropdown_list_widget using the `label` property had
different design than the rest of all of our dropdowns, in that the
label was on the same line as the dropdown.
Fix this by adjusting the `label` option to use our standard
`dropdown-title` CSS class.
Also remove the colons in the labels.
I confirmed that these were the only instances of this widget using
the label feature.
Fixes#20415.
The most plausible situations through which one would press these
hotkeys with the compose box still open are accidents (basically,
you're trying to type but the browser focus is unexpectedly not in the
compose textarea).
So we disable these keyboard shortcuts when the compose box is open,
regardless of where keyboard focus lies.
Fixes#21128.
Starting composing a message to a new recipient will clear the compose
box. Previously, we were saving drafts before doing so only in the
compose_actions.respond_to_message code path (i.e. when starting a
reply). Logically, this behavior should apply regardless of why we're
initiating a new message, so it belongs in compose_actions.start.
Fixes#21128.
Fixes#21171.
In stream edit and stream create replace the existing checkbox
format for choosing "stream post policy" with dropdown widget.
In "stream_types.hbs" implement the dropdown menu and remove
the checkbox format for selecting "stream post policy".
In "stream_create.js" and "stream_edit.js" edit the code for
"stream_post_policy" to extract the "stream post policy" value
from the dropdown menu after submitting the form.
In "stream_data.js/stream_post_policy_values", change, the object to match
the following order and description of these policies:
1. Everyone [Default]
2. Admins, moderators and full members
3. Admins and moderators
4. Admins only
This sorts from least to most restrictive.
We loop through edit history entries and see if any of them
are more interesting than a (un)resolve topic edit, extending
the existing loop we had.
We also update the associated node tests.
Fixes#19919.
Co-authored by: Lauryn Menard <lauryn@zulip.com>
Updates the simulated edit history entries that are saved when
`update_messages` events are received for the modern data
structure on the server for `message.edit_history` entries.
Also cleans up a misnamed field in said entries, `edited_by`.
Uses the `rendering_only` field in the `update_message` event
to filter the addition of `last_edit_timestamp` to the message,
which is what triggers the addition of an `Edited` notification
when a message is rerendered in the web app.
Also, removes the deletion of `msg.last_edit_timestr` since this is
regenerated every time the message is rendered, and so it did nothing
beyond confusing the code.
We already show the error if topic input is empty and it is
not allowed to send messages without topic in the organization,
and this commit also shows error when topic is "(no topic)".
The topic is set to "(no topic)" when someone sends a message
with empty topic input box and when it is allowed to send message
without topics in the organization.
This is not ideal behavior as we may want to treat "(no topic)"
differently from empty topic, but we can fix this in future and
this commit can be a short term fix.
Fixes#21344.
We have two different frontend implementations of computing the
un-resolved form of a topic name, and they have a subtle -- but
intentional -- difference in behavior.
Factor them both out into the resolve_topic module, along with
their inverse, and with comments and tests.
These two conditionals are each relying on the other to trigger
on the same condition, and to do complementary things. Move them
together to a single place so that that relationship is easy to see,
and to refactor.
The most notable change here is that when you are adding
subscribers to a stream as part of creating the stream,
you can now use the same essential pill-based UI for
adding users as we do when you edit subscribers for an
existing stream.
We don't try to exactly mimic the edit-stream UI or
implementation, since when you are adding subscribers
during create-stream, we are just updating a list in
memory, whereas in the edit-stream UI, we immediately
send info to the server.
Fixes#20499
This unfortunately requires somewhat ugly duplicated code, but I think
it's the best option for now.
I expect we will somewhat soon work on the transition to no longer
have two duplicate fetches here, and doing so will let us remove this
secondary code path.
Fixes#21304.
Prefer a regexp match over using String#replace to strip expected
prefixes and suffixes because (a) it implicitly verifies that the
input has the expected format and (b) it won’t unexpectedly strip from
the middle of the string.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Muted streams are now greyed out in the personal settings,
also changes to the notification settings of a muted stream are
not possible anymore.
Also, add a bell-slash icon after the stream name of muted streams,
clicking on it unmutes the stream.
Fixes#19780.
Previously, updating the UI when streams are muted was split between
two places: The server_events.js code path, which updated the checkbox
state and other parts of the app, and checkbox click handler, which
toggled the disabling of the notification settings checkboxes.
Move these to all live in a single place.
With the recent changes to lightbox image handling in #21145 and #20788
it is no longer necessary to have panning and zooming disabled by
default. This commit removes the enable/disable button and instead
replaces it with a "Reset Image" button, and enables panning and zooming
as the default state of the lightbox.
This commit attempts to prevent images with long filenames,
descriptions, or author names displayed in the lightbox from altering
the layout of the page.
It also adds a title prop to both the filename and author, allowing a
user to hover and see a tooltip of the full text in the case where the
text is truncated.
Fixes#21058.
Hides 'disable' button of any kind when nothing is selected
in dropdown list widgets by removing ':enabled' selector from
the button, the button is not actually a button, it's an <a> tag which
doesn't support "disabled" attribute.
Fixes part of #20831.
It's 2022 and the WHATWG no longer recognizes the term URI. Everything
is now a URL or a type of URL. Which is great because it's way less
confusing. Details here:
https://url.spec.whatwg.org/
Moves hash_util.by_stream_uri and hash_util.by_stream_topic_uri to
internal_url so they can be used by external codebases. Due to these
functions being called in many places in the web codebase, wrappers
for both functions are left in hash_util in order to keep these
calls simple.
Also adds test for explicitly testing each function.
Move hash_util.encode_stream_id to internal_url, so it can be shared
with external codebases. Also add a test that explicitly tests escaping
special characters in stream names.
Move stream_data.id_to_slug to internal_url, making it shareable. The
function has been renamed to stream_id_to_slug to reflect that it
operates on a stream id.
Moves the encodeHashComponent and decodeHashComponent functions out of
hash_util and into internal_url which belongs to shared. This is to
accommodate sharing of this code with mobile or any other codebases that
do not wish to duplicate logic.
In order to accommodate the sharing of hash_util with other codebases
including mobile, UI and web specific code should be removed. In this
commit, we remove exception handling for the decodeHashComponent
function and instead add the UI handling of it further up the call
stack.
The stream_data.id_to_slug and stream_data.name_to_slug
functions mistakenly used Javascript's String.replace method,
this commit changes it to use String.replaceAll, the result
being slugs generated from streams with names greater than
2 words are now properly formatted.
An attacker could maliciously craft a full name for their account and
send messages to a topic with several participants; a victim who then
opens an overflow tooltip including this full name on the recent
topics page could trigger execution of JavaScript code controlled by
the attacker.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
In open_edit_form, we had an initialization order bug where we called
set_up_external_account_field_edit_form, which clears the field name
field if the external account is of the "custom" type, after
populating the initial values for edit form.
This resulted in these fields being displayed as empty in the UI for
this field type. Fix the issue by reordering the initialization.
Fixes: #21262.
This reverts commit f3964673e7.
It broke drafts_scroll by confusing jQuery object APIs with DOM
element APIs.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit removes the unnecessary `data-list-widget` attribute
present in the <div> and <tbody> tag for muted_topics and muted_users table.
It became unnecessary/useless in 19cf6d0e04 and
then was renamed while still useless.
Also uses the correct variable name `muted_topic` and `muted_user`
instead of `muted_topics` and `muted_users` to render a item of their list
in DOM through Listwidget.
This changes the method of rendering list of alert words in DOM,
earlier it was rendered using 'for' loop over the array of alert_words
which is now changed to render using ListWidget, which gets a array
of objects from get_word_list() in alert_words.js.
The use of ListWidget helps to define a parent_container and $container
in table-body of alert-words-table using which we can now apply sorting over
alert words with the help of handle_sort() function in list_widget.js
Changed the method of adding alert_word_settings_item row in table body
through {{#with}} loop because of rendering through ListWidget, which was done
earlier using for loop over each alert-word in while rendering the list.
this commit also mocks template of render_alert_word_item
while mocking ListWidget.create() function in render_alert_words_ui().
and checks that ListWidget.create() is not called when variable `loaded`
is set as false.
Fixes#21142.
We follow how other apps present older messages, e.g. Gmail,
Facebook Messenger, etc. display it.
Specifically, the logic we use is:
If the time is <24hr ago, show an absolute time, like "21:30" (or "9:30pm").
Otherwise, show what day it was, and not a time
If the day was yesterday, say "Yesterday".
Otherwise, if it was <7 days ago, say the day of week, like "Friday".
Otherwise, if it was <1 year ago, say the month and day, like "Sep 6".
Otherwise, say the year, month, and day, like "Sep 9, 2020".
With some tweaks from Tim Abbott to better handle the future case.
Fixes#19775
Previously, update_user_data was called when deactivating
bots, but it was removed in 58b612a4f0.
Now, update_user_data is only called for 'type="realm", op="update"'
events, but these events are not sent when deactivating or
reactivating a user or bot, so this code is not used.
This commit changes the code to call update_view_on_deactivate function
from server_events_dispatch.js on receiving the user/bot remove event
instead of having it repeatedly in the success_continuation method
of click handlers.
We also add check to make sure we return early if the relevant settings
page is not opened yet.
This commit adds option to deactivate user to "Manage user" modal.
A modal is opened on clicking the option to confirm the deactivation
and the "Manage user" modal is closed.
The error from the server, if any, is shown in the modal itself
and in case deactivation is done successfully, the modal is closed.
Fixes#18944.
We pass handle_confirm function as an argument to confirm_deactivation
because we will use confirm_deactivation to deactivate the user from
user-info popover and the popover case will have a different handle_confirm
function (which is called after clicking "Confirm" button of the modal)
since error handling in that case will be different as there will be no
overlay in the background.
This commit adds a method to detect whether the draggable element has
moved out of view and if it has, move it back into view.
The panzoom library does have a `bounds` option that is supposed to
provide the functionality, but at the time of the commit it does not
appear to work correctly. Upstream bug:
https://github.com/anvaka/panzoom/issues/112
This PR changes the library used for panning and zooming in the lightbox
module from timmywil/panzoom to avanka/panzoom.
The original (timmywil) version of the library contains a bug where if
you have a high resolution touchpad and Firefox and you zoom in and out
repeatedly on an image, the image may drift. avanka/panzoom does not
appear to display this behavior.
Restores the behaviour from before 5f83bc5cfe, where clicking
outside the image closes the lightbox, primarily by way of swapping
out the panzoom library.
Fixes: #21163.
We are going to move to this code organization for
managing streams:
stream_create.js
stream_create_subscribers.js
stream_edit.js
stream_edit_subscribers.js
The modules stream_create.js and stream_edit.js historically
manage the entire process of creating and editing stream
data (respectively).
Going forward both will delegate most of the subscriber-specific
pieces to either stream_create_subscribers or stream_edit_subscribers.
The stream_*_subscribers modules will be somewhat similar in
nature, but the way that we manage subscribers at creation time
is a bit different than how we manage subscribers at edit time.
This will help us avoid some duplicate code when
we use input pills for stream-create.
See the long comment in set_up_handlers() for
more context.
We also rename:
submit_add_subscriber_form -> subscribe_new_users
Ideally set_up_handlers() would also extract the
concept of clearing the pills as soon as you either
hit enter or clicked on the Add button, but our
current paradigm for clearing pills when you edit
subscribers for an existing stream on the Subscribers
tab is that we wait for the server to acknowledge
the request. I believe this is a bit of a misfeature,
but I am punting on that change for now.
This is mostly a pure code move. A few small tweaks:
* The create() function is new.
* The new module doesn't assume a `pill_widget`
global.
This module represents the truly re-usable code
that can be shared during these two user actions:
* edit-stream subscribers (now)
* create-stream subscribers (future)
In both situations the input pill has (or will have)
essentially the same behavior, and the next commit
will tighten up the abstraction.
(The two processes will both also use fairly similar
ListWidgets, but the mechanics of managing the list
are going to be different, so we do not intend
to keep around stream_subscribers_ui in its current
name. More on that later.)
This simplifies some of our dependencies.
As an example, we really don't want compose.js
to depend on stream_subscribers_ui.js, since
the former doesn't use any actual UI code from
the latter.
We also rename the two functions here:
invite_user_to_stream -> add_user_ids_to_stream
remove_user_from_stream -> remove_user_id_from_stream
(The notion of "inviting" somebody to a stream is
somewhat misleading, since there is really no invitation
mechanism; you just add them.)
Apart from naming changes this is a verbatim code move.
Finally, we eliminate a little bit of test cruft--the
`override` helper already ensures that a function gets
called at least once during a test.
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.
This function is not used currently after we removed the
"Group PMs" section from right sidebar in 43e5b2d28b.
This commit also removes presence.is_active function as it
was only used in buddy_data.huddle_fraction_present.
This commit updates the error message shown on sending a message
with no topic in an organization with mandatory_topics setting
set as true to match the error message in API.
Autosize library can miss resize of compose-textarea when
compose is collapsed / expanded while preview box is displayed
and compose-textarea is hidden. So, we force a autosize.update
of compose-textarea, when user exits markdown preview, to ensure
that the textarea is of correct size.
Fixes#19353
Instead of blindly adjusting `compose-textarea` on resize,
we adjust the height of `compose-textarea` or `preview_message_area`
based on which is visible.
This commit creates the function warn_if_topic_resolved that checks if
the topic to which the user is composing is resolved or not. First it
checks if the stream exists and then if the topic name starts with the
RESOLVED_TOPIC_PREFIX. If the conditions are true, a warning banner is
shown to the user.
It also shows to the user a button to unresolve the topic, if he has
the permission to do so.
Fixes#20584.
The previous internationalization approach didn't support languages
with a different word order than English.
We also switch to using "moved" to explain topic/stream moves,
consistent with how the message feed explains it.
The recent commits to display the previous and new streams for a moved
message did not correctly handle messages moved multiple times.
To do this, we need to do a somewhat awkward loop, at least until we
modify the API to do this loop for us.
This commit fixes two things -
- We use the exact same color that is used for stream name in
day mode.
- Previously, we were passing black color explicitly to the
stream_privacy_icon template. This commit changes it to pass
different color in the night mode which is the same used for
stream name in night mode.
`bookend_top` is already defined firmly for `group` in
`add_subscription_marker`, so no need to redefine it.
`bookend_bottom` is no longer used anywhere in the codebase. Not
sure what the history is here.
We need to mark trailing bookends differently to identify them
in DOM easily. This fixes a bookend replication bug which can
happen sometimes when rendering.
We move the stream subscribed/unsubscribed bookend info from
js files to bookend handlebar.
Tweaked by tabbott to override the check-templates indentation logic.
This effectively reverts part of
70d444a8eb. While it's correct that we
want to render this bit of Handlebars template early, it was not
correct to move all compose box initialization earlier.
Do the same thing we do with the left/right sidebar container
templates, which is to render them directly in `ui_init.js`.
Fixes#20778.
In English, compound adjectives should essentially always be
hyphenated. This makes them easier to parse, especially for users who
might not recognize that the words “web public” go together as a
phrase.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit refactors the code to directly pass sub object to
selected_stream_title template instead of passing name, is_web_public
and invite_only as different parameters.
The content which is scrollable is moved left by the width of the
scrollbar when scrollbar is visible. The navbar, floating recipient bar
and composebox doesn't move. We reduce their width by scrollbar width
to adjust for the reduced width of the scrollable content.
Since floating recipient bar is center aligned (with margin: 0 auto)
we also have to move left by half the scrollbar width.
Group css classes having the same value being assigned together. This
makes the code easier to understand.
We no longer limit our list of candidate topics
to 300.
We continue to limit the topic results to 10, since
we don't want to overwhelm users or crowd out
non-topic-related suggestions.
We try to handle this is an efficient manner.
We were showing # for all types of streams in the title at the top
in the right column of stream settings overlay. This commit fixes
it to show globe icon for web-public streams and lock icon for
private streams.
Added a placeholder key to the polls slash command object. This is
selected and highlighted after being typed ahead in the compose box.
For slash commands without placeholder, everything works as before.
Formatting hints can easily be added for other slash commands too,
by adding a placeholder key to their object.
Fixes part of #20868
When users tabs through the message action icons, they used to
persist even when the focus is not on them. We manually
destroy them on blur event since tippy has some issue with
handling elements with opacity hiding effect.
Called the `decorate` function to update stream color in the compose
box on `change` instead of `blur`.
On clicking on a stream option, the input box for the stream name
remained in focus, hence decorate wasn't triggered on blur. Using
the change event instead, ensures that decorate will be called
anytime the stream is changed.
Fixes: #20871
Initialised `this.me` for the TaskData using a constructor to the
current user id.
The bug was caused due to `this.me` never being initialised, and hence
`idx` wasn't incremented on page reload, which resulted in duplicate
`data-key` attributes and hence new todos overwriting older todos with
the same `data-key`
Fixes: #20698
Navigation key presses like `Up` and `PageUp` with an empty recipient
boxes will now close the compose and propagate the keypress to the message
list or recent topics, depending upon the active view.
This extends behavior we've had for a long time with focus in the
compose box itself.
The data field will be a union type when it is converted to typescript.
This approach allows us to avoid introducing additional type check for
both of the properties.
We show user name in heading of the deactivation confirmation
modal instead of email, since there can be a case when admin
does not have access to real email and we already show email,
if accessible, in the content of the modal.
An explanatory note on the changes in zulip.yaml and
curl_param_value_generators is warranted here. In our automated
tests for our curl examples, the test for the API endpoint that
changes the posting permissions of a stream comes before our
existing curl test for adding message reactions.
Since there is an extra notification message due to the change in
posting permissions, the message IDs used in tests that come after
need to be incremented by 1.
This is a part of #20289.
After topic list is updated, only restore focus to it, if it was
focused before. This avoids jumping focus from say compose box
to topic search unexpectedly when the topic list is updated.
Use a popover which displays both the options instead of long text.
We only use a small text indicating the current state which user
can click on to trigger the popover.
My PR #18974 introduced a bug where the logged-in dropdown pill on
the /help pages stopped working and has been unresponsive ever
since. This was caused by the incorrect assumption that each
`.dropdown` would be inside an unordered list `ul`. However, that
isn't the case for the dropdown pill on the /help pages. This commit
simply removes said assumption, by widening the scope of the relevant
CSS selectors.
We make the banner, mentioning the user to confirm new email
after changing the email through settings, sticky and it
disappears either on reload or after confirming the new email.
Fixes#20686.
In the previous commit (bea41e975d) we
introduced a bug by using `hotkey` instead of `hotkey.name`, further
debugging revealed that the conditional was unnecessary and as such
has been removed in this commit, the comment for the is_numeric
conditional has also been changed to explain its actual purpose.
Some other inline comments have also been moved to be on their own
lines.
In commit 1d54b383bd we introduced some
changes to add better support for keyboard navigation with the global
time widget. Unfortunately, as a result of the fact that
get_keydown_hotkey returns undefined for numeric keys, we caused a
regression that prevented users from typing into the time picker.
Additionally, we also lost support for the backspace and delete keys.
Hence, this commit fixes the above bug by early returning in two
places if the key pressed is backspace, or delete or a numeric key.
Previously, we suffered a bug where we would not properly condense
messages on first load of CZO (ie after login).
This bug was an unintended consequence of setting recent topics as the
default view, because since the page loads to recent_topics the
message_list is hidden but still gets rendered into the DOM and when
condense_and_collapse runs, it causes get_message_height to cache a
message height of 0, which results in the message not being collapsed.
There may be other ways to trigger the same broken mechanism.
This commit changes the function so we only return 0 but don't cache
the result.
Fixes: #20666.
The old name was confusing, since the contents
of the div aren't just a table, and we have
smaller elements that actually do list a bunch
of subscriptions in tabular format.
Even though we intend to shortly share lots of code
for editing stream subscribers with the create-stream
UI, we don't want to confuse click handlers and
containers too much.
It's kind of silly to cache ListWidgets for subscriber
lists when we only ever update the most recent one.
This will save memory if you are managing a whole bunch
of streams, although I suspect the savings here is
mostly negligible unless you were doing something
crazy.
The main motivation here is just that it simplifies the
code.
Now our click handlers get stream_id directly from
e.target, and then downstream code is no longer
coupled to the event semantics.
Note that we'll probably just know the stream_id
more directly after future commits.
We also remove a little bit of redundant error
handling.
This is a fairly straightforward extraction.
It's good to test this with Iago, and then go into
Manage Streams and add/remove subscribers for a stream
like devel.
I copy/pasted two small functions that will soon
diverge from stream_edit. The get_stream_id function
will either use a module variable (since we're
generally only editing subscribers for one stream, and
we already have the singleton assumption with
`input_pill`) or a more strict CSS selector. And then
get_sub_for_target depends on get_stream_id. We may not
always need full subs, anyway, and when we adapt some
of this code for creating streams, things are likely to
change.
I stopped exporting a couple functions that have no
callers outside of this module.
The main entry point for the module is
enable_subscriber_management.
We continue to export invite_user_to_stream and
remove_user_from_stream, which should possibly be just
pulled into their own module to lessen some
dependencies, but they don't have too much baggage,
since they just wrap channel calls.
We handle "Theme settings" subsection separately in
get_subsection_property_elements as it contains unique
radio-button structure for emojiset setting.
This should have been fixed while reorganizing the section
to have color scheme and emoji related settings under same
subsection in adb612a0b4.
Fixes#20644.
This is a pure code refactor for readability.
Previously, we were relying on there being a side effect to
add_clean_reaction which was necessitated by the presence of an output
parameter, `message` (or more specifically `message.clean_reaction`).
Output parameters are confusing.
Hence, this commit changes to have a make_clean_reaction function that
returns a reaction.
The name here is accounting for future plans where
we will share code for both of these use cases:
* editing subscribers on current stream (now)
* editing subscribers on new stream (upcoming)
This has two long-term goals:
- avoid circular dependencies between
stream_ui_updates and stream_edit
- facilitate code reuse for adding subscribers
to a new stream (i.e. using same widget for
when you edit subscribers)
We change the various "Up to N minutes" settings option labels to
"Custom", since the N is a little too mathy for some users.
Since the new prompts for the value of N are longer, we need to move
those prompts to the next line. Mainly this means switching from
`dependent-inline-block` to `dependent-block`, but we also need to
move the block out of the containing input-group for the CSS to be
happy.
Substantially rewritten by tabbott to use CSS for positioning and
change the message deleting copy of this issue.
Fixes#20177.
This avoids the somewhat confusing visuals of showing messages as
EDITED where the content had not been changed, which also obscured
situations where a message had both been edited and moved.
It's possible we could do better with some sort of fancier block-move
visual styling, but it's a bit tricky to do well given that we support
moving multiple messages at once.
Fixes#20451.
As noted in the TODO that we delete with this commit, we never
implemented live-updated for edit history when moving a message to
another topic.
Implementing this involves somewhat ugly copy-paste of the logic for a
content edit, but structurally is pretty simple.
It also makes #20451 much more visible.
Zulip shows two guides on How to reply, first one by
the welcome bot and second one is intro_reply hotspot.
To simply and avoid redundancy, intro_reply hotspot is
removed.
Fixes#20482.
This commit changes the behavior of subscriber list to
always be sorted by name instead of sorting them by email
when emails are accessible.
This change is fine because we will be using user-level
email address visibility and in that case the email of
some users will be visible and email of some will be not.
We show "Email" column heading always in users list and
subscriber list irrespective of the email-address visibility
setting after 46660e5, so we do need to pass show_email
parameter to render_admin_tab and render_stream_settings.
Removed existing empty narrow divs from app/home.html and created
a new javascript module to dynamically load empty narrow messages
using handlebar template.
Fixes#18797
The web-public option was disabled instead of being hidden in stream creation
form during live update triggerred from setting enable_spectator_access to
False. It was not being hidden since we have made web-public as the first
option and it is selected by default.
This commit fixes the bug to hide the option and also makes the code more
readable.
We should only consider visible choices while selecting the default
stream-privacy choice in stream creation form. Previously, we were
only checking whether the option is disabled, but this resulted in
a case where no option was selected when the realm-level setting
was set to not allow web-public streams as the choice was only
hidden and not disabled.
It is possible for user to change the width by using
screen rotation after the page has been loaded on mobile.
If only height has changed, it is most likely due to a
virtual keyboard, we don't hide popover in that case.
Fixes#20439
If a user chooses to not broadcast their presence status to others, we
still show the user as available in their own user sidebar. Instead, one's
own availability should appear the same as it does for other users.
With tweaks from YashRE42: rebasing to use user_settings instead of
page_params, as introduced in the series of commits ending with
8755a76cf6, adding code comments and
moving the redraw call to `server_events_dispatch.js`.
Fixes part of #18846. Further work is required to display the user's own idle
status properly to complete #18846.
Co-authored-by: YashRE42 <33805964+YashRE42@users.noreply.github.com>
Co-authored-by: Ganeshprasad Biradar <biradarganesh25@gmail.com>
Changing realm-level notification batching period setting from UI
was broken after adding the "Custom" option in 4f63378e7f because it
handled only user-level setting code and not realm-level setting.
This commit fixes it.
This commit refactors the set_notification_batching_ui to
use settings_org.change_element_block_display_property function
for toggling the visibility of custom input.
We add id to the email_notification_batching_period_edit_minutes
element such that we can use change_element_block_display_property
function because it requires id of element as an argument.
This commit also removes the value attribute of the custom
input since its value was set undefined in the template
and then was set in set_notification_batching_ui, so there
is no use of keeping the value attribute in templates.
This is a prep commit for fixing the behavior of this element
in realm-level default settings.
Since we don't use video button in compose control buttons
popover, this will never be reached. We can add this code again
when we add video button to the popvoer.
We don't hide popover on click for formatting buttons, emoji picker and time
picker.
Emoji and time picker popovers need a reference to be displayed,
hence we don't hide them.
Not hiding formatting buttons is based on past discussion.
The current instance of compose popover is stored locally
so that we can access it across different modules.
The basic approach for hiding / displaying a button is based on
width and is executed at `sm` breakpoint as per our
`css_variables.js`.
Used handlebars and `hide/show-sm` css class to make this
work. This avoids using too much JS to hide/display elements.
`Press Enter to send` used to hide `Send` button, we remove that
behaviour.
We show the current state of `Enter` hotkey action via text below
`Send` button which can toggle behaviour on click.
The new is obviously parallel with the small avatar URL construction,
and allows us to deduplicate this construction between the popovers
and full user profile logic for getting a medium avatar URL.
Fixes#20140.
This regular expression to add commas to a large number is hard to
read and produces less useful output than using the standard browser
API for doing this.
Fixes#20416.
We disable the enable_spectator_access setting when the server level
setting, WEB_PUBLIC_STREAMS_ENABLED setting is set to False.
This commit adds a new argument is_disabled to settings_checkbox which
is used to disable the checkbox and set the color of label accordingly.
This commit also adds a help-link besides the label pointing to
"/help/web-public-streams" which is shown irrespective of the
setting being enabled or disabled.
Fixes#20417.
This makes the UI for users browsing organization permissions a bit
less confusing; if they can't edit anything, they shouldn't have these
extra little buttons.
Fixes#20002.
Consider a modal with an error element displayed. When a user clicks
the submit button, the current behaviour is to empty the element. This
empties the inner HTML of the error element, but the CSS makes it still
visible, just empty. This looks bad. To avoid this, we hide the element.
We use the `ui_report` module to display errors, which adds the `show`
class to the error element every time an error is to be displayed. This
makes sure that the error element isn't hidden when the user re-clicks
the submit button while the modal is still open.
update_ui_and_send_reaction_ajax is called from hotkeys, popovers,
reaction clicks, etc. but it is the common point to deny
spectator from creating a reaction local echo.
The availability of this option is now controlled by fancier logic in
stream_settings_ui.js, but we neglected to remove this
development_environment guard when doing so, resulting in stream
creation being broken in production environments (because the
JavaScript code depended on this value being available).
We select the first enabled radio button by default instead
of selecting "Public" because there can be case when a user
is allowed to create a private-stream only and the other
options are disabled in that case after some recent changes.
This commit adds code for live-updaing the stream-privacy choices
in stream creation form and privacy change modal on changing
"create_public_stream_policy", "create_private_stream_policy"
and "create_web_public_stream_policy".
This commit renames disable_private_stream_privacy_option to
update_private_stream_privacy_option_state and also refactors
the code such that it can also be used to enable the option along
with disabling the option in further commit.
This commit renames disable_public_stream_privacy_option to
update_public_stream_privacy_option_state and also refactors
the code such that it can also be used to enable the option along
with disabling the option in further commit.
This commit renames hide_or_disable_web_public_stream_privacy_option to
update_web_public_stream_privacy_option_state and also refactors the code
such that it can also be used to enable or show the option along with disabling
and hiding the option in further commit.
This commit splits the hide_or_disable_stream_privacy_options_if_required
function into three separate functions for public, private and web-public
streams. This is a prep commit for live-updating the stream-privacy choices
on changing the realm setting.
This commit adds "Manage this user" option in the user-info popover
which simply opens the administrative user-info modal.
We show a spinner on submit button in this case as modal
is not closed immediately and thus we need some indicator
to show that the task is in progress. There is no spinner
on submit button in the modal opened from "Users" section
of organization settings.
Error handling for this case is different than when the
modal is opened from "Users" section of organization
settings because there is no overlay in the background
of modal in this case.
In this case, we show error inside the modal and do not
close it and in case the change is completed successfully
we just close the modal without showing any message.
Fixes part of #18944.
We received a complaint about the generation of multiple duplicate
drafts for a single message. It was discovered that the likely cause
of this was how we were handling clients that were frequently
suspending/unsuspending, we would initiate a reload when we discovered
this, and expect the `beforeunload` handler to save the draft. This
behaved correctly, however, we would also save the compose state and
fill it in via `preserve_state` in reload.js. The important detail
here is that `preserve_state` would not encode and preserve the
`draft_id` for the current message, partly because it had no way of
knowing the `draft_id` of the draft... since we have not saved it yet,
the `beforeunload` event happens after `preserve_state`. As such,
performing any action that would trigger a draft to be saved, eg
pressing Esc to close the compose box, would save a duplicate draft of
the same message.
To resolve the above bug, we (1) ensure that we call
`drafts.update_draft()` in `preserve_state`, this returns a draft_id
to us, which we (2) ensure that we encode as part of the url and (3)
set on the `#composebox-textarea` as a `draft-id` data attribute,
which we check the next time we try to save the draft, post reload.
Note that this causes us to save the draft twice, once from
preserve_state and then again from the `beforeunload` handler, but we
do not add two drafts since the second update_draft call just edits
the timestamp because it finds the `draft-id` data attribute on the
`#composebox-textarea` set by the first call.
Previously, opening a draft and closing it without changing the
content would cause us to show the "saved as draft" tooltip. This was
annoying and would cause annoying UX after fixing a bug related to
saving drafts when reloading, as such, this commit removes the above
behaviour by introducing a simple check on whether the draft contents
are edited.
In message header search bar, users didn't use to get any typeahead
suggestions if a normal filter follows search filter.
E.g.: query => foo bar stream:D
In the above case, users didn't use to get any typeahead suggestions.
This was because we had set that the callers of 'parse' function can
assume that the 'search' operator is present in the last in the query.
Because of which `get_search_result` function (in search_suggestion.js)
didn't use to show any typeahead suggestions as it used to assume that
the latest typed query is for search filters.
Fixes part of #19435.
We directly pass operators to remove dependency on narrow_state
module. This avoids a circular dependency of `filter` module
which is evident on the `/devtools/integrations/` page.
This commit extends dialog_widget class by adding a new
optional paramter validate_input which will be a function
to validate the inputs in the dialog and will be called
before showing the spinner and calling the on_click function.
Currently, the password change modal uses this paramter to
validate that the old and new password inputs must not be
empty. Since the spinner will not be initiated in the case
where form is invalid, we need not hide the spinner after
showing the error and thus we can simplify the code to use
ui_report.error to show the error messages of empty fields.
This fixes unexpected cursor repositioning behavior when the cursor was
positioned before or inside the "Quoting..." element.
The comments document the new logic, but roughly we aim to just
preserve the logical position of your cursor after replacing the
placeholder.
We also factor out a shared variable for the "Quoting..." string which
will allow us to tag it for translation in a future commit.
If you used "Quote and reply" to start composing a message, and
started typing before receiving the original message body from the
server, we ended up resetting your cursor to the start of the line
after the quote for two reasons:
* We were incorrectly fetching the pre_cursor for our replacement
operation before doing the server fetch, which meant we ignored any
editing done while waiting for the server to respond.
* Worse, we actually fetched the original cursor position before
inserting the "[Quoting...]" placeholder text. So we were guaranteed
to have at least some amount of error in the cursor position.
Fixes#20379.
Continuing the efforts to reduce dom trashing from the previous
commits, here we remove the third forced reflow by reordering the call
to $(".top-messages-logo").show() via narrow.reset_ui_state(), such
that it happens before the other DOM writes in
recent_topics_ui.hide().
Tweaked by tabbott to avoid adding an unnecessary if/else statement
around recent_topics_ui.hide.
This is a prep commit towards pushing the reset_ui_state calls upwards
into recent_topics_ui, in order to prevent a forced reflow. One side
effect of this change is that we add a call to
`narrow_banner.hide_empty_narrow_message()` from `narrow.activate()`.
This likely has no visible effect, in that the message list rendering
process would end up setting the narrow_banner state correctly, but
logically it could in the future avoid a banner from a stale banner
incorrectly appearing before we've rendered the current view.
This is a prep commit towards extracting a reset_ui_state function
which we can call from here, narrow.activate(), recent_topics.show()
and recent_topics.hide().
We want that function because it will enables us to prevent a forced
reflow when navigating from recent_topics to stream: xyz.
Going through the description of commit
a150b9b0ae is highly recommended since
this is a related issue.
We had received a complaint on chat.zulip.org about navigation with
the keyboard `n` key being significantly slow (~5 seconds), the first
time `n` was pressed when starting from the recent topics view.
It was difficult to reproduce the amount of lag that was reported, but
running chrome with the profile tab set to 4x slowdown helped get
close to it.
Based on profiling from the original report, as well as locally with
chrome set to 4x slowdown, led to the realisation that recent topics
to stream navigation involved a lot of dom thrashing, and so this
series of commits aims to prevent this path from causing forced
reflows.
In this commit, we reorder the calls to $(...).show() in
recent_topics_ui.hide(), this prevents the first reflow in this path,
most likely because displaying message_feed_container before
message_view_header_underpadding was guaranteed to cause style
recalculations since the underpadding is visually above the message
container.
This causes a net 60 ms decrease in the first renarrow, an ~ 70 ms
increase in the second renarrow and an ~ 5 ms increase in the third
renarrow but, more importantly, it eliminates one reflow and sets on a
path where we can achieve strong gains in subsequent commits.
We show "Please enter your password" error inside the modal
if the "Old password" input is empty and "Please choose a new
password" error if the "New password" input is empty and do
not send a request to server.
Fixes#19901.
The stream creation form currently does not setup its own handler for
displaying the "N:" input when ".stream_message_retention_setting" is
changed.
Prior to e793ef7f62d280300afeeab2f4a086e99858a5a9, this form would
sometimes work as intended because stream_edit would set the handler
on this dropdown, when it was opened. However, after that commit, this
would simply never work.
Hence, in this commit, we make changes so that stream_create correctly
sets the handler on its dropdown. This causes us to repeat ourselves a
little and as such is not the cleanest solution, but this might be the
best we can do due to the complications of stream_edit opening a
modal.
The stream creation form also uses the same stream_types template as
the stream privacy modal, however, it currently does not setup its own
handler for displaying the "N:" input when
".stream_message_retention_setting" is changed.
Previously, if one opened the stream creation form, then opened the
stream edit modal, and then went back to the stream creation form, the
drop down would correctly also .show() the input, because the handler
here would also target that selector. This is incorrect since we can't
always expect the stream_edit modal to be opened first, stream_create
should set up its own handlers.
Hence, as a prep commit to fixing stream_creation, and to ensure we
don't add duplicate handlers, in this commit we change all selectors
that targeted ".stream_message_retention_setting" to
"#stream_privacy_modal .stream_message_retention_setting" in this
file.
The public and private stream choices in stream creation form are disabled
according to create_public_stream_policy and create_private_stream_policy
settings. It is not needed to disable them in stream privacy modal since
only admins can change the privacy of stream and they are allowed to
create public and private streams always irrespective of the setting.
This commit has the following changes -
- Adds dropdown for changing create_web_public_stream_policy and this
dropdown is visible only if settings.WEB_PUBLIC_STREAMS_ENABLED and
enable_spectator_access is set to True. This dropdown is live-udpated
on changing enable_spectator_access setting.
- The web-public stream option in stream creation form and stream privacy
modal is hidden if one of settings.WEB_PUBLIC_STREAMS_ENABLED or
enable_spectator_access is set to False except in stream privacy modal
when the stream is already web-public so that the user is not confused by
none of the options being selected.
- We disable the web-public stream option in stream creation form and
in stream-privacy modals of stream which are not already web-public
when the user is not allowed to create web-public streams as per
create_web_public_stream_policy setting.
- We use on_show parameter to hide or disable the options in stream-privacy
modal because we use the visible property of element to remove the bottom
border from last element in the stream-privacy choices and thus we have
to wait for the modal to be visible.
Fixes#20287. Fixes#20296.
This commit adds user_can_create_web_public_streams function
in settings_data.js which will be used in further commits
to disable or hide the UI elements for creating web-public
streams.
We do not have 'realm_' prefix to the settings used as keys
in realm_settings object, we directly use the setting name.
This commit removes the 'realm_' prefix from enable_spectator_access
setting.
This is a very frequently requested feature for organizations that are
new to Markdown, that brings Zulip's UI more in line with that of
competing projects and other markdown editors like the GitHub UI.
This works surprisingly unlike my previous attempts to do so.
WARN: This is a pseudo commit and should only be merged with upcoming
compose box bottom refactoring commit since the css changes required
for this change are missing here and are not required after that
commit.
Since we have the drafts button in top left corner and we need space
to insert formatting buttons in the bottom of compose box; removing
drafts link makes sense.
This provides a convenient interface to hide all drafts.
Fixes#19360.
However, we may want to continue to implement a button in the drafts
overlay as well for doing this operation.
In commit 3d86267041 we add logic to
`/shared/emoji.js` which duplicated some of the logic in this
function. Since this isn't desirable, we remove the duplicate logic
here and instead just call `emoji.get_emoji_details_for_rendering`.
In commit 3d86267041 we add logic to
`/shared/emoji.js` which duplicated some of the logic in this
function. Since this isn't desirable, we remove the duplicate logic
here and instead just call `emoji.get_emoji_details_for_rendering`.
Previously, if a user had a realm emoji set as their status emoji and
someone deleted the realm emoji, the app would fail to initialize,
because of the error we throw from `./shared/js/emoji.js`.
This commit fixes this by just displaying the deactivated emoji,
similar to how we do when realm_emoji used as reactions are deleted.
As part of the fix, we add a function get_emoji_details_for_rendering,
which duplicates some of the logic used in `reactions.js`, we can
refactor to remove the duplication in `reactions.js` in future
commits.
Note that the following behaviour is a part of our design:
If a user sets their emoji to a particular realm emoji, say for
example "octo-ninja", and "octo-ninja" was then deleted, and a new
emoji was added with the name "octo-ninja", the user's status emoji
would change to show the new emoji instead of the deleted emoji.
Also note that in the `user_status.js` node test, we were able to
change the name for the 991 realm_emoji because it had not been
previously used anywhere in the test (possibly added as just a copy
paste artifact?).
Fixes: #20274.
emoji: Use reaction_type parameter to analyze emoji.
This commit renames "Automatic" option in color scheme setting
dropdown to "Sync with compute". We do not change any variables
used in code just the text in the dropdown visible to user.
Fixes part of #20228.
We restrict access of messages from web public streams if
anonymous login is disabled via `enable_spectator_access`.
Display of `Anonymous login` button is now controlled by
the value of `enable_spectator_access`.
Admins can toggle `enable_spectator_access` via org settings in UI.
Changes `update_page` to only update the modified user setting instead
of updating all of the user settings on the page. This is modeled on
the behavior for updates to the realm user default settings.
This is a follow up on feedback in #20070.
Now that it's further away from the composebox, we probably want it to
be visible for longer. Doubling it from 1.5 seconds to 3 seconds seems
reasonable to start with, although we should tune it based on feedback.
Now that this is in the left sidebar, we can remove the now-redundant
compose area button for it. This also changes where the "Saved as
draft" tooltip appears.
This currently shows the drafts as a popup. Eventually, we'll want to
migrate it to be a view in the center pane, as we did with Recent
Topics.
This uses the same style as starred messages in order to show the number
of drafts.
See CZO for more context:
https://chat.zulip.org/#narrow/stream/101-design/topic/drafts.20in.20sidebar
Since the position of topic in recent topics can change, we
focus the last selected topic using the `topic_key` instead
of relying `row_focus` value which is incorrect.
When user is scrolling, we simply keep the center element in
focus.
When user is using hotkeys, we keep the focused element in
center.
When user is using keyboard, we need to always keep the
"focused" topic in visible scrolling area.
We determine if the topic row is above or below the visible
area and scroll half_height_of_visible_area so that the selected
topic is visible.
This gives a nice navigation experience for both the views.
Reduced height of recent topics table to account for
compose box so that focused element is not below compose box.
Previously, opening multiple message_edits and then drag-dropping a
file into any one of them would cause all of them to upload ie you'd
get one uploaded file in each message_edit.
This bug was caused by returning multiple elements from
upload.get_item("drag_drop_container", config) when config.mode =
"edit".
This commit changes the selector to use the row provided (config.row),
and so ensures that the above bug doesn't happen.
`calendarContainer` is defined for flatpickr instance if it is
open.
This also fixes a bug where the flatpickr doesn't open when
user tries to toggle it using the global time icon in compose.
We need to handle live-update of twenty_four_hour_time setting
separately in update_page because the database value of this
setting is boolean but we use dropdown in the frontend for this
setting with option values as "true" and "false" strings.
There was no heading for "Time format" setting in the
"Default user settings" section and thus no save-discard
widget to update the setting. This commit fixes the bug
and changes the heading to be only "Time" since there is
no realm-level default of language setting.
This bug was introduced in adb612a0b4.
Flatpickr tries to show a different picker for mobile which
is not visible for some reason. We display the same picker
on mobile which we know works for our use case.
Docs: https://flatpickr.js.org/options/
```
Set disableMobile to true to always use the non-native picker.
By default, flatpickr utilizes native datetime widgets unless
certain options (e.g. disable) are used.
```
Previously, navigating from any stream to the recent topics view would
cause a forced reflow every time we checked `is_visible()` because it
would call `$("#recent_topics_view").is(":visible")`.
The reason for this is related to how browsers ship frames, the
process follows these steps:
JavaScript > style calculations > layout > paint > composite.
(The layout step is called Reflow in firefox.)
Typically, the browser will handle these steps in the most optimal
manner possible, delaying expensive operations until they're needed.
However, it is possible to cause the browser to perform a layout
earlier than necessary. An example of this is what we previously did:
When we call `top_left_corner.narrow_to_recent_topics()`, we ask to
add a class via `.addClass()`, this schedules a Style Recalculation,
then, when we call `message_view_header.make_message_view_header()` it
calls `recent_topics_util.is_visible()` which calls
`$("#recent_topics_view").is(":visible")`.
Before the browser can get this value, it realizes that our dom was
invalidated by `.addClass()` and so it must execute the scheduled
Style Recalculation and cause a layout.
This is called a forced synchronous layout.
This commit adds a JavaScript variable representing the visible state,
in order to prevent the above behavior.
This commit reduces the main thread run time of
`build_message_view_header` from 131.81 ms to 5.20 ms.
Unfortunately we still have the case where
`recent_topics_ui.revive_current_focus()` calls
`recent_topics_ui.set_table_focus()` which causes a reflow.
However, by eliminating this reflow we still save ~100ms.
(It's important to note that we only save this sometimes, as other
things can still cost us a reflow.)
Further reading: https://developers.google.com/web/fundamentals/
performance/rendering/avoid-large-complex-layouts-and-layout-thrashing
PR #19576 added a settings option for selecting a notification batching
period. We want to extend that UI option with the ability to select
a custom period.
Tweaked by tabbott to have the natural model that picking a value
present in the dropdown live-updates to remove the custom input,
rather than only having the custom input disappear on reload.
Fixes#19713.
It's always better to use the user ID than the email for fetching data
about an object whose unique ID we have, which should be all of them.
And it's also cleaner code to use the standard people.js method; tabbott
checked that indeed all callers get their `user` objects from `people.js`.
Since we restrict spectators from having access to avatars using
email to avoid someone brute forcing a user's email, this removes
a 401 response from the server in spectator view when trying
to open user info popover.
Additionally, this fixes the cached-fetching behavior documented in
the comments we add about the way we construct URLs.