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)
I'd also like to add a database table to actually store the values
that we get out of this and our send message requests for future
inspection, but for now, grepping logs+statsd is good enough.
(imported from commit 99ef179651850217fe6e82c5e928d122ca91101e)
I renamed ui.process_condensing() to ui.condense_and_collapse(),
and, more importantly, it now takes a list of elements, not a single
element, which allows us to do some computations outside the loop.
(imported from commit d5984088030c2a0d4ec8b258c7fcec3e84caf2b1)
If we load a browser window in a narrowed view and then un-narrow
before the home message list has loaded, we end up attempting to
select message ID -1 from home_msg_list even though it is empty,
triggering a traceback.
(imported from commit eb8b686f6e9c1fa518028e5755ac6196781e92d7)
Cory Lynch
Abhijeet Kaur
Tim Abbott
Steve Howell
Steve Howell
Vaida Plankyte
Cynthia Lin
Rohitt Vashishtha
Mahim Goyal
fionabunny
Rishi Gupta
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
Jeff Arnold