Prettier would do this anyway, but it’s separated out for a more
reviewable diff. Generated by ESLint.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Prettier would do this anyway, but it’s separated out for a more
reviewable diff. Generated by ESLint.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
It's unclear what the purpose of this logic was, but testing confirms
that the text color is as expected without this in the day theme (so
it's likely a relic of an old design) and removing it fixes the hover
text being overridden to white in the night theme.
We hide the spoiler content in browser/desktop notifications.
Note: its not worth adding zjquery tests for this bit of code because
the tests do not operate on the actual data and are likely to get stale
if we change the syntax for spoilers.
This handler adds a neat little effect whereby hovering over the
clickable region to open the navbar triggers the search_icon hover
effect and is a neat little visual cue about what happens onClick.
The previous implementation was slightly messy because it fetched the
color and applied it via ".css(". This commit cleans it up by creating
and using the class "search_icon_hover_highlight" instead. We also
make the selectors more specific, ensuring they target children of
"#tab_bar", this was so because it was reasonable to expect someone to
define eg `search_closed` elsewhere and we wanted to prevent bugs when
that happened.
In 9046fc1032 we updated the navbar.html
file so that our css selectors did not override each other and cause
annoying problems.
Unfortunately this caused a regression in night mode where the
search_icon didn't have the correct hover effect.
This fixes the regression by adding the selectors.
The page_params.timezone feature is perhaps a misfeature, but
importantly it's not what is used to display the time in the message
feed (it's mainly used to show others your timezone).
Given that reality, we shouldn't use it for a feature whose whole
purpose is to display the time using the same timezone we use in the
message feed.
Fixes#15790.
Delete stored topic data in `recent_senders` and `recent_topics`
about the message's topics and re-render them. The process is similar
to topic editing. See `recent_senders.process_topic_edit` for
logical details.
In 9648e64d23, we added a clear outline
around focused link elements in popovers.
This was a good fix for popovers, but it's distracting for the
experience of clicking links in the sidebars and message feed.
We have changed our all instances of list_render to use
simplebar and thus, we will now use simplebar container
to track scroll event for all the lists created by
list_render.
This fixes the bug of new subscribers not rendering on
scrolling at the end of subscriber list in stream settings
and similar bug in some other lists also.
This commit also removes scroll_util.get_list_scrolling_container
function as this is no longer used.
Fixes#15637.
This commit fixes the dropdown_list_widget to use simplebar for
scrolling.
It was not being used because data-simplebar should not be inserted
to the element being rerendered. This commit adds a new element
wrapping 'dropdown-list-body' which was being rerendered and
data-simplebar is added to that new element 'dropdown-list-wrapper'.
Also, there should always be a max-height property on data-simplebar
element and it is also added in this commit.
There is also a change to set margin of 10px only on the first div
element and which is direct children of organization-settings-parent
element. This is correct because we only want margin to add some space
between the heading of subsection and the first setting of that
subsection. Previously, the margin was being added to first div of all
the other child containers also and this was adding unnecessary margin
to the first div element of different simplebar containers.
We do not need to use list_render for displaying list of streams specific
notification settings, as this is not scrollable and we do not provide
option to sort or filter this list as well.
After this change, all our list_render instances will be using simplebar
and we can change the code accordingly to fix the behaviour of scrolling.
We remove the action column and show action buttons next to topic
after unread count (if present). This save us a lot of extra space
on small window sizes.
For a:focus Bootstrap sets the following rules:
outline: thin dotted #333;
outline: 5px auto -webkit-focus-ring-color;
Firefox does not know -webkit-focus-ring-color and falls back to the
previous rule, making the outline invisible in darkmode.
Chromium has a bug[1] that makes outline: auto invisible when focussing
elements programmatically (which we do for the up & down arrow keys).
[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=1105822Fixes#15768.
jQuery's fadeOut() sets display: none using inline CSS.
This was overriden by .alert-notification since it used !important
to override the display: block set in loading.js. Removing the latter
allows us to remove the !important, and doesn't seem to break anything.
Fixes#15759.
This reverts commit 63643c9d9d.
As the commit mentions, it makes a UI change for legacy search which
has largely been considered a regression. We've been running with
this reverted in zulip.com essentially since it was first merged.
Apparently, our scrollbar logic crashed with an invalid URL fragment
(hash), which resulted in initialization not completing and thus the
logic failing.
In my view the root issue here is that we're not doing a good job of
catching JavaScript exceptions in portico pages.
Fixes#15706.
In 42f20e81be I fixed an edge case but
also accidentally made clicking on reactions open the compose box.
This commit adds back the e.stopPropagation(); and explicitly hides the
emoji picker popover, to address the inconsistency fixed in the previous
commit.
Previously, we were experiencing a bug that caused the left border of
the searchbox/tab_bar to disappear when the searchbox was opened. This
bug was a result of the following changes:
- 4cdd7aed2b accidentally added this line
as right: 2; instead of right: 2px;
- 46c966576d fixed this line to be
right: 2px; but caused the regression.
This commit fixes the bug by deleting this line.
Previously user have to click pixel perfect on the message controls
icons to achieve the click action.
This commit will uniformly increases the click target
area for the icons.
Tweaked by tabbott to avoid some weird glitches.
Throughout the codebase we use <i> tag for icons.
This commit will add <i> tag inside the starred message
div and fa classes are now used with this <i> tag.
The starred message div is now consistent with other
message_controls divs.
Tweaked by tabbott to use the name star_container for better
readability.
Prior to commit eb4a2b9d4e the center
area of the navbar was based on a structure that appended crumbs or
"tabs" as <li>s, forming a tab_bar and a tab_list.
However, in eb4a2b9d4e we apply a new
style and structure to the navbar which lets go of the convention of
tabs. Hence, we'd like to purge the tab_bar and tab_list labels from
our code base.
It would have been nicer if we could simply purge tab_bar from the
codebase and rename "#tab_list" so that we have an anchor and wrapper
structure in the html, but dropping the float: left on tab_bar causes
some confusing problems such as causing the horizontal border to
disappear and the search_box to shift out of its intended position and
so its simpler to get rid of tab_list from our code base first.
This commit:
- Removes the #tab_list wrapper div from tab_bar.hbs.
- Removes any #tab_list selectors from night_mode.scss so that they
simply target based on "#tab_bar" instead of "#tab_bar #tab_list".
- Removes tab_list selectors from zulip.scss, so that #tab_list
attributes now apply to the #tab_bar, in the process we drop the
duplicated width property and reorder the attributes.
- Replaces all mention of #tab_list with #tab_bar in JS files.
Prior to commit eb4a2b9d4e the center
area of the navbar was based on a structure that appended crumbs or
"tabs" as <li>s, forming a tab_bar and a tab_list.
However, in eb4a2b9d4e we apply a new
style and structure to the navbar which lets go of the convention of
tabs. Hence, we'd like to purge the tab_bar and tab_list labels from
our code base. This commit pushes us towards that goal by simplifying
the future merge of the two CSS labels.
Prior to commit eb4a2b9d4e the center
area of the navbar was based on a structure that appended crumbs or
"tabs" as <li>s, forming a tab_bar and a tab_list.
However, in eb4a2b9d4e we apply a new
style and structure to the navbar which lets go of the convention of
tabs. Hence, we'd like to purge the tab_bar and tab_list labels from
our code base. This commit pushes us towards that goal by simplifying
the future merge of the two CSS labels.
The letter-spacing attribute was set to its default value and so we
remove it and rely on the default.
Prior to commit eb4a2b9d4e the center
area of the navbar was based on a structure that appended crumbs or
"tabs" as <li>s, forming a tab_bar and a tab_list.
However, in eb4a2b9d4e we apply a new
style and structure to the navbar which lets go of the convention of
tabs. Hence, we'd like to purge the tab_bar and tab_list labels from
our code base. This commit pushes us towards that goal by simplifying
the future merge of the two CSS labels.
Currently the #tab_bar is just a container for the #tab_list and the
#tab_list handles the overflow attributes and so these do not serve
any purpose.
Prior to commit eb4a2b9d4e the center
area of the navbar was based on a structure that appended crumbs or
"tabs" as <li>s, forming a tab_bar and a tab_list.
However, in eb4a2b9d4e we apply a new
style and structure to the navbar which lets go of the convention of
tabs. Hence, we'd like to purge the tab_bar and tab_list labels from
our code base. This commit pushes us towards that goal by simplifying
the future merge of the two CSS labels.
We have the same selector within #tab_list and the duplication is
unnecessary.
Ideally we would not be relying on something that requires a 4 line
comment, and also makes it harder to add more static elements at the
end of the navbar, but this block should be acceptable for now.
One alternate would be a "grow-1" class or similar but we might need
to think that through.
Previously, we had the entire div within the conditional, instead of
just the contents, which were the only variable elements.
This change moves the conditional over just the contents of the div
and improves readability.
Previously, the navbar sub count would not live update as users
subscribed or unsubscribed, this commit adds the relevant calls in
stream events.
It would have been better to just have a single call within
server_events_dispatch but it seems difficult due to the way of
mark_subscribed and mark_unsubscribed are structured.
stream_events.mark_unsubscribed conditionally calls
subs.update_settings_for_unsubscribed which calls
subs.rerender_subscriptions_settings and as such handles the update
for the subscriptions modal on its own. Hence, we simply rely on the
stream_data.update_calculated_fields to ensure the subscriber counts
are updated and make a call to
tab_bar.maybe_rerender_title_area_for_stream(sub).
stream_events.mark_subscribed is similar.
Previously, we had the lines from this block being duplicated in all
the stream update paths, which is a little brittle.
Hence, in this commit, we extract it out with a comment explaining
what it does and call it in all the duplicated spots.
My previous message_header fix
0b4568d249
accidentally changed the alignment of dates in private messages (so that
it was inconsistent to the alignment in other narrows).
We use narrow_state.stream_sub instead of narrow_state.stream to directly
get the sub object instead of stream name, while subscribing to a stream
from the stream narrow.
This commit changes stream_data.is_user_subscribed to use stream id
instead of stream name.
We are using stream ids so that we can avoid bugs related to live
update after stream rename.
We have logic in place to update the ui for re-sending messages
on recieving the acknowledgement from the server on that API call.
However, if the acknowledgement is recieved through the get events
request before the `on_success` of `resend_message`, the message
gets re-rendered allowing the failed message actions to be clickable.
Now, we update the ".message_failed" ui for both cases. This helps
in preventing the "Trying to get local_id from row that has reified
message id" exception.
Fixes#15351.
fadeTo is not a good method to hide elements since it sets
opacity to 0 in which the element still can consume space and
be clickable. We set it's display to None using fadeOut method.
Also, allow this method to be called via ui_report.error.
Previously .recipient_row_date was positioned absolutely, allowing it to
overlap with the topic name on narrow screens. This can be solved by
using flexbox. To implement the empty space between the bar controls and
the date on wider screens we move the date outside of the bar controls
(which also makes more sense semantically since the date isn't a
control).
Fixes#15501.
The stream notification settings checkboxes were not checked
even when the notifications were turned on for the stream.
This was happening because we were passing stream name to
receives_notifications instead of stream id.
This commit fixes the bug by passing stream id to
receives_notifications. This change should have been done
in f3604fb while refactoring receives_notifications to use
stream id instead of name.
As a consequence of commit 1113589b9d the backspace key and some other
keys did not respond if the search yielded no results.
This change fixes that bug.
This fixes the bug of extra topics not being rendered on scrolling.
list_render uses `max-height` to determine which container is being
scrolled upon. Set the `max-height` on the scrolling container of
recent topics to help list_render identify it.
This is useful for the emoji-picker where holding down shift lets you
select multiple emojis. Otherwise when selecting multiple emojis with
the keyboard shortcuts you would need to release shift everytime you
wanted to navigate with the arrow keys.
Previously clicking on an existing message reaction (outside of the
emoji picker) while having the emoji picker open, removed the reaction
without updating the highlighting of the reacted emoji in the emoji
picker.
The emoji picker already is already closed when clicking outside.
The message reaction click handler however previously stopped the event
propagation, leaving the picker open, allowing the inconsistency.
There is a bug when clicking on the stream row in stream settings page
subscribes/unsubscribes the user from stream. The ideal behaviour
should be that user should be subscribed/unsubscribed only
when user clicks on tick icon. The buggy behaviour is visible only after
clicking the tick icon once.
This is because clicking on tick is adding sub_unsub_button class to the
stream row, while it should be added only to the ".check" element to
re-enable the button to handle requests.
This commit fixes the bug by adding the "sub_unsub_button" class to
".check" element only and not to the stream row and same change
is done for removing the "sub_unsub_button" class also.
Subscribe/Unsubscribe button in the right section of stream settings
page is not working because the target element in click handler was
changed to 'check.sub_unsub_button' in c234b4f2 and the button in
the right section with class 'sub_unsub_button' also uses the same
click handler.
This commit reverts c234b4f2 and the bug of subscribing/unsubscribing
the user by clicking on stream row in the stream settings page, which
c234b4f2 intended to fix will be fixed in next commit.
As we add more features where rendered_markdown.update_elements does
something useful, it'll become important to run this code everywhere
we render markdown in the DOM.
One can see in this case that we had actually copied one hunk of
rendered_markdown.update_elements years ago, before we extracted it as
an independent function; we get to delete that copy.
Fixes#15500.
We do not show the warning while sending messages to announce
stream if there is a wildcard mention in the message (i.e.
when wildcard_mention != null)
There are two cases where we should ideally show the warning
but we don't-
- When there is no wildcard mention in the message and
wildcard_mention is set to undefined (initial value of
wildcard_mention).
This is because "wildcard_mention != null" returns true for
this case and thus the warning is not shown, assuming the
message to have wildcard mention.
- When previous message had a wildcard mention and now a message
is being sent with no wildcard mention.
This is because the condition "wildcard_mention != null" is
checked with the previous value of wildcard_mention and not
with the value according to current message content, and thus
the warning is not shown, assuming the message to have wildcard
mention.
This commit changes the code to set wildcard_mention from the
latest message content before performing other validations and
thus solves the problems described above.
This particular commit has been a long time coming. For reference,
!avatar(email) was an undocumented syntax that simply rendered an
inline 50px avatar for a user in a message, essentially allowing
you to create a user pill like:
`!avatar(alice@example.com) Alice: hey!`
---
Reimplementation
If we decide to reimplement this or a similar feature in the future,
we could use something like `<avatar:userid>` syntax which is more
in line with creating links in markdown. Even then, it would not be
a good idea to add this instead of supporting inline images directly.
Since any usecases of such a syntax are in automation, we do not need
to make it userfriendly and something like the following is a better
implementation that doesn't need a custom syntax:
`![avatar for Alice](/avatar/1234?s=50) Alice: hey!`
---
History
We initially added this syntax back in 2012 and it was 'deprecated'
from the get go. Here's what the original commit had to say about
the new syntax:
> We'll use this internally for the commit bot. We might eventually
> disable it for external users.
We eventually did start using this for our github integrations in 2013
but since then, those integrations have been neglected in favor of
our GitHub webhooks which do not use this syntax.
When we copied `!gravatar` to add the `!avatar` syntax, we also noted
that we want to deprecate the `!gravatar` syntax entirely - in 2013!
Since then, we haven't advertised either of these syntaxes anywhere
in our docs, and the only two places where this syntax remains is
our game bots that could easily do without these, and the git commit
integration that we have deprecated anyway.
We do not have any evidence of someone asking about this syntax on
chat.zulip.org when developing an integration and rightfully so- only
the people who work on Zulip (and specifically, markdown) are likely
to stumble upon it and try it out.
This is also the only peice of code due to which we had to look up
emails -> userid mapping in our backend markdown. By removing this,
we entirely remove the backend markdown's dependency on user emails
to render messages.
---
Relevant commits:
- Oct 2012, Initial commit c31462c278
- Nov 2013, Update commit bot 968c393826
- Nov 2013, Add avatar syntax 761c0a0266
- Sep 2017, Avoid email use c3032a7fe8
- Apr 2019, Remove from webhook 674fcfcce1
Previously, the function update_table_stream_color did not update the
color of the date_row when it appeared within a topic. This was
incorrect because it meant that a small piece of the border to the
left of the message box would be left to the previous color when the
stream color was updated. This commit resolves the issue by adding an
update.
Fixes#15197.
To make the typeahead code more readable, we extract this function to
timerender. We also improve the logic to be more readable, and add tests
to confirm its validity.
We have moved our invalid timestamp logic to use timestamp-error class,
however, if there are any valid outputs by the backend markdown that
the frontend considers invalid, we want to debug them. This commit
adds tooling to ensure we log those error messages.
We had been using !time() syntax for timestamps so far. Since its
an unreleased feature, we can make changes without affecting many
people.
Fixes#15442.
This commit fixes a bug where clicking on a stream row on the left
in the subscriptions table called the ".stream-row" as well as the
".sub_unsub_button" click events in `stream_edit.js`.
This caused the stream subscription to toggle everytime the row was
clicked. Also, this bug is only observed if the ".sub_unsub_button"
had been clicked first.
The previous element passed was a simplebar container which calculated
the incorrect height, thus `scroll_util.scroll_element_into_container`
had no effect.
There is a bug and race issue that occurs when a message is selected
while we are in the process of reifying a locally echoed message,
raising the "Selected message id not in MessageList" error.
The code flow to get the exception is as follows:
* A user sends a message to the current narrow we are in.
* Before the new message event is received, we sent a message to
the same message list which renders it with a locally echoed id.
* One of the ways of getting the exception is to already have the
locally sent message selected, before receiving an acknowledgment
from the server.
* Thus the Message List Data's `selected_id` now points to the new
message id. The exception is raised on entering the `was_selected`
if block inside `message_list_view` which tries to re-select the
message.
Updating the `_rerender_message` code for this special case won't fix
the entire bug because, as mentioned above there are other ways of
getting the exception:
Ideally, after all our synchronous work (`echo.process_from_server`)
has completed we would expect the re-order and re-render work of the
`change_message_id` would occur first, due to the timer of the
setTimeout being set to 0.
However as evident from the race condition existing, this isn't always
the case. `change_message_id` function is responsible for 3 things:
updation, re-ordering and re-rendering.
The first one which is responsible for updating the message list's
local cache, occurs synchronously while for the latter two, they both
occur asynchronously.
Before the setTimeout which is responsible for the latter two actions,
is encountered the user might select the message by clicking or more
commonly by scrolling, which causes this message selection event to be
ahead of the setTimeout in the callback queue.
During this time frame, our race condition takes place.
And even though the message id is updated it's Message List is not
in the correct sort order, which leads to `closest_id` !== `id` in
`MessageList_select_id` being true and raising the exception.
Now, we only asynchronously call the re_render function, to guarantee
the data is always correct and UI updates should be done at the end.
Extended by tabbott to comment the setTimeout call.
Fixes#15346.
We change validate_stream_message to check the existence of stream from
the stream name in compose box early and we then pass stream_id or the
obtained sub objects accordingly to other validate functions.
Passing stream_id or sub objects to these functions, enables us to use
stream_id instead of stream name in stream_data.get_subscriber_count.
stream_data.get_stream_post_policy is also removed as we only used it in
validate_stream_message_policy, but we do not need it now as we can get
stream_post_policy directly from sub object obtained by early check of
valid stream name.
This commits add data-stream-id attribute to the compose_invite_users
template. This helps in avoiding the error that occured if user
clicked the link after renaming of stream.
As a result of above changes, the checks for empty and invalid stream
name in compose box are done in warn_if_mentioning_unsubscribed_user
function instead of needs_subscribe_warning function.
If a channel has a thousand subscribers this commit results in the count
being displayed with a thousands separator, e.g. with English locale you
get 1,000 instead of 1000.
Since we migrated to `image_upload_widget.hbs`
for upload widget's so we have to access those widget's elements
according to the `image_upload_widget.hbs` new CSS class names.
We need to access delete button element with
`#user-avatar-upload-widget .settings-page-delete-button`
not with old CSS id `#user_avatar_delete_button`.
When we extract common HTML template (`image_upload_widget.hbs` )
for user avatar, realm day/night logo and realm icon widget's
lot of new CSS are created to match image_upload_widget.hbs and
old CSS are preserved in `settings.scss`. This commit removes all
unwanted or unused CSS in `settings.scss`.
For the email and full name modals we simply change width to max-width.
The password modal used a flex-row class for no apparent reason,
the class wasn't used anywhere else and removing it fixes the UI bug.
Fixes#15311.
While highlights was the only case where this came up in the normal
message feed, we might in the future have other elements inside a
link, and we don't want those to ever eat the click.
I don't think there's a real performance concern here; fundamentally,
this is the handler for the user clicking, it can traverse a few DOM
elements.
Adds support for clicking anywhere on the header (except in a link) to
expand a spoiler block. Also fixes jumpy animation glitch on spoiler
collapse.
Fixes#15414.
Co-authored-by: Sara Gulotta <sgorecki@gmail.com>
Fixes the click target for the gear icon by providing
a proper rectangular area around it.
Minor UI adjustments of gear icon and expanded
navbar-search for small size devices.
Fixes: #15222.
When the keyboard focus is not on search box and user clicks on
search box, the focus will go move away from the search box to
the `current_focus_elem` on any rerender. To avoid that, we
move `current_focus_elem` to the search box when user clicks on it.
Since we had extracted `image_upload_widget.hbs` HTML for
image upload widget's like user avatar, realm logo, realm icon
we can also extract `image_upload_widget.scss` SCSS file
from settings.scss file with all the CSS related
to image upload widget's.
This change will also help us to keep `settings.scss` cleaner.
Previously, this was unconditional wrt local echoe which caused a bug
where by the pencil edit icon was visible first, then got hidden when
the chevron and star became visible.
This commit resolves the above bug, but this area still behaves
slightly weirdly in that, if, within a PM narrow, the user's mouse
cursor is over the spot where the message edit controls will appear
after sending, and then a message is sent by the user, only the
chevron and star appear at first. On cursor exit and reenter, all
three controls reappear ie the final state is correct.
Similar to the other "unless locally echoed" cases here, this will
probably prevent unexpected bugs caused by eg trying to enter edit
state before the message was received by the server, and then
redrawing later, etc.
Escape all the possible special characters.
We replaced \b with (?:^|\s) since it matches word boundries including
special characters.
Pasted relevant stackoverflow links which expain them properly.
This commit removes unnecessary code for adding and removing
"can_edit" class from emoji-settings element. This class is
unnecessary and is not used for styling or for any other purpose.
This commit removes the ".not(can-edit)" selector filter from
insert_tip_box. We do not require this selector filter because
this class is only used for emoji-settings and we already do not
prepend tip in emoji-settings page from this function and we handle
it separately.
As this class is only used for this purpose we can also remove this
class from emoji_settings_admin.hbs.
The organization_settings_tip is not visible if organization settings
overlay is opened with any section other than organization profile,
settings and permissions. This is because insert_tip_box is called from
settings_org.build_page, which is called only when we open any of the
above three sections after opening the overlay and not others.
We should call insert_tip_box function from admin.build_page instead
of settings_org.build_page because we need to insert the admin tips
each time the organization settings overlay is opened, irrespective
of the section which opens first.
The function insert_tip_box is moved to admin.js from settings_org.js,
because settings_org.js file handles the organization profile,
settings and permissions page only, while we display the tips in many
other sections including bots, custom emoji, etc.
Thus, it makes sense to move insert_tip_box function to admin.js, which
renders the complete organization settings overlay using render_admin_tab.
We send user_id of the referrer instead of email in the invites dict.
Sending user_ids is more robust, as those are an immutable reference
to a user, rather than something that can change with time.
Updates to the webapp UI to display the inviters for more convenient
inspection will come in a future commit.
In zulip.yaml, add `deprecated` tags to all parameters/keys with
`Deprecated` in the description. Then add tests to ensure that deprecated
parameters/keys will always have the `deprecated` key. Also, in
the API docs, sort the parameters according to presence of `deprecated`
key, presenting the `deprecated` keys at the end and add a `deprecated`
tag next to them.
This commit removes "realm_message_retention_days === null" check from
the conditionals, as we had updated the backend to replace NULL value
with -1 in 7a03e2a.
This commit fixes the UI for stream message retention days to allow
only owners to set or update the setting.
We hide the setting for non-owners in the stream creation form and
disable it in the stream_privacy_modal.
Fixes a part of #15558.
If your browser width was between 701px and 750px you got the mobile
view without the mobile header preventing you from changing sections in
the settings menu.
This was caused by a media-query mismatch:
subscriptions.scss used @media (max-width: 750px)
settings.scss however used @media (max-width: 700px)
Comments added by tabbott to help avoid future bugs like this.
* Don't annoyingly open the first section when switching
between the Settings and Organization tabs.
* Don't highlight currently active section in the settings list
(we don't display the currently active section in the mobile settings
list so it isn't actually active).
* Remove nearly invisible and buggy no-border logic.
The previous architecture did not work properly with the automatically
detected night theme, resulting in a weird mix of the night and day
themes on code blocks.
I'm not thrilled with the requirement this imposes that all of our
night theme CSS needs to be in one file, but we do need to get a quick
fix out here.
Fixes#15554.
This commit removes invited_as_values map in settings_invites.js.
This object has been removed to avoid duplication as we already
have role values in settings_config.js.
A similar map is created from settings_config.user_role_values
in settings_config.js and is used to populate invited_as_text
for invites.
This commit changes the PreregistrationUser.invite_as dict to have
same set of values as we have for UserProfile.role.
This also adds a data migration to update the already exisiting
PreregistrationUser and MultiuseInvite objects.
We leverage the composebox typeaheads to show flatpickr to pick dates
and times for the !time syntax.
We use moment.js to try and parse the time from current token. If we
are successful, we initialize flatpickr with the parsed time, else we
default to using the current time.
Currently we display -1 in input box of id_realm_message_retention_days
when realm_message_retention_days is -1, which isn't user friendly.
Displaying the input box as empty is more intuitive.
And if the user tries to submit an empty input box we throw invalid JSON
error that isn't user friendly either, so fixed that too. In the ideal
case, we shouldn't send the request at first place to the backend when we
don't have any input.
Currently, we use -1 as the Realm.message_retention_days value to retain
message forever unless specified at stream level for a particular stream,
that is, no policy set at the realm level. But this is incoherent with what
we use for Stream.message_retention_days where -1 means
> disable retention policy for this stream unconditionally
that can be confusing from an API standpoint.
So instead of trying some hack to reset the value to NULL or using some
other value like -2 for RETAIN_MESSAGE_FOREVER and use that for API. It is
much more intuitive to use a string like 'forever' that can be mapped to
RETAIN_MESSAGE_FOREVER at the backend. And this is similar to what we use
for streams settings as well.
`get_input_element_value()` function is more reliable to detect the input
element type and extract it's value. But the current way of setting the
value of input elements relies on first checking the `property_value` type.
Which is fine, but for the cases when the property value is null, and we
want to set element value as empty, this method will throw an error as it's
unable to detect the appropriate element type. This new function
`set_input_element_value` first rely on property value and then use
`setting-widget-type` as a fallback.
This fixes the change detection of org settings input elements. Luckily,
this regression didn't break our populate_data_for_request and that's also
why this didn't come to notice.
In 5200598a31, we introduced a new
client capability that can be used to avoid unreasonable network
bandwidth consumed sending avatar URLs of long term idle users in
organizations with 10,000s members.
This commit enables this feature and adds support for it to the web
client.
If the `load_messages_for_narrow` function tried to fetch messages with
a floating point anchor (locally echoed message id) we get a 400 error.
The logic to remove the rounding of the anchor parameter was done in
commit bf2f36e6b4, as it would always be
an integer in all incoming code paths.
However, since then we have updated the GET /messages API, to also allow
strings as the anchor parameter and this value's parsing is done in the
backend.
Fixes#15497.
We update the logic for displaying the "message is outside current
narrow" notice, by comparing whether the message the client sent can
be appended to the current narrow's filter or not (this results in us
correctly falling through to reporting the user needs to scroll down).
Previously in desktop view, the realm day/night logo element is arranged
one by one which is not looking good since we have a lot of space on the
the right side of the logo elements so we can move day/night logo elements
to allow them being alongside.
In mobile view, we don't have any space on the right side of the logo
elements so we don't have to change anything.
Fixes these compilation errors from webpack and PostCSS, exposed by
commit b10f156250 (#14997) which tries
to @extend these directives:
Unexpected '}' at app.d5da4b9d46e79634b8fb.css:9103:4.
Unexpected '}' at app.d5da4b9d46e79634b8fb.css:9104:0.
Invalid property name '@-moz-document url-prefix() {
@nest & #settings_page select {
background-color' at night_mode.scss:788:0. Ignoring.
Invalid selector '}
}
.user_status_overlay .overlay-content' at night_mode.scss:797:4. Ignoring.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit changes stream_data.create_sub_from_server_data to use
stream id, instead of stream name, for checking whether subscription
already exists or not. We are using stream ids so that we can avoid
bugs related to live update after stream rename.
This commit changes would_receive_message and want_normal_display
functions in compose_fade.js to use stream id, instead of stream
name, to get sub object. We are using stream ids so that we can
avoid bugs related to live update after stream rename.
This commit changes populate_group_for_message_container function to
use stream id to get sub object, instead of stream name.
We already have stream id from message object, so we can easily
use it to fetch sub. We are using stream ids so that we can
avoid bugs related to live update after stream rename.
This commit changes stream_data.remove_subscriber to use stream id
instead of stream name. We are using stream ids so that we can
avoid bugs related to live update after stream rename.
Thsi commit changes stream_data.add_subscriber to use stream_id
instead of stream name. We are using stream ids so that we can
avoid bugs related to live update after stream rename.
This commit removes stream_edit.rerender function. We directly
call subs.rerender_subscriptions_settings directly from
server_events_dispatch.js, which was the only caller of rerender
function, as we already have sub object.
We are using stream ids so that we can avoid bugs related to live
update after stream rename.
We can use get_sub_by_id instead of get_sub to get the stream info,
as we already have stream id from the message object. We are using
stream ids so that we can avoid bugs related to live update after
stream rename.
This commit changes receives_notifications function to use
stream_ids instead of stream names. We are using stream ids so
that we can avoid bugs related to live update after stream rename.
Prior to this commit has:link, has:attachment, has:image
filter couldn't be applied locally and deferred filtering to
web server. This commits make sure client filters all messages
it can instead of completely deferring to the server and hence
improve speed.
A tradeoff is also made to turn off local echo for has: narrows
as messages with link sent to has:link narrow were locally echoing
to another narrow and not appearing in the active has:link narrow.
Fixes: #6186.
Previously, the message controls had a bug where they would trigger on
mobile with a single tap over the area they occupy when visible. This
is wrong because a user would expect to first see the controls and
only trigger them once they are visible (with a second tap).
The above bug is caused by the fact that we were using "opacity: 0" on
".message_controls > div" to hide the controls and "opacity: 1" on
".messagebox &:hover .message_controls > div" to show the controls on
hover, however, this would not effect the click action because
"opacity". So we used "pointer-events: none;" and "pointer-events:
all;" with the hopes that it would prevented the above bug, but in
practice, it didn't.
(the most probable explanation being that tapping the message_control
area would cause the "&:hover" rule to trigger and change the
"pointer-event" to "all" before it could prevent the click trigger,
But that explanation is just conjecture.)
This commit replaces both "pointer-events" attributes with
"visibility: hidden" and "visibility: visible" respectively. The
result being that the message_controls behave identically to before,
except without the above bug.
The addition to the ".has_actions_popover .info" selector is important
because without it, we would regress on issue #3172.
Trivia:
An alternate approach to using "opacity" is to set the
"display" attribute to "none", however, using "display" prevents the
transition from animating (which is probably why we were using opacity
here in the first place). "visibility" does not prevent the transition
from animating.
History: The "pointer-events" attribute was introduced in
4d5aa3ddc9 and it replaced prior code
which relied on the "visibility" attribute... But it seems PR #3792
was mostly focused on improving the positioning through removal of
`display: none`, but introduced opacity to make the animations work
rather than visibility as the replacement solution, which requires the
pointer-events hack and resulted in the bug described here.
Fixes the second bug described in #13642.
This helps user understand "Include muted" filter better and
saves keypress to focus on more used filters like "participated"
and "unread".
See https://github.com/zulip/zulip/issues/15482.
With this implementation of the feature of the automatic theme
detection, we make the following changes in the backend, frontend and
documentation.
This replaces the previous night_mode boolean with an enum, with the
default value being to use the prefers-color-scheme feature of the
operating system to determine which theme to use.
Fixes: #14451.
Co-authored-by: @kPerikou <44238834+kPerikou@users.noreply.github.com>
With the previous color it was hard to read the text and
also that color does not matches with the zulip style.
This commit changes the color of `name` field for
user-profile modal for better visability both in day
and night mode.
We can now invite new users as realm owners. We restrict only
owners to invite new users as owners both for single invite
and multiuse invite link. Also, only owners can revoke or resend
owner invitations.
Add arrow key navigation support for recent topics.
Simple jquery is used to allow navigation for filter buttons,
a grid system is used for navigation inside table.
This commit corrects the message shown when we click the add button
for subscribing users to stream with empty input.
We show 'No user to subscribe.' as the message when trying to add
subscribers with empty input.
Fixes#15450.
This improves the logic and fixes the bug where the href was calculated
based on the current URL and not the filter of the current message list.
We now add the '/streams/public/' operator at the start of the operators,
similar to how it is represented in all other cases.
Fixes#15405
The `.search_icon` lies inside the `.pill_container` so we had to
remove it's display attribute which should have no visual changes.
We add `flex-wrap: nowrap` to prevent the cursor from moving onto
a new line, below the pills.
Fixes#15480.
This commit removes the click handler used for
'empty_feed_sub_unsub' class.
This class was used only in home.html and was replaced
by 'stream_sub_unsub_button' in 576be51.
This reverts part of b0d632577f.
The problem was that multiple queries were combined as a single
search pill. And since we create the pills then narrow / search,
we added a comma seperator between them for the typeahead lookups
as required by the logic in `input_pill.js`.
This however introduced a new bug where the search suggestions
were incorrect as the typeahead lookup table wasn't updated, so
every time an item from the type ahead was selected it updated
the input string with an invalid operator.
Thus to resolve the first problem, we follow a simpler approach
by extracting all operators from the search string using our
`Filter.parse` logic and next add the pills, one by one.
Whenever a search pill is selected or deleted by a click the navbar
gets rendered as the searchbox loses focus. This allows the user to
be able to continue editing the search query without having to refocus
the searchbox.
A main change is that we now display the navbar if the search box
is not focused. This was already present in the search pills version
but adding it to the legacy version is an improvement.
We sufficiently increase the timeout so that the pills are actually
deleted. This was required when `filter.is_common_narrow()` is true,
as then only we render the narrow description and close the search bar.
This commit also matches another behaviour of the legacy search.
i.e. We narrow every time a search suggestion is clicked.
The now redundant "focusin" and "focusout" event handler tests are
also removed.
This change was only required for the search pills enabled
search. As there is a valid use-case where the user might
want to remove just the latest pill(s) and then narrow.
This wasn't possible previously because, the typeahead was
looked up every time the backspace key was pressed. And since
the only way to narrow in search is through the enter key,
if the user entered it then the searchbox would get updated
with the first suggestion in the typeahead.
The alternative for the user would be to first lose focus on
the searchbox (by clicking outside) the focus again which
doesn't generate the typeahead. Then only the enter key would
be available for narrowing.
We do not display the typeahead after the search pills are
created. This is done just to match the behaviour for the
deletion of pills case too.
We use this approach and we don't just change the line
in `search.js` from `helpOnEmptyStrings: true` to
`helpOnEmptyStrings: !page_params.searchpills enabled`
because we still need to provide suggestions for '',
on initial lookup or every time the empty input searchbox
with search pills present gains focus.
When we move the avatar upload widget to `image_upload_widget.hbs` file
the CSS `position:absolute` for `avatar-source` is preserved.
by removing CSS `position:absolute` we can fix the bug.
Two things were broken here:
* we were using name(s) instead of id(s)
* we were always sending lists that only
had one element
Now we just send "stream_id" instead of "subscriptions".
If anything, we should start sending a list of users
instead of a list of streams. For example, see
the code below:
if peer_user_ids:
for new_user_id in new_user_ids:
event = dict(type="subscription", op="peer_add",
stream_id=stream.id,
user_id=new_user_id)
send_event(realm, event, peer_user_ids)
Note that this only affects the webapp, as mobile/ZT
don't use this.
We recently removed an API call for fetching user list for our
Settings>Users/Deactivated panels, which introduced a bug where
we rendered the users table before last active information is
processed by the frontend.
This commit makes us process presence before rendering our settings
panels. We move the presence init above because we need to initialize
settings_sections before hashchange.
Fixes#15453.
When the user clicks a button that opens a modal, and if we don't break off
the corresponding click event. This condition in the global click handler
will become true and enables all mouse events outside modal.
```js
$(document).on('click', function (e) {
...
// If user clicks outside an active modal
if ($('.modal.in').has(e.target).length === 0) {
// Enable mouse events for the background as the modal closes
$('.overlay.show').attr("style", null);
}
```
Related to #12369.
This commit adds message retention policy details in the subscription_type
text below the stream description.
We do not show any text when realm-level settings is set to forever and
stream-level is set to either forever or realm_default.
This commit adds frontend support for setting and updating message
retention days of a stream from stream settings.
Message retention days can be changed from stream privacy modal of the
stream and can be set from stream_creation_form while creating streams.
Only admins can create streams with message_retention_days value other
than realm_default.
This commit also contains relevant changes to docs.
This commits adds the code for live update of stream_post_policy in
subscription_type text in stream settings.
This is done by passing stream_data.stream_post_policy_values to the
template data, which were not passed previously and the if conditions
were not evaluated correctly.
Previously, we had implemented:
<span class="timestamp" data-timestamp="unix time">Original text</span>
The new syntax is:
<time timestamp="ISO 8601 string">Original text</time>
<span class="timestamp-error">Invalid time format: Original text</span>
Since python and JS interpretations of the ISO format are very
slightly different, we force both of them to drop milliseconds
and use 'Z' instead of '+00:00' to represent that the string is
in UTC. The resultant strings look like: 2011-04-11T10:20:30Z.
Fixes#15431.
There is apparently some way to have two instances
of `.emoji-popover-emoji-map`, although I can't
reproduce it.
This causes an `expectOne` check to fail fairly
deep in the stack.
Now we report it more directly.
This commit and a few previous ones mostly
address #15348 by trying to either a) not
depending on having a single instance of
the popover or b) making it more explicit
in cases where do expect that invariant.
Fixes#15348
This is just a pure refactor for now, but
we may want to modify this to more precisely
determine the active map (in case multiple
pickers are open for some reason).
This is clearly a better home for it, since message_scroll.js is the
only place that reads it, and also lets us provide a clearer name for
the functionality.
Since we are no longer using the "pointer" value sent in
page_params.pointer for anything, there's no value in continuing to
send it from the server to the client.
The remaining code in pointer.js is logic managing state for the
currently selected message.
Since the pointer is no longer used to set the browser's position, we
no longer need this complex code to send updates to the server during
the bankruptcy flow.
It's crazy that we need to do this; one would think that Electron apps
whose sole purpose is to be used with multiple team chat tools would
at least implement the standard desktop notification API correctly.
But it seems worth making this tactical change to prevent every
desktop notification throwing a traceback on those platforms, which if
nothing else results in a lot of error spam.
Fixes#15103.