If we have removed a stream from the home view, and our pointer
that we load from the server refers to a message that is no longer
visible, we don't want to error out but rather select the nearest
message to our previously selected one.
(imported from commit d212f1fba7b06836d1d916b43042991625b6f41e)
Messages are now selected on a MessageList, which triggers a
message_selected event that other parts of the code can listen for.
(imported from commit 1da9e4121425c0ac4461b41b7aea169072e1512b)
Right now the MIT realm has pretty bad UI lag with 1,200 messages loaded. We
need to fix the root problem, but this commit at least makes reloading the page
a satisfactory remedy.
(imported from commit 93d47710891cfc4db9fa00beaa5ccd10113aa1c3)
This commit just moves time rendering logic to its own file, and does
not make any functionality changes.
(imported from commit d111d03c6abc8d9550fcf65e4f89eab8056d1ed4)
This is accomplished by continuning to have per-conversation PM counts
but then summing them up into a global count.
We may split this off into per-conversation counts in the future.
(imported from commit 311e3b74715c3a01c0b75837e397a386ab65505c)
(And to let you know that it's OK that you have no messages.)
This fixes Trac #850 for the case where you first log in.
(imported from commit 47741856e34f67bfc2cc91bdc21def75ab6fe09d)
The message timestamp is now always clickable, and the popover contains the
full long-form date and time. This addresses one problem from usability
testing (see #470).
(imported from commit ad502dff128ad1c934fc0d3faaf5e2931c91c37e)
The interface is a little messy because so many of the inputs change
-- we need to better organize all these variables under centralized
'zfilt' and 'zhome' headings.
(imported from commit b247e86bf63ea2ea2c0d42ef23e8af0ce288d5dd)
So here's the reproduction recipe:
(1) Find a narrow that doesn't have any messages since 4 days ago
(2) Directly visit that narrow in your browser (or wait for someone to
do a deploy and thus auto-reload)
(3) Wait until load_old_messages has been called at least once
(4) Un-narrow
(5) Scroll up, and notice that the 400 most recent messages are above
sets of older messages.
The cause is that the code in add_messages assumed that
selected_message_id was within the range of message already in the
home view. This is true in most cases where add_message is being
called, but it is not true in the case that the user was in a narrowed
view containing only very old messages (And thus selected_message_id
would be older than everything in the home view).
We can fix this by tracking persistent_message_id separately and using
that for the relevant test in add_messages.
(imported from commit f0da2561ba68f729343b260adc398029fae6acf7)
If get_updates requests a message ID that is too old, Tornado will
return a 400, and currently the only way to start caring about newer
message IDs is to reload.
(imported from commit 1638d71868475ffd793162afc7a2731cab14bd75)
If you create a spinner in a hidden element and then show the
element, the spinner is placed differently than if you had created
the spinner while the element was visible. This commit makes it so
that we never create spinners while their parent is hidden.
(imported from commit a21e68976d70fcceece30ee35f5e7cf6f9490497)
/?lurk=foo will show all messages to the stream "foo", regardless of
whether you're subscribed.
(imported from commit 049d98b3ee8df19ef0a9dc392ae941dd463f8dd5)
It's possible for selected_message_id to not exist in zhome. For
instance, when you open the page to a narrowed URL, there is a race
between loading the narrowed messages and loading all your
messages. If the narrowed message request completes first, it will
update selected_message_id to your initial_pointer if the latter
happens to be among the narrowed messages. Even if it is not, you can
select a message by clicking on it before the zhome request finishes.
Then the old code would never add that selected_message_id to the
zhome table, so it wouldn't show up in the Home view or if you
re-narrowed.
I'm pretty sure there are still cases where the selected_message_id
might be outside the range of messages in zhome, in which case adding
to zhome might put old messages at the bottom. I observed this twice
on staging but was unable to reproduce it consistently.
(imported from commit 162feff3090f8806cc67140db0cfabb6e965aece)
Putting update_floating_recipient_bar in the old location caused it to
be called on every single keypress, which is unnecessarily
expensive. Instead, just call it once when we think we might actually
need it: after initiating a narrow.
(imported from commit a6c1518c4001a2dde44d7b512236795da3ccd351)
There's this very edge-case issue which is: if you go to the top of
the page and narrow to something other than the top message, the
floating subject bar does not update.
Why? Well, the way that the narrowing code works is that it sets up
narrowing and then calls
select_message_by_id(target_id, {then_scroll: true});
so that our selected message is in the view.
This in turn calls select_message, which calls recenter_view as
appropriate. This usually causes a scroll action, which in turn causes
the floating recipient bar to be updated.
But when we're at the top of the page, recenter_view doesn't need
to scroll at all! So the bar remains un-updated. Here we explicitly
update it to guard against that case.
This fixes Trac #651.
(imported from commit 6633cc8a81aedcbb31b30d7c1f27816f8808c700)
And change the color to a more thematically appropriate blue.
The shadow pointer is sort of confusing; we should really provide some
different sort of indication that your pointer is potentially moving
on narrow-and-unnarrow. (I think my fade-in-fade-out later in this
commit series is a not-bad first crack at this.)
Resolves Trac #472 - Dual pointers in narrowed view can be confusing
(imported from commit 2450517d99de85ade1c0e98c5510b59e70282451)
Alternatively the server could return a successful result with an empty list of
messages. But I prefer the solution in this commit, because it would allow us
in the future to warn the user about the problem. It does allow users to
determine if a given stream exists, but we haven't tried to hide that
information so far.
(imported from commit a91e12c90b12d3c870c0b637c3f1d6d3cef88491)
We were submitting a 'last' value of -1 to the server at startup,
which is invalid but normally ended up being OK because the user
usually had no messages whatsoever or had last be updated via
get_old_messages before the get_updates call went through.
(imported from commit df55ac1cdac443721c06ebed94a1c4b3ec7af2d1)
Jessica McKellar
Zev Benjamin
Leo Franchi
Keegan McAllister
Reid Barton
Luke Faraone
Waseem Daher
Tim Abbott
Jacob Hurwitz
Jeff Arnold