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

Oleg Sukhodolsky son.two at gmail.com
Thu Mar 22 08:15:57 PDT 2012 

On Thu, Mar 22, 2012 at 5:55 PM, Anton V. Tarasov
<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>  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>
>>>>  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 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
>>>>>
>

More information about the awt-dev mailing list