For more discoverability, the keyboard shortcuts for preview, and bold,
italic and link formatting are now displayed in the tooltips of those
compose buttons.
Earlier we did not activate widgets if their rendered HTML was cached,
and also when narrowing to the combined feed view. This caused bugs with
widgets not being activated, and so not responding to any interactions.
Now we unconditionally render and activate widgets in the current view,
irrespective of the cached HTML or the view being narrowed to.
`source` is expecting a list so `false` doesn't make sense here.
It was working before because the code that calls `source` in
`bootstrap_typeahead` just does falsey checks.
This commit replaces the fontawesome "edit" and "copy-link" icon found
in the user profile modal with the corresponding zulip icons.
It also moves the functional classes like
user-profile-manage-own-copy-link-button from the icon element to its
container, including adding a new div wrapping the icon in
user-profile-manage-others-edit-button.
Attempting to convert .data("draft-id") to .attr mysteriously breaks
draft saving, so I’ll leave that for future work.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
e.target is the wrong element, and even if this were to successfully
add the _full-height-no-scroll class to <body>, that’s not a child of
.portico-hello-page.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Its selector looks like it’s missing a ‘.’, but “fixing” it breaks the
page even more, and trying to decipher this mess of event handlers
that poorly replicate what should be native behavior is making my
brain hurt.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Combined feed always narrowed to the first unread id regardless
of if it was muted or not since we were not actually using the msg_id
that we found after all the hard work of doing all the checks for it.
Originally, we only wanted to do local echo in the current
view. However, now that we're looking at navigating the user to the
conversation that they send a new message to, it's going to be quite
common that we immediately visit a destination different from the
current view, where local echo in that different view would be
valuable.
The most interesting block was added in
af188205cb / #8989. But in
6637f2dbb7, the key logic for checking
`msg_list.data.fetch_status.has_found_newest` was duplicated in the
`add_new_messages` code path, which critically also updates
`update_expected_max_message_id` and thus may close a race with
fetching message history for a view we're being navigated to, where
the locally echoed message might fail to appear at all.
This change does come with a slight regression: If we are looking at a
search view where the filter is one that we cannot apply locally, a
newly sent message will now be locally echoed (returning the compose
box for drafting another) even though it cannot be displayed in the
current view, which means that the message will not appear in either
the compose box or the current view for the brief period before we get
a reply from the server in this scenario. This is a minor detail,
likely not worth troubling ourselves over.
Given our intent to experiment with navigating the user out of the
search view in this scenario, this is likely not important.
Co-authored-by: Tim Abbott <tabbott@zulip.com>
The `at_rendered_bottom` check was incorrect since it includes
bottom whitespace in the calculation to check if we are at the rendered
bottom. This is can cause us to not fetch new messages if user stops
scrolling when bottom whitespace is partially visible leading to
a bad UX.
If user goes to combined feed view on escape keypress, then
we restore their narrow pointer and offset by restoring it from
browser history if the their last narrow was the combined feed view.
This is no longer required since narrow state is restored by
`reload` library and narrow history restores the narrow pointer
and offset when going back to a view.
Only regression here is we will no longer restore the pointer when
user navigates to the combined feed view without using browser back
button and combined feed view is the default view. This is fixed
in the next commit.
We now use "settings-field-label" and "modal-field-label"
class on label elements in settings and modals respectively
to add the bottom margin which was previously done by
"dropdown-title" class as it is better to have more
generic names to use on label for all type of inputs.
This commit adds bottom margin to label elements of
different inputs by adding "modal-field-label" class
to the label elements. Some of them already have the
margin due to having dropdown-title class.
This commit adds bottom margin to label elements of
settings inputs in personal, organization, stream
and group settings using the recently added
"settings-field-label" class.
Most of the settings are dropdown settings, so the
label for them already had a margin as they use
"dropdown-title" class.
There is no need to have hr element below the "Field choices"
heading in custom profile edit form and this also makes it
consistent with the new custom profile field form.
This commit removes classes like "title", "input-label"
and "emoji-theme" from label elements in settings and
modals as these are classes are neither used in JS
nor to apply any CSS.
This only every did a single extra fetch, and now that this fetch is
in the same direction as our main fetching sequence, no longer is
meaningfully different from just specifying a different value of
consts.maximum_initial_backfill_size.
Previously, when a message is edited, it is locally echoed with its
pre-edit content.
This is because previously, when we tried to render the edited
message of the edit box during local echo, in order to update
the content, flags, and is_me_message properties of the message
object with that of those returned is markdown.render(), we used
the spread operator and created a new message object, and updated
the existing message object with this new one.
This was misconverted, since edit_locally() method already has a
fully-rendered message object to start with, and is just doing a
rerendering, it should be mutating what message it received, rather
than constructing a new local variable.
This removes the common min-width being used across all popovers and
instead sets the min-width according to a popover's requirements.
This allows for greater control over the popovers since we have a
variety of use cases for them — which a single common min-width cannot
accommodate.
For onboarding banners, we replace the close button with
"Got it" button.
Also, the banner is marked as read for the user only after
the "Got it" button is clicked. Earlier it was marked as read
as soon as it was displayed.
Register our `onTextInputHook` to be called on "input" events so that
the hook receives the updated text content of the input unlike the "keydown"
event which does not update the text content before running the hook.
Updates the base hash for the streams setting overlay to be
"channels" instead of "streams".
Because there are Welcome Bot and Notification Bot messages that
would have been sent with the "/#streams" hash, we will need to
support parsing those overlay hashes as an alias for "/#channels"
permanently.
Part of the stream to channels rename project.
Updates the streams settings URL in the message view header to be
generated with hash_util.stream_edit_url, which correctly encodes
the stream name in the URL.
Additionally, the text colors have been updated for both light and dark
themes, it starts showing when 900 or less characters are left, as 999
was too soon, and has a tooltip to show the maximum characters limit.
Fixes: #28706.
Add a rule to the switch_rows(event) function to avoid
switching stream row when pressing up/down key by checking
the current URL hash and the add_subscribers_pill focus state.
Add a utility function to hash_parser to help implement new
switch_rows behavior mentioned above.
Fixes#29690.
Adds a new trigger string to use for narrow.activate opts when
it is called due detecting a message move for the targeted message
ID: "retarget message location".
Updates narrow.save_narrow and narrow.hashchange to accept the
trigger as a parameter so that, even if the narrow was started via
a hash change in the web app, the URL and browser history is
updated for the current location of the targeted message.
Earlier, the primary modal button always turned grey on being disabled,
while other modal buttons remained as is in light mode, and grey in dark
mode. Now the styling is made consistent across all modal buttons, by
giving them all 50% opacity when disabled.
So far, the Send buttons area would turn grey when the message could not
be sent. The Save button when editing a message would also turn grey
when the message could not be edited anymore. Now we simply make the
buttons half opaque instead of turning them grey in a disabled state.
We change the background colors for the close / cancel / exit buttons
in modals and messages (when editing them or viewing their source). The
border is also removed for those buttons in messages.
When viewing the source of a message when not editable, the opacity of
the read-only textarea would be reduced to 0.5, like for any other read-
only textarea in dark mode. This was unnecessary for viewing message
source, so the opacity for this case is now set to 1.
Fixes: #28701.
In spectator mode, the separators encapsulating the topic visibility
switcher wasn't being hidden since the `hidden-for-spectators` class
was being applied only to the `popover-menu-inner-list-item` element.
As a follow-up commit to c3e4358, this removes the additional
separator by shifting the `hidden-for-spectators` class to the
`popover-menu-outer-list-item` element instead, which is responsible
for showing the separators.
We could have added a new function that would return early on the
first property that changed instead of using
`populate_data_for_request`. But we would still need to fetch
`field_data` in most cases. Using `populate_data_for_request` will
keep things simple and readable while the performance difference
should be negligible.
Fixes#29750.
- We introduced an argument called `custom_profile_field` similar to
`sub` and `group` in `check_property_changed` and
`populate_data_for_request`.
- We could've introduced `field` param in `get_input_element_value`,
but I've kept it clean since it didn't have any similar kind of data input.
The performance difference due to this should be negligible.
- Introduced a span that would be parent to all `field_data` params
since it is needed by the diff infrastructure.
- If there is no data to be changed, we display our success status
without sending the PATCH request since save changed button is
always enabled.
This is a preparatory refactor since we need to use this function in
settings_components.ts which is a typescript file. Although the
original file seemed like the best destination for this function,
settings_components.ts seems like the second best destination.
Do not send unnecessary extra params when changing the value of
`required` field. Instead of searching realm.custom_profile_fields
for the field we are editing, we will just use the checkbox value to update
the field value, since we don't need to send other params like `name`,
`hint`, etc. to the API after API feature level 252 update.
Do not send unnecessary extra params when changing the value of
display_in_profile_summary. Instead of searching realm.custom_profile_fields
for the field we are editing, we will just use the checkbox value to update
the field value, since we don't need to send other params like `name`,
`hint`, etc. to the API after API feature level 252 update.
Following the topic sidebar action popover menu redesign using the new
"popover-menu" tippy theme, we update the icons of the menu options to
match the new UI.
Fixes part of #28699.
Following the stream sidebar action popover menu redesign using the new
"popover-menu" tippy theme, we update the icons of the menu options to
match the new UI.
`callback_after_render` was not being called when `render` did
an early return which caused "load more" to not be updated.
This is noticeable now since we are doing fewer calls to
`process_messages` which also updates the `load more` banner.
In narrow.activate, the adjusted_terms_if_moved helper uses the
raw terms from the URL for checking if a message was moved. If a
non-canoncial operator was in the URL for a narrow (e.g. "subject"
instead of "topic" and now "stream" instead of "channel"), then
the view wasn't updated correctly.
Update adjusted_terms_if_moved to use the canonical version of the
operator in the URL when adjusting the message history.
Aman Agrawal
Prakhar Pratyush
N-Shar-ma
Anders Kaseorg
evykassirer
Pratik
nimishmedatwal
Karl Stolley
afeefuddin
Lauryn Menard
Sahil Batra
Alex Vandiver
Tim Abbott
roanster007
Sayam Samal
luska44
Lalit
PieterCK
Mateusz Mandera
Shubham Padia