Improve curtain mode error message.

remoting/webapp/client_screen.js

Index: remoting/webapp/client_screen.js
diff --git a/remoting/webapp/client_screen.js b/remoting/webapp/client_screen.js
index 3ffb0f848da96afc32a6cc9e1496cc5cb4a778a7..da8d82a26341ed006db9b2578757b3ed97142a98 100644
--- a/remoting/webapp/client_screen.js
+++ b/remoting/webapp/client_screen.js
@@ -255,10 +255,12 @@ function onClientStateChange_(oldState, newState) {
         remoting.setMode(remoting.AppMode.CLIENT_SESSION_FINISHED_ME2ME);
       }
     } else {
-      // The transition from CONNECTING to CLOSED state may happen
-      // only with older client plugins. Current version should go the
-      // FAILED state when connection fails.
-      showConnectError_(remoting.Error.INVALID_ACCESS_CODE);
+      // A state transition from CONNECTING -> CLOSED can happen if the host
+      // closes the connection without an error message instead of accepting it.
+      // For example, it does this if it fails to activate curtain mode. Since
+      // there's no way of knowing exactly what went wrong, we rely on server-
+      // side logs in this case and show a generic error message.
+      showConnectError_(remoting.Error.UNEXPECTED);

[Jamie, 2012/11/28 23:52:32]

I'm not particularly happy with this fix. I would prefer that the host closed
the session with an error message (preferably one specific to curtain mode). I'm
not sure it's worth the effort though, given that we don't expect this to happen
very often. Let me know if you disagree.

The reasons for giving an invalid access code error in this situation are no
longer valid. It was introduced in https://codereview.chromium.org/7511001 if
you're interested.

[rmsousa, 2012/11/29 00:11:14]

This seems like a valid change regardless of the host-side curtain mode change
(as long as we remove the example from the comment)

     }
 
   } else if (newState == remoting.ClientSession.State.FAILED) {