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)
There was this very cute problem where if you were narrowed and
scrolled to the top of the page, you couldn't seem to click on the
stream or subject name.
The issue was: the floating_recipient_row div was visibility: hidden,
which means that it made top_statusbar big enough to cover up that top
part, capturing the clicks.
So instead we make top_statusbar also visibility: hidden so that
the clicks get through.
(imported from commit 471e041ba1c429ad0b6e225da22585dc72120945)
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)
If we make the recipient_rows the same size for huddles and stream
messages, this becomes a non-issue. (Previously, the border on huddles
was 2px, which I think caused our invisible row to have its height
grow by 1px -- which was a problem, because then it left a little 1px
gap that you could see through when we scrolled over non-huddle
messages.)
(imported from commit d1f24e5c536bdf9c0827a15b611ba680ee4e5e36)
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)
There were two issues:
* The people_list population changed and I failed to noticed
* Typeahead source updating never worked before because calling .typeahead()
more than once does not change the data source
(imported from commit fda14029f4cd37260d82e7bb5689f5022e1b0d28)
This also makes the people_list a list of objects containing the person's full name and email.
(imported from commit cff9b3de8cab0c9b2690ffa60d65d666302b989f)
When Bootstrap shrinks the divs down into 'tablet' mode, our selected
message might end up being even lower in the screen than it was before
(because more text wraps). But our scrollbar does not automatically
advance to keep it in view -- so we do it manually.
This implementation is a little hackish in that it does some
unnecessary recenter_view-ing in big views (which can be a touch
disorienting) to optimize recentering on resizing for small views.
If that behavior is annoying, we can deal with it by being
smarter about when we trigger the recenter code.
(imported from commit 6834e11f7a37833982c388f15174df661d7f55b3)
When the window is narrow, vertical space (particularly in
our navigation menu) is at a premium, so let's be more
parsimonious.
(imported from commit 72628827bc108f4d9f2d47a11c48e0e772b769d4)
Zev Benjamin
Waseem Daher
Keegan McAllister
Jessica McKellar
Tim Abbott