We currently disable hotkeys if the focus is on a textbox or
button. Hidden buttons can still be in focus, so blur the search
buttons before hiding them.
(imported from commit 5fdab34ad9931ea5ea2ad1827b36dfe4c02d8797)
Whenever we use a typeahead, we should use the escaping highlighter
unless we're explicitly going to put sanitized content in it.
(imported from commit 33086327fe56a7bcbbbf8a08fe3f39800b195e75)
This also cleans up the autocomplete source specifications,
making the three typeaheads all look fairly consistent.
(imported from commit e72655d715db74cfc9ab45b51e7e2ff9e8ea84c5)
This makes the diff a bit cleaner.
Revert "Interim measure: Escape fullnames as well."
This reverts commit a634e6ac39ea337be499889b3ff64b3c4f4fcccb.
Revert "Interim measure: Escape subject names before they go into the typeahead."
This reverts commit 806bc719ab296ec0fe299b33c7aa6767a0c71b9d.
(imported from commit 5a579e3535846b2bc612cf03e43c562c83119812)
While we're at it, fix the fact that we're currently not adding
entries to the subscriptions_table at all when we do
subscribe-and-send.
(imported from commit 99bf574a4a296463e562a44186e2282654464542)
So that the 500 error view will render properly, even though no variables are
set. We keep the variable static_hidden, which by design is not used on the
500 page.
Fixes#240.
(imported from commit 3c7534f896479b7d7edbe5ef13958481e169a13c)
I'm sure this problem exists in a latent way with stream names and
email addresses as well. Once I figure out a general way to fix this,
I'd like to go back and handle these three cases in a cleaner,
symmetric way, but this'll do for now.
(imported from commit a634e6ac39ea337be499889b3ff64b3c4f4fcccb)
This is problematic because if your subject name is <b>hi</b>,
selecting it from the typeahead comes back with:
<b>hi</b>
which obviously isn't really OK.
(imported from commit 806bc719ab296ec0fe299b33c7aa6767a0c71b9d)
This is what caused our server to hang when receiving certain messages
over the last couple days. It was introduced by me making in the
assumption that doing the same thing we did after validate_notify
failed was a correct way to immediately return from
notify_new_message, which it was not. The code of validate_notify
actually finished the handler in the event that validation failed,
which isn't "correct", but did not manifest in a visible problem.
The correct way to trigger an immediate response from a tornado view
is to just return the value, not call handler.finish() and then return
None.
Similarly, the correct way to trigger longpolling from a tornado view
is to either return None (or equivalently, / drop off the end of the
function) or return a generator.
(imported from commit 5b931248b4650fc88d5d68f5936a95f19e097af9)
Tim Abbott
Jessica McKellar
Waseem Daher
Zev Benjamin
Keegan McAllister