Depend on latest backbone.browserStorage which has support for IndexedDB
via localforage.
Storage operations are now asynchronous and transactional.
Bugs fixed (mostly by waiting for operations to complete):
* Rooms are now fetched asynchronously, so wait before triggering `show`
or when closing.
* Make sure chat create/update transactions complete before firing events
* Make sure chats and messages have been fetched before creating new ones.
* When doing a `fetch` with `wait: false` on a collection and then
creating a model in that collection, then once the read
operation finishes (after creating the model), the collection is emptied again.
* Patch and wait when saving.
Otherwise we have previously set attributes overriding later ones.
* Make sure api.roomviews.close returns a promise
Test fixes:
* Chats are now asynchronously returned, so we need to use `await`
* Wait for the storage transaction to complete when creating and updating messages
* Wait for all chatboxes to close
Otherwise we get sessionStorage inconsistencies due to the async nature of localforage.
* Wait for room views to close in spec/chatroom.js
In the process, remove the `closeAllChatBoxes` override in
converse-controlbox by letting the `close` method decide whether it
should be closed or not.
- Combine all test init functions into `initConverse`
- Use `async` functions in more tests
- Replace `var` with `let` and `const` in more tests
- New utils method `toStanza` which converts a string to a Node
Avoid `An 'url' property must be specified` error by properly clearing
presence data upon teardown and then resetting the browserStorage upon
reconnection.
Store contact resources in a Backbone collection
`toLocaleString` now returns element attributes in alphabetical order
(for better cross-browser consistency).
Also, `toLocaleString` is now used in favor of `outerHTML` because
browsers aren't consistent with one another in their output.
Include entity capabilities hash in outgoing presences
Also, started some work on using jsdoc for rendering API documentation.
Ideally that would go into a separate commit but that would take ages to
untangle.
So that when a higher priority resource goes offline, we can fall back to the
right chat status if at the next priority level there are multiple resources.
789654d54e (comments)
Improve upon the previous implementation.
If the resource with the highest priority goes offline or becomes unavailable,
then the chat status of the contact must fall back to that of the resource with
the next highest priority.
In your example from #785, if the resource with priority 1 goes offline or
becomes unavailable, then in your implementation the chat status would stay at
online, although it must actually go to xa.
The solution is to update the resources attribute on the contact to not just be
an array or strings, but instead to be a map of resources to priorities and
statuses and to use that data structure.
