We had a couple places where autoscroll would
mysteriously midway through scrolling, and it
was because scrolling generates mousemove
events.
(imported from commit 666e5e5af81fdcc5cc56c314d1264dbec970c067)
Treat "mentioned" messages like "starred" messages for narrowing.
Lots of ugly copy/paste here. There might be opportunity for
some cleanup in places.
(imported from commit e7629890d42643c0000e1cc85422b2a0690f2cc4)
The bug we experienced here was that if you loaded the page in a
narrowed view, and then un-narrowed before the first block of messages
for the home view arrived via load_old_messages, then
narrow.deactivate() would re-select ID -1 in home_msg_list. This ends
up calling recenter_view() on the message, which in turn tries to
access the message with message id -1, which fails.
We do sometimes re-select a message ID in order to recenter the view
properly when we prepend messages to a message list, so we can't make
this always a nop; instead we add a check for id -1 in the
message_selected.zephyr event handler.
(imported from commit 66f84a586e59d99aaf0e4ba2cda9fe597b033145)
There was an off-by-one error in how we determine when
the message list was scrolled all the way to the bottom,
and this undermined our handlers for page down and scrolling
to get the pointer all the way to the bottom.
(imported from commit f80d11582b40726246e69c817a502b311081c730)
This reverts commit 13fb245f86ab84b1d2faea9d2a1f2145cd4aa907.
(Waseem wanted to hold off on adding more hot keys.)
(imported from commit 97c25ffa01fd7058fc90a278887d85b7d82a268a)
Re-focuses on the compose box after a send, but only if
the compose-box was opened by responding to the message
at the cursor (by hitting "r", enter, or clicking on the message)
(imported from commit 8e7560c8ea31397b57b2bc3e2e7d9dd996226a6f)
The reply-to autoscroll was using a flag that was redundant
to suppress_scroll_pointer_update and then updating it prematurely,
which caused the pointer to move when you clicked on a message to
reply to it. Now the pointer goes to the message you replied to.
(imported from commit e2f49fd6bd0da9a3f4b58c0eb08192ef0ee9abf0)
Now that we sometimes call message_edit.end() twice, we need to check
if we've already cleaned it up.
(imported from commit 4e0efa14ba78df0a86b2ae97b99fa1be6197df88)
The main point of this fix is to move some more scroll-related code
into viewport.js, but it also fixes a bug where the size of #main_div
was not accurately representing the full height of the message list.
Making the calculation more accurate narrows the window where we
do pointer adjustements on mousewheel moves.
(imported from commit 5d821f459284c4dbd5ff8056001e54caf4355f1d)
Fix min-height before doing the calculation of how much a
replied-to message is being covered by the compose box. This
change also removes an outdated call to slideDown.
(imported from commit e5a3f35bbacff16dffae62c9e9f6bbc7978a13c1)
The logic for this already existed, but start() was getting called
twice, once from compose.set_mode and once from the click handler, and
the result was the focus always being in the stream input box.
(imported from commit 9a832a118856b5705524975a4412b7e6e547ef5c)
This parallels clicking on a stream name, which narrows you to that
stream. This also gives you a discoverable way to narrow to PMs with a
particular person.
(imported from commit 6c706f0643f6a8ec20ac38360153227ec2f645ae)
This sets up the keys t and b to anchor your pointer to the top
and bottom of the viewport. It empowers keyboard users who
are otherwise at the mercy of Barnowl recentering, but of
course it doesn't affect users who don't want to opt in.
(imported from commit 13fb245f86ab84b1d2faea9d2a1f2145cd4aa907)
The functional change here is that our code to stop
autoscrolling on certain events, particularly mousemove,
now only runs during system initiated autoscroll events.
If the user had been replying to a message, then the feature
to stop autoscroll was too aggressive.
This patch also starts to put more scrolling-related code
into viewport.js, which will hopefully prevent some code
duplication and give us a single place to control things like
stopping animated scrolls.
(imported from commit e7d5946b0ac7fcfda2eff1d0e2b58a78b44ecc1a)
We also record the historical edits to the message in this JSON format:
[{"prev_content": "new test message 14", "timestamp": 1369157249},
{"prev_content": "new test message 13", "timestamp": 1369157118}]
but we don't actually do anything with the information as of yet.
(imported from commit 2d5ca449b87b33ad035ab0e076a22e150c8e7267)
* Modify the narrow icon in FontAwesome to make it better align to the pixel grid and display well on Windows+Chrome.
* Move the message controls to the right
* Hide the message info icon until the message is hovered / selected
* Switch the star to a gray version
* Increase the size of the gravatar
* Adjust the spacing
* Add the right-side message pointer
* Fix private message background colors and mention colors
* Modify star count test to account for new stars
* Bug fixes for stream subscription messages and other miscellanea.
(imported from commit 3d3d9de7e03f3658c5c78b492051b2b7f795487d)
This goes back to only scrolling by the size of the new
message, and it avoids scrolling in certain use cases.
(imported from commit f9e6380b779bb21283ba889715712b6b51633838)
Previously, we were referencing the mixpanel objects only once, at
page load time, which meant that there was a race between metrics.js
loading and mixpanel completely loading. Mixpanel starts with stub
methods and then replaces them once it fully loads, asynchronously.
If metrics.js ran before mixpanel loaded, we'd end up wrapping the
stub methods instead of the real versions. Adding a layer of
indirection ensures that we always get the right method.
(imported from commit 6a8cfbf249168443956895b7a7e29bf7bb4222aa)
This reverts commit 87226d857845c6f16cb3bc0d6ab5bb748aca5987.
This meant that if for some reason there's a server error or network
failure trying to send in your edit, your changes are silently lost.
(imported from commit 2b5d19716fef1565b061a2b6c7cecc54f183b6f3)
Currently, some browsers don't seem to be sending metrics information
to mixpanel. This commit will make said browsers noisy, but should
help debug what's going on.
(imported from commit c5050f66d985eb76e38117b2668594fedfc10702)
Use tab_bar_underpadding to find out the top of viewport
that we can view. Also, eliminate effective_page_size().
(imported from commit 0e2d777790552e77d635989e496f3446cefccb1e)
This will make it automatically work if we add new tab
bar like things. The current version of ui.message_viewport_info()
is slightly broken; that's a separate fix.
(imported from commit fa1906b738433223831250e3191dfd8e87d67daf)
Most of the model logic pertaining to unread counts had been in
zephyr.js, along with a couple global variables. Now the code
is encapsulated in unread.js. It was a pretty straightforward
extraction with some minor method name changes. Also, a small
bit of the logic had also been in stream_list.js.
Conflicts:
tools/jslint/check-all.js
(imported from commit f0abdd48f26ab20c5beaef203479eb5a70dacfff)
Set the background behind "Private messages" to green whenever
a user's unread count goes up for private messages. Remove
the background after 3s. Advanced browsers will fade the
green in and out over 6s (3s up, 3s down).
(imported from commit 80ed9661d9eec1d697f3259854037d7e145615cd)
The only known outstanding bug with this is that it doesn't properly
handle the updating of a message's highlighting/presence in a narrowed
view (e.g. in theory, a message should disappear if it is edited such
that its subject doesn't match your narrow or it no longer matches
your search). I think I'll just open a trac ticket about that once
this is merged, since it's a little hairy to deal with and kinda a
marginal use case.
Also it's not pretty, but that should be easy to tweak once we get the
framework merged.
Conflicts:
tools/jslint/check-all.js
(imported from commit 2d0e3a440bcd885546bd8e28aff97bf379649950)
Currently the interface for editing messages is limited to a
command-line API tool; it's great for testing with e.g.:
./api/examples/edit-message --message=348135 --content="test $(date +%s)" --site=http://localhost:9991 --subject="test"
The next commit will add a user interface for actually doing the editing.
(imported from commit bdd408cec2946f31c2292e44f724f96ed5938791)
Specifically:
* Leave the avatar image as inline and round it.
* Move timestamp to the left column.
* Replace the "Info" link with a permanent info sign.
* Move the pointer bar to the left.
* Remove borders
* Change selection background colors, and PM colors.
* Introduce the "narrowing" icon into our FontAwesome set.
* Modify the tests to account for the new "narrowing" icon and fixed a bug in star-finding.
* Clean up CSS and add a more prominent color to private messages
(imported from commit 8a8d6de8acccc52c0d16f5d1ce31aabdc72c88c8)
The geometry used by within_viewport() is a little off to
begin with, but we don't want to check it at all in this
situation, because if the last messages falls out of the
viewport, we still want to scroll. The relevant thing
to check is that available_space_for_scroll exceeds zero.
(imported from commit a0a6f0d23db2eab8d9f22fc9ad523031cf7f7ec2)
The prior code was subtracting out the compose box from the
calculation of available_place_for_scroll, which didn't make
sense when the compose box is at the bottom of the screen
and you're scrolling the current message up. You could see
the symptom pretty clearly by seeing autoscroll stop exactly
the height of the compose box from the top.
(imported from commit cfceb85c8be80cca957ac4a3ad0bbf0de7425c48)
This fixes a pretty subtle bug where the window-focus handler
wasn't updating the unread counts in the title, but it was
hard to notice, because as soon as you moved the mouse, the
problem fixed itself.
Apart from fixing the bug, this patch eliminates the expensive
mouseover handler, which is a big win.
The fix to the window-focus involved some unrelated cleanup. I
decoupled update_title_count() from received_messages(), as the
former method will probably live somewhere else soon.
Also, in order to get window-focus to update the title count,
I went pretty deep in the stack and added a call to
update_title_count() inside of update_unread_counts(). This
fixes window-focus as well as restoring that behavior to
code paths that were calling received_messages().
You'll see that call to update_title_count() is now adjacent
to the call to update_dom_with_unread_counts(), which is
fairly sensible, but then are calls to similar methods like
notifications.received_messages() that happen higher up in
the call chain, which seems kind of inconsistent to me. I
also don't like the fact that you have to go through a
mostly model-based function to get to view-based stuff, so
there are some refactorings coming.
(imported from commit 2261450f205f1aa81d30194b371a1c5ac6a7bdec)
I renamed set_count_internal to update_count_in_dom, because "internal"
was redundant in terms of saying the function was private, and it misled
me into thinking it was internal-only in impact, but it actually updates
the DOM.
I also removed the synchronous callback functions, since they both
led to simply hiding the count_span and clearing the text of the
value_span.
(imported from commit dea27d6414dc1b33818b24662f8246d687530b71)
This allows us to load our own code before most dependencies are
loaded. Our compiled Handlebars files still need the Handlebars
runtime, so we can't move all of our minified code before
dependencies yet.
(imported from commit e2d0fa13f05a08fc3c2519790f7382e5eef6eca2)
The problem is that if you load a browser window in a stream narrow,
add_message_metadata will be called for the messages in the narrowed
view before it is called for the messages going into the main view
(thus inserting them into all_msg_list), resulting in duplicate
copies of messages.
This would be mostly OK except that we call
process_message_for_recent_subjects inside add_message_metadata, and
that function assumes it is only called once on each message
(otherwise it'll double-count the message).
(imported from commit a3e7f85874100cd93a6d07684605da04d9cc80c7)
Created a function message_viewport_info() to return more accurate
effective viewport info and called it from process_visible_unread_messages().
Also killed off a tiny bit of dead code in process_visible_unread_messages().
(imported from commit 985fcf2fb447dbf1026e2de37574c255a9bd6196)
Whenever we get a narrowing event, it's possible for new messages
to appear visible, and we need to call process_visible_unread_messages().
This has been a bug, but it's mostly obscured by the fact that we
call process_visible_unread_messages() as part of focus/scrolling
events.
(imported from commit b9447977f8e2272d45865ca67b436cacafd58a03)
This works fine on prod, but after a new install-server, the closure
compiler complains about a side-effect-free for loop init.
(imported from commit aa0e4d788abe4c819d4d912d6a526fab4f676675)
This removes the large "New stream message" and "New private message"
from the left sidebar. It also makes the default action when clicking
inside the composebox the same as the "New stream message" button used to
do (instead of replying to the stream-subject pair at the current cursor).
(imported from commit 316f03a35b781aca4c42555f74b99c4332ff42de)
This refactoring basically splits off two functions from update_unread_counts(),
which then becomes a simple three-liner.
The function get_unread_counts() is extracted, and it's purely functional
computation. It paves the way for a more pull-based approach to getting "unread"
counts, where other parts of the program can just call it to get values as
needed without worrying about side effects. It is staying in zephyr.js for
now.
The other function is stream_list.update_dom_with_unread_counts(), which
has a new home in stream_list.js. It handles all the DOM manipulation
aspect of unread counts in the left pane, mostly by delegating to smaller
functions within stream_list. Some of those smaller functions can now
be turned into private methods FWIW, but I'm not sure it's worth the
trouble.
(imported from commit 799f9ebbaed8d530829a4741ef14be04bd8abf5a)
This is a prefactoring to eventually eliminate the home_unread_messages
global variable. More commits to follow.
In order to set up process_loaded_for_unread() not to modify
global variable to get its job done, we want to pull it out of
add_messages(), so that add_messages() doesn't have to pass back
state to the 9 different places in the codebase where it's called.
There are only 2 places where process_loaded_for_unread() get
called after this commit.
In order to facilitate pulling up process_loaded_for_unread(), I
made it so that the contract for add_messages() was to accept
already-hydrated messages. This way I could hydrate the messages
before calling process_loaded_for_unread() without have to
worry about double-caching them in add_messages. This will
slightly improve performance, but it was mostly done for code
clarity.
(imported from commit ad5aaad5b1f22c31647370f4c9dcb5f89d7d99a7)
This was a workaround for a number of other bugs we had, but at this
point just serves to make debugging more difficult.
(imported from commit 6662b7854c265bd8016f6c8ce75a095731211a45)
We really should not be storing bot API keys in the DOM and should
require some sort of additional authentication before showing them,
but this seems reasonable for a first pass.
(imported from commit c7d75aa52e21894bf53917457e771c18de38bbcc)
The idea here being: if there's only one line, it discourages
me from writing a long message (and also makes me think that
enter will send).
(imported from commit 424d8d305d1965ce3199ce3227dac94b395945bc)
This commit takes control of keyboard-based pagination away
from the browser, so that we can use the effective viewport
size as the amount to page, as well as keeping a little bit
of overlap from page to page. There had been issues with
pagination for a while, but the introduction of the always-open
composebox particularly aggravated the situation.
(imported from commit 45b9b7d5a6b322230c9d55e1be0b763dbce06e2e)
Previously we never sent desktop notifications when the browser was
focused, even if the message appeared offscreen. After this commit
there are only a few cases when PM or other notifiable message doesn't
trigger a desktop notification:
(1) You sent it yourself
(2) It was onscreen when it arrived while your Humbug window had focus
(imported from commit e381c02c0e6794594d6934f57249a11ba2a88210)
This is trying to make the logic flow clear -- e.g. we check once, at
the beginning, for whether the message is notifiable, and the checks
for whether the various notification settings are enabled are more
parallel.
(imported from commit a68c71a53055191bc16682a85f739ed8e40ddeae)
See #1234 for details. When you upload files the old-school way
(no drag&drop), there was a bug where you couldn't upload the same
file twice, due to us intercepting the change event and not clearing
out the file list when we were done. Tested on Chrome, but uses
a known IE workaround.
(imported from commit 8120c2e8bce41f3964f4f5c21aad3a85df0e433d)
The filedrop library has a few canned errors, but it seems to mostly
let server errors come through. We try to trap 413s to give a more
descriptive error than "unknown," but this is just a bandaid fix,
and we should see what's wrong with our prod configuration.
(imported from commit eac26406866d80340f24dbdca9f34408ddb92462)
The .height() and .width() functions are actually pretty expensive for
the number of times we call them. The viewport height and width
don't change often, though, so we can just cache them and recalculate
them on window resize.
(imported from commit 129fb8c058144125e2974f6b7967cd9f1a5c9ead)
The .height() and .width() functions are actually pretty expensive
for the number of times we call them. The callers of within_viewport
already know the offset and height of the row, so we just pass them
in so the values don't have to be recalculated.
(imported from commit d1c077bd87463d695f0bbe337b6a8b04ac2d17ce)
The optimizations are:
* Sort over the list of subscriptions instead of the DOM li elements.
This requires storing the li elements for each sub on the sub object.
* Do a bulk insert of the li elements instead of doing them one by one.
(imported from commit 1a987799930fc677e25f0bc2dcf66f83a4ac3163)
We now fire three events:
* subscription_add_done - fired when subs.js has finished handling a
subscription_add event (all structures are set up, etc.)
* subscription_remove_done - fired when subs.js has finished handling a
subscription_remove event
* sub_obj_created - fired when subs.js has created a sub object. This
happens both when a new subscription is added and at page startup for
all existing subscriptions
These events are fired whenever sub objects are created, even when
not tied to a subscription event.
(imported from commit a4863451f37e7fdbad480696b388ea788b01d6b9)
* Start a compose when we do a file upload
* Restore the "Formatting" and "Feedback" links.
* Dismiss composebox error messages when we defocus composebox
Realistically, the "correct" way to do this is not to have to
explicitly manage the composebox's state, as we do now -- it should
just be 100% visible and ready to send any time you click 'send'; it
shouldn't need to have first been composebox.start()ed.
(imported from commit 7f1725c229ed968a9b5500b25d600306173182a0)
Recently the typeahead for streams in the compose box was modified so
that streams only matched queries when the query was a prefix to the
stream. When that change was made, the old highlighting behavior
had been mistakenly left in place. This commit fixes the highlighting.
(imported from commit b7ec33daba46978df58eb91306686a4f1a57c7fa)
* Properly resize compose area when we cancel out of it.
* Re-enable clicking on 'reply' in popover.
(The issue with the latter is that clicking on "Reply" started
a reply and then bubbled up and triggered our code that canceled
a reply because you clicked out of the composebox.)
(imported from commit 25d0ea58b72d2ee246217baf3eb9cac58fc858f5)
Really, the "correct" way to do this is to undo "scrolltheworld", and
then just have a compose div that always lives underneath the message
list div. (This will also allow us to deal much more reasonably with
the whole "Is the composebox in focus" thing.)
In the interest of prototyping something more rapidly, though, we
adopt the somewhat more hackish approach, with the understanding that
much of it will probably be simplified later.
(imported from commit e2754be155c522b6dac28e7b84c62bd2030217c8)
We previously kept the lists in the DOM for all streams and updated
them all when new messages arrived. This was very expensive for
large numbers of streams, so we now just build the subject lists on
demand.
(imported from commit 937ad4322ce2014200aeae8645f79875f6af576e)
This commit also fixes a bug where "starred messages" wouldn't get
bolded when you narrowed to starred messages. However, it also
introduces a regression where subjects aren't highlighted correctly
on load to a narrow which will be fixed shortly.
(imported from commit 411575d92762e41d04c1baf126c0ab1dfb4225a5)
This will matter shortly as hashchange.initialize can call
narrow.activate(), which fires an event handler.
Really, I have no idea why we have these initialize() methods anyway
and we don't just do initialization on document.ready.
(imported from commit 3a6a80e1426b03439b95cae3f142a4b1c43125e9)
We memoize add_message_metadata by checking if the message is already
in the all_msg_list. Therefore, we need to add messages to that
message list before we add it to the narrowed_msg_list.
(imported from commit 4346179376ef6f982162c02c6152a0d294bfb2c0)
The String.localeCompare function is really slow, at least partially
because it creates a locale-aware collator object each time. So now,
when we can, we create and cache a locale-aware collator object.
However, this is not supported on most browsers, so we fall back to a
non-locale-aware comparison. This is not ideal, but for now we are
mostly working with English-speaking customers.
(imported from commit 51aa02e3b9fe4a0ef0cb084874fe26e91c57f65e)
Addionally, print out a blueslip error instead of dying
if a stream id is accessed when there is no stream to get
(imported from commit 0d6466ca79312a4fb9a235f313303ac5246afb35)
This decouples from Chrome notifications, which gives us cross-platform
support in at least modern browsers.
We log this action so its replayable in our message logs.
This implements the model change indicated by the previous schema commit.
(imported from commit b21213cdde54f43670bbb0bf1f607147fc732b38)
We test if the user supports sound in their browser, then determine which
sort of sound their browser supports.
When, whenever we show a desktop notification we also play a sound.
(imported from commit dae41e70a6e4f6ed60ffedaac546d77baee52675)
Since they can't be parsed, probably the best thing to do is to send
the user to the home tab; we could add in showing an error message but
then we'd need a way to clear the error message -- better to just have
this work.
(imported from commit 67c0475ff06eb0431621eef60b9c50287a158232)
The .data() method tries to coerce the value of the attribute into a
Javascript type, which is not what we want when the stream name looks
like a number or some other Javascript type.
(imported from commit a5f639d2ef98435cec6beacf3837fc185474a955)
On page load, the scroll_finished function was being called and
scroll_start_message was -1. This caused us to mark all messages
that we loaded through the messages initially visible as read. This
was particularly problematic because message_range iterates over all
message ids between its two arguments.
(imported from commit d93209d466797939cc9dbdbe76d25a5b20195bd2)
Previously we were doing quadratic work in the number of streams
because we had to iterate over all <li> elements every time we added
a new one.
(imported from commit 60cb97f77d161e9d8c3072157fa9c57c58f7af52)
Since we pick a new color every time we add a new subscription and
recomputing the available colors was linear in the number of
subscriptions, we were doing quadratic work on page load.
(imported from commit 647ff3cb82f405755711da47701f005e7bc0023e)
We were previously doing this on every message. Because
update_recent_subjects is linear in the number of streams in the
sidebar, this became very slow when we enabled the streams sidebar
for the MIT realm.
(imported from commit 95cd71d83bbcc08cc6c5c79ca567b5d6b9b17173)
We were previously calling sort_narrow_list after each stream was was
added. Because it is linear in the current length of the sidebar
list, we were doing quadratic work on page load. When we enabled the
streams sidebar on the MIT realm, this became problematic because of
the number of subscriptions Zephyr users have.
(imported from commit d60ddc638f0a81fbce08eecd6671e9ea6ca38515)
Messages are now explicitly condensed by our JS, which means that if
we run into some bug where our JS doesn't run, you still see the whole
message (rather than getting a clipped message).
(As of this commit, this can happen when you, e.g. are on the
Settings page and someone sends you a message.)
(imported from commit f3bec97800ea1852c80203e73552ee545fcc7e8a)
This fixes a bug where if you were narrowed to a search and received
a new message that belonged in that search, the message would appear
to have an empty subject and content.
(imported from commit fe1dbf584d3659d57c5b70c7eb45cb22bbc9732f)
Previously, we were having this problem where:
* You narrow to something
* That causes message_list.js:process_collapsing to run on all of the
elements in the view, which changes some of their sizes
* That causes the pane to scroll and either push the content up or
down, depending (since stuff on top of where you were is now a
different size)
* That triggers keep_pointer_in_view, which moves your pointer
Moving process_collapsing into narrow.activate doesn't obviously
fix any of this, but it does seem to mitigate the issue a bit.
In particular, we (a) process it less frequently, and (b) process it
immediately after we show the narrowed view table, which seems to
reduce the raciness of the overall experience.
This does, however, introduce a regression:
* If you receive a long message when you're on
#settings, e.g., and then go back to Home,
the message does not properly get a [More] appended
to it.
(imported from commit b1440d656cc7b71eca8af736f2f7b3aa7e0cca14)
This can be useful for debugging what sort of narrow is happening in
addition to the URI decoding bug we're currently experiencing.
(imported from commit 0cb55fec4ac1afa986c747eb79236b4300c9e636)
This shouldn't have any effect in normal realms, but for realms like
mit.edu that have large numbers of inactive streams, it will sort all
the streams that have had a recent message at the top (aka those that
aren't effectively inactive).
(imported from commit 027ce258d04b6fd58705e49f769dec7e0639bb38)
There's still a lot to do here. For example, the external code
should probably go through the new Filter object directly instead of
indirectly through the narrow module.
(imported from commit 22dcd31cdebd51453f1658af52a4432b2fe7a4cb)
In the case where we're getting old messages for a narrowed view, the
anchor message id might not actually be in the result set so there's
no reason to fetch an extra message.
(imported from commit e610d1f2cb95be3ff9fce6dc95e40c560bc5bf84)
When you create a stream that you'd previously created (then unsubscribed from),
it was possible to end up in the subscribers list twice. Once came from loading
the subscribers list from the backend, and once came from a bit of mark_subscribed
logic that only gets called if you've subscribed to that stream at least once before
in the current session.
resolves trac #1196
(imported from commit e47ff139a9c25b1b8689ea6795dfad96ae8d2591)
Changes include:
* New markup for the button in compose.html
* A hidden file input field in compose.html
* Added reference to the file input field in filedrop
initialization in compose.js
* A feature test and a click event binding for
the "Attach files" button in ui.js
* New paperclip icon reference in fonts.css
* New general hidden display classes in zephyr.css
* New composition pane button classes in zephyr.css
Fixes to the "Attach files" button commit e673bda...
Changes include:
* Fixed the feature test for (new XMLHttpRequest).upload so
it works in Firefox.
* Renamed .button to .message-control-button
* Removed stray newlines
(imported from commit c1f0834b74fd7120ec27db64ec380ffb3fa34633)
Previously, our check for whether we needed to call load_old_messages
a second time on page load to get up to the present caused us to
basically always do such a call.
(imported from commit b599041e8c0853b4c8c9ab2def6679142302523e)
The internal format of 'message' had changed, so prior to this commit,
the tutorial was receiving (a) internally inconsistent, and (b)
not-what-it-expected versions of the message.
(imported from commit 233b934e6b600bd59125d133fdf7443fd8f6bbf8)
It's subtle, but the slice was in the wrong place and wasn't
actually truncating the stream name at all, so the client and
server disagreed about where the tutorial messages should go.
(It might be the case that we should accept the tutorial stream
name from the client directly, rather than computing it in two
places.)
(imported from commit 8273223f182e8ad36eaea1cbf75e1426fcfdfbab)
If the system was waiting for you to reply and you replied 'exit', the
tutorial would stop -- but our thing that was waiting for you to reply
would continue waiting. It would eventually timeout and send you the
heartbroken "I didn't hear from you so I stopped waiting" message.
Chances are, you were unsubscribed so you didn't see it, but we
should still just not send it.
(imported from commit 694e442bc29b32efd59f08b4b8b5f573768aea21)
This was apparently broken by the final revision of our fix to the
autoscrolling+narrow bugs, because it attempted to use jquery's
animation queues to restrict which animations were stopped, and this
doesn't seem to work.
(imported from commit cf97f9f56dc5a16d1aa0322b5e6ec432a76d3be2)
Previously, we were calling util.same_stream_and_subject on a pair of
messages, one of which was a private message, which is not valid. We
should have instead been calling util.same_recipient, which checks the
message type as well.
(imported from commit bc5715807036bff1fd4f214dafad00e33678e91d)
Previously we were using message.display_recipient everywhere, which
is actually pretty confusing.
(imported from commit a58471172e28c039af8e290362e54b6660543924)
This is more consistent with how we compare subjects etc., and can be
used for comparing the subjects of a potential future message that
doesn't have a recipient id yet.
(imported from commit 93251c62dc74b3f12c6140b12fc8d6c756d35f37)
* renamed the 'icon-star' style to 'icon-vector-star' to keep backwards compatibility for icon-* classes
* changed relevant styles in zephyr.css; added FontAwesome assets
* changed relevant CSS classes in base.html, left-sidebar.html, ui.js, message.handlebars
* added new fonts.css to start consolidating all font-based assets
* added fonts.css to PIPELINE_CSS in settings.py under 'portico' and 'app'
* modified the stars test suite to reflect new star icon class name.
(imported from commit 3116fcfd4b5fb4edecd457da554fea616bb7081b)
Don't show an error if we can't handle the drop contents, since it may
just be empty rather than being a browser unsupported issue
(imported from commit 986495b4a94f4afacf75ffb35ea507d86c369b2f)
Some functions invoked by the make_script framework weren't returning
their Deferreds. I noticed this as the hello stream not getting picked
correctly because loading your real subs hadn't completed yet.
(imported from commit fac3fa36b77585bd5c03bf8fbaec052fe397a481)
Using [] doesn't cause incorrect behavior, but it's a mismatch with
how stream_info is initially declared and gives you a confusing
representation at the console.
(imported from commit c03d9e6a29ff990659f41ee478f631a019a5ac25)
Previously we added some names to your subs to use them as examples
during the tutorial. We no longer do that, but the tutorial could pick
a name from that list to recommend that you say hi on, even if you
aren't subbed.
Don't do that, and instead try to pick a stream that is in turn:
* your company name
* a probably-good stream name like social
* a stream that is hopefully not an alert stream like nagios
* eventually give up and pick anything
(imported from commit ec20c7722ea95b025dec62bcf47e33c62d1a8029)
Also handle the case of subscribing failing.
This race could cause you to not see initial traffic from the tutorial bot.
(imported from commit 395a2968555e20a4dbc106dfa9d5790e9f102a3e)
This is basically just the logical extension of the previous commit
for the case where the last thing we did was subscribe or unsubscribe.
This even magically updates when you subscribe or unsubscribe from
another window :).
(imported from commit 2399329d11bf66aa0b614a21d2b3cf4035452279)
This is required to get historical messages that might be within the
message ID range of your home view.
I think we could avoid calling load_old_messages on every narrow by
tracking when the user last subscribed to each stream, and if the user
subscribed before the first message in the current home view message
window (aka the messages used for the fast-path narrowing), don't call
load_old_messages. This would happen almost every time. But it would
require a schema change to do this.
We also remove the load_more_messages call from hashchange.initialize.
It is no longer required now that we're calling load_old_messages on
each narrow anyway.
(imported from commit 1c78c183e61392429592ae89d566315be7be8999)
This should fix the problems we've been having with out-of-order
message deliveries, and is also an important prerequisite for showing
historical messages.
(imported from commit 77a18a526bf8ec4f1f70b776ac8b7e189d00bcf4)
This is a V1 of this feature. For now, the only way to expand is by narrowing
to the stream---future revisions may add a manual toggle if it is found to be
useful.
Additionally, showing per-subject unread counts will be coming in a future revision
as well.
(imported from commit fb5df0d27e928fa3b0f32b9ff2c1c508202cf7e5)
This commit will incorrectly list past-online users as active, a shortcoming that is
addressed in the next commit
(imported from commit b018767df686f88c0ca939c067c573e4d7cea357)
Otherwise it applies to all password-type <input>s, which is not necessarily
what we want.
(imported from commit da2bb86961f4ff1dcc48e89e51abac6dbea79548)
We now have the bar color to indicate (for most users) whether the password is
valid, so revert to the default validation behavior and don't validate before
the first blur.
(imported from commit 5c2f6e05a8796033942a2af62f244b61459ff1bb)
And scroll there on any error (previously, we would scroll only if we end up
submitting the form).
(imported from commit 63597c4da78ac92cd5c2314d6d174d178b1caaf3)
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)
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)
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)
Our mobile apps (which don't support in_home_view filtering) will move
the pointer to a message that isn't actually in the home view, so we
need to accept that sort of input for now (and maybe in general --
even if we fix our mobile apps, third-party clients may screw this up
too).
(imported from commit ce837e972f0581abd1df44fdb2dd5270dfb9afde)
For people who aren't on the @humbughq.com realm the tutorial bot showed
up in the create new stream modal but attempting to invite them failed.
This was most often noticed with the tutorial bot.
In the future we should figure out a really good cross-realm story, but
in the near-term we need to probably exclude other people outside your
realm rather than special-casing @humbughq.com.
This closes trac #1059.
(imported from commit df704df0c8ae84b23d9491ce6ab77300831cdd20)
We now add the my_fullname class to the entry for you in the sidebar so
that we can automatically update this element when changing your name.
This closes trac #979.
(imported from commit f1473d6bb6f18810311d42c85d4b57aab9966498)
We also grey out the box to prevent the user from clicking twice.
This closes trac #1030.
(imported from commit eec810e3fbc5b7c9350c2d91e448fb27d4c856f8)
Leo Franchi
Jessica McKellar
Steve Howell
Keegan McAllister
Tim Abbott
acrefoot
Zev Benjamin
Allen Rabinovich
Waseem Daher
Luke Faraone
Jeff Arnold
Reid Barton