From 0cf9903726fc67f038c8e92ea6158c663b68180e Mon Sep 17 00:00:00 2001
From: JC Brand <jc@opkode.com>
Date: Tue, 31 Jan 2017 21:21:59 +0000
Subject: [PATCH] Fix failing tests.

---
 spec/protocol.js           | 54 +++++++++++++++++++-------------------
 src/converse-controlbox.js |  2 +-
 src/converse-core.js       |  3 ++-
 3 files changed, 30 insertions(+), 29 deletions(-)

diff --git a/spec/protocol.js b/spec/protocol.js
index bc6a7ec79..ae2fb8f9b 100644
--- a/spec/protocol.js
+++ b/spec/protocol.js
@@ -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.
diff --git a/src/converse-controlbox.js b/src/converse-controlbox.js
index f548b309b..11efaf2ac 100644
--- a/src/converse-controlbox.js
+++ b/src/converse-controlbox.js
@@ -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');
diff --git a/src/converse-core.js b/src/converse-core.js
index 5c06f8885..256cc8885 100755
--- a/src/converse-core.js
+++ b/src/converse-core.js
@@ -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');