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

[Semyon Sadetsky]

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