<AWT Dev> [9] Review request : 8038919, Requesting focus to a modeless dialog doesn't work on Safari

[Anton V. Tarasov]

On 22.10.2014 17:08, Sergey Bylokhov wrote:
> Hi, Mikhail.
> As I said before, window.getPeer() can return null in some cases. After this fix some tests fail 
> with NPE:
> ex: closed/java/awt/Frame/DisposeStressTest
> Please fix.

Sergey, you're right. Disposing happens synchronously unlike focus handling. In the test a toplevel 
is shown and immediately disposed (and the peer is dropped), however all the focus events are 
handled later.

So, Mikhail, my advice was wrong, sorry.

Regards,
Anton.

>
> On 09.10.2014 19:46, mikhail cherkasov wrote:
>> Hi Anton,
>>
>> Please review a new version: http://cr.openjdk.java.net/~mcherkas/8038919/webrev.04/
>>
>> Thanks,
>> Mikhail.
>>
>> On 10/8/2014 10:41 AM, Anton V. Tarasov wrote:
>>> Hi Mikhail,
>>>
>>> (sorry, I was away yesterday)
>>>
>>> On 07.10.2014 19:37, mikhail cherkasov wrote:
>>>> Hi Anton,
>>>>
>>>> But anyway, I'll have to use "instanceof" to check the type returned for
>>>> DefaultKeyboardFocusManager.getCurrentKeyboardFocusManager().getActiveWindow().getPeer() .
>>>> or does it always return only LWWindowPeer?
>>>
>>> That's right, on Mac a toplevel's peer is of LWWindowPeer type.
>>>
>>> Also, I think you should check for the active window to be not null (it's possible when all the 
>>> toplevels are set non-focusable).
>>> However, you can omit a check for peer==null, as an active window may not have a null peer.
>>>
>>> Regards,
>>> Anton.
>>>
>>>>
>>>> Thanks,
>>>> Mikhail.
>>>>
>>>> On 10/6/2014 12:56 PM, Anton V. Tarasov wrote:
>>>>> Hi Mikhail,
>>>>>
>>>>> Ok, thank you for the clarification.
>>>>>
>>>>> Still, let's make another attempt to avoid the "instanceof". In LWWindowPeer we have a good 
>>>>> public method - getPeerType() - which should return PeerType.EMBEDDED_FRAME for EF. Can it be 
>>>>> used in the code spot?
>>>>>
>>>>> Regards,
>>>>> Anton.
>>>>>
>>>>> On 06.10.2014 11:08, mikhail cherkasov wrote:
>>>>>> Hi Anton,
>>>>>>
>>>>>> it's window problem, toFront doesn't work for windows when embedded frame in browser is active.
>>>>>> Mac ignores toFront, because it recognizes browser is active application and doesn't
>>>>>> allow to java process activate its window.
>>>>>> So the problem occurs only when we call toFront on Windows and embedded frame is active, hence
>>>>>> fix should be done in Window's toFront method.
>>>>>>
>>>>>> Thanks,
>>>>>> Mikhail.
>>>>>>
>>>>>>
>>>>>> On 10/3/2014 5:48 PM, Anton V. Tarasov wrote:
>>>>>>> Hi Mikhail,
>>>>>>>
>>>>>>> Can we get rid of that "instance of"? I think it makes sense to create a new 
>>>>>>> LWEmbeddedFramePeer class with toFront overriden. Then we can do all the verifications 
>>>>>>> gracefully and call platformWindow.toFrontIgnoringOtherApps() (new method). I would also 
>>>>>>> rename LWCToolkit.activateApplication to match its native API call.
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Anton.
>>>>>>>
>>>>>>> On 16.09.2014 15:39, mikhail cherkasov wrote:
>>>>>>>> Hello all,
>>>>>>>>
>>>>>>>> please review the fix
>>>>>>>> http://cr.openjdk.java.net/~mcherkas/8038919/webrev.01/
>>>>>>>>
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8038919
>>>>>>>>
>>>>>>>> The problem appears if we trying to call toFront when embedded window is active in browser, 
>>>>>>>> this
>>>>>>>> call is ignored, because for macosx the browser process is active and it ignores
>>>>>>>>  [nsWindow orderFront:nsWindow] call to java process windows.
>>>>>>>> To fix this issue I use  [NSApp activateIgnoringOtherApps:YES]; before  [nsWindow 
>>>>>>>> orderFront:nsWindow]
>>>>>>>> if an embedded frame is active window.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Mikhail.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>