Sometimes Dropbox shares with /s/ and sometimes with /sh/,
and I'm not sure which controls it, but we should deal with both.
(imported from commit 2222450f25c418b5fbd60ab2c30477467e34c0d1)
Previously, if for some reason pointer updates were not returning from
the server, the client would resend its request every second, rather
than waiting for the previous request to fail before sending a new
one.
(imported from commit d134adc50aabd135c7631913fecab3519aca6640)
It's closer to a presence query than an update, and more importantly
this moves this out of Tornado -- previously Tornado was spending at
least 3ms per recipient on messages sent to the MIT realm fetching all
this data to return back to users. This should save around 100ms per
message sent to a popular stream the MIT realm -- but more
importantly, each such event is 100ms during which Tornado is not
processing other messages.
(imported from commit 134169f0fdcd9f6640fda957edc4a28b07783d8e)
This is required because our migration is going to go in two phases.
When we do the database migration (on pushing to master), we update
all messages at that point. But prod doesn't know about the new
flags field, so any new messages sent on prod will not have the
read bit set.
When we push to prod, we want to re-run the bit of the migration script
that automatically sets read flags on messages older than the users's
pointer.
(imported from commit 961d33e972eac9ada80089bf1b1269c7fb42d56b)
We also needed this when rerendering on append, so moving it into
_maybe_rerender allows the two places to share the code.
(imported from commit 027d99cae7864747cf1ec94c95e8ece495b5c907)
This avoids our repeatedly retrying to fetch a tweet that doesn't
exist from the Twitter API.
(imported from commit b4ca1060d03da21e7e59e5b99e682d2e8457df15)
It's pretty confusing if this doesn't change. In some other world we
could update the fade, but since we're currently only fading on reply,
I think it would be weird to update the fade when you're picking a new
recipient.
(imported from commit 8f77419d443d578068b57f847354ac6da7632ee2)
Previously, we compared the recipients of messages to the message that
you triggered the reply off of -- even if you did a reply-to-sender.
This commit changes the code to instead track what you faded by,
rather than just the message you faded on.
Fixes#1037.
(imported from commit d9e2cb4122501b1bc45e231d4b52c2e7f9284fdd)
Previously, if you renarrowed, all message fading would be cleared
until you close and then reopen the compose box.
Fixes#1024.
(imported from commit 57981ba29ab597c4c84ca6e4e9d04a8284f49117)
We treat these exceptions the same way we treat fatal errors: report
the error message to our server and then allow the exception to reach
the top level.
We could also override document.onerror, but don't. There are a
couple of ramifications of this:
* Exceptions caused by event handlers directly attached to DOM
elements aren't handled
* Exceptions caused by code at the top level that triggers an error
(such as parse errors in our Javascript files) aren't handled
The reason we don't override document.onerror is because the
document.onerror handler has a limited interface and doesn't receive
the exception object. It only gets the message, file, and line
number of the error. Additionally, exceptions that we allow to
propogate out of blueslip trigger an onerror event when they're never
caught. In order to avoid handling the error twice (once by blueslip
and once by the onerror handler), we'd have to encode the fact that
the error has already been handled in the error message, which is
pretty ugly.
(imported from commit 7f049ae519dc198a9f7cfd41fd5dd18e584bd061)
This is to let us pass in the stack trace of an existing exception,
which will be required in a upcoming commit.
(imported from commit 421366a7a01deb770b7620417fb4660769c5db53)
The referenced element where the error was supposed to go was removed
in 66fd42914e4fc33719c4f21ad401748989f20b49. Now the error message uses
the regular compose error message area.
(imported from commit c82a6d863fa327ba982157d0b0607545d7e65cb7)
Previously, if the pointer was high on the page such that there was a
lot of empty space below and the render window was full (a situation
we could get into if we're following new messages arriving), a newly
recieved message would not be rendered even though it would have been
visible on the screen if we had done a rerender. Adding the
_maybe_rerender() call to the end of append() ensures that we don't
end up in this situation.
(imported from commit 925d3cc62e8221b42f1d5ff1788e99c7d07ccc24)
Now that Zev's message list branch is merged, there's no longer a
performance penalty for loading these old messages, and it improves
our narrowing performance to have them loaded.
This code is slightly different from the original commit
93d47710891cfc4db9fa00beaa5ccd10113aa1c3 since the way to access the
first element in the message list and the API for get_old_messages
have changed since then.
(imported from commit f295f892bea9327eb8316225b7b98f0e3b3fdc9a)
This will hopefully make stream privacy more noticeable. We still don't
allow people to modify privacy after stream creation, however.
Since we now use a radio box on the stream creation modal we had to change
the selector used by subs.js to determine if a new stream was to be invite-
only.
(imported from commit 641a4fab74301a9b3ecd4b3859f010dd4ece193e)
These have been the recommended way to do generic views since Django
1.3, and the old-style views (previously deprecated) are gone in
Django 1.5.
(imported from commit 45938f452bd6aa363f7ccdbac9f2297d1b1b5e7b)
Zev Benjamin
Leo Franchi
Tim Abbott
Waseem Daher
Luke Faraone
Jeff Arnold