<AWT Dev> <Swing Dev> Request for review: 7155298 : Editable TextArea blocks GUI application from exit
Charles Lee
littlee at linux.vnet.ibm.com
Sat Mar 31 02:01:14 PDT 2012
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120331/3365d7cc/attachment.html
More information about the awt-dev
mailing list