We convert the following elements to use a class instead of
id for accessing them across the codebase:
* markdown_preview
* undo_markdown_preview
* markdown_preview_spinner
* message_edit_content
* preview_content
Converted them together since changes to one impacted the other in
some modules like click_handlers.
Also, added a function in rows to get `message_row`.
We use `.compose_upload_file` across compose and message_edit_form
for file upload icon. This will help us share common code between
`compose` and `message_edit_form`.
In both compose and `message_edit_form` we use `file_input`
class to identify the file `input` element. This will help
to more easily share common elements between compose and message_edit.
Since we can have multiple instances of `message_edit_form`, it
makes sense to have it as a class.
We track the message_edit_form by setting an id to
`form` element dependent on message_id.
This commit makes it so that muted users never appear
in the right sidebar buddy list, filter text or not.
The hiding is done in the frontend only, and we still
recieve presence data from the server as before, so
no extra work is required on unmuting someone, other
than to rerender the user list.
Long term if we find that there are too many muted users,
we may want to optimize how we send presence data, but
that is unlikely to happen.
The other less extreme option is to gray out muted users,
but that cannot be done because it would conflict
with the graying out we do for non-recipients when the
compose box is open.
This makes the naming more intuitive and gives us a
single place to add more conditions on filtering
user_ids, with the current motivation being filtering
muted users, the logic for which will be added in further
commits.
This is a direct code move which puts all the functions
related to `user_id` lists near the bottom of the file.
This will make the file slightly easier to read.
Long labels like "Yes, Unsubscribe this stream" can
be confusing for translators and it can also create bad
strings that can end with like 4 long words in German.
It is better to have the simple options like "Confirm"
and "Cancel". This commit fixes this issue by changing
the text to "Confirm".
Fixes#17926.
Previously, realm emojis can override default emojis in emoji-picker,
if the user sets an exisitng emoji name to his/her custom emoji.
For clear understanding--
If a user sets an realm emoji with name `smile`, this leads to the
newly realm emoji override the existing default emoji `smile`.
To address such behaviour, Added a warning modal which requires
the user confirmation before overriding the default emoji.
Fixes#16913.
Moved `admin_user_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
rather than the `/templates/settings` folder.
Fixes#18227
Moved `admin_user_group_list` template to `/templates/settings/` folder
as earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder.
Also modified the node tests to reflect the new changes.
Moved `admin_tab` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder instead.
Moved `admin_profile_field_list` template to `/templates/settings/` folder
as earlier, it was inaccurately placed within the `/templates` folder
rather than the `/templates/settings` folder.
Also modified the node tests to reflect the new changes.
Moved `admin_linkifier_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
rather than the `/templates/settings` folder.
Moved `admin_invites_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder instead.
Moved `admin_human_form` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder.
Moved `admin_export_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
rather than the `/templates/settings` folder.
Moved `admin_emoji_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder.
Moved `admin_default_stream_list` template to `/templates/settings/`
folder as earlier, it was inaccurately placed within the `/templates`
folder and should have been within the `/templates/settings` folder
instead.
Moved `admin_bot_form` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and `settings` folder is specifically for storing administrative
UI templates.
This involves in two changes for styling.
1. The alert class is moved from alert.css to app_components.css as this
class serves nothing but to default .alert elements to be hidden. This
is only required in the webapp but not portico pages (where .alert
elements are preferred to be shown by default).
2. The import statement for alert.css is moved from app.js to common.js,
so that both the webapp and the portico pages can share the styles. This
will be fine to share the styles as .alert-display, .alert-animations,
.alert-box are more specific then .alert and they use nested class to
define styles for inner elements.
Undoes #17936 properly.
This improves the UX of creating a stream for atleast 1000+ users
realm by showing the the stream creation form much faster than
before.
Search, user addition, scrolling worked smoothly on 15k+
users realm as tested on dev setup.
Also, simplebar is used to replace the default scrollbar.
Fixes#16805
When moving a topic within a stream that is deactivated, the stream
may not be present in stream_data. Avoid throwing an exception in
this situation by leaving stream_name as undefined; existing logic
seems to anticipate that as a possibility, so we don't need a broader
change.
Longer term, we may want to just send to clients basic data about
archived streams that the user has access to.
Fixes: #17271
This commit adds a helper function: `mute_or_unmute_topic`
in `click_handlers.js` to mute and unmute a topic. This function
is called when a user mutes/unmutes a topic from its recipient bar
or `recent topics`.
This is a prep commit for `Allow unmuting of a topic from its recipient bar`.
Related issue: #15223.
The bug happens in the case when the topic name is not set and the
user clicks on always_visible_topic_edit button results into unusual
behaviour of the always_visible_topic_edit button. To fix this, this
commit fix the behaviour by hiding and showing the
always_visible_topic_edit button in the appropiate situations, at the
same time we hide/show similar buttons.
Fixes#17813.
This allows us to use different "Show password" and "Hide password"
for these labels, which is more consistent with how other products
implement this.
It also lets us delete N duplicate copies of these strings in the HTML.
The "Save failed" standard text is appropriate for many of our
settings, but for changing one's password, we can go with just the
"Wrong password" part provided by the server.
The show password feature is a functionality to
toggle the visibility of the password fields in forms
so that one can check if they have entered the correct
password or not. We implement this using an eye icon
toggling which converts input field type from password
to text and vice-versa.
Fixes part of #17301.
This allows us to hide tooltips automatically when the
parent container is hidden while tooltip is active.
In an overlay, when a tooltip is active and `esc` is pressed,
the tooltip will remain active without this commit.
This has side effects of some properties of parent applying to
tooltips if property is directly set to `div`. Through manual testing,
only area where this was found was fixed.
We destroy the tooltips for which `reference` was either removed
from DOM or is hidden.
We only need to do this for tooltips
contained in simplebar containers for which tooltips can
overflow the boundary of the simplebar container.
There are 4 approaches we could have done this:
1. Asked tippy.js maintainers to do this for us.
In https://github.com/atomiks/tippyjs/issues/938 the
maintainer said that it is the responsibility of
the user to do so.
2. Tracked whenever we update the DOM for such elements and hide
tooltips when we were hiding the `reference` elements. This had
various problems like it is hard trigger events when certain elements have
been removed from DOM when `html()` method is used to render
new content.
3. Run an `optimized` periodic job to destroy tooltips when
`reference` elements are hidden. This isn't a good method to
do this since it sucks power and adds latency.
4. Use a `MutationObserver` on the parent element and watch
for changes. This methods seems to work well with no bad
side effects. We use this approach.
Instead of inserting tooltip inside `body`, we directly insert
it inside the `reference` element. This helps us to automatically
hide the tooltip when we hide the `reference` element.
This avoids the bug of tooltip persisting when the message reaction
is removed while the tooltip is active.
To reproduce:
* React 👍 to a message.
* Hover over the reaction.
* Press `+` from keyboard.
You will see reaction tooltip persisting while the reaction is hidden,
also "Add emoji" icon is displayed with tooltip.
Doing the same for elements which are inside a simplebar container
and for which tooltips can span outside the simplebar container,
makes the tooltips not visible or cut at the edges of simplebar
container since simplebar containers have overflow set to `hidden`.
This is something that cannot fixed as per
https://github.com/Grsmto/simplebar/issues/347
So, for simplebar contained elements we insert the tooltip to
`body`.
`reference` element: Element for which tooltip is displayed.
