JDK-5008122 : Korean: Java Web Start-add entry, buttons are stuck to the bottom of the page
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 1.4.2_02,1.4.2_03
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_xp
  • CPU: other,x86
  • Submitted: 2004-03-04
  • Updated: 2004-05-10
  • Resolved: 2004-05-10
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
1.4.2_05 05Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
 Filed on behalf of Sony.

These issues occur in the Korean/Simplified Chinese/Traditional>Chinese versions. They don't occur in Japanese and English.
JRE 1.4.2_03.

Go from Start menu ->Programs->Java Web Start->Java Web Start.
Click Add Entry.
In the window displayed, the buttons are stuck to the bottom edge
(kind of hard to explain -- please see buttons.JPG)
Was expecting some space or setback beneath the buttons.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_05 generic FIXED IN: 1.4.2_05 INTEGRATED IN: 1.4.2_05
31-08-2004

SUGGESTED FIX http://javaweb.sfbay/~ngthomas/webrevs/5008122/webrev/ ###@###.### 2004-03-22
22-03-2004

EVALUATION this is not a javawebstart bug, run my attached simple java testcase (test.java - and also put defaultImage.gif in the same directory) and you will see the same problem. ###@###.### 2004-03-17 Also I don't think this bug is really locale specific - I see the problem on my english solaris machine also. And if you run the attached testcase on winXP, the third dialog that pops up will have this problem too. Basically as long as there is line wrap, the problem will show up. If we don't call setLineWrap(true) in the testcase, problem will go away. This is either a Swing or Awt problem, reassign to Swing for further evaluation. ###@###.### 2004-03-17 One more note on the testcase: The call to SwingUtilities.invokeLater doesn't really matter; I was just testing it out. With or without it the bug is still there. ###@###.### 2004-03-17 Name: sh120115 Date: 03/18/2004 ###@###.###, this is the same bug as The test case, as filed, looks okay under 1.5. However, if you change line 25: JOptionPane jop2 = new JOptionPane(messageFormat("Java Web Start this is a test this is a test this is a test this is a test"), JOptionPane.PLAIN_MESSAGE, JOptionPane.YES_NO_OPTION, new ImageIcon(Thread.currentThread().getContextClassLoader().getResource("defaultImage.gif"))); and make the message really long, the layout of the JOptionPane is horrible. Thanks! ###@###.### 2004-03-18 ====================================================================== This bug [5008122] and what bug 4924163 has become under 1.5 are two sides of the same problem. Either 'buttons are stuck to the bottom' or 'the layout of the JOptionPane is horrible'. There is no win-win case here. See evaluation for 4924163. To get nice layout under 1.5 we have to do pack() twice. Most of the java applications would not do that. Thus most of java applications using wrapping for text components would have ugly layout. 4446522 [JTextArea.getPreferredSize() incorrect when line wrapping is used] is the bug which was fixed in tiger to address the wrapping problem. The fix for this bug created a number of regressions. If we are to backport the fix to 1.4 here is the list of regressions - [4924163, 4990877, 4986141 ] I do not think it is reasonable to backport the fix though. Doing two pack() would fix the described problem. -- Test.java --- import java.awt.*; import javax.swing.*; public class Test { public static void main(String[] args) { JFrame frame = new JFrame("test"); frame.getContentPane().setLayout(new BorderLayout()); String testString = "test test test test test test test " + "test test test test test "; JTextArea textArea = new JTextArea(testString); textArea.setLineWrap(true); textArea.setWrapStyleWord(true); textArea.setEditable(false); frame.getContentPane().add(textArea,BorderLayout.NORTH); JPanel panel = new JPanel(); panel.add(new JButton("ok")); panel.add(new JButton("cancel")); frame.getContentPane().add(panel, BorderLayout.SOUTH); frame.pack(); frame.pack(); frame.show(); } } ---- Try it on 1.4 with two pack() and without them. To use this workaround for the bug's test-case one has to modify JOptionPane. Reassigning bug back to ###@###.### ###@###.### 2004-03-18 I agree that we don't want to backport the fix to 1.4.2 since it would introduce new regressions. Also, we don't want to change JOptionPane to do two packs as it doesn't make sense. Perhaps the issue then is that the submitter shouldn't be using a JTextArea in the manner that they are. In reality, we don't advocate using text components to display static text to the user. The submitter appears to be using it simply to provide line wrapping, and a much better approach to doing this is to make the message text HTML. For example: message = "<html>This is the first line<br>This is the second line<br>This is the third line"; This text could be passed as the message when using JOptionPane, or put directly into a JLabel when laying out a dialog directly. Doing it this way allows them to explicitly specify how the message is layed out, without relying on JTextArea to perform some magic calculation. ###@###.###, is this suggestion sufficient to satisfy your customer? If so, I'd like to close this out. Thanks! ###@###.### 2004-03-18 As per e-mail from ###@###.### and telephone conversation with ###@###.###, re-assigning to Java Web Start. ###@###.### 2004-03-18
18-03-2004