Looks good to me.

On 8/30/16 7:18 PM, Semyon Sadetsky wrote:
Sorry for inconvenience, but I have to update this fix once again.


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.


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.


On 8/22/2016 9:19 PM, Semyon Sadetsky wrote:

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.



Reply via email to