Reoccurring package error (invalid length: -1004601152)

[andersevenrud]

This one reoccurring package error is sticking out like a sore thumb. So far this is the only one that trips any checks.

I haven't managed to figure out what's going on here, but it has either got to be:

1. Some kind of mistake in the receive queue
2. This package is malformed from the server
3. The original codebase does not handle this packet correctly which would mean that this codebase does not as well

Reference

HEAD: https://github.com/andersevenrud/xpra-html5-client/tree/3cd5e1bad6f378a170b6bc965d4f5f29233d955b

Stack trace

decode.ts:51 XpraDecodeQueue#process Error: invalid length: -1004601152
    at lz4decompress (compression.ts:26:11)
    at decompressXpraDrawData (compression.ts:63:12)
    at XpraDecodeQueue.decodeRGB (decode.ts:87:18)
    at XpraDecodeQueue.convertDrawData (decode.ts:60:28)
    at decode.ts:39:38
    at new Promise (<anonymous>)
    at XpraDecodeQueue.process (decode.ts:34:42)
    at XpraDecodeWebWorker.processMessage (worker.ts:101:20)
    at webworker.ts:27:12 

Packet data

Stripped of irrelevant information (metadata that is time based).

dimension: (2) [331, 1]
encoding: "rgb24"
image: Uint8Array(27) [192, 0, 31, 196, 25, 111, 183, 126, 187, 128, 25, 15, 2, 0, 191, 255, 111, 187, 189, 181, 67, 21, 80, 191, 255, 192, 0, buffer: ArrayBuffer(27), byteLength: 27, byteOffset: 0, length: 27, Symbol(Symbol.toStringTag): 'Uint8Array']
options: {rgb_format: 'RGB', lz4: 4}
position: (2) [18, 212]
rowStride: 993

Application

xclock

[totaam]

Some kind of mistake in the receive queue

Unlikely.

This package is malformed from the server

Very unlikely.

The original codebase does not handle this packet correctly which would mean that this codebase does not as well

The original lz4 support came from: Xpra-org/xpra-html5@4c19545 but it had some problems.
We switched to a pure JS implementation: Xpra-org/xpra-html5@f507836 and fixed AES compatibility: Xpra-org/xpra-html5@cdc09f3

But your error is in the draw packets, those are not handled at the packet layer (well, they kind of are if encryption is enabled since they will be transformed there - the datatype may change).

We now handle lz4 without effort:
https://github.com/Xpra-org/xpra-html5/blob/82199bc802571876f0b0ed20bc7e8dcce5257d02/html5/js/RgbHelpers.js#L21-L24
Because the packet encoders give us a Uint8Array: Xpra-org/xpra-html5#84

Hope this helps.