We now use narrow_state.filter() everywhere. The
two functions did the same thing, and I slightly
prefer the concise name, which was already in use
in lots of places.
This commit prepares the frontend code to be consumed by webpack.
It is a hack: In theory, modules should be declaring and importing the
modules they depend on and the globals they expose directly.
However, that requires significant per-module work, which we don't
really want to block moving our toolchain to webpack on.
So we expose the modules by setting window.varName = varName; as
needed in the js files.
We had a significant amount of code for handling what seemed to be 2
cases, but which were really just a single case (if we are trying to
narrow to a specific message ID, and we end up landing on it, restore
the previous offset; with the special case that the previous offset
might be passed in from the previous call).
This cleanup also fixes a very minor bug, where our background
auto-reload (`reload.initiate({immediate: true});` in the JS console)
would incorrectly reset the pointer position to match the a near:
message ID if that was present in the narrow.
This commit fixes a couple regression related to narrowing.
For a long time we've had bugs where we too aggressively
preserve the currrent selection on topic -> stream
re-narrows ("s" key) even when the wider narrow may
have unread messages before the selection.
Also, we recently introduced a bug so that when you used
a link from the "copy link to conversation" (aka a "near"
query), it would advance you to your first unread message
despite the near:999 specifier. (The code would work for
subsequent "near" queries once you had fetched some of
your original messages).
This commit introduces a new data structure called id_info (replacing
the select_strategy data structure) in various functions and uses that
to track all the ids of relevance.
Significantly rewritten by tabbott to handle a few extra corner cases,
and add a ton of comments explaining why it works the way it does.
Fixes#2091.
Fixes#9606.
The "if" condition that was removed in this commit
is no longer needed, since the called code now
handles the cannot-apply-locally use case. (We
wanted the called functions to be defensive, so
they already were effectively handling the conditions
anyway, and recent commits has them returning
appropriate values and doing the right things.)
We had debug code that was reaching into msg_list._items when
it could use msg_list.all_messages() instead.
When we split out MessageListData, using _items started
breaking this code.
We now work with MessageListData objects while populating
data from local narrows, before actually making the
wrapper MessageList object.
This change will simplify unit testing (less view stuff
to fake out) in certain situations.
It will also allow us to eliminate the delay_render flag.
We used to have positional parameters for table_name
and filter, but we don't use them for message_list.all
and we're about to replace filter in some cases.
Passing everything in on opts is more consistent and
self-documenting in the calling code, plus lots of
unit tests can get away with passing in `{}` now
for situations where table_name does not matter.
All of our callers pass in muting_enabled, so we
remove the default value for it. And then the
collapse_messages variable doesn't have to live on
`this` as it's only being passed through down to the
view.
We now only preserve the offset for the previous
selection (pre-narrow) if that is still the id
we want selected after calling maybe_add_local_messages.
Right not this does not change any behavior, but
upcoming changes to maybe_add_local_messages will
change the selected id to the first unread message
in certain circumstances, in which case preserving
the offset will possibly be confusing, since you're
not on the same message.
This is preparation for enabling an eslint indentation configuration.
90% of these changes are just fixes for indentation errors that have
snuck into the codebase over the years; the others are more
significant reformatting to make eslint happy (that are not otherwise
actually improvements).
The one area that we do not attempt to work on here is the
"switch/case" indentation.
For a commit that was just merged I had the "back-out" case
at the wrong nesting level. It was a pretty obscure failure
scenario that never came up in practice, but basically if you
were starting at a message that was not in your narrow, but
we did have some messages in your narrow, we would try to
go near the old message instead of talking to the server to
find the next unread message in that narrow.
Barring a few minor edge cases, when we now do a narrow
that is based on a sidebar-like search (e.g. stream/topic,
no extra conditions), we now go directly to either the
first unread message we know about locally or the last
message if we're all caught up.
We of course used to do this in master until recently; this behavior
was broken by Tim's narrowing refactor branch (ending with
26ac1d237b) which moved us to always
using the select_first_unread flag, by default (fixing issues where if
you clicked around while your pointer was behind, you'd land in the
wrong place).
We now have arguably the best of both worlds:
* The pointer is not considered when computing narrowing positioning
* We only go to the server for sidebar clicks if the data isn't
available in the browser.
This is purely to make it easier to read narrow.activate()
without having to page past lots of unnecessary detail when
you're trying to understand things like how we set the
selection.
The maybe_select_closest helper, when first introduced, was
tiny and close to its callers.
As it's grown, it's become kind of a big hurdle to reading
narrow.activate(), because it's out of chronological order
and it's hard to tell at a glance which variables it's closing
on.
Now we just move it out to module scope.
It's mostly moving code, with these minor changes:
* we pass in opts for the old closure vars
* we rename then_select_offset -> select_offset
* we early-exit on empty lists
We replace these variables in narrow.activate:
then_select_id (int w/-1 as a sentinel)
select_first_unread (boolean)
The main goal here is to get away from the boolean, since
we are about to introduce a third select strategy.
The new var is select_strategy and it has a union
type with these flavors:
"exact" (was select_first_unread === false)
"first_unread" (was select_first_unread === true)
The new flavor will be something like "last_id".
Eliminating then_select_id is also nice, since the -1
sentinel value could be a pitfall, and it's semantically
cleaner to encapsulate behind a check for
select_strategy.flavor.
We use an IIFE (immediately invoked function expression)
to fetch messages. This will allow us to introduce some
local vars in a subsequent commit without creating an ugly
diff and without cluttering an already crowded namespace.
This cleans up a subsequent diff. Within the context of
`maybe_select_closest`, there's only one `msg_id` we care about,
so the more convoluted name `then_select_id` makes much less
sense than it does in the enclosing scope, and it will make
even less sense after some future changes.
There's also some cosmetic cleanup here.
When we are deciding whether to preserve scroll position, we
mainly care that then_select_offset is set to a value. If
we had no intention of preserving scroll offset, we would have
never bothered to set it. The check for !select_first_unread
is always redundant, as verified by lots of clicking around
with some print debugging. And it's a brittle check,
because it couples the decision of scrolling destination to
the mechanism by which we decide our selection. While those
things are closely related, it's possible in the future that
we'll decide to advance to an unread message and still want
to set then_select_offset, but we might forget to mutate
select_first_unread.
Long story short, the code is simpler and safer now.
We move the var declaration of then_select_offset closer to
where it gets calculated, and we avoid code duplication in
calling current_msg_list.get_row().
Even when then_select_id has the sentinel value of -1, we were
trying to look it up in our message_list.all object. This would
have returned undefined, which is fine, but it's more explicit
to just bypass the check.
This mostly sets up the next commit. The two conditions here
are both inexpensive to check, but we want to bypass an upcoming
expensive operation if can_apply_locally() returns false.
We consistently either pass a `then_select_id` into narrow.activate,
or were using the select_first_unread option. Now, we just compute
select_first_unread based on the value of then_select_id.
In the very early days of Zulip, we didn't have unread counts; just
the pointer, and the correct behavior when opening a new tab was to
place you near the pointer. That doesn't make any sense now that we
do have unread counts, and this corner case has been a wart for a long
time.
This commit does the main behavior change here. However, there's a
bug we need to fix, where we might end up trying to pre-render a view
of the narrow based on the `all_msg_list` data before `all_msg_list`
is caught up). We need to fix that bug before we can merge this; it
should be possible to determine that using `FetchStatus` on
`all_msg_list`, or with better performance by using the `unread_msgs`
structure to determine whether the message we should be selecting is
present locally.
Fixes#789.
Fixes#9070.
Apparently, we were incorrectly passing through something related to
opts.use_initial_narrow_pointer as the value for `use_first_anchor`.
If you read the logic in narrow.js carefully,
use_initial_narrow_pointer was unconditionally false.
The correct value for this attribute is when we're trying to narrow to
the first unread message in a given context. There are two things to
check:
* then_select_id is -1; i.e. we don't have a specific message ID we're
trying to narrow around.
* select_first_unread is True, i.e. we're trying to narrow to the
first unread message.
A bit more work should allow us to get rid of the second condition,
but I'm not quite confident enough to do that yet.
The refactor in 12509515ae had a subtle
bug, which is that we switched from accessing the message list "this"
(aka the message list being rerendered) to current_msg_list. This
meant that when the narrowed_msg_list was in view and code needed to
modify home_msg_list, we accessed the wrong `selected_row` to preserve
the scroll position of (namely, the one in current_msg_list, not the
one in home_msg_list).
Fix this, by moving the function to be a property of the
message_list_view object, which makes more sense structurally, anyway.
We may, in the future, want to do a similar migration for more of
message_viewport.js.
Fixes#8854.
Fixes#8965.
Mark_message(s)_as_read is used in marking a message as having been
read by the browser, rename it to notify_server_message(s)_read to
avoid any confusion.
Previously, when unnarrowing, we were calling this on the wrong
selector (this was missed years ago when we refactored Zulip to use
divs rather than table rows in the main message feed).
Noticed while debugging #5312.
We now attach a fetch_status to message lists, so that they
can track their fetch status individually. When you go
back in a narrow and get all the older messages, we turn
off future fetches.
The narrow.js code no longer needs to orchestrate anything
here. The "home" message list won't have as many redundant
fetches after this commit, because we don't need to reset
flags every time we do `narrow.deactivate`.
And then actual narrows get a new message list every time
you narrow, so their fetch status gets reset implicitly
as part of constructing the MessageList object.
We are going to remove message_fetch.reset_for_narrow() soon,
but its callers probably still want to hide any scrolling
indicators, and we just let them do that directly.
This helps us consolidate the fetching constants without
having to export them. It will also remove some
responsibility for narrow.js to track fetching state.
This mostly moves code from ui.js.
We change the arguments to `message_fetch.load_more_messages()`
to be `opts` with callbacks for `show_loading` and `hide_loading`.
We also defer starting the scroll handler until `message_fetch.js`
has been initialized.
This works simimlar to the "n" key for next topics.
This commit does a few things:
* It wires up the hotkey to an existing function
that could change narrows.
* It adds documentation.
* It adds logic to make sure the compose box does
not open.
@showell helped a bit with the wording of comments here.
Fixes#4874
This commit prefixes stream names in urls with stream ids,
so that the urls don't break when we rename streams.
strean name: foo bar.com%
before: #narrow/stream/foo.20bar.2Ecom.25
after: #narrow/stream/20-foo-bar.2Ecom.25
For new realms, everything is simple under the new scheme, since
we just parse out the stream id every time to figure out where
to narrow.
For old realms, any old URLs will still work under the new scheme,
assuming the stream hasn't been renamed (and of course old urls
wouldn't have survived stream renaming in the first place). The one
exception is the hopefully rare case of a stream name starting with
something like "99-" and colliding with another stream whose id is 99.
The way that we enocde the stream name portion of the URL is kind
of unimportant now, since we really only look at the stream id, but
we still want a safe encoding of the name that is mostly human
readable, so we now convert spaces to dashes in the stream name. Also,
we try to ensure more code on both sides (frontend and backend) calls
common functions to do the encoding.
Fixes#4713
This helper function will allow us to cycle through PM narrows
that are unread, once we map it to a hotkey and/or other UI.
(We intend to make something like the "n" key for topics, but
that works on PM narrows instead.)
We made this change because users often unnecessarily click "Home"
first in their use of Zulip, because it seems appealing. While "All
messages" isn't quite precise (it doesn't include muted streams), it
does describe relatively simply the interleaved view that this
represents.
This commit leaves everything as "home" in the code, and only changes
user-visible strings and docs. Changing the code will be a big project;
there are hundreds of relevant occurrences in variable names, etc.
Further, we'll probably want to convert those various variable names
in different ways.
Tweaked by tabbott to extend the commit message and update a few comments.
This allows user to view all group private conversation messages
with a specific user. That is, it views all the the group private
messages from groups which include the given user.
Add search suggestion for group-pm-with. Add operator name
and description in "Search operators" tab.
Add change in tab name to "Group Messages" when using this operator.
Add frontend_tests for group-pm-with search operator.
Fixes: #3882.
We now use similar code for A/D hotkeys as we do for the "n"
key.
The old code was using jQuery operations that got tripped up
by our splitters between active and inactive streams.
Fixes#4569
Here are the functions in top_left_corner:
get_global_filter_li: pure code move
update_count_in_dom: simplifed copy of similar function in stream_list.js
update_dom_with_unread_counts: pure code move, split out from function
of same name in stream_list.js
delselect_top_left_corner_items: pure code move
handle_narrow_activated: pure code move + rename
handle_narrow_deactivated: pure code move, split out from from function
of smae name in stream_list.js
Previously, when you switched to a stream narrow with the central
message outside the range of messages cached in the browser, we would
reset the UI for loading more messages, but not actually reset the
state for whether it should be possible.
This seems to have been an oversight in refactoring back in 2014.
Fixes#6109.
The narrowing option from_reload was only used in
conjunction with use_initial_narrow_pointer, but the
latter option already takes into account whether a
reload happened.
This fixes a regression where we removed a call to
unread_ops.process_visible() inside of stream_list.js. Now
we call it from within narrow.activate() in the the
maybe_select_closest() callback.
The function modals.is_active() can see if modals are open
without having to look at the DOM. This should make it snappier
to type in the compose box. Even if the speedup is pretty minor,
not having to worry about jQuery slowness should make it easier
to diagnose future compose box issues.
The new function gets used in other places, too, where performance
isn't so much an issue.
Despite the length of this commit, it is a very straightforward
moving of code from narrow.js -> narrow_state.js, and then
everything else is just s/narrow.foo()/narrow_state.foo()/
(with a few tiny cleanups to remove some code duplication
in certain callers).
The only new functions are simple setter/getters that
encapsulate the current_filter variable:
narrow_state.reset_current_filter()
narrow_state.set_current_filter()
narrow_state.get_current_filter()
We removed narrow.predicate() as part of this, since it was dead
code.
Also, we removed the shim for narrow_state.set_compose_defaults(),
and since that was the last shim, we removed shim.js from the app.
This commit extracts the method compose_actions.on_narrow()
to handle changing the compose box (as appropriate) after
any narrowing action.
This change should be mostly non-user-facing, but it's not
exactly a trivial extraction.
For the case where the user already had content in their
compose box, we continue to leave the compose box alone,
but we now update compose fading 150+ lines later in
narrow.activate().
Likewise, for cases where we cancel composing, this will
also happen later in the function.
Finally, for PM narrows, where we auto-open the compose box, we
no longer call compose.cancel() before calling compose.start(),
because either a) the compose box would have not been open
in the first place or b) the start() function can handle
clearing the old fields.
We now auto-open the compose box whenever somebody narrows to
a "pure" PM narrow. We already did this for buddy list clicks,
so this make it work the same for other ways of narrowing to
PM conversation. Here, we optimize for composing, vs. reading,
since PM conversations tend to have lots of back and forth.
(Contrast this to stream conversations, where there's a higher
likelihood of lurking or doing a quick narrow to re-read some
message from the stream.)
We don't want to auto-open the compose box for topic
sidebar clicks, because we want to convenience folks
reading messages, not writing messages, since on
stream narrows, people tend to do much more reading
than writing. (Also, opening the compose box explicitly
is super easy.)
The part of this change that affects behavior is that
we remove the call to compose_actions.start('stream').
Then the simplification is that we replace the checks
to narrowed_by_reply() and !narrowed_to_topic() with
a single call to narrowed_by_pm_reply().
Fixes#3886.
This fixes the mobile web experience for Chrome on iOS.
Apparently, Chrome-on-iOS silently has a `viewport` module that
overrides and user-defined module by that name, causing all of our
code that accesses the viewport module to not work on that platform.
We fix this by renaming it.
The slugs for PM-with narrows now have user ids in them, so they
are more resilient to email changes, and they have less escaping
characters and are generally prettier.
Examples:
narrow/pm-with/3-cordelia
narrow/pm-with/3,5-group
The part of the URL that is actionable is the comma-delimited
list of one or more userids.
When we decode the slugs, we only use the part before the dash; the
stuff after the dash is just for humans. If we don't see a number
before the dash, we fall back to the old decoding (which should only
matter during a transition period where folks may have old links).
For group PMS, we always say "group" after the dash. For single PMs,
we use the person's email userid, since it's usually fairly concise
and not noisy for a URL. We may tinker with this later.
Basically, the heart of this change is these two new methods:
people.emails_to_slug
people.slug_to_emails
And then we unify the encode codepath as follows:
narrow.pm_with_uri ->
hashchange.operators_to_hash ->
hashchange.encode_operand ->
people.emails_to_slug
The decode path didn't really require much modication in this commit,
other than to have hashchange.decode_operand call people.slug_to_emails
for the pm-with case.
This experiment has been disabled for everyone for a while: if we
bring something like this back, it is not likely to be exactly the same,
and will be different enough to require a different implementation.
As it is, the summarization code was making a few code paths (rendering
especially) more complex, and is worth removing for simplicity's sake.
(imported from commit 6ac8cdc9f7077a5a1da01ab4268aba3db0bc43f8)
Previously, we saved the current_msg_list selected id and then
restored it as the home_msg_list selected id, which could result in
the home view loading to the wrong place.
This takes some already bad code and makes it even more in need of
refactoring, but it does fix a pressing bug. We should definitely
refactor both:
* the top of narrow.js
* the save/restore code in reload.js
after this, though.
(imported from commit bb2040219e4f545ba90bb04a696996cec2831484)
This does have a small functional change of using use_closest even for
the current_msg_list.last().id case, but that's harmless; and it does
reduce a lot of code duplication and confusing logic here.
(imported from commit 7c4ecaa197120cc6d5c05ce4887f33c7d94a9c59)
This implementation is somewhat hackish in large part because I think
we're going to be wanting to redo the get_old_messages API somewhat
soon, and this may naturally become a lot cleaner as a result, but
this isn't a lot of code and fixes#2235 part (A) and substantially
mitigates #1510.
(imported from commit 47a2160a44befa9d83190c5cc95b90e92cc5b4cc)
Even in the case where we are running embedded narrows,
we want narrow.operators() to return new-style operators
that you get with Filter objects, so that callees do
not need to support the legacy tuple format.
(imported from commit a6649881a926a2304e9f7cc8ca53b406e2c8828e)
Have narrow.activate() user filter.operators() to produce
operators that have operand/operator fields, so that its callees
don't need to be backward compatible with the tuple format.
(imported from commit e408e33074d1be2d112bb3cdc081ec3616c908ee)
Change the offset to hold of the selected message as an offset from the
top of the screen. Then use the current offset and scrollTop to compute
the new scrollTop.
(imported from commit 718e95d3435c0f84cbb7663a9bb2bc2789314203)
Our logic for unnarrowing when messages were read during the narrow
did not properly use the then_scroll option and thus actually set the
scroll position when they selected a new message. This was
accidentally prevented from being a big problem by the incorrect
scrolling logic that was fixed by:
Only preserve_pre_narrowing_screen_position when preserving pointer.
which caused the browser to scroll _back_ to close to the correct
scroll position (but not the intended scroll position -- it would
usually be a little bit off).
(imported from commit d779de8f89590d242f62d32b22a297bdc096c594)
I think that this will fix the issues we've been having with
hashchange.save_narrow() screwing up the scroll position in the page.
(imported from commit 25af9b7dda2d107220e11dd12b9dc344bc63addc)
Features:
* Only shows messages in the narrow
* New messages in the narrow will arrive as they are sent
* Works even for streams you're not subscribed to
* Automatically subscribes you to a stream on send
* Doesn't update your pointer
* All searches etc. automatically have the narrow added
(imported from commit 2e12b76849f6ca0f53dda5985dad477a04f7bbac)
Trying to condense messages when they are not yet visible just
leads to wasted effort and wrong results.
This commit makes it so that current_msg_list always points to a
visible list, so the code related to message rendering knows when
to call ui.condense_and_collapse(). For activating narrows, we
now let rendering handle the condense/collapse case.
The home view situation is a little trickier, because we render
new messages in the home view even when we're inside inside of a narrow,
presumably to make it fast to switch into the home view. When
we actually go back to the home view, we need to sweep for messages
that might need to be condensed, since they have been originally
rendered while the home view was not visible.
(imported from commit 4da2d278a4353e9e0c2b98cbf8c9dd03b06cd59b)
There are now 2 cases for narrowing:
1. We narrowed, but only backwards in time (ie no unread were
read). In this case, try to go back to exactly where we were before
narrowing. This behavior is unchanged.
2. We read some unread messages in a narrow. Instead of going back to
where we were before the narrow, go to our first unread message (or
the bottom of the feed, if there are no unread messages). This is new.
This means that after catching up through the sidebar, on returning
home you'll be at the bottom of your feed.
Searching for the first unread message in a message list with 40,000
messages only takes 17ms according to:
function timeit() {
var t0 = new Date().getTime();
_.find(current_msg_list.all(), unread.message_unread);
var t1 = new Date().getTime();
console.log('Find first unread: ' + (t1 - t0) + ' ms');
}
(imported from commit 87c467578a2cced0aa976d8ae2924371b85d2445)
Steve Howell
Armaan Ahluwalia
Shubham Dhama
Tim Abbott
Shubham Padia
Abhigyan Khaund
YJDave
Rishi Gupta
Alena Volkova
Cory Lynch
Abhijeet Kaur
Steve Howell
Vaida Plankyte
Cynthia Lin
Rohitt Vashishtha
Mahim Goyal
fionabunny
Elliott Jin
sinwar
AZtheAsian
Tommy Ip
Tim Abbott
Kartik Maji
Vishnu Ks
Aristeidis Fkiaras
Liz Sander
Steve Howell
Leo Franchi
Tim Abbott
Jason Michalski
Jessica McKellar