It seems to have no effect and does not appear anywhere else in our repository
or in jquery.validate.min.js.
(imported from commit c4d2f730f3b680e15af17cefee34f6930e64ade0)
Otherwise, if you get an error those e-mails are still around the next
time you try to invite someone.
(imported from commit b521a74f4d6c0d67271f804221f519d1aa7551ff)
This fixes user-visible browser errors caused by trying to use the id
of messages in an empty message list.
One error could be triggered by trying to go to the end of your feed
with the End key during a reload.
Another could be triggered by trying to narrow to a stream or subject
using hotkeys while in an empty narrow.
(imported from commit a0e5456fd3b475aecac6eddd7104772baaf3aeb8)
I noticed that on chrome, calling narrow.deactivate() actually ended
up calling itself recursively due to the hashchange code not correctly
handling the fact that in Chrome if you set
window.location.hash = '#';
and then read out the value, you get '' back out.
(imported from commit 9b5047fbe0e2ac1846e5325d066c72306634c523)
What was happening is that if you un-narrowed immediately after
receiving a message (e.g. because you just sent it), the autoscroll
animation from the zfilt table would still be running after you return
to the home view, resulting in the viewport being scrolled to an
apparently random point in the home view (even though the pointer was
still in the right place).
This cancels the autoscroll animations whenever you do one of:
(1) hashchange (e.g. to go to the settings page)
(2) select a message (covers narrowing/unnarrowing as well as keyboard hotkeys)
(3) mousewheel scroll
since those are basically the cases where we set the viewport
scrolltop directly.
Arguably this should instead be something where we somehow detect
which scroll events are triggered by what and cancel for any scroll
event not from the animation or rererendering, but that seems hard.
(imported from commit f776021303404c87b36241c733b3d1bcb083163b)
Now that our plugin is in the Jenkins marketplace thing,
we don't need to have the user laboriously download it
from us and upload it themselves.
(imported from commit 25e9926f7f2314db8f3ea6c00c40514b6fd546c3)
When testing locally this bar sort of lies, because the actual bottleneck
is Django→S3.
In prod, our connection to S3 will supposudly be really fast so this won't
matter.
(imported from commit c9f4b4882cbfdf3bbb8180f1500f35d8481c1f39)
This allows users to drag and drop content onto the compose box, storing
their data in Amazon S3.
New dependencies:
- python-boto
(imported from commit 339874e483db5c36312c9ceae56db29da6ca0d99)
This allows blueslip to catch exceptions from the event handlers on
these elements in addition to the other benefits that not using
inline handlers provide.
(imported from commit 2bdcb2496c6c08fa7228a20ce6164b527cf64e41)
The close handler will be called on cancel anyway, so we don't need
to delete in the click handler.
(imported from commit 0fcf4b0d1408312a0889f2b69e01207c9c3835fa)
Previously, narrowing to a stream name that only contained digits
would throw an exception.
(imported from commit dc76877427078d70e3d5625622c665be3302c976)
I generally don't like this sort of state variable, but I don't see a
better solution. The codepath is that when you start out on the
subscriptions page and then click one of the left sidebar links to
narrow to something:
(1) hashchanged() would call ui.change_tab
(2) ui.change_tab triggers a gear change event
(3) The ui.js gear-changed event handler updates the hash
Resulting in the hash ending up at "#". Since there's no easy way to
pass arguments through to the event handler, we just use a global
variable inside hash_change.js to track whether we're currently
handling a hashchange event.
(imported from commit 7bb905a223b5539240fc36de7896ee8074ebc62e)
We previously had 2 mechanisms for narrowing used by the left sidebar
-- the top few links used the hashchange mechanism, while the streams
links used a custom click handler. Both were buggy -- the hashchange
one hadn't been updated to just select the first unread message,
whereas the click handler didn't change tabs.
Fixes#1141.
(imported from commit 8a8af974e78cc5c33937ac0078f04a9b5452b94a)
This appears to have been caused by our code for preventing the
viewport from being recentered if you move the pointer away from the
edge of the viewport from a position near the edge, which was being
run even when it was not triggered by a scroll event.
(imported from commit 0a4b3dcca75a6e5dbf1beb77a5249bd6a9c61341)
The old directional hotkey calculation system was fragile, and because
of this, didn't scroll when you used the home/end keys.
(imported from commit dca4786de13a4ed2864600dadbf4b1a5ba848074)
...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)
Not needed for any specific reason, but we will need the .runtime.js file
eventually, and we should use a version of the library that matches the
Handlebars compiler.
(imported from commit 5600bc8d44b681999e2e5bbf04b890e2bb8477a1)
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)
Keegan McAllister
Jessica McKellar
Zev Benjamin
Tim Abbott
Waseem Daher
Luke Faraone
Leo Franchi
Reid Barton