Xpra: Ticket #854: HTML 5 client crash by scrolling in Firefox

Using Windows 8.1 x64 and Firefox 37.0.2 against a Fedora 21 0.15.0 r9285 server:



Sat, 09 May 2015 02:49:32 GMT - Antoine Martin: priority, description, milestone changed

Blocker for 0.15 release. Note: if you run with -d network you should be able to see the full packet data hexlified, from there you should be able to figure out which part contains NaN (which is obviously not a valid number).


Sat, 09 May 2015 04:19:57 GMT - Antoine Martin:

(r9286 avoids the bottom stacktrace - backport to v0.15.x in r9287)


Sat, 09 May 2015 05:25:13 GMT - J. Max Mena:

Reattempted with -d network

Captured the relevant log bits (with the traceback included):

2015-05-08 22:21:13,739 failed to parse bencode packet: invalid literal for long() with base 10: 'NaN'
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 740, in do_read_parse_thread_loop
    packet = decode(data, protocol_flags)
  File "/usr/lib64/python2.7/site-packages/xpra/net/packet_encoding.py", line 169, in decode
    packet, l = bdecode(data)
  File "xpra/net/bencode/cython_bencode.pyx", line 117, in xpra.net.bencode.cython_bencode.bdecode (xpra/net/bencode/cython_bencode.c:2437)
  File "xpra/net/bencode/cython_bencode.pyx", line 100, in xpra.net.bencode.cython_bencode.decode (xpra/net/bencode/cython_bencode.c:2164)
  File "xpra/net/bencode/cython_bencode.pyx", line 76, in xpra.net.bencode.cython_bencode.decode_list (xpra/net/bencode/cython_bencode.c:1645)
  File "xpra/net/bencode/cython_bencode.pyx", line 100, in xpra.net.bencode.cython_bencode.decode (xpra/net/bencode/cython_bencode.c:2164)
  File "xpra/net/bencode/cython_bencode.pyx", line 76, in xpra.net.bencode.cython_bencode.decode_list (xpra/net/bencode/cython_bencode.c:1645)
  File "xpra/net/bencode/cython_bencode.pyx", line 104, in xpra.net.bencode.cython_bencode.decode (xpra/net/bencode/cython_bencode.c:2212)
  File "xpra/net/bencode/cython_bencode.pyx", line 46, in xpra.net.bencode.cython_bencode.decode_int (xpra/net/bencode/cython_bencode.c:1069)
ValueError: invalid literal for long() with base 10: 'NaN'
2015-05-08 22:21:13,756 failed to parse bencode packet: 6c31333a627574746f6e2d616374696f6e6932656934656931656c694e614e65694e614e65656c656c6565
2015-05-08 22:21:13,756 will process ui packet gibberish
2015-05-08 22:21:13,756 Received uninterpretable nonsense from Protocol(SocketConnection(('127.0.0.1', 2200) - ('127.0.0.1', 34481))): packet index=0, packet size=43, buffer size=94, error=invalid literal for long() with base 10: 'NaN'
2015-05-08 22:21:13,757  data: 'l13:button-actioni2ei4ei1eliNaNeiNaNeelelee'
2015-05-08 22:21:13,757 disconnect_client(Protocol(SocketConnection(('127.0.0.1', 2200) - ('127.0.0.1', 34481))), packet index=0, packet size=43, buffer size=94, error=invalid literal for long() with base 10: 'NaN', ())
2015-05-08 22:21:13,757 disconnect_protocol(Protocol(SocketConnection(('127.0.0.1', 2200) - ('127.0.0.1', 34481))), packet index=0, packet size=43, buffer size=94, error=invalid literal for long() with base 10: 'NaN', ())
2015-05-08 22:21:13,757 Disconnecting client Protocol(SocketConnection(('127.0.0.1', 2200) - ('127.0.0.1', 34481))): packet index=0, packet size=43, buffer size=94, error=invalid literal for long() with base 10: 'NaN'

Hope that helps


