I renamed set_count_internal to update_count_in_dom, because "internal"
was redundant in terms of saying the function was private, and it misled
me into thinking it was internal-only in impact, but it actually updates
the DOM.
I also removed the synchronous callback functions, since they both
led to simply hiding the count_span and clearing the text of the
value_span.
(imported from commit dea27d6414dc1b33818b24662f8246d687530b71)
This allows us to load our own code before most dependencies are
loaded. Our compiled Handlebars files still need the Handlebars
runtime, so we can't move all of our minified code before
dependencies yet.
(imported from commit e2d0fa13f05a08fc3c2519790f7382e5eef6eca2)
The problem is that if you load a browser window in a stream narrow,
add_message_metadata will be called for the messages in the narrowed
view before it is called for the messages going into the main view
(thus inserting them into all_msg_list), resulting in duplicate
copies of messages.
This would be mostly OK except that we call
process_message_for_recent_subjects inside add_message_metadata, and
that function assumes it is only called once on each message
(otherwise it'll double-count the message).
(imported from commit a3e7f85874100cd93a6d07684605da04d9cc80c7)
Created a function message_viewport_info() to return more accurate
effective viewport info and called it from process_visible_unread_messages().
Also killed off a tiny bit of dead code in process_visible_unread_messages().
(imported from commit 985fcf2fb447dbf1026e2de37574c255a9bd6196)
Whenever we get a narrowing event, it's possible for new messages
to appear visible, and we need to call process_visible_unread_messages().
This has been a bug, but it's mostly obscured by the fact that we
call process_visible_unread_messages() as part of focus/scrolling
events.
(imported from commit b9447977f8e2272d45865ca67b436cacafd58a03)
This works fine on prod, but after a new install-server, the closure
compiler complains about a side-effect-free for loop init.
(imported from commit aa0e4d788abe4c819d4d912d6a526fab4f676675)
This removes the large "New stream message" and "New private message"
from the left sidebar. It also makes the default action when clicking
inside the composebox the same as the "New stream message" button used to
do (instead of replying to the stream-subject pair at the current cursor).
(imported from commit 316f03a35b781aca4c42555f74b99c4332ff42de)
This refactoring basically splits off two functions from update_unread_counts(),
which then becomes a simple three-liner.
The function get_unread_counts() is extracted, and it's purely functional
computation. It paves the way for a more pull-based approach to getting "unread"
counts, where other parts of the program can just call it to get values as
needed without worrying about side effects. It is staying in zephyr.js for
now.
The other function is stream_list.update_dom_with_unread_counts(), which
has a new home in stream_list.js. It handles all the DOM manipulation
aspect of unread counts in the left pane, mostly by delegating to smaller
functions within stream_list. Some of those smaller functions can now
be turned into private methods FWIW, but I'm not sure it's worth the
trouble.
(imported from commit 799f9ebbaed8d530829a4741ef14be04bd8abf5a)
This is a prefactoring to eventually eliminate the home_unread_messages
global variable. More commits to follow.
In order to set up process_loaded_for_unread() not to modify
global variable to get its job done, we want to pull it out of
add_messages(), so that add_messages() doesn't have to pass back
state to the 9 different places in the codebase where it's called.
There are only 2 places where process_loaded_for_unread() get
called after this commit.
In order to facilitate pulling up process_loaded_for_unread(), I
made it so that the contract for add_messages() was to accept
already-hydrated messages. This way I could hydrate the messages
before calling process_loaded_for_unread() without have to
worry about double-caching them in add_messages. This will
slightly improve performance, but it was mostly done for code
clarity.
(imported from commit ad5aaad5b1f22c31647370f4c9dcb5f89d7d99a7)
This was a workaround for a number of other bugs we had, but at this
point just serves to make debugging more difficult.
(imported from commit 6662b7854c265bd8016f6c8ce75a095731211a45)
We really should not be storing bot API keys in the DOM and should
require some sort of additional authentication before showing them,
but this seems reasonable for a first pass.
(imported from commit c7d75aa52e21894bf53917457e771c18de38bbcc)
The idea here being: if there's only one line, it discourages
me from writing a long message (and also makes me think that
enter will send).
(imported from commit 424d8d305d1965ce3199ce3227dac94b395945bc)
This commit takes control of keyboard-based pagination away
from the browser, so that we can use the effective viewport
size as the amount to page, as well as keeping a little bit
of overlap from page to page. There had been issues with
pagination for a while, but the introduction of the always-open
composebox particularly aggravated the situation.
(imported from commit 45b9b7d5a6b322230c9d55e1be0b763dbce06e2e)
Previously we never sent desktop notifications when the browser was
focused, even if the message appeared offscreen. After this commit
there are only a few cases when PM or other notifiable message doesn't
trigger a desktop notification:
(1) You sent it yourself
(2) It was onscreen when it arrived while your Humbug window had focus
(imported from commit e381c02c0e6794594d6934f57249a11ba2a88210)
This is trying to make the logic flow clear -- e.g. we check once, at
the beginning, for whether the message is notifiable, and the checks
for whether the various notification settings are enabled are more
parallel.
(imported from commit a68c71a53055191bc16682a85f739ed8e40ddeae)
See #1234 for details. When you upload files the old-school way
(no drag&drop), there was a bug where you couldn't upload the same
file twice, due to us intercepting the change event and not clearing
out the file list when we were done. Tested on Chrome, but uses
a known IE workaround.
(imported from commit 8120c2e8bce41f3964f4f5c21aad3a85df0e433d)
The filedrop library has a few canned errors, but it seems to mostly
let server errors come through. We try to trap 413s to give a more
descriptive error than "unknown," but this is just a bandaid fix,
and we should see what's wrong with our prod configuration.
(imported from commit eac26406866d80340f24dbdca9f34408ddb92462)
The .height() and .width() functions are actually pretty expensive for
the number of times we call them. The viewport height and width
don't change often, though, so we can just cache them and recalculate
them on window resize.
(imported from commit 129fb8c058144125e2974f6b7967cd9f1a5c9ead)
The .height() and .width() functions are actually pretty expensive
for the number of times we call them. The callers of within_viewport
already know the offset and height of the row, so we just pass them
in so the values don't have to be recalculated.
(imported from commit d1c077bd87463d695f0bbe337b6a8b04ac2d17ce)
The optimizations are:
* Sort over the list of subscriptions instead of the DOM li elements.
This requires storing the li elements for each sub on the sub object.
* Do a bulk insert of the li elements instead of doing them one by one.
(imported from commit 1a987799930fc677e25f0bc2dcf66f83a4ac3163)
