On 08-Nov-19 9:18 AM, Prasanta Sadhukhan wrote:
On 08-Nov-19 9:07 AM, Sergey Bylokhov wrote:
On 11/7/19 7:32 pm, Prasanta Sadhukhan wrote:
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?
I guess it is gnome3, BTW I am able to reproduce it as well on Ubuntu
19.10, after a number of iterations(~50) and can confirm that when it
fails the size of the window is changed(it became smaller than
initially).
OK. I will also try with more iterations on 18.04. But, one thing is
test is calling removeNotify,addNotify which are not supposed to be
called directly from programs. Shouldn't we use allowable APIs maybe
setVisible(false), setVisible(true)?
BTW, I tried with 100 iterations on local ubuntu18.04 and it passed and
I think mach5 system is also 18.04, so not sure why it will fail there.
Regards
Prasanta
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
