Previously, we'd render all the rows of the table except the first
(which is for creating new subscriptions) and append them all to the
table. This ends up being really slow. We now instead render the
entire tbody element and replace the existing tbody element.
When profiling on my laptop, this reduces the rendering time for a
few thousand streams from ~62 seconds to ~2 seconds.
(imported from commit 83a48e0e1f776f7663343662157298e89165ece3)
Regular Handlebars partials require pre-registering. This allows us
to treat any template as a partial.
(imported from commit fff785d4fa944547b7ad4c3a620ef9400777ec87)
I haven't hooked this into test-all yet, but I did modify
message_tour.js to accomodate the test.
(imported from commit e58f595f4fe1160f539c18ec09dbe22eebf1f104)
This change also adds comments to make it clear what the function does
and why it's used.
(imported from commit 68382abaf2d7c41c7de7d92cbf6e7583003aaf2a)
When you return to Home, we normally restore your last
position when in Home, which might have been before the
first unread message. This is cumbersome for sidebar readers,
so now we keep track of messages that you visit while on a
tour away from Home, and when you return Home, we skip forward
any messages that were in the tour, landing on the last visited
message. This all happens before rendering.
(imported from commit 9124a231d94f153e283e5ea95e40c50a58406275)
The goal here is to make it so that we can do other stuff with
the range of messages between two subsequent selections, besides
marking them as read.
(imported from commit f6eb07844fb2ccda195c9d4dfcdf1c15f3f40aff)
When hover over a typeahead menu item, the semantics have always been
to make it active, and now we also respect the naturalSearch option
there, which will set the text of the search box to the suggestion
immediately upon hover.
(imported from commit 02318d3d830e7e28d638efee0ef27023a73f52f7)
See https://github.com/twitter/bootstrap/issues/7392. I seem to
have fixed it with just the CSS part of their suggested patch.
To repro the bug prior to this fix, enter search, hover over a
typeahead, and then hit the up arrow key. You'll see two items
appear to be selected.
(imported from commit 383d60a606d7c19344a326208312a1555d060877)
This commit broke unread dots, since they're in the .messagebox
but absolutely positioned outside of it (so they got clipped.)
This reverts commit e0071851d2dc7d99c9acd93a1fc6fa1ce0c3b70e.
(imported from commit b3181b3a02cef905cc8f400f8c1cc3c92b5f0e15)
The total duration of this animation is the exact same, but
it starts immediately - let's see if this feels any better.
(imported from commit de86c259a25adb64514613579476480bdac29cb2)
There was some misguided code that eliminated the suggestion when
the user typed out the full topic, and since then there is more
generalized protection against duplicate suggestions.
(imported from commit 857e74458d10995170d312b77d99d839706ae680)
I'd encourage you all to review this diff thoroughly, since I am not
very familiar with this code. However, it seems to me that, prior to
this commit, if respond_to_cursor is true and page_params.staging is
true, compose.start gets called twice! (once by `respond_to_message`
and once by the "if (page_params.staging)" under the else, after it
returns.)
I eliminate the second call by sticking it inside the first else; now,
as far as I can tell, we call compose.start once and only once.
(imported from commit 319f51392541def358a138c104dd21722b4f8ba8)
The value it is passed is usually https://staging.humbughq.com, not
just staging.humbughq.com.
(imported from commit c3cd8fc5baa767377f506570aa8e7d2e1ed399ec)
Just before this is pushed to prod, we need to rename the Humbug feedback
bot in the database using:
./manage.py change_user_email feedback@humbughq.comfeedback@zulip.com
/etc/init.d/memcached restart
and we also need to update and restart feedback-bot in its deployed
location.
No action is required on pushing this to staging, but in between when
this is pushed to staging and when it is pushed to prod (and that
transition performed), feedback will not work on staging.
(imported from commit 73fc36f680b978f3aebae5df1822918ae4d4e952)
Just before this is pushed to prod, we need to rename the Humbug
notification bot in the database using:
./manage.py change_user_email humbug+notifications@humbughq.comnotification-bot@zulip.com
/etc/init.d/memcached restart
No action is required on pushing this to staging, but in between when
this is pushed to staging and when it is pushed to prod (and that
transition performed), notifying users that they were subscribed to a
new stream will not work on staging.
(imported from commit a0555527dec7b210022b09d9b1d13a7c910a8f9f)
Just before this is pushed to prod, we need to rename the Humbug new
user bot in the database using:
./manage.py change_user_email humbug+signups@humbughq.comnew-user-bot@zulip.com
/etc/init.d/memcached restart
No action is required on pushing this to staging, but in between when
this is pushed to staging and when it is pushed to prod (and that
transition performed), signup reporting to humbug will not work on
staging.
(imported from commit af2cd007b41ea885491f383442f211e8609fe5f9)
Just before this is pushed to prod, we need to rename the Humbug error
bot in the database using:
./manage.py change_user_email humbug+errors@humbughq.comerror-bot@zulip.com
/etc/init.d/memcached restart
No action is required on pushing this to staging, but in between when
this is pushed to staging and when it is pushed to prod (and that
transition performed), error reporting to humbug will not work on
staging.
(imported from commit 93044bb01797c981067f359676826d4a5791e235)
When we push this to staging, we'll need to rename the bot in the
database and also pull on git.zulip.net.
(imported from commit 22b2397b197c8820f0e55daecd8f98d829e195bd)
Luke Faraone
Tim Abbott
Zev Benjamin
Steve Howell
Scott Feeney
Waseem Daher
Waseem Daher