This makes it easier for mobile clients to use the API by enabling them to
present the user with a familiar username / password prompt, rather than
by asking them for their API key.
(imported from commit 6ed06cfe86f87e7aef54a4be7835fb7bf8d7f209)
The key property is that we never reveal the non-public directory name
4nrjx8cwce2bka8r to a not-logged-in user. This makes it less likely that
random people from the Internet will download all our client code while we're
still in private beta.
(imported from commit 7428e847e0a1a34152cb6dc2b677c1b47290c202)
Previously if you tried to send to "a b", we actually ended up trying
to send to "a%20b", since we were url-encoding the stream name and
then not properly decoding it.
(imported from commit 307d2999bd309e47fc654ae4422ab4372edde064)
PgUp, PgDn will already call the scroll handler, which will
of its own accord call keep_pointer_in_view.
(imported from commit 8b6e53eaeda91d0f35775de72e16d63dc6c8340b)
We'll use this internally for the commit bot. We might eventually disable it
for external users.
(imported from commit 3136cd9faadc6b81355889d2ee6472985da87fbe)
That andSelf is only necessary if a .recipient_row were immediately
followed by a .bookend_tr, which, I don't know, after a redesign could
very well be the case, so let's guard against it now, especially since
our performance on scroll is currently pretty good.
(imported from commit 1011555fbfd30943b4aa917997d6e35bcce959fc)
In my limited trial, this sped the call up, on average, from
0.507ms to 0.473 ms... so, admittedly, not a lot.
I think this is a little conceptually cleaner, though, and it handles
the common path with the least work, which I like.
(imported from commit c8b827a2e8111fbdd54bcabe05ac36f64523c466)
nextAll/prevAll walks the entire DOM, basically.
This code only walks the DOM until we find a new .message_row.
This speeds up the average time of a call to this function from about
6.38ms to 0.678ms, in my benchmarking.
Admittedly, the whole outer loop here could still use some
optimization, if we want to; do we really need to call this 1000
times?
(imported from commit 852e2f660a16f8cfd7be35d3271aedb1ac481663)
http://api.jquery.com/first-selector/ mentions that using ":first" in
query selectors can be a little slow since we can't use the browser's
native querySelectorForAll implementation.
In my tests, this cut the average time down from 6.70ms to 6.38ms.
So, not great, but this function is most frequently called
many times in a big while loop, so, better than nothing.
(imported from commit d7725edd0c81431829fe353c6dd2bc61b1de6b19)
If the client is not composing a message, we can just force a page
reload. However, if he is composing a message, we must preserve that
message while still reloading as soon as possible.
We take the following approach: if the client has not completed the
composition after 5 minutes, do a compose-preserving reload
(described below). If he sends the message before the timeout
expires, reload the page after a successful send. If the send fails
(not due to server timeout), however, we do a compose-perserving
reload in case the error was due to the data format changing. If the
send failed due to server timeout, we don't reload because the reload
will probably also fail.
In a compose-preserving reload, we redirect to an URI that has a
fragment indicating we are doing a reload and containing all the
necessary information for restoring the compose window to its
previous state. On page load, we check the fragment to see if we
just did a compose-preserving reload, and, if we did, we restore the
compose window (or just try the send again in the case of send
failure). The URI fragment looks like:
(imported from commit af4eeb3930c24118e088057d4da456748fbd2229)
Tim Abbott
Waseem Daher
Keegan McAllister
Luke Faraone
Zev Benjamin