<AWT Dev> <Swing Dev> Request for review: 7155298 : Editable TextArea blocks GUI application from exit
Sean Chou
zhouyx at linux.vnet.ibm.com
Sat Mar 31 19:26:56 PDT 2012
Thanks to every one !
On Sat, Mar 31, 2012 at 5:01 PM, Charles Lee <littlee at linux.vnet.ibm.com>wrote:
> **
> Hi Sean,
>
> The patch has been committed @
>
> Changeset: 96340349e35b
> Author: zhouyx
> Date: 2012-03-31 16:55 +0800
> URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/96340349e35b
>
> 7155298: Editable TextArea/TextField are blocking GUI applications from exit
> Summary: Stop default caret's timer by setVisible(false) when dispose
> Reviewed-by: anthony, ant
>
>
> Please verify it.
>
> Thank you all for reviewing.
>
>
>
> On 03/27/2012 11:22 AM, Sean Chou wrote:
>
> Hi Anthony,
>
> I tried the scenario you suggested, but it doesn't work. And I found
> the jtreg spec says:
>
> ' A "main" action is
> considered to be finished when the main method returns; if a test involves
> multiple threads, some synchronization may be necessary to ensure that the
> other threads finish their work before the thread running the main method
> returns. '
>
> Then I tried to join TimerQueue in main, but it always blocks. So I
> started a new process
> to wait instead.
>
> I tested and found the "/" separated path works on windows, it is not
> a problem :)
>
> On Mon, Mar 26, 2012 at 9:55 PM, Anthony Petrov <anthony.petrov at oracle.com
> > wrote:
>
>> Hi Sean,
>>
>> 92 worker =
>>> Runtime.getRuntime().exec(System.getProperty("java.home")+"/bin/java
>>> TestDispose workprocess");
>>>
>>
>> This won't work on MS Windows because the path separator character is
>> different there.
>>
>> Actually, I don't understand why you need this Runtime stuff in the first
>> place. If test JVM doesn't terminate, the test will fail. So why not create
>> a frame and a text field right in the main(), then call dispose() and
>> return from main()? Since the timer thread will still be running, the
>> test's JVM won't exit, and the test will fail by timeout eventually. Will
>> this testing scenario work?
>>
>> --
>> best regards,
>> Anthony
>>
>>
>> On 03/23/12 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
>>> <mailto:son.two at gmail.com>> wrote:
>>>
>>> On Thu, Mar 22, 2012 at 10:50 PM, Anton V. Tarasov
>>> <anton.tarasov at oracle.com <mailto: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 <mailto: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 <mailto: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 <mailto: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
>
>
>
> --
> Yours Charles
>
>
--
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120401/80deaf03/attachment.html
More information about the awt-dev
mailing list