Installing Safari 5.1 on OSX breaks webRDP keyboard / drag and drop in File Services / Java Applets
As of 9-26-2012, Oracle has taken over the development of Java for Apple. They have released Java 1.7 Update 7 and this fixes the Keyboard issue along with the Drag and Drog issues in File Services. However be aware that installing this means that Chrome won't work with Java. This is because Java is 64 bit and Chrome is 32 bit and thus they can't talk to each other. This is a problem that Oracle and Google will have to work out.
webRDP / File Services and Safari 5.1 / OSX Updates
Update 8-29-2011: Apple has released a 1.6.0_27 beta version of java with a new version of Plugin2. This is ONLY available to apple developers. This fix partially fixes the keyboard issue but ONLY if you have it display the java console. Apple has acknowledged that drag and drop is still broken and they are working on a fix for that.
Overview of original problem:
Apple released Safari 5.1 alongside Mac OS X 10.7 (Lion) at the end of July. One of the features Safari 5.1 enables is the sandboxing of the Java Runtime Environment (JRE). This feature is not limited to Safari itself but is enabled for all web browsers that use OS X’s JRE. The sandboxing of Java applets is preventing keyboard input from being received by applets.
Details
Basically, this means that when a Java applet is started inside a web browser, it is spawned into its own process, preventing the applet from hijacking control of the browser (or the rest of the operating system). The view that is seen in Safari (or Firefox, or Chrome) is not actually the applet view, but rather a mirror, a reflection of the view being rendered by the Java process. On Windows and Linux, the system lets the parent process (Firefox, Internet Explorer, Safari, etc) assume parenthood of windows belonging to other processes. On OS X, that is impossible due to the security architecture in place. It is a limitation achieved through trading freedom for security.
webRDP’s issue
What this means to webRDP is that when you start a webRDP session through webNetwork (or any other avenue that utilizes the applet side), webRDP is spawned in a separate process, with its own window (that is hidden from view) and a mirror of that view is created in the web browser. Delivery of some events (mouse input and limited keyboard input) may be possible with this mirror view, but this is currently unreliable. Given that the view is no longer a child of the web browser, and is in its own process when you type in the web browser, the browser receives the keystrokes, not the applet.
Workaround #1
This is the most reliable workaround, and one supported by Apple’s engineers on the Java team. Once the applet has launched inside the browser, you can hold down Command and Shift, move the mouse over the applet, and you will see a title bar appear along the top of the applet itself. You can click on the title bar, drag the window a short distance, and release, and it will create a new window with the applet inside. This should restore full keyboard functionality as you are interacting with a view directly attached to the Java process, instead of a mirrored view in the browser window.
Workaround #2
We have had hit-or-miss success with this solution, and it lowers the security of your system with respect to Java applications, so we would only recommend it for advanced users, after careful consideration.
Inside of the Java Preferences application (/Applications/Utilities/Java Preferences.app), under the Advanced Tab, there is a setting near the bottom for "Verify mixed security code". If you set that to "Disable - insecure, not recommended" it appears to turn off the sandboxing enough to restore most of the prior functionality, but we have had limited success, and due to the security risks involved, we recommend sticking with Workaround #1 if at all possible.
File Services Issue
Drag and drop is also affected by this Apple OSX update. The same steps used in Workaround #1 for webRDP works for File Services. For File services the Drag and Drop window in the upper right can be dragged out to temporarily restore functionality.
Update, the following information has been posted by Apple Engineers:
http://lists.apple.com/archives/java-dev/2011/Jul/msg00083.html
Unfortunately, this is a known issue with Plugin2, which has become the default applet plug-in for all browsers on Snow Leopard and Lion as of yesterday. We have not found NPAPI to have sufficient facilities for us to replicate Java’s external drag-and-drop services, and are looking for other technical avenues to pursue.
As a workaround, you can detach the applet from the web page by holding down Cmd-Shift and dragging. The detached applet should respond correctly any DnD operations.
Sorry,
Mike Swingler
Java Engineering
Apple Inc.
Here is a bug ticket that is in for the FireFox team where they have also discovered this problem.https://bugzilla.mozilla.org/show_bug.cgi?id=588455