Also, show topic by creating a message object, instead of directly
inserting HTML into the DOM. This is a necessary precursor to being able
to render chat messages via lit-html/lit-element.
Queue messages and handle them sequentially, each time waiting for promises to
resolve before handling the next message.
Updates #1899, which likely happens because an error message is received
before messages have been fetched.
- Collapse 3 different loops into one.
- Check all saved stanza ids in the parsed attrs, not just the archive id
- Remove check for archive id in converse-mam since it just duplicates what's now being done in converse-chat
- Don't use disco to check for support, XEP-359 mandates that services SHOULD advertise support,
which is not a strong enough guarantee that they do.
updates #1856
to rely on the parsed stanza attributes
This was to fix a bug whereby a full stanza was used to query for 1:1
messages with a full JID when the bare JID is stored.
We now are sure that the attributes we're using to query for duplicates
are the same attributes that get saved for a messages.
This will make it easier to add config-based functionality, such as
allowing/showing the `/topic` slash command only to those users who are
allowed to set the subject.
- Rename `chatRoomOpened` event to `chatRoomViewInitialized`
- Rename `chatBoxInitialized` to `chatBoxViewInitialized` and trigger only for `ChatBoxView` instances.
- New event `headlinesBoxViewInitialized`
- Trigger the `chatBoxInitialized` event when a new `_converse.ChatBox` is opened.
Otherwise we might run into a situation where a very old,
cached MUC that's being restored has `connection_status` set to ENTERED
(and the user happens to be in the MUC via another client)
and then restores cached messages without taking
`clear_messages_on_reconnection` into account.
We now distinguish more clearly between joining and re-joining a MUC.
The `enterRoom` method has been refactored away.
Instead, `join` or `rejoin` should be used, depending on the circumstances.
Don't fetch cached occupants in the `initialize` function, instead, only fetch
them if we're restoring a MUC that we're still connected to.
If we're not restoring a still-connected MUC, then we clear the
occupants cache, and the messages cache if `clear_messages_on_reconnection` is `true`.
updates #1807
updates #1808
