<AWT Dev> <Swing Dev> Request for review: 7155298 : Editable TextArea blocks GUI application from exit

[Anton V. Tarasov]

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>  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 Sukhodolsky<son.two at gmail.com>  wrote:
>>> Hi Sean,
>>>
>>> comments inlined.
>>>
>>> On Thu, Mar 22, 2012 at 10:15 AM, Sean Chou<zhouyx at 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.two at 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<zhouyx at 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,
>>>>>> Sean Chou
>>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best Regards,
>>>> Sean Chou
>>>>
>>
>>
>>
>> --
>> Best Regards,
>> Sean Chou
>>