<AWT Dev> [14] RFR JDK-8233703:java/awt/Frame/FrameLocation.java fails on mac

[Prasanta Sadhukhan]

Hi Sergey,

OK. Since the test pass in local ubuntu18.04 system and fail only in 
mach5 linux system, I thought it's a test issue. Do you know what window 
manager our mach5 linux system is running?

Regards
Prasanta
On 08-Nov-19 2:42 AM, Sergey Bylokhov wrote:
> Hi, Prasanta.
>
> I think that the test passed after the fix is because it does not have 
> enough time to update
> the location of the Frame by the native callback.
>
> Before the fix we have this sequence of calls:
>  1 Sets the bounds of the frame(this bounds are cached in the frame 
> and returned by getX/getY)
>  2 Make the frame visible
>  3 Wait while the callback from the native change the location of the 
> frame cached at step 1
>  4 Check the coordinates
>  5 Destroy/Recreate the peer
>  6 goto step  3
>
> After the fix:
>  1 Sets the bounds of the frame(this bounds are cached in the frame 
> and returned by getX/getY)
>  2 Make the frame visible
>  3 Check the coordinates cached at step 1
>  4 Destroy/Recreate the peer
>  5 goto step  3
>
> So actually the new test did not check location of the frame but check 
> the values cached in the Frame object.
>
>
> On 11/6/19 3:57 am, Prasanta Sadhukhan wrote:
>> Hi All,
>>
>> Please review a fix for an issue where it is seen the frame location 
>> is sometimes wrong in mac on mach5 headful nightly run.
>>
>> It seems to be a timing issue as it shows 10 frames by calling 
>> frame.removeNotify(),frame.addNotify() repeatedly, which by the way 
>> are not supposed to be called by programs directly.
>>
>> Proposed fix is to make not to make thread sleep every time 
>> removeNotify,addNotify is called so that there is no delay. I have 
>> ran mach5 job (in JBS) for 3 consecutive runs on all 3 platforms and 
>> they pass.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8233703
>>
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8233703/webrev.0/
>>
>> Regards
>> Prasanta
>
>