The ES6 backticks in /static/js/portico/landing-page.js were causing
the server to trip up. This was fixed by switching from JS string
interpolation to string concatenation (ES5).
Modified timerender.js absolute_time() to include the year
in the returned string when the supplied timestamp is in
an older year. This included adding an optional second
argument to specify the current date to facilitate unit
tests.
Fixes#5737.
This commit specifically addresses the issue when in preview mode,
while "enter sends" is enabled. Previously the messages were just
sent, now they must pass validation.
Fixes#5574.
This allows us to reliably parse the error in code, rather than
attempt to parse the error text. Because the error text gets
translated into the user's language, this error-handling path
wasn't functioning at all for users using Zulip in any of the
seven non-English languages for which we had a translation for
this string.
Together with 709c3b50f which fixed a similar issue in a
different error-handling path, this fixes#5598.
It's hinted in the registation process, and as long as one person in the
realm does it, everyone else will know. The tooltip also draws too much
visual attention.
This fixes the original issue that #5598 was the root cause of; when
the user returns to a Zulip browser tab after they've been idle past
the timeout (10 min, per IDLE_EVENT_QUEUE_TIMEOUT_SECS), we now
correctly reload the page even if they're using Zulip in German or
another non-English language where we have a translation for the
relevant error message.
This function no longer sets properties to false, so the supported
way of doing this is to instead use prop(foo, false). Some tests
had to be fixed to accommodate this.
In case the user was not allowed to upload an emoji, we were displaying
two different but sematically same tips. This commit merges them and
also updates `update_custom_emoji_ui()` function in settings_emoji.js
to live update tooltip.
Our code to edit messages that were echoed locally but failed
by the server was broken. We just disable it for now.
We have opened #5841 to try to restore this functionality.
Our logic for editing failed messages is broken in various ways,
so we are removing the codepath for editing for now. We will
try to restore these features as part of #5841.
Because of local echo, message ids can change in message rows.
Having reactions use markup to indicate their message id just
creates more moving parts, since we would need to handle
message_id_changed events.
Now our handlers just call row.get_message_id() as needed.
We no longer do the message_store piece of reifying ids
via a trigger. We now make an explicit call to an
ordinary function.
This has several benefits:
- no more initialize() function
- no more scary comments about garbage collection
- the function has a real name now
- the function is less indented
- we can easily see when the message_store step happens
- simpler node tests
- simpler tracebacks (no jQuery cruft)
While demoing Zulip at PyCon, I learned that it is hard to
distinguish topics from streams in our left sidebar.
Indenting them by a few pixel seems to make it more clear
that topics belong to a stream.
We used to generate a file at this path in the static build,
but since 3f5d0e69f the corresponding output goes into
static/webpack-bundles instead. Clear the now-dead path
from our gitignore files.
Also add a comment explaining an important non-obvious wrinkle in how
paths in the format are interpreted, and adjust some paths to a
consistent style.
If you use the escape key to close a message edit, we need
to blur out the text fields. Otherwise, hotkeys.js thinks
we are still editing the text. This bug would disable the
use of things like arrow keys until the user subsequently
focused another field.
We probably eventually want hotkeys.js to be smarter about
ignoring hidden fields that still have the focus, but there's
also no reason not to blur the fields here, and this is a more
local, less risky fix.
Currently when hovering over the external link icon generated when a topic contains a
realm filter, an underline appears. This commit removes that underline.
This commit renames possibly_notify_new_messages_outside_viewport()
to the more concise name notify_local_mixes().
We really only need to call this function in one place, so we
have the caller check the `local_id` condition. We can eventually
upstream this code even further so that it's completely
obvious that it's only ever called from the local-echo codepath.
We were calling maybe_add_narrowed_messages() in a place
where local_id is guaranteed to be undefined, since
we always set local_id to undefined when
can_apply_locally() fails.
In turn maybe_add_narrowed_messages() was calling
possibly_notify_new_messages_outside_viewport(), which
requires a local_id to do anything meaningful.
This removes all the associated dead code--passing in
a parameter that we know always was undefined and
calling a function that we know always would no-op.
Not only does this simplify the code a bit, but it avoids
us stepping on the toes of the alternative code path that
deals with non-locally-echoed messages.
This commit early-exits before our loop when local_id is none,
and it tries to more clearly indicate that the callers will
generally be just calling this with messages sent on the
local-echo path.
We now make it so that get_next_local_id() only returns up
to 5 local ids relative to any given max id.
For example, if your pointer is at message 999, we'd give out
999.01, 999.02, ..., 999.05.
We also avoid giving out the same local id twice. This prevents
a bug where if you had aborted a previously failed locally echoed
message, a subsequent local echo would get into a funny state.
In order to to prevent false alarms on using the same local id
twice, we call get_next_local_id() later in the try_deliver_locally()
function.
We had code that would try to re-render locally echoed messages
that were rendered right before a browser restart. This code
has gotten buggy over time, so we are removing it for now.
We will try to re-solve the problem as part of #5825, but
possibly with a different strategy.
This commit removes all code related to headers because
(1) we don't need the code and (2) it splits #**stream**
as a paragraph, which we don't want. This commit also
fixes the inconsistency when #**stream** is on a new line.
Fixes#4678.
This allow the webbpack dev server to properly reload JavaScript modules
while running in dev without restarting the server. We need to connect
to webpack-dev-server directly because SockJS doesn't support more than
one connection on the same host/port.
We eliminate `.get(0)` calls in buld_stream_list.
The easy case is that we stop building jQuery objects
for the splitters only to pull out the DOM immediately.
The more subtle case is that we also don't do `.get(0)` calls
to get DOM out of our individual list items. By passing
in full jQuery objects to `append()`, we should prevent ourself
from orphaning the old objects, which may in the future have
things like tooltip logic attached to them.
The user mention regex was checking for multiple lines,
so it broke when the user mention was on a new line.
This changes the regex AND adds a couple tests to
test inline markdown regexes.
This either removes aria-hidden=true assignments from buttons with
text, or adds a span to only hide the 'x' symbol rather than the
button for closing buttons.
There is a "user-select: none" (cross-browser) that was put on
the #bottom_whitespace div, but the div doesn't actually have any
content that can be selected, and it also makes it difficult to
deselect selected text because when clicked over it will save the
current selection.
This makes the avatar portion more responsive and efficient on many
screen settings and also fixes some of the design incongruences present
on the page.
This changes the markdown section and sidebar to be the correct
height on mobile along with correcting the broken footer to always
appear below the content.
Fixes: #5798.
This new setting controls whether or not users are allowed to see the
edit history in a Zulip organization. It controls access through 2
key mechanisms:
* For long-ago edited messages, get_messages removes the edit history
content from messages it sends to clients.
* For newly edited messages, clients are responsible for checking the
setting and not saving the edit history data. Since the webapp was
the only client displaying it before this change, this just required
some changes in message_events.js.
Significantly modified by tabbott to fix some logic bugs and add a
test.
I deleted a test case that involved a highlighted stream, but
the query was empty. This produces kind of a weird result with
typeahead_helper.highlight_with_escaping, but this function already
has coverage in node_tests/typeahead_helper.js, so the check here
was essentially redundant anyway. Specifically, the highlighter
wraps every character individually with <strong>, and looks really
messy in html.
Fixes#3496. This was just a simple regex addition to filter
to accept the format `operand:"foo bar"` as a token. Also,
it will now accept an additional space after the separating colon.
I pushed a bunch of commits that attempted to introduce
the concept of `client_message_id` into our server, as
part of cleaning up our codepaths related to messages you
sent (both for the locally echoed case and for the host
case).
When we deployed this, we had some strange failures involving
double-echoed messages and issues advancing the pointer that appeared
related to #5779. We didn't get to the bottom of exactly why the PR
caused havoc, but I decided there was a cleaner approach, anyway.
Add a line of text stating that there are no active or inactive bots.
This is for better understanding of the user, as blank screen that
used to appear in case of no bots being present might seem broken
to some.
Tweaked by tabbott to improve the English.
The old translation copies in localStorage were not being removed
when they were no longer needed, so we can free up the storage
by deleting them.
This was accidentally not merged months ago when originally
implemented, but it was written to fix#4443 and in fact does so.
This change has us tracking messages as soon as we start
sending the message to the server. The next step is to
reconfigure the timeouts a bit to deal with the server not
responding.
We now use a client-side message id to track the state of our
sent messages. This sets up future commits to start tracking
state earlier in the message's life cycle.
It also avoids ugly reify logic where we capture an event to
update our data structure to key on the server's message id
instead of the local id. That eliminates the node test as well.
Another node test gets deleted here, just because it's not
worth the trouble with upcoming refactorings.
This mostly sets the stage for a subsequent commit to start
using client_message_id as the key into sent_messages.
It has the nice side effect of making it more explicit that
certain things should always happen when transmit_message()
succeeds.
This commit does regress our node test coverage a bit.
This commit starts to decouple client_message_id from local_id.
We don't really take advantage of the decoupling in this
commit--in fact, it's a bit of a pain at first. But this should
be a fully working checkpoint commit.
This is mostly straightforward moving of code out of compose.js.
The code that was moved currently supports sending time
reports for sent messages, but we intend to grow out the new
module to track more state about sent messages.
The following function names in this commit are new, but their
code was basically pulled over verbatim:
process_success (was process_send_time)
set_timer_for_restarting_event_loop
clear
initialize
All the code in the new module is covered by previous tests that
had been written for compose.js. This commit only modifies
a few things to keep those tests.
The new module has 100% node coverage, so we updated `enforce_fully_covered`.
We are deprecating local_id/local_message_id on the Python server.
Instead of the server knowing about the client's implementation of
local id, with the message id = 9999.01 scheme, we just send the
server an opaque id to send back to us.
This commit changes the name from local_id -> client_message_id,
but it doesn't change the actual values passed yet.
The goal for client_key in future commits will be to:
* Have it for all messages, not just locally rendered messages
* Not have it overlap with server-side message ids.
The history behind local_id having numbers like 9999.01 is that
they are actually interim message ids and the numerical value is
used for rendering the message list when we do client-side rendering.
Prior to this commit, 7 megabytes of images (through 253 individual requests)
were heavily slowing down the initial load. With this commit, we load only the
logos (60 or so images).
Documentation and images for the individual integration sub-pages is requested
separately using the /integrations/doc/ endpoint, which returns HTML.
Vishnu Ks
Brock Whittaker
digi0ps
David Coleman
hollywoodno
Vaida Plankyte
Greg Price
Cynthia Lin
Sarah
Rishi Gupta
Harshit Bansal
Cory Lynch
Shubham Gupta
Jack Zhang
Steve Howell
Joshua Pan
Pweaver (Paul Weaver)
Tim Abbott
Durga Akhil Mundroy
Sawant Shah
Abhijeet Kaur