* Explicit forwards and backwards paging
* Include upper or lower bound when calling `RSM.prototype.next` or `RSM.prototype.previous`
* Bugfix: Don't override new RSM parameters (caused infinite recursion)
If we've fetched the roster before within this session, then we don't
have to do so again, regardless of whether versioning is supported or
not, otherwise, even if we have a cached roster, we still need to get
the latest one again.
by not logging in automatically when `auto_login` is `false` and we're
using anonymous, external or prebind authentication.
For `authentication` set to `login` the situation is much more
ambiguous, since we don't have a clear distinction between wether we're
restoring a previous session (`keepalive`) or whether we're
automatically setting up a new session (`auto_login`).
So currently if *either* `keepalive` or `auto_login` is `true` and
`authentication` is set to `login`, then Converse will try to log the
user in.
even if the `_converse.bosh_session` instance does not exist.
We do this to avoid trying to reconnect with stale tokens upon
reconnection. Especially relevant for anonymous connections, but could
also be applicable when switching between websocket and BOSH connections
when reconnecting.
Also renamed `startNewBOSHSession` to `startNewPreboundBOSHSession`
It's unlikely that `keepalive` needs to be set to `false`, but there are
some edge cases where it might be useful.
Here's a breakdown of the different configurations of `keepalive` and `auto_join`:
---
* auto_login: false, keepalive: true
This is the default config. Users need to log in manually, but then
Converse will try to reconnect them when the page reloads.
* auto_login: true, keepalive: true
Also very popular configuration. Used with `credentials_url` or `prebind_url`.
* auto_login = `true`, keepalive = `false`
Not sure what this could be useful for. No currently known application.
* auto_login = `false`, keepalive = `false`
Useful when you want some kind of specific action to trigger login, but
you don't want to maintain that state across page reloads.
Also relevant when using a websocket connection with anonymous login.
With websocket it's impossible to maintain anonymous sessions across page
reload because the the session gets removed server-side as soon as the
websocket connection drops and the server won't accept a full JID with
password for an anonymous connection anyway (which could happen upon
page reload when Converse tries to login in again if `keepalive` was `true`).
triggering connectionInitialized.
That way, when listening for `connectionInitialized`, we'll know when it
fires whether we've attached to a BOSH connection or not.
If `auto_login` is false, we shouldn't log in, so we only try to log in when
it is true. Otherwise we still try to restore the BOSH session (if applicable).
- Split between `login` auth and the rest (`external`, `anonymous`, `prebind`)
- It doesn't make sense to pass along credentials when not using `login` auth so avoid that flow.
- It's not necessary to pass the `reconnecting` flag to `attemptNonPreboundSession`
Includes some refactoring:
- Don't send an `active` chat state notification when entering a MUC
I can't think of a good reason why this might be necessary or desired.
- Move `setChatState` form the view to the model
- Remove unused method `handleChatStateNotification`
- Don't store `role` and `affiliation` for the current user on the
ChatRoom object, but instead on the ChatRoomOccupant object representing
the user.
In some cases, it might be desirable to clear cached chat messages once you've
reconnected to the XMPP server.
For example, if you want to prevent the chat history from getting too long or
if you want to avoid gaps in the chat history (for example due to MAM not
returning all messages since the last cached message).
If you're using OMEMO, then you probably don't want to set this setting to
``true``. OMEMO messages can be decrypted only once, so if they then
subsequently get cleared, you won't get the plaintext back.
This is done to avoid unnecessary repaints and reflows (caused when a
message has already rendered and then an occupant is created and
attached to that message, cauring a re-render).
Related to #1266
and re-enter if necessary.
This solves the problem where we "clone" a tab (e.g. middle-click) and
then restore a MUC from cache which we haven't actually entered (given
that the new tab represents a new device and session).
Also... add `await` in a test to try and fix Travis flakiness
We then use this flag to determine whether we should use the values from
sessionStorage.
This appears to fix the problem I originally tried to fix in 607d798665.
When "cloning" a tab (e.g. via middle-click), the `active` flag will be
set and we'll create a new empty user session, otherwise it'll be false
and we can re-use the user session.
This reverts commit 607d798665.
Unfortunately this doesn't solve the issue because we have a
chicken-and-egg problem due to not knowing the resource beforehand.
So what happens after this change is that we never resume XEP-0198
sessions but instead always start a new one.
Otherwise we run into a bug where two tabs with Converse.js share the
same XEP-0198 SM-ID, causing both to go into a reconnection-loop as
the XMPP server switches XEP-0198 sessions between them.
This bug is due to a distinction in how sessionStorage behaves when you
open the existing site in a new tab (e.g. middle-click or
`target="_blank"), as opposed to creating a new tab
and then opening the site in that tab.
In the latter case, the newly created sessionStorage object is empty.
In the former, the contents of sessionStorage of the current page is
copied over to the new page!
Distinguish between getting an existing entity and
creating a new one.
When creating a new one, ensure that we don't fetch from the cache.
New API method for creating a disco entity.
Only fetch messages after we have the latest room features
Otherwise we run into race conditions where MAM messages are fetched
before we know whether (updated) the room supports MAM or not.
I'm not sure how much this is an issue outside of tests, where we might
run into race conditions arising to the fact that we don't always
respond to every IQ stanza
- Fixes#1575. Height not properly set on MUC invitation list
- Add new configuration setting: `muc_mention_autocomplete_min_chars`
- Bugfix. `min_chars` setting for MUC mentions wasn't having an effect
When reconnecting with a new transport, we call setUserJID
so that a new resource is generated, to avoid multiple
server-side sessions with the same resource.
We also call `_proto._doDisconnect` so that connection event handlers
for the old transport are removed.
https://xmpp.org/extensions/xep-0198.html#resumption
The <resume/> element MUST include a 'previd' attribute whose value
is the SM-ID of the former stream and MUST include an 'h' attribute
that identifies the sequence number of the last handled stanza sent
over the former stream from the server to the client.
- Set roster_fetched flag when we get an empty IQ[type="result"] stanza
- Set `restored` flag when resuming in converse-smacks
- Don't trigger change event when fetching xmppstatus values
- Removed two events, since we can just listen to `change` on `_converse.xmppstatus`.
