This replaces the `startsWith` string prototype method with `indexOf`
because no versions of Internet Explorer support this feature, and
it really is not difficult to just use `indexOf` instead and check
whether the starting index of the full string is 0.
This keeps hotspot icons positioned at the front of the message
viewport but behind sidebars (i.e. the left sidebar has a z-index
of 103). Hotspots associated with elements outside of the message
viewport should be individually adjusted at the bottom of hotspots.css.
compute_placement utilizes the dimensions of the viewport, viewport location of
an element, and dimensions of an element to determine if a popover will fit
horizontally and/or veritically given its orientation. The default placement
is now viewport_center, which displays the popover, without an arrow, in the
fixed center of the viewport.
This should be particularly useful for hotspots on mobile or large popovers
that contain a lot of content. The property hotspot.location.popover can be
optionally set to fix the orientation of a popover (most likely to
VIEWPORT_CENTER).
This fixes the lightbox zoom issues that occurred on some browsers
due to the units of `deltaY` being in lines rathern than pixels,
making it incredibly slow to zoom.
This change simplifies how we mark all messages as read. It also
speeds up the backend by taking advantage of our partial index
for unread messages. We also use a new statsd indicator.
By the time we render messages, we will have set message.unread,
so we don't need to calculate it from flags.
We add a line to the local-echo path to make this explicit
in that code.
When we learn about updated message, a bunch of flag/boolean
fields concern us:
starred
mentioned
alerted
is_me_message
We now set booleans consistently with how we set new incoming
messages.
This code adds 'read' to message.flags and sets message.unread
to false.
It's not clear that the boolean message.unread is used in any
meaningful way, but we set it to false to avoid confusion. The
bankruptcy code was not doing this before.
Another quirk that existed before was that you could get two
'read' flags in a message when you declared bankruptcy. It's
also plausible that this could happen if you marked a message
as read via two different ways. It probably did not cause
user-facing bugs, but it would be confusing for troubleshooting.
Fixes#5032.
The new method borrows some code from the event loop
and unread_ops.mark_messages_as_read, and it is now
flexible about message_ids being marked as unread
even when there is no corresponding message in the
message store. For that scenario we still want to
update our data structures, which wasn't happening
before this change. (Generally, this was a non-issue
up until now, but it will become a bigger issue when
we start loading unread message ids from the server.)
This function allows us to see whether unread.js thinks a message
id is unread (as opposed to looking at the message itself). This
method is useful when we get notifications from the server that a
message has been read. In the future, we may not actually have
a local copy of an unread message, but we'll still know that it is
unread based on page_params. We'll want to update the data in that
case.
Going forward, we'll want to deprecate message.flags for most use
cases and just use the unread.js data structures to track unread
messages.
The prior implementation was needlessly complex. Both del() and
add() are cheap and idempotent.
With this change we no longer bother to delete a topic from a
dictionary when its last message is mark as read, since it doesn't
really help performance. We add a line to the tests to maintain
100% line coverage.
In a subsequent commit, we may have unread counts for
deactivated users. There is no reason to fail hard on these
scenarios; if there is no list item for a user_ids_string,
updating the unread count should be a noop.
It's not always clear whether user_ids are strings or integers, so
we explicitly convert them to integers for sorting when creating
keys for PMs.
To keep the tests passing, this commit removes some unneeded
defensive code in message_store.js that only applies to contrived
test input.
This is a redesign of the features landing page from the current style
that includes the new sections in a grid format as well as some new
high-quality sections.
Main reasons:
* Shouldn't be hardcoding welcome bot
* compose_actions.cancel() was not closing the compose box, for some
reason. It was working fine before commit a few up from here ("tutorial:
Remove rest of tutorial."), but I think possibly due to the fact that one
had to click a button to exit the tutorial (that could be wrong, it was
hard to pinpoint why it was working before that commit and not after.)
This code should be going away anyway once #5816 is resolved.
* .screen is no longer being changed by other parts of the tutorial
* first_run_message we don't need, since we're guaranteed to have a message.
* Changing to #home and narrow.deactivate are not needed since we're
immediately narrowing to PM with welcome-bot.
These have been replaced by the initial stream messages and PMs.
The two pieces of information that exist here and not in the initial stream
messages are a link to /integrations, and a demonstration of image
uploading/pasting.
I think the current information presented is already a lot, though probably
it would be good to work in integrations somehow. Image pasting should just
be done in a separate Zulip that demonstrates the many different formatting
features.
The overflow was set to "hidden". I'm unsure of how this was even
working on desktop, but the #user-presences div certainly would
not scroll on mobile. This enables mobile scrolling.
When a user clicks on the `.player-container` node and the click
target is actually that (and not the YT video iFrame within), then
hide the lightbox – they likely mean to exit out of the lightbox.
This commit extract send_messages.js to clean up code related
to the following things:
* sending data to /json/report_send_time
* restarting the event loop if events don't arrive on time
The code related to /json/report changes the following ways:
* We track the state almost completely in the new
send_messages.js module, with other modules just
making one-line calls.
* We no longer send "displayed" times to the servers, since
we were kind of lying about them anyway.
* We now explicitly track the state of each single sent
message in its own object.
* We now look up data related to the messages by local_id,
instead of message_id. The problem with message_id was
that is was mutable. Now we use local_id, and we extend
the local_id concept to messages that don't get rendered
client side. We no longer need to react to the
'message_id_changed' event to change our hash key.
* The code used to live in many places:
* various big chunks were scattered among compose.js,
and those were all moved or reduced to one-line
calls into the new module
* echo.js continues to make basically one-line calls,
but it no longer calls compose.report_as_received(),
nor does it set the "start" time.
* message_util.js used to report received events, but
only when they finally got drawn in the home view;
this code is gone now
The code related to restarting the event loop if events don't arrive
changes as follows:
* The timer now gets set up from within
send_messages.message_state.report_server_ack,
where we can easily inspect the current state of the
possibly-still-in-flight message.
* The code to confirm that an event was received happens now
in server_events.js, rather than later, so that we don't
falsely blame the event loop for a downstream bug. (Plus
it's easier to just do it one place.)
This change removes a fair amount of code from our node tests. Some
of the removal is good stuff related to us completing killing off
unnecessary code. Other removals are more expediency-driven, and
we should make another sweep at ramping up our coverage on compose.js,
with possibly a little more mocking of the new `send_messages` code
layer, since it's now abstracted better.
There is also some minor cleanup to echo.resend_message() in this
commit.
See #5968 for a detailed breakdown of the changes.
Prior to this we were also performing highlighting inside HTML tags
which was wrong and causing weird behavior. Like, for example, if
someone added `emoji` as an alert word then any message containing
both emoji and alert word was rendered with a jumbo emoji.
Fixes: #4357.
This makes the canvas zoom and pan feature cross-browser compatible in
a few ways:
1. Replace deprecated `mousewheel` event in favor of the similar and
cross-browser event `wheel`.
2. Create approximate substitute for `e.movementX` and `e.movementY`
values that are missing in Safari.
This completes the major endpoint migrations to eliminate legacy API
endpoints from Zulip.
There's a few other things that will happen naturally, so I believe
this fixes#611.
A realm filter should match only after the start of a line, whitespace
or opening delimiters. But markdown was not configured to respect those
rules which was causing some weird rendering behavior. This commit fixes
the regex used for matching realm filters. On the backend we are using
regex with negative lookbehind to perform matches but since javascript
regex don't support lookbehind we are using a workaround on the frontend
using `contains_backend_only_syntax()` function which detects if a realm
filter can be rendered correctly by backend only and if so it stops the
message from getting echoed locally.
Fixes: #5154.
This class is mostly a thin layer over the dictionary, but it
consolidates all the logic to create lookup keys, which have
to follow the convention of being comma-separated, numerically
sorted user_ids.
interface_type select menu will be used to choose the interface
for outgoing webhooks. It will be displayed only when the selected
bot type is OUTGOING WEBHOOK type. The default value is GENERIC
interface type (1).