This was preventing huddles from sending because clients thought they
were still sending a stream message.
(imported from commit 694b06cbc43adc9563327ebffccb7fa37aa36bac)
The flag is set to the kind of message being composed in
start_composing() and set to false in finish_composing().
This avoids the problem where composing_message() will return true
when the animation is still running.
(imported from commit 4c2e7e1fad2e6b2123825bd51d5b24ae41bccd45)
This fixes a bug where the server wasn't returning from get_updates
immediately when the client needed a reload.
(imported from commit 1d854eb1c7061f468d091e103f10074f4c7231d8)
These make assumptions about the current message type. We should just use
by_recipient externally.
This reverts commit ad2123f99ce91361ab907c308bfecec4efd722a4.
(imported from commit b7945896568c4c5c31a9d5bddb0e9ade8eef859b)
Known issues:
* Not all of the options in the menu are functional yet
* The wording isn't totally perfect on some of these options;
I kind of want to use a 'first name' in some of them.
(imported from commit 5a333fb939fcca7e0d0ecb2c43e79501139ac0db)
Embedding this in index.html won't work anymore, because the Django FastCGI and
the Tornado servers might have been started at different times.
(imported from commit 187909d0593449cf2989857671f9ca526723e451)
Previously if you tried to send to "a b", we actually ended up trying
to send to "a%20b", since we were url-encoding the stream name and
then not properly decoding it.
(imported from commit 307d2999bd309e47fc654ae4422ab4372edde064)
PgUp, PgDn will already call the scroll handler, which will
of its own accord call keep_pointer_in_view.
(imported from commit 8b6e53eaeda91d0f35775de72e16d63dc6c8340b)
That andSelf is only necessary if a .recipient_row were immediately
followed by a .bookend_tr, which, I don't know, after a redesign could
very well be the case, so let's guard against it now, especially since
our performance on scroll is currently pretty good.
(imported from commit 1011555fbfd30943b4aa917997d6e35bcce959fc)
In my limited trial, this sped the call up, on average, from
0.507ms to 0.473 ms... so, admittedly, not a lot.
I think this is a little conceptually cleaner, though, and it handles
the common path with the least work, which I like.
(imported from commit c8b827a2e8111fbdd54bcabe05ac36f64523c466)
nextAll/prevAll walks the entire DOM, basically.
This code only walks the DOM until we find a new .message_row.
This speeds up the average time of a call to this function from about
6.38ms to 0.678ms, in my benchmarking.
Admittedly, the whole outer loop here could still use some
optimization, if we want to; do we really need to call this 1000
times?
(imported from commit 852e2f660a16f8cfd7be35d3271aedb1ac481663)
http://api.jquery.com/first-selector/ mentions that using ":first" in
query selectors can be a little slow since we can't use the browser's
native querySelectorForAll implementation.
In my tests, this cut the average time down from 6.70ms to 6.38ms.
So, not great, but this function is most frequently called
many times in a big while loop, so, better than nothing.
(imported from commit d7725edd0c81431829fe353c6dd2bc61b1de6b19)
