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

[Sean Chou]

Oh, I'm really sorry about that !

I removed the comment, a new webrev is at :
http://cr.openjdk.java.net/~zhouyx/7155298/webrev.03/

Please take a look again. Thanks !

On Sat, Mar 24, 2012 at 1:50 AM, Anton V. Tarasov
<anton.tarasov at oracle.com>wrote:

> **
> Hi Sean,
>
> XTextAreaPeer.java:
>
> +        // visible caret has a timer thread which must be stopped+//        jtext.getCaret().setVisible(false);
> ^^^
>
> Seems that you forgot the comments in the webrev.
>
> The new test looks fine to me.
>
> Thanks,
> Anton.
>
>
> On 23.03.2012 10:49, Sean Chou wrote:
>
>
>  I modified the testcase according to Anthony Petrov's suggestion(
> http://mail.openjdk.java.net/pipermail/awt-dev/2012-March/002389.html) .
> The new webrev: http://cr.openjdk.java.net/~zhouyx/7155298/webrev.02/
>
>  However, the timeout action in jtreg only checks the main method, but
> the timeout is caused by timer thread .
>  So, I started an other process to run the testcase and the main testcase
> waitFor that process to stop. In order to kill the process started by the
> testcase, I added a ShutdownHook to the runtime of main testcase. And added
> /othervm action to testcase .
>
>  It seems the testcase is a little over complex, is there any other
> method to make the testcase simpler ?
>
> On Fri, Mar 23, 2012 at 2:04 AM, Oleg Sukhodolsky <son.two at gmail.com>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.
>> >
>> >
>>
>
>
>
>  --
> Best Regards,
> Sean Chou
>
>
>


-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120326/3dad6330/attachment.html