You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@guacamole.apache.org by Lucio Seki <ls...@redhat.com> on 2021/02/03 11:51:36 UTC
Clipboard bugs
Hello folks,
I found several clipboard issues using Guacamole 1.3.0, but couldn't find
any related discussions in JIRA nor in the mailing list archive.
Should I create bug reports for them?
Following is the description of what I'm facing.
---
# Overview
I have 2 physical machines:
- A laptop running RHEL8
- A laptop running Windows 10
On the RHEL8 laptop, I have 2 KVM instances:
- Fedora 33
- RHEL8
Local/remote combinations I tested:
- RHEL8/RHEL8
- RHEL8/Fedora 33
- RHEL8/Windows 10
- Fedora 33/RHEL8
- Fedora 33/Windows 10
- Windows 10/RHEL8
- Windows 10/Fedora 33
For RHEL8 and Fedora 33 remotes, I used the following environments:
- Wayland (GNOME)
- X11 (Gnome Classic)
Web browsers I used for testing:
- Google Chrome
- Mozilla Firefox
I executed the test in the 24 combinations from the above items.
# Guacamole installation
On the RHEL8 laptop, I created 2 Podman containers:
- guacamole/guacd
- guacamole/guacamole
First, I defined the following user-mapping.xml:
```
<user-mapping>
<authorize username="guacadmin" password="guacadmin">
<connection name="kvm">
<protocol>vnc</protocol>
<param name="hostname">10.88.0.1</param>
<param name="port">5900</param>
<param name="password">guacamole</param>
</connection>
<connection name="windows 10">
<protocol>rdp</protocol>
<param name="hostname">192.168.15.10</param>
<param name="ignore-cert">true</param>
</connection>
</authorize>
</user-mapping>
```
I started the containers running the following commands:
```
$ sudo podman run --name lseki-guacd \
-p 4822:4822 \
-e GUACD_LOG_LEVEL=debug \
-d guacamole/guacd
$ sudo podman run --name lseki-guacamole \
-v `pwd`:/etc/guacamole --privileged \
-e GUACAMOLE_HOME=/etc/guacamole \
-e GUACD_HOSTNAME=10.88.0.1 \
-e GUACD_PORT=4822 \
-d -p 8080:8080 guacamole/guacamole
```
# Test scenario
I executed the following steps to test the clipboard behavior:
1. open guacamole home in a private browser window
2. allow access to the clipboard if asked
3. login to the remote machine
4. open gedit/notepad and type:
```
L1#1234567890
L2#1234567890
L3#1234567890
L4#1234567890
L5#1234567890
#copied from remote clipboard#"
```
5. on local machine, select and copy:
```
#copied from local clipboard#
```
6. on remote machine, position the cursor after "L1#1234" and press Ctrl+V
7. close any window that might open
8. select "#copied from remote clipboard#" in the gedit/notepad and press
Ctrl+C
9. position the cursor after "L2#1234" and press Ctrl+V
10. close any window that might open
11. position the cursor after "L3#1234", right click and Paste
12. press Ctrl+Shift+Alt to show Guacamole clipboard textarea, erase any
text written there, and write "#copied from guacamole clipboard#"
13. Press Ctrl+Shift+Alt to hide Guacamole clipboard textarea
14. position the cursor after "L4#1234" and press Ctrl+V
15. close any window that might open
16. position the cursor after "L5#1234" and use the browser Paste option
17. close any window that might open
18. select all and press Ctrl+C
19. press Ctrl+Alt+Shift to show Guacamole clipboard textarea and copy
what's written there
20. close gedit/notepad and logout
I recorded the screen while running these tests and uploaded to YouTube [0].
I compiled the test results in CSV [1]. Please open it with some
spreadsheet software, as GitHub doesn't render the linebreaks.
# Test results
In summary, following are the main issues I found:
1. On RHEL8 and Fedora 33 locals, if you're using Firefox, pressing
Ctrl+V opens "Print" and/or "Open" window instead of pasting.
2. On RHEL8 and Fedora 33 remotes, if you're using Firefox, using browser
Edit menu -> Paste will paste the local clipboard content, but special
characters will be replaced by non-special ones (e.g. '#' becomes '3').
3. On Windows 10 local, if you're using Google Chrome, you can't paste
local clipboard content to the remote.
4. On Windows 10 local, if you're using Firefox, you can't paste local
clipboard content to the remote except if you use browser's Edit menu ->
Paste, but you'll face issue #2.
5. On RHEL8 and Fedora 33 remotes, the remote clipboard is not updated
with the Guacamole clipboard content.
6. On RHEL8 and Fedora 33 remotes, the Guacamole clipboard won't be
updated with the remote clipboard content.
7. Browser Edit menu -> Paste operation behavior is inconsistent among
browsers/locals/remotes.
---
Please let me know if I should create bug reports for the issues above.
Regards,
[0] https://www.youtube.com/playlist?list=PL-zQ6cGNR-toZKpJPbA3LE06eszyJOx_7
[1] https://gist.github.com/lucioseki/287f30fbtbd022fe0ff084667e25243da
<https://gist.github.com/lucioseki/287f30fbbd022fe0ff084667e25243da>
--
Lucio Seki
He / Him / His
Senior Systems Administrator, RH Training - Learning Platforms
Red Hat <https://www.redhat.com/>
lucio@redhat.com
<https://www.redhat.com/>
Re: Clipboard bugs
Posted by Lucio Seki <ls...@redhat.com>.
Thanks Mike, I created the following issues in Guacamole JIRA:
https://issues.apache.org/jira/browse/GUACAMOLE-1281 [Bug] Ctrl+V keyboard
shortcut opens Open File dialog
https://issues.apache.org/jira/browse/GUACAMOLE-1282 [New Feature] Add
option to send key events instead of accessing the remote clipboard
Regards,
--
Lucio
On Thu, Feb 4, 2021 at 6:07 PM Mike Jumper <mi...@glyptodon.com>
wrote:
> On Wed, Feb 3, 2021 at 1:58 PM Lucio Seki <ls...@redhat.com> wrote:
>
>> Thanks for the quick reply, Mike.
>>
>> On Wed, Feb 3, 2021 at 4:06 PM Mike Jumper <mi...@glyptodon.com>
>> wrote:
>>
>>> On Wed, Feb 3, 2021 at 3:52 AM Lucio Seki <ls...@redhat.com> wrote:
>>>
>>>> ...
>>>>
>>>
>>> In summary, following are the main issues I found:
>>> 1. On RHEL8 and Fedora 33 locals, if you're using Firefox, pressing
>>> Ctrl+V opens "Print" and/or "Open" window instead of pasting.
>>>
>>> This sounds like the clipboard contents are (somehow) being turned into
>>> key events when a paste attempt is made, possibly by the
>>> "Guacamole.InputSink" object recently added to allow dead keys to work.
>>>
>>>
>> Should I report a bug for this?
>>
>
> Yes, please.
>
> ...
>> As I'm using KVM's VNC server, I don't have VNC servers running on the
>> remote machines at all.
>> It seems that KVM's VNC server doesn't have access to the VM's clipboard.
>>
>
> Right - the clipboard isn't exposed at all via KVM's VNC server.
>
> In this case, would it be possible to make Google Chrome send key events
>> instead, as in Firefox?
>>
>
> Perhaps. Intentionally supporting paste via the browser's "Edit" menu and
> sending the text as hopefully-equivalent keystrokes is an interesting idea.
> Providing a similar option via the Ctrl+Alt+Shift menu could also be
> interesting. When you pop over to our JIRA to report the issue with Firefox
> paste behavior, I suggest also opening a feature request for this.
>
> Can you clarify what this means vs. what was mentioned earlier with
>>> respect to Firefox? Inconsistent how?
>>>
>>
>> Depending on the browser and the remote OS combination (the local OS
>> doesn't matter), the behavior is different:
>> - Firefox with remote RHEL8/Fedora 33: pastes the local clipboard content
>> but replaces special characters with non-special characters.
>> - Firefox with remote Windows 10: pastes the remote clipboard content.
>> - Google Chrome with any local/remote OS combination: nothing happens.
>>
>>
>>> The browser "Edit -> Paste" operation really should not be available.
>>>
>>
>> So Google Chrome is behaving correctly by doing nothing, and Firefox is
>> behaving unexpectedly by sending key events when it shouldn't.
>>
>
> Yes.
>
> - Mike
>
>
Re: Clipboard bugs
Posted by Mike Jumper <mi...@glyptodon.com>.
On Wed, Feb 3, 2021 at 1:58 PM Lucio Seki <ls...@redhat.com> wrote:
> Thanks for the quick reply, Mike.
>
> On Wed, Feb 3, 2021 at 4:06 PM Mike Jumper <mi...@glyptodon.com>
> wrote:
>
>> On Wed, Feb 3, 2021 at 3:52 AM Lucio Seki <ls...@redhat.com> wrote:
>>
>>> ...
>>>
>>
>> In summary, following are the main issues I found:
>> 1. On RHEL8 and Fedora 33 locals, if you're using Firefox, pressing
>> Ctrl+V opens "Print" and/or "Open" window instead of pasting.
>>
>> This sounds like the clipboard contents are (somehow) being turned into
>> key events when a paste attempt is made, possibly by the
>> "Guacamole.InputSink" object recently added to allow dead keys to work.
>>
>>
> Should I report a bug for this?
>
Yes, please.
...
> As I'm using KVM's VNC server, I don't have VNC servers running on the
> remote machines at all.
> It seems that KVM's VNC server doesn't have access to the VM's clipboard.
>
Right - the clipboard isn't exposed at all via KVM's VNC server.
In this case, would it be possible to make Google Chrome send key events
> instead, as in Firefox?
>
Perhaps. Intentionally supporting paste via the browser's "Edit" menu and
sending the text as hopefully-equivalent keystrokes is an interesting idea.
Providing a similar option via the Ctrl+Alt+Shift menu could also be
interesting. When you pop over to our JIRA to report the issue with Firefox
paste behavior, I suggest also opening a feature request for this.
Can you clarify what this means vs. what was mentioned earlier with respect
>> to Firefox? Inconsistent how?
>>
>
> Depending on the browser and the remote OS combination (the local OS
> doesn't matter), the behavior is different:
> - Firefox with remote RHEL8/Fedora 33: pastes the local clipboard content
> but replaces special characters with non-special characters.
> - Firefox with remote Windows 10: pastes the remote clipboard content.
> - Google Chrome with any local/remote OS combination: nothing happens.
>
>
>> The browser "Edit -> Paste" operation really should not be available.
>>
>
> So Google Chrome is behaving correctly by doing nothing, and Firefox is
> behaving unexpectedly by sending key events when it shouldn't.
>
Yes.
- Mike
Re: Clipboard bugs
Posted by Lucio Seki <ls...@redhat.com>.
Thanks for the quick reply, Mike.
On Wed, Feb 3, 2021 at 4:06 PM Mike Jumper <mi...@glyptodon.com>
wrote:
> On Wed, Feb 3, 2021 at 3:52 AM Lucio Seki <ls...@redhat.com> wrote:
>
>> ...
>>
>
> In summary, following are the main issues I found:
> 1. On RHEL8 and Fedora 33 locals, if you're using Firefox, pressing
> Ctrl+V opens "Print" and/or "Open" window instead of pasting.
>
> This sounds like the clipboard contents are (somehow) being turned into
> key events when a paste attempt is made, possibly by the
> "Guacamole.InputSink" object recently added to allow dead keys to work.
>
>
Should I report a bug for this?
2. On RHEL8 and Fedora 33 remotes, if you're using Firefox, using browser
>> Edit menu -> Paste will paste the local clipboard content, but special
>> characters will be replaced by non-special ones (e.g. '#' becomes '3').
>>
>
> This sounds like a secondary manifestation of the above (clipboard
> contents becoming key events under Firefox). The browser's own "Edit ->
> Paste" option should not be available, and if used I wouldn't expect it to
> have any effect. Local clipboard contents are forwarded to the remote end
> through the clipboard functionality of the underlying protocol, with any
> subsequent paste then happening only remotely.
>
>
3. On Windows 10 local, if you're using Google Chrome, you can't paste
>> local clipboard content to the remote.
>>
>
> Clipboard is definitely not fundamentally broken on Chrome. You should be
> able to copy/paste directly using the local clipboard if you have granted
> access when prompted. If you refused to grant access, you can edit the
> contents of the clipboard using the clipboard interface in the Guacamole
> menu (Ctrl+Alt+Shift). Beware that Chrome will refuse to prompt for access
> if not operating over SSL.
>
>
I'm not using SSL, so I added the Guacamole URL to the "Insecure origins
treated as secure" setting
(chrome://flags/#unsafely-treat-insecure-origin-as-secure) in order to
grant access to the clipboard.
Guacamole is able to read my local clipboard, as the Guacamole menu
clipboard is updated with my local clipboard contents [0].
I think I'm facing the same issue as #5 and #6, as I'm always trying to
connect to KVM instances, and KVM's VNC server running on the hypervisor
doesn't have access to the VM's clipboard.
I'll try a local Win 10 to remote Win 10 connection, and give an update on
this.
4. On Windows 10 local, if you're using Firefox, you can't paste local
>> clipboard content to the remote except if you use browser's Edit menu ->
>> Paste, but you'll face issue #2.
>>
>
> This also sounds the same as #1 - clipboard contents are being turned into
> key events under Firefox, with further unexpected behavior due to Ctrl
> being held if the paste occurs through Ctrl+V.
>
> 5. On RHEL8 and Fedora 33 remotes, the remote clipboard is not updated
>> with the Guacamole clipboard content.
>> 6. On RHEL8 and Fedora 33 remotes, the Guacamole clipboard won't be
>> updated with the remote clipboard content.
>>
>
> There are no known issues where clipboard would simply not work at all,
> and it is unlikely that so fundamental a bug exists on the Guacamole side
> (it would be easily noticed during testing and in regular use). Assuming
> these are VNC machines, be sure to verify that the "vncconfig" tool is
> running on the remote side, as Linux VNC servers normally require this for
> clipboard to be forwarded back and forth.
>
>
As I'm using KVM's VNC server, I don't have VNC servers running on the
remote machines at all.
It seems that KVM's VNC server doesn't have access to the VM's clipboard.
In this case, would it be possible to make Google Chrome send key events
instead, as in Firefox?
> 7. Browser Edit menu -> Paste operation behavior is inconsistent among
>> browsers/locals/remotes.
>>
>
> Can you clarify what this means vs. what was mentioned earlier with
> respect to Firefox? Inconsistent how?
>
Depending on the browser and the remote OS combination (the local OS
doesn't matter), the behavior is different:
- Firefox with remote RHEL8/Fedora 33: pastes the local clipboard content
but replaces special characters with non-special characters.
- Firefox with remote Windows 10: pastes the remote clipboard content.
- Google Chrome with any local/remote OS combination: nothing happens.
> The browser "Edit -> Paste" operation really should not be available.
>
So Google Chrome is behaving correctly by doing nothing, and Firefox is
behaving unexpectedly by sending key events when it shouldn't.
> If you're seeing this with Firefox, and the inconsistency is that the
> option exists with Firefox but not other browsers, this sounds like another
> instance of the same issue as noted in #1: the presence of a hidden input
> field (necessary for dead key support) results in Firefox believing that
> paste within that field is possible, with any attempt at such a paste
> resulting in the clipboard contents turning into key events.
>
> - Mike
>
>
[0] https://youtu.be/wbQ6tfmqH5c?t=70
---
Lucio
Re: Clipboard bugs
Posted by Mike Jumper <mi...@glyptodon.com>.
On Wed, Feb 3, 2021 at 3:52 AM Lucio Seki <ls...@redhat.com> wrote:
> ...
>
In summary, following are the main issues I found:
1. On RHEL8 and Fedora 33 locals, if you're using Firefox, pressing
Ctrl+V opens "Print" and/or "Open" window instead of pasting.
This sounds like the clipboard contents are (somehow) being turned into key
events when a paste attempt is made, possibly by the "Guacamole.InputSink"
object recently added to allow dead keys to work.
2. On RHEL8 and Fedora 33 remotes, if you're using Firefox, using browser
> Edit menu -> Paste will paste the local clipboard content, but special
> characters will be replaced by non-special ones (e.g. '#' becomes '3').
>
This sounds like a secondary manifestation of the above (clipboard contents
becoming key events under Firefox). The browser's own "Edit -> Paste"
option should not be available, and if used I wouldn't expect it to have
any effect. Local clipboard contents are forwarded to the remote end
through the clipboard functionality of the underlying protocol, with any
subsequent paste then happening only remotely.
3. On Windows 10 local, if you're using Google Chrome, you can't paste
> local clipboard content to the remote.
>
Clipboard is definitely not fundamentally broken on Chrome. You should be
able to copy/paste directly using the local clipboard if you have granted
access when prompted. If you refused to grant access, you can edit the
contents of the clipboard using the clipboard interface in the Guacamole
menu (Ctrl+Alt+Shift). Beware that Chrome will refuse to prompt for access
if not operating over SSL.
4. On Windows 10 local, if you're using Firefox, you can't paste local
> clipboard content to the remote except if you use browser's Edit menu ->
> Paste, but you'll face issue #2.
>
This also sounds the same as #1 - clipboard contents are being turned into
key events under Firefox, with further unexpected behavior due to Ctrl
being held if the paste occurs through Ctrl+V.
5. On RHEL8 and Fedora 33 remotes, the remote clipboard is not updated
> with the Guacamole clipboard content.
> 6. On RHEL8 and Fedora 33 remotes, the Guacamole clipboard won't be
> updated with the remote clipboard content.
>
There are no known issues where clipboard would simply not work at all, and
it is unlikely that so fundamental a bug exists on the Guacamole side (it
would be easily noticed during testing and in regular use). Assuming these
are VNC machines, be sure to verify that the "vncconfig" tool is running on
the remote side, as Linux VNC servers normally require this for clipboard
to be forwarded back and forth.
7. Browser Edit menu -> Paste operation behavior is inconsistent among
> browsers/locals/remotes.
>
Can you clarify what this means vs. what was mentioned earlier with respect
to Firefox? Inconsistent how?
The browser "Edit -> Paste" operation really should not be available. If
you're seeing this with Firefox, and the inconsistency is that the option
exists with Firefox but not other browsers, this sounds like another
instance of the same issue as noted in #1: the presence of a hidden input
field (necessary for dead key support) results in Firefox believing that
paste within that field is possible, with any attempt at such a paste
resulting in the clipboard contents turning into key events.
- Mike