2017-03-19 22:43:38 +01:00
|
|
|
exports.do_unread_count_updates = function do_unread_count_updates(messages) {
|
|
|
|
unread.process_loaded_messages(messages);
|
|
|
|
unread_ui.update_unread_counts();
|
|
|
|
resize.resize_page_components();
|
|
|
|
};
|
|
|
|
|
2019-01-08 01:26:02 +01:00
|
|
|
function add_messages(messages, msg_list, opts) {
|
2017-03-19 22:43:38 +01:00
|
|
|
if (!messages) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
loading.destroy_indicator($('#page_loading_indicator'));
|
|
|
|
|
2019-11-02 00:06:25 +01:00
|
|
|
const render_info = msg_list.add_messages(messages, opts);
|
message scrolling: Fix "Scroll down to view" warning.
We recently added a feature to warn users that they
may need to scroll down to view messages that they
just sent, but it was broken due to various complexities
in the rendering code path.
Now we compute it a bit more rigorously.
It requires us to pass some info about rendering up
and down the stack, which is why it's kind of a long
commit, but the bulk of the logic is in these JS files:
* message_list_view.js
* notifications.js
I choose to pass structs around instead of booleans,
because I anticipate we may eventually add more metadata
about rendering to it, plus bools are just kinda brittle.
(The exceptions are that `_maybe_autoscroll`, which
is at the bottom of the stack, just passes back a simple
boolean, and `notify_local_mixes`, also at the bottom
of the stack, just accepts a simple boolean.)
This errs on the side of warning the user, even if the
new message is partially visible.
Fixes #11138
2019-01-07 21:00:03 +01:00
|
|
|
|
|
|
|
return render_info;
|
2019-01-08 01:26:02 +01:00
|
|
|
}
|
|
|
|
|
2020-06-13 19:05:31 +02:00
|
|
|
exports.message_has_link = function (message) {
|
|
|
|
return $(message.content).find(`a`).length > 0;
|
|
|
|
};
|
|
|
|
|
|
|
|
exports.message_has_image = function (message) {
|
|
|
|
return $(message.content).find(`.message_inline_image`).length > 0;
|
|
|
|
};
|
|
|
|
|
|
|
|
exports.message_has_attachment = function (message) {
|
|
|
|
return $(message.content).find(`a[href^='/user_uploads']`).length > 0;
|
|
|
|
};
|
|
|
|
|
2019-01-08 01:26:02 +01:00
|
|
|
exports.add_old_messages = function (messages, msg_list) {
|
message scrolling: Fix "Scroll down to view" warning.
We recently added a feature to warn users that they
may need to scroll down to view messages that they
just sent, but it was broken due to various complexities
in the rendering code path.
Now we compute it a bit more rigorously.
It requires us to pass some info about rendering up
and down the stack, which is why it's kind of a long
commit, but the bulk of the logic is in these JS files:
* message_list_view.js
* notifications.js
I choose to pass structs around instead of booleans,
because I anticipate we may eventually add more metadata
about rendering to it, plus bools are just kinda brittle.
(The exceptions are that `_maybe_autoscroll`, which
is at the bottom of the stack, just passes back a simple
boolean, and `notify_local_mixes`, also at the bottom
of the stack, just accepts a simple boolean.)
This errs on the side of warning the user, even if the
new message is partially visible.
Fixes #11138
2019-01-07 21:00:03 +01:00
|
|
|
return add_messages(messages, msg_list, {messages_are_new: false});
|
2019-01-08 01:26:02 +01:00
|
|
|
};
|
2020-05-30 17:34:07 +02:00
|
|
|
|
2019-01-08 01:26:02 +01:00
|
|
|
exports.add_new_messages = function (messages, msg_list) {
|
2020-05-30 17:34:07 +02:00
|
|
|
if (!msg_list.data.fetch_status.has_found_newest()) {
|
|
|
|
// We don't render newly received messages for the message list,
|
|
|
|
// if we haven't found the latest messages to be displayed in the
|
|
|
|
// narrow. Otherwise the new message would be rendered just after
|
|
|
|
// the previously fetched messages when that's inaccurate.
|
|
|
|
msg_list.data.fetch_status.update_expected_max_message_id(messages);
|
|
|
|
return;
|
|
|
|
}
|
message scrolling: Fix "Scroll down to view" warning.
We recently added a feature to warn users that they
may need to scroll down to view messages that they
just sent, but it was broken due to various complexities
in the rendering code path.
Now we compute it a bit more rigorously.
It requires us to pass some info about rendering up
and down the stack, which is why it's kind of a long
commit, but the bulk of the logic is in these JS files:
* message_list_view.js
* notifications.js
I choose to pass structs around instead of booleans,
because I anticipate we may eventually add more metadata
about rendering to it, plus bools are just kinda brittle.
(The exceptions are that `_maybe_autoscroll`, which
is at the bottom of the stack, just passes back a simple
boolean, and `notify_local_mixes`, also at the bottom
of the stack, just accepts a simple boolean.)
This errs on the side of warning the user, even if the
new message is partially visible.
Fixes #11138
2019-01-07 21:00:03 +01:00
|
|
|
return add_messages(messages, msg_list, {messages_are_new: true});
|
2017-03-19 22:43:38 +01:00
|
|
|
};
|
|
|
|
|
2020-05-01 08:29:08 +02:00
|
|
|
exports.get_messages_in_topic = function (stream_id, topic) {
|
|
|
|
// This function is very expensive since it searches
|
|
|
|
// all the messages. Please only use it in case of
|
|
|
|
// very rare events like topic edits. Its primary
|
|
|
|
// use case is the new experimental Recent Topics UI.
|
|
|
|
return message_list.all.all_messages().filter(x => {
|
|
|
|
return x.type === 'stream' &&
|
|
|
|
x.stream_id === stream_id &&
|
|
|
|
x.topic.toLowerCase() === topic.toLowerCase();
|
|
|
|
});
|
|
|
|
};
|
2017-03-19 22:43:38 +01:00
|
|
|
|
2019-10-25 09:45:13 +02:00
|
|
|
window.message_util = exports;
|