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 a user types "/me runs to the store", we put "runs to the store"
in bold after their name.
(imported from commit fbc11e99244e1c8fa1c03e4753e706957fcd449e)
This is unnecessary without summarization and has a performance
impact on scrolling.
This reverts commit 6270a33ff0fe98fc901b687ca533ef0ea127d052.
(imported from commit ac328a9fe344adfaf1cc1822cd58bc9178ae1a33)
This reverts commit c10d9c1a0d23891acce88bf8d79866c08cb75681.
This reverts commit 9259a246946cd968a8725c38ff5ef2d4b4793717.
(imported from commit 50e9e0136c2487cc63d75ae2b78df0c70a1b0be1)
When we add starring of historical messages, they'll get added to the
home view (since we don't filter them out), which isn't a big deal --
but we don't want to make an inaccurate claim that the user subscribed
to this stream and then unsubscribed.
This should most properly be handled by filtering server-side, but at
the moment our lack of an index on UserMessage.flags makes that
impractical from a performance perspective.
(imported from commit 00751a5f9fc20e9da5c09914c11d1579f9e7398e)
Use the new count_full_messages_between instead of subtraction in
message_list_view.append. By finding a count higher than it should be
when summarized messages are present, it didn't add new messages until
the pointer moved under certain conditions.
(imported from commit c10d9c1a0d23891acce88bf8d79866c08cb75681)
Summary blocks can contain hundreds of messages. When the rendering window
code didn't take this into account, it would lead to all kinds of
unpleasant behavior when you scroll.
Trac #1888
Unfortunately, this replaces a subtraction with a function that iterates
through all the messages.
(imported from commit 9259a246946cd968a8725c38ff5ef2d4b4793717)
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)
Instead of collapsing muted messages, just hide them altogether
in view where it makes sense to hide them.
(imported from commit 1c2c987ff302ceb135a025753cf421b4de1aea71)
If the date_row is between two messages, it tells you when the message
below was sent, but not when the message above was sent--for that you'd
either have to click on a message or keep scrolling up. This is especially
annoying when there are sometimes gap days on a particular stream (you shouldn't
assume that the message above is simply from the previous day).
This adds the date of the previous message (the time above) to the date_row.
(imported from commit 4c6c956118ae09fedca042e797a6029fdd26e00c)
This is experimental, for staging only. There might be a better
way to model this than dueling force_expand/force_collapse flags,
but it works for now. The code in collapse_recipient_group()
could also be DRYed up relative to expand_summary_row().
(imported from commit 107151d1ecd640970fb7700d41278a003bd1abaa)
This is to set up collapsing, but I think they could be useful
in general, so I'm keeping this is a separate commit.
(imported from commit 0da2b8ef246649f678c7cb6664ee78bf36aca076)
(The approach has been simplified to look for summary_row in
the DOM, which makes muted and summary features work off the
same code.)
(imported from commit 4fa3d6ae5ad7bbac5958e60ecffb368d6ef29d2e)
This change will allow us to test the muting feature on
staging. Any topic named "muted" will automatically be
muted. You can also mute any other topic on the console:
muting.mute_topic('devel', 'ios');
current_msg_list.rerender();
More UI around this experiment will be coming soon, as well
as support for muting entire streams.
The muting module keeps track of which topics are muted, but a
user can expand muted messages, and once that happens, the
messages are marked with the "force_expand" flag that gets
persisted to the back end.
Muted messages are rendered in similar fashion to the summarized
rows, and as part of unifying some of that code, we have
made it so that expanding a summarized section doesn't remove
individual flags related to summaries; instead, the messages
get the force_expand flag set.
(imported from commit acee4190e63813d46850415c41ff8ebfae4a6953)
Jessica McKellar
Steve Howell
Allen Rabinovich
Kevin Mehall
Tim Abbott
acrefoot
Scott Feeney