There was nothing to ensure that the changes resulting from scrolling
happened before the unread counts were checked. We already had a long
wait there; might as well do those checks after it to ensure that the
DOM is updated.
(imported from commit 0d4014ae6a74dd684521fecabefc4bf79015f842)
These engagement data will be useful both for making pretty graphs of
how addicted our users are as well as for allowing us to check whether
a new deployment is actually using the product or not.
This measures "number of minutes during which each user had checked
the app within the previous 15 minutes". It should correctly not
count server-initiated reloads.
It's possible that we should use something less aggressive than
mousemove; I'm a little torn on that because you really can check the
app for new messages without doing anything active.
This is somewhat tested but there are a few outstanding issues:
* Mobile apps don't report these data. It should be as easy as having
them send in update_active_status queries with new_user_input=true.
* The semantics of this should be better documented (e.g. the
management script should print out the spec above)x.
(imported from commit ec8b2dc96b180e1951df00490707ae916887178e)
people_list and people_dict include the feedback bot and anyone you've
cross-realm PM'd with. Useful for autocomplete, but not for admin and
stream settings views.
Fixes the UI part of Trac #1772.
(imported from commit cdefd4e86980447aad5190e7fc8ae3666d66e3c3)
hashchange, which calls admin.setup_page, runs in another onready
event handler before zulip.js main().
(imported from commit 5d4e71f4666baf0a53e3fe9804561ce6cdc06261)
This is feature-flagged to staging only.
There are basically 3 parts to the implementation:
1. In response to typing, fade/unfade the user list.
2. When a compose is aborted, unfade all users.
3. When the presence list is redrawn, fade/unfade the user list again.
(imported from commit cd416de232849a9f69dcacdc8b0fcfc20e3848a2)
This is the last step in getting a consistent client-side picture of who
is on a stream (provided non-MIT realm, and provided the local user is
subscribed to that stream).
(imported from commit 8bca722f169860ad4c1c92fdcb70d62c60f70fed)
The test will fail if a new attribute is added to the structure that
gather_subscriptions() returns. It should only be concerned with the
subscription's color.
(imported from commit fd5bad97bbce2544e0078ee029f54d4e45da9c15)
We found that since bugdown processes are threaded, the cost of
doing a db query in a markdown processor is quite high---each
thread must start up a new db connection including a SSL handshake
etc. We should strive to keep our rendering pipeline free of mandatory
DB queries.
(imported from commit 555066bd03da6c681b74ce6137acc264eb41c55d)