It's not so black and white in a world where we auto-scroll at the
bottom, and we've observed that people trying Humbug over-focus on it.
(imported from commit 2057643f179d5d1666cb33438c5a513977197b37)
This is a lot cleaner, and also cuts about 50-70 ms off of page load time in
local testing (with lots of users), presumably because there's less work to be
done by the slow Django template engine.
(imported from commit 257b700238ee5d9a4ae00a53011ed5bce018124c)
This fixes tests that have been failing for me for, well, months, that
I've been ignoring:
======================================================================
FAIL: test_successful_subscriptions_list (zephyr.tests.SubscriptionAPITest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/jesstess/dev/humbug/zephyr/tests.py", line 631, in test_successful_subscriptions_list
self.assertIsInstance(stream['name'], str)
AssertionError: u'Denmark' is not an instance of <type 'str'>
======================================================================
FAIL: test_get_stream_colors (zephyr.tests.SubscriptionPropertiesTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/jesstess/dev/humbug/zephyr/tests.py", line 515, in test_get_stream_colors
self.assertIsInstance(color, str)
AssertionError: u'#c2c2c2' is not an instance of <type 'str'>
----------------------------------------------------------------------
The more comprehensive fix to this is going through both our API and
JSON calls and ensuring that we always return unicode objects,
documenting that, and then testing that more specifically. For now, at
least have passing tests.
(imported from commit ed1875ea1f66c1f1e89f80502c0d6abb323dc489)
This fixes an experienced bug where you couldn't subscribe to a stream
with non-ASCII characters (failing with a UnicodeEncodeError), as well
as many other potential bugs.
(imported from commit f084a4b4b597b85935655097a7b5a163811c4d71)
This is required by Pika 0.9.8. We need at least 0.9.6 for the next
commit; I had been testing with 0.9.5 previously. Anyway this way
seems more correct as well.
(imported from commit bfb9e9e78938073001f70c4d28a5e07cc4ebac32)
They are more meaningful this way -- the fact that your bots that
never log in or inactive users don't have colored streams shouldn't
impact that statistic.
(imported from commit b39debda338cbbad06957bc969b42862a888026a)
This is required if the stream has unread messages in it
(from a previous subscription period). Otherwise the
unread count will be 0 until reload.
Fixes Trac #1117
(imported from commit 8f3d78eb52fdecb52456b0037cc89665c9027fbc)
Previously it was centered with respect to its enclosing div, which
looked slightly off.
(imported from commit da64f33551b500857bb91cb3ece959aafc9b1eb0)
In Firefox, prevents e.g. a slash in a stream name, which we wanted to store as
%2F, from converting back to a literal slash.
There is some appeal to normalizing the URL fragment after parsing, but in
general this way seems better. It may decrease page load time on narrowed
views.
Doesn't yet fix#826; the URL is correct but the narrow is still wrong.
(imported from commit 32e3fa9e968139863f34b9698f1c8b39d06f0c14)
This change could significantly load the database if pushed to prod at
the same time as:
send_message: Save rendered message content to the database.
goes out. So this should go out in a different prod push from that
commit.
(imported from commit 4e5a370bc43defb5083cac3df45c649cf2366abf)
This will automatically fix bugs such as one in which
internal_send_message didn't properly strip() the subject argument
before sending a message.
We change the recipient_type argument to internal_send_message to take
the recipient type name (e.g. 'stream') both to better fit the API and
also because the previous code incorrectly handled huddles.
(imported from commit 78c2596d328f6bb1ce2eaa3eed9a9e48146e3b6a)
This is preparatory for using this new arguments checking function in
internal_send_message as well.
(imported from commit 578e09c50b8a700c019c7dd235b2d9527af34e39)
This cache should save 2 database queries whenever we send a private
message. However, previously it was per-process (which meant it was
mostly useless) and also buggy (it never stored anything in the cache,
so that it was completely useless). Switching this to our standard
memcached setup will address both problems.
(imported from commit 1d807f30704bccf28de33a80523488aedc58a9be)
This fixes a nondeterministic test failure for me.
The first message sent in the test suite appears to get dropped. I don't know
why this is, and I'm pretty sure it was an existing bug. This message used to
be the one disabling the tutorial, which might explain why that didn't always
work.
Regardless, this commit at least makes the test suite usable, and we can work
on fixing that bug later.
(imported from commit 063e40871b9883e3a6dab93a4e0a51c5b2dae4b7)
Previously we only used these caches for Tornado requests, because we
were not updating memcached when e.g. the user's pointer changed, and
so functions like update_pointer would not work correctly.
Now that we are updated memcached when the User and UserProfile
objects change, we can use these for all requests.
This saves 2 database queries on every Django request to the server.
(imported from commit aa5bffd885d14bde38b95e80a226bd5ab66f253d)
This was biting us before when the user would leave a narrow before a
get_old_messages call associated with it finished. Specifically,
search.maybe_highlight_message() would assume a message was in the
DOM when it wasn't any more.
We also have to hide the 'loading more messages' indicator when
reseting the 'load more' status because otherwise it wouldn't get
hidden like normal in the load_old_messages() continuation, causing a
load_more_messages() not to fire when re-entering a narrow.
(imported from commit 4a136dd01305b039c0970f897b07e603b87d5d8e)
This should substantially decrease the amount of server load generated
by the userpresence system.
I tested that this indeed was indeed saving one query on
/json/update_active_status requests on my laptop with 2 users from the
humbughq.com realm logged in.
(imported from commit 03e9d4eb95b9f664d489862684ae162db2076e08)
This cache filling code takes about 5 seconds to run, which means it
will finish before Tornado starts reading from this cache, but if that
were to change, it would be much better to have made at least some
progress.
(imported from commit 60a3420cdb9ddf331d83573a3fdb6be1a5ee5a4f)
Previously we were calling select_related() on Message.client, which
doesn't exist. It seems kinda poor that this doesn't raise an
exception.
I believe this issue was causing us to do very large numbers of
database queries during get_updates calls during server restarts.
(imported from commit b79bd698820fbd9dd82bd61fc175c32cd5ce6d05)
Previously, AdminEmailHandler would crash if the record did not
contain any exception information (e.g. because it came from
logging.error()).
(imported from commit 868ec68f3a57eddbb2c851ecf9894e5eddf21e4c)
Previously when we logged errors using logging.error() but didn't
throw an exception, we would send these totally useless error
humbugs/emails that look like this:
Error generated by Anonymous user (not logged in)
No stack trace available
This change makes those messages include the actual text passed to
logging.error(), which is substantially more useful.
(imported from commit 76a8220ffe66d19cb0ca8ba9d1b42d5ecc4fd511)
But discard any changes the Django response middleware may have made
to anything other than the content.
This allows us to, for example, output our nice database query logging
for get_updates requests.
(imported from commit e1d2fd38ceb4d73ff50bdfaad7c72ddb24d0fe16)
This is preparatory for running the Django response middleware on
our Tornado responses.
(imported from commit 05da8ea9cb663a928b2f98a928f3992aae4f067c)
If the user scrolls super fast, our scroll handler might not catch
the user passing by some messages.
(imported from commit 14cebffcd1321f02443971ac5e1c922db19648ab)
This will mainly be useful in the event system branch, where we want
to actually send a response from a file other than tornadoviews.py.
(imported from commit b7ae9bb9b062215ab44eb5f0a3a72d6baeee1d07)
Since we flush memcached when we do a server restart, the flurry of
get_updates requests that fly in afterwards are all cache misses for
getting the User/UserProfile objects, so Tornado ends up spending
around 70ms per get_updates request rather than the usual 1-2ms.
So this should substantially improve our Tornado performance around
server restarts.
(imported from commit 07b8126bdfd4ff14e4c3362f9eda1fe5fd571c5b)
Our previous code could in theory end up clearing the caches it had
just filled, if Tornado's cache filling work happened to be faster
than the memcached flush.
(imported from commit 48174aadad398fb7a7c917a1df765c1261b12a55)
We create a circular reference between handler functions and our
wrappers for them so that we can pass the wrapper to jQuery.off when
users pass the original handler to us. This reference-counting
system can't break all the circular references we create because
users can unbind event handlers without explicitly naming the
handlers they want to remove (they can remove all bindings on an
element, for example). For now, we hope that this memory leak isn't
too bad.
(imported from commit 9615b5761b4b09ca7ca52c0d847e9b83330373fa)
Previously, we couldn't actually unbind some event handlers. The
problem was that when a user called $.off(events, handler), the
passed handler wouldn't match any that were actually bound because
the handler that was actually bound was our wrapper.
This bug specifically caused the handlers for our idle timers to
never be unbound, effectively never cancelling them.
(imported from commit 48efac954994a05c356d326e64a78ab0ace9fe3e)
We will need this for removing event handlers. This will
unfortunately create a memory leak, but we'll partially deal with
that later.
(imported from commit e439cb44d245e16d2254d1be053b68015a1f4c79)
Sometimes Dropbox shares with /s/ and sometimes with /sh/,
and I'm not sure which controls it, but we should deal with both.
(imported from commit 2222450f25c418b5fbd60ab2c30477467e34c0d1)
Previously, if for some reason pointer updates were not returning from
the server, the client would resend its request every second, rather
than waiting for the previous request to fail before sending a new
one.
(imported from commit d134adc50aabd135c7631913fecab3519aca6640)
It's closer to a presence query than an update, and more importantly
this moves this out of Tornado -- previously Tornado was spending at
least 3ms per recipient on messages sent to the MIT realm fetching all
this data to return back to users. This should save around 100ms per
message sent to a popular stream the MIT realm -- but more
importantly, each such event is 100ms during which Tornado is not
processing other messages.
(imported from commit 134169f0fdcd9f6640fda957edc4a28b07783d8e)
This is required because our migration is going to go in two phases.
When we do the database migration (on pushing to master), we update
all messages at that point. But prod doesn't know about the new
flags field, so any new messages sent on prod will not have the
read bit set.
When we push to prod, we want to re-run the bit of the migration script
that automatically sets read flags on messages older than the users's
pointer.
(imported from commit 961d33e972eac9ada80089bf1b1269c7fb42d56b)
We also needed this when rerendering on append, so moving it into
_maybe_rerender allows the two places to share the code.
(imported from commit 027d99cae7864747cf1ec94c95e8ece495b5c907)
This avoids our repeatedly retrying to fetch a tweet that doesn't
exist from the Twitter API.
(imported from commit b4ca1060d03da21e7e59e5b99e682d2e8457df15)
It's pretty confusing if this doesn't change. In some other world we
could update the fade, but since we're currently only fading on reply,
I think it would be weird to update the fade when you're picking a new
recipient.
(imported from commit 8f77419d443d578068b57f847354ac6da7632ee2)
Previously, we compared the recipients of messages to the message that
you triggered the reply off of -- even if you did a reply-to-sender.
This commit changes the code to instead track what you faded by,
rather than just the message you faded on.
Fixes#1037.
(imported from commit d9e2cb4122501b1bc45e231d4b52c2e7f9284fdd)
Previously, if you renarrowed, all message fading would be cleared
until you close and then reopen the compose box.
Fixes#1024.
(imported from commit 57981ba29ab597c4c84ca6e4e9d04a8284f49117)
We treat these exceptions the same way we treat fatal errors: report
the error message to our server and then allow the exception to reach
the top level.
We could also override document.onerror, but don't. There are a
couple of ramifications of this:
* Exceptions caused by event handlers directly attached to DOM
elements aren't handled
* Exceptions caused by code at the top level that triggers an error
(such as parse errors in our Javascript files) aren't handled
The reason we don't override document.onerror is because the
document.onerror handler has a limited interface and doesn't receive
the exception object. It only gets the message, file, and line
number of the error. Additionally, exceptions that we allow to
propogate out of blueslip trigger an onerror event when they're never
caught. In order to avoid handling the error twice (once by blueslip
and once by the onerror handler), we'd have to encode the fact that
the error has already been handled in the error message, which is
pretty ugly.
(imported from commit 7f049ae519dc198a9f7cfd41fd5dd18e584bd061)
This is to let us pass in the stack trace of an existing exception,
which will be required in a upcoming commit.
(imported from commit 421366a7a01deb770b7620417fb4660769c5db53)
The referenced element where the error was supposed to go was removed
in 66fd42914e4fc33719c4f21ad401748989f20b49. Now the error message uses
the regular compose error message area.
(imported from commit c82a6d863fa327ba982157d0b0607545d7e65cb7)
Previously, if the pointer was high on the page such that there was a
lot of empty space below and the render window was full (a situation
we could get into if we're following new messages arriving), a newly
recieved message would not be rendered even though it would have been
visible on the screen if we had done a rerender. Adding the
_maybe_rerender() call to the end of append() ensures that we don't
end up in this situation.
(imported from commit 925d3cc62e8221b42f1d5ff1788e99c7d07ccc24)
Now that Zev's message list branch is merged, there's no longer a
performance penalty for loading these old messages, and it improves
our narrowing performance to have them loaded.
This code is slightly different from the original commit
93d47710891cfc4db9fa00beaa5ccd10113aa1c3 since the way to access the
first element in the message list and the API for get_old_messages
have changed since then.
(imported from commit f295f892bea9327eb8316225b7b98f0e3b3fdc9a)
This will hopefully make stream privacy more noticeable. We still don't
allow people to modify privacy after stream creation, however.
Since we now use a radio box on the stream creation modal we had to change
the selector used by subs.js to determine if a new stream was to be invite-
only.
(imported from commit 641a4fab74301a9b3ecd4b3859f010dd4ece193e)
I think my previous commit causes the tutorial to run more regularly
in the test suite, so we, in turn, need to be more systematic
about disabling it.
(imported from commit c3805438b0564874a358526d3592b86d147547c0)
We were previously having an issue where the tutorial could
be pre-empted if you got a few messages while you were first
logging in.
I have some reservations about this being slightly fragile, and a
better approach might be to just have a bit that we use to determine
whether or not you've already seen a tutorial. (Or potentially that
checks whether or not you've ever sent a message.)
(imported from commit f8858f64a36bcd25887b76314caff283929f340c)
The issue, prior to this fix, is that the presence list actually
gets drawn *on top of* our "more messages" popup, which is ugly.
(Toggling the z-index on either or both of them did not seem
necessarily to matter, but that's probably because z-index
is subtler than I understand.)
This fixes Trac #1078.
(imported from commit a255aadb1884cf6c659085b26a36d378f680e83e)
When narrowing, we use the selected id in the home view as the anchor,
and if the user is new and hasn't selected any messages yet (or moved
the pointer since first using humbug), their home view selected message
will be -1. Rather than failing to get_old_messages for any narrows starting
from that point, return all matching messages.
(imported from commit 72cfe392d9ac01ed41abc8eadf0f47240e374665)
The new system, called blueslip, makes errors fatal when in debug
mode and only output a message when running in production. In the
future, it could also send user errors back to us automatically.
(imported from commit 1232607c0311e885c8b5a5e8a45ffb28822426e0)
This should substantially improve the repeat-rendering time for pages
with large numbers of tweets since we don't need to go all the way to
twitter.com, which can take like a second, to render tweets properly.
To deploy this commit properly, one needs to run
./manage.py createcachetable third_party_api_results
(imported from commit 01b528e61f9dde2ee718bdec0490088907b6017e)
The jQuery .data() documentation says: "Every attempt is made to
convert the string to a JavaScript value (this includes booleans,
numbers, objects, arrays, and null) otherwise it is left as a
string. To retrieve the value's attribute as a string without any
attempt to convert it, use the attr() method."
(imported from commit f47c1cbb94cb5a98ea9842b00f45c35cd21873f9)
This should hopefully cause the page not to scroll around when we load
a giant block of emoji, because now the size of the emoji is known
before it finishes loading.
(imported from commit f566437edd725f6084c6a10c6230fd36e8d12346)
Our mobile apps (which don't support in_home_view filtering) will move
the pointer to a message that isn't actually in the home view, so we
need to accept that sort of input for now (and maybe in general --
even if we fix our mobile apps, third-party clients may screw this up
too).
(imported from commit ce837e972f0581abd1df44fdb2dd5270dfb9afde)
This commit adds a dependency on python-twitter,
whose upstream is at https://github.com/bear/python-twitter,
and which for now needs to manually be installed on our
servers from the Debian package in sid.
(imported from commit 80cd9f4f59a6f0de6b75ac95e412c69e2a2e2490)
This should make their size totally known to the DOM,
which should prevent jumpiness when they load.
(imported from commit 564d920014f5bc52c217adf54c2f5bab6ba625e0)
We now clean up the stream subscription in more places, but some
historical tutorial streams are still around and if an error or page
reload happens during the tutorial it'll stick around.
(imported from commit 8cf0ebda26bf752c1a23296a4ba85d194bbb3004)
This uses the unauthed v1 of the Twitter API, which is going to go
away soon, but it's fine as an interim measure.
(imported from commit 709a250271321f5479854a363875c9da43e6382d)
For people who aren't on the @humbughq.com realm the tutorial bot showed
up in the create new stream modal but attempting to invite them failed.
This was most often noticed with the tutorial bot.
In the future we should figure out a really good cross-realm story, but
in the near-term we need to probably exclude other people outside your
realm rather than special-casing @humbughq.com.
This closes trac #1059.
(imported from commit df704df0c8ae84b23d9491ce6ab77300831cdd20)
We now add the my_fullname class to the entry for you in the sidebar so
that we can automatically update this element when changing your name.
This closes trac #979.
(imported from commit f1473d6bb6f18810311d42c85d4b57aab9966498)
We also grey out the box to prevent the user from clicking twice.
This closes trac #1030.
(imported from commit eec810e3fbc5b7c9350c2d91e448fb27d4c856f8)
This code also has the side effect of making it no longer possible to
click to the right of a name to start composing a message to them.
Fixes#931
(imported from commit 80e995ccc8ead18b80a39181c47cc94d6063f0f6)
Previously, if a narrowed view started out with no message selected,
one would never be selected unless you clicked on it.
(imported from commit 11c6a1a8d046ec33a3dbea4067c40896be137485)
The message list data structure never had the rendered_idx values
initiatized except via _maybe_rerender (called when a message is
selected). For the narrowed message list for streams with no messages
yet, we didn't select a message (as there was none to select); the end
result is that msg_list.append() will never rerender because it tries
to subtract undefined from undefined and gets NaN in its test for
whether it needs to rerender.
So fix this by initializing _min_rendered_idx and _max_rendered_idx to
valid values for the empty message list (the closed interval from 0 to -1).
(imported from commit 6afecb1569185a842a3a9108cedba7e88f8befad)
I find that I never use it, and I don't totally like our
experience in the app to be different from our users'.
Admittedly, this is a small way in which that's the case :)
Finally, since we do usability studies in @humbughq.com,
the link appears there too, and I'd like it not to.
(imported from commit 1225c4ae79de52fa98b21ce00a6542df76b667ea)
Use less technical subjects, and make them good examples of actual
topics you'd want to discuss (previous examples like 'jQuery' might
leave people wondering "jQuery is a technology, not a topic, why is
that a subject?")
(imported from commit 23b74fe145ed2d325daa94a46e63c42c005b1459)
Prior to this change, any stream message sent by internal_send_message
could only be in the realm of the sender.
This was a problem most notably for... the tutorial bot, with the
hilarious consequence that the tutorial worked fine in humbughq.com,
but failed to start anywhere else.
(imported from commit 33a904a28e3a57e1a2cf9172c2e2a75b50967a50)
Require POST method for /accounts/logout. This has the side effect of
automatically enabling Django's CSRF protection.
(imported from commit 44b1b6ebaadc1c03006e21ae54ac768e31234801)
The typeaheads take some time to open and changing focus on keydown
sometimes prevents them from doing so before the focus is changed.
(imported from commit a8153704e60f3d6c34af55a3de5bd43071a15baf)
This is in response to the following bug report by Evan Broder:
FYI, it looks like if I accidentally tab to the "Formatting" link and
hit enter, it erases the message (and replaces it with a reply to
whatever the selected message is, I think?)
This is subtle and here's why: Suppose you have the focus on a
stream name in your left sidebar. j and k will still move your
cursor up and down, but Enter won't reply -- it'll just trigger
the link on the sidebar! So you keep pressing enter over and
over again. Until you click somewhere or press r.
Net-net though, I think it's a change worth making, because
it's good for keyboard accessibility.
(imported from commit b65bcc0abbc751718bb03d418c03961b9ed9e42b)
I.e. if you sent a stream message, Tutorial bot will reply to that
stream, and if you sent a PM, Tutorial bot will reply with a PM.
(imported from commit 05b7d1848f6eb1f70dcd5fb365fba9daee52a5dd)
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)
With this change,
pkill -SIGUSR1 -f runtornado
will dump the stack and SIGUSR2 will enable an interactive debugging
session.
This fixes#613 for Tornado which was the original motive for that
ticket; I'm not sure whether we want to do this for our Django
processes as well, but it would be easy to do so if we did.
(imported from commit a7de7c6070f4bf0404bed6f434e6a6b291d66a26)
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)
Otherwise we're by default testing the phone size layout, which
probably isn't what we want the default test setup to be.
(imported from commit a76b2d51c18824b0a5f6342cce848aca87dda15a)
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)
This cuts about 6 seconds off of the test startup time on my laptop.
The other startup costs are about 1 second for the server to come up
and about half a second for casperjs to begin executing tests.
generate-fixtures now takes a '--force' option that can be use to
force a regeneration of the test database.
(imported from commit 1f473507502f0edf159b2638abb392d9357eb46f)
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)
Previously, using e.g. the search box would be problematic because the
compose box closing event might fire, blurring the search box, in the
middle of whatever you were doing.
(imported from commit cc045f5a6a7b7fbf72848da14b6fcd3df39cab05)
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)
I don't actually have this problem, but Jessica et al tell me that the
tutorial bot's messages sometimes arrive too late for them and it
interferes with the test suite's ability to run correctly.
I add a delay which should hopefully reduce the occurrence
of this issue.
(imported from commit 0f41610ada7dd49d71f0deef034e014164357197)
Even though they look like images, they're not -- you need to
append ?dl=1 to get the image version.
(imported from commit 2a05e7c58f475c908687110d9191f8709425c660)
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)
This code adds a dependency on python-django-auth-openid, installable as
django-openid-auth from PyPI.
On prod, one needs to run a syncdb in order to create the required
tables. A database *migration* is not required, as these are new tables
only.
(imported from commit c902a0df8d589d93743b27e480154a04402b2c41)
Jessica McKellar
Keegan McAllister
Leo Franchi
Waseem Daher
Tim Abbott
Jeff Arnold
Zev Benjamin
Luke Faraone
Reid Barton