This way if you refer to "trac #253" in the subject, it's super
convenient to get from your recipient bar to the ticket.
A note on performance: this part of rendering for 1000 messages takes
about 3.5ms for messages with 1 match; this is small compared to the
overall time for to_dict_uncached for that many message objects, so I
think this is OK for now.
(imported from commit 5bdc2b8415d7599d59eb554739f545c485b78d5a)
Previous code iteratively called set_user_status() once for each user;
which in turn was rerendering the user sidebar, also once for each user.
I changed the API a bit by replacing activity.set_user_status() with
activity.set_user_statuses(), plural, that takes an object and updates
all the user statuses in one go before rendering.
(imported from commit 1111c9029264f892f25e76d2e5e5ff996dcbc7ca)
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)
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)
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 is slightly inconsistent, but keeps the unread count from decreasing
when narrowing and un-narrowing.
(imported from commit 185e8653c31a312c166e784b335ae7ae7e9b78e9)
After fixing the high numbers of database queries earlier in this
branch, I found that sending 500 RabbitMQ messages for a bulk change
in subscriptions was consuming more than half the time for these (and
then we'd end up with 500 events in a queue). To handle this, we
create a "user X subscribed to these N streams" event, rather than
sending one event for each individual subscription.
(imported from commit 44a34a9fab9b67e9f0da6fee53335d8c5030392b)
Trac #1403.
This shows the 5 most recent subjects, as well as any others with unread messages. This
requires tracking all subjects and filtering at display time, rather than filtering when
building the subject list.
(imported from commit 8bda7d50e6785a6e70abea4b3af4d03a16d076d3)
Get data directly from the main user list, rather than maintaining a
separate list just for autocomplete.
Fixes trac #1362 -- Does not depend on historical messages, so
will do the correct autocomplete after a single reload.
(imported from commit 6b35a709dba3384530082e8cfacf0151f9e0eb26)
I don't love the default reloading message, but I'm not sure how to
tell the user why we need to reload in several cases.
(imported from commit 5f2eecdb0d83f31bd60673b247e8aac8f08ce20f)
This is a pure refactoring. We set messages.sent_by_me inside
add_message_metadata(), which gets called early in a message's
lifetime.
(imported from commit 2f6270f92ecdf0e4a64401030f86d89a8fb7be2e)
This should substantially improve narrowing performance, while still
delivering enough messages that one should only need to contact the
server again if the user scrolls up a significant distance.
(imported from commit 2b0af0e5b9d3a449e7f195a87d57d517b47f0b3a)
Don't show an error banner for any uncaught JS exception, as often the app
will continue to work fine, and there's no way to dismiss it other than
reloading the page.
Also, don't show a transient "could not connect to humbug" error if
the check-for-messages-in-narrow request fails.
(imported from commit 2c634ba088b58c17fa5b2e3353b0589d40b8e357)
1) When you send a message, restore the focus to the composebox, targeted at the same recipient
2) If the composebox is completely empty and you press up or down, have that close the composebox and take the appropriate action
3) If you started the compose via a reply option (r, enter, click), don't refocus the composebox if the cursor has changed.
(imported from commit 84545e49d06959eb62e7fd2b22e1387383df6d1d)
The message_viewport_info() function encapsulates our logic
around the compose box and other elements blocking the viewport,
so viewport.js seems like a more logical home for it. It also
makes ui.js, one of our largest modules, a little bit smaller.
(imported from commit 7838668b28175e161b87a6d7a8124b73012f0ff3)
The core simplification here is that zephyr.js no longer has:
* the global home_unread_messages
* the function unread_in_current_view() [which used the global]
The logic that used to be in zephyr is now in its proper home
of unread.js, which has these changes:
* the structure returned from unread.get_counts() includes
a new member called unread_in_current_view
* there's a helper function unread.num_unread_current_messages()
Deprecating zephyr.unread_in_current_view() affected two callers:
* notifications.update_title_count()
* notifications_bar.update()
The above functions used to call back to zephyr to get counts, but
there was no nice way to enforce that they were getting counts
at the right time in the code flow, because they depended on
functions like process_visible_unread_messages() to orchestrate
updating internal unread counts before pushing out counts to the DOM.
Now both of those function take a parameter with the unread count,
and we then had to change all of their callers appropriately. This
went hand in hand with another goal, which is that we want all the
unread-counts logic to funnel though basically one place, which
is zephyr.update_unread_counts(). So now that function always
calls notifications_bar.update() [NEW] as well as calling into
the modules unread.js, stream_list.js, and notifications.js [OLD].
Adding the call to notifications_bar.update() in update_unread_counts()
made it so that some other places in the code no longer needed to call
notifications_bar.update(), so you'll see some lines of code
removed. There are also cases where notifications.update_title_count()
was called redundantly, since the callers were already reaching
update_unread_counts() via other calls.
Finally, in ui.resizehandler, you'll see a simple case where the call
to notifications_bar.update() is preceded by an explicit call
to unread.get_counts().
(imported from commit ce84b9c8076c1f9bb20a61209913f0cb0dae098c)
We are moving back to a barnowl-ish scrolling algorithm for
the arrow keys, where when you have a message selected toward
the bottom of the screen, hitting down arrow and up arrow
effectively puts the originally selected message at the center
of the screen. In order to avoid unnecessary scrolls, we
are making it so that you can move the pointer closer to the
edges.
(imported from commit c08233d6d2034a04469b8f424b39d94a230cafe0)
`current_msg_list.get(id)` and `rows.get(id,
current_msg_list.table_name)` are not interchangable in terms of
checking for whether we have a message. The former checks whether
the message is in the current message list while the latter checks
whether the message is in the current message list and currently
rendered. `message_edit.end` only operates on rendered messages.
(imported from commit 203ee612bfd0aa94571dde9b601e948b3c6f6cbb)
Previously, if you didn't have a message that someone else had edited
in your message list, you would get an exception because we weren't
checking whether we actually had the message or not.
(imported from commit 33a5c6e7fe95b5397a32df5c7b5f6714d71e1e5f)
Before this fix, the code would restrict the pointer to be above
either the 1/2 mark or 2/3 mark of the page, depending on your
scrolling direction. This fix makes it so that the system leaves
your scroll and pointer alone when between the 1/5 mark and 4/5
mark. This means the user can read more messages on the screen
at a time before getting paginated.
(imported from commit 98f6319bf63181dd331e037ac20a0c15518725ea)
Re-focuses on the compose box after a send, under these conditions:
1) narrowed to stream+subject -or- responding to PM/huddle
2) compose was initiated by clicking on a message or hitting "r"/"enter"
3) cursor has not moved since you've started the composition
Additionally, if you are thus narrowed, we will move your cursor when you've sent
a message to that message, assuming that such a message initially appears visible.
(imported from commit 373c858081694e6fc9994639340a847d66edb566)
This change fixes the barnowl scrolling so that the ratios of
1/5, 1/2, and 2/3 are all relative to the visible viewport.
The core part of the fix is that we need to call
ui.message_viewport_info() to get the correct offsets for
the top/height of the actually visible viewport Because
this function is fairly expensive, I didn't want the
helper functions needlessly re-calling it. I could
have passed the helper functions the structure, but at
that point it was simpler to inline their functionality.
(imported from commit fb10d99313d568e85acfa70703c4651466acbc21)
Treat "mentioned" messages like "starred" messages for narrowing.
Lots of ugly copy/paste here. There might be opportunity for
some cleanup in places.
(imported from commit e7629890d42643c0000e1cc85422b2a0690f2cc4)
Re-focuses on the compose box after a send, but only if
the compose-box was opened by responding to the message
at the cursor (by hitting "r", enter, or clicking on the message)
(imported from commit 8e7560c8ea31397b57b2bc3e2e7d9dd996226a6f)