Found by running the tests after
sed -i 's/\.with(/.toBeUsed().with(/g' frontend_tests/node_tests/*.js
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 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.
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.
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.
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.
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`.
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.)
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>
Note that at this point, it's not possible to create moderator users;
this just will make it easier to write tests for logic involving them
as we develop the feature.
‘function’ and ‘=>’ are not equivalent because they bind ‘this’
differently. For these functions, the ‘function’ semantics are
intentional.
This reverts part of commit 1a241cef88
(#17388).
Signed-off-by: Anders Kaseorg <anders@zulip.com>
We now call $.clear_all_elements at the top
of run_test.
We have to exempt two modules from the new regime:
compose
settings_user_groups
Also, if modules do set_global("$", ...) we don't
try to call the non-existent function.
It's possible we'll want to move to something like
this, but we might want to clean up the two
sloppy_$ modules first:
// AVOID THIS:
// const $ = require("zjquery")
run_test("test widget", ({override, $}) => {
override(foo, "bar", ...);
$.create(...);
// do stuff
});
It was checking whether the selector string is itself null, not
whether it selects anything!
Use page.waitForSelector(…, {hidden: true}) instead.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Move clear_zulip_refs into restore, and rewrite it without lodash. We
no longer need the requires array, and zrequire is now nothing more
than a wrapper around require.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
We weren't exercising this method in any
meaningful way during the tests, and when
do add coverage, we probably want to just
test it directly.
We also kill off stub_selector(), which was
never well-documented.
Callers can either explicitly pass in children,
stub out $(...)[0] as needed, or just
circumvent jQuery complications with override.
Note the reactions test was broken before,
since $(...)[0] was always returning the same
stub.
Like using $('input') is too broad a selector and shouldn't
be used in the codebase. With this error messages, contributors
can easily understand that now.
We no longer export make_zjquery().
We now instead have a singleton zjquery instance
that we attach to global.$ in index.js.
We call $.clear_all_elements() before each module.
(We will soon get even more aggressive about doing
it in run_test.)
Test functions can still override $ with set_global.
A good example of this is copy_and_paste using the
real jquery module.
We no longer exempt $ as a global variable, so
test modules that use the zjquery $ need to do:
const $ = require("../zjsunit/zjquery");
The "silent" option was kind of evil, as it had
$(...).find(...) passing back "self" instead of a stub.
Now we just use $(...).set_find_results(...) or
override(...) to simulate/bypass drawing code.
(It turns out hash_util didn't even need this option.)
The tooltips for the left panel of stream settings
have been broken since November 2018 due to my
commit 8f915da2ca.
The code prior to 2018 was restoring tooltips
right inside the loop where we were detaching
the row from the DOM to put it back into the
DOM at another place. And then I tried to
just add them in bulk, forgetting that I was
in the middle of all the DOM manipulation (and
hence my selector for the loop was a noop).
Also, I don't think we've ever had them for live
events that add streams. (I fixed that too.)
It's not clear to me that this code is actually
necessary, as we get hover help without
calling $(...).tooltip(...) properly.
This is probably why we didn't notice any
breakage when we merged my 2018 commit.
We generally want to avoid clicking on DOM elements
that may not actually be visible due to the prior
operation. Instead, we can just find the visible
element after each step.
I also introduce a couple helper functions to
de-clutter the click/unclick/click steps, and I do
a couple extra clicks for good measure.
You can verify that the test will fail if you
add an early return to update_check_button_for_sub.
We just want to reset the scrollbar here, which
we still do via ui.reset_scrollbar.
You don't want to preserve scroll position if
you are filtering or re-sorting.
We have long had this annoying two-pass way of building the
DOM that I am trying to eliminate.
The function names that I introduce here describe the current
situation more accurately.
In passing I make it so that we only throttle redraws when
users are actually typing. Using a throttled redraw when
you click on the sort icons is at best unnecessary, and it
may actually aggravate double clicks.
This splits the one big `run_test` block into
add/edit/delete parts, for better clarity.
This also removes the `with_field` calls and
uses the override style instead, which is
preferred because it makes sure the stubbed
function is actually called.
This commit replaces `with_field` calls to
use the override style instead.
`override` is preferred since it makes sure
the stubbed function is actually called,
while `with_field` doesn't, which makes it
hard to spot dead code.
This commit replaces all `with_stub` calls and
explicitly calls `make_stub` instead.
The `with_stub` helper does not add much clarity
hence we now use scoped stub objects instead.
This de-indents some blocks where scoping isn't
required, for example when there is a single
stub object inside a `run_test` function.
With this change, we also need to explicitly
assert `num_calls`.
We can relax this restriction in the future, but
basically every time it came up for me, the test
code was just disorganized, or it had an easy
workaround.
These are still kind of a mess.
The old code combined the worst of both worlds:
- we had one monolithic test
- we called the events multiple times,
verifying a different stub each time
Now I make the tests more granular.
We could actually re-combine the tests, but
in a nicer way, so that we just set
up multiple stubs and verify that all stubs
get correctly invoked.
There is also some code cleanup here--in dispatch_subs,
we don't stub stream_data, so it's easier to write
deeper tests that actually validate the data changes.
This prevents a bug where we interpret "2something"
as a modern slug instead of a legacy stream name.
The bug was probably somewhat unlikely to happen in
practice, since it only manifests if 2 is an actual
stream_id.
We still need to write to these globals with set_global because the
code being tested reads from them, but the tests themselves should
never need to read from them.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit makes it so that MessageListData
methods always attempt to filter muted messages.
We later, in a new function
(`messages_filtered_for_topic_mutes`)
check if `excludes_muted_topics` is true or not,
and skip the filtering work if it isn't.
This new function consistently returns a new list.
This refactor will later allow us to write clean
and concise code as part of mute users.
This commit also refactors the muting tests
for MessageListData, which were earlier
spread across two `run_test` functions.
These tests should remain organized,
since similar tests will be added as part of
user mutes in future commits.
Previously, the `muting_enabled` property of
MessageListData class was used to indicate whether
some messages in the message list need to be
filtered due to topic muting, depending on the
narrow. For example, we exclude messages belonging
to muted topics from stream narrows, but not from
search narrows.
The name `muting_enabled` is a bit confusing, and hence is
changed to `excludes_muted_topics`.
It is also important that the name be specific, since
a similar new property will be added for user mutes
in future commits.
I have a local branch with a hacked up version of
zjquery that lets you basically detect when zjquery
stubs are never actually invoked by real code.
There are some nuances to that kind of audit, so
I haven't pushed the auditing code, but these
are low hanging fruit.
I now just use inline the code to create stubs
for the line items in the markdown_content
container, and I don't add methods to the
zjquery stubs.
And then I use the new "children" feature in
zjquery's `$.create(sel, opts)` to set up
$(".markdown_content"), which means I don't
have to stub `each` any more.
It's actually pretty rare in our codebase to
call methods like `$(...).map` or `$(...).each`,
but we now support them better in zjquery.
You can pass a list of child elements now to
`$.create(...)`.
Fixes the sorting button labels in stream settings, which were
regressed by commit f8fbae4d8e (because
the HTML was not marked as being HTML).
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This is a minor refactor in the muting test in
`message_list`.
The `unmuted_messages` function filters out messages only
considering topic mutes, and not stream mutes.
The test previously made it look like we were testing
stream muting, by stubbing the `is_topic_muted` on the
basis of `stream_id`.
This also replaces the stub and uses real data instead.
This is a prep commit, which renames some variables
and functions involved in topic muting to include
the word "topic" in them.
This is done to have clarity when similar code
will be added as a part of the mute-user in
future commits.
Replaced methods/functions of moment.js with date-fns library.
The motive was to replace it with a smaller frontend timezone library.
Date-fns ~ 11.51 kb
moment.js ~ 217.87 kb
Some of the format strings change because date-fns encodes them
differently from how moment did.
Fixes#16373.
It's not clear to me why this code was necessary,
and I assume it was either originally written
with a bit of misunderstanding of how zjquery
works or it became unnecessary with some refactoring
of the "real" code.
We move some of the data setup to the top of the file.
We also remove some get_sub() calls that aren't really
necessary now that peer_data and stream_data are more
independent.
The maybe_clear_subscribers() function was an artifact of
when we used to attach subscribers to the "sub" records in
stream_data.js. I think it was basically a refactoring
shim, and due to some other recent cleanup, it was only
used in test code.
We also change how we validate stream ids.
Going forward, peer_data just looks up stream_ids with the
normal stream_data API when it's trying to warn about
rogue stream_ids coming in. As I alluded to in an earlier
commit, some of the warning code here might be overly
defensive, but at least it's pretty self-contained.
Now when we want to measure how long a block
of code takes to execute, we just wrap it with
`blueslip.measure_time`, instead of the awkward
idiom from my original commit of getting a callback
function.
My rationale for the original scheme was that I
wanted to minimize diffs and avoid changing
`const` to `let` in a few cases, but I believe
now that the function wrapper is nicer.
In a few cases I just removed the blueslip timing
code, since I was able to confirm on czo that
the times were pretty minimal.
We now use the same code in all places to
get the bucket of user_ids that correspond
to a stream, and we consistently treat
a stream as having zero subscribers, not
an undefined number of subscribers, in
the hypothetical case of us asking about
a stream that we're not tracking.
The behavior for untracked streams has
always been problematic, since if a
stream is untracked, all bets are off.
So now if we don't "track" the stream,
the subscriber count is zero. None of
our callers distinguish between undefined
and zero.
And we just consider the stream to be subscribed
by a user when add_subscriber is called,
even if we haven't been told by stream_data
to track the stream. (We also stop
returning true/false from add_subscriber,
since only test code was looking at it.)
We protect against the most likely source
of internal-to-the-frontend bugs by adding
the assert_number() call.
We generally have to assume that the server
is sending us sensible data at page load
time, or all bets are off.
And we have good protections in place
for unknown ids in our dispatch code
for peer_add/peer_remove events.
We also streamline some of the error handling code
by doing everything up front. This will prevent
scenarios where a single bad stream_id/user_id causes a
bunch of the same warnings in an inner loop.
This removes a bit of complexity. If a piece of
settings code needs to render a stream with
subscribers, it just asks for it.
We no longer have the brittle, action-at-a-distance
mechanism of mutating the subscriber count on to
the stream_data version of a sub.
Stream subs are pretty small, so making copies of
them is cheap, and the blueslip timings from the
previous commit can help confirm that.
There is some discussion of putting `subscriber_count`
on the Stream model, which may eventually get us
away from tracking it in `peer_data.js`, but we will
cross that bridge when we get there. See
https://github.com/zulip/zulip/issues/17101 for
more details.
The weekly stream traffic is a better tiebreaker
for stream typeaheads than subscriber count, as
it's more directly a measure of a stream's current
relevance.
Normally stream traffic and subscriber counts are
closely correlated, but a good example for me is
the #twitter feed on czo, which only has 80 subscribers,
but which gets more traffic than our #integrations
stream (with 16k subscribers). I would rather
see #twitter win the tiebreaker (if it even got
to the tiebreaker).
The main motivation behind this fix, though, is
to break our dependency on peer_data, which has
some upcoming changes that will introduce some
performance tradeoffs, and I want one less place
to audit.
Also, it will be easier long term to share this
code with mobile if we don't require mobile
to pull in our peer_data dependency. (The webapp
has different forces than mobile that dicate
our data structures.)
Anders Kaseorg
sahil839
Steve Howell
Wesley Aptekar-Cassels
Aman Agrawal
YashRE42
Abhijeet Prasad Bodas
aryanshridhar
Ganesh Pawar