-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTML5 Client 4.5 - client decoding error - failed to create image bitmap from webp [object Blob] #101
Comments
I have transferred your issue to the xpra-html5 project as I am fairly confident that the problem comes from your browser not supporting the decoding of webp images in the decode worker. Looks like we will need to validate webp decoding better before enabling it. |
Many thanks for immediately looking into this. Meanwhile I have tried selecting PNG encoding on the HTML5 client (http://192.168.56.80:14500/connect.html), and I got a similar error after establishing the session...
I'm sure you are correct that it is an HTML5 client issue, but probably a more generic one than just webp decoding. Thanks again, |
Can you please specify the exact version of the rpm -q xpra-html5 As per the previous comment, please try other versions, in particular: |
Hi, Thanks again for the guidance. :) Please below find the HTML5 Client versions on my test environments... 1.) CentOS v7.9 with Xpra from https://xpra.org/dists/CentOS/7.9.2009/x86_64/ - Where I do have the error with all browsers (Chrome / Safari / Firefox / Opera)
2.) CentOS v7.9 with Xpra from https://xpra.org/dists/CentOS/7.7.1908/x86_64/ - Where I do have the error w/Chrome only
3.) CentOS v7.7 with Xpra from https://xpra.org/dists/CentOS/7.7.1908/x86_64/ - Where I don't have the error with any browser (Chrome / Safari / Firefox / Opera)
It is interesting that in case 2.) the HTML5 client which seems to be installed is 3.0.9, but in the session log I get 4.5-r1031...
Thanks, |
You should have 4.5.1 installed, not 4.5 - not sure why that is. You may want to try the beta 4.5.2 builds I have just uploaded: |
Yeah, it is really puzzling why I get a different HTML5 client version on the same host / same Xpra deployment, depending on the browser. Just to summarize... CentOS v7.9 with Xpra from https://xpra.org/dists/CentOS/7.7.1908/x86_64/
CentOS v7.9 with Xpra from https://xpra.org/dists/CentOS/7.7.1908/x86_64/ - Safari Version 14.1.2 (15611.3.10.1.5, 15611) / Mac (OK)
CentOS v7.9 with Xpra from https://xpra.org/dists/CentOS/7.7.1908/x86_64/ - Fiorefox 93.0 (64-bit) / Mac (OK)
CentOS v7.9 with Xpra from https://xpra.org/dists/CentOS/7.7.1908/x86_64/ - Chrome Version 94.0.4606.81 (Official Build) (64-bit) / Windows (ERR)
It seems as of the HTML5 client version would be browser dependent. And when using CentOS v7.9 with Xpra from https://xpra.org/dists/CentOS/7.9.2009/x86_64/
...that's when the HMTL5 client changes to 4.5 for all browsers, and all has the client decording error... CentOS v7.9 with Xpra from https://xpra.org/dists/CentOS/7.9.2009/x86_64/ - Safari Version 14.1.2 (15611.3.10.1.5, 15611) / Mac (ERR)
CentOS v7.9 with Xpra from https://xpra.org/dists/CentOS/7.9.2009/x86_64/ - Fiorefox 93.0 (64-bit) / Mac (ERR)
CentOS v7.9 with Xpra from https://xpra.org/dists/CentOS/7.9.2009/x86_64/ - Chrome Version 94.0.4606.81 (Official Build) (64-bit) / Windows (ERR)
It seems as if client version 4.5-r1031 would have the issue in general. How it appears for Chrome when xpra-html5-3.0.9-10.r26132xpra3.el7_7.noarch is installed, that's a bit of a mistery to me, while for all other browsers client version 3.0.9 is shown / working well. I'll go ahead now and try the beta 4.5.2 builds from https://xpra.org/beta/CentOS/7/x86_64/ and will let you know my findings. I really appreciate all your help so far, |
I have updated the xpra-html5 from xpra-html5-4.5.2-1.r1057.el7.noarch.rpm on the CentOS v7.9 host having Xpra installed from https://xpra.org/dists/CentOS/7.9.2009/x86_64/ as follows...
...then I have started Xpra...
...but unfortunately I still got the same error...
Sorry, I have a feeling that I must be missing something obvious here. :( |
I agree.
Make sure the correct version is installed: $ grep VERSION /usr/share/xpra/www/js/Utilities.js
VERSION : "4.5.2", And assuming that it is correct ( |
I'm sincerely at a loss here. I have started from scratch with a clean CentOS v7.9 VM, and... 1.) installed Xpra using https://xpra.org/beta/CentOS/7/x86_64/ as the source... NOTE: It was missing the turbojpeg dependency, which I have added manually, as seen in the log below
2.) Next I have disabled the systemd startup...
3.) Then I have started the Xpra proxy manually, making sure first it is not running...
4.) Then I have verified the IP of my VM...
5.) Also checked the installed Xpra HTML5 client version as you have advised...
6.) Now that the Xpra proxy was running on 192.168.56.80, I have connected to it from my browser via http://192.168.56.80:14500/connect.html launching /usr/bin/xterm, where I ran into the refresh issue as usually. 7.) This is the contents of the /run/user/1000/xpra/:1.log with the usual error and the unexpected HTML5 client version...
8.) And these are the Xpra packages installed on the system...
I sincerely appreciate all the time you are spending on trying to help me here. If needed, I am happy to make available the VirtualBox VM to you, if making first-hand checks on it would save time for you. Many thanks again, |
Hi Antoine, I spent some more time experimenting, and found that if I launch Xpra with the command below on the CentOS 7.9 server...
...and just attach to the session... ...the HTML5 client version still shows incorrectly in the log file...
...but I get no client decoding errors. The difference seems to be compared to the previous logs where the error was present, is that in those cases, the user session was launched via a proxy session...
Here is the full log for reference...
I hope this helps in narrowing the problem down to its source. Many thanks, |
Hi Antoine, Apologies for all the spam here. Finally I have managed to get the correct HTML5 Client version appear in the log file, by cleaning up the cache of the browser. Now I get the correct HTML5 Client loaded...
Unfortunately the client decoding error is still there with the client version 4.5.2-r1046, if I go via the Xpra proxy. If I just attach to a session pre-launched on the server using...
...then all is well...
If I downgrade the HTML5 client to xpra-html5-3.1-10.41xpra1.el7.noarch.rpm, then all is well both via proxy and direct connection
Then if I upgrade the HTML5 client to xpra-html5-4.3-1.r1008.el7.noarch.rpm, then the problem starts to happen while going via the Xpra proxy...
Conclusively, it seems like if the HTML5 client is v4.x and it goes via the Xpra proxy v3.1 then the client decoding error seems to occur. Sorry again for all the spam, just would like to save you the trouble of having to go through the same hurdle finding the trigger for the error to occur. Wishing you a good weekend, |
Thanks a lot for the info. Will fix. |
I haven't looked at this in great detail yet but I'm going to guess that the problem is going to be similar to Xpra-org/xpra@239a2dc @walakee you can try applying it by hand to your installation. |
@totaam thanks for the additional details. When you say...
...can you please let me know in a bit more detail what I should do. I have to admit, I'm a bit of a noob, I know how to install RPM packages, but patching / compiling source code is way beyond by abilities. Apologies for that. |
OTOH - untested: wget https://github.com/Xpra-org/xpra/commit/462b576824ac58ba7120286941fba93bd34439cf.patch
f=`python -c "import xpra;print(xpra.__file__)"`
DIR=`dirname $f`
patch -p2 -d $DIR < 462b576824ac58ba7120286941fba93bd34439cf.patch |
@totaam, many thanks for the detailed help. I'm afraid I was able to apply the patch with limited success (1 out of 3 hunks FAILED). Please find the screen log below...
These are the Xpra packages I have installed...
Sorry if I have messed something up above, causing the issue. |
My bad, sorry. I forgot that you're running 3.x. wget https://github.com/Xpra-org/xpra/commit/32d940445bd5c3ad020f846d5261063d3ab1ffc4.patch
.. |
Thanks for the immediate reply. Do I need to undo the previously applied patch somehow, before going ahead with the one above? |
Yes. If that's too difficult, you can also just re-install the original package. |
Thanks for the tip, I took the easy way, and I went for stopping...
...then uninstalling / reinstalling python2-xpra-server-3.1-10.29270xpra1.el7.x86_64.rpm, and then was able to apply the patch successfully...
...then I have started the Xpra service...
Then I did a browser cache cleanup, and started a new session via the proxy, but unfortunately it seems like the client decoding error issue is still present...
Sorry for the bad news, and thanks again for all your help... |
Sorry, that didn't work. |
No worries. Many thanks for all the time you put into trying to help me. I definitely owe you a beer (or more)!!! |
@totaam, just one more thought: this is the contents of my /lib64/python2.7/site-packages/xpra/server/proxy directory after applying the patch above...
I see that the proxy_instance.py and proxy_instance.pyc files have been updated, but the proxy_instance.pyo was not. I'm just wondering if this could be the reason why the patch didn't work? Maybe I missed something obvious I should have done after applying the patch? |
|
This should not be happening.
See:
That narrows it down somewhat. |
I did so, and the
Here I have started a session via the HTML5 client, and then the
There is probably nothing to check here, it is more just an FYI. |
It only happened when I used https://xpra.org/beta/CentOS/7/x86_64/ as the installation source. I did not have this issue with the other repos. |
Many thanks, for all your time spent on this... |
only take into account encodings actually enabled by the client
We now also validate
|
Many thanks for the update. Is there anything you would like me to test? |
@totaam, I'm just wondering if you were able to get anywhere with this, and if there is anything I can do to help you? I'm no programmer unfortunately - as you may have guessed from my comments above - but would be glad to help with testing if that is helpful? |
@walakee it's near the top of my TODO list, I'm hoping to find the time to investigate soon. |
@totaam many thanks for the update. I don't suppose you will be able to get to this before Christmas? I understand that December can be hectic for most people? :) |
@walakee I do intend to try to deal with this ASAP, bear with me. |
Blocked by: Xpra-org/xpra#3346 |
Now that the proxy bug is out of the way, I can finally reproduce this one using the 3.1.x branch and xpra start --start=xterm :10
xpra proxy --bind-tcp=0.0.0.0:14500 --tcp-auth=allow --no-daemon Connecting with chrome:
And the javascript console shows:
Turning off the decode worker (#20) fixes things. |
Someone smarter than me can figure out why the decode worker is having those problems with the legacy packet encoders. @walakee this should fix your problem, you can apply the commit above by hand (it's tiny) or wait for the beta |
@totaam many thanks for all your help with this. I'm glad to report that with One thing I ran into is, that windows now initially appear fine... ...but after resizing the window, the contents disappear... ...if I switch to a different browser tab, and switch back, the contents appear again. I guess I need to open an other ticket for this? Many thanks again, |
@totaam, many thanks for the hint on the forced refresh. I have the same lines in the /usr/share/xpra/www/js/Window.js file (dated Dec 19 06:13 / size 50,781 bytes / xpra-html5.noarch 4.5.2-1.r1107.el7), but the issue mentioned above is still present (xterm goes blank after resize). Sorry if I have missed something obvious? |
Ah, OK, understood. Thanks for the clarification... :) |
Dear Xpra Developers,
I am a happy user of Xpra on CentOS v7.7, but time has come to upgrade to CentOS v7.9. In preparation for the upgrade I wanted to test Xpra on a clean lab environment, so I have built a clean CentOS v7.9 VM, and installed Xpra on it using https://xpra.org/dists/CentOS/7.9.2009/x86_64/ as the source. The issue I'm running into is, if I start an Xpra session via a the HTML5 client using Chrome, I don't get screen refreshes, and the /run/user/1000/xpra/:1.log file gets filled with the errors as follows...
Same configuration works fine with CentOS v7.7 and Xpra installed from https://xpra.org/dists/CentOS/7.7.1908/x86_64/.
This is the contents of the /etc/xpra/xpra.conf file...
...and the Xpra proxy is being launched with...
The above is true for both the CentOS v7.7 with Xpra installed from https://xpra.org/dists/CentOS/7.7.1908/x86_64/ environment, as well as for the CentOS v7.9 with Xpra installed from https://xpra.org/dists/CentOS/7.9.2009/x86_64/ environment.
Below is the full log from /run/user/1000/xpra/:1.log on CentOS v7.7 with Xpra installed from https://xpra.org/dists/CentOS/7.7.1908/x86_64/ environment, where I have no issues, for reference...
Below is the full log from /run/user/1000/xpra/:1.log on CentOS v7.9 with Xpra installed from https://xpra.org/dists/CentOS/7.9.2009/x86_64/ environment, where I have have the problem...
Interestingly, if I install Xpra from https://xpra.org/dists/CentOS/7.7.1908/x86_64/ on CentOS v7.9, I also have the issue. Here is the log of that...
One difference I have found in the logs between CentOS v7.7 and CentOS v7.9 while Xpra being installed from https://xpra.org/dists/CentOS/7.7.1908/x86_64/ is, the following lines...
CentOS v7.7 / Xpra for CentOS 7.7.1908 - Chrome Version 94.0.4606.81 (Official Build) (64-bit) / Windows (OK)
CentOS v7.9 / Xpra for CentOS 7.7.1908 - Chrome Version 94.0.4606.81 (Official Build) (64-bit) / Windows (ERR)
I also tried different browsers connecting to CentOS v7.9 while Xpra being installed from https://xpra.org/dists/CentOS/7.7.1908/x86_64/ with the following success rate...
CentOS v7.9 / Xpra for CentOS 7.7.1908 - Safari Version 14.1.2 (15611.3.10.1.5, 15611) / Mac (OK)
CentOS v7.9 / Xpra for CentOS 7.7.1908 - Fiorefox 93.0 (64-bit) / Mac (OK)
Unfortunately none of the above works when using CentOS v7.9 / Xpra for CentOS 7.9.2009. In that case the HTML5 client version will show 4.5 in the logs, and I get the same error like with Google Chrome above.
Any help would be greatly appreciated, making Xpra work on CentOS v7.9 / Xpra for CentOS 7.9.2009 and Google Chrome.
Many thanks,
Walakee
PS: Apologies if the information above was a bit overwhelming. This is my first GitHub post, so I'm not sure about the level of detail expected here.
The text was updated successfully, but these errors were encountered: