This reverts commit 6fba17599f (#16898).
@chrisbobbe reported this crash:
Uncaught TypeError: Cannot read property 'stream_id' of undefined
at starred_messages.js:43
at Array.filter (<anonymous>)
at Object.e.get_topic_starred_msg_ids (starred_messages.js:40)
at stream_popover.js:221
at HTMLSpanElement.<anonymous> (stream_popover.js:358)
at HTMLUListElement.dispatch (jquery.js:5429)
at HTMLUListElement.v.handle (jquery.js:5233)
Signed-off-by: Anders Kaseorg <anders@zulip.com>
The textarea in Settings/User Profile was overflowing in
smaller width devices.
This commit fixes that issue by adding appropriate media queries.
Fixes part of #16817.
This reverts commit 34ada11448.
That commit traded a minor visual glitch for a major usability
regression at my most common browser width (960px).
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Previously, exact matches could be pushed off the typeahead list in the
case where there were more prefix matches that happened to rank first,
which is confusing to the user: if an emoji, for instance, falls into
this category, it will never show up in typeahead, which is easy to
confuse with the emoji not existing.
This isn't a perfect fix — there are still cases where it's hard to find
emojis because the prefix-space is very crowded, but it does fix a
category of surprising and frustrating behaviour.
This doesn't come completely without downside - it means that the exact
match emoji will jump to the front of the list, which changes what is
currently conceptually a "filtering" operation to a "filtering and
sorting" operation, but it seems on the whole to be a more ideal
experience. This is particularly notable in the non-typeahead emoji
picker, which uses the same codepath, but this change seems somewhat
desirable even there, since it allows the user to type the name of an
emoji and press enter and have that emoji show up, without having to
visually confirm that they aren't inadvertently selecting a
prefix-matching emoji.
A better solution to this in the long term might be ordering emoji
results by shortest-first as a tiebreaker for alphabetical ordering,
since that should provide the same behaviour while keeping the mental
model as "filtering" (since the sort order won't change as the user
types), but this seems like a reasonable first pass, and changing to
shortest-first ordering after making this change won't break any muscle
memory for existing users.
We change the text. This is an attempt to make the text space occupied by
the col header of last message timestamp smaller so that
it doesn't overflow to next line in some languages.
Also, add some extra padding.
We don't need to handle user clicking on Zulip logo since
changing the hash via the `a` tag takes care of it automatically.
Also, cleanup the narrow.restore_home_state function since
it is no longer being used.
We manually trigger a re-render of RT after a stream is muted
to update the list of topic in RT for the active filter.
This fixes the bug that RT doesn't update correctly
after a stream is muted.
On safari, after search box wraps to next line on smaller widths,
it is not visible due to some flex box default property difference
between chrome and safari. We fix this by resetting default
property.
If user is in private message narrow, we reduce height of stream
list to allow height for pm list in the left sidebar. We need
to recalculate it when moving out of pm narrow and moving in
rt narrow.
We need to increase a bit of spacing around text in rows at <750px
because row height is reduced after hiding avatars. We use
padding instead of line height so that this plays nice when text
is wrapped.
Note more padding is also required for >750px now because text
can be wrapped now and take more width than avatars.
Since All messages narrow is no longer home page for webapp,
we change its icon to align-left which also shows a concept of
interleaved topics / messages.
When idle, we try to backfill messages and in the end reselect
the closest message in the list, which can be a unread message
if present.
When recent topics is open, we can backfill messages; but
shouldn't select the message_id otherwise it will mark the
message as read if the message is unread while triggering
`message_selected.zulip`.
User can go from recent topics to stream / topic narrow via various
means, but all go through narrow.activate, hence we make sure all the
state changes we do in recent_topics.hide are actually applied when we
hide recent topics and go to another narrow.
This fixes the bug that narrowing from left sidebar to a stream
takes user to the top of the narrow.
The top row of the RT can be hidden sometimes after scrolling down
and then scrolling up. This is because the focus is applied before
the row is rendered. Applying the focus after the topic row is
rendered by the browser makes sure it is always visisble when
it needs to be.
For inputs to recent topics which were unhandled, we return false
so that the browser can handle them.
This also fixes the issue of search box not able input `t` key.
We land user on the first row of the table instead of the search
box because here user can access hotkeys like `w`, `q`, `/`, etc,
which will not be directly available if user is focused in
recent topics search box.
For tests:
We set focus to search by default to avoid mocking a lot of
table html for getting the tests passing.
This fixes the bug where a user cannot type vim keys in the
general search box / user search / stream search,
since they are captured by recent topics.
The behaviour was flaky for stream search, but can be reproduced
consistently after previous commit fixing the popovers.any_active
output.
Previously the filter would be reset every time the page was
refreshed. This commit adds persistence via localstorage, the tests
follow the pattern used in tests for drafts.
Fixes: #15676.
When user directly has hash for overlay in the URL when app loads,
we need to still show recent topics in the background. This
doesn't need to happen in other cases when user is accessing
the overlay after UI is loaded.
Go to Recent Topics on "#", no hash and "#recent_topics".
Go to Recent Topics as the last destination for escape key.
Map `a` key to All messages and change its hash to
`#all_messages`.
throttled mousewheel handler marks messages as read in the
message_list regardless of if the message_list is visible or not.
We don't trigger it if recent_topics is visible.
Recent Topics is no longer an overlay now, but note that it is
also not a typical messages narrow. It can reside between
an overlay and a Filter in the sense that it is dispalyed as
a typical Filter narrow but has properties of an Overlay.
Compose box is not visible in this view as it will be confusing
to many users and hence compose shortcuts have also been disabled.
Keyboard shortcuts that apply on messages have also been disabled.
The remaining shortcuts that apply to a narrow are still accessible
here.
This issue adds the appropriate padding to the
copy_generate_invite_link class. This fixes the copy link icon which
seemed to be shifted when clicked.
Fixes#16868
This commits gives a right margin to the stream description
so that it does not collide with the icon on its right and
also become better visually appealing.
Fixes the following issues:
- Rectifies broken label tag having a misleading 'for' attribute.
- Removed 'name' attribute from unlabelled span tag.
- Removed label expression from DropdownListWidget to built an,
abstraction for control group only.
Fixes#17311.
When interacting with popovers in the night theme using the keyboard
UI (e.g. the `i` menu for a message), the background color was
incorrectly white, resulting from the bootstrap `nav > li > a:focus`
rule. We had already fixed this for `nav > li > a:hover`; we just
need to add `nav > li > a:focus` to the relevant block of CSS rules as
well.
Replaces #17195 and #17353.
Rewritten to use a cleaner solution by tabbott.
We now only assign target once, rather than
assigning it then overwriting it for the
not-sent-by-me use case.
I tried to extract a "selector" here but the linter
complained.
Splitting up the tests here ensures we don't
needlessly do extra work here. (In the prior
clumsy implementation, the second test that
I split out here would fail due to the lack
of us setting up the jquery stub.)
On realms with large numbers of custom emoji, the typeahead emoji picker
often isn't useful. This is exacerbated by the fact the picker prefers
longer matches, so if there are five emoji that share a prefix, and an
emoji that is just the prefix, the only-prefix emoji will never show in
the typeahead emoji picker. This means that if someone thinks that there
is an emoji that shares a prefix with many other emoji, but they don't
remember for sure, they cannot use the typeahead emoji picker to check
that the emoji that they are entering exists.
There are two "real" fixes to this, neither of which this commit
addresses:
First, we should adjust the emoji ranking code such that exact string
matches for existing emojis are always shown in the picker. This would
be an improvement overall (the current behaviour is surprising and
frustrating), but it doesn't fundamentally solve the problem - if there
are many matching emoji, some of them will be pushed off the list.
Second, we should allow scrolling through the entire list of matching
entries in a typeahead, instead of only looping through the top N
matches. This will completely fix the problem (although there is some
UI/UX consideration in how to make it clear that the box is scrollable),
but seems like significantly more work to implement.
However, increasing the typeahead box size should improve the user
experience here independently of either of those changes.
I've chosen 8 as the max size for no particularly principled reason -
the fact that it's larger than 5 makes it more useful, but it's not so
large that it covers an obnoxious amount of the screen. Possibly it
would make sense to make it a bit bigger, but 8 seems like a good place
to start.
I've tested this on my laptop, which has a Intel i5-7200U CPU (~4.5 years
old, middle of the line when it was released) on a test instance with
5000 users, as well as on chat.zulip.org, and didn't see any noticeable
performance regression in completing @-mentions or emoji on either.
This warning was added in #6551. It’s not for any version of the
current Electron app, which we warn about on the server side with
DESKTOP_WARNING_VERSION, but rather some pre-Electron app so ancient I
don’t even know what it is. Apparently it communicated using the
window.bridge global, so eradicate that too.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Appling i18 to reaction tooltips (#16585) caused usernames to be
double-escaped, for instance, if there is a single-quote in a username.
This disables escaping of usernames by i18next, since they're escaped
again later by the rendering code.
Fixes: #16785
Usually we increase the opacity of an interactable icon on hover, but the search-icon at the top of the
right sidebar was missing the behavior.
Co-authored-by: ritik <ritikcn05@gmail.com>
Anders Kaseorg
Suyash Vardhan Mathur
Riken Shah
Wesley Aptekar-Cassels
Aman Agrawal
YashRE42
Signior-X
Steve Howell
aryanshridhar
Tim Abbott
Megamind
Ganesh Pawar