Fixes this KaTeX warning:
Warning: KaTeX doesn't work in quirks mode. Make sure your website has
a suitable doctype.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This is pretty much a verbatim code move,
except that I inlined noop and reset_jquery
in the new file.
Also, in the last test, I no longer reset
the compose state.
We split them in the commit: c50dbf8297
because at that time we thought markdown_katex was gonna
require rewireproxy magic in the later commits.
But we later removed the rewiremock dependency in the
commit: 30c7108955.
So now, we can safely merge `markdown_katex.js` test file
with `markdown.js` test file.
The extracted logic is in linkifier.js.
We have decided to name it linkifier.js instead of realm_linkifier.js
because in future when we will add stream-level linkifiers, we'll
likely want them to be managed by this same file.
I'm not sure that settings UI is particularly worth having puppeteer
tests for, so it's possible we shouldn't bring these back at all. But
in any case, it's worth disabling them as they've been failing for
some time.
This commit solves a rare flake, where the `realm
_linkifier.ts` test was failing because there was no
appropriate wait call for the table
(`#admin_linkifiers_table`) to get updated after editing
the pattern.
The command:
codespell --skip='./locale,*.svg,./docs/translating,postgresql.conf.template.erb,.*fixtures,./yarn.lock,./docs/THIRDPARTY,./tools/setup/emoji/emoji_names.py,./tools/setup/emoji/emoji_map.json,./zerver/management/data/unified_reactions.json' --ignore-words=codespell_ignore_words.txt .
The content of codespell_ignore_words:
```
te
ans
pullrequest
ist
cros
wit
nwe
circularly
ned
ba
ressemble
ser
sur
hel
fpr
alls
nd
ot
```
This tests the basic mechanics of list_cursor
more directly than the activity node tests.
It also sets the stage to eliminate some
tests from activity.js while maintaining
100% coverage on list_cursor.
This is mostly moving tests from activity.js
into user_search.js, but it's not a verbatim
code move.
The new module continues to make sure that
the boundary between activity and user_search
is correct, as most of the testing uses
the configuration of UserSearch from
static/js/activity.js.
It does not use a real buddy_list, though,
which simplifies some tests.
I cleaned up some tests by making sure we
were testing both sides of conditions more
rigorously.
After this change we no longer need the
bloated activity.js tests to maintain full
coverage on static/js/user_search.js.
This commit adds the dropdown in 'Stream settings' section of organization
permissions page to control who can move messages between streams and
also hides the stream-edit UI in message-edit form accordingly.
Fixes#14499.
This commit extracts the logic for testing user_can_invite_others_to_realm
user_can_create_streams, and user_can_subscribe_other_users to a single
function test_policy and this function test_policy is called passing
different policies and validation functions as arguments.
This helps in removing a lot of duplicated code.
This also handles a few other places missed earlier like
narrow headings, beacuse they use the same function.
We already rerender the PM list for events, so there's no
need to do anything special when someone is muted/unmuted.
`people.get_full_names` is now only used in the settings pages
while creating ListWidgets etc, so we add a new test for
it to ensure coverage.
Long ago, we changed Zulip to inspect server-provided topic history in
our compose and search typeahead modules, but did not trigger a query
to the server to fetch data.
This could result in confusing experiences where someone thought that
a topic doesn't exist that just isn't present in recent history.
Once we merge this, we may want to adjust the messaging in typeahead
to advertise that the first option will create a new topic, since this
change may make it feel more like creating topics is a heavyweight
operation.
Fixes#9857.
Previously, the hook to save drafts when closing the compose box was a
focusout on #compose-textarea. This mostly worked, and was essentially
invisible to users (because the animation to notify you about saved
drafts was in the close_compose_ui widget that is hidden), but you'd
end up seeing the tooltip appear (in the wrong place) if you closed
the compose box immediately after sending a message with Tab+Enter.
The correct fix is for the drafts hook to be just before we start
clearing compose box state, inside hide_box.
This was difficult to catch in a development environment, since one
doesn't use that flow with "Enter sends" enabled.
We were apparently not using the ListWidget API for replacing the
content of a widget without removing the whole thing from the DOM and
replacing it.
Unless ListWidget has unexpected bugs, this should have the exact same
result as the previous logic, with much a nicer user experience.
We use styling same as that of the number shown for overflow
(e.g "+3") which has a gray background.
To keep these avatars up-to-date, we need to rerender the
recent topics view after receiving a `muted_users` event.
Also update the user documentation to mention this detail.
We deliberately avoid mentioning "recent topics" because
this applies to mobile too.
This seems more consistent with what users would expect; Recent topics
may be a better default view in general, but if a user has picked
another default view, we should use that where the default view is
desired.
The default label for empty narrows depends on whether it's a
stream/topic narrow or a PMs narrow.
We leave some default text in compose.hbs for reply label
because it take some time for the js to display the
correct label.
The browser seems to autofill the `Name` field of the add-playground
form. Most likely this behavior is a result of value of the `name`
input field being `name`, causing the browser do to something weird
here. This name is now changed to `playground_name`.
Share code between `safe_full_names` and `get_display_full_names`
functions, and rename `safe_full_names` to `get_full_names_for_poll`,
because that was the only place where this was used earlier.
This also has the nice side effect of showing "Muted user" instead
of the muted username in poll results.
The reason for this flake is it missed clicking on the Set
All button (`.subs_set_all_users`) because it calculated
its position before/during it starts scrolling.
There are two scrolling events caused by typing `ot`,
* First is due to internal focus call before typing
which scrolled down the page to bring input in the view.
* Second is after it typed `ot` the user list is updated to
one value, which caused the modal height to decrease rapidly.
Note: It theory, there is three scrolling event,
First is of course internal focus then, after it typed `o`
the list is updated to two values and one is after `t` the
list is updated to a single value.
But as puppeteer is very quick it directly jumped to the
scrolling event after it typed `ot`.
For a more detailed explanation read,
https://chat.zulip.org/#narrow/stream/43-automated-testing/topic/master.20failing/near/1173996.
This commit just temporarily fixes this flake, it's not the
best approach to use time-based delays as they can't be
robust (e.g If the machine is super slow then time-based
delays can fail.).
We don't want to rely on browser hash to check if RT is visible
because soon we want to display default_view without any hash
and RT may or may not be visible in that hash.
Active stream's hash look like this - `#streams/1/announce`
Since the stream_id is present where typically hash section
is for all other hashes, get_current_hash_section should return
the same result.
A modal is added to edit the realm linkifier which
supports ui_report error.
Puppeteer tests to verify linkifier update and an
invalid test to verify that linkifier error messages
are reported on the modal are added as well.
Previously, we used to hide 1:1 PMs with muted users everywhere
in the UI. This commit makes it so that such messages will now be
visible in `pm-with/<muted_user>` narrows, meaning these will not
be excluded from message lists, but will still be hidden under
the "This message was hidden." dialog implemented earlier.
* We hide 1:1 PMs from and to muted users throughout
the UI, because doing so will not lead to loss of
conversational context. The "to" part is also important,
because the last few messages sent to a user before
muting them would probably be asking them to stop
spamming.
* After this change, we will need to do filtering for either
user or topic muting in pretty much all narrows, so we need
to keep the `_all_items` list in MessageListData always
up-to-date.
* A further commit will relax this and make it possible to
view these messages only when in a `pm-with/muted_user`
narrow.
This basically reverts 4bd7ec7c36 and
3a9dfc02e6.
The plan earlier was to have compeletely different codepaths
for user and topic muting, so that we could call seperate
functions in the message list class on receiving the respective
events.
However, this cannot be done, because if we, for example, on
receiving a `muted_users` event, filter `_all_items` based on
just user mutes, and store the result in `_items`, then, that
result may still contain topic-muted messages, which is
undesirable. Hence whenever we filter messages, we must do so
based on both user as well as topic muting.
(The code for the former will be added in further commits.)
So, we will have a single function which will handle updating
the message lists for muting.
These mock objects did not buy any ease in testing, as
evident from the fact that this commit hardly contains
any changes to the tests themselves.
This commit also removes some unnecessary `filter: undefined`,
parameters sent to MessageList constructor.
Add a function which is called before every render to
get the number of items it can render. This can be used by
instance to load custom number of items as per its state.
We allow ListWidget instances to pass functions in opts that can
be called after scrolling to determine when to render.
Also, allow a callback function to be called pre render.
We move compose from being a part of message feed to
being a part of middle column which is a common parent of recent
topics and message feed. This allows us to use a common compose
box for both the views. Fortunately, compose actions were
independent of this change so there weren't any evident
side effects.
Fixes#17543
This corner case was reported in #17320, basically, the
issue was when two or more alert words were used
consecutively with a single space between them, it didn't
detect the even number word as `alert word`.
This button will allow users to avoid a distracting red banner across
their screen, while they wait for their sysadmin to do the upgrade
work.
Fixes: #18359
Since we don't process private messages yet, we don't
need to re-render when we receive a new private message
as it doesn't change any data related to recent_topics.
This will allow us to avoid duplication of array filtering
logic of the form-
`Array.filter((user_id) => !muting.is_user_muted(user_id))` and
`Array.filter((person) => !muting.is_user_muted(person.user_id))`
We want to exclude 1:1 PMs from muted users everywhere
except in `pm-with/<muted_user>`.
This method will help us determine whether we are in such
a narrow.
* We show a "Click here to reveal." hyperlink in the hidden
message dialog for user to click on and read a hidden message.
* The "reveal" action is temporary, in the sense that a revealed
message will again be hidden once the broswer tab reloads or
if the user renarrows.
* When a message is revealed, we make sure to show the sender
of that message, even if it isn't the first message of it's group.
This is because the first message of that message group (which
would have otherwise shown the sender) can still be hidden.
* Reactions and background color after revealing a message are
the same as if the message hadn'e been hidden at all in the
first place.
* We hide the sender and reactions on messages sent by muted
users, and replace the content with a "This message was hidden"
dialog.
* Ideally, we should collapse a series of consequetive
messages sent by muted users into one such dialog, but
that could break the cursor behaviour and `near/<message_id`
links, so we as of now show one dialog per muted message.
* Because we hide the sender, there is a chance of the first
hidden message in a group looking like it was sent by the
author of the message above it. To tackle this, we intentionally
make the hidden message dialog float-left, so that it is clear
that this is a special type of message.
* For context, we still show the timestamp of the message.
* Starring, editing, deleting etc a message still work just like
before.
A further commit will add the ability to reveal a
hidden message.
We also add a check to see if `message_feed_container` is visible,
since it is possible that recent topics could be visible which
was not a possibility when this logic was written.
akshatdalton
Anders Kaseorg
Steve Howell
Tim Abbott
Riken Shah
rht
Vishnu KS
sahil839
Abhijeet Prasad Bodas
Aman Agrawal
Sumanth V Rao