Documentation variously says to disable on the form or on the input box, e.g.:
https://developer.mozilla.org/en-US/docs/How_to_Turn_Off_Form_Autocompletionhttp://msdn.microsoft.com/en-us/library/ms533486%28VS.85%29.aspx
However, at least in Chrome, disabling on the form produces an ugly
"This webpage has disabled autocomplete" message if you try to arrow
down on an input box as if there were suggestions, so I've just put it
on the input element. This still works on recent versions of Safari
and Firefox.
(imported from commit b47f438d6e1d930d7d6871070858c97c6479a0ae)
We weren't listing to compose finish events during reload previously,
which meant that finishing a message was not handled in the same way
as canceling a message.
(imported from commit 4f2576121a8b5354c94348bc2896a2db8c4be000)
This would only happen when you hit enter directly, instead of using
the search up / down buttons.
(imported from commit 90301f64b3f24e91c103342bd6a7f1b3e61f8928)
I am pretty sure there's no point to using a hash at all. But until I hear
back from the author, let's at least make sure we put as much entropy into the
hash as we expect to get out of it.
(imported from commit 51a231adeab014cc1af8cb67e89baf06e0a1f593)
This is the behavior specified by Django. Since this was broken before,
our CSRF protection had no effect on Tornado views other than printing
a warning message :(
(imported from commit 7975d3c9b6c18915f917ac2da4592a55f6b6a658)
Eventually this should go to the staging server, and we'll have a separate
process to migrate changes from there to production.
(imported from commit 2a712758844524fdf2f23f798baf6b607d056b9a)
Per the docs, these are only meant to be used on arrays of DOM elements.
jQuery might one day assign a different meaning to arrays of strings,
and then we could have some security issues or weird breakage.
(imported from commit 545eee1e9c6955556d5c4bda30cd6db0dce19c60)
Instead we infer this from narrow.active(), with the ability to override during
the narrowing procedure.
(imported from commit fab9c6861f19aedf0ee8af094c1ef4e8a0a73d80)
The get_profile API call now returns a client_id, which an API user
can pass to update_pointer and get_messages (note that clients still
need to pass a pointer argument to get pointer updates). This
client_id is currently the equivalent of the website's session key,
but the website might get client_ids in the future to distinguish
browser windows.
This commit differs from 88f6cf0033c849af88d1b99da3bdc2148dfbb6fe in
that it uses request.POST.get("foo") instead of request.POST["foo"].
For some reason the latter triggers CSRF errors.
(imported from commit b2a4a7322d16dbf241cd6eef146621c79d84cafc)
This reverts commit 88f6cf0033c849af88d1b99da3bdc2148dfbb6fe.
It seems to have broken API users.
(imported from commit 2f861ebc016076547092421f87dbcac00a65e2f6)