The streams:all adveritsement notice in search should only appear
after we've already received the response from the server, to avoid a
mix of problems ranging from misplaced loading indicator to scrolling
issues to the notice just being distracting while you're waiting for
the server to return results.
We need to add a pre_scroll_cont parameter to the message_fetch API,
since adding this notice would otherwise potentially throw off the
scroll positioning logic for which message to select.
Fixes#13441.
In 452e226ea2 and
648a60baf6, we changed how `search:`
narrows work to:
(1) Never mark messages as read inside searches (search:)
(2) Take you to the bottom, not the first unread, if a `near:` or
similar wasn't specified.
This is far better behavior for these use cases, because in these
narrows, you can't actually see all the context around the target
messages, so marking them as read is counterproductive. This is
especially important in `has:mention` where you goal is likely
specifically to keep track of which threads mentioning you haven't
been read. But in many other narrows, the current behavior is
effectively (1) setting the read bit on random messages and (2) if the
search term matches many messages in a muted stream with 1000s of
unreads, making it hard or impossible to find recent search matches.
The new behavior is that any narrow that is structurally a search of
history (including everything that that isn't a stream, topic,
pm-with, "all messages" or "private messages") gets that new behavior
of being unable to mark messages as read and narrows taking you to the
latest matching messages.
A few corner cases of interest:
* `is:private` is keeping the old behavior, because users on
chat.zulip.org found it confusing for `is:private` to not mark
messages as read when one could see them all. Possibly a more
complex answer is required here.
* `near:` narrows are getting the new behavior, even if it's a stream:
+ topic: narrow. This is debatable, but is probably better than
what was happening before.
Modified significantly by tabbott for cleanliness of implementation,
this commit message, and unit tests.
Fixes#9893. Follow-up to #12556.
The compose_state.recipient field was only actually the recipient for
the message if it was a private_message_recipient (in the sense of
other code); we store the stream in compose_state.stream instead.
As a result, the name was quite confusing, resulting in the
possibility of problematic correctness bugs where code assumes this
field has a valid value for stream messages. Fix this by changing it
to compose_state.private_message_recipient for clarity.
Fixes commit id 648a60baf6. When
allow_use_first_unread_when_narrowing() is false last message of
narrow is shown in view.
Comments rewritten by tabbott to explain in detail what's happening.
This commit was automatically generated by `tools/lint --only=eslint
--fix`, after an `.eslintrc.json` change.
A half dozen files were removed from the changes by tabbott pending
further work to ensure we avoid breaking valuable PRs with merge
conflicts.
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
With webpack, variables declared in each file are already file-local
(Global variables need to be explicitly exported), so these IIFEs are
no longer needed.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
When a user performs a search that might contain historical public
streams messages that the user has access to (but doesn't because
we're searching the user's own personal history), we add a notice
above the first search result to let the user know that not all
messages may have been searched.
Fixes#12036.
After migration to an ES6 module, `messages_read_in_narrow` would no
longer be mutable from outside the module.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Commit 02413f9a1b introduced a bug
where any code reaching `if(operators('search')` would be executed,
which caused inputs where we didn't have the search operator to
throw an error when we do not find a search operan later.
At least one affected cases was narrowing to an empty topic.
Modified heavily by punchagan to correctly handle narrowing to huddles, and
for `group-pm-with` narrows. Also, fixed broken tests in the original PR.
Closes#5876
Some search queries always return empty because of how we handle search,
this adds text that ensures users trying bad searches realize that they
are doing so.
This changes the "new private message" button to be instead "new
conversation" when looking at PMs, to avoid confusion that the button
was the right thing to do to reply to the current private message
conversation.
Fixes#11679.
Changed <h5> to <p>, and removed the special formatting of
.empty_search_text to make this more in line with the formatting we
generally use with empty narrows.
Also adds relevant tests and documentation. We currently
do not narrow to a new topic, and instead just narrow to
the stream. Similarly, we do not narrow to a PM if any of
the recipients are invalid.
Before this change, if you hit ESC, then hotkey
code would call search.clear_search, which would
call narrow.deactivate(), which would then use
`$('#search_query')` to clear a value, but then
let search.clear_search blur the input and
disable the exit button. It was all confusing.
Things are a bit more organized now.
Now the code works like this:
hotkey.process_escape_key
Just call narrow.deactivate.
$('#search_exit').on('click', ...):
Just call narrow.deactivate.
narrow.deactivate:
Just call search.clear_search_form
search.clear_search_form:
Just do simple jquery stuff. Don't
change the entire user's narrow, not
even indirectly!
There's still a two-way interaction between
the narrow.js module and the search.js module,
but in each direction it's a one-liner.
The guiding principle here is that we only
want one top-level API, which is narrow.deactivate,
and that does the whole "kitchen sink" of
clearing searches, closing popovers, switching
in views, etc. And then all the functions it
calls out to tend to have much smaller jobs to
do.
This commit can mostly be considered a refactoring, but the
order of operations changes slightly. Basically, as
soon as you hit ESC or click on the search "X", we
clear the search widget. Most users won't notice
any difference, because we don't have to hit the
server to populate the home view. And it's arguably
an improvement to give more immediate feedback.
If a user is narrowed by `is:private`, `pm-with`, or `group-pm-with`,
change the `New topic` button to say `New stream message` instead for
added clarity.
Also, add to the Casper and Node tests for this behavior.
Fix#9072.
When visiting a narrow like
https://chat.zulip.org/#narrow/stream/doesnotexist, grey-out the reply
button and add the title `There are no messages to reply to.`
Also, add to the tests for `narrow.js` with
`#left_bar_compose_reply_button_big`.
Fix#8547.
This allows several modules to no longer need
to import `narrow` (or, in our current pre-import
world, to not have to use that global).
The broken dependencies are reflected in the node
tests, which should now run slightly faster.
Following points have been implemented in this commit:
1.) Add search pill on selecting typeahead.
2.) Re-narrow after removing a search pill.
3.) Add quiet optional parameter to removeLastPill.
4.) Pre populate search pills in narrow.activate.
5.) Clear existing search pills on narrow.deactivate.
Description of above points:
1.) I tried out using the description from suggestions.lookup_table
to append a pill using appendValidatedData so that the description
had not to be calculated again. But the description in the suggestions
lookup contains html due to highlighting. This html is escaped when
inputed in a pill. An attempt was also made to remove the higlighting
by replacing the tags. But other espaced characters like < also
popped up, so it was better to use append_search_string.
3.) If one wants to refresh the pill using pill.clear and wants to
repopulate them, evaluating the event_handler associated with the
action of removing the pill may not be desired.
4.) Pill population code is added to narrow.activate. Pills are not
populated if the narrow was triggered by search as search handles the
addition and removal of pill by itself. The reason for not handling
search too in narrow.activate is to avoid clearing the pills and
repopulating them. Example of some of the triggers for narrow.activate
include `restore draft`, `topic change`,`sidebar`.
Also modifies tests for search.js
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.
Tim Abbott
Mohit Gupta
Anders Kaseorg
Vinit Singh
Anders Kaseorg
Rohitt Vashishtha
Puneeth Chaganti
SatyendraBanjare
YashRE42
Tim Wissel
Siddharth Varshney
Rishi Gupta
Steve Howell
Vishnu Ks
Shubham Dhama
Marco Burstein
Shubham Padia
Armaan Ahluwalia
Abhigyan Khaund
YJDave
Alena Volkova