JDK-6524986 : XEmbed server doesn't get focused if embedded into applet
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: linux,solaris
  • CPU: generic,x86
  • Submitted: 2007-02-14
  • Updated: 2011-03-08
  • Resolved: 2011-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u2Fixed 7 b09Fixed
Description
Consider the following hierarchy: there is an applet A plugged into Mozilla/Firefox browser. Inside the applet there is an AWT component C that implements XEmbed server specification (e. g. XEmbedCanvasPeer). Inside the component there is an XEmbed client S (e. g. StarOffice bean or XEmbeddedFrame).

Then, consider the current focused component is some HTML element, while A is not focused. If I click on some component inside A with mouse, it successfully gets focused, while if I click on S it doesn't. At the same time I can tab in and out of S from/to C.
The same problem may be reproduced in easier configuration: an applet with a single button. Set focus is on some HTML element other than applet, then click on some other window like terminal, and then click on a button inside the applet - the button doesn't get focused. Only the second mouse click makes it a focus owner.

Comments
EVALUATION There is a dependency between this, 6537010, 6453597, 6521732. A fix for this is required before seeing 6537010.
29-03-2007

SUGGESTED FIX The full version of the fix can be found at the following location: http://sa.sfbay.sun.com/projects/awt_data/7/6524986
14-02-2007

SUGGESTED FIX --- XEmbedCanvasPeer.java 2007-02-14 17:59:59.000000000 +0300 *************** *** 335,341 **** xembedLog.fine("Requesting focus for client"); postEvent(new InvocationEvent(target, new Runnable() { public void run() { ! target.requestFocusInWindow(); } })); } else { --- 335,341 ---- xembedLog.fine("Requesting focus for client"); postEvent(new InvocationEvent(target, new Runnable() { public void run() { ! target.requestFocus(); } })); } else { --- XEmbeddedFramePeer.java 2007-02-14 18:05:42.000000000 +0300 *************** *** 76,89 **** public boolean requestWindowFocus() { // Should check for active state of host application if (embedder != null && embedder.isActive()) { ! if (embedder.isApplicationActive()) { ! xembedLog.fine("Requesting focus from embedding host"); ! embedder.requestFocus(); ! return true; ! } else { ! xembedLog.fine("Host application is not active"); ! return false; ! } } else { xembedLog.fine("Requesting focus from X"); return super.requestWindowFocus(); --- 76,84 ---- public boolean requestWindowFocus() { // Should check for active state of host application if (embedder != null && embedder.isActive()) { ! xembedLog.fine("Requesting focus from embedding host"); ! embedder.requestFocus(); ! return true; } else { xembedLog.fine("Requesting focus from X"); return super.requestWindowFocus();
14-02-2007

EVALUATION After debugging AWT XEmbed code I found the following. When I click S with mouse, it generates XEMBED_REQUEST_FOCUS message and sends it to C. According to the specification, C should request focus and then reply with XEMBED_FOCUS_IN, but this doesn't happen. Thus, the problem is that C can't request focus from embedding applet. I was able to find out why. When C receives XEMBED_REQUEST_FOCUS it checks if its top-level is an active window and calls requestFocusInWindow. The problem is that the top-level (applet's XEmbeddedFrame) has no focus and is not an active window, so requestFocusInWindow is not called. And even if I remove the check for active window, this would not be enough: requestFocusInWindow must be replaced with requestFocus. This is what the fix for this bug is.
14-02-2007