If we have removed a stream from the home view, and our pointer
that we load from the server refers to a message that is no longer
visible, we don't want to error out but rather select the nearest
message to our previously selected one.
(imported from commit d212f1fba7b06836d1d916b43042991625b6f41e)
Messages are now selected on a MessageList, which triggers a
message_selected event that other parts of the code can listen for.
(imported from commit 1da9e4121425c0ac4461b41b7aea169072e1512b)
Previously we would select the first message in the block. Now, we
only do that if a message that is selected will not be in the
resulting narrowed view. If the selected message will be in the
narrowed view, we select that message once narrowed.
(imported from commit 4da5a3a0b597b58c2e028f1b29ac20ae3808a4d1)
I kind of expect this to work, and hopefully this'll help with
people getting stuck on the "Settings" page in the tutorial.
(imported from commit 1159d884dcd331bcfb74864a0176fa293e8c3714)
Most of them are just typos or funny punctuation, but this also adds
the word "above" after "You and Humbug Tutorial Bot" since otherwise
the user might try to click the text in the message body and be
confused.
(imported from commit dccaf4acd24db713acab261440f0a9d03860e0f4)
Right now the MIT realm has pretty bad UI lag with 1,200 messages loaded. We
need to fix the root problem, but this commit at least makes reloading the page
a satisfactory remedy.
(imported from commit 93d47710891cfc4db9fa00beaa5ccd10113aa1c3)
Here I have a sketchy but functional framework for dealing with
all of the async stuff that a tutorial requires, and an early
draft of what such a tutorial might look like.
I could probably go and remove the first-run message, but I'll
keep it around for now in the unlikely event that something I
haven't anticipated goes wrong in starting up the tutorial.
(imported from commit de9779a66a1b3fe790082decb324c90ec180b39b)
The idea here is: part of the onboarding tutorial is going to
be you talking to the tutorial bot and it talking to you, from
our Javascript.
The reason it's driven by Javascript is that then in principle we can
do nice stuff like making popovers appear in places to point things
out to you, whereas if we were to do it strictly server-side, doing so
would be a lot harder.
The downside to doing it in Javascript is that you don't get any of
the Markdown rendering, since that happens on the server. So instead
we add this call where you give it a message, and it responds by
having the tutorial bot send you that message.
I don't think there are any security concerns here because
(1) The bot only messages you -- so you can't use it to make someone
else think that the system is telling them to do something
(2) If there were an issue associated with having the server parse
arbitrary Markdown, you could just trigger the issue by sending
a message yourself.
(imported from commit b34f594dab6be6bcb81899278ae1cbe447404468)
The defaults are quite large for a small site like ours where on
server down means an outage (e.g. only check every 5 minutes and then
require 4 failures before we alert the admins).
(imported from commit 3b2f436bbb716262f4ee939434749be535ffd6d3)
- Find Python and JavaScript files the same way, by looking at
everything in Git with specific exceptions
- Check the non-browser JavaScript, with appropriate JSLint options
Fixes#19 and #387.
(imported from commit 042bd6c26aa7a7ea2209935320ef4da12344b02b)
Leo Franchi
Jessica McKellar
Zev Benjamin
Luke O'Malley
Keegan McAllister
Tim Abbott
Waseem Daher
Reid Barton