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)
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)
Fixes the blueslip error on "i" in empty narrow.
Also removes a then-uncessary check from do_narrow_action as suggested
by acrefoot.
(imported from commit 10b1f702b535b4eef54e500ccef93b6a5280e953)
Summarized messages are not shown and cannot be selected. If
`opts.use_closest === false` and you try to select a summarized
message, we still have to use the closest instead of failing.
Eventually, we'll make summary rows selectable, but that would be
rather involved since selections are managed by ID, summaries exist only
in the DOM, and many parts of the code get the selection and expect
it to be a message.
(imported from commit 998c4f24aece84528cc9da53a47f9e4f5391702d)
On a page load or reload, the browser will, at an idle time, scroll to
the top of the page. We can't intercept this browser-induced scroll,
so to make sure it doesn't in interfere with our scrolling to the
correct place in your message feed, we let the browser scroll happen
before the work we do on page load.
(imported from commit f5f441ab90bcdb8404e05caea3c6da81a3a6fc1e)
This commit makes keep_pointer_in_view() less aggressive when
the pointer is toward the top of the screen. If the pointer is toward
the top of the screen, then as long as it's fully on the screen, we
don't pull the rug out from under the user and change the pointer.
An important benefit of this change is that we fix trac #1608,
which was a bug where autoscrolling interacted with
keep_pointer_in_view() to push messages past the top of the screen
before they were read.
(imported from commit e39926df99bfaedd5c0757f1241887ccd9b93fab)
The helper functions now return true when a message is on
screen, not when it's off screen, and the names have been
changed accordingly. I also eliminated the at_end parameter,
which was kind of abstract, by having message_is_far_enough_up
and message_is_far_enough_down handle those details.
(imported from commit cdb1543e430f49f23eb1b3a88d9aaff95ce7ca74)
* Move the state into a closure to duplicate it for multiple queues
* Use _.debounce instead of manual setTimeout fiddling
* Have it handle manipulating the message flags
(imported from commit 938f51fd666131a3cec5901d3f3fdd39e203b462)
Functions were supposed to check that messages were unread before
passing them to process_read_messages, but some didn't.
The `mark_messages_as_read` function was essentially that, so
take that name.
(imported from commit 2917fe30d2defb8a047ec32e1bc70d379779276b)
When you read messages in a narrow and then un-narrow, collapse
adjacent messages read in the narrow into a summary row that can
be clicked to expand those messages.
Scoped to staging with feature flags.
The implementation of this within our current MessageList is rather ugly.
(imported from commit bcb3a39d8c0c334136fe86318f18ead03f0f50bf)