* Disable for search-like narrows (whitelist stream and home instead of
blacklisting topics and PMs)
* Use home view summarization flag for All Messages
(imported from commit 48bd10ae5da7c7564c2efe86a40078f1a7e96e20)
Don't warn when @-mentioning a bot on a public stream that it does
not appear to be subscribed to. It may be receiving those messages
anyway.
(imported from commit 4a00694942a721897a01736f48033c71048e0b16)
This doesn't address the more complicated case of someone @-mentioning
you on a muted topic, which consensus is you do want to get
information for, but we need to develop some infrastructure to present
that case to users clearly.
(imported from commit a4bc1e89c108fa8ba6eccc0a198eabf2231326ab)
Add the option "Narrow to just this message" to the chevron
menu. This has two use cases:
* It's an easy way to get a sharable URL for the message.
* It reduces distractions.
For now it is feature flagged to just customer12.invalid and staging.
See #1880.
(imported from commit 897d247176f9024ff825ccd3b338236569eed5ab)
Allow users to open Zulip windows in new tabs with command-click
from the left sidebar narrowing links and recipient bar
narrowing links.
(imported from commit d60c038c7bf1efccd461f5284d513b9cbfbdaebf)
If the user has text in the compose box, don't close or
change the compose box when they narrow.
(imported from commit f9b400f6bac37cb313f1fd87aadb3ba1d3a035ef)
For the two cases where narrowing should open the compose box,
we now put that logic inside of narrow.js.
(imported from commit 570e22e90c2f6d422ba71cce400c075f0b8adf51)
Handle closing the compose box inside of narrow.js, to
ensure consistent behavior for all the narrowing UI options.
(imported from commit f17a687491eb2361c73032cd974cedb2a0a2dd85)
The main user-facing feature here is that users can open narrows
in new tabs or windows. Internally, it makes the HTML more semantic.
One consequence of making these elements into actual anchor tags
is that clicking on them no longer triggers this logic to
close the compose box when you click outside of it:
// Unfocus our compose area if we click out of it. Don't let exits out
// of modals or selecting text (for copy+paste) trigger cancelling.
if (compose.composing() && !$(e.target).is("a") &&
($(e.target).closest(".modal").length === 0) &&
window.getSelection().toString() === "") {
compose.cancel();
}
Instead of patching the above code, I elected to just call
compose.cancel() explicitly in the click handlers for the links
themselves.
We are gonna try to clean up the compose-box behavior globally soon.
(imported from commit c9a01916f1714fe3dd495d25c78cd5e5532105ef)
Trac #1737
Firefox has the slightly broken behavior that it emits a click event on
the document when you right click, but not on any of the child nodes, so
our #compose stopPropagation doesn't stop right-click events from closing
compose. Chrome never emits click events on right click.
(imported from commit 2519c542715c93877b6d38e5dcff1f3e011688e4)
When decoding an operand, a + can be converted to a space
only if the operand is not an email address.
(imported from commit 08fc36a579bbe6409137c60c0fa9579fe3ab2c43)
It's a bit of a contrived use case, but you could make a topic
called "12345" and then mute it from the sidebar, and it would
crash inside Dict. We now call attr(), not data(), to avoid
string-to-integer conversions.
(imported from commit 89666f40d624df154d41077546e1c13a23ee7e67)
Before this change, you could narrow to an old topic, and it would
not show up in the sidebar unless it had unread messages.
(imported from commit f177a7378dac064e46a6417357cc86ada4475936)
The old code was looping through recent_subjects to find the
original subject name, but we already have logic in get_subject_filter_li()
to be case-insensitive. I tried this with various casings of topics,
narrowing to topics, as well as narrowing to a stream (so no active topic)
and narrowing to an old topic.
(imported from commit 1decde13477cb742fd4bc82798f1afb282182bdf)
Create our own objects for handlebars, so that we can add transient
flags like is_zero without worrying about side effects to other
code.
(imported from commit b351a369cb3f36233e108e270c7abdd4ab8c5860)
When we call rerender() on MessageList, it is usually because
something big has happened, so it's reasonable that the pointer
may now be invalid. As an example, the old pointed-to message
may been removed from the home view. We have always just
moved the pointer under the hood, but now we do it in a way
that doesn't generate spurious blueslip errors.
(imported from commit d399a101f36b744a423ea7da80dda8352440c6c9)
There is a scenario where we call process_read_message()
for a message that we haven't recorded as unread before.
I'm not sure how it happens, but I put back code to
guard against crashing. The regression happened in
5752458c821.
(imported from commit 5ce15d2e236b738b445ed88f1733aa0612be0ff3)
This fixes a blueslip error where we were trying to add the same
message into a MessageList twice. Muting complicates our duplicate
detection, because empty() can return true even when we already
are storing messages that just aren't shown (because of muting).
The name empty() should probably be fixed in light of muting,
but filtering with self.get() is not really a problem here.
(imported from commit 83b0890471c9a0aa21996f3d0d3be4a238f23e65)
We have been persisting muting preferences on the back end for
a while, but we haven't been adding them to page_params for the
client to have at reload/startup time.
(imported from commit d9ca68aa0e4d22bfb0e6ce67fc0bc63981175c8b)
With the muting/hiding features, it has become the case that
this._hash can have entries that don't map to actually visible
rows, so this.get() can return true on an id that shouldn't
actually be selected, causing downstream code to explode. Now
we call this.closest_id() regardless of whether the hash is
populated, to be safe, but then we still call blueslip.error
if the pointer moved.
(imported from commit 348e8ff67ce3a6d61aaeb31f80549386518af2d0)
If you have two browsers open for the same account, muting in one
browser will now be reflected in the other browser. This got
regressed when changing the approach from collapsing to hiding.
The new code should be less brittle, as we encapsulate re-rendering
in muting.rerender().
(imported from commit 4e65e265b64513d38f518770453b7436cb92b4ca)
Update get_counts() so that it ignores counts for muted topics
when calculating stream/home unread counts.
(imported from commit 9b4e4da4346c225c535e97d709d3dee032603cc5)
The indirection was more confusing than helpful, especially
since the function had side effects, despite its getter-like
name.
(imported from commit 85d9cf642b4177f62488136f0e0f7f6c9304942e)
After killing off unread_counts.stream, the only field of
unread_counts was "private", so I just made unread_privates.
(imported from commit 9678f5b03524afb883ec4fa638b059e698888e78)
The prior commit makes it so that we no longer use unread_counts.stream
in get_counts(). This commit removes the code that updates the
data structure.
(imported from commit 5752458c8212bf02cf9c8733ce349fc35b204a9b)
These two data structures are kind of redundant:
unread_counts['stream']
unread_subjects
We are deprecating the former. The latter is more flexible for
features like muting.
Now, in get_counts(), we compute home counts and stream counts
in the same loop that computes subject counts.
(imported from commit c8d0ea12a56d0128811e0aa165de9882546906a5)
Kevin Mehall
Jessica McKellar
Steve Howell
Leo Franchi
Luke Faraone
Allen Rabinovich
Waseem Daher