I can provide more logs if needed. (although I'll be out and about tomorrow, Saturday the 9th PST and Sunday is Mother's Day)

EDIT: for what it's worth, scrolling works fine in Chrome 42


Sat, 09 May 2015 12:37:27 GMT - Antoine Martin:

It looks to me like Firefox is not sending the x and y coordinates for the mouse scroll button events (it was not at all obvious to me that this was how you were scrolling until I saw the packet dump).

From what I am reading, it is not possible (or rather, not advisable) to try to get the current mouse coordinates in Javascript, so this makes the fix slightly more complicated: we need to keep track of the current mouse position from all mouse move events so that we can send it with these click (scroll) events. (we then just check if the x and y values are isNaN and substitute the last known coordinates if they are)

@josh: am-i-rite?


Sun, 10 May 2015 11:39:02 GMT - Josh:

@antoine: confirmed. sounds like the best solution.

Pushed fix in r9290, tested with Firefox on OS X and working now for me.

@maxmylyn: can you see if the problem is fixed for you?


Mon, 11 May 2015 10:34:23 GMT - Antoine Martin: owner changed

Backport to v0.15.x in r9293. Works-for-me.

@maxmylyn: can you still break it?


Mon, 11 May 2015 17:02:00 GMT - J. Max Mena:

Using the 0.15.0 tagged branch builds (r9303) I am unable to crash with scrolling using Firefox.


Using my trunk(r9303) builds, I am still able to crash by scrolling in Chrome and Firefox.

a -d network produces the following output and traceback:

2015-05-11 09:47:04,283 failed to encode packet: ['draw', 3, 1054, 0, 1, 665, 'rgb32', 'x^\xb3\xc9M\xcd\xcd/\xaaTH,Q0\xa80O3IKNL4211\xb7\xb0\x03\x00x\x00\x086', 20, 4, {'zlib': 4, 'rgb_format': 'RGBX'}]
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 479, in encode
    main_packet, proto_version = self._encoder(packet)
  File "/usr/lib64/python2.7/site-packages/xpra/net/packet_encoding.py", line 64, in do_bencode
    return bencode(data), 0
  File "xpra/net/bencode/cython_bencode.pyx", line 208, in xpra.net.bencode.cython_bencode.bencode (xpra/net/bencode/cython_bencode.c:4234)
ValueError: cannot encode '['draw', 3, 1054, 0, 1, 665, 'rgb32', 'x^\xb3\xc9M\xcd\xcd/\xaaTH,Q0\xa80O3IKNL4211\xb7\xb0\x03\x00x\x00\x086', 20, 4, {'zlib': 4, 'rgb_format': 'RGBX'}]': 'utf8' codec can't decode byte 0xb3 in position 2: invalid start byte
2015-05-11 09:47:04,295 internal error: error in network packet write/format
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 278, in _write_format_thread_loop
    self._add_packet_to_queue(*self._get_packet_cb())
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 288, in _add_packet_to_queue
    chunks, proto_flags = self.encode(packet)
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 487, in encode
    raise e
ValueError: cannot encode '['draw', 3, 1054, 0, 1, 665, 'rgb32', 'x^\xb3\xc9M\xcd\xcd/\xaaTH,Q0\xa80O3IKNL4211\xb7\xb0\x03\x00x\x00\x086', 20, 4, {'zlib': 4, 'rgb_format': 'RGBX'}]': 'utf8' codec can't decode byte 0xb3 in position 2: invalid start byte
2015-05-11 09:47:04,295 connection lost: error in network packet write/format
2015-05-11 09:47:04,296 close() closed=False
2015-05-11 09:47:04,296 terminate_queue_threads()
2015-05-11 09:47:04,296 read thread: empty marker, exiting
2015-05-11 09:47:04,296 will process ui packet connection-lost
2015-05-11 09:47:04,296 write thread: empty marker, exiting
2015-05-11 09:47:04,297 close() closed=True
2015-05-11 09:47:04,297 close() closed=True
2015-05-11 09:47:04,297 process_connection_lost(Protocol(None), ['connection-lost'])
2015-05-11 09:47:04,297 io_thread_loop(write, <bound method Protocol._write of Protocol(None)>) loop ended, closed=True
2015-05-11 09:47:04,297 Connection lost
2015-05-11 09:47:04,303 cleanup_source(Protocol(None))
2015-05-11 09:47:04,303 xpra client disconnected.
 17: handler exception: [Errno 107] Transport endpoint is not connected

Traceback (most recent call last):
  File "xpra/net/bencode/cython_bencode.pyx", line 204, in xpra.net.bencode.cython_bencode.bencode (xpra/net/bencode/cython_bencode.c:4140)
2015-05-11 09:53:35,798 processing packet button-action
2015-05-11 09:53:35,799 will process ui packet button-action
  File "xpra/net/bencode/cython_bencode.pyx", line 204, in genexpr (xpra/net/bencode/cython_bencode.c:4007)
  File "xpra/net/bencode/cython_bencode.pyx", line 202, in xpra.net.bencode.cython_bencode.bencode.bytestostr (xpra/net/bencode/cython_bencode.c:3877)
  File "/usr/lib64/python2.7/encodings/utf_8.py", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xb3 in position 2: invalid start byte
2015-05-11 09:53:35,801 failed to encode packet: ['draw', 2, 498, 0, 1, 316, 'rgb32', 'x^\xb3\xc9M\xcd\xcd/\xaaTH,Q0\xa80OK1O6I30MN\xb6\xb0\x03\x00x.\x08i', 46, 4, {'zlib': 4, 'rgb_format': 'RGBX'}]
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 479, in encode
    main_packet, proto_version = self._encoder(packet)
  File "/usr/lib64/python2.7/site-packages/xpra/net/packet_encoding.py", line 64, in do_bencode
    return bencode(data), 0
  File "xpra/net/bencode/cython_bencode.pyx", line 208, in xpra.net.bencode.cython_bencode.bencode (xpra/net/bencode/cython_bencode.c:4234)
ValueError: cannot encode '['draw', 2, 498, 0, 1, 316, 'rgb32', 'x^\xb3\xc9M\xcd\xcd/\xaaTH,Q0\xa80OK1O6I30MN\xb6\xb0\x03\x00x.\x08i', 46, 4, {'zlib': 4, 'rgb_format': 'RGBX'}]': 'utf8' codec can't decode byte 0xb3 in position 2: invalid start byte
2015-05-11 09:53:35,802 internal error: error in network packet write/format
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 278, in _write_format_thread_loop
    self._add_packet_to_queue(*self._get_packet_cb())
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 288, in _add_packet_to_queue
    chunks, proto_flags = self.encode(packet)
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 487, in encode
    raise e
ValueError: cannot encode '['draw', 2, 498, 0, 1, 316, 'rgb32', 'x^\xb3\xc9M\xcd\xcd/\xaaTH,Q0\xa80OK1O6I30MN\xb6\xb0\x03\x00x.\x08i', 46, 4, {'zlib': 4, 'rgb_format': 'RGBX'}]': 'utf8' codec can't decode byte 0xb3 in position 2: invalid start byte
2015-05-11 09:53:35,802 connection lost: error in network packet write/format

Mon, 11 May 2015 17:06:30 GMT - Antoine Martin: owner, status changed

