Hello all, With the frequency that questions like the forwarded email below are asked, I think we should look to adding an up-to-date FAQ on the website (not within the manual) which covers these questions/issues.
So far, the following come to mind: * Something fundamental to Guacamole isn't working for me. Where do I report this? (Remember that guac is used by many others without issue, and the more fundamental a problem is, the less likely it's a bug - troubleshooting steps, check the logs, failing that ask on the mailing lists.) * I have set things up successfully, however if i try [X], instead of [Y] happening as documented, [Z] happens. Where should I report this? (JIRA) * I have found an issue which may have security implications. Where should I report this? (private@) * Why don't you just use the clipboard directly instead of the box in the menu? (JavaScript cannot access the clipboard directly for security reasons) * I see the browser has "copy" and "paste" events. Why don't you handle these events so clipboard works? (Doing so is actually varying combinations of impossible and unreliable, and ultimately results in confusion.) * I press [keyboard shortcut] but it's handled by my browser or operating system instead of the remote desktop. Can you fix this? (No, guac already attempts to handle all keyboard events, and can't control whether your browser or operating system reserve some keyboard shortcuts for their own use.) * I need to share files on my computer with the remote desktop. I see Guacamole has drive redirection support, but only for files accessible to the Guacamole server. How can I share local files? (This is not possible, JavaScript cannot access local files directly in this way.) * I want to print to my local printer. I see Guacamole has printing support, but this produces a PDF download. How do I print directly to my local printers? (This is not possible, JavaScript cannot access local printers. It is possible to cause the PDF to automatically open a print dialog, and on some browsers it is also possible to automatically open the PDF, but currently this does not actually work reliably across all platforms and whether it will work cannot be detected.) * Can you add support for X11 forwarding to SSH? (No, this wouldn't actually work well in practice, but there is an X.Org driver being written) * I'm trying to connect to my remote desktop by it isn't working. Why? (troubleshooting procedures, how to check the logs) * I am using an application within the remote desktop under Guacamole, but the application isn't working correctly. Can you fix Guacamole so it doesn't break my application? (it isn't) * When I connect via RDP, the screen size is set correctly, but it does not update if I resize the browser window. Why? * When I connect via VNC, the screen size is not set correctly. It remains the same regardless of the browser window's size. Why? * I want to do [Y] in order to accomplish [X]. How do I do [Y] with Guacamole? (Rather than assume Y is the correct approach, instead look into how to do X with Guacamole - see "the xy problem") Any thoughts/suggestions? - Mike On Sun, Jan 14, 2018 at 1:16 AM, Mike Jumper <[email protected]> wrote: > On Fri, Jan 12, 2018 at 6:25 AM, Amarjeet Singh <[email protected]> > wrote: > >> ... >> >> 1. After more debugging I have noticed that these functions take lot of >> time to process if buffer size if large ( copying or pasting large amount >> of data ). >> >> >> 1. >> *__encode_utf8 * >> 2. >> *__append_utf8 * >> 3. >> *array_writer.sendData(__encode_utf8(text)); * >> 4. *__decode_utf8* >> >> > Can you elaborate here? What leads you to the conclusion that encoding > things to UTF-8 is taking significant processing time? > > 2. There are many function in Guacamole Javascript which are independent >> of user interface elements, such as the DOM and common JS functions like >> getElementById where we can use Webworker to improve the performance of >> Guacamole. >> > > Again, can you elaborate? What specifically do you believe would be > improved through the use of WebWorkers? Have you tried making this change > yourself and observed significant improvement? > > 3. On Paste event we can get the data from the Local Clipboard and send it >> to the Remote Server so that Remote server also synced with the Local >> Server == And then send the Ctrl + V keys to paste the CLipboard data. >> > > The browser will only fire the "paste" event under very strict > circumstances. What you describe can work, but you will run into > difficulties with: > > * Differences among platforms between the keys pressed locally vs. > remotely for pasting clipboard data (not all platforms use Ctrl+V, and even > on platforms which typically use Ctrl+V, not all applications will do so) > * The need to allow some key events through to the browser so that > keyboard events blossom into actual clipboard events, yet still somehow > take control of those events to the extent that they can be sent to the > remote desktop unmodified if they do not actually deal with clipboard after > all. > > This was actually tried in the past, years ago, in much older releases of > Guacamole. The changes were ultimately removed because they proved too > unreliable and confusing for users. Users were confounded when Cmd+V on Mac > didn't work for paste connecting to Windows, or when pasting via Ctrl+V did > nothing when a remotely-running terminal emulator actually required > Ctrl+Shift+V for paste, or when attempting to paste through clicking with > the mouse did nothing. > > 4. On Copy event We are getting the data from the remote Clipboard and >> same we can send it the Local Clipboard using the Copy event to make both >> the local and remote clipboard synced. >> > > Similar to paste, this does not work well in practice. Besides the issues > with keyboard events described above, there are timing issues with > retrieval of clipboard data. There is no guarantee that the remote > clipboard data will be received locally within a reasonable time frame of > Ctrl+C being pressed. Because the clipboard can only be modified during the > "copy" event itself, something must block the main JavaScript thread while > clipboard data is being received. We did exactly this in older releases of > Guacamole, through using synchronous XMLHttpRequest to force the thread to > block while the server awaits clipboard data, but again ran into issues: > > * As with paste, the copy event will not occur during remote mouse > interaction. > * As with paste, platform and application differences in keyboard > shortcuts cannot be reliably handled or predicted. > * Synchronous XMLHttpRequest is deprecated and can no longer be relied > upon. > > 5. Main task is to sync the Local and remote Clipboard before copying and >> pasting data. >> >> *My Queries are as follows :- * >> >> >> 3. Can't we send plain data so that we don't have to decode or encode the >> data in Clipboard scenario as it can increase the performance ? >> >> >> > No. There is no such thing as "plain data". For communication between two > systems to make sense (between Guacamole client and server), there must be > an agreed upon encoding for data sent and received. Guacamole uses UTF-8 > for transmitted text, and the processing required to transform JavaScript's > own Unicode strings into UTF-8 is very minimal. > > 4. Can't we make a ajax request to get the plain data which is sent by >> remote server { on copy event }. We can save the data in guacamole server >> when we receive data from remote server and on copy event fire an ajax >> request ). >> > > No (see above-described issues with copy). Being able to modify local > clipboard data within the copy event would require blocking the main > thread, which cannot be done reliably. > > >> I had already done few change in the JavaScript code to make it work. It >> is *working in Chrome* only. Microsoft Edge hangs and IE ( issues while >> updating the local clipboard ). >> > > I do not recommend making these changes. It is not possible to do what you > describe reliably. > > If anyone has any suggestions, Please share in this thread. >> > > From my perspective, the best path forward is to use the clipboard APIs > which are on the track for standardization and have already been adopted by > the mainstream browsers: > > https://www.w3.org/TR/clipboard-apis/ > > Guacamole already does this. As implementation of these APIs improves, > behavior of the clipboard within Guacamole will also improve. Currently, > IE10 and IE11 will prompt the user to grant clipboard access when these > APIs are used. If other browsers follow suit, displaying permissions > prompts for clipboard access similar to the prompts already displayed for > audio/video input, etc., then there will be no need to attempt these > workarounds. > > Again, please beware that *we have tried all these clipboard-related > workarounds before*. Though they may seem inviting, they do not work well > in practice, and actually make the user experience more confusing. > > - Mike > >
