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

[Semyon Sadetsky]

-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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>