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)
This was not totally effective, and with the previous commit it is no longer
needed.
This reverts commit e86c0b653669cf86b0d8956c2c85eb7610fc342f.
(imported from commit 0de5bfec87147b1336f6f79c33d4e32493e1e508)
feedback-bot and zephyr_mirror will need to be updated and restarted
when this is deployed to prod.
(imported from commit fe2b524424c174bcb1b717a851a5d3815fda3f69)
in the narrowed view, not messages older than the oldest message in
the home view
Tim provided most of the code for this patch
(imported from commit ec0bbfd344cac351f56a456fc560848603721135)
load_old_messages cares whether it is acting on behalf of a narrow
(for_narrow) not whether it is acting on behalf of a button push.
(imported from commit 16c00e015478f94f0631e211a92a7066a38135a8)
This restores the time-travel functionality and fixes Waseem's laundry
list of problems with its original UI.
(imported from commit e30e02c25af994435adb815d26284b3669c945a4)
This was causing glitching where if you narrow so that zfilt has only
one message, and add messages on top (e.g. via get_old_messages), and
then add messages on bottom (e.g. by receiving one), we end up with
the bookend row missing. One can make this happen with narrowing,
but, this situation happens every time with time travelling.
(imported from commit 71d85980d8aa9431a17b33e9e5111fd3f76cecf3)
If the message doesn't exist, rows.get returns an empty jQuery object, not
'undefined'.
(imported from commit 40620f3e4853a662cb93939bf7f0695f81298777)
This is so we only send a single pointer update when the user scrolls
through a bunch of messages at once.
(imported from commit 20d239d7179e5f57ada99968361a0f9b7b18c591)
(But don't actually make it work yet -- that's for the next commit.
This makes the diff a bit easier to review, since it's really just
code moving from composebox_typeahead to typeahead_helper, and the
appropriate changes in zephyr.js, rather than code moving AND
changing)
(imported from commit 5cb2e836eeb8807f4eb98424558702d44a0e2b70)
The main problem with this code is that the error message doesn't go
away until you reload. To fix this, we need to add a noblock option
on get_updates.
(imported from commit dc45af397bcf06a218bda5dd224ebd5fdf3462db)
The reproducer for the issue here is:
- Scroll to the top of your feed
- Click on a stream name
- Open a popover
- Click on a subject name
- Note that your old popover doesn't go away, and that you can open
a new one.
The problem was that when we narrow, we call jQuery.empty() on the
zfilt table. That not only removes nodes but also clears event
handlers and jquery data. Thus, even though we have a reference to
the old popover element in the ui module, the element has forgotten
it had a popover. When we call .popover("destroy") it actually
creates a new popover, but never shows it.
(imported from commit 9721d60c78549bd2362833590b304952f2bdef2d)
The problem seems to be caused by a bug in Firefox. We work around
the issue by adding empty table rows to the top of the table and
removing them when the user is idle.
This resolves trac #413
(imported from commit 2b15a4a2241bd7e813800a42608d650e0d4fa4f0)
Previously, it was impossible to narrow to a completely empty narrow.
Now it is possible, and the code needs to be tweaked in a few ways
not to break in this case.
(imported from commit e4dd4159ad52d003fc11d0b8b6531322c12a3de8)
Previously, we were adding those narrowed messages to message_dict the
first time, and thus totally skipping those messages each additional
time you tried to "load old messages" on that narrow.
(imported from commit 77eef376e1165b86e3c599608a1b5089a09d51e0)
