Thanks to every one ! On Sat, Mar 31, 2012 at 5:01 PM, Charles Lee <litt...@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.pet...@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....@gmail.com >>> <mailto:son....@gmail.com>> wrote: >>> >>> On Thu, Mar 22, 2012 at 10:50 PM, Anton V. Tarasov >>> <anton.tara...@oracle.com <mailto:anton.tara...@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.tara...@oracle.com <mailto:anton.tara...@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.tara...@oracle.com <mailto:anton.tara...@oracle.com>> >>> >>> wrote: >>> >>>>> >>> >>>>> On 22.03.2012 12:47, Oleg Sukhodolsky wrote: >>> >>>>>> >>> >>>>>> On Thu, Mar 22, 2012 at 12:01 PM, Sean >>> Chou<zho...@linux.vnet.ibm.com <mailto:zho...@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
