That way we don't lose the user's input values, we avoid flashing and we
avoid unnecessary rendering.
In the process, fixed an annoying issue where Chrome auto-completes
what it thinks is the username into the "Language Tag" field of the MUC
config form.
Instead we tell Chrome that the MUC JID is the username, thereby also
letting it save the password to to that JID.
- Let box_id start with char for valid HTML.
- No need to use SHA1 for box id
- No need for the user_id attribute.
- Set nickname when we set the roster contact.
Also...
- _converse.api.contacts.get is now async
- _converse.api.chats.create is now async
Set reference to roster contact on the message and chatbox object and
listen for changes to the nickname.
Currently, because chat boxes are fetched and initialized before the
roster, messages and chats are repainted with the correct display name
only later, causing a "flash" effect.
Ideally we would only initialize the chat boxes after the roster
contacts have been fetched, but this is currently not easily possible
because we need the control box to render before everything else.
Instead of deleting devices that are not returned in the device list,
set an `active` flag, so that we don't remove the trust setting.
Set deactivated devices to `active` when a receive an OMEMO message from
it.
Also, set omemo_supported to true when we've succesfully decrypted a
message.
When set, the "Nickname" field won't be shown in the "Add groupchat"
modal and instead the nickname will be automatically set (based on other
config settings).
Until now, we've only been explicitly documenting the `_converse.api`
namespace and only considered the methods under it as forming the API
contract (which determines how we do semver releases).
It appears as if we've reached a point where trying to keep everything
under the `_converse.api` namespace no longer makes sense. Certain
methods are applicable to particular models and trying to shoehorn them
into the `_converse.api` namespace seems clunky and non-intuitive.
I've therefore decided to slightly refactor `sendMessage` to let it take
two simple parameters and to document it with JSDoc so that it's
presented as an API method, albeit only available on a chat model.
updates #1496
updates #1504
