Sorry for inconvenience, but I have to update this fix once again.
http://cr.openjdk.java.net/~ssadetsky/8161910/webrev.02
I have found the main root cause of the issue. In the 8036815 I have
missed one insets_corrected = true; statement in the RaparentNotify
handler. In my new Unity algo for establishing frame dimensions the
insets correction should be postponed until the frame extent property is
set. This is corrected in the updated fix.
Also the frame insets correction optimization is restored with only one
exclusion when the client area is not set to ensure that the target
frame will receive the final size and location update.
--Semyon
On 8/24/2016 4:24 PM, Semyon Sadetsky wrote:
The fix was amended to
http://cr.openjdk.java.net/~ssadetsky/8161910/webrev.01/
Because Unity WM may change initial window location (for example when
window overlaps desktop bars) I removed the optimization that skipped
frame bounds revalidation in case of the initial frame insets was
correct. This should guaranty the ConfigureNotify event always to come
after the extent size event.
--Semyon
On 8/22/2016 9:19 PM, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8161910
webrev: http://cr.openjdk.java.net/~ssadetsky/8161910/webrev.00/
A regression of the 8036915 in which a new frame dimensioning algo
was introduced for the Unity WM because the latter differs from other
WMs a lot. The algo has a flaw in some scenarios when the extent
size event is delayed while the initial frame insets were established
correctly, therefore the frame dimensions do not require any tuning.
In this case the content window need to be notified right in the
extent event handler to let the content to receive its new dimensions
because subsequent XConfigureNotify event may be omitted.
--Semyon