Ah, this one is most probably my fault (not sure why it only popped up now): in trying to fix py3k support, I must have borken python2 (and I've already spent a couple of days on this stoopid unicode nonsense).

Probably caused by r9220 or r9219.


Mon, 11 May 2015 17:28:22 GMT - Antoine Martin:

r9304 adds a test for this unicode pita.


Tue, 12 May 2015 05:35:06 GMT - Antoine Martin: attachment set

partial revert which at least gets python2 working again..


Tue, 12 May 2015 06:42:50 GMT - Antoine Martin: attachment set

all but one test fails..


Tue, 12 May 2015 08:07:43 GMT - Antoine Martin: owner, status changed

As of r9308 (r9309 for v0.15.x branch), all tests pass for both python2 and py3k and the html5 client no longer disconnects.

@maxmylyn: back to you! (to see what else I've broken..)


Tue, 12 May 2015 17:06:13 GMT - J. Max Mena:

Upped to 9329 0.15.0:

2015-05-12 09:39:21,354 failed to encode packet: [3, 3, 209, 42, 1, 16, 'rgb24', <read-write buffer ptr 0x7f2c88002380, size 64 at 0x7f2c9c1e8c70>, 3, 4, {'rgb_format': 'BGRX'}]
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 484, in encode
    main_packet, proto_version = self._encoder(packet)
  File "/usr/lib64/python2.7/site-packages/xpra/net/packet_encoding.py", line 70, in do_rencode
    return  rencode_dumps(data), FLAGS_RENCODE
  File "rencode.pyx", line 330, in rencode._rencode.dumps (rencode/rencode.c:4310)
  File "rencode.pyx", line 310, in rencode._rencode.encode (rencode/rencode.c:4108)
  File "rencode.pyx", line 243, in rencode._rencode.encode_list (rencode/rencode.c:3110)
  File "rencode.pyx", line 316, in rencode._rencode.encode (rencode/rencode.c:4159)
Exception: type <type 'buffer'> not handled
2015-05-12 09:39:21,355 internal error: error in network packet write/format
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 274, in _write_format_thread_loop
    self._add_packet_to_queue(*self._get_packet_cb())
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 284, in _add_packet_to_queue
    chunks, proto_flags = self.encode(packet)
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 492, in encode
    raise e
Exception: type <type 'buffer'> not handled
2015-05-12 09:39:21,356 Connection lost
2015-05-12 09:39:21,356 xpra client disconnected.

Using latest trunk builds all is fine, except for connecting with a normal Xpra client after using the HTML5 client with normal fullscreen windows (re-testing to see if I see the same issue on trunk) I get the following print in the server:

Exception in thread web-proxy-for-Protocol(SocketConnection(('10.0.32.138', 2200) - ('10.0.11.124', 52067))):
Traceback (most recent call last):
  File "/usr/lib64/python2.7/threading.py", line 813, in __bootstrap_inner
    self.run()
  File "/usr/lib64/python2.7/threading.py", line 766, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/xpra/server/server_core.py", line 395, in run_proxy
    self.start_tcp_proxy(proto, data)
  File "/usr/lib64/python2.7/site-packages/xpra/server/server_core.py", line 404, in start_tcp_proxy
    self._potential_protocols.remove(proto)
ValueError: list.remove(x): x not in list

And the client(Win8.1 64-bit r9202) prints over and over:

2015-05-12 09:53:17,017 error processing draw packet
Traceback (most recent call last):
  File "xpra\client\ui_client_base.pyc", line 1974, in _draw_thread_loop
  File "xpra\client\ui_client_base.pyc", line 2020, in _do_draw
  File "xpra\client\client_window_base.pyc", line 423, in draw_region
  File "xpra\client\window_backing_base.pyc", line 473, in draw_region
  File "xpra\client\window_backing_base.pyc", line 264, in paint_rgb24
  File "xpra\client\window_backing_base.pyc", line 175, in process_delta
Exception: expected 3376 bytes for 1x844 with rowstride=4 but received 26 (34 co
mpressed)
2015-05-12 09:53:17,163 invalid img data <type 'str'>: <memory at 0x7fcc2cea1a68
>
2015-05-12 09:53:17,164 draw error
Traceback (most recent call last):
  File "xpra\client\ui_client_base.pyc", line 2020, in _do_draw
  File "xpra\client\client_window_base.pyc", line 423, in draw_region
  File "xpra\client\window_backing_base.pyc", line 473, in draw_region
  File "xpra\client\window_backing_base.pyc", line 264, in paint_rgb24
  File "xpra\client\window_backing_base.pyc", line 175, in process_delta
Exception: expected 3376 bytes for 1x844 with rowstride=4 but received 26 (34 co
mpressed)
2015-05-12 09:53:17,164 draw error
Traceback (most recent call last):
  File "xpra\client\ui_client_base.pyc", line 2020, in _do_draw
  File "xpra\client\client_window_base.pyc", line 423, in draw_region
  File "xpra\client\window_backing_base.pyc", line 473, in draw_region
  File "xpra\client\window_backing_base.pyc", line 264, in paint_rgb24
  File "xpra\client\window_backing_base.pyc", line 175, in process_delta
Exception: expected 3376 bytes for 1x844 with rowstride=4 but received 26 (34 co
mpressed)
2015-05-12 09:53:17,164 error processing draw packet

If you think this new issue is unrelated to the work on this one, then I can open a separate ticket.


Tue, 12 May 2015 17:50:10 GMT - Antoine Martin:

The issues from comment:11 are not likely to be related to the html5 client. (but I don't think we really need a ticket for them unless they persist)

Just to be clear: are you building from trunk (0.16) or from the 0.15.x branch?


Tue, 12 May 2015 18:04:29 GMT - J. Max Mena:

Keyboard randomly broke



ValueError? ..... Steps to reproduce would be welcome


Found a semi-reliable repro using my trunk build:

EDIT:


Just to be clear: are you building from trunk (0.16) or from the 0.15.x branch?


I build from both trunk and 0.15.x branch. I've been starting with 0.15.x since we're working for the release, switching to trunk to see if the issue appears there as well.


Wed, 13 May 2015 07:31:10 GMT - Antoine Martin:

Link to the numlock ticket: #858


Found a semi-reliable repro using my trunk build: (..)


I have tried and tried again, both with trunk and 0.15, no luck! Help!

Are the previous buffer errors gone for you? (r9346 applied the fixes to v0.15.x)


Wed, 13 May 2015 21:28:26 GMT - J. Max Mena:

Help!


Updated to trunk r9357 and I am no longer able to reproduce this error. It appears to have been resolved; at least for my use case - I will keep an eye out for it.

However running 0.15.0 r9357 I get the following traceback many times scrolling in firefox using the firefox HTML 5 viewer:

2015-05-13 14:26:39,648 error processing damage data:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/server/source.py", line 1734, in encode_loop
    fn_and_args[0](*fn_and_args[1:])
  File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1187, in make_data_packet_cb
    packet = self.make_data_packet(damage_time, process_damage_time, wid, image, coding, sequence, options)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1524, in make_data_packet
    ret = encoder(coding, image, options)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window_video_source.py", line 1245, in video_encode
    ret = self._video_encoder.compress_image(csc_image, quality, speed, options)
  File "xpra/codecs/enc_x264/encoder.pyx", line 520, in xpra.codecs.enc_x264.encoder.Encoder.compress_image (xpra/codecs/enc_x264/encoder.c:5861)
AssertionError

EDIT: After actually using firefox after noticing this print it appears that painting is broken using h264. I will attach a screenshot.


Wed, 13 May 2015 21:33:17 GMT - J. Max Mena: attachment set

after scrolling slightly on the fedora start page


Thu, 14 May 2015 04:00:59 GMT - Antoine Martin:

Nope, still no luck. I've tried both trunk and v0.15.x.

Can you please post the exact commands that you've used (both client and server), the exact branch + revisions used for both (and maybe try trunk to see if the bug is present there or not), detailed steps (size of window, etc), xpra info, and anything else that might be relevant.

As of r9358 (trunk), the AssertionError message should include more information.


Thu, 14 May 2015 17:26:33 GMT - J. Max Mena:

Using my 0.15.0 Fedora 21 build r9357 with the following start command:

xpra start :13 --no-daemon --bind-tcp=0.0.0.0:2200 --html=on --start-child=firefox --start-child=xterm --start-child=xterm

In addition I connected using Firefox and the h264 option. With normal fullscreen window enabled.


After updating to the latest r9365 0.15.0 the traceback now prints:

2015-05-14 10:26:06,315 error processing damage data:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/server/source.py", line 1734, in encode_loop
    fn_and_args[0](*fn_and_args[1:])
  File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1187, in make_data_packet_cb
    packet = self.make_data_packet(damage_time, process_damage_time, wid, image, coding, sequence, options)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1524, in make_data_packet
    ret = encoder(coding, image, options)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window_video_source.py", line 1245, in video_encode
    ret = self._video_encoder.compress_image(csc_image, quality, speed, options)
  File "xpra/codecs/enc_x264/encoder.pyx", line 520, in xpra.codecs.enc_x264.encoder.Encoder.compress_image (xpra/codecs/enc_x264/encoder.c:5861)
AssertionError
2015-05-14 10:26:06,370 error processing damage data:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/server/source.py", line 1734, in encode_loop
    fn_and_args[0](*fn_and_args[1:])
  File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1187, in make_data_packet_cb
    packet = self.make_data_packet(damage_time, process_damage_time, wid, image, coding, sequence, options)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1524, in make_data_packet
    ret = encoder(coding, image, options)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window_video_source.py", line 1245, in video_encode
    ret = self._video_encoder.compress_image(csc_image, quality, speed, options)
  File "xpra/codecs/enc_x264/encoder.pyx", line 520, in xpra.codecs.enc_x264.encoder.Encoder.compress_image (xpra/codecs/enc_x264/encoder.c:5861)
AssertionError

Thu, 14 May 2015 18:20:15 GMT - Antoine Martin:

I've just tried it, exactly as you describe, connecting with chrome 42.0.2311.152, no errors at all.

Please try with trunk so we can see the more detailed assert error message. "normal fullscreen window" does not make any difference. Is it required to trigger the bug? xpra info, etc..


Thu, 14 May 2015 18:25:43 GMT - J. Max Mena:

Updated to trunk and the encoding issues have disappeared. It appears to be confined to the 0.15.0 branch for me at the moment.


Fri, 15 May 2015 05:07:37 GMT - Antoine Martin: priority changed

Lowering the priority as I am unable to reproduce, not for a lack of trying.

I think there must be something funny with your environment or build system. Please provide more info on that, and try the latest beta builds I have just made to see if you can reproduce it with those. Please also provide xpra info, etc.


Fri, 15 May 2015 16:52:57 GMT - J. Max Mena:

Retested against an r9368 0.15.0 Fed 21 server from the beta repo and I am unable to reproduce the issue.

Looks like it's my build environment. I'll try poking it a bit and see what I come up with; but for now it looks like that issue has been resolved with your builds.


Fri, 15 May 2015 17:09:43 GMT - Antoine Martin:

To be used sparingly and carefully, this is a script that I use when I want to wipe everything (ie: when switching branches during development):

sudo rm -fr \
   /usr/bin/xpra* \
   /usr/lib*/python*/site-packages/xpra* \
   /usr/share/icons/xpra* \
   /usr/share/man/man1/xpra* \
   /usr/share/xpra*
   /usr/share/applications/xpra* \
   /usr/lib/cups/backend/xpra*

And you may also want to run this from your xpra source directory:

rm -fr build
./setup.py clean

Fri, 15 May 2015 17:29:01 GMT - J. Max Mena:

Connecting with a Win81 r9365 0.15.0 client with --encodings=h264 against your beta build I get the following traceback when highlighting text in Firefox:

2015-05-15 10:27:20,484 sound-source codec: MPEG-1 Layer 3 (MP3)
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 927, in expire_delayed_region
    self.may_send_delayed()
  File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1024, in may_send_delayed
    self.do_send_delayed()
  File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1036, in do_send_delayed
    self.send_delayed_regions(*delayed)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1051, in send_delayed_regions
    self.do_send_delayed_regions(damage_time, window, regions, coding, options)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window_video_source.py", line 575, in do_send_delayed_regions
    return send_nonvideo(encoding=None)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window_video_source.py", line 524, in send_nonvideo
    WindowSource.do_send_delayed_regions(self, damage_time, window, regions, encoding, options, exclude_region=exclude_region, get_best_encoding=get_best_encoding)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1128, in do_send_delayed_regions
    self.process_damage_region(damage_time, window, region.x, region.y, region.width, region.height, actual_encoding, options)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window_video_source.py", line 610, in process_damage_region
    WindowSource.process_damage_region(self, damage_time, window, x, y, w, h, coding, options)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1166, in process_damage_region
    assert coding is not None
AssertionError

Fri, 15 May 2015 19:01:34 GMT - Antoine Martin:

Please post "xpra info" for a session showing this bug.

Just checking: is this still with firefox running through a chrome browser client or a native client directly? Please provide the full version numbers: Chrome, Firefox, etc..

The only way coding can be None here is if we fail to find a valid non-video encoding to use (and there must be a video region detected too at that point). This code path will call get_best_nonvideo_encoding to find one, and this can only return None if the non_video_encodings list is empty, and it should not be:

If this bug is reproducible, running the server with -d encoding could help, it will log the non_video_encodings - which is better than inferring it from "xpra info". If you can reproduce this bug with a native 0.15.x client, please post the output of Encoding_Info.exe, and try with the latest v0.14.x client too.


Fri, 15 May 2015 21:03:54 GMT - J. Max Mena: attachment set

requested Xpra info with broken h264 encoder


Fri, 15 May 2015 21:10:03 GMT - J. Max Mena:

Apologies for forgetting the Xpra info. I just attached it.


For clarification:

This is using a normal Xpra client launched from CMD using the following command: Xpra_cmd.exe attach tcp:10.0.32.137:2200 --encodings=h264

The client is a 0.15.X client that Smo built yesterday that has the revision number r9365. I am using Firefox running on the remote machine to get this error. The remote machine is running your latest Fedora 21 beta build, r9368.


Encoding_Info outputs the following:

codecs and csc modules found:
* PIL                  : library.zip\PIL\__init__.pyc
* enc_vpx              : xpra.codecs.vpx.encoder.pyd
* dec_vpx              : xpra.codecs.vpx.decoder.pyd
* enc_x264             : xpra.codecs.enc_x264.encoder.pyd
* enc_x265             :
* nvenc3               :
* nvenc4               :
* nvenc5               :
* csc_swscale          : xpra.codecs.csc_swscale.colorspace_converter.pyd
* csc_cython           : xpra.codecs.csc_cython.colorspace_converter.pyd
* csc_opencl           :
* dec_avcodec2         : xpra.codecs.dec_avcodec2.decoder.pyd
* enc_webp             : xpra.codecs.webp.encode.pyd
* dec_webp             : xpra.codecs.webp.decode.pyd
codecs versions:
* PIL                  : 2.2.1
* avcodec2             : 56.13.100
* cython               : 0.3.0.20.2
* dec_webp             : 0.4.1
* enc_webp             : 0.4.1
* numpy                : 1.8.1
* swscale              : 3.1.101
* vpx                  : 1.4.0
* x264                 : 142

Also of note:

If I launch the client using --encodings=h264,webp, the issue goes away. It looks to only be a problem when forcing the client to only use h264.


Sat, 16 May 2015 05:05:28 GMT - Antoine Martin:

In the future, please follow wiki/ReportingBugs, in particular the bit where I asked for the exact command lines used (also in comment:16). Knowing that, the bug is trivial to identify: I've moved to #863 since this has nothing to do with the html5 client.

You probably meant to use --encoding=h264 and not --encodings=h264, see the man page for details. Saying In addition I connected using Firefox and the h264 option is NOT sufficient.

If the problems with the html5 client are resolved, please close this ticket.


Also, please be aware that your win32 builds have some seriously out of date libraries:

and probably others..


Wed, 20 May 2015 19:33:34 GMT - J. Max Mena: status changed; resolution set

Everything within the scope of this ticket has been resolved.

Other issues, naturally, have been moved to other tickets.

Closing.


Sat, 23 Jan 2021 05:07:57 GMT - migration script:

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