-
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
Clicks aren't registering properly with Safari on xpra over HTML5 when using SSL #226
Comments
This is probably a side effect of using the new clipboard API with Safari. Lines 2059 to 2060 in 953523e
@heinosasshallik does that work for you? |
I have no idea how to force Safari to accept my self signed certificate, all the examples I found online ended up just bringing me back to the "This connection is not private" certificate error page. |
@totaam You don't need to add a self signed certificate. Just go to "more info" and "visit the page anyway". You'll have an insecure connection, but the bug can be replicated like that easily. Note: It's not actually called "more info" and "visit the page anyway", but it's something like that, and it exists in Chrome and Firefox too. You'll see the option when you're brought to the "This connection is not private" certificate error page. Just in case, I'll mention again that I included an example docker image which will allow you to easily replicate the issue. Bring that up, go to |
No, that doesn't work here. That's the problem. |
Like I said above, it just goes in a loop back to the "This connection is not private" certificate error page. |
The frustration is understandable. I'd hate to deal with the certificate error problem as well. In case it makes any difference, I'm using the latest versions of MacOS and Safari. If yours is not the latest version, then you can try upgrading both of them at once by choosing the "upgrade software" (or similar) option in your Mac's settings. |
I don't have any Apple hardware (that could run recent versions of MacOS) so I run MacOS virtualized and upgrading does not work... |
Wonderful! Thank you so much! When do you think we could get this fix into a new release? Just asking so I know whether to wait for the release or hot patch it in. |
I was going to make a new release this week, but MacOS has taken so much of my time that this looks unlikely now. |
Replicating your workaroundI tried to replicate your workaround and it was a nightmare, but I think I got it working. No matter what I did, the bug would remain because the changes I tried to make weren't actually applying. I assume it's a caching issue. I'll detail my steps in case anyone else tries to replicate this issue. In order to make sure the workaround was applying, I tried the following things:
I verified that the workaround was in fact not in place by going to the elements tab, copying the HTML, pasting it into vim and seeing if the workaround code was there. Note: searching in the elements tab did not work properly in my version of Safari. The only thing that finally worked was running the container on a completely different server and making sure the workaround is in place before ever connecting to xpra with Safari. What a nightmare... ConclusionsI can see that the workaround introduced this issue: #227, and that xpra is still unusable on Safari on HTTPS, even after the workaround. Like in your case, my window was also not drawn after I put the workaround in place. I remember that your first suggestion was to comment out these lines: Lines 2059 to 2060 in 953523e
It's possible that the above solution would have also worked, and I just didn't see the changes due to the caching. I can try it out, if someone tells me how to get rid of Safari's caching without spinning up a new server each time. |
Commenting out those 2 lines was just my initial guess, but it turns out that any clipboard access triggers this Safari "feature" so the best thing we can do for now is to disable clipboard support when Safari is used with Edit: the workaround has nothing to do with #227 - which is just another Safari "feature". |
but we also want to change the default setting on the connect page
There are so many things wrong with Safari, especially #227, that I'm not going to spend any time on this. |
Firefox is now broken in exactly the same way: #301 |
Describe the bug
When using Safari with XPRA served over HTML, over HTTPS, then when you left-click, the left click doesn't go through, and it says it shows a menu with "Paste" in it (as if you had right clicked).
Screenshot showing the menu with "Paste" in it that appears when left clicking:
This issue only occurs when connecting to xpra over HTTPS, and not when connecting over HTTP. Keyboard keys still work. This issue does not occur with Chrome or Firefox.
To Reproduce
Steps to reproduce the behavior:
I have created a minimal reproducible case for you to test this out.
minimal_test_case.zip
Steps to reproduce using the minimal reproducible case:
docker-compose build
to build the imagedocker-compose up
to bring the image uphttps://IP_ADDRESS_HERE:14500
xpra
. Enter the password so you can see the application.I served the application from a Linux machine and connected to it from a Mac, so for me,
IP_ADDRESS_HERE
was the IP address of the Linux machine on the local network.System Information (please complete the following information):
Additional context
On Safari version 14.1.2 (16611.3.10.1.16), no image shows up at all, but that's probably a separate issue.
The text was updated successfully, but these errors were encountered: