...rather than embedding them into index.html.
This is only acceptable for dev, but the next commit adds an alternative
mechanism for prod.
There isn't actually a manual deployment step here. However, this commit won't
work on staging / prod without the next one (since we don't serve
zephyr/static/templates in prod).
(imported from commit dce7ddfe89e07afc3a96699bb972fd124335aa05)
This has the nice side effect of not requiring us to trigger the
events manually in the success callbacks of our subscribe/unsubscribe
ajax calls.
(imported from commit e8d9970b708e9832d22be4803570071bacb46792)
We currently only use these events to change the autocomplete lists.
I figure that the presence list will be updated by presence events.
(imported from commit e9c1466659c4bfd463806656e0023984a4ea4177)
A ticket is filed and this error is not fatal to the UI but rather
a warning to investigate, which we will now do
(imported from commit 3f67ec2b503e91b3921e33b89febd97790e389f1)
Before this commit, if you try to arrow around when the selected
message is outside the pointer threshold for recentering, you get a
big jump, even if you are arrowing towards the center of the viewport.
(imported from commit 5c15d5ccccdf027a8bfa8b79bf519fccbfa971d8)
We have to be careful about timing here. If Tornado fails to load
existing queues on startup then all clients will reload at once. On
the other hand, if we don't reload immediately then the client won't
get any events until the reload. For now, I've opted for the
user-friendly approach, so we need to make sure that Tornado gets a
chance to dump and reload its queues correctly.
(imported from commit 51a6ab31cb461e1e3373486dcec2e57eb12a8077)
Addresses a complaint brought up in our usability study.
We now hook into the "show" event on .subscription_settings elements and
do some obnoxious math to move the scrollbar the way we want.
Closes trac #1015.
(imported from commit 5d9cee1ffc242eb7b743fdccd2bd76bf0a7ba060)
This is in addition to only successfully reporting a given error once
per session. Previously, if an error was triggered many times before
the ajax call to report the error returned, we'd end up making many
ajax requests to report the error.
(imported from commit 559179e3c8c3fbf03bbb091a67361d447c80b7bb)
We made this change for performance reasons that don't exist now that
we only render a small portion of your messages, and it causes a
distracting flicker when you scroll through messages slowly.
(imported from commit 33379320f6b90d93ec8beac17323b287f8bb2485)
Those examples make the tutorial feel much longer, and they aren't
relevant to people who aren't using Humbug to talk about code.
(imported from commit c3213775d26cf533b3d9bde691de08a53d427939)
It's not so black and white in a world where we auto-scroll at the
bottom, and we've observed that people trying Humbug over-focus on it.
(imported from commit 2057643f179d5d1666cb33438c5a513977197b37)
This is required if the stream has unread messages in it
(from a previous subscription period). Otherwise the
unread count will be 0 until reload.
Fixes Trac #1117
(imported from commit 8f3d78eb52fdecb52456b0037cc89665c9027fbc)
In Firefox, prevents e.g. a slash in a stream name, which we wanted to store as
%2F, from converting back to a literal slash.
There is some appeal to normalizing the URL fragment after parsing, but in
general this way seems better. It may decrease page load time on narrowed
views.
Doesn't yet fix#826; the URL is correct but the narrow is still wrong.
(imported from commit 32e3fa9e968139863f34b9698f1c8b39d06f0c14)
This was biting us before when the user would leave a narrow before a
get_old_messages call associated with it finished. Specifically,
search.maybe_highlight_message() would assume a message was in the
DOM when it wasn't any more.
We also have to hide the 'loading more messages' indicator when
reseting the 'load more' status because otherwise it wouldn't get
hidden like normal in the load_old_messages() continuation, causing a
load_more_messages() not to fire when re-entering a narrow.
(imported from commit 4a136dd01305b039c0970f897b07e603b87d5d8e)
If the user scrolls super fast, our scroll handler might not catch
the user passing by some messages.
(imported from commit 14cebffcd1321f02443971ac5e1c922db19648ab)
We create a circular reference between handler functions and our
wrappers for them so that we can pass the wrapper to jQuery.off when
users pass the original handler to us. This reference-counting
system can't break all the circular references we create because
users can unbind event handlers without explicitly naming the
handlers they want to remove (they can remove all bindings on an
element, for example). For now, we hope that this memory leak isn't
too bad.
(imported from commit 9615b5761b4b09ca7ca52c0d847e9b83330373fa)
Previously, we couldn't actually unbind some event handlers. The
problem was that when a user called $.off(events, handler), the
passed handler wouldn't match any that were actually bound because
the handler that was actually bound was our wrapper.
This bug specifically caused the handlers for our idle timers to
never be unbound, effectively never cancelling them.
(imported from commit 48efac954994a05c356d326e64a78ab0ace9fe3e)
We will need this for removing event handlers. This will
unfortunately create a memory leak, but we'll partially deal with
that later.
(imported from commit e439cb44d245e16d2254d1be053b68015a1f4c79)
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)
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)
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)
We were previously having an issue where the tutorial could
be pre-empted if you got a few messages while you were first
logging in.
I have some reservations about this being slightly fragile, and a
better approach might be to just have a bit that we use to determine
whether or not you've already seen a tutorial. (Or potentially that
checks whether or not you've ever sent a message.)
(imported from commit f8858f64a36bcd25887b76314caff283929f340c)
The issue, prior to this fix, is that the presence list actually
gets drawn *on top of* our "more messages" popup, which is ugly.
(Toggling the z-index on either or both of them did not seem
necessarily to matter, but that's probably because z-index
is subtler than I understand.)
This fixes Trac #1078.
(imported from commit a255aadb1884cf6c659085b26a36d378f680e83e)
The new system, called blueslip, makes errors fatal when in debug
mode and only output a message when running in production. In the
future, it could also send user errors back to us automatically.
(imported from commit 1232607c0311e885c8b5a5e8a45ffb28822426e0)
The jQuery .data() documentation says: "Every attempt is made to
convert the string to a JavaScript value (this includes booleans,
numbers, objects, arrays, and null) otherwise it is left as a
string. To retrieve the value's attribute as a string without any
attempt to convert it, use the attr() method."
(imported from commit f47c1cbb94cb5a98ea9842b00f45c35cd21873f9)
Keegan McAllister
Jessica McKellar
Zev Benjamin
Leo Franchi
Luke Faraone
Jeff Arnold
Tim Abbott
Waseem Daher