When there is a circular dependency between disco entities (via their
advertised `disco#items`), Converse went into an infinite loop because
even though there was a check whether an entity already existed, it
failed to add newly created entities to the global
`_converse.disco_entities` collection.
It might be that it's shown in response to a failed XEP-156 lookup
because the user mistyped.
In which case the user can just correct the JID and try again, without
entering a connection URL.
Render the form based on `api.settings` instead of its own model.
When the login form is submitted, save the JID, password and connection
URL to `api.settings`.
Set the `service` on the Strophe connection object just before
connecting for the first time, otherwise a user supplied URL (via the
login form) is never used.
New API setting: show_connection_url_input
Add test case for incoming OMEMO message corrections.
The correction was being ignored because the parsed `msgid` of an
incoming correction was set to the `msgid` of the message being
replaced.
For error messages we still use the `message` attribute, since error
messages generally don't have a body, and if one does, it likely refers
to the `body` of a rejected message that the error refers to.
We're still setting both `body` and `message` attributes, but usage of
`message` for a normal `chat`, `groupchat` or `headline` stanza should
be considered deprecated.
Add the ability to send OMEMO corrections.
Refactor how OMEMO messages are sent to avoid having to override
`sendMessage` and thereby also allowing corrections of OMEMO messages to
be sent out.
Add two new hooks.
- getOutgoingMessageAttributes
- createMessageStanza
to be fetched from the server before triggering OMEMOInitialized.
For some contacts, the IQ to fetch the device list never receives a
response. IQ stanzas take 20 seconds to timeout, which means that all
OMEMO operations are blocked for 20 seconds (because everything waits
for `OMEMOInitialized`).
Create a new API method `api.omemo.devicelists.get` and use that to
fetch and `await` for any devicelist. That way we lazily wait for
devicelists to be fetched from the server and can continue with other
OMEMO operations unrelated to users who's clients don't respond to
devicelist queries.
Trigger an `emojiSelected` event instead of manually calling `insertIntoTextArea` on the `converse-message-form` a component.
This loosens the coupling between the emoji picker and `converse-message-form`.
Call `disableArrowNavigation` when the emoji-picker is disconnected from
the DOM or when escape is pressed. See #2754
- Clear timer when a messages changes from epehemeral to non-ephemeral
- Set MUC occupant on `groupchat` message when `type` changes to `groupchat` (from `error`)
- Set roster contact on `chat` message when `type` changes to `chat` (from `error`)
Thanks @afriedmanGlacier
Promises only get recreated upon logout, not reconnection.
However OMEMO was getting re-initialized on reconnection and
`_converse.omemo_store` was also deleted.
This caused a race condition where an incoming MAM message would cause
`parseEncryptedMessage` that then throws an AttributeError because
`_converse.omemo_store` is undefined because OMEMO isn't yet
initialized.
Waiting for the `OMEMOInitialized` promise doesn't help because it's
still the old (already resolved) promise from before the reconnection.
inside `parseMessageForMUCCommands`.
If the function doesn't find any core MUC commands, it calls
`parseMessageForCommands` which will trigger the hook.
I think it's appropriate to give built-in commands preference above
commands by 3rd party plugins and this also solves the issue of the hook
being triggered twice (once in `parseMessageForMUCCommands` and
then again in `parseMessageForCommands`).
When calling `getDeviceList`, wait for the devices to be fetched
Otherwise a race condition might occur, whereby a new device gets
created in the collection, and then removed again as the collection is
replaced with the values fetched from the browser-storage cache.
Also created `converse-omemo-fingerprints` component to asynchronously
render fingerprints in the user details modal. Was done as part of this
commit because due to `getDeviceList` being async, the relevant test for
the modal were also failing
before parsing message stanza for encryption parameters.
Otherwise we might not know what our own device-id/sid is, and therefore
can't decrypt the incoming message.
Fixes#2733
As mentioned in the XEP, don't show error messages for OMEMO messages
that can't be decrypted because they were already decrypted before or
because they weren't encrypted for this device.
And use that to render images in unfurls.
This solves the issue of github URL unfurl images not having an image
extension and then being rendered as a hyperlink by `converse-rich-text`.
Instead, we know that it's supposed to be a url, so we just use `converse-image`.
