Set the background behind "Private messages" to green whenever
a user's unread count goes up for private messages. Remove
the background after 3s. Advanced browsers will fade the
green in and out over 6s (3s up, 3s down).
(imported from commit 80ed9661d9eec1d697f3259854037d7e145615cd)
The only known outstanding bug with this is that it doesn't properly
handle the updating of a message's highlighting/presence in a narrowed
view (e.g. in theory, a message should disappear if it is edited such
that its subject doesn't match your narrow or it no longer matches
your search). I think I'll just open a trac ticket about that once
this is merged, since it's a little hairy to deal with and kinda a
marginal use case.
Also it's not pretty, but that should be easy to tweak once we get the
framework merged.
Conflicts:
tools/jslint/check-all.js
(imported from commit 2d0e3a440bcd885546bd8e28aff97bf379649950)
Currently the interface for editing messages is limited to a
command-line API tool; it's great for testing with e.g.:
./api/examples/edit-message --message=348135 --content="test $(date +%s)" --site=http://localhost:9991 --subject="test"
The next commit will add a user interface for actually doing the editing.
(imported from commit bdd408cec2946f31c2292e44f724f96ed5938791)
Specifically:
* Leave the avatar image as inline and round it.
* Move timestamp to the left column.
* Replace the "Info" link with a permanent info sign.
* Move the pointer bar to the left.
* Remove borders
* Change selection background colors, and PM colors.
* Introduce the "narrowing" icon into our FontAwesome set.
* Modify the tests to account for the new "narrowing" icon and fixed a bug in star-finding.
* Clean up CSS and add a more prominent color to private messages
(imported from commit 8a8d6de8acccc52c0d16f5d1ce31aabdc72c88c8)
The geometry used by within_viewport() is a little off to
begin with, but we don't want to check it at all in this
situation, because if the last messages falls out of the
viewport, we still want to scroll. The relevant thing
to check is that available_space_for_scroll exceeds zero.
(imported from commit a0a6f0d23db2eab8d9f22fc9ad523031cf7f7ec2)
The prior code was subtracting out the compose box from the
calculation of available_place_for_scroll, which didn't make
sense when the compose box is at the bottom of the screen
and you're scrolling the current message up. You could see
the symptom pretty clearly by seeing autoscroll stop exactly
the height of the compose box from the top.
(imported from commit cfceb85c8be80cca957ac4a3ad0bbf0de7425c48)
This fixes a pretty subtle bug where the window-focus handler
wasn't updating the unread counts in the title, but it was
hard to notice, because as soon as you moved the mouse, the
problem fixed itself.
Apart from fixing the bug, this patch eliminates the expensive
mouseover handler, which is a big win.
The fix to the window-focus involved some unrelated cleanup. I
decoupled update_title_count() from received_messages(), as the
former method will probably live somewhere else soon.
Also, in order to get window-focus to update the title count,
I went pretty deep in the stack and added a call to
update_title_count() inside of update_unread_counts(). This
fixes window-focus as well as restoring that behavior to
code paths that were calling received_messages().
You'll see that call to update_title_count() is now adjacent
to the call to update_dom_with_unread_counts(), which is
fairly sensible, but then are calls to similar methods like
notifications.received_messages() that happen higher up in
the call chain, which seems kind of inconsistent to me. I
also don't like the fact that you have to go through a
mostly model-based function to get to view-based stuff, so
there are some refactorings coming.
(imported from commit 2261450f205f1aa81d30194b371a1c5ac6a7bdec)
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)
