When starting a compose, call compose_fade.set_faded_messages,
which will immediately do fade/unfade logic, whereas before
the code path went thru debouncing logic.
(imported from commit 7d0b30435be32a7132dbf05bf064b03b925a2d42)
Move code from compose.update_fade() into
compose_fade.set_focused_recipient(), which makes it
so that we only have to send the msg_type.
(imported from commit c17665d9f34f525bdedcd36d39d3a112fa36a914)
The code in unfade_messages() is O(N) over the number of
messages, but a simple flag allows us to track the fact that
all messages are unfaded, so we can short circuit the O(N)
logic in many cases.
A typical scenario now would be that you start typing a
stream while the topic is still empty. Modulo debouncing,
every keystroke now leads to a call to unfade_messages(),
but this change only does real work the first time.
(imported from commit da07cf408bbdbf5b381ff3ec33a5e05e34eef5b5)
The compose_fade has three public exports:
set_focused_recipient
unfade_messages
update_faded_messages
All code was pulled directly from compose.js, except for the
one-line setter of set_focused_recipient. The focused_recipients
variable that used to be in compose.js was moved to compose_fade.js,
hence the need for the setter.
(imported from commit 462ca5d0d0bd58612d0197f3734a8c78de8c6d30)
"Kiosk mode" is a "read-only" Zulip suitable for embedding into
an iframe on another site. I say "read-only" in quotation marks,
because the account is still a fully-fledged active account on
the server, and we just tear out a bunch of stuff in Javascript
(that a malicious user could easily re-enable).
So in that sense, it's not actually safe in security-sensitive
environments -- malicious users logged in via kiosk mode
can do anything the kiosk-mode user can do.
(We need this functionality for the customer3 realm specifically;
we'll possibly just tear this code back out once that experiment
has run its course.)
(imported from commit deb035b4c702fcdb0e660ed549fe74c682abb6d9)
This fixes Trac #1567.
This is kind of a big hammer approach, though. If we did support
spellcheck on other platforms (without doing more work), this might
actually potentially disable it.
But we don't, so this is mostly a non-issue for now.
(imported from commit 74dcb42b19c37e1e8d1e9a2b265e1e6ae0cc2c67)
There are also one or two places we don't need to use it for security
purposes, but we do so for consistencey.
(imported from commit aa111f5a22a0e8597ec3cf8504adae66d5fb6768)
util.enforce_arity takes a function and returns a new version which
throws an error if an incorrect number of arguments (as determined by
the function prototype) are passed.
(imported from commit 20e69a6dc7b6f8455726ab4fae8d5b7b04dc4103)
If you search for "hello", then the word "hello" will once again
be highlighted yellow in the messages.
(imported from commit 172a40f1e288f9947ab3bfbff82b4a2f5ba5cecb)
Our API documentation says that we do, and it seems like it could be
useful to clients, so we might as well do it.
(imported from commit c391e4952a09d41df4dc06e3dc6ee094f774822b)
The main changes are:
(1) Changing the input format for the example response so that it is
human-readable and editable
(2) Updating it to use the events API
(imported from commit 308fade9595d6877836d343d2307e3fceff3e7d4)
When we deploy this, we'll need to of course actually build and deploy
the new API tarball.
(imported from commit 03c853e8a9424a63f1c74bb83637d5a1e50a159a)
The e-mail forwarder will use this. Set it to nullable temporarily to
accomodate existing streams; later commits will a) provide a script to
give all streams a token, and b) make the field non-null.
Realm administrators will eventually have a UI to regenerate stream
tokens.
(imported from commit a084d0a7012eb9665e4da095cbc46aa9ef354eaa)
This makes our life a bit nicer if the message is super-long,
because then even when it's "condensed", we still get a link
to the actual article.
(imported from commit 32e70d29cb702ce73f6cd0c04dbc58457cd2e6b5)
Even though we support a command-line option of --user=,
it gets stored in a field called 'email'.
(imported from commit f2956524517a93187ed182caf8e2d85ccbc1a0f4)
The test-all script now calls the symlink, and the run script
has been cleaned up to be symlink friendly.
(imported from commit 8abb5c1e5744416e94ff843e50c53e0d0f7e1316)
This fixes trac #1357, which says that some users get annoyed
when the system keeps generating the same color for them, which
would happen if they didn't like #76ce90 and kept picking a
new color for their streams.
(imported from commit 0fdb726aad4009332cc056a5e98bb39e01ef414c)
Instead of splicing up a cloned copy of stream_assignment_colors
every time somebody uses a color, we just rebuild a hash
of used_colors from our subscribed streams when we need to assign
a color, and we avoid calling into stream_color.pick_color() when
a stream already has a color.
This change has a slight functional impact in the situation where
a user unsubscribes some streams during their session, because
we weren't "reclaiming" colors before on unsubscription, but the
simple approach gets that for free.
(imported from commit adf360365bdf1ae9db99c533a0bde62d91f5dfe8)
This is a pure refactoring that mostly just moves code from
subs.js to the new stream_color.js and updates module references
accordingly. In order to prevent introducing some exports,
update_stream_color was given an additional "sub" parameter
and update_stream_sidebar_swatch_color was given an "id"
parameter.
Killed off unused initial_color_fetch var.
(imported from commit b7644ce67f50d31fb46f564d758d661eea776aa6)
One of the ugly parts of message_list.js is how it re-uses the message objects
from the server to hold handlebars template parameters. These objects are
shared between different message lists and re-renders, but are mutated by the
rendering process. The `dom_id` attribute is normally unset on summary rows,
and should not be used in the template. But when a message comes in with a
`dom_id` from another render, it can end up on the summary row, breaking
`rows.get()`.
(imported from commit ef6af65d5e995dffbd7234547786d6ea861920da)