<Swing Dev> [9] Review Request for 8130892: Test javax/swing/plaf/basic/BasicTextUI/8001470/bug8001470.java fails in Solaris Sparcv9

[Semyon Sadetsky]

Alexander,
you can run the next test on Windows which sets the right frame size and 
see that it fails because of the negative size.

import javax.swing.*;
import javax.swing.border.EmptyBorder;
import java.awt.*;

public class bug8001470 {

     private static JFrame frame;
     private static JTextField textField1;
     private static JTextField textField2;

     public static void main(String[] args) throws Exception {
         SwingUtilities.invokeAndWait(new Runnable() {
             @Override
             public void run() {
                 frame = new JFrame("JTextField Test");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

                 JPanel container = (JPanel) frame.getContentPane();
                 container.setLayout(new GridLayout(2,1));

                 textField1 = new JTextField("\u0e01");
                 textField2 = new JTextField("\u0c01");
                 JPanel panel = new JPanel();
                 BorderLayout mgr = new BorderLayout();
                 panel.setLayout(mgr);
                 container.add(panel);
                 panel.setBorder(new EmptyBorder(100, 100, 100, 100));
                 panel.add(textField1);
                 panel.add(textField2);
                 frame.setVisible(true);
                 frame.pack();
             }
         });
         if( textField1.getHeight() < 10 || textField2.getHeight() < 10 )
             throw new Exception("Wrong field height");
         System.out.println("ok");
         SwingUtilities.invokeLater(new Runnable() {
             @Override
             public void run() {
                 frame.dispose();
             }
         });
     }
}

--Semyon


On 7/27/2015 2:52 PM, Semyon Sadetsky wrote:
> -Alexander Yarmoliskiy
> +Alexander Zvegintsev
>
> On 7/27/2015 2:36 PM, Semyon Sadetsky wrote:
>> It is probably an issue, but even if fix it we cannot guarantee that 
>> insets will be always less then the resulting frame size. Method 
>> guessInsets() which obtains insets in frame's peer is hinting.
>> And again layout manager is able to apply negative size to container 
>> regardless the frame size.
>>
>> --Semyon
>>
>> On 7/27/2015 1:38 PM, Alexander Scherbatiy wrote:
>>>
>>>   I see that  sun.awt.X11.WindowDimensions class takes insets into 
>>> account and sets window size bigger than insets size. It looks like 
>>> difference between windows size and insets should be positive in 
>>> this case.
>>>
>>>  Thanks,
>>>  Alexandr.
>>>
>>> On 7/27/2015 9:56 AM, Semyon Sadetsky wrote:
>>>> Your expectation is not correct because if insets are set for a 
>>>> container then its child components can receive negative size even 
>>>> if the parent size is positive.
>>>>
>>>> --Semyon
>>>>
>>>> On 7/24/2015 7:09 PM, Sergey Bylokhov wrote:
>>>>> On 23.07.15 16:06, Semyon Sadetsky wrote:
>>>>>> Peer validation doesn't make any sense until layout manager may 
>>>>>> easily set negative size for any component using 
>>>>>> Component.setBounds(). That happens this issue particularly.
>>>>> In your first request you mention that the problem occurs when "On 
>>>>> Linux and Solaris platforms the initial frame window width and 
>>>>> height can be negative".
>>>>> My expectation is that: if the window size if >=0 then none of the 
>>>>> layout managers should set negative value for width/height, no?
>>>>>
>>>>>> So we need either to introduce the size constraint and fix the 
>>>>>> general issue either make UI to be prepared to get negative size 
>>>>>> occasionally i.e. fix the particular case (what is done in the 
>>>>>> solution).
>>>>>> Which option are you suggesting?
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>> On 7/23/2015 2:06 PM, Sergey Bylokhov wrote:
>>>>>>> On 23.07.15 9:22, Semyon Sadetsky wrote:
>>>>>>>> O.K. It sounds like a generic rule. Can I add this constant to 
>>>>>>>> the Component.reshape()?
>>>>>>> Historically our components have a lack of any data validation 
>>>>>>> because the user was able to call peers methods directly. I 
>>>>>>> assume that such validation should exists already in the peers 
>>>>>>> classes(like XBaseWindow.xSetBounds()).
>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>> On 7/22/2015 3:40 PM, Sergey Bylokhov wrote:
>>>>>>>>> It seems that the bug is in fact that the size of the window 
>>>>>>>>> is negative. In a lot of place we assume that it should be >=0.
>>>>>>>>>
>>>>>>>>> On 22.07.15 14:28, Semyon Sadetsky wrote:
>>>>>>>>>> In setVisible(true) if size is not specified and pack has not 
>>>>>>>>>> been called yet frame get some initial size depending on the 
>>>>>>>>>> platform.
>>>>>>>>>> That is the purpose of the test : to call pack() after 
>>>>>>>>>> setVisible().
>>>>>>>>>>
>>>>>>>>>> --Semyon
>>>>>>>>>>
>>>>>>>>>> On 7/22/2015 2:03 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>> On 7/17/2015 5:32 PM, Semyon Sadetsky wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> Please review fix for JDK9:
>>>>>>>>>>>>
>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8130892
>>>>>>>>>>>> webrev: 
>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8130892/webrev.00/
>>>>>>>>>>>>
>>>>>>>>>>>> On Linux and Solaris platforms the initial frame window 
>>>>>>>>>>>> width and height can be negative. So the root view is 
>>>>>>>>>>>> initialization trigger was updated to take negative values 
>>>>>>>>>>>> into account. The fix was tested on Ubuntu 12, OEL7 and 
>>>>>>>>>>>> Solaris 11.
>>>>>>>>>>>    It looks strange that the test which does not set 
>>>>>>>>>>> explicit bounds and calls frame.pack() encounters into 
>>>>>>>>>>> negative sizes.
>>>>>>>>>>>    In which place does the frame window obtain negative 
>>>>>>>>>>> width and height?
>>>>>>>>>>>
>>>>>>>>>>>    Thanks,
>>>>>>>>>>>    Alexandr.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --Semyon
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150727/baf45b2c/attachment.html>