<AWT Dev> <Swing Dev> Request for review: 7155298 : Editable TextArea blocks GUI application from exit
Anthony Petrov
anthony.petrov at oracle.com
Mon Apr 2 06:17:51 PDT 2012
Thank you!
--
best regards,
Anthony
On 03/31/12 13:01, Charles Lee 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 <mailto: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/
>> <http://cr.openjdk.java.net/%7Ezhouyx/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>
>> <mailto: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>
>> <mailto: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>
>> <mailto: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>
>> <mailto: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>
>> <mailto: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
>
More information about the awt-dev
mailing list