Fixes#14971
Instead of taking user to top / end of fetched history, we take
user to the first / last message of the narrow.
We simply check our cached history if we have the data for the
jump, if not, we ask server for the data.
Tested by simply pressing `fn + left / right arrow` on mac in
combined feed and topic narrows. Also, reduced message_fetch
constant values to be all single digital to check if the -
data not in cache -> fetch data -> select message logic works well.
This correctly avoids pageup/pagedown scrolling past already rendered
content, while also always making progress, which the previous logic
introduced in d8ec141de2 might do, at
least in degenerate cases with very small render windows.
I'm not sure this change has any effect in practice with current
render window values, but it does fix a bug if I set the maximum
render window size to 20.
The previous batch of improvements to this code path in
6562ea94e4 introduced a race bug where:
- You navigate to a narrowed view; Zulip renders cached data from
`all_messages_data` that we know is current, but
`fetch_status.has_found_newest` is initialized to `false`
nonetheless.
- The bottom is visible, triggering the check for whether the view
should be marked as read.
- `fetch_status.has_found_newest` is still `false`, and so we
incorrectly refuse to mark as read.
- We finish fetching data from the server, do the background rerender
for that (with no changes), but that doesn't trigger a re-check for
whether the bottom is visible.
There's several ways to address this, but most correct to me is to not
check fetch_status in this particular code path.
The same reasoning applies to the navigate.js call sites.
I was not able to reproduce obviously badly broken behavior from these
logic bugs, but after the renaming of message_viewport helpers in the
last few commits, it's clear that this logic was trying to check if
we're actually at the start/end of the possibly message feed, not just
the rendered portion, and doing so incorrectly.
The previous logic for both scrolling down and using pagedown would
incorrectly mark an entire conversation as read when reaching the
bottom of a render window, even if there were more messages loaded or
to fetch from the server.
Fix this error in the calculation by asking the correct data
structures if we're actually at the bottom.
To avoid the navigate.js keyboard shortcut code paths circumventing
this new logic, or needing to duplicate it, they now call
process_visible, rather than its helper.
Replaced all instances of `safeOuterWidth()` and `safeOuterHeight()`
methods from the codebase with the safe counterparts `outerWidth() ?? 0`
and `outerHeight() ?? 0`. Removed custom safeOuterWidth/safeOuterHeight
method definitions from global JQuery object instance.
This function will allow us to adjust the codebase to write what it
means semantically -- whether a check is for the message list being
visibly empty, or completely empty.
In this commit, we leave the .empty() method incorrect, because
several other adjustments need to be made atomically with fixing it.
Ever since we started bundling the app with webpack, there’s been less
and less overlap between our ‘static’ directory (files belonging to
the frontend app) and Django’s interpretation of the ‘static’
directory (files served directly to the web).
Split the app out to its own ‘web’ directory outside of ‘static’, and
remove all the custom collectstatic --ignore rules. This makes it
much clearer what’s actually being served to the web, and what’s being
bundled by webpack. It also shrinks the release tarball by 3%.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Anders Kaseorg
Aman Agrawal
Varun Singh
Tim Abbott
xoldyckk