- 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.
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!
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.
- 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`.
- Remove the `keepalive` configuration setting. It is now always implicitly `true`.
- Remove the `expose_rid_and_sid` configuration setting.
- A `prebind_url` is now mandatory when setting `authentication` to `prebind`.
- It's no longer possible to pass in `rid` and `sid` values to `converse.initialize.
I'm using prettierx, which is a fork of prettier so that we can have
spaces before the brackets in a function declaration.
I don't like how restrictive prettier is concerning its configuration
and formatting.
- it messes up some indentation in specs/
- it removes a second newline when I specifically want to have two
- it doesn't allow spaces before brackets in function declarations (hence prettierx)
- it adds spaces for function parameters with default values
None of this is configurable.
So auto-formatting is not turned on by default, but it might be a useful
tool in some cases.
Fixes an issue where indentation was off in converse-core.js, causing
vim-sleuth to wrongly indent by three spaces only.
- New plugin `converse-smacks`
- New config option `enable_smacks`
- Rename session cache id from `converse.bosh-session` to `converse.session`
- Refactor logout and login as consistently used api methods
- Refactor session cache to store per JID
Fixes#316
- new config option `singleton`.
- new plugin `converse-uniview`
- removed `converse-embedded`.
- various CSS changes, to properly render an embedded full app
- don't re-open cached and non-autojoined chats in singleton mode
The goal here is to extend the `embedded` `view_mode` so that the full app can
also be embedded, not just a single MUC or private chat.
To do this, we'll need to differentiate between multi and singleton chat apps.
* A singleton chat app contains only a single chat.
* A multi-chat app can contain zero or more chats
So we introduce a new config option, `singleton`, which when used with
`view_mode` set to `embedded` will determine whether a single chat or the full
app is embedded.
Similarly, in `overlayed`, `fullscreen` and `mobile` view modes, `singleton`
set to true will allow only one chat within the parameters of that view mode.
We're appropriating the word `singleton` and introducing the concepts of
`uniview` and `multiview` (see a785ca8) to cover what was
previously meant with `singleton`.
updates #1297
- Use native `getTime` method instead of moment's `valueOf`
- Use toISOString() instead of moment().format()
This makes the code timezone independent since we're now globally using UTC.
- 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
We distinguish between UniView and MultiView instances.
UniView means that only one chat is visible, even though there might be multiple ongoing chats.
MultiView means that multiple chats may be visible simultaneously.
