We suspect that these seem to be causing a regression where scrolling
in narrowed views gets really sluggish, but we haven't totally been
able to figure out why since it's challenging to reproduce locally.
(It currently manifests itself on staging but not prod.)
So for now we'll back them out. Here's the full set of things:
Revert "Cause update_floating_recipient_bar to get called less frequently."
This reverts commit a6c1518c4001a2dde44d7b512236795da3ccd351.
Revert "Remove double-scroll in un-narrowing code."
This reverts commit 3dde6c27ffa1e8afa1a084b1b2baee3bc0512962.
Revert "Reset our scroll position if we change our hash to "#"."
This reverts commit 925b44d770c96dafaabebc9e0114f9a3b8f53c4d.
Revert "Properly update floating subject bar when you are at top of page."
This reverts commit 6633cc8a81aedcbb31b30d7c1f27816f8808c700.
(imported from commit a273730581cef30c33bedf701659ee084434f8ad)
Note that on local dev servers, this will print out every half second, as
Tornado polls for file changes for autoreloading. In production it will only
print out when network events occur.
(imported from commit adfe88879e4e446b7dfa6ee69e0a9ad013e9c4d4)
This should remove a database query invoked from Tornado by our
decorators in the common case.
We use hashlib.sha1() on the key because memcached doesn't support
keys with whitespace in them.
(imported from commit 351ef4c76bc68e2d53f0e7ddca91dcf95e7bb2a6)
Previously it wouldn't work due to using the wrong port numbers.
This commit also has the side effect of fixing the fact that our
frontend tests would send real emails and log events to the real
message log.
(imported from commit f2cf400e6061c089627acba2759d588981ecf5bb)
This should save a database query when we later need to access fields
such as the user's realm name in format_updates_response.
(imported from commit ceef726db9e917cfb0b47061130d7299ee64890d)
This code is from a previous protocol where the users array was posted
as a comma-separate list, rather than encoded via json.
(imported from commit 3a2edfcbf250a7eef305b2e98018c1361cc2fffe)
This is for consistency with the rest of our code dealing with message
delivery, which always uses the user_profile_id.
(imported from commit 5bf10bb9b994b0a98d3a22bd0bd86e542ab8a2ee)
Putting update_floating_recipient_bar in the old location caused it to
be called on every single keypress, which is unnecessarily
expensive. Instead, just call it once when we think we might actually
need it: after initiating a narrow.
(imported from commit a6c1518c4001a2dde44d7b512236795da3ccd351)
Watching new users, I've seen them not notice the pointer and
mix. Give them a little more hinting about what message is selected.
(imported from commit c98e22dcef881ed7400071ec438a6e91d6cd3d9e)
select_message_by_id with then_scroll: true already recenter_views
on the selected message; no need to also call scroll_to_selected.
(imported from commit 3dde6c27ffa1e8afa1a084b1b2baee3bc0512962)
Changing the hash to "#" causes Chrome to jump to the top of the page
on Mac OS X. This commit doesn't actually fix any bug, but it
is necessary for my *next* commit, where otherwise you'd have to
ensure that the scroll code came *after* the hashchange code.
(imported from commit 925b44d770c96dafaabebc9e0114f9a3b8f53c4d)
There's this very edge-case issue which is: if you go to the top of
the page and narrow to something other than the top message, the
floating subject bar does not update.
Why? Well, the way that the narrowing code works is that it sets up
narrowing and then calls
select_message_by_id(target_id, {then_scroll: true});
so that our selected message is in the view.
This in turn calls select_message, which calls recenter_view as
appropriate. This usually causes a scroll action, which in turn causes
the floating recipient bar to be updated.
But when we're at the top of the page, recenter_view doesn't need
to scroll at all! So the bar remains un-updated. Here we explicitly
update it to guard against that case.
This fixes Trac #651.
(imported from commit 6633cc8a81aedcbb31b30d7c1f27816f8808c700)
I don't view this as a complete solution to
Trac #466 - Make the fact that you are narrowed more apparent,
but it's a start.
(I think a real solution would have to give you something that
helps you make the determination of "Is this view narrowed?"
when you come back to your computer, and this animation does not
help you do that.)
(imported from commit eb3646f3f3a4e25a43266e9146308633fd997eb2)
This commit just moves around some lines so that the code that
hides the main view and shows the filtered view, or vice versa,
are together so that it's easier to reason about the sequence
of things that's happening.
(imported from commit 7e99f45293c0e1a4cdfa1a08f41f8c770c370d6c)
This used to be a button that let us un-narrow, I guess.
A git grep for it after this commit turns up no actual
references to it.
(imported from commit 05acb4bb40da1b032f548c511fbae5b2b20874a8)
And change the color to a more thematically appropriate blue.
The shadow pointer is sort of confusing; we should really provide some
different sort of indication that your pointer is potentially moving
on narrow-and-unnarrow. (I think my fade-in-fade-out later in this
commit series is a not-bad first crack at this.)
Resolves Trac #472 - Dual pointers in narrowed view can be confusing
(imported from commit 2450517d99de85ade1c0e98c5510b59e70282451)
tornado.web already does this, based on the setting of the 'debug' kwarg.
Dropping this in production saves us waking up twice a second to stat()
a bunch of files.
We already explicitly restart the server on deploys.
(imported from commit 283bb0da609acb2699a04111a74c13224fe5124c)
If you narrow to a view that only has one or two message, sometimes
the grey box gets cut off and doesn't go to the bottom of the
page. This fixes that.
(imported from commit 55724d03aa30922d91bd33fab4447d889be78889)
CasperJS can't handle them; window.webkitNotifications.requestPermission()
throws a type error. We can revisit this when we want to write tests for the
notification code.
(imported from commit 90f4d6ac3ddb387e74051b9af2c230698fa94479)
We apparently cannot rely on Iago to consistently be subscribed to
"Denmark", so make this determination some other way.
(imported from commit 2a75b345c2d82097ab44538942af89536aac09ed)
Previously, if last was None, we wouldn't check dont_block,
server_generation, or any of the other reasons that get_updates might
return immediately, and just unconditionally entered longpolling mode.
In the process, this reorders return_messages_immediately to have
fewer cases and thus be easier to read.
(imported from commit 67803b8bfc7d9c9c1a4d6916eb2fb62664fb35a9)
This check was a workaround for the fact that the browser client
submitted a "last" value of -1.
(imported from commit a668f6a4e7a0c027f1214166a9bbf40d29b5daeb)
We shouldn't deploy this change until strictly after we deploy
"Fix website improperly submitting a last value of -1."
or we will break website clients.
(imported from commit 7f682ab0f7060b677f53f0a0073faef216f45d00)
This was done using instructions provided by the South authors:
<http://south.readthedocs.org/en/0.7.6/convertinganapp.html>
This adds a dependency on python-django-south >=0.7.5. Now when you are
reinitializing the database, you need to run "./manage.py migrate --all"
before running populate_db.
When deploying this commit onto existing servers, you need to run these
commands manually:
./manage.py syncdb
./manage.py migrate zephyr 0001 --fake
./manage.py migrate confirmation 0001 --fake
These do *not* need to be run on new databases, only on existing ones.
(imported from commit f24cff421a6be9ab9cf4c4342565c484ac336e2d)
This view lives at /accounts/accept_terms, and (after getting an acceptance
from the user) sends an email to all@ documenting the acceptance.
(imported from commit 8f64286ab02887fd6544fa274b2967f6499b6dbc)
So, I got annoyed that our test suite was taking forever to run:
real 2m13.443s
user 1m32.630s
sys 0m3.748s
Some quick profiling determined that the test suite is spending all of
its time loading the fixtures files (zephyr/fixtures/messages.json)
that it loads for each test case (3s to load that for each test case).
To improve this situation, I cut out from the test database used by
the test suite most of the users, subscriptions, etc. that aren't
being used directly by the test cases. The impact is a quite
significant speedup:
real 0m15.176s
user 0m9.161s
sys 0m0.508s
We're still spending over a quarter of a second per test, which isn't
great -- but this is at least no longer unbearable.
This commit doesn't make any changes to the populate_db output if you
don't pass the new --test-suite option.
(imported from commit 2334ba5399b33edab3d29ff269fde4ea77ccd48e)
Jeff Arnold
Waseem Daher
Keegan McAllister
Tim Abbott
Jessica McKellar
Zev Benjamin
Luke Faraone