Made the 'Users in chat' header above the overflow area, so it always stays on
top. Now using `visibility: hidden;` instead of `display: none;` to show/hide
messages/users so that nojs css animations don't reset.
This adds a field 'watching' in `user_for_websocket` that's True iff WATCHING,
False iff NOTWATCHING, and None otherwise (since clients don't need to know if
a user is tentative or absent). When the value of this field changes for any
user, they get added to the update buffer (like with any other change).
Removed race condition in `t_sunset_users`: `broadcast_users_update` was being
called *after* a user was removed from memory (and for each user being removed,
which was redundant). In that scenario if there's a user in the update buffer
and `t_sunset_users` wins the race between it and `t_broadcast_users_update`,
then when `t_sunset_users` calls `broadcast_users_update` a KeyError would be
raised since the user's already been removed.
Fixed unintended behaviour of `t_sunset_users`: it was removing users based on
the result of `is_visible`, so users who were actually tenative (as opposed to
absent) were being removed.
This reorders the elements so the comment submit input comes before the
captcha image input (that reloads the form). If a non-submittable input
is active and you press enter, Firefox chooses the first submittable
input and submits the form as if that input were clicked. Before this,
pressing enter on the captcha answer input would reload the form instead
of submitting the comment.
By default the buffer is exhausted every 4 seconds. This should defend against
a potential DoS against clients with JavaScript enabled. Before this, any
request with no token would generate a new user and immediately broadcast the
new user to all the websockets. It's best to lock down as much as possible the
number of places a client can cause the server to broadcasts to all the
websockets.
Any single-user tripcode update deleted all existing tripcode display css
rules, because of one place where there was `stylesheet_color` (the global
variable) where it should have been `stylesheet` (the function argument).
Also now using proper js function named-argument syntax. (Why is it legal
to declare global variables in the arguments of a function call? What?)
In JavaScript, declaring a global variable in a function call is not OK:
> function f(x) {
... console.log(typeof n);
... return x;
... }
> f(var n = 42)
Uncaught SyntaxError: Unexpected token 'var'
> f(let n = 42)
Uncaught SyntaxError: missing ) after argument list
> f(const n = 42)
Uncaught SyntaxError: Unexpected token 'const'
Unless of course you elide the variable keyword:
> f(7)
undefined
7
> f(n = 42)
number
42
> n
42
Not even once.
Incoming requests are handled in anonstream/routes/. Route handlers
mainly depend on files in anonstream/, which in turn depend on files in
anonstream/helpers/ and anonstream/utils/. Utils are pure functions and
helpers are almost pure functions; they don't mutate state but they
do depend on the global app config.
n9k