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

[Sergey Bylokhov]

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.
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


-- 
Best regards, Sergey.