I added comments to the section of the template that generates
recipient bars for stream/topic messages.
(imported from commit a7ea9353dc5db20db3410b9566f5e0d670eff31f)
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)
I'm not saying it's beautiful, but prior to this we bolded
the topic name, but we didn't bold the stream name or user name.
Now we uniformly bold the name of the thing you're taking
action on.
(imported from commit f48b9d267b73858263541a905f6fd7fd626068ba)
There's one place where we don't really get this right, though,
which is the Streams page -- there's still a checkbox labeled
"include in home view".
I'm basically OK with that.
(imported from commit 55319b57f0c3d005a9937258a55254b9a91ce6ae)
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)
Steve Howell
Jessica McKellar
Allen Rabinovich
Leo Franchi
Kevin Mehall
Waseem Daher