This simplifies a bunch of fragile resizing logic in our code,
and also addresses the Chrome Canary bug where clicking in the
searchbox causes the navbar to get huge.
This fixes Trac #764 and Trac #1039
(imported from commit fc8c3995109de384b71dfba2b986a8500ff7f08d)
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)
Previously we defaulted to current_msg_list.selected_id, which was
fine if you were narrowing from the home view, but if you navigated to
a narrow with no messages in it and then clicked something in the left
panel or used the search bar, it wouldn't work.
Fixes trac: #870.
(imported from commit 5ee480d8d2b1fb300fccbe75e04135d977a1fc07)
The first change might somewhat address users asking "does it matter
which one I click on?" by not being specific that one should click on
_this message_.
The latter I think addresses a small confusion I've seen where people
try try to hit tab before starting a reply.
(imported from commit 708acdf4d4c80713795b96b1a59d681a88604670)
This is the fix for https://trac.humbughq.com/ticket/958 (Narrowing
moves the pointer) proposed by jhurwitz. Currently on master,
narrowing can cause you to end up wildly out of place.
This branch is not a perfect fix -- you do end up with the pointer on
the expected message after the narrow, but that message is centered on
the screen; better would be for that message to not move at all.
(imported from commit b89e4e2c896add20eceb609db46c46dc025fdce2)
If this is not the case, then you can't actually click the
"Press Enter to send" checkbox in the composebox (or anything
in the space occupied by where the popup will go).
This actually is not a perfect solution because that area still
remains unclickable for anything else. (In particular, for example,
scroll a message's "Info" link and then try to click on it -- you
can't! The click is captured by the #notifications-area div.)
http://www.vinylfox.com/forwarding-mouse-events-through-layers/
proposes an alternative more general way of dealing with this,
but it seems like a real pain.
This fixes Trac #1017.
(imported from commit 9cfde1cfff63ab32ae7d129980c47567e221eac3)
This import strips other icons we aren't using from the CSS definitions and
fonts.
Licensed under MIT.
(imported from commit 02cc2681a1cf44107444b6fe70420afca6950ae2)
In Safari only, if you narrow to something and scroll all the way back
up to the top and then unnarrow, your position actually remains all
the way at the top!
We explicitly call a "scroll_to_selected" as the final step of
deactivating a narrow, which brings this message into view.
This doesn't seem to be an issue on Chrome and Firefox, but I'm not
quite sure why; something about the sequence of events.
(imported from commit fc73640351be03c02eb2f3c8a23de3327723f002)
By splitting up all_msg_list and home_msg_list, we can properly add/remove
streams from the home view without having to jump through hoops.
(imported from commit 92767197759f7519197dfc58be951b60fa823fbb)
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)
Waseem Daher
Zev Benjamin
Jessica McKellar
Tim Abbott
Luke Faraone
Leo Franchi
Keegan McAllister
Jeff Arnold
Reid Barton