United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-5008122 : Korean: Java Web Start-add entry, buttons are stuck to the bottom of the page

Details
Type:
Bug
Submit Date:
2004-03-04
Status:
Resolved
Updated Date:
2004-05-10
Project Name:
JDK
Resolved Date:
2004-05-10
Component:
deploy
OS:
generic,windows_xp
Sub-Component:
webstart
CPU:
x86,other
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.4.2_02,1.4.2_03
Fixed Versions:
1.4.2_05 (05)

Related Reports
Duplicate:
Relates:
Relates:

Sub Tasks

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


                                     
2004-08-31
SUGGESTED FIX

http://javaweb.sfbay/~ngthomas/webrevs/5008122/webrev/
###@###.### 2004-03-22
                                     
2004-03-22
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
                                     
2004-03-18



Hardware and Software, Engineered to Work Together