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

[Artem Ananiev]

Adding swing-dev back to CC since a question about JComponent has appeared.

Artem

On 3/22/2012 10:04 PM, Oleg Sukhodolsky wrote:
> On Thu, Mar 22, 2012 at 10:50 PM, Anton V. Tarasov
> <anton.tarasov at oracle.com>  wrote:
>> 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...
>
> well, (synthetic) focus events are your area of expertise ;)
>
>> 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()?
>
> well, the later is a question for Swing team.
> The former is reasonable fix (not the best one, but good enough).
> So, if everyone agree with this approach then I'm fine (hope this is
> the only problem we
> will have with invisible focused JTextXXX)
>
> Oleg.
>
>>
>> Either of these looks fine to me.
>>
>> Thanks,
>> Anton.
>>
>>