This allows us to do some nice styling on the final message in a group
(in this commit series, this leads to some gently rounded corners.)
(imported from commit 86e7e8586dd4ee3cd8d4ce3be43fd2abab3f1d16)
This updates desktop notifications to use avatar_url from the
server (in case users have uploaded their own avatar). It
also removes the unneeded stamp parameter from the URL, and
it unifies URL handling with message_list.
(imported from commit 6bb43a25c01cc3d26f30fc167780a477d1c5d023)
The message_viewport_info() function encapsulates our logic
around the compose box and other elements blocking the viewport,
so viewport.js seems like a more logical home for it. It also
makes ui.js, one of our largest modules, a little bit smaller.
(imported from commit 7838668b28175e161b87a6d7a8124b73012f0ff3)
We could get into this situation when someone is doing a search and
someone else edits a message while the results are still loading.
(imported from commit 99e371fd75c7ae7dc98a0c03bc434e434da44b94)
We had a couple places where autoscroll would
mysteriously midway through scrolling, and it
was because scrolling generates mousemove
events.
(imported from commit 666e5e5af81fdcc5cc56c314d1264dbec970c067)
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)
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)
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)
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)
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)
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)
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)
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)
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 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 using message.display_recipient everywhere, which
is actually pretty confusing.
(imported from commit a58471172e28c039af8e290362e54b6660543924)
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 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)
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)
...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)
Tim Abbott
Kevin Mehall
Allen Rabinovich
Steve Howell
Leo Franchi
Zev Benjamin
Waseem Daher
Jeff Arnold
Michael McCanna
Keegan McAllister
Jessica McKellar