Xpra: Ticket #1586: HTML5 client, when reconnecting, sometimes fails reconnection with errors indicating 'unknown or invalid packet type'

Testing for #1390 (2.1 r16421 fedora 25 server against osx 10.12 chrome 57 html5 client), I encountered a client disconnection.

Server log indicated a ping timeout, and then an 'unknown or invalid packet type' error on reconnection attempt.

From the packet type indicated, it looks like the packets from the timed out connection are getting mixed in with the reconnection attempt packets int he websocket connection (or something like that. (We're seeing this issue also, including invalid packet types for keyboard input when a user types anything while the client is attempting to make its connection.)

Server log clip.

2017-07-19 17:37:11,645 client 4: got hello: server version 2.1 accepted our connection
2017-07-19 17:37:11,662 client 4: startup complete
2017-07-19 17:37:11,699 the remote printer 'HTML5 client' has been configured
2017-07-19 17:38:36,611 client 4: ping timeout - reconnecting
2017-07-19 17:38:37,772 unknown or invalid packet type: damage-sequence from Protocol(tcp websocket: 10.0.32.138:14500 <- 10.0.4.140:51930)
2017-07-19 17:38:38,870 Handshake complete; enabling connection
2017-07-19 17:38:38,871 Disconnecting client 10.0.4.140:51908:
2017-07-19 17:38:38,871  new client (this session does not allow sharing)
2017-07-19 17:38:38,882 xpra client 4 disconnected.
2017-07-19 17:38:38,895 HTML5 Mac OSX Chrome client version 2.1
2017-07-19 17:38:38,895  automatic picture encoding enabled
2017-07-19 17:38:38,895  also available:
2017-07-19 17:38:38,895   jpeg, png, rgb32
2017-07-19 17:38:38,895 unknown or invalid packet type: damage-sequence from Protocol(tcp websocket: 10.0.32.138:14500 <- 10.0.4.140:51931)
2017-07-19 17:38:38,896 unknown or invalid packet type: damage-sequence from Protocol(tcp websocket: 10.0.32.138:14500 <- 10.0.4.140:51931)
2017-07-19 17:38:38,898 unknown or invalid packet type: damage-sequence from Protocol(tcp websocket: 10.0.32.138:14500 <- 10.0.4.140:51931)
2017-07-19 17:38:38,898  client root window size is 1373x891 with 1 display:
2017-07-19 17:38:38,899   HTML (363x236 mm - DPI: 96x95)
2017-07-19 17:38:38,899     Canvas
2017-07-19 17:38:38,905 best resolution matching 1373x891 is unchanged: 1400x900
2017-07-19 17:38:38,909 keyboard mapping already configured (skipped)
2017-07-19 17:38:38,930 xpra client 5 disconnected.


Thu, 20 Jul 2017 07:19:30 GMT - Antoine Martin: milestone set

The ticket tracking this "re-connect" feature is #1473.

I'll try to take a look for 2.2


Mon, 27 Nov 2017 07:34:50 GMT - Antoine Martin: owner, status changed

I believe this should be fixed in r17526.

To make it easier to trigger the re-connect code on demand, I had patched the html5 client with this change so that stealing the session would trigger a re-connect (whereas normally it just goes back to the connect page):

Index: html5/js/Client.js
===================================================================
--- html5/js/Client.js	(revision 17527)
+++ html5/js/Client.js	(working copy)
@@ -1524,6 +1524,10 @@
 }
 XpraClient.prototype._process_disconnect = function(packet, ctx) {
+	if (true) {
+		ctx.do_reconnect();
+		return;
+	}
 	// save the disconnect reason
 	var reason = packet[1];
 	ctx._debug("disconnect reason:", reason);

To trigger fast damage events, I used glxgears.


Sun, 22 Apr 2018 06:38:16 GMT - Antoine Martin: status changed; resolution set


Sat, 23 Jan 2021 05:28:25 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1586