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

[mikhail cherkasov]

Ok, will send review soon.

Does a bug already  exist in JBS?

Thanks,
Mikhail.

On 10/22/2014 5:08 PM, 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.
>
> 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.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>