<AWT Dev> <Swing Dev> Request for review: 7155298 : Editable TextArea blocks GUI application from exit

[Anton V. Tarasov]

On 3/22/12 6:15 PM, Oleg Sukhodolsky wrote:
> On Thu, Mar 22, 2012 at 5:55 PM, Anton V. Tarasov
> <anton.tarasov at oracle.com>  wrote:
>> On 22.03.2012 14:37, Oleg Sukhodolsky wrote:
>>> On Thu, Mar 22, 2012 at 2:19 PM, Anton V. Tarasov
>>> <anton.tarasov at oracle.com>    wrote:
>>>> On 22.03.2012 12:47, Oleg Sukhodolsky wrote:
>>>>> On Thu, Mar 22, 2012 at 12:01 PM, Sean Chou<zhouyx at linux.vnet.ibm.com>
>>>>>   wrote:
>>>>>> Hi Oleg,
>>>>>>
>>>>>>      Seem there are misunderstanding .
>>>>>>      DefaultCaret can receive FocusLostEvent when another control get
>>>>>> focused. But it
>>>>>> doesn't receive FocusLostEvent when disposing.
>>>>>>
>>>>>>      The reason is XTextAreaPeer doesn't receive FocusLostEvent when
>>>>>> disposing. But
>>>>>> I don't know if it is a rule that a FocusLostEvent must be sent to the
>>>>>> focused>>>    component when the top-level window is disposed ?
>>>>> Well, for regular AWT component it is expected.  And I'd expect that
>>>>> this should also be true for peer.
>>>>
>>>> That's right, focus_lost should be dispatched to a disposed focus owner.
>>> So, now we need to figure out why the caret doesn't get the event.
>>>
>>> Oleg.
>>
>> I ran the testcase provided in the webrev and debugged a little. FOCUS_LOST
>> does come to the textarea on its disposal, though when the focus event is
>> being dispatched I see the peer is null.
>> This is quite expected actually. When Component.removeNotify() is called on
>> EDT, it transfers focus further (appropriate focus events get queued) and
>> then nullifies the peer. The events come later.
>> Hope this helps.
> Thank you (I do not have Linux, so I can not debug this).
> So, now we know that the cause of the problem is that our internal
> AWTText(Field|Area) may be disposed while they think
> that they are focused, and, at the same time, we can not propogate
> real focus lost to them since peer is desposed
> before we receive the event.
> So, the suggested fix works fine for one particular problem (unstopped
> timer), but we may get some other
> problems due to the cause.
> For me it looks like better fix would be to pass synthetic focus lost
> when we dispose text peer, this way we guarantee
> that life-circle of our synthetic components will be similar to real
> ones and we will meet Swing's expectations.
>
> Does this sounds reasonable?
>
> Regards, Oleg.

This sounds reasonable, though I personally don't like the idea of yet 
another synthetic focus event...

I actually like the fix Sean suggested (after we see the whole picture). 
Otherwise, we may follow your suggestion
to create AWTTextArea.removeNotify(). And even simpler, why not to put 
getCaret().setVisible(false) right into JTextComponent.removeNotify()?

Either of these looks fine to me.

Thanks,
Anton.