TypeScript doesn't understand Array.prototype.slice.call; rather than dealing with the
type-checking issues around it, we remove it; it was only necessary for ancient browsers where
NodeList isn’t directly iterable.
Remove the winjs specific `getScrollbarWidth` property while we're at it;
WinJS isn't relevant anymore.
Reorders methods due to TypeScript files enforcing define-before-use when
this commit was drafted.
When referring to <div id="my-id" class="my-class">:
- my-id is an id
- #my-id is a selector
- my-class is a class name
- .my-class is a selector
When an id or a class name is interpolated into a selector, it needs
to be escaped with CSS.escape.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
We expect the URL to be of stream if it is opened in right panel.
As archiving a stream extracts stream id from hash,
but while a stream is opened and we switch between `All Streams` or
`Subscribed` tabs, the url changes, causing bug in archiving the stream.
As as fix for this issue if a stream is opened in the right
panel the hash of the URL remain of the stream and doesn't update.
If it is archived then the URL updates accordingly.
Fixes#23855.
Cleans up node test to use helper functions when setting a filter
and narrow state for private messages and when checking the return
value for `pm_list_data.get_list_info`.
Also, reduces the number of users in the test by creating more
group direct message conversations.
The logic for whether one needs to scroll down to view messages sent
by the current client was incorrectly not checking whether a message
feed was visible at all.
This replaces one of the our larger remaining blocks of code with
explicit logic for message_lists.home with logic that should correct
if we support maintaining a different set of rendered message lists.
This should have identical behavior to the previous implementation
given that all_rendered_message_lists is either just
message_lists.home or that plus the current narrowed message list;
can_apply_locally() is always true for the home message list, and the
list === message_lists.current check is equivalent to the more complex
narrow_state.active() check.
Because we don't call this function with home_msg_list, I believe the
existing msg_list !== message_lists.current check would have always
been false when the new check is false, but this is more explicit
about the logical intent.
The flex-direction property for modal__content should
be set to column as we want to display the elements.
This does not affect most of the modals since they
do not have multiple direct child elements that are
visible at same time and the data-simplebar attribute
already sets the "flex-direction: column" property to
the elements where it is used.
But in the email address visibility modal on user
registration page, there are multiple direct child
elements for the "modal__content" element and we need
to set "flex-direction: column" property for them to
work correctly. We also change the width of select
element in the modal to "fit-content" to avoid it
taking the whole width even when not required.
This commit also fixes the bug in login_to_access
modal, since the `modal__content` for it also
has two direct child elements.
- Being more specific about what the user will get.
- Putting less emphasis on entering multiple emails, since most
people probably just have one email they need to check.
- Using more intuitive wording and hint that deactivated or
deleted accounts won't be included.
Fixes: #24890.
This is a follow up to #24673, we want to modify every webhook events to
follow the same pattern and consistency where branch name should only
show on opened and merged events.
This is a prep commit to help make the changes to make changes to pull
event message easier. Our Bitbucket has been using a custom template to
render the reviewers. This means that values are fixed to how the templates
like it. These changes will allow `get_pull_request_event_message` to
support reviewer and allow for a easier and flexible adjustment to these
messages if needed.
Previously, the assignee message would stick around in the middle of the
event message. This doesn't look as good as if we put it to the end of
the event message. These changes does just that and move the assignee
messages towards the end of the event message to make it look better
and cleaner for the readers.
Previously, there was a stale code that didn't verify
if 'muted_topics' and 'user_topic' events are sent correctly.
This commit updates the test to verify if the expected
users are notified via 'muted_topics' and 'user_topic'
events.
This commit updates the move-topic codepath to perform
bulk database operations on the UserTopic record using
user_profiles for each visibility_policy instead of
previously looping over each user_profile one by one.
This commit refactors 'set_user_topic_visibility_policy_in_database'
to perform bulk database operations and the related changes.
There is an increase in database query count because requests
to delete user_topic rows now take two queries instead of one.
This is required for logging the info for a request to delete
a non-existent user_topic row while performing bulk operations
at the same time.
The overall query count will be lower while performing
bulk operations (multiple user_profiles instead of one).
This commit updates the 'do_update_message' codepath to
update the UserTopic records regardless of visibility policy
during the "move-topic" operation.
This is required before offering new visibility policies
in the UI.
Previously, UserTopic records were moved or deleted only
for objects with a MUTED visibility policy.
Fixes: #24574
This is a prep commit that renames 'set_topic_mutes' and
'topic_is_muted' to 'set_topic_visibility_policy' and
'topic_has_visibility_policy' respectively, and refactors
them to work with any visibility_policy, not only MUTED.
This PR adds a modal to warn when user unchecks a box on the "PMs,
mentions, and alerts" line of notifications panel that will result in
all notifications for private messages and mentions being disabled.
Fixes#24151.
`topic_row_top = $(topic_row).offset().top;` returns an error
while calling `topic_offset_to_visible_area` since we cannot
find the `topic_row` for some reason which doesn't seem logically
possible but we add logic to handle that case as well.
The compose send button spinner (which disables the send button while
present) was correctly hidden in both the happy case of a sent message
as well as for all locally echoed message, in both cases via
clear_compose_box to reset the compose box for a new message.
But for a message that was not locally echoed, and failed to send,
nothing hid the compose spinner, resulting in the user being unable to
attempt to resend the message.