I figure it's worth giving people time to read the message and click
the "Report error link" before we redirect the page away; 60 seconds
is still short enough that if the person wasn't at their computer,
it'll still fix itself.
(imported from commit 577193cf8dca0a646933741a50769378ddd824bb)
The new message list system can rerender the message list on scroll,
but did not properly re-highlight any messages which were highlighted
at the time the scrolling was initiated due to an open compose box,
this time due to a bug where the meaning of "this" changes when we
moved the rendering code into the message list library.
(imported from commit 26d9716811b56a6f89ae22e68038ad560dcfee64)
The new message list system can rerender the message list on scroll,
but did not properly re-fade any messages which were faded at the
time the scrolling was initiated due to an open compose box.
(imported from commit 4bc7c172e8bb55acfaacc5e5460eb6a2ef9aebe2)
Now when the font increases, so will the size of the emoji. (1.4em
seems to be 20px at our default settings, so this doesn't change the
size of the emoji for any of our existing people).
(imported from commit edb0b590f00bfbad0355a41b1f995335cf0e9e07)
Previously we did the equivalent of a $('.message_comp').child('input'),
which does not search beyond the first level.
In addition, using a comma in a selector is essentially an AND, which
means the narrow search only applied to elements of the 'input' class.
So when debugging we saw a bunch of elements being selected and that hid
the bug for a bit.
Now we do a .find instead which will ensure we blur the correct
elements.
This closes trac #1045.
(imported from commit f44383ee9fc93406d031589ef914f5a003334ea7)
This now adds you to a special `tutorial-username` when you begin,
we send tutorial messages there, and we remove you from it when
you're done.
(imported from commit a93a90b9347a4f72536e96331ddfd1d47727ce71)
But only allow them to send to tutorial-<<your username>>.
The idea being that this helps reduce potential abuse from this JSON
call. (Because otherwise, anyone could call into this endpoint and
have the tutorial bot send random messages to random peoples's
streams.)
(imported from commit 471d4348d7ad43858b5df240e4f1dceba006aab6)
Prior to this commit, at 800px, e.g., the Google button
is smushed into the login form.
(imported from commit 422d1b677439460785f6b31ea2fe2c819e23e259)
Previously, we blurred all input/text boxes, including e.g. the search
box. This probably won't impact normal operation, but this can be a
problem for our automated frontend tests which tend to have different
timing than real life.
(imported from commit ea84312bea2aae99d51b48cede0746e7a5b6e76e)
We had a bug where if the selected message had the same subject as the
target message, but a different stream, narrowing by subject would
narrow to that subject plus the selected message's stream rather than
the target message's stream.
(imported from commit 4b196342318a06d8aeea46bf05e3d7416ecb6c5b)
Previously if you narrowed to
"pm-with:wdaher@humbughq.com,jbarnold@humbughq.com", you'd always get
no results because our filter was comparing your query against
message.reply_to, which is sorted in alphabetical order.
(imported from commit 40dc78640f3b010f11312176cfcf3c331fdf3337)
The most expensive part of adding the display time to messages is
calling time.toLocaleDateString() and time.toLocaleTimeString().
Most of the time, this information never gets seen, so we now delay
calculating it until just before the user would see it. This cuts
the time to render a chunk of messages from >1s to ~200ms.
(imported from commit 6167e7a8e1c3b4ca77471fa346292be4ffa67ec8)
Adding the display times to messages is very expensive (> 1s for 400
messages in Chrome on my machine). This commit doesn't directly
address that issue, but does mitigate its affects on scrolling speed
when rendering the next chunk of the message list. After this
commit, rendering a portion of the message list for the second time
only takes ~300ms.
(imported from commit b22badb5dcce69be297f6403b1cb40950e46376e)
Long-term we probably want to pick the render window size and
re-render threshold based on the user's window height instead of
arbitrarily.
When we re-render we probably also want to ensure that the newly
selected message appears in the same location as it would have
before the re-render.
(imported from commit f044b7f2200822e8e6e8dba7108d087a69016134)
One of Matt Goldstein's comments is that we often make you look
like you're not at your computer, even when you are, just because
you haven't checked Humbug for a while.
While it's important to have this be accurate, right now I think
we err on the side of showing you as not present. So I increased
some of the timeouts in an attempt to fix that.
(imported from commit 9fd8f432e6684ec1b33d1d932f37caa99c627959)
This might need to change after we merge zev's message list branch, but
it fixes the bug and performs well and isn't a lot of code.
And it has the nice property that it'll only fade messages within the
neighbors range, so there's no need to update the unfading code to
support this.
(imported from commit c562d7335bc5635c960321e1451e4ba0f4452ee9)
It's not quite what the CUSTOMER4 person wanted, but
I think it scratches the itch.
This fixes Trac #1023
(imported from commit 9186499c8f6bacb230a2d1ed6d5ca7ffa7416ac3)
To be fully responsive, we can basically never specify the width of
our container in a fixed number of pixels; otherwise we'll run into
the situation where there's an inordinate amount of wasted space on
our left and right.
So everything needs to change from, e.g. row to row-fluid,
and that has a whole cascading series of changes that that implies.
(imported from commit 7e2771d916f429548c65c0a00fc4c11397054656)
Zev Benjamin
Jessica McKellar
Tim Abbott
Waseem Daher
Luke Faraone
Leo Franchi
Keegan McAllister
Jeff Arnold