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)
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 fixes a bug where the server wasn't returning from get_updates
immediately when the client needed a reload.
(imported from commit 1d854eb1c7061f468d091e103f10074f4c7231d8)
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)
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)
Zev Benjamin
Keegan McAllister
Tim Abbott
Zev Benjamin
Waseem Daher