Xpra: Ticket #1059: Unable to add working Xterm windows to HTML5 Client

Title is a bit wonky.

The server is a Fedora 23 trunk r11425 server started with:

 dbus-launch xpra start :13 --bind-tcp=0.0.0.0:2200 --html=on --start-child=firefox --start-new-commands=yes

And connected by navigating to $IP:2200. The client machine runs Win8.1 64-bit. The browsers this was tested on are Google-Chrome 47.0.2526.106 and Firefox 43.0



Thu, 17 Dec 2015 20:17:54 GMT - J. Max Mena: attachment set


Thu, 17 Dec 2015 22:58:43 GMT - J. Max Mena: description changed

(forgot server info in ticket description)


Thu, 17 Dec 2015 23:02:43 GMT - J. Max Mena:

Update:


Fri, 18 Dec 2015 00:50:56 GMT - Josh:

Can you post the output of the Web Console in Firefox? Can't seem to replicate this issue....


Fri, 18 Dec 2015 17:33:03 GMT - J. Max Mena:

Chrome console output:

EDIT: I get the following error when spawning an Xterm window:

error processing 'draw' with 'function (packet, ctx) {
	var start = new Date().getTime(),
		wid = packet[1],
		x = packet[2],
		y = packet[3],
		width = packet[4],
		height = packet[5],
		coding = packet[6],
		data = packet[7],
		packet_sequence = packet[8],
		rowstride = packet[9],
		options = {};
	if (packet.length>10)
		options = packet[10];
	if (coding in ctx.OLD_ENCODING_NAMES_TO_NEW)
		coding = ctx.OLD_ENCODING_NAMES_TO_NEW[coding];
	var win = ctx.id_to_window[wid];
	var decode_time = -1;
	if (win) {
		// win.paint draws the update to the window's off-screen buffer and returns true if it
		// was changed.
		win.paint(x, y,
			width, height,
			coding, data, packet_sequence, rowstride, options,
			function (ctx) {
				decode_time = new Date().getTime() - start;
				ctx._window_send_damage_sequence(wid, packet_sequence, width, height, decode_time);
			}
		);
		// request that drawing to screen takes place at next available opportunity if possible
		if(requestAnimationFrame) {
			requestAnimationFrame(function() {
				win.draw();
			});
		} else {
			// requestAnimationFrame is not available, draw immediately
			win.draw();
		}
	}
}': RangeError: Source is too large
}}} (looks to be the relevant error)

Fri, 18 Dec 2015 17:48:02 GMT - Josh:

Okay, I see. Do the windows paint correctly without this error if you disable h.264 encoding?


Fri, 18 Dec 2015 17:51:17 GMT - J. Max Mena:

I get the same error with PNG, and no error at all with JPEG. They still don't paint correctly.


Sun, 27 Dec 2015 19:06:48 GMT - Josh: status changed

I get this problem now with trunk server, I thought I had updated before I tested but seems not.

r11499 makes debugging easier because the web console output will reflect the line the error occurred.

The Xpra log showed that h264 was selected regardless of the encoding option in html5 client. r11500 makes us a bit more verbose about what options are being set. It was clear from this that none of the URL parameter options were being set, broken by r10847 and fixed in r11501. A real doobie that one, sorry.

The error persists even with rgb encoding, so r11502 adds some logging of image data sizes. Now the problem is clear.

got  1024 to paint with stride 64
xpra_client.js:231 received a draw packet
xpra_window.js:773 got  1024 to paint with stride 64
xpra_client.js:231 received a draw packet
xpra_window.js:773 got  2944 to paint with stride 184
xpra_client.js:231 received a draw packet
xpra_window.js:773 got  1024 to paint with stride 64
xpra_client.js:231 received a draw packet
xpra_window.js:771 data size mismatch: wanted 184 , got 2852 , stride 2852
xpra_window.js:775 Uncaught RangeError: Source is too large
xpra_client.js:231 received a draw packet
xpra_window.js:771 data size mismatch: wanted 184 , got 2852 , stride 2852
xpra_window.js:775 Uncaught RangeError: Source is too large
xpra_client.js:231 received a draw packet
xpra_window.js:773 got  1024 to paint with stride 64
2 xpra_client.js:231 received a window-metadata packet
xpra_client.js:231 received a draw packet
xpra_window.js:773 got  10336 to paint with stride 608
xpra_client.js:231 received a draw packet
xpra_window.js:773 got  19536 to paint with stride 888
xpra_client.js:231 received a draw packet
xpra_window.js:773 got  1024 to paint with stride 64

Partial window updates were cut out in r8779 and I forgot to add them back in after refactoring the drawing code. I am really surprised I did not notice this till now.


Sun, 27 Dec 2015 19:22:38 GMT - Antoine Martin:

@joshiggins: I was just in the process of making the final 0.16.0 builds... but it sounds like these changes should be included - should I just cancel the builds and merge this in 0.16?


Sun, 27 Dec 2015 19:25:58 GMT - Josh:

@antoine: I'm just finishing off the fix for this, it's not pushed yet. But yes, if you can (sorry!) it would be better to get this in.


Mon, 28 Dec 2015 04:21:02 GMT - Antoine Martin:

@joshiggins: I have cherry picked the non-debug changes in r11503. It looks like these should be applied to the 0.15 branch too? Hopefully that's enough, if not, we can include more in 0.16.1.


Mon, 28 Dec 2015 23:20:39 GMT - Josh: status changed; resolution set

@antoine: r11503 looks good. Yes I think they should go back to 0.15 too.

@maxmylyn: TL;DR please make sure our old friend python-imaging is installed.


It seems that we did have partial window drawing but ignoring the rowstride - we can place images wherever we want anyway, so there was method in the madness.

The apparent regressions (transparent windows, corrupted partial updates, huge strides) are because python-imaging is missing. I thought I was going mad! If you inspect the raw rgb values, they were either zeros or repeating pattern of 255, 0, 255. I remember now that this came up before on the original HTML5 ticket (#473).

However a few other (minor) issues have been identified whilst looking at this which I will move into another ticket.


Tue, 29 Dec 2015 00:39:18 GMT - Antoine Martin:

Applied to v0.15.x in r11514.


Sat, 23 Jan 2021 05:13:47 GMT - migration script:

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