Fix failing tests.

This commit is contained in:
JC Brand 2017-01-31 21:21:59 +00:00
parent 9510bdc152
commit 0cf9903726
3 changed files with 30 additions and 29 deletions

View File

@ -25,33 +25,33 @@
});
/* Some level of integration between roster items and presence
* subscriptions is normally expected by an instant messaging user
* regarding the user's subscriptions to and from other contacts. This
* section describes the level of integration that MUST be supported
* within an XMPP instant messaging applications.
*
* There are four primary subscription states:
*
* None -- the user does not have a subscription to the contact's
* presence information, and the contact does not have a subscription
* to the user's presence information
* To -- the user has a subscription to the contact's presence
* information, but the contact does not have a subscription to the
* user's presence information
* From -- the contact has a subscription to the user's presence
* information, but the user does not have a subscription to the
* contact's presence information
* Both -- both the user and the contact have subscriptions to each
* other's presence information (i.e., the union of 'from' and 'to')
*
* Each of these states is reflected in the roster of both the user and
* the contact, thus resulting in durable subscription states.
*
* The 'from' and 'to' addresses are OPTIONAL in roster pushes; if
* included, their values SHOULD be the full JID of the resource for
* that session. A client MUST acknowledge each roster push with an IQ
* stanza of type "result".
*/
* subscriptions is normally expected by an instant messaging user
* regarding the user's subscriptions to and from other contacts. This
* section describes the level of integration that MUST be supported
* within an XMPP instant messaging applications.
*
* There are four primary subscription states:
*
* None -- the user does not have a subscription to the contact's
* presence information, and the contact does not have a subscription
* to the user's presence information
* To -- the user has a subscription to the contact's presence
* information, but the contact does not have a subscription to the
* user's presence information
* From -- the contact has a subscription to the user's presence
* information, but the user does not have a subscription to the
* contact's presence information
* Both -- both the user and the contact have subscriptions to each
* other's presence information (i.e., the union of 'from' and 'to')
*
* Each of these states is reflected in the roster of both the user and
* the contact, thus resulting in durable subscription states.
*
* The 'from' and 'to' addresses are OPTIONAL in roster pushes; if
* included, their values SHOULD be the full JID of the resource for
* that session. A client MUST acknowledge each roster push with an IQ
* stanza of type "result".
*/
it("Subscribe to contact, contact accepts and subscribes back", mock.initConverse(function (converse) {
/* The process by which a user subscribes to a contact, including
* the interaction between roster items and subscription states.

View File

@ -303,7 +303,7 @@
close: function (ev) {
if (ev && ev.preventDefault) { ev.preventDefault(); }
if (converse.connection.connected) {
if (converse.connection.connected && !converse.connection.disconnecting) {
this.model.save({'closed': true});
} else {
this.model.trigger('hide');

View File

@ -140,6 +140,7 @@
// out or disconnecting in the previous session.
// This happens in tests.
// We therefore first clean up.
converse.connection.reset();
converse._tearDown();
}
@ -541,11 +542,11 @@
};
this.logOut = function () {
converse.chatboxviews.closeAllChatBoxes();
converse.setDisconnectionCause(converse.LOGOUT, undefined, true);
if (typeof converse.connection !== 'undefined') {
converse.connection.disconnect();
}
converse.chatboxviews.closeAllChatBoxes();
converse.clearSession();
converse._tearDown();
converse.emit('logout');