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>
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.
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.
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.
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
Anders Kaseorg
Aman Agrawal
YashRE42
Steve Howell
Wesley Aptekar-Cassels