Previously, we had some ugly complicated logic through which we
attempted to keep the selected message on screen when prepending
messages, but we didn't actually preserve the scroll position -- the
selected message would jump on the screen. This fixes that, by just
saving/restoring the scroll position of the selected message.
This perhaps makes our model/view split even less clear, but at least
it's correct.
(imported from commit 0a01450bbbcdf1b45c891d0570c9fcfb11769315)
message_list.prepend() now actually only rerenders the new messages
when prepending using the where="top" functionality (previously it
would erroneously just adjust the message database and then wait for
message_list.append() to call _maybe_rerender(), determine that things
are awry, and rerender the whole message list).
(imported from commit c64b7b540a4f5332ad792de0fad9f20750e6db1c)
This has two benefits:
(1) Users can scroll their last message to near the top of the screen,
which decreases how often one needs to scroll down to track current
messages.
(2) It makes scrolling bugs near the bottom of the screen a lot easier
to find, because scrolling down too far isn't blocked by being unable
to scroll messages off the screen.
We should probably later convert this to some formula that varies
dynamically based on the height of the last message.
(imported from commit 41954fecd9efb43820ed1ccb5210283c17752f51)
It turns out that this code tries to place the initial pointer 1/7
from the top; the only reason something reasonable happened
historically is that bottom_whitespace was only 40% of the screen, so
the pointer message ends up landing in the center anyway.
(imported from commit 56d4c2acd018d9a87551c82a43c214c6d80bfb90)
Previously we incorrectly would sometimes trigger autoscroll when
messages arrived via get_old_messages (i.e. we loaded some historical
messages from the server). This resulted in some confusing and
erroneous scrolling behavior.
I kinda hate the fact that we need to pass these values all the way
through the rendering process, but fundamentally there's no other way
for _render to find out, and pushing the autoscrolling higher up in
the stack is hard since we don't return anything like the block of new
messages.
(imported from commit c5ed27f1b21691a21c68ed7e09cff8e3e4a75e76)
This is purely cosmetic, and just puts some similar functions
together in a way that JS lint won't complain about calling a
function before it was defined.
(imported from commit 8a5a81ae5b7ca7dbaa60147ae4f32f50b1cbbf3a)
This reduces roundtrips hopefully and will provide a friendlier error
message than what would otherwise be produced by Django.
(imported from commit 034aeef00043e3bf059583770f6c08c4f73ceeb5)
Fixes the JS traceback "'null' is not an object" introduced in b67e52d.
Testing: Receive a message when narrowed to a different subject, with
the window focused.
(imported from commit 54b9e7924a2bf66ba5cc9799fc3687a084496465)
Fixes the JS traceback "Selected message id not in MessageList"
introduced by b67e52d
Testing:
* Narrow to a subject and send a PM
* Narrow to a PM recipient and send a stream message
* Narrow to a subject and send a stream message to a different subject
(imported from commit 1171c3f97813dc7db891042906762be8afb2a1b5)
This reverts commit f8fbf70c8502370a78159e24f3cf9589fb9d384f, since
we're waiting on some Firefox and no-hover fixes.
(imported from commit 6b13f5bb9d907303ab311afd7da584bc06538c91)
(The dead code made sense in the very early phases of sketching out
the feature, but it's no longer executed.)
(imported from commit 464145f227ddb25f0554bbbade0b0e3e0e399bc3)
This is slightly inconsistent, but keeps the unread count from decreasing
when narrowing and un-narrowing.
(imported from commit 185e8653c31a312c166e784b335ae7ae7e9b78e9)
I tried 30px at first, but I think a slightly bigger avatar helps
fill out the table a bit. It should be easier to tweek these in
CSS now, although Allen agrees with me that the tabular display
may be short lived when we add edit/delete features.
(imported from commit b4d69cddf63fa122374e20731a5755e7dec86304)
