Re: [10] Review Request 8190230: [macosx] Order of overlapping of modal dialogs is wrong

[Dmitry Markov]

Hi Semyon,

The fix looks good to me.
I have only a minor remark regarding the test. It might be reasonable to use 
Util.testPixelColor() from regtesthelpers package instead of 
Robot.getPixelColor(). However it is up to you and you may keep it as is.

Thanks,
Dmitry 
> On 31 Oct 2017, at 15:05, Semyon Sadetsky  wrote:
> 
> Thank you, Alexander. I have corrected the webrev.
> 
> --Semyon
> 
> On 10/31/2017 02:25 AM, Alexander Zvegintsev wrote:
>> Hi Semyon,
>> 
>> the fix looks good to me,  but the test link is broken in this webrev.
>> Thanks,
>> Alexander.
>> On 30/10/2017 20:37, Semyon Sadetsky wrote:
>>> 
>>> Hello, 
>>> 
>>> Please review fix for JDK10: 
>>> 
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8190230 
>>>  
>>> 
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8190230/webrev.00/ 
>>>  
>>> 
>>> After the 8169589 fix siblings of the same parent are overlapped in the 
>>> order they appear in  the array of child windows. But this order do not 
>>> preserve the previous overlapping order in which the sibling windows have 
>>> been shown before the order update. That is the cause of unexpected 
>>> reorder. 
>>> 
>>> In the fix each platform window is attributed with a timestamp of the 
>>> moment when it was show in front last time. Then this timestamp is used to 
>>> sort the sibling windows array before putting them into an order to each 
>>> other. 
>>> 
>>> --Semyon 
>>> 
>> 
> 

Re: [10] Review Request 8190230: [macosx] Order of overlapping of modal dialogs is wrong

[Semyon Sadetsky]

Thank you, Alexander. I have corrected the webrev.

--Semyon


On 10/31/2017 02:25 AM, Alexander Zvegintsev wrote:


Hi Semyon,

the fix looks good to me,  but the test link is broken in this webrev.

Thanks,
Alexander.
On 30/10/2017 20:37, Semyon Sadetsky wrote:


Hello,

Please review fix for JDK10:

bug: https://bugs.openjdk.java.net/browse/JDK-8190230

webrev: http://cr.openjdk.java.net/~ssadetsky/8190230/webrev.00/

After the 8169589 fix siblings of the same parent are overlapped in 
the order they appear in  the array of child windows. But this order 
do not preserve the previous overlapping order in which the sibling 
windows have been shown before the order update. That is the cause of 
unexpected reorder.


In the fix each platform window is attributed with a timestamp of the 
moment when it was show in front last time. Then this timestamp is 
used to sort the sibling windows array before putting them into an 
order to each other.


--Semyon

Re: [10] Review Request 8190230: [macosx] Order of overlapping of modal dialogs is wrong

[Alexander Zvegintsev]

Hi Semyon,

the fix looks good to me,  but the test link is broken in this webrev.

Thanks,
Alexander.

On 30/10/2017 20:37, Semyon Sadetsky wrote:


Hello,

Please review fix for JDK10:

bug: https://bugs.openjdk.java.net/browse/JDK-8190230

webrev: http://cr.openjdk.java.net/~ssadetsky/8190230/webrev.00/

After the 8169589 fix siblings of the same parent are overlapped in 
the order they appear in  the array of child windows. But this order 
do not preserve the previous overlapping order in which the sibling 
windows have been shown before the order update. That is the cause of 
unexpected reorder.


In the fix each platform window is attributed with a timestamp of the 
moment when it was show in front last time. Then this timestamp is 
used to sort the sibling windows array before putting them into an 
order to each other.


--Semyon

[10] Review Request 8190230: [macosx] Order of overlapping of modal dialogs is wrong

[Semyon Sadetsky]

Hello,

Please review fix for JDK10:

bug: https://bugs.openjdk.java.net/browse/JDK-8190230

webrev: http://cr.openjdk.java.net/~ssadetsky/8190230/webrev.00/

After the 8169589 fix siblings of the same parent are overlapped in the 
order they appear in  the array of child windows. But this order do not 
preserve the previous overlapping order in which the sibling windows 
have been shown before the order update. That is the cause of unexpected 
reorder.


In the fix each platform window is attributed with a timestamp of the 
moment when it was show in front last time. Then this timestamp is used 
to sort the sibling windows array before putting them into an order to 
each other.


--Semyon