This commit eliminates a bug, introduced in commit
7bc04bb829, where the send button's
tooltip hotkey hint would have incorrect placement when the user had
triggered a tippy instance on the send button while it was disabled.
The reason behind this bug was the conflict between code in the
previously mentioned commit which set the tooltip content to
`display: block` to account for the inline italicized empty topic name
in the error message, and the need for `display: flex` to ensure the
hotkey hint was positioned correctly.
This commit introduces the use of createSingleton from the Tippy.js
library to group the tooltips of compose box formatting buttons. The
main benefit is that the hover delay only applies when you move the
cursor into the group for the first time — after that, tooltips show up
instantly as you move between buttons. It makes the whole experience
feel a lot smoother.
We store the singleton instance in a variable to avoid creating multiple
instances unnecessarily. Before initializing a new singleton, we destroy
the previous one to prevent memory leaks and ensure correct behavior.
Previously, each formatting button had its own independent tooltip with
separate delays, which made the experience feel sluggish and disjointed
when hovering across buttons.
Now, by sharing a delay timer across the grouped tooltips, the
transition feels more natural.
Fixes: #24825.
Co-authored-by: Sayam Samal <sayam@zulip.com>
Compose send tooltip was not correctly displayed when the compose
box was in an invalid state.
We significanlty improve the logic for displaying the tooltip here
to provide a more robust experience to the user.
Previously, the send button's tooltip was triggered by
the entire message controls row, which also contains the
options button. This caused overlapping tooltips as the
options button has its own tooltip.
This commit resolves the issue by applying the tooltip
only to the send button.
This commit adds tooltip support for various
invalid conditions mentioned in issue 32115.
A `show_banner` positional argument is added
in the `validate` method which has a default
value of true.
The reason behind introducing this is to
not trigger banners on hovering the disabled
send button, since the tooltip message is also
determined using the same validate method.
We want to only disable the button on hover,
which is why the update_send_button_status() method
is called only on "mouseenter" event, which is
added to the send button in compose_setup.js
To incorporate this change a new param is
introduced which determines whether to enable/disable
send_button by running update_send_button_status
Earlier, typing something in the textarea or
recipient box would also trigger
`update_send_button_status` which doesn't
work well since we've introduced a lot of
new booleans which determine whether send
button gets disabled causing send button to
get disabled while typing instead while hovering
Hence this change.
This commit is a pre commit to a change that will
introduce banners and tooltips as per various
unmet conditions while composing a message.
To accomodate future changes, the toggling is
switched to conditional addition/removal of the
`disabled-message-send-controls` class while
updating the status of the send button.
Also a default cursor is added and the send
area tooltips are disabled whenever the
`disabled-message-send-controls` class is
present.
This adds the "New direct message" button back in the closed compose UI
for DMs view, to make the closed compose UI consistent across the app.
Since the closed compose UI is always visible, and one that is likely
to be used frequently, it makes sense to have the same UI across all
the views to avoid the mental overhead of figuring out how to compose
a message in different views.
Bug:
A tooltip appears on hovering over a control button in the
message edit form. Now when the form was closed either using
Esc key (cancel) or Enter / Ctrl + Enter (save), the tooltip
didn't disappear. This resulted in a random tooltip visible
in the message list view.
Fix:
Since tippyjs doesn't hide tooltip even after the element is
hidden we need to explicitly hide the tooltip in those cases.
See https://github.com/atomiks/tippyjs/issues/938
This commit fixes the above mentioned bug by explicitly hiding
the tooltip instance.
Names like “delegate”, “Instance”, “Placement”, “Props”, and
“ReferenceElement” are much too generic to make sense as named
imports.
The downside is that we now need to write tippy.default(…) instead of
tippy(…) (because ES module namespace objects cannot be callable), but
that cost is worthwhile.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Important changes in this commit:
* We only cache message list for "Combined feed" if it is the
default view.
* We modify existing handling of home message list code so that
it can be used to for any message list that we want to cache
using a new `preserve_rendered_state` variable.
* narrow_state.filter() returns the filter of combined feed view list
instead of `undefined`.
* We start fetching messages from the latest message on app load.
* Messages in all messages data and Recent view are always synced.
* If combined feed view list is not cached, we don't track it's
last pointer, effectively sending user to the latest unread
message always .
Change compose_reply_button tooltip logic to show the correct tooltip.
Earlier in organizations where DMs were disabled, a stale tooltip was
being displayed.
Earlier if the user hovered over the compose_reply_button when it was
disabled and switched to a stream in which it was enabled before waiting
for the tooltip delay, the next time the user hovers over the
compose_reply_button the stale disabled tooltip is displayed instead of
the enabled one.
This is fixed by checking if the compose_reply_button is enabled on the
fly while rendering the tooltip via instance.setContent().
Fixes#29238.
Updates translated strings in web/ that do not need updates to any
tests. The majority of these strings are also unique to the file/
template that they are in. A few have overlap with one other file.
Some changes here update placeholders/variables in these strings to
no longer use stream so that all the translation updates for this
rename happen at the same time.
The exception to this are cases of "<z-stream>" placeholders in
these translated strings.
Part of the stream to channel rename project.
Update the Filter class to use "channel" as the canoncial operator
for streams, but keep using "stream" for user-facing text and URLs.
When searching, "channel" does not create any suggestions until
a colon is added and then it shows suggestions with "stream". And
when a search string with channel as an operator is entered, then
it is replaced by "stream" as well.
Part of stream to channel rename project.
