JDK-4972534 : [Tiger]Can't input anything into textfields on solaris10 by JRE1.5-B32
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2003-12-24
  • Updated: 2004-10-21
  • Resolved: 2004-02-05
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.
Other
5.0u1 b04Fixed
Related Reports
Relates :  
JDK-4978234 - keyboard issue using suntea with Java 1.5 plugin and mozilla 1.6b
Description
Steps to reproduce:
1.On solaris10(build46),Mozilla1.4-12,JRE1.5_b32, on solaris10 CDE english locale.
2.Open mozilla and launch applet's demo, such as Dither Test, Arc Test,SpreadSheet. 
3.Can't input anythings, and can't move mouse's cursor and can't delete character.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b37 tiger-beta2 VERIFIED IN: tiger-beta2
24-08-2004
EVALUATION Name: dmR10075 Date: 12/29/2003 The bug is not reproducible on Linux with b32 and mozilla 1.4/1.5a ====================================================================== We ought to determine where the cause of this bug lies (e.g. Mozilla or Java) and try to find a fix in the Tiger/Solaris10 timeframe. ###@###.### 2004-01-09 Name: dmR10075 Date: 01/13/2004 We don't have Solaris 10 and we don't have Mozilla 1.4b12 to reproduce the bug. Trying to acquire both. If submitter could try to reproduce the bug in a more generally available platform that would help us evaluate the bug sooner. ###@###.### 2004-1-13 ====================================================================== This bug can be reproduce on: Solaris8, JRE1.5_b32,Sun Mozilla1.4-15b Solaris9,JRE1.5_b32, Sun Mozilla1.4-12. Solaris10(49),JRE1.5_b32, Sun Mozilla1.4-15. The workaround is Open the java console, and click on it,move cursor back to the applet's text field, then it can be inputed. ###@###.### 2004-01-13 Name: dmR10075 Date: 01/13/2004 The problem is not reproducible with XAWT on S10/Mozilla1.4b12 The problem is reproducible with Motif on S10/Mozilla1.4b12. It seems that the focus remains on Browser while Java thinks it owns focus. It could be because of a race between XEmbed initialization sequence and Frame initialization. During initialization, MEmbeddedFramePeer is created and its setVisible method is called. At that moment XEmbed is not yet active(it in process though) and safety check in setVisible fails - we proceed in 1.4 compatibility mode and request focus to embeddedframe as if there were no XEmbed. In result, when time for normal request comes, we see that we already have focus and skip requesting it from XEmbed and X focus remains on browser. ###@###.### 2004-1-13 ====================================================================== Name: dmR10075 Date: 01/14/2004 Generally, problem happens if we generate synthetic events during XEmbed. In result, we don't have focus and don't request it, and browser has focus. To fix that, we should check for XEmbed before synthesizing focus events. Another place where we do it is sun.applet.AppletPanel.setDefaultFocus ###@###.### 2004-1-14 ====================================================================== This bug had been fixed on JRE1.5.0_beat2-b37 on Solaris10-b51. ###@###.### 2004-02-05
14-01-2004
SUGGESTED FIX Name: dmR10075 Date: 01/14/2004 Check for XEmbed before synthesizing focus events. If it is active - use XEmbed requests instead. ------- MEmbeddedFrame.java ------- *** /tmp/sccs.oOYtSL 2004-01-14 13:42:17.000000000 +0300 --- MEmbeddedFrame.java 2004-01-14 13:35:27.000000000 +0300 *************** *** 52,58 **** public void synthesizeWindowActivation(boolean b) { MEmbeddedFramePeer peer = (MEmbeddedFramePeer)getPeer(); if (peer != null) { ! peer.synthesizeFocusInOut(b); } } --- 52,66 ---- public void synthesizeWindowActivation(boolean b) { MEmbeddedFramePeer peer = (MEmbeddedFramePeer)getPeer(); if (peer != null) { ! if (peer.isXEmbedActive()) { ! // If XEmbed is active no synthetic focus events are allowed - everything ! // should go through XEmbed ! if (b) { ! peer.requestXEmbedFocus(); ! } ! } else { ! peer.synthesizeFocusInOut(b); ! } } } ------- MEmbeddedFramePeer.java ------- *** /tmp/sccs.luDrg0 2004-01-14 13:42:17.000000000 +0300 --- MEmbeddedFramePeer.java 2004-01-14 13:43:39.000000000 +0300 *************** *** 9,21 **** import sun.awt.EmbeddedFrame; import java.util.logging.*; public class MEmbeddedFramePeer extends MFramePeer { private static final Logger xembedLog = Logger.getLogger("sun.awt.motif.xembed.MEmbeddedFramePeer"); public MEmbeddedFramePeer(EmbeddedFrame target) { super(target); ! xembedLog.fine("Creating XEmbed-enabled motif embedded frame"); } void create(MComponentPeer parent) { --- 9,22 ---- import sun.awt.EmbeddedFrame; import java.util.logging.*; + import java.awt.Window; public class MEmbeddedFramePeer extends MFramePeer { private static final Logger xembedLog = Logger.getLogger("sun.awt.motif.xembed.MEmbeddedFramePeer"); public MEmbeddedFramePeer(EmbeddedFrame target) { super(target); ! xembedLog.fine("Creating XEmbed-enabled motif embedded frame, frame supports XEmbed:" + supportsXEmbed()); } void create(MComponentPeer parent) { *************** *** 35,41 **** public void setVisible(boolean vis) { super.setVisible(vis); ! if (vis && !isXEmbedActive() && !supportsXEmbed()) { // Fix for 4878303 - generate WINDOW_GAINED_FOCUS and update if we were focused // since noone will do it for us(WM does it for regular top-levels) synthesizeFocusInOut(true); --- 36,44 ---- public void setVisible(boolean vis) { super.setVisible(vis); ! xembedLog.fine("Peer made visible"); ! if (vis && !supportsXEmbed()) { ! xembedLog.fine("Synthesizing FocusIn"); // Fix for 4878303 - generate WINDOW_GAINED_FOCUS and update if we were focused // since noone will do it for us(WM does it for regular top-levels) synthesizeFocusInOut(true); *************** *** 64,67 **** --- 67,78 ---- return super.requestWindowFocus(); } } + public void handleWindowFocusIn() { + super.handleWindowFocusIn(); + xembedLog.fine("windowFocusIn"); + } + public void handleWindowFocusOut(Window oppositeWindow) { + super.handleWindowFocusOut(oppositeWindow); + xembedLog.fine("windowFocusOut, opposite is null?:" + (oppositeWindow==null)); + } } ###@###.### 2004-1-14 ======================================================================
14-01-2004