* We now clear the validation errors when the input box is de-focused
* We make the left sidebar height accommodate the validation error messages
(imported from commit 4b39bfd3e8e8dd707722492a3f98967ee4ccf0ab)
To get to the bottom of the too-much-fading regression,
it was necessary to clean up the code, which was overly
complicated by multi-purposed functions.
The API for compose_fade now has these functions:
set_focused_recipient
start_compose
clear_compose
update_message_list
update_faded_messages
Internally there is now a notion of "normal display",
so e.g. when you want a normal display, we call
_diplay_messages_normally() internally, which removes the
faded/unfaded classes from all messages.
(imported from commit 7eb2b0a163f29d9ebae26661f432fecc7c331e4c)
This is an experiment to try to ease the customer3 onboarding process
given that there will be a website with a public feed of recent Zulip
messages, to ensure that those messages appear for new users.
(imported from commit 31fb59c1800728b5e4d8a5ce7282c7dcedb02b21)
Previously we would just discard the results of get_old_messages,
which meant that any messages sent either while you were doing the
tutorial or that you started out with (as in the case of the CUSTOMER3
experiment) would be lost until you reloaded.
(imported from commit f5280c091ab6ed7c2af6eb8fe49c0fa6b997ac97)
This if statement stopped working when we made the pointer managed via
the events system.
(imported from commit 382ca5bd055ab85048b211068ff3d43a47607f28)
This makes fade/unfade start sooner (good), but it might
re-introduce some typing sluggishness (bad).
(imported from commit 4e3112ed1ac931f2931182f91b60567ef2d72695)
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)