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)
This also makes the people_list a list of objects containing the person's full name and email.
(imported from commit cff9b3de8cab0c9b2690ffa60d65d666302b989f)
Without this, if you suspend and resume you wait up to 90 seconds for
long polling to retry.
(imported from commit 5e964c357f395d30107af5b2c934949058c0d3a8)
We had this fascinating behavior where pressing a down arrow near the
end of the page would advance the pointer, call recenter_view, which
would trigger a scroll event, which would call keep_pointer_in_view,
which would notice that we were at the end of the page and advance the
pointer again!
I split out that last part into its own function which is only called
on mousewheel events.
(imported from commit bc85443e762356e3055f8f88585940a1f11f9124)
This also helps us manage checking, case-insensitive, for
subscriptions while preserving the casing used by the class creator
for display.
It also fixes a bug where the class_list would become out of sync with
your true subscriptions, allowing you to appear to send messages to
classes to which you had unsubscribed.
(imported from commit 5e8d017bcfb27a71c52f7517733eda7b926d721b)
It is confusing, and clicking on it should behave like clicking
elsewhere in the message.
(imported from commit e56434e8e143f6fa58b095e1c7d311b4aa24313f)
The new version is now the only codepath that we use in order to start
a reply to a message.
(imported from commit dd28316d2640fd5fd712f326690d480b7db59c4c)
This is somewhat experimental and we may need to work on the condition
when it shows up (or move it elsewhere).
Also, maybe it should say "Today/Yesterday" for times super close to
now -- the main issue with doing this is whether it needs to update
without your reloading the page to avoid being super confusing.
(imported from commit e29faf30c83b9574e5d233213f42a24175f9a616)
Zev Benjamin
Waseem Daher
Tim Abbott
Jessica McKellar
Keegan McAllister