<AWT Dev> [8] Review Request: JDK-8027025 [macosx] getLocationOnScreen returns 0 if parent invisible

[Anthony Petrov]

Hi Petr,

The workaround you suggest seems to be more or less safe, so let's go 
with it.

Please file a separate issue to investigate the setBounds/zoom code on 
Mac later.

--
best regards,
Anthony

On 10/23/2013 01:05 PM, Petr Pchelko wrote:
> Hello, Anthony.
>
>> What happens if you display a decorated frame centered on the screen? Will it receive the initial Move/Size event? And if yes, why exactly this isn't happening for undecorated frames?
> Yes. The decorated frame is receiving the initial move/resize event. I suppose it's somehow moved(resized) be adding the window decorations, but this is only a guess.
>
> With best regards. Petr.
>
> On 23.10.2013, at 12:56, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>
>> Hi Petr,
>>
>> What happens if you display a decorated frame centered on the screen? Will it receive the initial Move/Size event? And if yes, why exactly this isn't happening for undecorated frames?
>>
>> Also, at [1] Alexander said:
>>>    The problem was that NSWindow is created with zero bounds and then
>>> actual bounds are set.
>>>    In this case NSWindow treats big bounds as zoomed state and next zoom
>>> move the window to initial zero bounds.
>>
>> I'm wondering, won't the same scenario fail for undecorated windows after your fix, just reverting them back to 0x0/1x1 instead of 0x0/0x0?
>>
>> [1] http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005469.html
>>
>> --
>> best regards,
>> Anthony
>>
>> On 10/23/2013 12:43 PM, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8027025
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/8027025/webrev.00/
>>>
>>> The problem:
>>> When initializing the peer's location and bounds we rely on the initial move/resize event. However if the undecorated frame is created right at the center of the screen this initial event does not come.
>>> My testing shows that this is an only situation.
>>>
>>> The solution:
>>> We revert the changes in JDK-8007219 for undecorated frames. The initial position is a 0-0-1-1 stub, the real position is set later during the initialization.
>>> I don't want to do that for decorated frames as 1. this is not needed 2. the native maximize button starts working ugly in some cases.
>>>
>>> With best regards. Petr.
>>>
>