This essentially reverts d900957e468815bcb99de67d570dfd7ce4413220.
This code was consuming up to 50-100ms per client recipient of a
message, so for any messages that would go to 50+ browser windows /
mobile devices, it would take several seconds to run, during which
time Tornado would be completely blocked.
In the future, we can re-fix #174 using a cache of recently delivered
messages, so that this code block doesn't go to the database and thus
can run instantaneously.
(imported from commit bdfa1664210429411737f70cde54ab5a56525341)
For whatever reason, specifying a percentage for bottom_whitespace
seems to cause issues in some browsers, including Firefox 17
and the Firefox Nightlies.
This is a bit confusing to me, since bottom_whitespace is basically
immediately resized by resizehandler initially anyway. But hey.
(imported from commit 93da101edeb6f16b01a92aed775e9117c0295086)
CSS height percentage was not working because parent div has an undefined
height, so instead it is set to 40% of the window height on resize (and initial
load) via JavaScript.
Fixes trac ticket #24.
(imported from commit 2c6a8489585c4bf70c44469ce8628264ec3fbc36)
Variables like stream, subject, and message were getting cleared from the DOM
when the compose box was closed. The "Create and send" button was trying to
access these variables to create a new stream, but they were gone. Now they
are cleared when a new compose is started.
Fixes trac ticket #568.
(imported from commit 39ccaaeacb3f92f4b1d771be1b34ff660e0d5883)
We now encase the request info in a preformatted block, which ensures we
won't accidentally trigger any formatting while being reasonably
space-efficient.
(imported from commit 7c69a6ff2b2abd9474aae08b5ba608bcb40cec56)
This should really be handled on a per-method basis, but in general we
don't want "password" or "key" to be sent to us for security reasons.
Addresses trac #569.
(imported from commit 1c246fce00f3740977c595641341ee36eb5ed831)
We were submitting a 'last' value of -1 to the server at startup,
which is invalid but normally ended up being OK because the user
usually had no messages whatsoever or had last be updated via
get_old_messages before the get_updates call went through.
(imported from commit df55ac1cdac443721c06ebed94a1c4b3ec7af2d1)
Importing zephyr.views here has the unfortunate side effect of
creating Client ids 1 and 2 automatically (via decorators.py
instantiating the two client objects it makes), before we go ahead and
delete all objects in the database as part of the populate_db startup.
(imported from commit da03cb7606334d5926e42f422ab94d1c884937b9)
This was not totally effective, and with the previous commit it is no longer
needed.
This reverts commit e86c0b653669cf86b0d8956c2c85eb7610fc342f.
(imported from commit 0de5bfec87147b1336f6f79c33d4e32493e1e508)
Previously, the StreamColor restore code didn't properly account for
the fact that most user subscriptions were in pending_subs and thus
not yet in the database.
(imported from commit 2e28c5a68aa045494b9336d7114c23f5c3706c28)
By processing UserMessage objects in batches as we go, this avoids
consuming a large amount of memory that is linear in the size of the
messages log.
(imported from commit 0c42d97f0863da9c079836c60bebcbaeec59f849)
This was causing issues with our ability to unsubscribe from
streams with " in their names.
The solution here is a bit hacky, since it depends on the JavaScript
being fairly aware of the layout of the DOM, which is not great.
But it works.
This fixes Trac #328.
(imported from commit a1b6c8e1f3a9daacdc48920a195717aa89b3a9a9)
This fixes Trac #522, which previously prevented you from
subscribing to a stream named
'"]'); alert('hi');
This does not fix#328, which is that you can't unsubscribe
from 'Waseem', among other things.
(imported from commit 869063cafa9e7e988aea993d072ca1ad880bcee1)
Unfortunately, this doesn't actually give us much performance gain
either; it's not really the calls to 'find' that are taking any time.
But I do find this a little cleaner as well.
Simply initializing 100 colorpickers with our options takes about 700ms.
Initializing ~100 colorpickers with the total default set of options
shaves that down to about 300-400ms (though obviously doesn't quite
achieve what we want).
(imported from commit 7084b35fb6e77600edfcdcfcc2761a11e6f38c03)
Rather than calling the template generating code once per
subscription, let's just do it in a batch when possible.
With about 100 subscriptions, the "fetch" call takes about 800ms to
render (while testing locally) both before and after this change,
which is somewhat disappointing.
But this *is* cleaner!
(imported from commit 9ba8819524da86c00a2508349be0ea0ddd48606b)
This is useful when testing the sigup workflow, as this script enables you
to run through a MIT signup without manually creating a new inactive user
in the database.
(imported from commit c22649cc7c561c2fbe8682d1b17d7e5aba9ac04e)
Hopefully this will make things slightly more discoverable;
the previous solution (putting a prompt in the initial text)
was not that discoverable.
(imported from commit f6a7fce1bfd27bda412522768e981b2ffc39f474)
This fixes https://trac.humbughq.com/ticket/546.
It's a little unpleasant that this special-casing lives in hotkey.js
-- instead you could imagine doing something where there was a whole
special set of hotkeys when a search is active, like we do with the
composebox, but this gets the job and is probably simplest.
I would have written this as a case that just falls through in the
else condition, but jslint doesn't like that.
(imported from commit 65a1b8aa1efc356b6690dc177058a4fb9e12745a)
We previously were only using it at the first loop through all
messages, which meant code accessing the message type copied from one
place to another would break (potentially subtly), because things
would work if and only if the very last message happened to have the
same type as what is expected in the relevant piece of code.
(imported from commit ad9ce5efdb200e0c0d5c3ffa6db33113fdad8c5a)
This addresses Greg Price's feedback in #527. We now distinguish
between normal pushes, force pushes, and branch deletions.
(imported from commit 0fab6055f63ffc7e6df283b8bb8ed9971000e6d5)
This cuts a 30s operation down to about 2s on my machine.
And also move the code to run before we print the "done" message and
have logging for how long it is taking.
(imported from commit 2f20f8ca3fee714735a50fe6c6cfd630df452768)
This is syntax like
Here's [a link][]
[a link]: http://google.com
This is not very useful for short chat-style messages. It will confuse users,
especially because we don't document it. And disabling it saves the effort of
applying the same link fixups as elsewhere.
(imported from commit c23391465486db545302b79c084b4f9cd5cdcc6a)
This was a really cute bug where our layout messes up if you resize
the page while "Subscriptions" (or to a less visible extent,
"Settings") is active.
The problem here is that we compute the size of the top navbar
based on the size of main_div -- but when main_div is hidden,
it has a width of zero!
We need to instead look at the width of the pane that *is* active.
Resolves https://trac.humbughq.com/ticket/216
(imported from commit adbef00d190845f90c5cfdb46df4ec7b703635ef)
feedback-bot and zephyr_mirror will need to be updated and restarted
when this is deployed to prod.
(imported from commit fe2b524424c174bcb1b717a851a5d3815fda3f69)
Ironically, I think this might've bee introduced by
commit ca35321c02d5e79e4f9c439a662805c016a333ed,
'Fix "resizing window breaks in Firefox" issue'.
Basically, when the window is 776px wide according to
window.innerWidth, that's the width not including the
scrollbar. However, in Chrome, the media query seems to ignore the
width of the scrollbar, so from the CSS's perspective, the window is
actually ~766px wide, so it goes into condensed mode.
But the rest of our code doesn't, which causes the break.
A bit more on this browser-specific difference at:
http://www.456bereastreet.com/archive/201101/media_queries_viewport_width_scrollbars_and_webkit_browsers/
So the issue we have is, to match the CSS's behavior:
* In Firefox, we should be listening to window.innerWidth
* In Chrome, we should be listening to window.width
We fix this hopefully once and for all by using window.matchMedia --
aka the exact same query that the CSS itself uses. As discussed in my
last commit, this feature is unavailable in IE<10, so we provide a
potentially more fragile fallback, i.e. what we did before this
commit.
(imported from commit d8e6425b81c90c8e0fdda28e7273988c9bfd67ec)
Make it so the image is not squished, change some paragraphs into
headers, and wordsmith a bit.
(imported from commit 81295e1a8ddd4f1ecd4532c4dfb8a38467bb530e)
This is an interim strategy for user education that'll be a stopgap
until we build something in the app itself.
(imported from commit 9022d4ceffca98e127f7045f73c012857fe6fc54)
When we changed our stream name model to treat stream names as
case-insensitive, we didn't update populate_db to do the same.
This commit makes that update, which is to use the lower-cased stream
name for dictionary lookups and deduplication, but the original-case
stream name for actually creating streams.
(imported from commit fc32ec75a5ae286bce7ec86c6e6fb6893888cbd0)
bulk_create_streams was taking about 10 seconds to run with prod data;
this should be a basically immediate operation. The cause was a
missing select_related on one of the loops through all streams.
(imported from commit 8b82f0c41facc3999bb699dbc350708ac69797e9)
in the narrowed view, not messages older than the oldest message in
the home view
Tim provided most of the code for this patch
(imported from commit ec0bbfd344cac351f56a456fc560848603721135)
The transaction.commit() line inside the except IntegrityError clause
doesn't work unless we've entered transaction management.
(imported from commit 2ae520e05c9a19ec35af7c244631b01d4b9598d6)
This makes subscribing to zephyr classes for the zephyr class
mirroring bot a lot faster, since we don't need to subscribe to the
third of our streams on which no users will actually receive messages.
(imported from commit 029b7fb260b480db5599e3c9f9effc502f6d8b59)
The tabindex on this link doesn't actually do anything, because of the Safari
tab workaround. I added it anyway in case we remove that workaround later.
(imported from commit 11f31f2561907300b350c11732be88589d736f94)
This fixes a bug where you could click on the already-selected mode button, and
it would switch modes without changing which button is selected.
(imported from commit 263ee0b52ba844c52a3a60968bb1bbff73482412)
With the removal of process_compose_hotkey, the state machine now has only one
state. Everything else is based on things like "is a text box focused right
now", which is probably a better approach.
(imported from commit 0e39c03956d28e30d2bdbf3b285410ad0cacca3e)
load_old_messages cares whether it is acting on behalf of a narrow
(for_narrow) not whether it is acting on behalf of a button push.
(imported from commit 16c00e015478f94f0631e211a92a7066a38135a8)
During long-polling mode, we were not passing the server generation
number back to the client even when they requested it. This was
causing the web client to initiate reloads every time it got a
non-immediate return from a long-polling request.
(imported from commit 66c16bf5a1c18bdd975b09d672ebdb4db8d4755d)
This restores the time-travel functionality and fixes Waseem's laundry
list of problems with its original UI.
(imported from commit e30e02c25af994435adb815d26284b3669c945a4)
This was causing glitching where if you narrow so that zfilt has only
one message, and add messages on top (e.g. via get_old_messages), and
then add messages on bottom (e.g. by receiving one), we end up with
the bookend row missing. One can make this happen with narrowing,
but, this situation happens every time with time travelling.
(imported from commit 71d85980d8aa9431a17b33e9e5111fd3f76cecf3)
authenticated_api_view and authenticated_json_view call
update_user_activity with a client generated using
@has_request_variables with a default of e.g. get_client("website").
Because that get_client call only happens once on importing the
module, if those client objects didn't exist previously in the
fixtures, then the first test will generate objects with ids 2 and 3,
and then the second test will dump the database, restore from the
fixtures, and then eventually generate client objects with ids 4 and
5. But since the default values were only computed at module load,
we'll still end calling add_user_activity with client objects with ids
2 and 3, which don't exist in the newly restored database.
Fix this madness by just making sure those two client objects exist in
the database.
(imported from commit d940e129d077a560d9a0f96ec3daa2e16ce21c8b)
If the message doesn't exist, rows.get returns an empty jQuery object, not
'undefined'.
(imported from commit 40620f3e4853a662cb93939bf7f0695f81298777)
Previously, if the client was not interested in pointer updates, they
would still return early from get_updates() when the pointer was
updated.
(imported from commit ef9d8b5678b7e72f799840148577651ee10d47ad)
Realistically, if there is a pointer update, no other client is going
to have the same pointer. If they do, the client can ignore the
update.
(imported from commit ca2db60ed7a7c5e4b50a9fa8d350985460922a50)
This is so we only send a single pointer update when the user scrolls
through a bunch of messages at once.
(imported from commit 20d239d7179e5f57ada99968361a0f9b7b18c591)
Keegan McAllister
Tim Abbott
Waseem Daher
Jeff Arnold
Tyler Hallada
Zev Benjamin
Luke Faraone
Jessica McKellar