Re: AWT Dev Swing Dev Request for review: 7155298 : Editable TextArea blocks GUI application from exit
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.pet...@oracle.com mailto: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/ 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@gmail.com mailto:son@gmail.com mailto: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 mailto: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 mailto: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 mailto: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 Chouzho...@linux.vnet.ibm.com mailto:zho...@linux.vnet.ibm.com mailto: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
Re: AWT Dev Swing Dev Request for review: 7155298 : Editable TextArea blocks GUI application from exit
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 mailto: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/ 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@gmail.com mailto:son@gmail.com mailto: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 mailto: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 mailto: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 mailto: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 Chouzho...@linux.vnet.ibm.com mailto:zho...@linux.vnet.ibm.com mailto: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 focusedcomponent 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
Re: AWT Dev Swing Dev Request for review: 7155298 : Editable TextArea blocks GUI application from exit
Hi Sean, On 27.03.2012 7:22, 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. TimerQueue is a package private class which assumes reflection which I would avoid using by any means. I personally don't see any strong reason why you shouldn't use the Runtime stuff (taking into account the jtreg behavior). Anthony, do you? I tested and found the / separated path works on windows, it is not a problem :) I looked at the implementation of Runtime.exec(String) just for curiosity. It (in its deep) normalizes the path via File.getPath(), so using slash seems ok. Thanks, Anton. On Mon, Mar 26, 2012 at 9:55 PM, Anthony Petrov anthony.pet...@oracle.com mailto: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/ 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@gmail.com mailto:son@gmail.com mailto: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 mailto: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 mailto: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 mailto: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 Chouzho...@linux.vnet.ibm.com mailto:zho...@linux.vnet.ibm.com mailto: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 focusedcomponent 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
Re: AWT Dev Swing Dev Request for review: 7155298 : Editable TextArea blocks GUI application from exit
Sean, Anton, thanks for clarifications. I'm fine with the fix then. -- best regards, Anthony On 3/27/2012 12:54 PM, Anton V. Tarasov wrote: Hi Sean, On 27.03.2012 7:22, 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. TimerQueue is a package private class which assumes reflection which I would avoid using by any means. I personally don't see any strong reason why you shouldn't use the Runtime stuff (taking into account the jtreg behavior). Anthony, do you? I tested and found the / separated path works on windows, it is not a problem :) I looked at the implementation of Runtime.exec(String) just for curiosity. It (in its deep) normalizes the path via File.getPath(), so using slash seems ok. Thanks, Anton. On Mon, Mar 26, 2012 at 9:55 PM, Anthony Petrov anthony.pet...@oracle.com mailto: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/ 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@gmail.com mailto:son@gmail.com mailto: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 mailto: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 mailto: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 mailto: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 Chouzho...@linux.vnet.ibm.com mailto:zho...@linux.vnet.ibm.com mailto: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 focusedcomponent when the top-level window is disposed ? Well, for regular AWT component it is expected. And I'd
Re: AWT Dev Swing Dev Request for review: 7155298 : Editable TextArea blocks GUI application from exit
Hi Sean, I'm fine with your changes. Thanks! Anton. On 26.03.2012 6:48, Sean Chou wrote: 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/ http://cr.openjdk.java.net/%7Ezhouyx/7155298/webrev.03/ Please take a look again. Thanks ! On Sat, Mar 24, 2012 at 1:50 AM, Anton V. Tarasov anton.tara...@oracle.com mailto:anton.tara...@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/ 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@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 Chouzho...@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 focusedcomponent 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
Re: AWT Dev Swing Dev Request for review: 7155298 : Editable TextArea blocks GUI application from exit
Adding swing-dev back to CC since a question about JComponent has appeared. Artem On 3/22/2012 10:04 PM, Oleg Sukhodolsky wrote: On Thu, Mar 22, 2012 at 10:50 PM, Anton V. Tarasov 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.comwrote: 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 wrote: On 22.03.2012 12:47, Oleg Sukhodolsky wrote: On Thu, Mar 22, 2012 at 12:01 PM, Sean Chouzho...@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.
Re: AWT Dev Swing Dev Request for review: 7155298 : Editable TextArea blocks GUI application from exit
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.comwrote: 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.htmlhttp://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/~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.tarasov@oracle.**comanton.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.tarasov@oracle.**comanton.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.tarasov@oracle.**comanton.tara...@oracle.com wrote: On 22.03.2012 12:47, Oleg Sukhodolsky wrote: On Thu, Mar 22, 2012 at 12:01 PM, Sean Chouzho...@linux.vnet.ibm.com mailto:zho...@linux.vnet.ibm.**comzho...@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 focusedcomponent 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
Re: AWT Dev Swing Dev Request for review: 7155298 : Editable TextArea blocks GUI application from exit
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.tara...@oracle.comwrote: ** 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@gmail.comwrote: On Thu, Mar 22, 2012 at 10:50 PM, Anton V. Tarasov 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 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.comwrote: 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 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 focusedcomponent 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
Re: AWT Dev Swing Dev Request for review: 7155298 : Editable TextArea blocks GUI application from exit
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 wrote: On Thu, Mar 22, 2012 at 10:50 PM, Anton V. Tarasov 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 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.comwrote: 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 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 focusedcomponent 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
Re: AWT Dev Swing Dev Request for review: 7155298 : Editable TextArea blocks GUI application from exit
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/ 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@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 Chouzho...@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 focusedcomponent 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
Re: AWT Dev Swing Dev Request for review: 7155298 : Editable TextArea blocks GUI application from exit
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 ? On Thu, Mar 22, 2012 at 2:42 PM, Oleg Sukhodolsky son@gmail.com wrote: Hi Sean, comments inlined. On Thu, Mar 22, 2012 at 10:15 AM, Sean Chou zho...@linux.vnet.ibm.com wrote: Hi Oleg, I replaced the TextArea with JTextArea in the test and the application exits. With some code added to DefaultCaret.java after invocation to flasher.stop , I got a stack trace as follow, which is not seen in test with TextArea. java.lang.RuntimeException: my exception 2 at javax.swing.text.DefaultCaret.setVisible(DefaultCaret.java:985) at javax.swing.text.DefaultCaret.focusLost(DefaultCaret.java:364) at java.awt.AWTEventMulticaster.focusLost(AWTEventMulticaster.java:230) at java.awt.Component.processFocusEvent(Component.java:6396) at java.awt.Component.processEvent(Component.java:6260) at java.awt.Container.processEvent(Container.java:2229) at java.awt.Component.dispatchEventImpl(Component.java:4860) at java.awt.Container.dispatchEventImpl(Container.java:2287) at java.awt.Component.dispatchEvent(Component.java:4686) at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1908) at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:937) at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:611) at java.awt.Component.dispatchEventImpl(Component.java:4730) at java.awt.Container.dispatchEventImpl(Container.java:2287) at java.awt.Component.dispatchEvent(Component.java:4686) at sun.awt.SunToolkit$4.run(SunToolkit.java:588) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705) at java.awt.EventQueue.access$000(EventQueue.java:101) at java.awt.EventQueue$3.run(EventQueue.java:666) at java.awt.EventQueue$3.run(EventQueue.java:664) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) at java.awt.EventQueue.dispatchEvent(EventQueue.java:675) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:211) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:128) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:117) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:113) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:105) at java.awt.EventDispatchThread.run(EventDispatchThread.java:90) So, the difference is when disposing, if JTextArea is used, DefaultCaret receives a focusLost event; if TextArea is used, DefaultCaret does not receive that event. Does DefaultCaret receives focusGained for TextArea? If yes, perhaps we should investigate why it doesn't receive focusLost and fix this (who knows what other problems could be introduced by invisible focused JTextArea) I also instrumented forwardFocusLost and found it is not invoked when disposing (this can be seen from the above stack trace as well) . But I can't answer the question whether AWTTextArea/AWTTextField.removeNotify() should stop the timer. Swing-dev is added to cc list. AWTTextArea/AWTTextField are our own classes, so it is we who responsible to decide whether added some calls to thier methods or not. Regards, Oleg. On Wed, Mar 21, 2012 at 9:14 PM, Oleg Sukhodolsky son@gmail.com wrote: Hi Sean, as far as I understand the caret and the timer both come from Swing, thus I wonder why calling removeNotify() on JPasswotrdField/JTextArea doesn't stop the timer? What does Swing expect? It might be some bug in Swing (I hope it is not, but it is better to verify ;) As for changes I'd suggest to move this additional call (if we decide that this is the right way to fix the problem) into AWTTextArea/AWTTextField.removeNotify() this will help in case we decide to call it in some other place. Regards, Oleg. On Wed, Mar 21, 2012 at 11:55 AM, Sean Chou zho...@linux.vnet.ibm.com wrote: Hi all, It is found that when TextArea or TextField is setEditable(true), the application will not exit after the application frame disposes. The reason is the visible caret contains a timer which controls its flashing . This timer must be stopped when disposing. Link to webrev: http://cr.openjdk.java.net/~zhouyx/7155298/webrev.00/ Link to bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7155298 -- Best Regards,
Re: AWT Dev Swing Dev Request for review: 7155298 : Editable TextArea blocks GUI application from exit
On Thu, Mar 22, 2012 at 12:01 PM, Sean Chou 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. Anyone from AWT team, what is the current policy for forwarding focus events to peers? Reagds, Oleg. On Thu, Mar 22, 2012 at 2:42 PM, Oleg Sukhodolsky son@gmail.com wrote: Hi Sean, comments inlined. On Thu, Mar 22, 2012 at 10:15 AM, Sean Chou zho...@linux.vnet.ibm.com wrote: Hi Oleg, I replaced the TextArea with JTextArea in the test and the application exits. With some code added to DefaultCaret.java after invocation to flasher.stop , I got a stack trace as follow, which is not seen in test with TextArea. java.lang.RuntimeException: my exception 2 at javax.swing.text.DefaultCaret.setVisible(DefaultCaret.java:985) at javax.swing.text.DefaultCaret.focusLost(DefaultCaret.java:364) at java.awt.AWTEventMulticaster.focusLost(AWTEventMulticaster.java:230) at java.awt.Component.processFocusEvent(Component.java:6396) at java.awt.Component.processEvent(Component.java:6260) at java.awt.Container.processEvent(Container.java:2229) at java.awt.Component.dispatchEventImpl(Component.java:4860) at java.awt.Container.dispatchEventImpl(Container.java:2287) at java.awt.Component.dispatchEvent(Component.java:4686) at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1908) at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:937) at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:611) at java.awt.Component.dispatchEventImpl(Component.java:4730) at java.awt.Container.dispatchEventImpl(Container.java:2287) at java.awt.Component.dispatchEvent(Component.java:4686) at sun.awt.SunToolkit$4.run(SunToolkit.java:588) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705) at java.awt.EventQueue.access$000(EventQueue.java:101) at java.awt.EventQueue$3.run(EventQueue.java:666) at java.awt.EventQueue$3.run(EventQueue.java:664) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) at java.awt.EventQueue.dispatchEvent(EventQueue.java:675) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:211) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:128) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:117) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:113) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:105) at java.awt.EventDispatchThread.run(EventDispatchThread.java:90) So, the difference is when disposing, if JTextArea is used, DefaultCaret receives a focusLost event; if TextArea is used, DefaultCaret does not receive that event. Does DefaultCaret receives focusGained for TextArea? If yes, perhaps we should investigate why it doesn't receive focusLost and fix this (who knows what other problems could be introduced by invisible focused JTextArea) I also instrumented forwardFocusLost and found it is not invoked when disposing (this can be seen from the above stack trace as well) . But I can't answer the question whether AWTTextArea/AWTTextField.removeNotify() should stop the timer. Swing-dev is added to cc list. AWTTextArea/AWTTextField are our own classes, so it is we who responsible to decide whether added some calls to thier methods or not. Regards, Oleg. On Wed, Mar 21, 2012 at 9:14 PM, Oleg Sukhodolsky son@gmail.com wrote: Hi Sean, as far as I understand the caret and the timer both come from Swing, thus I wonder why calling removeNotify() on JPasswotrdField/JTextArea doesn't stop the timer? What does Swing expect? It might be some bug in Swing (I hope it is not, but it is better to verify ;) As for changes I'd suggest to move this additional call (if we decide that this is the right way to fix the problem) into AWTTextArea/AWTTextField.removeNotify() this will help in case we decide to call it in some other place. Regards, Oleg. On Wed, Mar 21, 2012 at 11:55 AM, Sean Chou zho...@linux.vnet.ibm.com wrote: Hi all, It is found that when TextArea or TextField is setEditable(true), the application will not exit after the application frame
Re: AWT Dev Swing Dev Request for review: 7155298 : Editable TextArea blocks GUI application from exit
On 22.03.2012 12:47, Oleg Sukhodolsky wrote: On Thu, Mar 22, 2012 at 12:01 PM, Sean Chouzho...@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. Anyone from AWT team, what is the current policy for forwarding focus events to peers? Focus events are forwarded to peers. Look at the very end of Component.dispatchEventImpl(AWTEvent). Thanks, Anton. Reagds, Oleg. On Thu, Mar 22, 2012 at 2:42 PM, Oleg Sukhodolskyson@gmail.com wrote: Hi Sean, comments inlined. On Thu, Mar 22, 2012 at 10:15 AM, Sean Chouzho...@linux.vnet.ibm.com wrote: Hi Oleg, I replaced the TextArea with JTextArea in the test and the application exits. With some code added to DefaultCaret.java after invocation to flasher.stop , I got a stack trace as follow, which is not seen in test with TextArea. java.lang.RuntimeException: my exception 2 at javax.swing.text.DefaultCaret.setVisible(DefaultCaret.java:985) at javax.swing.text.DefaultCaret.focusLost(DefaultCaret.java:364) at java.awt.AWTEventMulticaster.focusLost(AWTEventMulticaster.java:230) at java.awt.Component.processFocusEvent(Component.java:6396) at java.awt.Component.processEvent(Component.java:6260) at java.awt.Container.processEvent(Container.java:2229) at java.awt.Component.dispatchEventImpl(Component.java:4860) at java.awt.Container.dispatchEventImpl(Container.java:2287) at java.awt.Component.dispatchEvent(Component.java:4686) at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1908) at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:937) at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:611) at java.awt.Component.dispatchEventImpl(Component.java:4730) at java.awt.Container.dispatchEventImpl(Container.java:2287) at java.awt.Component.dispatchEvent(Component.java:4686) at sun.awt.SunToolkit$4.run(SunToolkit.java:588) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705) at java.awt.EventQueue.access$000(EventQueue.java:101) at java.awt.EventQueue$3.run(EventQueue.java:666) at java.awt.EventQueue$3.run(EventQueue.java:664) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) at java.awt.EventQueue.dispatchEvent(EventQueue.java:675) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:211) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:128) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:117) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:113) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:105) at java.awt.EventDispatchThread.run(EventDispatchThread.java:90) So, the difference is when disposing, if JTextArea is used, DefaultCaret receives a focusLost event; if TextArea is used, DefaultCaret does not receive that event. Does DefaultCaret receives focusGained for TextArea? If yes, perhaps we should investigate why it doesn't receive focusLost and fix this (who knows what other problems could be introduced by invisible focused JTextArea) I also instrumented forwardFocusLost and found it is not invoked when disposing (this can be seen from the above stack trace as well) . But I can't answer the question whether AWTTextArea/AWTTextField.removeNotify() should stop the timer. Swing-dev is added to cc list. AWTTextArea/AWTTextField are our own classes, so it is we who responsible to decide whether added some calls to thier methods or not. Regards, Oleg. On Wed, Mar 21, 2012 at 9:14 PM, Oleg Sukhodolskyson@gmail.com wrote: Hi Sean, as far as I understand the caret and the timer both come from Swing, thus I wonder why calling removeNotify() on JPasswotrdField/JTextArea doesn't stop the timer? What does Swing expect? It might be some bug in Swing (I hope it is not, but it is better to verify ;) As for changes I'd suggest to move this additional call (if we decide that this is the right way to fix the problem) into AWTTextArea/AWTTextField.removeNotify() this will help in case we decide to call it in some other place. Regards, Oleg. On Wed, Mar 21, 2012 at 11:55 AM, Sean Chouzho...@linux.vnet.ibm.com wrote: Hi all, It is found that when TextArea or TextField is setEditable(true), the
Re: AWT Dev Swing Dev Request for review: 7155298 : Editable TextArea blocks GUI application from exit
On Thu, Mar 22, 2012 at 2:19 PM, Anton V. Tarasov anton.tara...@oracle.com wrote: On 22.03.2012 12:47, Oleg Sukhodolsky wrote: On Thu, Mar 22, 2012 at 12:01 PM, Sean Chouzho...@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. Anyone from AWT team, what is the current policy for forwarding focus events to peers? Focus events are forwarded to peers. Look at the very end of Component.dispatchEventImpl(AWTEvent). Thanks, Anton. Reagds, Oleg. On Thu, Mar 22, 2012 at 2:42 PM, Oleg Sukhodolskyson@gmail.com wrote: Hi Sean, comments inlined. On Thu, Mar 22, 2012 at 10:15 AM, Sean Chouzho...@linux.vnet.ibm.com wrote: Hi Oleg, I replaced the TextArea with JTextArea in the test and the application exits. With some code added to DefaultCaret.java after invocation to flasher.stop , I got a stack trace as follow, which is not seen in test with TextArea. java.lang.RuntimeException: my exception 2 at javax.swing.text.DefaultCaret.setVisible(DefaultCaret.java:985) at javax.swing.text.DefaultCaret.focusLost(DefaultCaret.java:364) at java.awt.AWTEventMulticaster.focusLost(AWTEventMulticaster.java:230) at java.awt.Component.processFocusEvent(Component.java:6396) at java.awt.Component.processEvent(Component.java:6260) at java.awt.Container.processEvent(Container.java:2229) at java.awt.Component.dispatchEventImpl(Component.java:4860) at java.awt.Container.dispatchEventImpl(Container.java:2287) at java.awt.Component.dispatchEvent(Component.java:4686) at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1908) at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:937) at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:611) at java.awt.Component.dispatchEventImpl(Component.java:4730) at java.awt.Container.dispatchEventImpl(Container.java:2287) at java.awt.Component.dispatchEvent(Component.java:4686) at sun.awt.SunToolkit$4.run(SunToolkit.java:588) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705) at java.awt.EventQueue.access$000(EventQueue.java:101) at java.awt.EventQueue$3.run(EventQueue.java:666) at java.awt.EventQueue$3.run(EventQueue.java:664) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) at java.awt.EventQueue.dispatchEvent(EventQueue.java:675) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:211) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:128) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:117) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:113) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:105) at java.awt.EventDispatchThread.run(EventDispatchThread.java:90) So, the difference is when disposing, if JTextArea is used, DefaultCaret receives a focusLost event; if TextArea is used, DefaultCaret does not receive that event. Does DefaultCaret receives focusGained for TextArea? If yes, perhaps we should investigate why it doesn't receive focusLost and fix this (who knows what other problems could be introduced by invisible focused JTextArea) I also instrumented forwardFocusLost and found it is not invoked when disposing (this can be seen from the above stack trace as well) . But I can't answer the question whether AWTTextArea/AWTTextField.removeNotify() should stop the timer. Swing-dev is added to cc list. AWTTextArea/AWTTextField are our own classes, so it is we who responsible to decide whether added some calls to thier methods or not. Regards, Oleg. On Wed, Mar 21, 2012 at 9:14 PM, Oleg Sukhodolskyson@gmail.com wrote: Hi Sean, as far as I understand the caret and the timer both come from Swing, thus I wonder why calling removeNotify() on JPasswotrdField/JTextArea doesn't stop the timer? What does Swing expect? It might be some bug in Swing (I hope it is not, but it is better to verify ;) As for changes I'd suggest to move this additional call (if we decide that this is the right way to fix the problem) into
Re: AWT Dev Swing Dev Request for review: 7155298 : Editable TextArea blocks GUI application from exit
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 wrote: On 22.03.2012 12:47, Oleg Sukhodolsky wrote: On Thu, Mar 22, 2012 at 12:01 PM, Sean Chouzho...@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. Thanks, Anton. Anyone from AWT team, what is the current policy for forwarding focus events to peers? Focus events are forwarded to peers. Look at the very end of Component.dispatchEventImpl(AWTEvent). Thanks, Anton. Reagds, Oleg. On Thu, Mar 22, 2012 at 2:42 PM, Oleg Sukhodolskyson@gmail.com wrote: Hi Sean, comments inlined. On Thu, Mar 22, 2012 at 10:15 AM, Sean Chouzho...@linux.vnet.ibm.com wrote: Hi Oleg, I replaced the TextArea with JTextArea in the test and the application exits. With some code added to DefaultCaret.java after invocation to flasher.stop , I got a stack trace as follow, which is not seen in test with TextArea. java.lang.RuntimeException: my exception 2 at javax.swing.text.DefaultCaret.setVisible(DefaultCaret.java:985) at javax.swing.text.DefaultCaret.focusLost(DefaultCaret.java:364) at java.awt.AWTEventMulticaster.focusLost(AWTEventMulticaster.java:230) at java.awt.Component.processFocusEvent(Component.java:6396) at java.awt.Component.processEvent(Component.java:6260) at java.awt.Container.processEvent(Container.java:2229) at java.awt.Component.dispatchEventImpl(Component.java:4860) at java.awt.Container.dispatchEventImpl(Container.java:2287) at java.awt.Component.dispatchEvent(Component.java:4686) at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1908) at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:937) at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:611) at java.awt.Component.dispatchEventImpl(Component.java:4730) at java.awt.Container.dispatchEventImpl(Container.java:2287) at java.awt.Component.dispatchEvent(Component.java:4686) at sun.awt.SunToolkit$4.run(SunToolkit.java:588) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705) at java.awt.EventQueue.access$000(EventQueue.java:101) at java.awt.EventQueue$3.run(EventQueue.java:666) at java.awt.EventQueue$3.run(EventQueue.java:664) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) at java.awt.EventQueue.dispatchEvent(EventQueue.java:675) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:211) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:128) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:117) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:113) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:105) at java.awt.EventDispatchThread.run(EventDispatchThread.java:90) So, the difference is when disposing, if JTextArea is used, DefaultCaret receives a focusLost event; if TextArea is used, DefaultCaret does not receive that event. Does DefaultCaret receives focusGained for TextArea? If yes, perhaps we should investigate why it doesn't receive focusLost and fix this (who knows what other problems could be introduced by invisible focused JTextArea) I also instrumented forwardFocusLost and found it is not invoked when disposing (this can be seen from the above stack trace as well) . But I can't answer the question whether AWTTextArea/AWTTextField.removeNotify() should stop the timer. Swing-dev is added to cc list. AWTTextArea/AWTTextField are our own classes, so it is we who responsible to decide whether added some calls to thier methods or not. Regards, Oleg. On Wed, Mar 21, 2012 at 9:14 PM, Oleg Sukhodolskyson@gmail.com wrote: Hi Sean, as far as I understand the caret and the
Re: AWT Dev Swing Dev Request for review: 7155298 : Editable TextArea blocks GUI application from exit
On Thu, Mar 22, 2012 at 5:55 PM, Anton V. Tarasov 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 wrote: On 22.03.2012 12:47, Oleg Sukhodolsky wrote: On Thu, Mar 22, 2012 at 12:01 PM, Sean Chouzho...@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. Thanks, Anton. Anyone from AWT team, what is the current policy for forwarding focus events to peers? Focus events are forwarded to peers. Look at the very end of Component.dispatchEventImpl(AWTEvent). Thanks, Anton. Reagds, Oleg. On Thu, Mar 22, 2012 at 2:42 PM, Oleg Sukhodolskyson@gmail.com wrote: Hi Sean, comments inlined. On Thu, Mar 22, 2012 at 10:15 AM, Sean Chouzho...@linux.vnet.ibm.com wrote: Hi Oleg, I replaced the TextArea with JTextArea in the test and the application exits. With some code added to DefaultCaret.java after invocation to flasher.stop , I got a stack trace as follow, which is not seen in test with TextArea. java.lang.RuntimeException: my exception 2 at javax.swing.text.DefaultCaret.setVisible(DefaultCaret.java:985) at javax.swing.text.DefaultCaret.focusLost(DefaultCaret.java:364) at java.awt.AWTEventMulticaster.focusLost(AWTEventMulticaster.java:230) at java.awt.Component.processFocusEvent(Component.java:6396) at java.awt.Component.processEvent(Component.java:6260) at java.awt.Container.processEvent(Container.java:2229) at java.awt.Component.dispatchEventImpl(Component.java:4860) at java.awt.Container.dispatchEventImpl(Container.java:2287) at java.awt.Component.dispatchEvent(Component.java:4686) at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1908) at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:937) at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:611) at java.awt.Component.dispatchEventImpl(Component.java:4730) at java.awt.Container.dispatchEventImpl(Container.java:2287) at java.awt.Component.dispatchEvent(Component.java:4686) at sun.awt.SunToolkit$4.run(SunToolkit.java:588) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705) at java.awt.EventQueue.access$000(EventQueue.java:101) at java.awt.EventQueue$3.run(EventQueue.java:666) at java.awt.EventQueue$3.run(EventQueue.java:664) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) at java.awt.EventQueue.dispatchEvent(EventQueue.java:675) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:211) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:128) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:117) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:113) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:105) at java.awt.EventDispatchThread.run(EventDispatchThread.java:90) So, the difference is when disposing,
Re: AWT Dev Swing Dev Request for review: 7155298 : Editable TextArea blocks GUI application from exit
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 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.comwrote: On 22.03.2012 12:47, Oleg Sukhodolsky wrote: On Thu, Mar 22, 2012 at 12:01 PM, Sean Chouzho...@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 focusedcomponent 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... 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()? Either of these looks fine to me. Thanks, Anton.
Re: AWT Dev Swing Dev Request for review: 7155298 : Editable TextArea blocks GUI application from exit
On Thu, Mar 22, 2012 at 10:50 PM, Anton V. Tarasov 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 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 wrote: On 22.03.2012 12:47, Oleg Sukhodolsky wrote: On Thu, Mar 22, 2012 at 12:01 PM, Sean Chouzho...@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.
