This seems more likely to be what people want when e.g. viewing all huddles.
Later we can get more clever and select the nearest huddle, or something.
(imported from commit 8ec1aa02c050dd25eb868b1e317d114743525c7b)
Our old selector here was picking up the floating recipient label, or
something. This was breaking narrow-to-all-huddles when on a stream message --
you get no selection and the code is sad.
(imported from commit d25fab03bd6d745df6d787c0b1b6452c8c539e32)
- s for stream or huddle
- S for subject
- p for all personals (still buggy)
We've eliminated the 'g' prefix entirely. And the old 'g-a' un-narrow sequence
has no new equivalent, but you can still use Esc.
(imported from commit 6bdaacce9639e3f749418e06622a317937e7d014)
Ideally this would be part of hiding zhome, but right now zhome/zfilt are
assumed to the tables themselves, and changing that seems unfortunately
invasive. And it's not crazy to think of the "loading controls" as a logically
separate thing that we might show/hide independently.
Longer term, we may want an indication in narrowed view that there could be
more messages on the server.
(imported from commit eb72d720da7c03f6f1378ae18ab6e973bf98247f)
The server will occationally return successfully with no data during
a restart. Previously, when we would get such responses, the page
would stop working because of JS errors.
(imported from commit 39b89907dc5ae9a9eb54ebf60d0069281e401786)
This fixes a problem where the client would never stop asking for old
messages (bug introduced during rebase)
(imported from commit eef9f19e1e9982b1e0a954eb36a81e1b7ee5b564)
The client may now optionally send its current pointer during
get_updates and the server will return the latest pointer if it
differs and was updated more recently by a different session.
(imported from commit e43b377d7dfb52f83cefb0b1003863d5407caf80)
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)
If the client is not composing a message, we can just force a page
reload. However, if he is composing a message, we must preserve that
message while still reloading as soon as possible.
We take the following approach: if the client has not completed the
composition after 5 minutes, do a compose-preserving reload
(described below). If he sends the message before the timeout
expires, reload the page after a successful send. If the send fails
(not due to server timeout), however, we do a compose-perserving
reload in case the error was due to the data format changing. If the
send failed due to server timeout, we don't reload because the reload
will probably also fail.
In a compose-preserving reload, we redirect to an URI that has a
fragment indicating we are doing a reload and containing all the
necessary information for restoring the compose window to its
previous state. On page load, we check the fragment to see if we
just did a compose-preserving reload, and, if we did, we restore the
compose window (or just try the send again in the case of send
failure). The URI fragment looks like:
(imported from commit af4eeb3930c24118e088057d4da456748fbd2229)
Given that we now look at the top of the pointer rather than the
bottom for this check, our previous 4/5 number was far too permissive
(and led to your selected message often getting covered up by the
compose window).
Anecdotally, this feels a bit better to me.
(imported from commit 39ca7924db56272f7e623708ce0125b2a7012656)
In particular, we had this issue on huge messages. Suppose you had a
huge message and were scrolling up from the bottom. Initially it would
get selected as the message underneath it was below the
threshold. Then, when you scrolled again we said "oh, well, the top is
too tall, it's also *above* the threshold" and moved the pointer back
down. So it glitched back and forth.
Now we consider you above the view threshold by looking at your
bottom, and below the view threshold by looking at your top, which
seems to resolve this issue.
(imported from commit 2434d1103ab3fa894ade612ac1fb10b2f3cd66cf)
I think this'll allow for a slighlty more accurate drawing of our
floating recipient row in the even that some of these things have
borders and others don't.
(imported from commit 31714f7356604e1d9c64bcc7f6fd14b8a02a99b5)
I'm actually not sure if this is a performance gain or not; I guess it
depends if any of the stuff inside mousewheel or scroll took longer
than 50ms to call (and right now it does).
(imported from commit e3fcc4a14cd8787fa2357a43ed878ab08646e4f2)
This allows us to put other stuff in the narrowbox and have
it also magically get resized. At least in theory.
(imported from commit 92975e3d0893b34d52cad910462cbf2ccaed2eab)
Tim Abbott
Keegan McAllister
Zev Benjamin
Waseem Daher
Zev Benjamin
Jessica McKellar