Change the logic for rendering PM threads in PM section to
be in the same as that of topics view --
In default view, only recent 5 PM threads would be shown
and append the active conversation as the 6th one at last
if not present in those 5.
In PM section with unreads, a maximum of 8 conversations
would be shown and rest of them would be hidden behind
the 'more conversations' li-item, clicking on which takes
to the zoomedIn view of PM section where all the present
PM threads would be visible.
Co-authored-by: Tim Abbott <tabbott@zulip.com>
The old link here broke once we introduced separate APKs per ABI,
in zulip/zulip-mobile#5296.
We could make a direct link to app-armeabi-v7a-release.apk , the one
that's compatible with almost all devices. But perhaps better is to
just go back to linking to the release page, where the user can
choose the best APK for their device. (If they're in the habit of
downloading APKs manually to install on their device, then probably
that means they're going to be used to choosing the right one.)
User report and discussion:
https://chat.zulip.org/#narrow/stream/48-mobile/topic/Direct.20apk.20download.20link.20is.20404/near/1358758
This makes parse() more re-entrant.
This also drives out a change to the linkifiers
test, where I no longer couple the linkifiers
logic to markdown concerns. I probably should have
done this in an earlier commit, but better late
than never. I didn't bother to split out a commit
for the test stuff, since it's just tests and
the commit is still fairly atomic in nature.
It has always been pretty arbitrary what we did inside
of setup() vs. parse(), and we want to avoid unpredictable
results from other platforms neglecting to call setup().
On my machine you can parse a simple message in about
25 microseconds, based on a trial of a million messages
with the content of "**bold**". Whatever portion of
that time is related to setup-related things like
compiling regexes should be negligible from the user's
perspective, since we never run parse() in a loop.
Our sub (i.e stream) and user_group objects have a bunch
of fields that aren't relevant to markdown parsing, so
we create narrow types that make it easier for us to
share code with mobile in the future.
I considered working purely in id space, but the problem
there is that user-entered stream names and user group
names need to be canonicalized.
The abstract_map() helper clarifies that our code
doesn't need a concrete Map object from JS. This
change is possibly premature until we get a little
bit closer on integrating with mobile, since it
solves kinda the same problem that we might handle
more elegantly with TypeScript or Flow.
OTOH I find it to be pretty non-intrusive for the
webapp.
These are the low-hanging-fruit places where we
can avoid using the helpers global.
The long term goal here is to make the markdown
code truly re-entrant, but some challenges still
remain.
Before this change, we would use **some** options relating
to parsing messages, but not all of them. The reason for
this was completely unintentional.
It's mostly a moot point, since the server sends back pretty
generic messages when you do something like invoke the
"/dark" command, and the message would parse the same way
whether or not the parser was looking for things like user
mentions or stream links.
In order to make this code predictable, I had to decide
whether we do a completely vanilla parse or a full message
parse. My decision now is mostly tactical. It's a trivial
one-line change to just use all the options for message
parsing, whereas it requires a major overhaul to allow a
vanilla parse.
I also predict that we will eventually want to parse these
server responses as if they were messages. I doubt the
zcommand responses would ever take advantage of it, but I
could imagine things like nag messages wanting to use user
mentions.
Even if my predictions are wrong, my decisions here are
pretty easy to reverse once we learn more.
For the particular case of zcommands, it is puzzling to me
why the server doesn't just send back HTML, but I don't want
to open that can of worms yet, as that would technically be
an API change.
For now I am happy with the one-line fix.
The zcommand code was calling directly into the "marked"
library, which was extremely misleading, since you don't
get a vanilla parse of the markdown due to the fact
that markdown.js calls setOptions at initialize time.
This commit shifts the responsibility to markdown.js
as well as adding a bit of test coverage, but it is
otherwise just a pure code-move refactoring.
The next commit will tweak things further.
This is mostly done for correctness reasons--it is
easiest from a logical standpoint to set the realm
emojis at the end of the function, since we do not want
them to be overwritten by normal emojis. The code
worked before this change, but it involved a clunky
check to map.has().
There is also probably a very minor performance
improvement insofar as N (the number of normal
emojis) is typically greater than R (the number
of realm emojis), and we eliminate N calls to
map.has in return for R calls to map.set. Even
if R is quite large, the readability advantages
probably far outweigh any performance considerations,
since we are using native map calls.
Thanks to Austin Riba for this suggestion.
The mobile app was never able to use the shared
version of emoji.js, because, among other problems
with our code organization, the emoji.js module
is strongly based on a mutate-the-data paradigm
that doesn't play nice with React. The way
that we mutate data and violate encapsuation
here is something that we would mostly want to fix
without even trying to shared code with mobile, so
subsequent commits will try to extract some pure
functions into a shared module.
The backend validates that URL inputs are RFC valid URLs (with no
specific length limit), but the frontend appears to have a maximum
length of 50 specified, likely because of a copy-paste error.
Increase the HTML maxlength for this input to 2048, which is a length
supported for URLs by all major browsers.
Fixes#21633
The feature deactivates the bot user; Zulip has no "delete bot"
feature. So fix the label to match what it does.
We also change the icon to match the one we use for deactivating users
in the "Manage users" UI.
Fixes#21619
We need to adjust height of recent topics along with the app
otherwise the container becomes separately scrollable due to
it overflowing the app height.
This is definitely better than having linkifiers
reach directly into marked.js, but there is
probably further improvement we can do here
to clean up how these regexes get set.
This introduces a circular dependency between
markdown.js and linkifiers.js, but we will
soon break it in the other direction.
Note we now avoid linkifier checks for the case that a message
contains more obvious backend-only syntax such as attachments.
The next commit will eliminate the ugly early-return.
This gets us closer to having an API that can
be used my mobile.
The parse() function becomes a subset of
apply_markdown() that is no longer coupled
to the shape of a webapp object, and it can
be supplied with a new helper_config for each
invocation. Mobile will likely call this directly.
The setup() function becomes a subset of
initialize() that allows you to set up the
parser **before** having to build any kind of
message-specific helpers. Mobile will likely
call this directly.
The webapp continues to call these functions,
which are now thin wrappers:
* apply_markdown (wrapping parse)
* initialize (wrapping setup)
Note we still have several other problems to
solve before mobile can use this code, but we
introduce this now so that we can get a head
start on prototyping and unit testing.
Also, this commit does not address the fact
that contains_backend_only_syntax() is still
bound to the webapp config.
We were showing the push notifications tooltip in user default
settings section even if the push notifications were configured
on the server.
The bug was because the setting value was undefined in the template
used for user default settings section, so this commit fixes the bug
by correctly passing the setting value to relevant template file.
Fixes#21602.
We use `fadeOut` effect to hide the scroll to bottom button more
widely. We already use `fadeIn` effect to display the button
every time.
We deliberately don't use the `fadeOut` effect when doing
`make_compose_box_full_size` to avoid any button overlap with
compose for a short time.
The implementation closely follows `handle_deactivation()`.
Using the same existing reactivate confirmation modal.
Also, this commit will also lead to open confirmation modal
to reactivate bots in settings > bots, and currently there is no
existing confirmation modal for deactivating bots.
This commit is a follow-up of #21436.
We previously added support for showing the status_emoji to the PM
list, but we only supported individual PMs and not group PMs, this is
prep commit towards supporting group PMs.
We previously added support for showing the status_emoji to the PM
list, but we only supported individual PMs and not group PMs, this is
prep commit towards supporting group PMs.
Previously, we were experiencing a regression in the positioning of
the play icon for youtube previews, as such, this commit uses a
previously created `handle_video_preview_mouseenter` to ensure the
positioning is always correct.
This is an ugly way of doing things, because this could be handled
directly through CSS flexbox, however, it is an acceptable temporary
fix.
This commit extracts the logic used to ensure that the play icon is
correctly positioned over the video preview for embedded videos, with
the intention that we can use this to fix a regression in the play
icon positioning for youtube video previews.
We render a login button for images that failed to load for
spectators. The image failed to load most likely due to being
rate limited by the server.
Fixes#19840
f0c680e9c0 introduced a call to
message_helper.process_new_message without first calling
message_store.set_message_flags on the message.
This resulted in it being possible as a race, when loading the Zulip
app to a stream/topic/near narrow, for a message to have the
`historical` flag be undefined due to not being initialized.
That invalid state, in turn, resulted in the message_list_view code
path for rendering the message feed incorrectly displaying additional
recipient bars around the message.
We could fix this by just calling message_store.set_message_booleans
in this code path. However, this bug exposes the fact that it's very
fragile to expect every code path to call that function before
message_helper.process_new_message.
So we instead fix this by moving message_store.set_message_booleans
inside message_helper.process_new_message.
One call point of concern in this change is maybe_add_narrow_messages,
which could theoretically reintroduce the double set_message_flags
bugs detailed in 9729b1a4ad. However, I
believe that to not be possible, because that call should never
experience a cache miss.
The other existing code paths were already calling
set_message_booleans immediately before
message_helper.process_new_message. They are still changing here, in
that we now do a cache lookup before attempting to call
set_message_booleans. Because the message booleans do not affect the
cache lookup and the local message object is discarded in case of a
cache hit, this should have no functional impact.
Because I found the existing comment at that call site confusing and
almost proposed removing it as pointless, extend the block comment to
explicitly mention that the purpose is refreshing our object.
Fixes#21503.
This eliminates an annoying bundle of complexity that caused the
frontend markdown processor's interface with the rest of Zulip's new
message processing code paths being more similar to that of a new
message from the server.
It also cuts down on code duplication.
The previous message.unread block in insert_local_message was
non-functional. markdown.apply_markdown is overriding what that set by
calling message_store.init_booleans, which happens to set the same
value for the `unread` flag, and then setting individual message
booleans as it finds elements like mentions during rendering.
Improve this situation partially by deleting the message_unread block,
and adding conversion logic to translate what the markdown processor
is doing into message flags.
Then, we can call message_store.set_message_flags just like we do when
processing new messages arriving via the API. This will be helpful
shortly, when we deduplicate the calls to
message_store.set_message_flags.
As noted in the lengthy TODO, this exposes the fact that we should
really rework how the frontend markdown processor returns the
mentioned state to its caller.
There is config_data for the embedded bots only for giphy and
followup bots, so we send "config_data" field to API only for
those bots and not others. Send config_data field as {} to
the API for other bots raised InternalError earlier.
aparna-bhatt
jai2201
Tim Abbott
Aman Agrawal
Greg Price
Steve Howell
Archisman Das
NerdyLucifer
Sahil Batra
yogesh sirsat
YashRE42