From pavel.porvatov at oracle.com  Mon Oct  3 02:40:12 2011
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Mon, 03 Oct 2011 13:40:12 +0400
Subject: <Swing Dev> Unexpected NullPointerException by endComposition()
In-Reply-To: <4E817E18.5020209@linux.vnet.ibm.com>
References: <4E784792.7050202@linux.vnet.ibm.com> <4E79F8E4.8030509@oracle.com>
	<4E7AD3E9.7020704@linux.vnet.ibm.com>
	<1316683094.13161.4.camel@chalkhill>
	<4E817E18.5020209@linux.vnet.ibm.com>
Message-ID: <4E8982FC.2030605@oracle.com>

Hi Charles,
> On 09/22/2011 05:18 PM, Neil Richards wrote:
>> On Thu, 2011-09-22 at 14:21 +0800, Charles Lee wrote:
>>> Hi guys,
>>>
>>> The webrev is attached.
>> For ease of review, I've uploaded the webrev to cr.openjdk.java.net [1]
>>
>> Regards, Neil
>>
>> [1] http://cr.openjdk.java.net/~ngmr/6938583/webrev.00
>>
> Hi guys,
>
> Any update about this issue? Is the idea workable?
>
Can you explain why should we consume right clicks but not left ones? 
(May be there are other test cases when NPE is thrown... ) And why do 
you consume event? (May be it hides NPE but breaks functionality)

Thanks, Pavel

From littlee at linux.vnet.ibm.com  Mon Oct  3 06:19:36 2011
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Mon, 03 Oct 2011 21:19:36 +0800
Subject: <Swing Dev> Unexpected NullPointerException by endComposition()
In-Reply-To: <4E8982FC.2030605@oracle.com>
References: <4E784792.7050202@linux.vnet.ibm.com> <4E79F8E4.8030509@oracle.com>
	<4E7AD3E9.7020704@linux.vnet.ibm.com>
	<1316683094.13161.4.camel@chalkhill>
	<4E817E18.5020209@linux.vnet.ibm.com> <4E8982FC.2030605@oracle.com>
Message-ID: <4E89B668.6020100@linux.vnet.ibm.com>

On 10/03/2011 05:40 PM, Pavel Porvatov wrote:
> Hi Charles,
>> On 09/22/2011 05:18 PM, Neil Richards wrote:
>>> On Thu, 2011-09-22 at 14:21 +0800, Charles Lee wrote:
>>>> Hi guys,
>>>>
>>>> The webrev is attached.
>>> For ease of review, I've uploaded the webrev to cr.openjdk.java.net [1]
>>>
>>> Regards, Neil
>>>
>>> [1] http://cr.openjdk.java.net/~ngmr/6938583/webrev.00
>>>
>> Hi guys,
>>
>> Any update about this issue? Is the idea workable?
>>
> Can you explain why should we consume right clicks but not left ones? 
> (May be there are other test cases when NPE is thrown... ) And why do 
> you consume event? (May be it hides NPE but breaks functionality)
>
> Thanks, Pavel
>

1. When right clicks, it suppose to show a manu on where you click. But 
I guess the demo (CodePointIM) is not suppose to show that (what will be 
show when use CodePointIM and right click? IIRC, I tried the normal 
input and right click but get nothing)
2. If point 1 is true, consuming the right click in the CodePointIM is 
the easiest way to fix it and less error-prone comparing with fixing in 
the jdk...
3. Consuming left click will disable the movement of the input place by 
clicking, I guess...

-- 
Yours Charles


From pavel.porvatov at oracle.com  Wed Oct  5 08:38:51 2011
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Wed, 05 Oct 2011 19:38:51 +0400
Subject: <Swing Dev> [Accessibility]Focus unable to traverse in the
	menubar
In-Reply-To: <1316522669.4683.10.camel@chalkhill>
References: <4E730733.6020402@linux.vnet.ibm.com> <4E7710C7.5030506@oracle.com>
	<1316522669.4683.10.camel@chalkhill>
Message-ID: <4E8C7A0B.7060006@oracle.com>

Hi Neil and Jing,
> On Mon, 2011-09-19 at 13:52 +0400, Pavel Porvatov wrote:
>> Hi Jing,
>>
>> I can't agree with you about the problem. According to
>> http://download.oracle.com/javase/tutorial/uiswing/components/menu.html
>> "Menus are unique in that, by convention, they aren't placed with the
>> other components in the UI". Instead, a menu usually appears either in a
>> menu bar or as a popup menu", so your test-case is invalid.
> Hi Pavel,
> I'm not sure I understand your objection to the testcase.
>
> As you can see from the testcase code, the JMenu component _is_ held by
> a JMenuBar component, in concordance with the documentation you point
> to.
Yep, that was my mistake. BTW the test treats with JMenu in a strange 
way. Actually the test should contain something like this:
         JMenuBar menubar = new JMenuBar();
         JMenu jMenu = new JMenu("sample menu");
         jMenu.add(new JMenuItem("hello"));
         menubar.add(jMenu);

> Perhaps you're worried that the physical layout of the components in the
> panel materially affects the nature of the problem being reported ?
>
> If so, please consider the modified testcase in an update to the webrev
> I previously posted [2].
>
> The modification uses the BorderLayout manager instead of GridLayout,
> adding the JMenuBar so that it appears at the top of the panel.
>
> You'll notice that this rearrangement in physical layout does not change
> the nature of the problem being reported.
>
> Hope this helps to clarify things,
> Regards, Neil
The fix changes default value of the JMenuBar.Focusable field and so it 
breaks backward compatibility.

Moreover the test have many other problems, but not only in JMenuBar:
1. Shift-TAB doesn't work from JComboBox
2. TAB from the last Button moves focus to some non-interactive 
component and next TAB pressing doesn't change focus state at all

May be the ContainerOrderFocusTraversalPolicy should be fixed...?

P.S. CC-ed Anton as a focus expert

From alexander.kouznetsov at oracle.com  Thu Oct  6 11:32:17 2011
From: alexander.kouznetsov at oracle.com (alexander.kouznetsov at oracle.com)
Date: Thu, 06 Oct 2011 18:32:17 +0000
Subject: <Swing Dev> hg: jdk8/swing/jdk: 7074853: TransparentRuler demos
	Readme should	mention the correct jar file name
Message-ID: <20111006183241.6F00B47C4D@hg.openjdk.java.net>

Changeset: 2409cb55b545
Author:    mrkam
Date:      2011-10-06 11:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/swing/jdk/rev/2409cb55b545

7074853: TransparentRuler demos Readme should mention the correct jar file name
Reviewed-by: rupashka

! src/share/demo/jfc/TransparentRuler/README.txt


From pavel.porvatov at oracle.com  Fri Oct  7 02:11:34 2011
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Fri, 07 Oct 2011 13:11:34 +0400
Subject: <Swing Dev> Unexpected NullPointerException by endComposition()
In-Reply-To: <4E89B668.6020100@linux.vnet.ibm.com>
References: <4E784792.7050202@linux.vnet.ibm.com> <4E79F8E4.8030509@oracle.com>
	<4E7AD3E9.7020704@linux.vnet.ibm.com>
	<1316683094.13161.4.camel@chalkhill>
	<4E817E18.5020209@linux.vnet.ibm.com> <4E8982FC.2030605@oracle.com>
	<4E89B668.6020100@linux.vnet.ibm.com>
Message-ID: <4E8EC246.6050409@oracle.com>

Hi Charles,
> On 10/03/2011 05:40 PM, Pavel Porvatov wrote:
>> Hi Charles,
>>> On 09/22/2011 05:18 PM, Neil Richards wrote:
>>>> On Thu, 2011-09-22 at 14:21 +0800, Charles Lee wrote:
>>>>> Hi guys,
>>>>>
>>>>> The webrev is attached.
>>>> For ease of review, I've uploaded the webrev to cr.openjdk.java.net 
>>>> [1]
>>>>
>>>> Regards, Neil
>>>>
>>>> [1] http://cr.openjdk.java.net/~ngmr/6938583/webrev.00
>>>>
>>> Hi guys,
>>>
>>> Any update about this issue? Is the idea workable?
>>>
>> Can you explain why should we consume right clicks but not left ones? 
>> (May be there are other test cases when NPE is thrown... ) And why do 
>> you consume event? (May be it hides NPE but breaks functionality)
>>
>> Thanks, Pavel
>>
>
> 1. When right clicks, it suppose to show a manu on where you click. 
> But I guess the demo (CodePointIM) is not suppose to show that (what 
> will be show when use CodePointIM and right click? IIRC, I tried the 
> normal input and right click but get nothing)
> 2. If point 1 is true, consuming the right click in the CodePointIM is 
> the easiest way to fix it and less error-prone comparing with fixing 
> in the jdk...
> 3. Consuming left click will disable the movement of the input place 
> by clicking, I guess...
>
There is no information about popup menu in the bug description. The 
problem is that endComposition() throws NPE if Input Method is turned on 
and the program is in composition mode. If you apply your fix and change 
BUTTON3 into BUTTON2 in the MouseEventTest2 test (see bug description), 
then NPE will be thrown with your patch as well...

Regards, Pavel

From littlee at linux.vnet.ibm.com  Fri Oct  7 08:28:31 2011
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Fri, 07 Oct 2011 23:28:31 +0800
Subject: <Swing Dev> Unexpected NullPointerException by endComposition()
In-Reply-To: <4E8EC246.6050409@oracle.com>
References: <4E784792.7050202@linux.vnet.ibm.com> <4E79F8E4.8030509@oracle.com>
	<4E7AD3E9.7020704@linux.vnet.ibm.com>
	<1316683094.13161.4.camel@chalkhill>
	<4E817E18.5020209@linux.vnet.ibm.com> <4E8982FC.2030605@oracle.com>
	<4E89B668.6020100@linux.vnet.ibm.com> <4E8EC246.6050409@oracle.com>
Message-ID: <4E8F1A9F.3010501@linux.vnet.ibm.com>

On 10/07/2011 05:11 PM, Pavel Porvatov wrote:
> Hi Charles,
>> On 10/03/2011 05:40 PM, Pavel Porvatov wrote:
>>> Hi Charles,
>>>> On 09/22/2011 05:18 PM, Neil Richards wrote:
>>>>> On Thu, 2011-09-22 at 14:21 +0800, Charles Lee wrote:
>>>>>> Hi guys,
>>>>>>
>>>>>> The webrev is attached.
>>>>> For ease of review, I've uploaded the webrev to 
>>>>> cr.openjdk.java.net [1]
>>>>>
>>>>> Regards, Neil
>>>>>
>>>>> [1] http://cr.openjdk.java.net/~ngmr/6938583/webrev.00
>>>>>
>>>> Hi guys,
>>>>
>>>> Any update about this issue? Is the idea workable?
>>>>
>>> Can you explain why should we consume right clicks but not left 
>>> ones? (May be there are other test cases when NPE is thrown... ) And 
>>> why do you consume event? (May be it hides NPE but breaks 
>>> functionality)
>>>
>>> Thanks, Pavel
>>>
>>
>> 1. When right clicks, it suppose to show a manu on where you click. 
>> But I guess the demo (CodePointIM) is not suppose to show that (what 
>> will be show when use CodePointIM and right click? IIRC, I tried the 
>> normal input and right click but get nothing)
>> 2. If point 1 is true, consuming the right click in the CodePointIM 
>> is the easiest way to fix it and less error-prone comparing with 
>> fixing in the jdk...
>> 3. Consuming left click will disable the movement of the input place 
>> by clicking, I guess...
>>
> There is no information about popup menu in the bug description. The 
> problem is that endComposition() throws NPE if Input Method is turned 
> on and the program is in composition mode. If you apply your fix and 
> change BUTTON3 into BUTTON2 in the MouseEventTest2 test (see bug 
> description), then NPE will be thrown with your patch as well...
>
> Regards, Pavel
Maybe I should use |SwingUtilities.isRightMouseButton(MouseEvent anEvent) ?|

-- 
Yours Charles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111007/cc7bb447/attachment.html 

From littlee at linux.vnet.ibm.com  Fri Oct  7 08:30:01 2011
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Fri, 07 Oct 2011 23:30:01 +0800
Subject: <Swing Dev> Unexpected NullPointerException by endComposition()
In-Reply-To: <4E8EC246.6050409@oracle.com>
References: <4E784792.7050202@linux.vnet.ibm.com> <4E79F8E4.8030509@oracle.com>
	<4E7AD3E9.7020704@linux.vnet.ibm.com>
	<1316683094.13161.4.camel@chalkhill>
	<4E817E18.5020209@linux.vnet.ibm.com> <4E8982FC.2030605@oracle.com>
	<4E89B668.6020100@linux.vnet.ibm.com> <4E8EC246.6050409@oracle.com>
Message-ID: <4E8F1AF9.1010205@linux.vnet.ibm.com>

On 10/07/2011 05:11 PM, Pavel Porvatov wrote:
> Hi Charles,
>> On 10/03/2011 05:40 PM, Pavel Porvatov wrote:
>>> Hi Charles,
>>>> On 09/22/2011 05:18 PM, Neil Richards wrote:
>>>>> On Thu, 2011-09-22 at 14:21 +0800, Charles Lee wrote:
>>>>>> Hi guys,
>>>>>>
>>>>>> The webrev is attached.
>>>>> For ease of review, I've uploaded the webrev to 
>>>>> cr.openjdk.java.net [1]
>>>>>
>>>>> Regards, Neil
>>>>>
>>>>> [1] http://cr.openjdk.java.net/~ngmr/6938583/webrev.00
>>>>>
>>>> Hi guys,
>>>>
>>>> Any update about this issue? Is the idea workable?
>>>>
>>> Can you explain why should we consume right clicks but not left 
>>> ones? (May be there are other test cases when NPE is thrown... ) And 
>>> why do you consume event? (May be it hides NPE but breaks 
>>> functionality)
>>>
>>> Thanks, Pavel
>>>
>>
>> 1. When right clicks, it suppose to show a manu on where you click. 
>> But I guess the demo (CodePointIM) is not suppose to show that (what 
>> will be show when use CodePointIM and right click? IIRC, I tried the 
>> normal input and right click but get nothing)
>> 2. If point 1 is true, consuming the right click in the CodePointIM 
>> is the easiest way to fix it and less error-prone comparing with 
>> fixing in the jdk...
>> 3. Consuming left click will disable the movement of the input place 
>> by clicking, I guess...
>>
> There is no information about popup menu in the bug description. The 
> problem is that endComposition() throws NPE if Input Method is turned 
> on and the program is in composition mode. If you apply your fix and 
> change BUTTON3 into BUTTON2 in the MouseEventTest2 test (see bug 
> description), then NPE will be thrown with your patch as well...
>
> Regards, Pavel

Why change Button3 to Button2? Does Button3 reflect the right click?

NPE was occurred because the component is null. Component becomes null 
because the default carret, IIRC, has been changed when it receive the 
right click event. It is the right behavior, if I understand correctly. 
So I am trying to disable the right click event if the demo does not 
suppose some menu should going to show up.

-- 
Yours Charles


From pavel.porvatov at oracle.com  Sat Oct  8 02:41:39 2011
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Sat, 08 Oct 2011 13:41:39 +0400
Subject: <Swing Dev> Unexpected NullPointerException by endComposition()
In-Reply-To: <4E8F1AF9.1010205@linux.vnet.ibm.com>
References: <4E784792.7050202@linux.vnet.ibm.com> <4E79F8E4.8030509@oracle.com>
	<4E7AD3E9.7020704@linux.vnet.ibm.com>
	<1316683094.13161.4.camel@chalkhill>
	<4E817E18.5020209@linux.vnet.ibm.com> <4E8982FC.2030605@oracle.com>
	<4E89B668.6020100@linux.vnet.ibm.com> <4E8EC246.6050409@oracle.com>
	<4E8F1AF9.1010205@linux.vnet.ibm.com>
Message-ID: <4E901AD3.9020805@oracle.com>

Hi Charles,
> On 10/07/2011 05:11 PM, Pavel Porvatov wrote:
>> Hi Charles,
>>> On 10/03/2011 05:40 PM, Pavel Porvatov wrote:
>>>> Hi Charles,
>>>>> On 09/22/2011 05:18 PM, Neil Richards wrote:
>>>>>> On Thu, 2011-09-22 at 14:21 +0800, Charles Lee wrote:
>>>>>>> Hi guys,
>>>>>>>
>>>>>>> The webrev is attached.
>>>>>> For ease of review, I've uploaded the webrev to 
>>>>>> cr.openjdk.java.net [1]
>>>>>>
>>>>>> Regards, Neil
>>>>>>
>>>>>> [1] http://cr.openjdk.java.net/~ngmr/6938583/webrev.00
>>>>>>
>>>>> Hi guys,
>>>>>
>>>>> Any update about this issue? Is the idea workable?
>>>>>
>>>> Can you explain why should we consume right clicks but not left 
>>>> ones? (May be there are other test cases when NPE is thrown... ) 
>>>> And why do you consume event? (May be it hides NPE but breaks 
>>>> functionality)
>>>>
>>>> Thanks, Pavel
>>>>
>>>
>>> 1. When right clicks, it suppose to show a manu on where you click. 
>>> But I guess the demo (CodePointIM) is not suppose to show that (what 
>>> will be show when use CodePointIM and right click? IIRC, I tried the 
>>> normal input and right click but get nothing)
>>> 2. If point 1 is true, consuming the right click in the CodePointIM 
>>> is the easiest way to fix it and less error-prone comparing with 
>>> fixing in the jdk...
>>> 3. Consuming left click will disable the movement of the input place 
>>> by clicking, I guess...
>>>
>> There is no information about popup menu in the bug description. The 
>> problem is that endComposition() throws NPE if Input Method is turned 
>> on and the program is in composition mode. If you apply your fix and 
>> change BUTTON3 into BUTTON2 in the MouseEventTest2 test (see bug 
>> description), then NPE will be thrown with your patch as well...
>>
>> Regards, Pavel
>
> Why change Button3 to Button2? Does Button3 reflect the right click?
No, Button2 is the middle button. But if you use Button2 in the 
MouseEventTest2 the test is still valid and it shouldn't throw any 
unexpected exceptions. But if you apply your fix and replace Button3 by 
Button2 in the MouseEventTest2 test, run the MouseEventTest2 test and 
use testcase from the bug description (of course in step 5 you should 
use the middle mouse button now) you'll get NPE
>
> NPE was occurred because the component is null. Component becomes null 
> because the default carret, IIRC, has been changed when it receive the 
> right click event. It is the right behavior, if I understand 
> correctly. So I am trying to disable the right click event if the demo 
> does not suppose some menu should going to show up.
>
I still don't understand where do you see popup menu? I wrote about the 
test from http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6938583 and 
there is no popup there...

Regards, Pavel

From pavel.porvatov at oracle.com  Sat Oct  8 04:35:32 2011
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Sat, 08 Oct 2011 15:35:32 +0400
Subject: <Swing Dev> A proposal for a behavior change about mnemonic key
In-Reply-To: <CAOo=rxVZZfCZjKRakzhQ9RxzQPC5bM1gUkDS-j6EORUoj91ybg@mail.gmail.com>
References: <AANLkTimDaioEK4oLkeqtRBPUCt4yPCZ0r3yHi=waisOg@mail.gmail.com>	<BANLkTi=yLQgf_c1J6ahVqenC+aHCJWh=kg@mail.gmail.com>	<CAOo=rxVvLQWxvLFZErt3xFTJokyHtfzetfbN3Rn=4DFPpVgmcA@mail.gmail.com>	<B56FF905-2911-41DB-935D-A2026AD1D137@gmail.com>	<CAOo=rxUNj5aCAbDKDo3i6rq-uEet4KdMKwy_iu4nRWdvE+oB6A@mail.gmail.com>	<4E6E2CC9.5080100@oracle.com>	<CAOo=rxUiLukv5rZbUG6QpSCorTwiNdCkvS3w3B1OV3WTW3us8w@mail.gmail.com>	<4E6F290E.9010701@oracle.com>	<CAOo=rxU1d=vvzDiRk=-PG1_JbtTgUNmE0QF2cuPtEH3bhTNQ+g@mail.gmail.com>	<4E70C568.6050105@oracle.com>	<CAOo=rxXGNy9qA5GoJ0y+0Cb6jTxvho1jNPgrp4hTGLHeR+wCUA@mail.gmail.com>	<4E79F306.3040406@oracle.com>
	<CAOo=rxVZZfCZjKRakzhQ9RxzQPC5bM1gUkDS-j6EORUoj91ybg@mail.gmail.com>
Message-ID: <4E903584.9030808@oracle.com>

Hi Sean,
> Hi Pavel,
>
>    Your observation is right, but I can't agree with the conclusion. 
> Windows and
> GTK behave differently about how to close an opened menu. Under GTK, press
> "alt" can not close an opened menu, so, the "esc" is used to close it; 
> while
> windows performs more friendly, when mnemonic key is pressed again, 
> the first
> opened menu is closed automatically. This is totally about how to 
> close an
> opened menu, and it doesn't change the fact that menus with same mnemonic
> key are iterated.
>
>    On the other side, swing implementation doesn't follow GTK's 
> behavior about
> how to close the menu at all. Open the swingset2 and you can find its 
> behavior
> is the same with windows. Press "alt+f" and then press "alt+l" will 
> open the
> "look and feel" menu instead of GTK's "alt+f", "esc", and "alt+l".
>
>    So, I think GTK's behavior about "use esc to close an opened menu" 
> is not
> user friendly and we can ignore it, while GTK's "iterate over menus 
> with same
> mnemonic key" is better than current java implementation and we can add
> this feature. And if a user wants to use GTK's key sequence "alt+f", 
> "esc",
> "alt+l", it is also functional.
>
>    So I think this enhancement will help keep the behavior same with 
> both these
> platforms, how do you think?
Sounds reasonable and I don't object now to the decision. Does anybody 
have ideas (e.g. objections) about the new functionality?

I glanced at your patch and have the following comments:
1. Could you please file CR about the problem
2. A test is needed (I think it's possible to write an automatic one)
3. Could you please correct the new code to obey our code standards 
(aligning, spacing, mandatory braces in if/else conditions and others)

If possible send patch as a webrev, please.

Thanks, Pavel

>
> 2011/9/21 Pavel Porvatov <pavel.porvatov at oracle.com 
> <mailto:pavel.porvatov at oracle.com>>
>
>     Hi Sean,
>
>     I found out that Windows and GTK works in different ways (I used
>     your apps):
>
>     1. When Alt+i is pressed several times:
>     In Windows focus moves between items
>     In Ubuntu focus stays at the initially selected item
>
>     2. When sequence Alt+i and Escape pressed several times
>     In Windows the first menu item is selected
>     In Ubuntu after every sequence the next item is selected
>
>     In such case we should use different strategies for different
>     platforms...
>
>
>     Regards, Pavel
>
>>     Hi Pavel,
>>
>>         I just tested linux gtk platform.  With gtk2+, ubuntu linux
>>     with kernel 2.6.38, xfce, x86_32.
>>     I set four menus with mnemonic "i". Press "alt+i" will travel
>>     through four menus. The difference
>>     is that each menu must be closed with "esc" before "alt+i" opens
>>     the next one.
>>
>>         So press "alt+i" opens "File", and press "esc" to close it;
>>         then press "alt+i" opens "Edit", and press "esc" to close it;
>>         ... for next menu with mnemonic "i"
>>
>>     I attached the test application and its ui file. If it is
>>     blocked, please use
>>     this link:
>>     https://docs.google.com/leaf?id=0B8kRxsymP7imOGU1NjhiM2ItMGQ5Ni00NWNhLWJmMDQtZjZiZmQzN2U4ZGUw&hl=en_US
>>     <https://docs.google.com/leaf?id=0B8kRxsymP7imOGU1NjhiM2ItMGQ5Ni00NWNhLWJmMDQtZjZiZmQzN2U4ZGUw&hl=en_US>
>>
>>     Ubuntu x86_32 should work.
>>
>>
>>     So, I think both windows and linux gtk have supported traversal
>>     of same mnemonic keyed
>>     items already.
>>
>>
>>     2011/9/14 Pavel Porvatov <pavel.porvatov at oracle.com
>>     <mailto:pavel.porvatov at oracle.com>>
>>
>>         Hi Sean,
>>>         Hi Pavel,
>>>
>>>             Let's see if this time works. The attachement just
>>>         contains the exe file written by C#, the application is very
>>>         simple, I just drag a menu to the default WinForm in VS2003.
>>>             Please change the extension from exe1 to exe after unzip
>>>         as gmail doesn't allow exe file to be sent.
>>         Yes, I see. And what about other platforms/lafs? Your patch
>>         affects behavior of all lafs. So we must be sure, that such
>>         behavior is correct for every supported platform...
>>
>>         Regards, Pavel
>>
>>>
>>>         2011/9/13 Pavel Porvatov <pavel.porvatov at oracle.com
>>>         <mailto:pavel.porvatov at oracle.com>>
>>>
>>>             Hi Sean,
>>>
>>>             I think the attached sample was removed because I didn't
>>>             get any attachments...
>>>
>>>             Regards, Pavel
>>>
>>>>             Hi Pavel,
>>>>
>>>>                I found C# Form application treats Mnemonics in menu
>>>>             in this way. I attached the sample
>>>>             application. Press alt+i will iterate over three menu.
>>>>
>>>>             2011/9/13 Pavel Porvatov <pavel.porvatov at oracle.com
>>>>             <mailto:pavel.porvatov at oracle.com>>
>>>>
>>>>                 Hi Sean,
>>>>>                 Hi,
>>>>>
>>>>>                    Thanks.
>>>>>
>>>>>                    So is there any one can give me a suggestion
>>>>>                 about what shall I
>>>>>                 do if we want these feature ?  Thanks again.
>>>>                 First of all you should file a bug (RFE actually).
>>>>                 BTW: before reviewing the fix I'd like to ask about
>>>>                 OS behavior when there are several components with
>>>>                 the same mnemonic. How Windows XP/Vista/7 and Linux
>>>>                 (Gnome/KDE) manage the described situation?
>>>>
>>>>                 Regards, Pavel
>>>>
>>>>
>>>>>
>>>>>                 2011/7/6 Jean-Remi Desjardins
>>>>>                 <jeanremi.desjardins at gmail.com
>>>>>                 <mailto:jeanremi.desjardins at gmail.com>>
>>>>>
>>>>>                     I think that sounds like a great idea!
>>>>>
>>>>>                     Regards,
>>>>>                     Jean-R?mi Desjardins
>>>>>
>>>>>                     Sent from my iPhone (so don't expect me to be
>>>>>                     too verbose)
>>>>>
>>>>>                     On 2011-07-06, at 5:42 AM, Sean Chou
>>>>>                     <zhouyx at linux.vnet.ibm.com
>>>>>                     <mailto:zhouyx at linux.vnet.ibm.com>> wrote:
>>>>>
>>>>>>                     Hi,
>>>>>>
>>>>>>                        Is there anybody interested in this
>>>>>>                     feature? Or any other comments?
>>>>>>
>>>>>>                     2011/4/21 Sean Chou
>>>>>>                     <zhouyx at linux.vnet.ibm.com
>>>>>>                     <mailto:zhouyx at linux.vnet.ibm.com>>
>>>>>>
>>>>>>                         Hi,
>>>>>>
>>>>>>                            I have a simple patch to demo the new
>>>>>>                         behavior. With the patch, the focus will
>>>>>>                         go through the radiobuttons with mnemonic
>>>>>>                         key Y when alt+y is pressed instead of
>>>>>>                         select the last.
>>>>>>
>>>>>>
>>>>>>                         The patch is as follows:
>>>>>>
>>>>>>                         diff -r 554adcfb615e src/share/classes/javax/swing/KeyboardManager.java
>>>>>>                         --- a/src/share/classes/javax/swing/KeyboardManager.java	Wed Mar 16 15:01:07 2011 -0700
>>>>>>                         +++ b/src/share/classes/javax/swing/KeyboardManager.java	Thu Mar 17 14:57:14 2011 +0800
>>>>>>                         @@ -251,6 +251,93 @@
>>>>>>                                            }
>>>>>>                                        } else if ( tmp instanceof Vector) { //more than one comp registered for this
>>>>>>                                            Vector v = (Vector)tmp;
>>>>>>                         +
>>>>>>                         +                 /* The below code is added to make sure the focus is not always
>>>>>>                         +                    transferred to the last component in the vector when
>>>>>>                         +                    more than one component have the same mnemonic
>>>>>>                         +                 */
>>>>>>                         +	              if ((e.getModifiers()&  Event.ALT_MASK) == Event.ALT_MASK) {
>>>>>>                         +                      /* Mnemonic key should transfer the focus only, do not select.
>>>>>>                         +                       * The following code works in this way:
>>>>>>                         +                       * 1. If only one component in the vector is visible, fireBinding on it.
>>>>>>                         +                       * 2. If multi-components in the vector are visible, move the focus to next component.
>>>>>>                         +                       *    2.1 If the next component is not a JAbstractButton, fireBinding on it.
>>>>>>                         +                       *    2.2 If the next component is a JMenu, which is a JAbstractButton, fireBinding
>>>>>>                         +                       *        on it to open the menu.
>>>>>>                         +                       *    2.3 If the next component is another JAbstractButton like JRadioButton. Request
>>>>>>                         +                       *        focus on it instead of fireBinding. To AVOID SELECTION&  CLICK of the button.
>>>>>>                         +                       * 3. If the code is triggered by release event, fireBinding on current focus component
>>>>>>                         +                       *    instead of move focus.
>>>>>>                         +                       * 4. Further consideration: there may be more swing control like JMenu, or customized
>>>>>>                         +                       *    controls, which may break this behavior.
>>>>>>                         +                       */
>>>>>>                         +                      // This has alt as it's modifier so this could be a mnemonic
>>>>>>                         +                      Component focusOwner = KeyboardFocusManager.getCurrentKeyboardFocusManager().getFocusOwner();
>>>>>>                         +                      {
>>>>>>                         +                      // If only one visible component, invoke it.
>>>>>>                         +                      int visibleComponentCounter = 0;
>>>>>>                         +                      int nextFocus = 0;
>>>>>>                         +                      for (int i =  0; i<  v.size(); i++){
>>>>>>                         +                          JComponent c = (JComponent) v.elementAt(i);
>>>>>>                         +                          if (c.isShowing()&&  c.isEnabled()){
>>>>>>                         +                    	         visibleComponentCounter++ ;
>>>>>>                         +                    		      nextFocus = i;
>>>>>>                         +                    	     }
>>>>>>                         +                      }
>>>>>>                         +                      if (visibleComponentCounter == 1){
>>>>>>                         +                    	     JComponent tmpc = (JComponent) v.elementAt(nextFocus);
>>>>>>                         +                    	     fireBinding(tmpc, ks, e, pressed);
>>>>>>                         +                          if (e.isConsumed())
>>>>>>                         +                        	  return true;
>>>>>>                         +                      }
>>>>>>                         +                      // If multi-components are visible, do not select the button, just move the focus.
>>>>>>                         +                      for (int counter = v.size() - 1; counter>= 0; counter--) {
>>>>>>                         +                          JComponent c = (JComponent) v.elementAt(counter);
>>>>>>                         +                          if (c.isShowing()&&  c.isEnabled()) {
>>>>>>                         +                              if ((c == focusOwner)
>>>>>>                         +                                       || (c instanceof JLabel&&  ((JLabel) c).getLabelFor() == focusOwner)) {
>>>>>>                         +                                  if (e.getID() == KeyEvent.KEY_RELEASED){
>>>>>>                         +                                	     nextFocus = counter;
>>>>>>                         +                                	     break;
>>>>>>                         +                                  }
>>>>>>                         +                            	    nextFocus = (counter - 1 + v.size()) % v.size();
>>>>>>                         +                                  break;
>>>>>>                         +                              }
>>>>>>                         +                          }
>>>>>>                         +                      }
>>>>>>                         +                      for (; nextFocus>= 0; nextFocus--) {
>>>>>>                         +                          JComponent c = (JComponent) v.elementAt(nextFocus);
>>>>>>                         +                          if (c.isShowing()&&  c.isEnabled()) {
>>>>>>                         +                              break;
>>>>>>                         +                          }
>>>>>>                         +                      }
>>>>>>                         +                      if (nextFocus>= 0) {
>>>>>>                         +                          JComponent tmpc = (JComponent) v.elementAt(nextFocus);
>>>>>>                         +                          // Next is the hack for this accessibility:
>>>>>>                         +                          // For general Buttons, do not press them, but request focus only.
>>>>>>                         +                          // For special buttons like JMenu, needs press.
>>>>>>                         +                          // If it is not a button, let the component handles by itself.
>>>>>>                         +                          if (!(tmpc instanceof javax.swing.AbstractButton)){
>>>>>>                         +                        	   fireBinding(tmpc, ks, e, pressed);
>>>>>>                         +                              if (e.isConsumed())
>>>>>>                         +                            	    return true;
>>>>>>                         +                          }
>>>>>>                         +                          if (tmpc instanceof JMenu ) {
>>>>>>                         +                              fireBinding(tmpc, ks, e, pressed);
>>>>>>                         +                              tmpc.requestFocusInWindow();
>>>>>>                         +                              if (e.isConsumed())
>>>>>>                         +                                  return true;
>>>>>>                         +                          } else {
>>>>>>                         +                              boolean result = tmpc.requestFocusInWindow();
>>>>>>                         +                              e.consume();
>>>>>>                         +                              return result;
>>>>>>                         +                          }
>>>>>>                         +                      }
>>>>>>                         +                      // If it is not handled here, default behavior is selecting the last.
>>>>>>                         +                      }
>>>>>>                         +                 }
>>>>>>                         +
>>>>>>                         +
>>>>>>                                            // There is no well defined order for WHEN_IN_FOCUSED_WINDOW
>>>>>>                                            // bindings, but we give precedence to those bindings just
>>>>>>                                            // added. This is done so that JMenus WHEN_IN_FOCUSED_WINDOW
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                         2011/4/1 Sean Chou
>>>>>>                         <zhouyx at linux.vnet.ibm.com
>>>>>>                         <mailto:zhouyx at linux.vnet.ibm.com>>
>>>>>>
>>>>>>                             Hi all,
>>>>>>
>>>>>>                                In daily use, we may encounter a
>>>>>>                             problem of mnemonic key: there may be
>>>>>>                             several
>>>>>>                             controls want the same key to be set
>>>>>>                             as mnemonic key. It is not common but
>>>>>>                             it does exist.
>>>>>>
>>>>>>                                Current openjdk implementation
>>>>>>                             allows users to set a same mnemonic
>>>>>>                             key for
>>>>>>                             different controls; but during the
>>>>>>                             execution, when the mnemonic key is
>>>>>>                             pressed,
>>>>>>                             the last control always gets the
>>>>>>                             action. Users are not able to touch
>>>>>>                             other controls with
>>>>>>                             that mnemonic key. This may confuse them.
>>>>>>
>>>>>>                                If all the controls with the same
>>>>>>                             mnemonic key can be accessed through, for
>>>>>>                             example, when the mnemonic key is
>>>>>>                             pressed, the focus is moved to the
>>>>>>                             last control,
>>>>>>                             and when the mnemonic key is pressed
>>>>>>                             again, the focus is moved to the
>>>>>>                             second control
>>>>>>                             with that mnemonic, it will give user
>>>>>>                             the choice to select other controls.
>>>>>>
>>>>>>                                Here is an example for the case:
>>>>>>
>>>>>>                             package test;
>>>>>>
>>>>>>                             import java.awt.BorderLayout;
>>>>>>                             import java.awt.Container;
>>>>>>                             import javax.swing.ButtonGroup;
>>>>>>                             import javax.swing.JFrame;
>>>>>>                             import javax.swing.JRadioButton;
>>>>>>
>>>>>>                             public class TestFocus extends JFrame {
>>>>>>                             public TestFocus() {
>>>>>>                             Container pane = getContentPane();
>>>>>>                             pane.setLayout(new BorderLayout());
>>>>>>                             JRadioButton btn1,btn2,btn3;
>>>>>>                             btn1 = new JRadioButton("Yes");
>>>>>>                             btn1.setMnemonic('Y');
>>>>>>                             btn2 = new JRadioButton("Yup");
>>>>>>                             btn2.setMnemonic('Y');
>>>>>>                             btn3 = new JRadioButton("No");
>>>>>>                             btn3.setMnemonic('N');
>>>>>>                             btn3.setSelected(true);
>>>>>>                             ButtonGroup group = new ButtonGroup();
>>>>>>                             group.add(btn1);
>>>>>>                             group.add(btn2);
>>>>>>                             group.add(btn3);
>>>>>>                             pane.add(btn1,BorderLayout.NORTH);
>>>>>>                             pane.add(btn2,BorderLayout.CENTER);
>>>>>>                             pane.add(btn3,BorderLayout.SOUTH);
>>>>>>                             setSize(200,200);
>>>>>>                             setVisible(true);
>>>>>>                             setDefaultCloseOperation(EXIT_ON_CLOSE);
>>>>>>                             }
>>>>>>                             public static void main(String[] args) {
>>>>>>                             new TestFocus();
>>>>>>                             }
>>>>>>                             }
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                             -- 
>>>>>>                             Best Regards,
>>>>>>                             Sean Chou
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                         -- 
>>>>>>                         Best Regards,
>>>>>>                         Sean Chou
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                     -- 
>>>>>>                     Best Regards,
>>>>>>                     Sean Chou
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                 -- 
>>>>>                 Best Regards,
>>>>>                 Sean Chou
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>             -- 
>>>>             Best Regards,
>>>>             Sean Chou
>>>>
>>>
>>>
>>>
>>>
>>>         -- 
>>>         Best Regards,
>>>         Sean Chou
>>>
>>
>>
>>
>>
>>     -- 
>>     Best Regards,
>>     Sean Chou
>>
>
>
>
>
> -- 
> Best Regards,
> Sean Chou
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111008/4fdbf071/attachment-0001.html 

From neugens.limasoftware at gmail.com  Sat Oct  8 08:38:44 2011
From: neugens.limasoftware at gmail.com (=?utf-8?B?bmV1Z2Vucy5saW1hc29mdHdhcmVAZ21haWwuY29t?=)
Date: Sat, 08 Oct 2011 08:38:44 -0700
Subject: <Swing Dev>
	=?utf-8?q?A_proposal_for_a_behavior_change_about_mnem?=
	=?utf-8?q?onic_key?=
Message-ID: <4e906e85.4e2ae70a.0bec.2b1a@mx.google.com>

I believe that native look and feel should mandate the different  keybindings, the cross platform look and feel should behave in a specified way, that doesn't need to be necessarily the same as the underlying platform, although this should be user configurable in a property though (perhaps saved in the preferences), because it's indeed an area if great confusion for the users.

Mario

----- Reply message -----
Da: "Pavel Porvatov" <pavel.porvatov at oracle.com>
Data: sab, ott 8, 2011 04:35
Oggetto: <Swing Dev> A proposal for a behavior change about mnemonic key
A: <zhouyx at linux.vnet.ibm.com>
Cc: "swing-dev at openjdk.java.net" <swing-dev at openjdk.java.net>


Hi Sean,
> Hi Pavel,
>
>    Your observation is right, but I can't agree with the conclusion. 
> Windows and
> GTK behave differently about how to close an opened menu. Under GTK, press
> "alt" can not close an opened menu, so, the "esc" is used to close it; 
> while
> windows performs more friendly, when mnemonic key is pressed again, 
> the first
> opened menu is closed automatically. This is totally about how to 
> close an
> opened menu, and it doesn't change the fact that menus with same mnemonic
> key are iterated.
>
>    On the other side, swing implementation doesn't follow GTK's 
> behavior about
> how to close the menu at all. Open the swingset2 and you can find its 
> behavior
> is the same with windows. Press "alt+f" and then press "alt+l" will 
> open the
> "look and feel" menu instead of GTK's "alt+f", "esc", and "alt+l".
>
>    So, I think GTK's behavior about "use esc to close an opened menu" 
> is not
> user friendly and we can ignore it, while GTK's "iterate over menus 
> with same
> mnemonic key" is better than current java implementation and we can add
> this feature. And if a user wants to use GTK's key sequence "alt+f", 
> "esc",
> "alt+l", it is also functional.
>
>    So I think this enhancement will help keep the behavior same with 
> both these
> platforms, how do you think?
Sounds reasonable and I don't object now to the decision. Does anybody 
have ideas (e.g. objections) about the new functionality?

I glanced at your patch and have the following comments:
1. Could you please file CR about the problem
2. A test is needed (I think it's possible to write an automatic one)
3. Could you please correct the new code to obey our code standards 
(aligning, spacing, mandatory braces in if/else conditions and others)

If possible send patch as a webrev, please.

Thanks, Pavel

>
> 2011/9/21 Pavel Porvatov <pavel.porvatov at oracle.com 
> <mailto:pavel.porvatov at oracle.com>>
>
>     Hi Sean,
>
>     I found out that Windows and GTK works in different ways (I used
>     your apps):
>
>     1. When Alt+i is pressed several times:
>     In Windows focus moves between items
>     In Ubuntu focus stays at the initially selected item
>
>     2. When sequence Alt+i and Escape pressed several times
>     In Windows the first menu item is selected
>     In Ubuntu after every sequence the next item is selected
>
>     In such case we should use different strategies for different
>     platforms...
>
>
>     Regards, Pavel
>
>>     Hi Pavel,
>>
>>         I just tested linux gtk platform.  With gtk2+, ubuntu linux
>>     with kernel 2.6.38, xfce, x86_32.
>>     I set four menus with mnemonic "i". Press "alt+i" will travel
>>     through four menus. The difference
>>     is that each menu must be closed with "esc" before "alt+i" opens
>>     the next one.
>>
>>         So press "alt+i" opens "File", and press "esc" to close it;
>>         then press "alt+i" opens "Edit", and press "esc" to close it;
>>         ... for next menu with mnemonic "i"
>>
>>     I attached the test application and its ui file. If it is
>>     blocked, please use
>>     this link:
>>     https://docs.google.com/leaf?id=0B8kRxsymP7imOGU1NjhiM2ItMGQ5Ni00NWNhLWJmMDQtZjZiZmQzN2U4ZGUw&hl=en_US
>>     <https://docs.google.com/leaf?id=0B8kRxsymP7imOGU1NjhiM2ItMGQ5Ni00NWNhLWJmMDQtZjZiZmQzN2U4ZGUw&hl=en_US>
>>
>>     Ubuntu x86_32 should work.
>>
>>
>>     So, I think both windows and linux gtk have supported traversal
>>     of same mnemonic keyed
>>     items already.
>>
>>
>>     2011/9/14 Pavel Porvatov <pavel.porvatov at oracle.com
>>     <mailto:pavel.porvatov at oracle.com>>
>>
>>         Hi Sean,
>>>         Hi Pavel,
>>>
>>>             Let's see if this time works. The attachement just
>>>         contains the exe file written by C#, the application is very
>>>         simple, I just drag a menu to the default WinForm in VS2003.
>>>             Please change the extension from exe1 to exe after unzip
>>>         as gmail doesn't allow exe file to be sent.
>>         Yes, I see. And what about other platforms/lafs? Your patch
>>         affects behavior of all lafs. So we must be sure, that such
>>         behavior is correct for every supported platform...
>>
>>         Regards, Pavel
>>
>>>
>>>         2011/9/13 Pavel Porvatov <pavel.porvatov at oracle.com
>>>         <mailto:pavel.porvatov at oracle.com>>
>>>
>>>             Hi Sean,
>>>
>>>             I think the attached sample was removed because I didn't
>>>             get any attachments...
>>>
>>>             Regards, Pavel
>>>
>>>>             Hi Pavel,
>>>>
>>>>                I found C# Form application treats Mnemonics in menu
>>>>             in this way. I attached the sample
>>>>             application. Press alt+i will iterate over three menu.
>>>>
>>>>             2011/9/13 Pavel Porvatov <pavel.porvatov at oracle.com
>>>>             <mailto:pavel.porvatov at oracle.com>>
>>>>
>>>>                 Hi Sean,
>>>>>                 Hi,
>>>>>
>>>>>               
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111008/af2bad31/attachment.html 

From littlee at linux.vnet.ibm.com  Sun Oct  9 00:50:27 2011
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Sun, 09 Oct 2011 15:50:27 +0800
Subject: <Swing Dev> Unexpected NullPointerException by endComposition()
In-Reply-To: <4E901AD3.9020805@oracle.com>
References: <4E784792.7050202@linux.vnet.ibm.com> <4E79F8E4.8030509@oracle.com>
	<4E7AD3E9.7020704@linux.vnet.ibm.com>
	<1316683094.13161.4.camel@chalkhill>
	<4E817E18.5020209@linux.vnet.ibm.com> <4E8982FC.2030605@oracle.com>
	<4E89B668.6020100@linux.vnet.ibm.com> <4E8EC246.6050409@oracle.com>
	<4E8F1AF9.1010205@linux.vnet.ibm.com> <4E901AD3.9020805@oracle.com>
Message-ID: <4E915243.6080304@linux.vnet.ibm.com>

On 10/08/2011 05:41 PM, Pavel Porvatov wrote:
> Hi Charles,
>> On 10/07/2011 05:11 PM, Pavel Porvatov wrote:
>>> Hi Charles,
>>>> On 10/03/2011 05:40 PM, Pavel Porvatov wrote:
>>>>> Hi Charles,
>>>>>> On 09/22/2011 05:18 PM, Neil Richards wrote:
>>>>>>> On Thu, 2011-09-22 at 14:21 +0800, Charles Lee wrote:
>>>>>>>> Hi guys,
>>>>>>>>
>>>>>>>> The webrev is attached.
>>>>>>> For ease of review, I've uploaded the webrev to 
>>>>>>> cr.openjdk.java.net [1]
>>>>>>>
>>>>>>> Regards, Neil
>>>>>>>
>>>>>>> [1] http://cr.openjdk.java.net/~ngmr/6938583/webrev.00
>>>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> Any update about this issue? Is the idea workable?
>>>>>>
>>>>> Can you explain why should we consume right clicks but not left 
>>>>> ones? (May be there are other test cases when NPE is thrown... ) 
>>>>> And why do you consume event? (May be it hides NPE but breaks 
>>>>> functionality)
>>>>>
>>>>> Thanks, Pavel
>>>>>
>>>>
>>>> 1. When right clicks, it suppose to show a manu on where you click. 
>>>> But I guess the demo (CodePointIM) is not suppose to show that 
>>>> (what will be show when use CodePointIM and right click? IIRC, I 
>>>> tried the normal input and right click but get nothing)
>>>> 2. If point 1 is true, consuming the right click in the CodePointIM 
>>>> is the easiest way to fix it and less error-prone comparing with 
>>>> fixing in the jdk...
>>>> 3. Consuming left click will disable the movement of the input 
>>>> place by clicking, I guess...
>>>>
>>> There is no information about popup menu in the bug description. The 
>>> problem is that endComposition() throws NPE if Input Method is 
>>> turned on and the program is in composition mode. If you apply your 
>>> fix and change BUTTON3 into BUTTON2 in the MouseEventTest2 test (see 
>>> bug description), then NPE will be thrown with your patch as well...
>>>
>>> Regards, Pavel
>>
>> Why change Button3 to Button2? Does Button3 reflect the right click?
> No, Button2 is the middle button. But if you use Button2 in the 
> MouseEventTest2 the test is still valid and it shouldn't throw any 
> unexpected exceptions. But if you apply your fix and replace Button3 
> by Button2 in the MouseEventTest2 test, run the MouseEventTest2 test 
> and use testcase from the bug description (of course in step 5 you 
> should use the middle mouse button now) you'll get NPE
>>
>> NPE was occurred because the component is null. Component becomes 
>> null because the default carret, IIRC, has been changed when it 
>> receive the right click event. It is the right behavior, if I 
>> understand correctly. So I am trying to disable the right click event 
>> if the demo does not suppose some menu should going to show up.
>>
> I still don't understand where do you see popup menu? I wrote about 
> the test from 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6938583 and there 
> is no popup there...
>
> Regards, Pavel
I got your point. What about this solution:
If in the compose mode, endCompositoin just sendComposedText instead of 
sendCommittedText.

The patch is attached

-- 
Yours Charles

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.v2
Url: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111009/767f7979/attachment.ksh 

From zhouyx at linux.vnet.ibm.com  Mon Oct 10 00:38:29 2011
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Mon, 10 Oct 2011 15:38:29 +0800
Subject: <Swing Dev> DnD fails with JTextArea and JTextField
In-Reply-To: <CAOo=rxWazVk-_xQJhyUqeTd45MWT_zvMA5CoZ2=Z7pE_Z3hxiA@mail.gmail.com>
References: <BANLkTim=cSTyZONavk-QfC0CU9EMRQ5H+w@mail.gmail.com>
	<4DDF3769.2040709@oracle.com>
	<BANLkTi=OnDdss48WR0wvg4pi6oDDrUxqZA@mail.gmail.com>
	<4DECEBD0.2030804@oracle.com>
	<CAOo=rxUyH0J5z7O+b7xLZa=H+r9-4cfCc=CmpXvbMOq9eiWTGQ@mail.gmail.com>
	<4E6F284B.1060601@oracle.com>
	<CAOo=rxU6G6-da+TOxBQyfwfaa_L=sEVTr45cT2OG+KogGE0Keg@mail.gmail.com>
	<4E71B608.7090201@oracle.com>
	<CAOo=rxWsiy9DqBmMAfLSGBL_frqcbsXaPWQtGr2W_RokObsZWA@mail.gmail.com>
	<4E787587.8040802@oracle.com>
	<CAOo=rxV5Q1MbY9yYQ1Hpg6XKe6bsn8OgUUaBSA5bDUDxoxppqQ@mail.gmail.com>
	<4E803E9C.5050303@oracle.com>
	<CAOo=rxXDio4s-u+V6eLVMWnqf9dpLFmWYCCRN1CCzAAvzOHUiw@mail.gmail.com>
	<4E8057B6.20804@oracle.com>
	<CAOo=rxX8o0hSpnjyijZoED1L7GvbNDFLNvp9Q0+pbeDCJnBG-w@mail.gmail.com>
	<4E81F3C5.6080805@oracle.com>
	<CAOo=rxX05BYPDTkJnGijyqVerV04fO3SwT2hZGFETQyG9kapuQ@mail.gmail.com>
	<4E8494F8.60306@oracle.com>
	<CAOo=rxWazVk-_xQJhyUqeTd45MWT_zvMA5CoZ2=Z7pE_Z3hxiA@mail.gmail.com>
Message-ID: <CAOo=rxVrV+yyN6ipyR7prQu_wtHJhgnPLOYbqn_3rD5mJnAGPQ@mail.gmail.com>

Hi,

    One more: I put the testcase under javax/swing/JTextArea because the bug
is filed toward it.

On Mon, Oct 10, 2011 at 3:35 PM, Sean Chou <zhouyx at linux.vnet.ibm.com>wrote:

> Hi Pavel, Artem,
>
>    I run jtreg on another machine and it passes. The attachment is the
> testcase and patch.
>
> The following modification to testcase are done as suggested last time:
> 1. Copyright in agreed form (the ibm info)
> 2. Date in copyright
> 3. All swing code in EDT
> 4. Use realSync()
>
> Please have a look, thanks.
>
>
> On Thu, Sep 29, 2011 at 11:55 PM, Artem Ananiev <artem.ananiev at oracle.com>wrote:
>
>>
>> On 9/28/2011 9:48 PM, Sean Chou wrote:
>>
>>> Hi Artem,
>>>
>>>     I can not validate the testcase after I changed to use realSynch,
>>> it always fails with throwing an exception.
>>>     Testcase test\javax\swing\JSlider\**6848475\bug6848475.java  fails
>>> on
>>> my machine with timeoutexception as
>>> well.
>>>     I run the test in its directory with command like this:
>>> jtreg -verbose:all -testjdk:...j2sdk/ bug6848475.java
>>>
>>
>> It may be a bug with realSync() implementation, possibly related to
>>
>> 6421984: realSync throws InfiniteLoop some times.
>>
>> Thanks,
>>
>> Artem
>>
>>  2011/9/28 Artem Ananiev <artem.ananiev at oracle.com
>>> <mailto:artem.ananiev at oracle.**com <artem.ananiev at oracle.com>>>
>>>
>>>
>>>
>>>    On 9/27/2011 5:19 AM, Sean Chou wrote:
>>>
>>>        Hi Pavel,
>>>
>>>             Is toolkit.realSync() doing the job of "sleep 10s and throw
>>> an
>>>        timeout exception" ?
>>>
>>>
>>>    Definitely, not. SunToolkit.realSync() is what Robot.waitForIdle()
>>>    was initially supposed to be: this call should wait until all the
>>>    pending events (native, Java) to be processed. Sometimes, however,
>>>    it fails to do so, e.g. when native events are turned into Java
>>>    events, and Java event handlers call more native methods - then the
>>>    TimeoutException is thrown.
>>>
>>>    Thanks,
>>>
>>>    Artem
>>>
>>>        I found the main thread exit after realSynch is invoked. Should
>>>        I catch
>>>        that exception?
>>>        bug6848475.java seems not catching it.
>>>
>>>
>>>        2011/9/26 Pavel Porvatov <pavel.porvatov at oracle.com
>>>        <mailto:pavel.porvatov at oracle.**com <pavel.porvatov at oracle.com>>
>>>        <mailto:pavel.porvatov at oracle.**__com
>>>
>>>        <mailto:pavel.porvatov at oracle.**com <pavel.porvatov at oracle.com>
>>> >>>
>>>
>>>            __
>>>
>>>            Hi Sean,
>>>
>>>                Hi Pavel,
>>>
>>>                   Thanks for new comments. I was looking
>>>                at test\javax\swing\JTextArea\__**6940863
>>>
>>>                and copied the copyright from there, and just put the
>>>                initialization part of the swing
>>>                code into EDT. I didn't find realSynch in Toolkit class
>>>            so used
>>>                synch. I'll modify
>>>                that.
>>>
>>>            The realSync is a SunToolkit method.
>>>
>>>                   About the first comment, do you mean to put the
>>>            testcase and
>>>                the fix together
>>>                in a webrev ?
>>>
>>>            Yep! It's hard to reconstruct fix from different mails.
>>>        Don't forget
>>>            to select an appropriate folder for the test...
>>>
>>>            Thanks, Pavel
>>>
>>>
>>>                2011/9/26 Pavel Porvatov <pavel.porvatov at oracle.com
>>>            <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >
>>>            <mailto:pavel.porvatov at oracle.**__com
>>>
>>>            <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >>>
>>>
>>>
>>>                    Hi Sean,
>>>
>>>                        Hi Pavel,
>>>
>>>                            Thanks for the comments. I modified the
>>> testcase
>>>                        according to the comments,
>>>                        please have a look at it again.
>>>                            I tried to run with jtreg and it runs well.
>>>
>>>                    Looks much better. Still have several comments:
>>>
>>>                    1. Could you please sent complete fix as a webrev,
>>>            but not
>>>                    parts of the fix as a single file?
>>>
>>>                    2. Date of copyright...
>>>
>>>                    3. You are still using Swing components on non-EDT
>>>            thread. As
>>>                    I wrote before take a look at the
>>>                    test\javax\swing\JSlider\__**6848475\bug6848475.java
>>>
>>>            test...
>>>
>>>                    4. Use toolkit.realSync() instead of toolkit.sync().
>>>            BTW: as
>>>                    described in javadoc realSync cannot be invoked on
>>>            the EDT
>>>                    thread...
>>>
>>>                    Regards, Pavel
>>>
>>>                    P.S. Sorry for my stubborn =) But on some machines not
>>>                    accurate tests actually fail (e.g. on Solaris).
>>>            Therefore
>>>                    later we must fix tests and that's a really boring
>>>            task...
>>>
>>>
>>>
>>>                        2011/9/20 Pavel Porvatov
>>>                <pavel.porvatov at oracle.com
>>>                <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >
>>>                <mailto:pavel.porvatov at oracle.**__com
>>>
>>>                <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >>>
>>>
>>>
>>>                            Hi Sean,
>>>
>>>                            The have several comments :
>>>
>>>                            1. Could you please read
>>>                http://openjdk.java.net/jtreg/
>>>                            is it possible run your test via jtreg?
>>>
>>>                            2. There is no copyright in the begin of test
>>>
>>>                            3. There are no jtreg tags
>>>
>>>                            4. All Swing code must be initialized on the
>>>                EDT thread
>>>
>>>                            5. Keep test minimal as possible, please. It
>>>                helps other
>>>                            people to understand your code.... E.g.
>>>                there is no need
>>>                            to create JButton with listener.
>>>
>>>                            6. Note that the "frame.setVisible(true)"
>>>                doesn't
>>>                            guarantee that after that line Frame is
>>>                visible, you
>>>                            should use toolkit.realSync() here
>>>
>>>                            7. No TODO, please
>>>
>>>                            8. Are you sure your test should pass if
>>>                exceptions
>>>                            occurs (see your catch blocks)
>>>
>>>                            Please take a look at other tests and use
>>>                them as a good
>>>                            examples....
>>>
>>>                            Regards, Pavel
>>>
>>>
>>>                                Hi Pavel,
>>>
>>>                                   I wrote a test case for the behavior
>>>                    of DefaultCaret.
>>>                                Please take a look, it is
>>>                                attached.
>>>
>>>
>>>
>>>                                2011/9/15 Pavel Porvatov
>>>                    <pavel.porvatov at oracle.com
>>>                    <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >
>>>                    <mailto:pavel.porvatov at oracle.**__com
>>>
>>>                    <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >>>
>>>
>>>
>>>                                    Hi Sean,
>>>
>>>                                        Hi Pavel,
>>>
>>>                                            I'm comfortable with moving
>>>                        the checking into
>>>
>>>                          DefaultCaret#__**updateSystemSelection method.
>>>
>>>                                            About regression  test, I'm
>>>                        not sure how to
>>>                                        write, because it contains user
>>>                        operation. Can you
>>>                                        give me a similar test so I can
>>>                        write one for this bug?
>>>
>>>                                    Yes, you can find a lot examples in
>>> the
>>>                                    test/javax/swing directory by word
>>>                    Robot, e.g.
>>>
>>>                      test\javax\swing\JSlider\__**
>>> 6848475\bug6848475.java.
>>>
>>>                                    One hint: use reflection ONLY if
>>>                    there are no
>>>                                    another ways to write a test...
>>>
>>>                                    Regards, Pavel
>>>
>>>
>>>                                        2011/9/13 Pavel Porvatov
>>>                        <pavel.porvatov at oracle.com
>>>                        <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >
>>>                        <mailto:pavel.porvatov at oracle.**__com
>>>
>>>                        <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >>>
>>>
>>>
>>>                                            Hi Sean,
>>>
>>>                                                Hi Pavel ,
>>>
>>>                                                    I'm sorry I didn't
>>>                            make update for this
>>>                                                bug for a long time, and
>>>                            here is some
>>>                                                recent investigation.
>>>                            The scenario is as follows:
>>>
>>>                                                Suppose we are dragging
>>>                            "abcde" over TextField
>>>                                                tf, which have "hello
>>>                            dragging" as
>>>                                                its content. When we are
>>>                            dragging from start
>>>                                                to end, there is a
>>>                            cursor moving from
>>>                            "h" to "g", which means the place to insert
>>>                            "abcde" if we drop it.
>>>                                                When we dragging "abcde"
>>>                            exit tf, there will
>>>                                                be a dragExit event, the
>>>                            tf needs to
>>>                                                restore its original
>>>                            status after we drag out.
>>>                                                Eg. if its cursor is
>>>                            between "h" and
>>>                            "e" in "hello", which appears like "h|ello",
>>>                                                when we are dragging
>>>                            over it, it may like
>>>                            "hello dr|agging", and when drag exit, it
>>>                                                needs to be "h|ello"
>>> again.
>>>                                                So in dragExit handler,
>>>                            it calls
>>>
>>>                              javax.swing.TransferHandler.__**cleanup(false),
>>> which
>>>
>>>                                                means only to restore
>>>                            the original state.
>>>                                                cleanup calls
>>>
>>>                              javax.swing.text.__**JTextComponent.setDropLocation
>>> to
>>>
>>>                                                set the cursor to original
>>>                                                position. And
>>>                            setDropLocation calls
>>>                                                DefaultCaret.setDot and
>>>                            DefaultCaret.moveDot
>>>                                                to set the state.
>>>                                                The problem is moveDot
>>>                            doesn't know this is
>>>                                                just to restore the
>>>                            original state,
>>>                                                it treats the invocation
>>>                            as an action to
>>>                                                select something. And it
>>>                                                calls
>>> updateSystemSelection
>>>                                                which will
>>>                                                call
>>>                            java.awt.datatransfer.__**
>>> Clipboard.setContent.
>>>
>>>                                                And the selected content
>>>                                                is changed from "abcde"
>>>                            to the original
>>>                                                selected part of "hello
>>>                            dragging", then
>>>                                                the drop operation finds
>>>                            it is not the string
>>>                                                dragged and nothing is
>>>                            dropped.
>>>
>>>                                                So I made a simple
>>>                            patch(attached) . It just
>>>                                                check if the textField
>>>                            owns focus
>>>                                                before
>>>                            updateSystemSelection, if it is not
>>>                                                focused, it does not
>>>                            treat the moveDot as
>>>                                                a selection action and
>>>                            does not
>>>                                                call
>>>                            Clipboard.setContent.  This works on Linux,
>>>                                                however, DefaultCaret is
>>>                            shared by Linux and
>>>                                                Windows while windows
>>>                            doesn't have
>>>                                                this problem. So I don't
>>>                            think this is a
>>>                                                correct patch, but it
>>>                            brings my question.
>>>
>>>                                                I think it is strange
>>>                            for DefaultCaret to use
>>>                                                setDot and moveDot to
>>>                            restore
>>>                                                original state,
>>>                            especially moveDot will cause
>>>                                                an updateSystemSelection
>>>                            operation,
>>>                                                which makes moveDot much
>>>                            like an action from
>>>                                                user instead of just
>>>                            restoring state.
>>>
>>>                                                I'm not sure why it
>>>                            works well on windows, but
>>>                                                I don't think it is
>>>                            right to call
>>>                                                updateSystemSelection or
>>>                            it is not right to
>>>                                                use setDot and moveDot
>>>                            to restore
>>>                                                the original state. Is
>>>                            there any reason for that ?
>>>
>>>                                            Thanks for the patch! I
>>>                        believe you are right
>>>                                            and we shouldn't update
>>>                        system selection
>>>                                            clipboard when the component
>>>                        doesn't have
>>>                                            focus. I'd like to modify
>>>                        your fix and move
>>>                                            checking into the
>>>
>>>                          DefaultCaret#__**updateSystemSelection method:
>>>
>>>                                              if (this.dot != this.mark
>>>                        && component !=
>>>                                            null && component.hasFocus())
>>> {
>>>
>>>                                            We also must write
>>>                        regression tests for fixes
>>>                                            if possible, so an automatic
>>>                        test is needed as
>>>                                            well. Could you please write
>>>                        a test for the fix?
>>>
>>>
>>>                         > I'm not sure why it works well on windows,
>>>                                            That's because Windows
>>>                        doesn't have system
>>>                                            selection clipboard...
>>>
>>>
>>>                         > Is there any reason for that ?
>>>                                            No, that's a just bug...
>>>
>>>                                            Regards, Pavel
>>>
>>>
>>>                                                2011/6/6 Pavel Porvatov
>>>                            <pavel.porvatov at oracle.com
>>>                            <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >
>>>                            <mailto:pavel.porvatov at oracle.**__com
>>>
>>>                            <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >>>
>>>
>>>
>>>                                                    Hi Sean,
>>>
>>>                                                        Hi,
>>>
>>>                                                        I reported, but
>>>                                the system doesn't reply
>>>                                                        me a bug number.
>>>                                It says "will give me
>>>                                                        email",
>>>                                                        but I haven't
>>>                                got one yet. Is this the
>>>                                                        right process,
>>>                                or I might make a problem
>>>                                                        when
>>>                                                        reporting?
>>>
>>>                                                    I don't know why the
>>>                            system didn't report
>>>                                                    bug ID, but your bug
>>>                            was filed
>>>                                                    successfully. You
>>>                            can find it here:
>>>                            http://bugs.sun.com/__**
>>> bugdatabase/view_bug.do?bug___**id=7049024<http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=7049024>
>>>
>>>                            <http://bugs.sun.com/**
>>> bugdatabase/view_bug.do?bug_**id=7049024<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7049024>
>>> >
>>>
>>>                                                    Regards, Pavel
>>>
>>>
>>>                                                        2011/5/27 Pavel
>>>                                Porvatov
>>>                                <pavel.porvatov at oracle.com
>>>                                <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >
>>>                                <mailto:pavel.porvatov at oracle.**__com
>>>
>>>                                <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>>> >>>
>>>
>>>
>>>                                                            Hi Sean,
>>>
>>>                                                                Hi all,
>>>
>>>                                                                    I
>>>                                    have a testcase related to DnD
>>>                                                                failure
>>>                                    with JTextArea and
>>>
>>>                                      JTextField on linux. The
>>>                                                                testcase
>>>                                    is as follows:
>>>
>>>                                                                /*
>>>                                                                 *
>>>                                    DnDTest.java
>>>                                                                 */
>>>                                                                import
>>>                                    java.awt.Color;
>>>                                                                import
>>>                                    java.awt.Component;
>>>                                                                import
>>>                                    java.awt.Dimension;
>>>                                                                import
>>>                                    java.awt.FlowLayout;
>>>                                                                import
>>>                                    java.awt.Frame;
>>>                                                                import
>>>                                    java.awt.event.WindowAdapter;
>>>                                                                import
>>>                                    java.awt.event.WindowEvent;
>>>
>>>                                                                import
>>>                                    javax.swing.JTextArea;
>>>                                                                import
>>>                                    javax.swing.JTextField;
>>>
>>>
>>>                                                                public
>>>                                    class DnDTest extends Frame {
>>>                                                                Component
>>> c;
>>>                                                                public
>>>                                    DnDTest() {
>>>
>>>                                      super("Single Frame --- AWT Frame");
>>>
>>>                                      super.setBackground(Color.__**
>>> gray);
>>>
>>>                                                                // set
>>>                                    layout here.
>>>
>>>                                      setLayout(new FlowLayout());
>>>                                                                c = new
>>>                                    JTextArea("JTextArea
>>>
>>>  component");
>>>
>>>                                      c.setPreferredSize(new
>>>
>>>                                      Dimension(400, 100));
>>>                                                                add(c);
>>>                                                                c = new
>>>                                    JTextField("JTextField
>>>
>>>                                      component(No IM)");
>>>
>>>                                      c.setPreferredSize(new
>>>
>>>                                      Dimension(400, 20));
>>>                                                                add(c);
>>>
>>>                                      addWindowListener(new
>>>                                    WindowAdapter() {
>>>                                                                public
>>> void
>>>
>>>                                      windowClosing(WindowEvent event) {
>>>
>>>                                      System.exit(0);
>>>                                                                }
>>>                                                                });
>>>
>>>                                      setSize(850, 360);
>>>
>>>                                      setVisible(true);
>>>                                                                }
>>>                                                                public
>>>                                    static void main(String[] args) {
>>>                                                                new
>>>                                    DnDTest();
>>>                                                                }
>>>                                                                }
>>>
>>>
>>>
>>>                                      Reproduce steps:
>>>                                                                1. Run
>>>                                    the testcase with b143
>>>                                                                2. Open
>>>                                    a new file with gedit and
>>>                                                                input
>>>                                    some words like "abcde"
>>>                                                                3. Drag
>>>                                    "abcde" into JTextField and
>>>                                                                drop it
>>>                                    there.
>>>                                                                4. Once
>>>                                    more, drag "abcde" into
>>>
>>>                                      JTextField and then move out of the
>>>                                                                Frame
>>>                                    (keep draging) and drag
>>>                                                                into
>>>                                    JTextField again and drop it.
>>>
>>>
>>>  Expectation:
>>>                                                                The
>>>                                    second DnD inputs another
>>>                                    "abcde" into JTextField.
>>>
>>>                                                                Result:
>>>                                                                The
>>>                                    second DnD inputs nothing
>>>                                                                into
>>>                                    JTextField.
>>>
>>>                                                            Yes, looks
>>>                                like a bug. The test case
>>>                                                            works on
>>>                                Windows as expected.
>>>
>>>
>>>
>>>                                      Investigation:
>>>                                                                The
>>>                                    JTextArea as well has this
>>>                                                                problem,
>>>                                    and in step 4, if we drag
>>>                                    "abcde" over JTextField and then
>>>                                                                drop
>>>                                    into JTextArea, nothing
>>>                                                                is input
>>>                                    into JTextArea either.
>>>                                                                However,
>>>                                    if "abcde" is drag
>>>                                                                into
>>>                                    JTextField or JTextArea
>>>                                                                directly
>>>                                    or when JTextArea/Field are
>>>                                                                empty as
>>>                                    in step 2, it works.
>>>
>>>
>>>                                                                Are
>>>                                    there any comments? And can
>>>                                                                anyone
>>>                                    file a bug for it please ?
>>>
>>>                                                            Anybody can
>>>                                file a bug,
>>>                                http://bugreport.sun.com/__**bugreport/<http://bugreport.sun.com/__bugreport/>
>>>
>>>                                <http://bugreport.sun.com/**bugreport/<http://bugreport.sun.com/bugreport/>
>>> >
>>>
>>>                                                            Regards, Pavel
>>>
>>>
>>>
>>>
>>>                                                        --
>>>                                                        Best Regards,
>>>                                                        Sean Chou
>>>
>>>
>>>
>>>
>>>
>>>                                                --
>>>                                                Best Regards,
>>>                                                Sean Chou
>>>
>>>
>>>
>>>
>>>
>>>                                        --
>>>                                        Best Regards,
>>>                                        Sean Chou
>>>
>>>
>>>
>>>
>>>
>>>                                --
>>>                                Best Regards,
>>>                                Sean Chou
>>>
>>>
>>>
>>>
>>>
>>>                        --
>>>                        Best Regards,
>>>                        Sean Chou
>>>
>>>
>>>
>>>
>>>
>>>                --
>>>                Best Regards,
>>>                Sean Chou
>>>
>>>
>>>
>>>
>>>
>>>        --
>>>        Best Regards,
>>>        Sean Chou
>>>
>>>
>>>
>>>
>>> --
>>> Best Regards,
>>> Sean Chou
>>>
>>>
>
>
> --
> Best Regards,
> Sean Chou
>
>


-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111010/837ff5d0/attachment-0001.html 

From zhouyx at linux.vnet.ibm.com  Mon Oct 10 00:35:22 2011
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Mon, 10 Oct 2011 15:35:22 +0800
Subject: <Swing Dev> DnD fails with JTextArea and JTextField
In-Reply-To: <4E8494F8.60306@oracle.com>
References: <BANLkTim=cSTyZONavk-QfC0CU9EMRQ5H+w@mail.gmail.com>
	<4DDF3769.2040709@oracle.com>
	<BANLkTi=OnDdss48WR0wvg4pi6oDDrUxqZA@mail.gmail.com>
	<4DECEBD0.2030804@oracle.com>
	<CAOo=rxUyH0J5z7O+b7xLZa=H+r9-4cfCc=CmpXvbMOq9eiWTGQ@mail.gmail.com>
	<4E6F284B.1060601@oracle.com>
	<CAOo=rxU6G6-da+TOxBQyfwfaa_L=sEVTr45cT2OG+KogGE0Keg@mail.gmail.com>
	<4E71B608.7090201@oracle.com>
	<CAOo=rxWsiy9DqBmMAfLSGBL_frqcbsXaPWQtGr2W_RokObsZWA@mail.gmail.com>
	<4E787587.8040802@oracle.com>
	<CAOo=rxV5Q1MbY9yYQ1Hpg6XKe6bsn8OgUUaBSA5bDUDxoxppqQ@mail.gmail.com>
	<4E803E9C.5050303@oracle.com>
	<CAOo=rxXDio4s-u+V6eLVMWnqf9dpLFmWYCCRN1CCzAAvzOHUiw@mail.gmail.com>
	<4E8057B6.20804@oracle.com>
	<CAOo=rxX8o0hSpnjyijZoED1L7GvbNDFLNvp9Q0+pbeDCJnBG-w@mail.gmail.com>
	<4E81F3C5.6080805@oracle.com>
	<CAOo=rxX05BYPDTkJnGijyqVerV04fO3SwT2hZGFETQyG9kapuQ@mail.gmail.com>
	<4E8494F8.60306@oracle.com>
Message-ID: <CAOo=rxWazVk-_xQJhyUqeTd45MWT_zvMA5CoZ2=Z7pE_Z3hxiA@mail.gmail.com>

Hi Pavel, Artem,

   I run jtreg on another machine and it passes. The attachment is the
testcase and patch.

The following modification to testcase are done as suggested last time:
1. Copyright in agreed form (the ibm info)
2. Date in copyright
3. All swing code in EDT
4. Use realSync()

Please have a look, thanks.

On Thu, Sep 29, 2011 at 11:55 PM, Artem Ananiev <artem.ananiev at oracle.com>wrote:

>
> On 9/28/2011 9:48 PM, Sean Chou wrote:
>
>> Hi Artem,
>>
>>     I can not validate the testcase after I changed to use realSynch,
>> it always fails with throwing an exception.
>>     Testcase test\javax\swing\JSlider\**6848475\bug6848475.java  fails on
>> my machine with timeoutexception as
>> well.
>>     I run the test in its directory with command like this:
>> jtreg -verbose:all -testjdk:...j2sdk/ bug6848475.java
>>
>
> It may be a bug with realSync() implementation, possibly related to
>
> 6421984: realSync throws InfiniteLoop some times.
>
> Thanks,
>
> Artem
>
>  2011/9/28 Artem Ananiev <artem.ananiev at oracle.com
>> <mailto:artem.ananiev at oracle.**com <artem.ananiev at oracle.com>>>
>>
>>
>>
>>    On 9/27/2011 5:19 AM, Sean Chou wrote:
>>
>>        Hi Pavel,
>>
>>             Is toolkit.realSync() doing the job of "sleep 10s and throw an
>>        timeout exception" ?
>>
>>
>>    Definitely, not. SunToolkit.realSync() is what Robot.waitForIdle()
>>    was initially supposed to be: this call should wait until all the
>>    pending events (native, Java) to be processed. Sometimes, however,
>>    it fails to do so, e.g. when native events are turned into Java
>>    events, and Java event handlers call more native methods - then the
>>    TimeoutException is thrown.
>>
>>    Thanks,
>>
>>    Artem
>>
>>        I found the main thread exit after realSynch is invoked. Should
>>        I catch
>>        that exception?
>>        bug6848475.java seems not catching it.
>>
>>
>>        2011/9/26 Pavel Porvatov <pavel.porvatov at oracle.com
>>        <mailto:pavel.porvatov at oracle.**com <pavel.porvatov at oracle.com>>
>>        <mailto:pavel.porvatov at oracle.**__com
>>
>>        <mailto:pavel.porvatov at oracle.**com <pavel.porvatov at oracle.com>>>>
>>
>>            __
>>
>>            Hi Sean,
>>
>>                Hi Pavel,
>>
>>                   Thanks for new comments. I was looking
>>                at test\javax\swing\JTextArea\__**6940863
>>
>>                and copied the copyright from there, and just put the
>>                initialization part of the swing
>>                code into EDT. I didn't find realSynch in Toolkit class
>>            so used
>>                synch. I'll modify
>>                that.
>>
>>            The realSync is a SunToolkit method.
>>
>>                   About the first comment, do you mean to put the
>>            testcase and
>>                the fix together
>>                in a webrev ?
>>
>>            Yep! It's hard to reconstruct fix from different mails.
>>        Don't forget
>>            to select an appropriate folder for the test...
>>
>>            Thanks, Pavel
>>
>>
>>                2011/9/26 Pavel Porvatov <pavel.porvatov at oracle.com
>>            <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>> >
>>            <mailto:pavel.porvatov at oracle.**__com
>>
>>            <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>> >>>
>>
>>
>>                    Hi Sean,
>>
>>                        Hi Pavel,
>>
>>                            Thanks for the comments. I modified the
>> testcase
>>                        according to the comments,
>>                        please have a look at it again.
>>                            I tried to run with jtreg and it runs well.
>>
>>                    Looks much better. Still have several comments:
>>
>>                    1. Could you please sent complete fix as a webrev,
>>            but not
>>                    parts of the fix as a single file?
>>
>>                    2. Date of copyright...
>>
>>                    3. You are still using Swing components on non-EDT
>>            thread. As
>>                    I wrote before take a look at the
>>                    test\javax\swing\JSlider\__**6848475\bug6848475.java
>>
>>            test...
>>
>>                    4. Use toolkit.realSync() instead of toolkit.sync().
>>            BTW: as
>>                    described in javadoc realSync cannot be invoked on
>>            the EDT
>>                    thread...
>>
>>                    Regards, Pavel
>>
>>                    P.S. Sorry for my stubborn =) But on some machines not
>>                    accurate tests actually fail (e.g. on Solaris).
>>            Therefore
>>                    later we must fix tests and that's a really boring
>>            task...
>>
>>
>>
>>                        2011/9/20 Pavel Porvatov
>>                <pavel.porvatov at oracle.com
>>                <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>> >
>>                <mailto:pavel.porvatov at oracle.**__com
>>
>>                <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>> >>>
>>
>>
>>                            Hi Sean,
>>
>>                            The have several comments :
>>
>>                            1. Could you please read
>>                http://openjdk.java.net/jtreg/
>>                            is it possible run your test via jtreg?
>>
>>                            2. There is no copyright in the begin of test
>>
>>                            3. There are no jtreg tags
>>
>>                            4. All Swing code must be initialized on the
>>                EDT thread
>>
>>                            5. Keep test minimal as possible, please. It
>>                helps other
>>                            people to understand your code.... E.g.
>>                there is no need
>>                            to create JButton with listener.
>>
>>                            6. Note that the "frame.setVisible(true)"
>>                doesn't
>>                            guarantee that after that line Frame is
>>                visible, you
>>                            should use toolkit.realSync() here
>>
>>                            7. No TODO, please
>>
>>                            8. Are you sure your test should pass if
>>                exceptions
>>                            occurs (see your catch blocks)
>>
>>                            Please take a look at other tests and use
>>                them as a good
>>                            examples....
>>
>>                            Regards, Pavel
>>
>>
>>                                Hi Pavel,
>>
>>                                   I wrote a test case for the behavior
>>                    of DefaultCaret.
>>                                Please take a look, it is
>>                                attached.
>>
>>
>>
>>                                2011/9/15 Pavel Porvatov
>>                    <pavel.porvatov at oracle.com
>>                    <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>> >
>>                    <mailto:pavel.porvatov at oracle.**__com
>>
>>                    <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>> >>>
>>
>>
>>                                    Hi Sean,
>>
>>                                        Hi Pavel,
>>
>>                                            I'm comfortable with moving
>>                        the checking into
>>
>>                          DefaultCaret#__**updateSystemSelection method.
>>
>>                                            About regression  test, I'm
>>                        not sure how to
>>                                        write, because it contains user
>>                        operation. Can you
>>                                        give me a similar test so I can
>>                        write one for this bug?
>>
>>                                    Yes, you can find a lot examples in the
>>                                    test/javax/swing directory by word
>>                    Robot, e.g.
>>
>>                      test\javax\swing\JSlider\__**
>> 6848475\bug6848475.java.
>>
>>                                    One hint: use reflection ONLY if
>>                    there are no
>>                                    another ways to write a test...
>>
>>                                    Regards, Pavel
>>
>>
>>                                        2011/9/13 Pavel Porvatov
>>                        <pavel.porvatov at oracle.com
>>                        <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>> >
>>                        <mailto:pavel.porvatov at oracle.**__com
>>
>>                        <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>> >>>
>>
>>
>>                                            Hi Sean,
>>
>>                                                Hi Pavel ,
>>
>>                                                    I'm sorry I didn't
>>                            make update for this
>>                                                bug for a long time, and
>>                            here is some
>>                                                recent investigation.
>>                            The scenario is as follows:
>>
>>                                                Suppose we are dragging
>>                            "abcde" over TextField
>>                                                tf, which have "hello
>>                            dragging" as
>>                                                its content. When we are
>>                            dragging from start
>>                                                to end, there is a
>>                            cursor moving from
>>                            "h" to "g", which means the place to insert
>>                            "abcde" if we drop it.
>>                                                When we dragging "abcde"
>>                            exit tf, there will
>>                                                be a dragExit event, the
>>                            tf needs to
>>                                                restore its original
>>                            status after we drag out.
>>                                                Eg. if its cursor is
>>                            between "h" and
>>                            "e" in "hello", which appears like "h|ello",
>>                                                when we are dragging
>>                            over it, it may like
>>                            "hello dr|agging", and when drag exit, it
>>                                                needs to be "h|ello" again.
>>                                                So in dragExit handler,
>>                            it calls
>>
>>                              javax.swing.TransferHandler.__**cleanup(false),
>> which
>>
>>                                                means only to restore
>>                            the original state.
>>                                                cleanup calls
>>
>>                              javax.swing.text.__**JTextComponent.setDropLocation
>> to
>>
>>                                                set the cursor to original
>>                                                position. And
>>                            setDropLocation calls
>>                                                DefaultCaret.setDot and
>>                            DefaultCaret.moveDot
>>                                                to set the state.
>>                                                The problem is moveDot
>>                            doesn't know this is
>>                                                just to restore the
>>                            original state,
>>                                                it treats the invocation
>>                            as an action to
>>                                                select something. And it
>>                                                calls updateSystemSelection
>>                                                which will
>>                                                call
>>                            java.awt.datatransfer.__**
>> Clipboard.setContent.
>>
>>                                                And the selected content
>>                                                is changed from "abcde"
>>                            to the original
>>                                                selected part of "hello
>>                            dragging", then
>>                                                the drop operation finds
>>                            it is not the string
>>                                                dragged and nothing is
>>                            dropped.
>>
>>                                                So I made a simple
>>                            patch(attached) . It just
>>                                                check if the textField
>>                            owns focus
>>                                                before
>>                            updateSystemSelection, if it is not
>>                                                focused, it does not
>>                            treat the moveDot as
>>                                                a selection action and
>>                            does not
>>                                                call
>>                            Clipboard.setContent.  This works on Linux,
>>                                                however, DefaultCaret is
>>                            shared by Linux and
>>                                                Windows while windows
>>                            doesn't have
>>                                                this problem. So I don't
>>                            think this is a
>>                                                correct patch, but it
>>                            brings my question.
>>
>>                                                I think it is strange
>>                            for DefaultCaret to use
>>                                                setDot and moveDot to
>>                            restore
>>                                                original state,
>>                            especially moveDot will cause
>>                                                an updateSystemSelection
>>                            operation,
>>                                                which makes moveDot much
>>                            like an action from
>>                                                user instead of just
>>                            restoring state.
>>
>>                                                I'm not sure why it
>>                            works well on windows, but
>>                                                I don't think it is
>>                            right to call
>>                                                updateSystemSelection or
>>                            it is not right to
>>                                                use setDot and moveDot
>>                            to restore
>>                                                the original state. Is
>>                            there any reason for that ?
>>
>>                                            Thanks for the patch! I
>>                        believe you are right
>>                                            and we shouldn't update
>>                        system selection
>>                                            clipboard when the component
>>                        doesn't have
>>                                            focus. I'd like to modify
>>                        your fix and move
>>                                            checking into the
>>
>>                          DefaultCaret#__**updateSystemSelection method:
>>
>>                                              if (this.dot != this.mark
>>                        && component !=
>>                                            null && component.hasFocus()) {
>>
>>                                            We also must write
>>                        regression tests for fixes
>>                                            if possible, so an automatic
>>                        test is needed as
>>                                            well. Could you please write
>>                        a test for the fix?
>>
>>
>>                         > I'm not sure why it works well on windows,
>>                                            That's because Windows
>>                        doesn't have system
>>                                            selection clipboard...
>>
>>
>>                         > Is there any reason for that ?
>>                                            No, that's a just bug...
>>
>>                                            Regards, Pavel
>>
>>
>>                                                2011/6/6 Pavel Porvatov
>>                            <pavel.porvatov at oracle.com
>>                            <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>> >
>>                            <mailto:pavel.porvatov at oracle.**__com
>>
>>                            <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>> >>>
>>
>>
>>                                                    Hi Sean,
>>
>>                                                        Hi,
>>
>>                                                        I reported, but
>>                                the system doesn't reply
>>                                                        me a bug number.
>>                                It says "will give me
>>                                                        email",
>>                                                        but I haven't
>>                                got one yet. Is this the
>>                                                        right process,
>>                                or I might make a problem
>>                                                        when
>>                                                        reporting?
>>
>>                                                    I don't know why the
>>                            system didn't report
>>                                                    bug ID, but your bug
>>                            was filed
>>                                                    successfully. You
>>                            can find it here:
>>                            http://bugs.sun.com/__**
>> bugdatabase/view_bug.do?bug___**id=7049024<http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=7049024>
>>
>>                            <http://bugs.sun.com/**
>> bugdatabase/view_bug.do?bug_**id=7049024<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7049024>
>> >
>>
>>                                                    Regards, Pavel
>>
>>
>>                                                        2011/5/27 Pavel
>>                                Porvatov
>>                                <pavel.porvatov at oracle.com
>>                                <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>> >
>>                                <mailto:pavel.porvatov at oracle.**__com
>>
>>                                <mailto:pavel.porvatov at oracle.**com<pavel.porvatov at oracle.com>
>> >>>
>>
>>
>>                                                            Hi Sean,
>>
>>                                                                Hi all,
>>
>>                                                                    I
>>                                    have a testcase related to DnD
>>                                                                failure
>>                                    with JTextArea and
>>
>>                                      JTextField on linux. The
>>                                                                testcase
>>                                    is as follows:
>>
>>                                                                /*
>>                                                                 *
>>                                    DnDTest.java
>>                                                                 */
>>                                                                import
>>                                    java.awt.Color;
>>                                                                import
>>                                    java.awt.Component;
>>                                                                import
>>                                    java.awt.Dimension;
>>                                                                import
>>                                    java.awt.FlowLayout;
>>                                                                import
>>                                    java.awt.Frame;
>>                                                                import
>>                                    java.awt.event.WindowAdapter;
>>                                                                import
>>                                    java.awt.event.WindowEvent;
>>
>>                                                                import
>>                                    javax.swing.JTextArea;
>>                                                                import
>>                                    javax.swing.JTextField;
>>
>>
>>                                                                public
>>                                    class DnDTest extends Frame {
>>                                                                Component
>> c;
>>                                                                public
>>                                    DnDTest() {
>>
>>                                      super("Single Frame --- AWT Frame");
>>
>>                                      super.setBackground(Color.__**gray);
>>
>>                                                                // set
>>                                    layout here.
>>
>>                                      setLayout(new FlowLayout());
>>                                                                c = new
>>                                    JTextArea("JTextArea
>>
>>  component");
>>
>>                                      c.setPreferredSize(new
>>
>>                                      Dimension(400, 100));
>>                                                                add(c);
>>                                                                c = new
>>                                    JTextField("JTextField
>>
>>                                      component(No IM)");
>>
>>                                      c.setPreferredSize(new
>>
>>                                      Dimension(400, 20));
>>                                                                add(c);
>>
>>                                      addWindowListener(new
>>                                    WindowAdapter() {
>>                                                                public void
>>
>>                                      windowClosing(WindowEvent event) {
>>
>>                                      System.exit(0);
>>                                                                }
>>                                                                });
>>
>>                                      setSize(850, 360);
>>
>>                                      setVisible(true);
>>                                                                }
>>                                                                public
>>                                    static void main(String[] args) {
>>                                                                new
>>                                    DnDTest();
>>                                                                }
>>                                                                }
>>
>>
>>
>>                                      Reproduce steps:
>>                                                                1. Run
>>                                    the testcase with b143
>>                                                                2. Open
>>                                    a new file with gedit and
>>                                                                input
>>                                    some words like "abcde"
>>                                                                3. Drag
>>                                    "abcde" into JTextField and
>>                                                                drop it
>>                                    there.
>>                                                                4. Once
>>                                    more, drag "abcde" into
>>
>>                                      JTextField and then move out of the
>>                                                                Frame
>>                                    (keep draging) and drag
>>                                                                into
>>                                    JTextField again and drop it.
>>
>>
>>  Expectation:
>>                                                                The
>>                                    second DnD inputs another
>>                                    "abcde" into JTextField.
>>
>>                                                                Result:
>>                                                                The
>>                                    second DnD inputs nothing
>>                                                                into
>>                                    JTextField.
>>
>>                                                            Yes, looks
>>                                like a bug. The test case
>>                                                            works on
>>                                Windows as expected.
>>
>>
>>
>>                                      Investigation:
>>                                                                The
>>                                    JTextArea as well has this
>>                                                                problem,
>>                                    and in step 4, if we drag
>>                                    "abcde" over JTextField and then
>>                                                                drop
>>                                    into JTextArea, nothing
>>                                                                is input
>>                                    into JTextArea either.
>>                                                                However,
>>                                    if "abcde" is drag
>>                                                                into
>>                                    JTextField or JTextArea
>>                                                                directly
>>                                    or when JTextArea/Field are
>>                                                                empty as
>>                                    in step 2, it works.
>>
>>
>>                                                                Are
>>                                    there any comments? And can
>>                                                                anyone
>>                                    file a bug for it please ?
>>
>>                                                            Anybody can
>>                                file a bug,
>>                                http://bugreport.sun.com/__**bugreport/<http://bugreport.sun.com/__bugreport/>
>>
>>                                <http://bugreport.sun.com/**bugreport/<http://bugreport.sun.com/bugreport/>
>> >
>>
>>                                                            Regards, Pavel
>>
>>
>>
>>
>>                                                        --
>>                                                        Best Regards,
>>                                                        Sean Chou
>>
>>
>>
>>
>>
>>                                                --
>>                                                Best Regards,
>>                                                Sean Chou
>>
>>
>>
>>
>>
>>                                        --
>>                                        Best Regards,
>>                                        Sean Chou
>>
>>
>>
>>
>>
>>                                --
>>                                Best Regards,
>>                                Sean Chou
>>
>>
>>
>>
>>
>>                        --
>>                        Best Regards,
>>                        Sean Chou
>>
>>
>>
>>
>>
>>                --
>>                Best Regards,
>>                Sean Chou
>>
>>
>>
>>
>>
>>        --
>>        Best Regards,
>>        Sean Chou
>>
>>
>>
>>
>> --
>> Best Regards,
>> Sean Chou
>>
>>


-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111010/796b3858/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: webrev.7049024.zip
Type: application/zip
Size: 151351 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111010/796b3858/attachment-0001.zip 

From neil.richards at ngmr.net  Mon Oct 10 07:29:06 2011
From: neil.richards at ngmr.net (Neil Richards)
Date: Mon, 10 Oct 2011 15:29:06 +0100
Subject: <Swing Dev> DnD fails with JTextArea and JTextField
In-Reply-To: <CAOo=rxVrV+yyN6ipyR7prQu_wtHJhgnPLOYbqn_3rD5mJnAGPQ@mail.gmail.com>
References: <BANLkTim=cSTyZONavk-QfC0CU9EMRQ5H+w@mail.gmail.com>
	<4DDF3769.2040709@oracle.com>
	<BANLkTi=OnDdss48WR0wvg4pi6oDDrUxqZA@mail.gmail.com>
	<4DECEBD0.2030804@oracle.com>
	<CAOo=rxUyH0J5z7O+b7xLZa=H+r9-4cfCc=CmpXvbMOq9eiWTGQ@mail.gmail.com>
	<4E6F284B.1060601@oracle.com>
	<CAOo=rxU6G6-da+TOxBQyfwfaa_L=sEVTr45cT2OG+KogGE0Keg@mail.gmail.com>
	<4E71B608.7090201@oracle.com>
	<CAOo=rxWsiy9DqBmMAfLSGBL_frqcbsXaPWQtGr2W_RokObsZWA@mail.gmail.com>
	<4E787587.8040802@oracle.com>
	<CAOo=rxV5Q1MbY9yYQ1Hpg6XKe6bsn8OgUUaBSA5bDUDxoxppqQ@mail.gmail.com>
	<4E803E9C.5050303@oracle.com>
	<CAOo=rxXDio4s-u+V6eLVMWnqf9dpLFmWYCCRN1CCzAAvzOHUiw@mail.gmail.com>
	<4E8057B6.20804@oracle.com>
	<CAOo=rxX8o0hSpnjyijZoED1L7GvbNDFLNvp9Q0+pbeDCJnBG-w@mail.gmail.com>
	<4E81F3C5.6080805@oracle.com>
	<CAOo=rxX05BYPDTkJnGijyqVerV04fO3SwT2hZGFETQyG9kapuQ@mail.gmail.com>
	<4E8494F8.60306@oracle.com>
	<CAOo=rxWazVk-_xQJhyUqeTd45MWT_zvMA5CoZ2=Z7pE_Z3hxiA@mail.gmail.com>
	<CAOo=rxVrV+yyN6ipyR7prQu_wtHJhgnPLOYbqn_3rD5mJnAGPQ@mail.gmail.com>
Message-ID: <1318256946.7676.4.camel@chalkhill>

On Mon, 2011-10-10 at 15:38 +0800, Sean Chou wrote:
> Hi,
> 
> 
>     One more: I put the testcase under javax/swing/JTextArea because
> the bug is filed toward it.
> 
> On Mon, Oct 10, 2011 at 3:35 PM, Sean Chou <zhouyx at linux.vnet.ibm.com>
> wrote:
>         Hi Pavel, Artem,
>         
>         
>            I run jtreg on another machine and it passes. The
>         attachment is the testcase and patch.
>         
>         
>         The following modification to testcase are done as suggested
>         last time:
>         1. Copyright in agreed form (the ibm info)
>         2. Date in copyright
>         3. All swing code in EDT 
>         4. Use realSync()
>         
>         
>         Please have a look, thanks.

For ease of review, I've uploaded the webrev to cr.openjdk.java.net [1].

Regards, Neil

[1] http://cr.openjdk.java.net/~ngmr/7049024/webrev.02/

-- 
Unless stated above:
IBM email: neil_richards at uk.ibm.com
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From neil.richards at ngmr.net  Mon Oct 10 08:01:14 2011
From: neil.richards at ngmr.net (Neil Richards)
Date: Mon, 10 Oct 2011 16:01:14 +0100
Subject: <Swing Dev> [Accessibility]Focus unable to traverse in the
 menubar
In-Reply-To: <4E92EB65.6080605@oracle.com>
References: <4E730733.6020402@linux.vnet.ibm.com>
	<4E7710C7.5030506@oracle.com> <1316522669.4683.10.camel@chalkhill>
	<4E8C7A0B.7060006@oracle.com>  <4E92EB65.6080605@oracle.com>
Message-ID: <1318258874.7676.33.camel@chalkhill>

On Mon, 2011-10-10 at 16:56 +0400, Anton Tarasov wrote:
> Hi Neil and Jing, 

> I'm afraid that it's wrong to use ContainerOrderFocusTraversalPolicy
> for swing components. This policy is designed for AWT.
> JMenuBar calls setFocusTraversalKeysEnabled(false) in its ctor which
> means that it "swallows" focus traversal keys (like TAB/SHIFT-TAB
> etc.)
> and so it can't be a member of a focus traversal chain. Swing's
> default traversal policy (LayoutFocusTraversalPolicy) excludes
> JMenuBar
> from a focus traversal cycle. ContainerOrderFocusTraversalPolicy is
> not "aware" about JMenuBar and so it allows it.
> 
> So, either a default Swing policy should be used, or a custom policy.
> At worst, ContainerOrderFocusTraversalPolicy should be overriden
> to exclude JMenuBar from a cycle (override its accept(Component)
> method). 
> 
> Thanks,
> Anton.

Hi Anton,
Thanks for reviewing the suggestion, and for your insights into this
scenario.

>From the Javadoc, it seems that setFocusTraversalKeysEnabled() is mainly
concerned with choosing whether focus traversal key presses (normally
TAB and SHIFT-TAB) are processed "automatically" (when 'true') or are
delivered to the Component as key events (for the component's code to
process "manually").

(In the case of JMenuBar, it makes them come through as key events, but
doesn't do anything special to process these events, which is why they
get discarded.)

Your description above, though, seems to suggest that it is generally
undesirable for the JMenuBar to be given the focus, as all the
Swing-aware focus traversal policies make a point of not giving focus to
JMenuBar items.

If this is so, then wouldn't it make sense to call setFocusable(false)
from its constructor (too), to ensure it doesn't get focus ?

Or, to put it another way, could you explain a little of the reasoning
or scenario behind why it is desirable for JMenuBar items to be
generally focusable, even though they aren't focus-traversable ?

I think such an explanation would be really helpful in clearing up my
confusion on this point.

Thanks, Neil

-- 
Unless stated above:
IBM email: neil_richards at uk.ibm.com
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From pavel.porvatov at oracle.com  Tue Oct 11 02:50:44 2011
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Tue, 11 Oct 2011 13:50:44 +0400
Subject: <Swing Dev> Unexpected NullPointerException by endComposition()
In-Reply-To: <4E915243.6080304@linux.vnet.ibm.com>
References: <4E784792.7050202@linux.vnet.ibm.com> <4E79F8E4.8030509@oracle.com>
	<4E7AD3E9.7020704@linux.vnet.ibm.com>
	<1316683094.13161.4.camel@chalkhill>
	<4E817E18.5020209@linux.vnet.ibm.com> <4E8982FC.2030605@oracle.com>
	<4E89B668.6020100@linux.vnet.ibm.com> <4E8EC246.6050409@oracle.com>
	<4E8F1AF9.1010205@linux.vnet.ibm.com> <4E901AD3.9020805@oracle.com>
	<4E915243.6080304@linux.vnet.ibm.com>
Message-ID: <4E941174.9070709@oracle.com>

Hi Charles,
> On 10/08/2011 05:41 PM, Pavel Porvatov wrote:
>> Hi Charles,
>>> On 10/07/2011 05:11 PM, Pavel Porvatov wrote:
>>>> Hi Charles,
>>>>> On 10/03/2011 05:40 PM, Pavel Porvatov wrote:
>>>>>> Hi Charles,
>>>>>>> On 09/22/2011 05:18 PM, Neil Richards wrote:
>>>>>>>> On Thu, 2011-09-22 at 14:21 +0800, Charles Lee wrote:
>>>>>>>>> Hi guys,
>>>>>>>>>
>>>>>>>>> The webrev is attached.
>>>>>>>> For ease of review, I've uploaded the webrev to 
>>>>>>>> cr.openjdk.java.net [1]
>>>>>>>>
>>>>>>>> Regards, Neil
>>>>>>>>
>>>>>>>> [1] http://cr.openjdk.java.net/~ngmr/6938583/webrev.00
>>>>>>>>
>>>>>>> Hi guys,
>>>>>>>
>>>>>>> Any update about this issue? Is the idea workable?
>>>>>>>
>>>>>> Can you explain why should we consume right clicks but not left 
>>>>>> ones? (May be there are other test cases when NPE is thrown... ) 
>>>>>> And why do you consume event? (May be it hides NPE but breaks 
>>>>>> functionality)
>>>>>>
>>>>>> Thanks, Pavel
>>>>>>
>>>>>
>>>>> 1. When right clicks, it suppose to show a manu on where you 
>>>>> click. But I guess the demo (CodePointIM) is not suppose to show 
>>>>> that (what will be show when use CodePointIM and right click? 
>>>>> IIRC, I tried the normal input and right click but get nothing)
>>>>> 2. If point 1 is true, consuming the right click in the 
>>>>> CodePointIM is the easiest way to fix it and less error-prone 
>>>>> comparing with fixing in the jdk...
>>>>> 3. Consuming left click will disable the movement of the input 
>>>>> place by clicking, I guess...
>>>>>
>>>> There is no information about popup menu in the bug description. 
>>>> The problem is that endComposition() throws NPE if Input Method is 
>>>> turned on and the program is in composition mode. If you apply your 
>>>> fix and change BUTTON3 into BUTTON2 in the MouseEventTest2 test 
>>>> (see bug description), then NPE will be thrown with your patch as 
>>>> well...
>>>>
>>>> Regards, Pavel
>>>
>>> Why change Button3 to Button2? Does Button3 reflect the right click?
>> No, Button2 is the middle button. But if you use Button2 in the 
>> MouseEventTest2 the test is still valid and it shouldn't throw any 
>> unexpected exceptions. But if you apply your fix and replace Button3 
>> by Button2 in the MouseEventTest2 test, run the MouseEventTest2 test 
>> and use testcase from the bug description (of course in step 5 you 
>> should use the middle mouse button now) you'll get NPE
>>>
>>> NPE was occurred because the component is null. Component becomes 
>>> null because the default carret, IIRC, has been changed when it 
>>> receive the right click event. It is the right behavior, if I 
>>> understand correctly. So I am trying to disable the right click 
>>> event if the demo does not suppose some menu should going to show up.
>>>
>> I still don't understand where do you see popup menu? I wrote about 
>> the test from 
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6938583 and there 
>> is no popup there...
>>
>> Regards, Pavel
> I got your point. What about this solution:
> If in the compose mode, endCompositoin just sendComposedText instead 
> of sendCommittedText.
>
> The patch is attached
>
Could you please explain the fix? May be it removes NPE but it puzzles 
me. So if buffer.length() == 0 you invoke sendCommittedText, right? But 
sendCommittedText commits buffer, but buffer is empty. Looks strange...

BTW: the code like "if (!notInCompositionMode) {" a little bit difficult 
to understand =) I'd preffer to avoid two negations and use "if 
(notInCompositionMode)" and swap if/else blocks...

Regards, Pavel


From littlee at linux.vnet.ibm.com  Tue Oct 11 21:44:04 2011
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Wed, 12 Oct 2011 12:44:04 +0800
Subject: <Swing Dev> Unexpected NullPointerException by endComposition()
In-Reply-To: <4E941174.9070709@oracle.com>
References: <4E784792.7050202@linux.vnet.ibm.com> <4E79F8E4.8030509@oracle.com>
	<4E7AD3E9.7020704@linux.vnet.ibm.com>
	<1316683094.13161.4.camel@chalkhill>
	<4E817E18.5020209@linux.vnet.ibm.com> <4E8982FC.2030605@oracle.com>
	<4E89B668.6020100@linux.vnet.ibm.com> <4E8EC246.6050409@oracle.com>
	<4E8F1AF9.1010205@linux.vnet.ibm.com> <4E901AD3.9020805@oracle.com>
	<4E915243.6080304@linux.vnet.ibm.com> <4E941174.9070709@oracle.com>
Message-ID: <4E951B14.106@linux.vnet.ibm.com>

On 10/11/2011 05:50 PM, Pavel Porvatov wrote:
> Hi Charles,
>> On 10/08/2011 05:41 PM, Pavel Porvatov wrote:
>>> Hi Charles,
>>>> On 10/07/2011 05:11 PM, Pavel Porvatov wrote:
>>>>> Hi Charles,
>>>>>> On 10/03/2011 05:40 PM, Pavel Porvatov wrote:
>>>>>>> Hi Charles,
>>>>>>>> On 09/22/2011 05:18 PM, Neil Richards wrote:
>>>>>>>>> On Thu, 2011-09-22 at 14:21 +0800, Charles Lee wrote:
>>>>>>>>>> Hi guys,
>>>>>>>>>>
>>>>>>>>>> The webrev is attached.
>>>>>>>>> For ease of review, I've uploaded the webrev to 
>>>>>>>>> cr.openjdk.java.net [1]
>>>>>>>>>
>>>>>>>>> Regards, Neil
>>>>>>>>>
>>>>>>>>> [1] http://cr.openjdk.java.net/~ngmr/6938583/webrev.00
>>>>>>>>>
>>>>>>>> Hi guys,
>>>>>>>>
>>>>>>>> Any update about this issue? Is the idea workable?
>>>>>>>>
>>>>>>> Can you explain why should we consume right clicks but not left 
>>>>>>> ones? (May be there are other test cases when NPE is thrown... ) 
>>>>>>> And why do you consume event? (May be it hides NPE but breaks 
>>>>>>> functionality)
>>>>>>>
>>>>>>> Thanks, Pavel
>>>>>>>
>>>>>>
>>>>>> 1. When right clicks, it suppose to show a manu on where you 
>>>>>> click. But I guess the demo (CodePointIM) is not suppose to show 
>>>>>> that (what will be show when use CodePointIM and right click? 
>>>>>> IIRC, I tried the normal input and right click but get nothing)
>>>>>> 2. If point 1 is true, consuming the right click in the 
>>>>>> CodePointIM is the easiest way to fix it and less error-prone 
>>>>>> comparing with fixing in the jdk...
>>>>>> 3. Consuming left click will disable the movement of the input 
>>>>>> place by clicking, I guess...
>>>>>>
>>>>> There is no information about popup menu in the bug description. 
>>>>> The problem is that endComposition() throws NPE if Input Method is 
>>>>> turned on and the program is in composition mode. If you apply 
>>>>> your fix and change BUTTON3 into BUTTON2 in the MouseEventTest2 
>>>>> test (see bug description), then NPE will be thrown with your 
>>>>> patch as well...
>>>>>
>>>>> Regards, Pavel
>>>>
>>>> Why change Button3 to Button2? Does Button3 reflect the right click?
>>> No, Button2 is the middle button. But if you use Button2 in the 
>>> MouseEventTest2 the test is still valid and it shouldn't throw any 
>>> unexpected exceptions. But if you apply your fix and replace Button3 
>>> by Button2 in the MouseEventTest2 test, run the MouseEventTest2 test 
>>> and use testcase from the bug description (of course in step 5 you 
>>> should use the middle mouse button now) you'll get NPE
>>>>
>>>> NPE was occurred because the component is null. Component becomes 
>>>> null because the default carret, IIRC, has been changed when it 
>>>> receive the right click event. It is the right behavior, if I 
>>>> understand correctly. So I am trying to disable the right click 
>>>> event if the demo does not suppose some menu should going to show up.
>>>>
>>> I still don't understand where do you see popup menu? I wrote about 
>>> the test from 
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6938583 and there 
>>> is no popup there...
>>>
>>> Regards, Pavel
>> I got your point. What about this solution:
>> If in the compose mode, endCompositoin just sendComposedText instead 
>> of sendCommittedText.
>>
>> The patch is attached
>>
> Could you please explain the fix? May be it removes NPE but it puzzles 
> me. So if buffer.length() == 0 you invoke sendCommittedText, right? 
> But sendCommittedText commits buffer, but buffer is empty. Looks 
> strange...
>
> BTW: the code like "if (!notInCompositionMode) {" a little bit 
> difficult to understand =) I'd preffer to avoid two negations and use 
> "if (notInCompositionMode)" and swap if/else blocks...
>
> Regards, Pavel
>
Hi Pavel,

Sorry for the confusion. Here is some explanation, please correct me if 
I am wrong:
1. There two modes which is judge from the buffer size: composed mode 
when the buffer size is not zero and normal mode when the buffer size is 
zero.
2. The original code make no difference whether it is in the composed 
mode or normal mode. In the normal mode, which buffer size is zero, it 
sends the committed text. In the composed mode, which buffer size is not 
zero, it also sends the committed code. And NPE occurred here.
3. In the patch, I do not change the logic when in the normal mode. 
(notInCompositionMode branch)  Why? I guess it is the logic of "Ends any 
input composition that may currently be going on in this context. 
Depending on the platform and possibly user preferences, this may commit 
or delete uncommitted text." from the api spec....
4. In the patch, the logic in the composed mode is that: if it is in the 
composed mode, keep every thing as just composed :-)

-- 
Yours Charles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111012/cc8fc3a7/attachment.html 

From pavel.porvatov at oracle.com  Fri Oct 14 01:06:31 2011
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Fri, 14 Oct 2011 12:06:31 +0400
Subject: <Swing Dev> Unexpected NullPointerException by endComposition()
In-Reply-To: <4E951B14.106@linux.vnet.ibm.com>
References: <4E784792.7050202@linux.vnet.ibm.com>
	<4E79F8E4.8030509@oracle.com>	<4E7AD3E9.7020704@linux.vnet.ibm.com>	<1316683094.13161.4.camel@chalkhill>	<4E817E18.5020209@linux.vnet.ibm.com>
	<4E8982FC.2030605@oracle.com>	<4E89B668.6020100@linux.vnet.ibm.com>
	<4E8EC246.6050409@oracle.com>	<4E8F1AF9.1010205@linux.vnet.ibm.com>
	<4E901AD3.9020805@oracle.com>	<4E915243.6080304@linux.vnet.ibm.com>
	<4E941174.9070709@oracle.com> <4E951B14.106@linux.vnet.ibm.com>
Message-ID: <4E97ED87.2080304@oracle.com>

Hi Charles,
> On 10/11/2011 05:50 PM, Pavel Porvatov wrote:
>> Hi Charles,
>>> On 10/08/2011 05:41 PM, Pavel Porvatov wrote:
>>> I got your point. What about this solution:
>>> If in the compose mode, endCompositoin just sendComposedText instead 
>>> of sendCommittedText.
>>>
>>> The patch is attached
>>>
>> Could you please explain the fix? May be it removes NPE but it 
>> puzzles me. So if buffer.length() == 0 you invoke sendCommittedText, 
>> right? But sendCommittedText commits buffer, but buffer is empty. 
>> Looks strange...
>>
>> BTW: the code like "if (!notInCompositionMode) {" a little bit 
>> difficult to understand =) I'd preffer to avoid two negations and use 
>> "if (notInCompositionMode)" and swap if/else blocks...
>>
>> Regards, Pavel
>>
> Hi Pavel,
>
> Sorry for the confusion. Here is some explanation, please correct me 
> if I am wrong:
> 1. There two modes which is judge from the buffer size: composed mode 
> when the buffer size is not zero and normal mode when the buffer size 
> is zero.
Right
> 2. The original code make no difference whether it is in the composed 
> mode or normal mode. In the normal mode, which buffer size is zero, it 
> sends the committed text. In the composed mode, which buffer size is 
> not zero, it also sends the committed code. And NPE occurred here.
> 3. In the patch, I do not change the logic when in the normal mode. 
> (notInCompositionMode branch)  Why? I guess it is the logic of "Ends 
> any input composition that may currently be going on in this context. 
> Depending on the platform and possibly user preferences, this may 
> commit or delete uncommitted text." from the api spec....
Yes. But after your change the following code looks strange for  me:
         if (!notInCompositionMode) {
            ....
         } else {
 >>>>            sendCommittedText();
         }
So if we are not in composition mode we send something (empty string 
actually). Logically we shouldn't send anything (IMO), because buffer is 
empty. Why should we do something at all if endComposition is invoked 
and we are not in composition mode?
> 4. In the patch, the logic in the composed mode is that: if it is in 
> the composed mode, keep every thing as just composed :-)

I found a new bug (???) in the fix. If you apply the patch, run the 
MouseEventTest2 test and follow the instructions from the bug 
description NPE will not be thrown, but the JTextArea remains in 
composition mode even after endComposition completion.

Regards, Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111014/9ade559e/attachment.html 

From zhouyx at linux.vnet.ibm.com  Fri Oct 14 01:28:52 2011
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Fri, 14 Oct 2011 16:28:52 +0800
Subject: <Swing Dev> code review request: 7049024: DnD fails with JTextArea
	and JTextField
Message-ID: <CAOo=rxVo3C=5nuzPksbCwVfTThkQeN=de4NxboVS+M8pnoL3EA@mail.gmail.com>

Hi all,

    The case is about how to handle system selection when
DefaultCaret.moveDot is invoked.
In current implementation, the text component (like JTextField) related to
the DefaultCaret
instance will change the system selection because caret moves (as perform a
"select"
operation). However, there is an action in DnD that only the view needs to
be restored in a
selected status while the system selection should not be restored because it
is not a
"select" operation.

    The fix checks if the component related to the DefaultCaret instance
owns the focus,
if it does, the action is treated as user selection and update "system
selection"; else, the
action is thought to restore the visual status of the component only and
does not update
"system selection".

    And, there is a regression testcase in the patch as well. The testcase
is put in directory
JTextArea because the bug is reported to it.

    Webrev is here : http://cr.openjdk.java.net/~ngmr/7049024/webrev.02/

    I have tested it on linux.
    Windows is not affected by this bug and the regression test case does
not affect it as well.

-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111014/28dc023e/attachment.html 

From pavel.porvatov at oracle.com  Fri Oct 14 02:30:43 2011
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Fri, 14 Oct 2011 13:30:43 +0400
Subject: <Swing Dev> code review request: 7049024: DnD fails with
 JTextArea and JTextField
In-Reply-To: <CAOo=rxVo3C=5nuzPksbCwVfTThkQeN=de4NxboVS+M8pnoL3EA@mail.gmail.com>
References: <CAOo=rxVo3C=5nuzPksbCwVfTThkQeN=de4NxboVS+M8pnoL3EA@mail.gmail.com>
Message-ID: <4E980143.6080800@oracle.com>

Hi Sean,

I saw your fix and it looks good. Now I'm discussing copyright details: 
if we can add IBM copyright or not...

Regards, Pavel
> Hi all,
>
>     The case is about how to handle system selection when 
> DefaultCaret.moveDot is invoked.
> In current implementation, the text component (like JTextField) 
> related to the DefaultCaret
> instance will change the system selection because caret moves (as 
> perform a "select"
> operation). However, there is an action in DnD that only the view 
> needs to be restored in a
> selected status while the system selection should not be restored 
> because it is not a
> "select" operation.
>
>     The fix checks if the component related to the DefaultCaret 
> instance owns the focus,
> if it does, the action is treated as user selection and update "system 
> selection"; else, the
> action is thought to restore the visual status of the component only 
> and does not update
> "system selection".
>
>     And, there is a regression testcase in the patch as well. The 
> testcase is put in directory
> JTextArea because the bug is reported to it.
>
>     Webrev is here : 
> http://cr.openjdk.java.net/~ngmr/7049024/webrev.02/ 
> <http://cr.openjdk.java.net/%7Engmr/7049024/webrev.02/>
>
>     I have tested it on linux.
>     Windows is not affected by this bug and the regression test case 
> does not affect it as well.
>
> -- 
> Best Regards,
> Sean Chou
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111014/45c5a3a0/attachment.html 

From anton.tarasov at oracle.com  Mon Oct 10 05:56:05 2011
From: anton.tarasov at oracle.com (Anton Tarasov)
Date: Mon, 10 Oct 2011 16:56:05 +0400
Subject: <Swing Dev> [Accessibility]Focus unable to traverse in the
	menubar
In-Reply-To: <4E8C7A0B.7060006@oracle.com>
References: <4E730733.6020402@linux.vnet.ibm.com> <4E7710C7.5030506@oracle.com>
	<1316522669.4683.10.camel@chalkhill> <4E8C7A0B.7060006@oracle.com>
Message-ID: <4E92EB65.6080605@oracle.com>

Hi Neil and Jing,

On 10/5/2011 7:38 PM, Pavel Porvatov wrote:
> Hi Neil and Jing,
>> On Mon, 2011-09-19 at 13:52 +0400, Pavel Porvatov wrote:
>>> Hi Jing,
>>>
>>> I can't agree with you about the problem. According to
>>> http://download.oracle.com/javase/tutorial/uiswing/components/menu.html
>>> "Menus are unique in that, by convention, they aren't placed with the
>>> other components in the UI". Instead, a menu usually appears either 
>>> in a
>>> menu bar or as a popup menu", so your test-case is invalid.
>> Hi Pavel,
>> I'm not sure I understand your objection to the testcase.
>>
>> As you can see from the testcase code, the JMenu component _is_ held by
>> a JMenuBar component, in concordance with the documentation you point
>> to.
> Yep, that was my mistake. BTW the test treats with JMenu in a strange 
> way. Actually the test should contain something like this:
>         JMenuBar menubar = new JMenuBar();
>         JMenu jMenu = new JMenu("sample menu");
>         jMenu.add(new JMenuItem("hello"));
>         menubar.add(jMenu);
>
>> Perhaps you're worried that the physical layout of the components in the
>> panel materially affects the nature of the problem being reported ?
>>
>> If so, please consider the modified testcase in an update to the webrev
>> I previously posted [2].
>>
>> The modification uses the BorderLayout manager instead of GridLayout,
>> adding the JMenuBar so that it appears at the top of the panel.
>>
>> You'll notice that this rearrangement in physical layout does not change
>> the nature of the problem being reported.
>>
>> Hope this helps to clarify things,
>> Regards, Neil
> The fix changes default value of the JMenuBar.Focusable field and so 
> it breaks backward compatibility.
>
> Moreover the test have many other problems, but not only in JMenuBar:
> 1. Shift-TAB doesn't work from JComboBox
> 2. TAB from the last Button moves focus to some non-interactive 
> component and next TAB pressing doesn't change focus state at all
>
> May be the ContainerOrderFocusTraversalPolicy should be fixed...?

I'm afraid that it's wrong to use ContainerOrderFocusTraversalPolicy for 
swing components. This policy is designed for AWT.
JMenuBar calls setFocusTraversalKeysEnabled(false) in its ctor which 
means that it "swallows" focus traversal keys (like TAB/SHIFT-TAB etc.)
and so it can't be a member of a focus traversal chain. Swing's default 
traversal policy (LayoutFocusTraversalPolicy) excludes JMenuBar
from a focus traversal cycle. ContainerOrderFocusTraversalPolicy is not 
"aware" about JMenuBar and so it allows it.

So, either a default Swing policy should be used, or a custom policy. At 
worst, ContainerOrderFocusTraversalPolicy should be overriden
to exclude JMenuBar from a cycle (override its accept(Component) method).

Thanks,
Anton.

>
> P.S. CC-ed Anton as a focus expert

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111010/e18a5b67/attachment.html 

From anton.tarasov at oracle.com  Wed Oct 12 05:54:53 2011
From: anton.tarasov at oracle.com (Anton Tarasov)
Date: Wed, 12 Oct 2011 16:54:53 +0400
Subject: <Swing Dev> [Accessibility]Focus unable to traverse in the
	menubar
In-Reply-To: <1318258874.7676.33.camel@chalkhill>
References: <4E730733.6020402@linux.vnet.ibm.com>	
	<4E7710C7.5030506@oracle.com> <1316522669.4683.10.camel@chalkhill>	
	<4E8C7A0B.7060006@oracle.com> <4E92EB65.6080605@oracle.com>
	<1318258874.7676.33.camel@chalkhill>
Message-ID: <4E958E1D.7030205@oracle.com>

Hi Neil,

On 10/10/2011 7:01 PM, Neil Richards wrote:
> On Mon, 2011-10-10 at 16:56 +0400, Anton Tarasov wrote:
>> Hi Neil and Jing,
>> I'm afraid that it's wrong to use ContainerOrderFocusTraversalPolicy
>> for swing components. This policy is designed for AWT.
>> JMenuBar calls setFocusTraversalKeysEnabled(false) in its ctor which
>> means that it "swallows" focus traversal keys (like TAB/SHIFT-TAB
>> etc.)
>> and so it can't be a member of a focus traversal chain. Swing's
>> default traversal policy (LayoutFocusTraversalPolicy) excludes
>> JMenuBar
>> from a focus traversal cycle. ContainerOrderFocusTraversalPolicy is
>> not "aware" about JMenuBar and so it allows it.
>>
>> So, either a default Swing policy should be used, or a custom policy.
>> At worst, ContainerOrderFocusTraversalPolicy should be overriden
>> to exclude JMenuBar from a cycle (override its accept(Component)
>> method).
>>
>> Thanks,
>> Anton.
> Hi Anton,
> Thanks for reviewing the suggestion, and for your insights into this
> scenario.
>
> > From the Javadoc, it seems that setFocusTraversalKeysEnabled() is mainly
> concerned with choosing whether focus traversal key presses (normally
> TAB and SHIFT-TAB) are processed "automatically" (when 'true') or are
> delivered to the Component as key events (for the component's code to
> process "manually").
>
> (In the case of JMenuBar, it makes them come through as key events, but
> doesn't do anything special to process these events, which is why they
> get discarded.)

That is right, though it doesn't directly relate to the issue we're 
talking about =)

> Your description above, though, seems to suggest that it is generally
> undesirable for the JMenuBar to be given the focus, as all the
> Swing-aware focus traversal policies make a point of not giving focus to
> JMenuBar items.
>
> If this is so, then wouldn't it make sense to call setFocusable(false)
> from its constructor (too), to ensure it doesn't get focus ?
>
> Or, to put it another way, could you explain a little of the reasoning
> or scenario behind why it is desirable for JMenuBar items to be
> generally focusable, even though they aren't focus-traversable ?
>
> I think such an explanation would be really helpful in clearing up my
> confusion on this point.
>
> Thanks, Neil
>

Well, I suspect that the core of the problem is that adding JMenuBar as 
JComponent to a swing
container doesn't make much sense. Though it is not directly prohibited, 
doing so may cause
side effects like the one you've discovered. When JMenuBar is set 
properly onto a JFrame its focus
is managed by JRootPane and its focusability just isn't taken into 
account. That's may be the reason
it's not declared unfocusable. Honestly, I can't tell you exactly.

If you do it, you probably won't make any harm, but I personally don't 
think this is a vital fix
(unless you have a good use case of the scenario you've provided). 
Anyway, this is a swing question
(I'm, as an AWT dev member, leaving the decision to swing guys).

Thanks,
Anton.







From zhouyx at linux.vnet.ibm.com  Mon Oct 17 21:45:09 2011
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Tue, 18 Oct 2011 12:45:09 +0800
Subject: <Swing Dev> Focus on image icons are not visible in javaws
 cache with high contrast mode
In-Reply-To: <4E732DB1.6070804@oracle.com>
References: <4e647dc3.82cde30a.3537.5eed@mx.google.com>
	<CAOo=rxWpsDbsS3GVaH8shVfu3NKr1gu2VRSOgmOgutQffWnxTQ@mail.gmail.com>
	<4E6A13ED.200@oracle.com>
	<CAOo=rxXAttuk+_dV9U39cjXtAt9XkGo3Pec9pJv2BE0NcCL=jQ@mail.gmail.com>
	<1316086740.27737.52.camel@chalkhill> <4E71F7D4.6000704@oracle.com>
	<1316098057.27737.111.camel@chalkhill>
	<4E732DB1.6070804@oracle.com>
Message-ID: <CAOo=rxV3iW-2CM=NfOE9R+6fQm4P5jvCiJv77Ve_52aTRPDucQ@mail.gmail.com>

Hi Pavel,

    From your image, I agree the focus color is not always the same
with ControlTextColor,
but I cannot recreate it. When I changed  color of "3D objects" to red, I
got another image.
Please have a look.
    I think your suggestion is reasonable, we'd better use the focus color
from windows, but
it maybe a problem to keep 100% the same, I still not found if there is a
document for the
focus color.

On Fri, Sep 16, 2011 at 7:06 PM, Pavel Porvatov
<pavel.porvatov at oracle.com>wrote:

> Hi Neil,
>
>  On Thu, 2011-09-15 at 17:04 +0400, Pavel Porvatov wrote:
>>
>>> Hi Neil,
>>>
>>>> On Wed, 2011-09-14 at 14:14 +0800, Sean Chou wrote:
>>>>
>>>>> Hi Pavel,
>>>>>
>>>>>
>>>>>     I reported a bug there yesterday,
>>>>>     http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=7089914<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7089914>
>>>>>     So far, I'm not sure if Windows use ControlTextColor, I'll check
>>>>> it.
>>>>>
>>>>>  For ease of review, I've uploaded Sean's change as a webrev [1].
>>>>
>>>> With the change, I see the following focus-related color settings in the
>>>> WindowsLookAndFeel:
>>>>
>>>> Button.focus:           ControlTextColor
>>>> Checkbox.focus:         ControlTextColor
>>>> RadioButton.focus:      ControlTextColor
>>>> Slider.focus:           ControlDarkShadowColor
>>>> TabbedPane.focus:       ControlTextColor
>>>> ToggleButton.focus:     ControlTextColor
>>>>
>>>> So the change of setting for Button, Checkbox and RadioButton conforms
>>>> to what is already used for TabbedPane and ToggleButton.
>>>>
>>> But doesn't conform to Slider.focus...
>>>
>> Are you recommending that Slider.focus should be changed to
>> ControlTextColor too ?
>>
> No, I meant that we cannot fix some bugs by copy-paste method.
>
>>  From it's name, it's not entirely obvious to me that 'ControlTextColor'
>>>>>
>>>> is really the ideal setting to use here, but it's also clear that it's a
>>>> far better setting to use than the current hard-coded 'black'.
>>>>
>>> Yes, of course. The last question is which color is correct. We can't
>>> change one incorrect color to another incorrect color...
>>>
>> I guess I hope that some knowledgeable person might be able to suggest /
>> corroborate / refute the choice of setting here.
>>
>> It seems worse to consider sticking with a hard-coded, un-configurable
>> value that has been demonstrated to cause problems, than to use a
>> setting whose value can at least be configured, in practice fixes the
>> problem's symptoms, and is already used in most other similar contexts
>> within the same look&  feel.
>>
>>
>> Suggestions for how to improve things further are always welcome.
>>
> Your points sounds good. But as I said: we can't change one incorrect color
> to another incorrect color (doesn't matter configurable it or not). I
> attached  the screenshot that shows that ControlTextColor is not always
> equal to color of selection frame (to reproduce this image press the
> Advanced button and change color of "3D objects" to red).
>
> Regards, Pavel
>



-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111018/cb1c4541/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3dobjectRed.PNG
Type: image/png
Size: 18796 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111018/cb1c4541/3dobjectRed-0001.PNG 

From zhouyx at linux.vnet.ibm.com  Tue Oct 18 00:53:25 2011
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Tue, 18 Oct 2011 15:53:25 +0800
Subject: <Swing Dev> Add Look&Feel support for AIX platform
Message-ID: <CAOo=rxWjwNu6EyMc9Wcq3QAQvNker2n6S+i4sMKFHrQT66pY-A@mail.gmail.com>

Hi all,

    This is a simple patch to add LookAndFeel support for AIX platform to
help bring
up GUI application.

    This is part of the series of AIX patches.
-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111018/659b5578/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OJDK-167.diff
Type: application/octet-stream
Size: 1244 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111018/659b5578/OJDK-167.diff 

From spoole at linux.vnet.ibm.com  Tue Oct 18 03:15:00 2011
From: spoole at linux.vnet.ibm.com (Steve Poole)
Date: Tue, 18 Oct 2011 11:15:00 +0100
Subject: <Swing Dev> Add Look&Feel support for AIX platform
In-Reply-To: <CAOo=rxWjwNu6EyMc9Wcq3QAQvNker2n6S+i4sMKFHrQT66pY-A@mail.gmail.com>
References: <CAOo=rxWjwNu6EyMc9Wcq3QAQvNker2n6S+i4sMKFHrQT66pY-A@mail.gmail.com>
Message-ID: <1318932900.16297.5.camel@jazzette>

On Tue, 2011-10-18 at 15:53 +0800, Sean Chou wrote:

Hi Sean,   I wonder if the inclusion of AIX in the enum is at the wrong
point?    You've added it before UNKNOWN which makes logical sense - but
you have changed UNKNOWN's ordinal value so if the enum is
serialised/deserialised  then you could in theory break  something
relying on UNKNOWN being the 4th entry 

Its a small point and unlikely to happen I expect but I thought I'd
point it out.

> Hi all,
> 
> 
>     This is a simple patch to add LookAndFeel support for AIX platform
> to help bring
> up GUI application. 
> 
> 
>     This is part of the series of AIX patches. 



From tom.hawtin at oracle.com  Tue Oct 18 04:27:22 2011
From: tom.hawtin at oracle.com (Tom Hawtin)
Date: Tue, 18 Oct 2011 12:27:22 +0100
Subject: <Swing Dev> Add Look&Feel support for AIX platform
In-Reply-To: <1318932900.16297.5.camel@jazzette>
References: <CAOo=rxWjwNu6EyMc9Wcq3QAQvNker2n6S+i4sMKFHrQT66pY-A@mail.gmail.com>
	<1318932900.16297.5.camel@jazzette>
Message-ID: <4E9D629A.4070004@oracle.com>

On 18/10/2011 11:15, Steve Poole wrote:
> On Tue, 2011-10-18 at 15:53 +0800, Sean Chou wrote:
>
> Hi Sean,   I wonder if the inclusion of AIX in the enum is at the wrong
> point?    You've added it before UNKNOWN which makes logical sense - but
> you have changed UNKNOWN's ordinal value so if the enum is
> serialised/deserialised  then you could in theory break  something
> relying on UNKNOWN being the 4th entry
>
> Its a small point and unlikely to happen I expect but I thought I'd
> point it out.

It does change the ordinal but it's not a technically binary 
compatibility change as defined by the JLS (3rd Ed. 13.4.26). The 
behavioural change by insertion is less significant as the results from 
compareTo select the same sort order.

http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#13.4.26

"13.4.26 Evolution of Enums

"Adding or reordering constants from an enum type will not break 
compatibility with pre-existing binaries.
If a precompiled binary attempts to access an enum constant that no 
longer exists, the client will fail at runtime with a NoSuchFieldError. 
Therefore such a change is not recommended for widely distributed enums.

"In all other respects, the binary compatibility rules for enums are 
identical to those for classes."


Java Serialisation serialises enums by name rather than just ordinal.

Tom

From littlee at linux.vnet.ibm.com  Tue Oct 18 22:28:55 2011
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Wed, 19 Oct 2011 13:28:55 +0800
Subject: <Swing Dev> Unexpected NullPointerException by endComposition()
In-Reply-To: <4E97ED87.2080304@oracle.com>
References: <4E784792.7050202@linux.vnet.ibm.com>
	<4E79F8E4.8030509@oracle.com>	<4E7AD3E9.7020704@linux.vnet.ibm.com>
	<1316683094.13161.4.camel@chalkhill>	<4E817E18.5020209@linux.vnet.ibm.com>
	<4E8982FC.2030605@oracle.com>	<4E89B668.6020100@linux.vnet.ibm.com>
	<4E8EC246.6050409@oracle.com>	<4E8F1AF9.1010205@linux.vnet.ibm.com>
	<4E901AD3.9020805@oracle.com>	<4E915243.6080304@linux.vnet.ibm.com>
	<4E941174.9070709@oracle.com> <4E951B14.106@linux.vnet.ibm.com>
	<4E97ED87.2080304@oracle.com>
Message-ID: <4E9E6017.8080501@linux.vnet.ibm.com>

On 10/14/2011 04:06 PM, Pavel Porvatov wrote:
> Hi Charles,
>> On 10/11/2011 05:50 PM, Pavel Porvatov wrote:
>>> Hi Charles,
>>>> On 10/08/2011 05:41 PM, Pavel Porvatov wrote:
>>>> I got your point. What about this solution:
>>>> If in the compose mode, endCompositoin just sendComposedText 
>>>> instead of sendCommittedText.
>>>>
>>>> The patch is attached
>>>>
>>> Could you please explain the fix? May be it removes NPE but it 
>>> puzzles me. So if buffer.length() == 0 you invoke sendCommittedText, 
>>> right? But sendCommittedText commits buffer, but buffer is empty. 
>>> Looks strange...
>>>
>>> BTW: the code like "if (!notInCompositionMode) {" a little bit 
>>> difficult to understand =) I'd preffer to avoid two negations and 
>>> use "if (notInCompositionMode)" and swap if/else blocks...
>>>
>>> Regards, Pavel
>>>
>> Hi Pavel,
>>
>> Sorry for the confusion. Here is some explanation, please correct me 
>> if I am wrong:
>> 1. There two modes which is judge from the buffer size: composed mode 
>> when the buffer size is not zero and normal mode when the buffer size 
>> is zero.
> Right
>> 2. The original code make no difference whether it is in the composed 
>> mode or normal mode. In the normal mode, which buffer size is zero, 
>> it sends the committed text. In the composed mode, which buffer size 
>> is not zero, it also sends the committed code. And NPE occurred here.
>> 3. In the patch, I do not change the logic when in the normal mode. 
>> (notInCompositionMode branch)  Why? I guess it is the logic of "Ends 
>> any input composition that may currently be going on in this context. 
>> Depending on the platform and possibly user preferences, this may 
>> commit or delete uncommitted text." from the api spec....
> Yes. But after your change the following code looks strange for  me:
>         if (!notInCompositionMode) {
>            ....
>         } else {
> >>>>            sendCommittedText();
>         }
> So if we are not in composition mode we send something (empty string 
> actually). Logically we shouldn't send anything (IMO), because buffer 
> is empty. Why should we do something at all if endComposition is 
> invoked and we are not in composition mode?
>> 4. In the patch, the logic in the composed mode is that: if it is in 
>> the composed mode, keep every thing as just composed :-)
>
> I found a new bug (???) in the fix. If you apply the patch, run the 
> MouseEventTest2 test and follow the instructions from the bug 
> description NPE will not be thrown, but the JTextArea remains in 
> composition mode even after endComposition completion.

Right. It seems that we have to do some thing in the jdk :-). Here it is:

The patch attached is just adding a null check at the beginning of the 
mouseClicked method in DefaultCaret. So why the component is null in the 
DefaultCaret? That because the caret has already been deinstalled. It 
seems to be an order problem of mouse event and the event which 
endCompositon sent. The endComposition will exchange the caret and 
deinstall the old one. On the other hand, mouse click event was 
happening on the old caret. So the component of the old caret is null 
now. NPE happens.

>
> Regards, Pavel


-- 
Yours Charles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111019/46713733/attachment.html 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.v3
Url: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111019/46713733/patch.v3 

From spoole at linux.vnet.ibm.com  Wed Oct 19 03:15:03 2011
From: spoole at linux.vnet.ibm.com (Steve Poole)
Date: Wed, 19 Oct 2011 11:15:03 +0100
Subject: <Swing Dev> Add Look&Feel support for AIX platform
In-Reply-To: <4E9D629A.4070004@oracle.com>
References: <CAOo=rxWjwNu6EyMc9Wcq3QAQvNker2n6S+i4sMKFHrQT66pY-A@mail.gmail.com>
	<1318932900.16297.5.camel@jazzette> <4E9D629A.4070004@oracle.com>
Message-ID: <1319019303.11996.15.camel@jazzette>

On Tue, 2011-10-18 at 12:27 +0100, Tom Hawtin wrote:
> On 18/10/2011 11:15, Steve Poole wrote:
> > On Tue, 2011-10-18 at 15:53 +0800, Sean Chou wrote:
> >
> > Hi Sean,   I wonder if the inclusion of AIX in the enum is at the wrong
> > point?    You've added it before UNKNOWN which makes logical sense - but
> > you have changed UNKNOWN's ordinal value so if the enum is
> > serialised/deserialised  then you could in theory break  something
> > relying on UNKNOWN being the 4th entry
> >
> > Its a small point and unlikely to happen I expect but I thought I'd
> > point it out.
> 
> It does change the ordinal but it's not a technically binary 
> compatibility change as defined by the JLS (3rd Ed. 13.4.26). The 
> behavioural change by insertion is less significant as the results from 
> compareTo select the same sort order.
> 
> http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#13.4.26
> 
> "13.4.26 Evolution of Enums
> 
> "Adding or reordering constants from an enum type will not break 
> compatibility with pre-existing binaries.
> If a precompiled binary attempts to access an enum constant that no 
> longer exists, the client will fail at runtime with a NoSuchFieldError. 
> Therefore such a change is not recommended for widely distributed enums.
> 
> "In all other respects, the binary compatibility rules for enums are 
> identical to those for classes."
> 
> 
> Java Serialisation serialises enums by name rather than just ordinal.
> 
Thanks for the clarification Tom.

> Tom
> 



From zhouyx at linux.vnet.ibm.com  Thu Oct 20 00:07:35 2011
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Thu, 20 Oct 2011 15:07:35 +0800
Subject: <Swing Dev> code review request: 7049024: DnD fails with
 JTextArea and JTextField
In-Reply-To: <4E980143.6080800@oracle.com>
References: <CAOo=rxVo3C=5nuzPksbCwVfTThkQeN=de4NxboVS+M8pnoL3EA@mail.gmail.com>
	<4E980143.6080800@oracle.com>
Message-ID: <CAOo=rxW4mwTT127yzajYhYUQk5k8N-COZ_SF_aOefWjxB17fTw@mail.gmail.com>

Hi Pavel,

    Is there any update ? We are told to use this kind of copyright for new
files, I think there
should be some published agreements about it.

On Fri, Oct 14, 2011 at 5:30 PM, Pavel Porvatov
<pavel.porvatov at oracle.com>wrote:

> **
> Hi Sean,
>
> I saw your fix and it looks good. Now I'm discussing copyright details: if
> we can add IBM copyright or not...
>
> Regards, Pavel
>
> Hi all,
>
>      The case is about how to handle system selection when
> DefaultCaret.moveDot is invoked.
> In current implementation, the text component (like JTextField) related to
> the DefaultCaret
> instance will change the system selection because caret moves (as perform a
> "select"
> operation). However, there is an action in DnD that only the view needs to
> be restored in a
> selected status while the system selection should not be restored because
> it is not a
> "select" operation.
>
>      The fix checks if the component related to the DefaultCaret instance
> owns the focus,
> if it does, the action is treated as user selection and update "system
> selection"; else, the
> action is thought to restore the visual status of the component only and
> does not update
> "system selection".
>
>      And, there is a regression testcase in the patch as well. The
> testcase is put in directory
> JTextArea because the bug is reported to it.
>
>      Webrev is here : http://cr.openjdk.java.net/~ngmr/7049024/webrev.02/
>
>      I have tested it on linux.
>     Windows is not affected by this bug and the regression test case does
> not affect it as well.
>
>  --
> Best Regards,
> Sean Chou
>
>
>


-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111020/206dd914/attachment.html 

From neil.richards at ngmr.net  Thu Oct 20 08:10:00 2011
From: neil.richards at ngmr.net (Neil Richards)
Date: Thu, 20 Oct 2011 16:10:00 +0100
Subject: <Swing Dev> Add Look&Feel support for AIX platform
In-Reply-To: <CAOo=rxWjwNu6EyMc9Wcq3QAQvNker2n6S+i4sMKFHrQT66pY-A@mail.gmail.com>
References: <CAOo=rxWjwNu6EyMc9Wcq3QAQvNker2n6S+i4sMKFHrQT66pY-A@mail.gmail.com>
Message-ID: <1319123400.9882.48.camel@chalkhill>

On Tue, 2011-10-18 at 15:53 +0800, Sean Chou wrote:
> Hi all,
> 
> 
>     This is a simple patch to add LookAndFeel support for AIX platform
> to help bring
> up GUI application. 
> 
> 
>     This is part of the series of AIX patches. 
> -- 
> Best Regards,
> Sean Chou
> 
> 

For ease of review, I've uploaded this suggested fix as a webrev [1].

The change looks good to me.

Regards, Neil

[1] http://cr.openjdk.java.net/~ngmr/ojdk-167/webrev.00/index.html

-- 
Unless stated above:
IBM email: neil_richards at uk.ibm.com
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From neil.richards at ngmr.net  Thu Oct 20 10:37:22 2011
From: neil.richards at ngmr.net (Neil Richards)
Date: Thu, 20 Oct 2011 18:37:22 +0100
Subject: <Swing Dev> Unexpected NullPointerException by endComposition()
In-Reply-To: <4E9E6017.8080501@linux.vnet.ibm.com>
References: <4E784792.7050202@linux.vnet.ibm.com>
	<4E79F8E4.8030509@oracle.com>	<4E7AD3E9.7020704@linux.vnet.ibm.com>
	<1316683094.13161.4.camel@chalkhill>	<4E817E18.5020209@linux.vnet.ibm.com>
	<4E8982FC.2030605@oracle.com>	<4E89B668.6020100@linux.vnet.ibm.com>
	<4E8EC246.6050409@oracle.com>	<4E8F1AF9.1010205@linux.vnet.ibm.com>
	<4E901AD3.9020805@oracle.com>	<4E915243.6080304@linux.vnet.ibm.com>
	<4E941174.9070709@oracle.com> <4E951B14.106@linux.vnet.ibm.com>
	<4E97ED87.2080304@oracle.com>  <4E9E6017.8080501@linux.vnet.ibm.com>
Message-ID: <1319132242.5671.81.camel@chalkhill>

For ease of review, I've uploaded a webrev of the patch.v3 suggested fix
[1].

Regards, Neil

[1] http://cr.openjdk.java.net/~ngmr/6938583/webrev.02/index.html

-- 
Unless stated above:
IBM email: neil_richards at uk.ibm.com
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From pavel.porvatov at oracle.com  Wed Oct 26 08:12:59 2011
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Wed, 26 Oct 2011 19:12:59 +0400
Subject: <Swing Dev> Focus on image icons are not visible in javaws
 cache with high contrast mode
In-Reply-To: <CAOo=rxV3iW-2CM=NfOE9R+6fQm4P5jvCiJv77Ve_52aTRPDucQ@mail.gmail.com>
References: <4e647dc3.82cde30a.3537.5eed@mx.google.com>
	<CAOo=rxWpsDbsS3GVaH8shVfu3NKr1gu2VRSOgmOgutQffWnxTQ@mail.gmail.com>
	<4E6A13ED.200@oracle.com>
	<CAOo=rxXAttuk+_dV9U39cjXtAt9XkGo3Pec9pJv2BE0NcCL=jQ@mail.gmail.com>
	<1316086740.27737.52.camel@chalkhill> <4E71F7D4.6000704@oracle.com>
	<1316098057.27737.111.camel@chalkhill>
	<4E732DB1.6070804@oracle.com>
	<CAOo=rxV3iW-2CM=NfOE9R+6fQm4P5jvCiJv77Ve_52aTRPDucQ@mail.gmail.com>
Message-ID: <4EA8237B.4020407@oracle.com>

  Hi Sean,
> Hi Pavel,
>
>     From your image, I agree the focus color is not always the same 
> with ControlTextColor,
> but I cannot recreate it. When I changed  color of "3D objects" to 
> red, I got another image.
> Please have a look.
It seems you changed Color1, but not Color (which a little bit lower 
then Color1)....
>     I think your suggestion is reasonable, we'd better use the focus 
> color from windows, but
> it maybe a problem to keep 100% the same, I still not found if there 
> is a document for the
> focus color.
Yes, the MS documentation about focus color is the best way to fix the 
bug. Can anybody point to such document?

Regards, Pavel
>
> On Fri, Sep 16, 2011 at 7:06 PM, Pavel Porvatov 
> <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>> wrote:
>
>     Hi Neil,
>
>         On Thu, 2011-09-15 at 17:04 +0400, Pavel Porvatov wrote:
>
>             Hi Neil,
>
>                 On Wed, 2011-09-14 at 14:14 +0800, Sean Chou wrote:
>
>                     Hi Pavel,
>
>
>                         I reported a bug there yesterday,
>                     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7089914
>                         So far, I'm not sure if Windows use
>                     ControlTextColor, I'll check
>                     it.
>
>                 For ease of review, I've uploaded Sean's change as a
>                 webrev [1].
>
>                 With the change, I see the following focus-related
>                 color settings in the
>                 WindowsLookAndFeel:
>
>                 Button.focus:           ControlTextColor
>                 Checkbox.focus:         ControlTextColor
>                 RadioButton.focus:      ControlTextColor
>                 Slider.focus:           ControlDarkShadowColor
>                 TabbedPane.focus:       ControlTextColor
>                 ToggleButton.focus:     ControlTextColor
>
>                 So the change of setting for Button, Checkbox and
>                 RadioButton conforms
>                 to what is already used for TabbedPane and ToggleButton.
>
>             But doesn't conform to Slider.focus...
>
>         Are you recommending that Slider.focus should be changed to
>         ControlTextColor too ?
>
>     No, I meant that we cannot fix some bugs by copy-paste method.
>
>                      From it's name, it's not entirely obvious to me
>                     that 'ControlTextColor'
>
>                 is really the ideal setting to use here, but it's also
>                 clear that it's a
>                 far better setting to use than the current hard-coded
>                 'black'.
>
>             Yes, of course. The last question is which color is
>             correct. We can't
>             change one incorrect color to another incorrect color...
>
>         I guess I hope that some knowledgeable person might be able to
>         suggest /
>         corroborate / refute the choice of setting here.
>
>         It seems worse to consider sticking with a hard-coded,
>         un-configurable
>         value that has been demonstrated to cause problems, than to use a
>         setting whose value can at least be configured, in practice
>         fixes the
>         problem's symptoms, and is already used in most other similar
>         contexts
>         within the same look&  feel.
>
>
>         Suggestions for how to improve things further are always welcome.
>
>     Your points sounds good. But as I said: we can't change one
>     incorrect color to another incorrect color (doesn't matter
>     configurable it or not). I attached  the screenshot that shows
>     that ControlTextColor is not always equal to color of selection
>     frame (to reproduce this image press the Advanced button and
>     change color of "3D objects" to red).
>
>     Regards, Pavel
>
>
>
>
> -- 
> Best Regards,
> Sean Chou
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111026/11dabb65/attachment.html 

From zhouyx at linux.vnet.ibm.com  Thu Oct 27 00:30:34 2011
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Thu, 27 Oct 2011 15:30:34 +0800
Subject: <Swing Dev> Focus on image icons are not visible in javaws
 cache with high contrast mode
In-Reply-To: <4EA8237B.4020407@oracle.com>
References: <4e647dc3.82cde30a.3537.5eed@mx.google.com>
	<CAOo=rxWpsDbsS3GVaH8shVfu3NKr1gu2VRSOgmOgutQffWnxTQ@mail.gmail.com>
	<4E6A13ED.200@oracle.com>
	<CAOo=rxXAttuk+_dV9U39cjXtAt9XkGo3Pec9pJv2BE0NcCL=jQ@mail.gmail.com>
	<1316086740.27737.52.camel@chalkhill> <4E71F7D4.6000704@oracle.com>
	<1316098057.27737.111.camel@chalkhill>
	<4E732DB1.6070804@oracle.com>
	<CAOo=rxV3iW-2CM=NfOE9R+6fQm4P5jvCiJv77Ve_52aTRPDucQ@mail.gmail.com>
	<4EA8237B.4020407@oracle.com>
Message-ID: <CAOo=rxUw_JTkttdKUfUMcZsKhU_4JOJH5X96tm55tEySiJFi4A@mail.gmail.com>

   It seems the black color for focus is set intentionally. If we set it to
"ControlTextColor ",
the focus color may become red in above testcase, that's not what we want.
   And I changed the color for all items listed with "3D object", the focus
remains black;
maybe windows just uses "black" for focus color in normal mode, and another
color for
high contrast mode.

   However, the original patch posted is not right in this scenario. I'll
modify it. How about
just uses white for high contrast mode ? As it simply uses black for normal
mode.

On Wed, Oct 26, 2011 at 11:12 PM, Pavel Porvatov
<pavel.porvatov at oracle.com>wrote:

>   Hi Sean,
>
> Hi Pavel,
>
>      From your image, I agree the focus color is not always the same
> with ControlTextColor,
> but I cannot recreate it. When I changed  color of "3D objects" to red, I
> got another image.
> Please have a look.
>
> It seems you changed Color1, but not Color (which a little bit lower then
> Color1)....
>
>     I think your suggestion is reasonable, we'd better use the focus color
> from windows, but
> it maybe a problem to keep 100% the same, I still not found if there is a
> document for the
> focus color.
>
> Yes, the MS documentation about focus color is the best way to fix the bug.
> Can anybody point to such document?
>
> Regards, Pavel
>
>
> On Fri, Sep 16, 2011 at 7:06 PM, Pavel Porvatov <pavel.porvatov at oracle.com
> > wrote:
>
>> Hi Neil,
>>
>>  On Thu, 2011-09-15 at 17:04 +0400, Pavel Porvatov wrote:
>>>
>>>> Hi Neil,
>>>>
>>>>> On Wed, 2011-09-14 at 14:14 +0800, Sean Chou wrote:
>>>>>
>>>>>> Hi Pavel,
>>>>>>
>>>>>>
>>>>>>     I reported a bug there yesterday,
>>>>>>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7089914
>>>>>>     So far, I'm not sure if Windows use ControlTextColor, I'll check
>>>>>> it.
>>>>>>
>>>>>>  For ease of review, I've uploaded Sean's change as a webrev [1].
>>>>>
>>>>> With the change, I see the following focus-related color settings in
>>>>> the
>>>>> WindowsLookAndFeel:
>>>>>
>>>>> Button.focus:           ControlTextColor
>>>>> Checkbox.focus:         ControlTextColor
>>>>> RadioButton.focus:      ControlTextColor
>>>>> Slider.focus:           ControlDarkShadowColor
>>>>> TabbedPane.focus:       ControlTextColor
>>>>> ToggleButton.focus:     ControlTextColor
>>>>>
>>>>> So the change of setting for Button, Checkbox and RadioButton conforms
>>>>> to what is already used for TabbedPane and ToggleButton.
>>>>>
>>>> But doesn't conform to Slider.focus...
>>>>
>>> Are you recommending that Slider.focus should be changed to
>>> ControlTextColor too ?
>>>
>>  No, I meant that we cannot fix some bugs by copy-paste method.
>>
>>>    From it's name, it's not entirely obvious to me that
>>>>>> 'ControlTextColor'
>>>>>>
>>>>> is really the ideal setting to use here, but it's also clear that it's
>>>>> a
>>>>> far better setting to use than the current hard-coded 'black'.
>>>>>
>>>> Yes, of course. The last question is which color is correct. We can't
>>>> change one incorrect color to another incorrect color...
>>>>
>>> I guess I hope that some knowledgeable person might be able to suggest /
>>> corroborate / refute the choice of setting here.
>>>
>>> It seems worse to consider sticking with a hard-coded, un-configurable
>>> value that has been demonstrated to cause problems, than to use a
>>> setting whose value can at least be configured, in practice fixes the
>>> problem's symptoms, and is already used in most other similar contexts
>>>  within the same look&  feel.
>>>
>>>
>>> Suggestions for how to improve things further are always welcome.
>>>
>> Your points sounds good. But as I said: we can't change one incorrect
>> color to another incorrect color (doesn't matter configurable it or not). I
>> attached  the screenshot that shows that ControlTextColor is not always
>> equal to color of selection frame (to reproduce this image press the
>> Advanced button and change color of "3D objects" to red).
>>
>> Regards, Pavel
>>
>
>
>
>  --
> Best Regards,
> Sean Chou
>
>
>


-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111027/c92f8de6/attachment.html 

From pavel.porvatov at oracle.com  Thu Oct 27 06:12:40 2011
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Thu, 27 Oct 2011 17:12:40 +0400
Subject: <Swing Dev> Unexpected NullPointerException by endComposition()
In-Reply-To: <4E9E6017.8080501@linux.vnet.ibm.com>
References: <4E784792.7050202@linux.vnet.ibm.com>
	<4E79F8E4.8030509@oracle.com>	<4E7AD3E9.7020704@linux.vnet.ibm.com>
	<1316683094.13161.4.camel@chalkhill>	<4E817E18.5020209@linux.vnet.ibm.com>
	<4E8982FC.2030605@oracle.com>	<4E89B668.6020100@linux.vnet.ibm.com>
	<4E8EC246.6050409@oracle.com>	<4E8F1AF9.1010205@linux.vnet.ibm.com>
	<4E901AD3.9020805@oracle.com>	<4E915243.6080304@linux.vnet.ibm.com>
	<4E941174.9070709@oracle.com> <4E951B14.106@linux.vnet.ibm.com>
	<4E97ED87.2080304@oracle.com> <4E9E6017.8080501@linux.vnet.ibm.com>
Message-ID: <4EA958C8.2030505@oracle.com>

Hi Charles,
> On 10/14/2011 04:06 PM, Pavel Porvatov wrote:
>> Hi Charles,
>>> On 10/11/2011 05:50 PM, Pavel Porvatov wrote:
>>>> Hi Charles,
>>>>> On 10/08/2011 05:41 PM, Pavel Porvatov wrote:
>>>>> I got your point. What about this solution:
>>>>> If in the compose mode, endCompositoin just sendComposedText 
>>>>> instead of sendCommittedText.
>>>>>
>>>>> The patch is attached
>>>>>
>>>> Could you please explain the fix? May be it removes NPE but it 
>>>> puzzles me. So if buffer.length() == 0 you invoke 
>>>> sendCommittedText, right? But sendCommittedText commits buffer, but 
>>>> buffer is empty. Looks strange...
>>>>
>>>> BTW: the code like "if (!notInCompositionMode) {" a little bit 
>>>> difficult to understand =) I'd preffer to avoid two negations and 
>>>> use "if (notInCompositionMode)" and swap if/else blocks...
>>>>
>>>> Regards, Pavel
>>>>
>>> Hi Pavel,
>>>
>>> Sorry for the confusion. Here is some explanation, please correct me 
>>> if I am wrong:
>>> 1. There two modes which is judge from the buffer size: composed 
>>> mode when the buffer size is not zero and normal mode when the 
>>> buffer size is zero.
>> Right
>>> 2. The original code make no difference whether it is in the 
>>> composed mode or normal mode. In the normal mode, which buffer size 
>>> is zero, it sends the committed text. In the composed mode, which 
>>> buffer size is not zero, it also sends the committed code. And NPE 
>>> occurred here.
>>> 3. In the patch, I do not change the logic when in the normal mode. 
>>> (notInCompositionMode branch)  Why? I guess it is the logic of "Ends 
>>> any input composition that may currently be going on in this 
>>> context. Depending on the platform and possibly user preferences, 
>>> this may commit or delete uncommitted text." from the api spec....
>> Yes. But after your change the following code looks strange for  me:
>>         if (!notInCompositionMode) {
>>            ....
>>         } else {
>> >>>>            sendCommittedText();
>>         }
>> So if we are not in composition mode we send something (empty string 
>> actually). Logically we shouldn't send anything (IMO), because buffer 
>> is empty. Why should we do something at all if endComposition is 
>> invoked and we are not in composition mode?
>>> 4. In the patch, the logic in the composed mode is that: if it is in 
>>> the composed mode, keep every thing as just composed :-)
>>
>> I found a new bug (???) in the fix. If you apply the patch, run the 
>> MouseEventTest2 test and follow the instructions from the bug 
>> description NPE will not be thrown, but the JTextArea remains in 
>> composition mode even after endComposition completion.
>
> Right. It seems that we have to do some thing in the jdk :-). Here it is:
>
> The patch attached is just adding a null check at the beginning of the 
> mouseClicked method in DefaultCaret. So why the component is null in 
> the DefaultCaret? That because the caret has already been deinstalled. 
> It seems to be an order problem of mouse event and the event which 
> endCompositon sent. The endComposition will exchange the caret and 
> deinstall the old one. On the other hand, mouse click event was 
> happening on the old caret. So the component of the old caret is null 
> now. NPE happens.
It looks that you are trying to fix the consequence, but not the root of 
the problem. The endComposition method shouldn't send anything to 
deinstalled DefaultCaret. I think the previous version of the fix was 
much closer than this one.

Regards, Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111027/04e5fb58/attachment.html 

From pavel.porvatov at oracle.com  Thu Oct 27 06:26:16 2011
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Thu, 27 Oct 2011 17:26:16 +0400
Subject: <Swing Dev> code review request: 7049024: DnD fails with
 JTextArea and JTextField
In-Reply-To: <CAOo=rxW4mwTT127yzajYhYUQk5k8N-COZ_SF_aOefWjxB17fTw@mail.gmail.com>
References: <CAOo=rxVo3C=5nuzPksbCwVfTThkQeN=de4NxboVS+M8pnoL3EA@mail.gmail.com>
	<4E980143.6080800@oracle.com>
	<CAOo=rxW4mwTT127yzajYhYUQk5k8N-COZ_SF_aOefWjxB17fTw@mail.gmail.com>
Message-ID: <4EA95BF8.6010101@oracle.com>

Hi Sean,
> Hi Pavel,
>
>     Is there any update ? We are told to use this kind of copyright 
> for new files, I think there
> should be some published agreements about it.
Unfortunately there are no news yet. Do you have some special reasons to 
keep IBM copyright there?

Regards, Pavel
>
> On Fri, Oct 14, 2011 at 5:30 PM, Pavel Porvatov 
> <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>> wrote:
>
>     Hi Sean,
>
>     I saw your fix and it looks good. Now I'm discussing copyright
>     details: if we can add IBM copyright or not...
>
>     Regards, Pavel
>
>>     Hi all,
>>
>>         The case is about how to handle system selection when
>>     DefaultCaret.moveDot is invoked.
>>     In current implementation, the text component (like JTextField)
>>     related to the DefaultCaret
>>     instance will change the system selection because caret moves (as
>>     perform a "select"
>>     operation). However, there is an action in DnD that only the view
>>     needs to be restored in a
>>     selected status while the system selection should not be restored
>>     because it is not a
>>     "select" operation.
>>
>>         The fix checks if the component related to the DefaultCaret
>>     instance owns the focus,
>>     if it does, the action is treated as user selection and update
>>     "system selection"; else, the
>>     action is thought to restore the visual status of the component
>>     only and does not update
>>     "system selection".
>>
>>         And, there is a regression testcase in the patch as well. The
>>     testcase is put in directory
>>     JTextArea because the bug is reported to it.
>>
>>         Webrev is here :
>>     http://cr.openjdk.java.net/~ngmr/7049024/webrev.02/
>>     <http://cr.openjdk.java.net/%7Engmr/7049024/webrev.02/>
>>
>>         I have tested it on linux.
>>         Windows is not affected by this bug and the regression
>>     test case does not affect it as well.
>>
>>     -- 
>>     Best Regards,
>>     Sean Chou
>>
>
>
>
>
> -- 
> Best Regards,
> Sean Chou
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111027/647570ba/attachment-0001.html 

From sergey.malenkov at sun.com  Thu Oct 27 08:52:15 2011
From: sergey.malenkov at sun.com (sergey.malenkov at sun.com)
Date: Thu, 27 Oct 2011 15:52:15 +0000
Subject: <Swing Dev> hg: jdk8/swing/jdk: 7092744: XMLEncoder fails to encode
	and breaks	backward compatibility
Message-ID: <20111027155241.351F34716C@hg.openjdk.java.net>

Changeset: 5880a716f277
Author:    malenkov
Date:      2011-10-27 19:51 +0400
URL:       http://hg.openjdk.java.net/jdk8/swing/jdk/rev/5880a716f277

7092744: XMLEncoder fails to encode and breaks backward compatibility
Reviewed-by: rupashka

! src/share/classes/com/sun/beans/finder/AbstractFinder.java
! src/share/classes/com/sun/beans/finder/ConstructorFinder.java
! src/share/classes/com/sun/beans/finder/MethodFinder.java
+ test/java/beans/XMLEncoder/Test7092744.java


From littlee at linux.vnet.ibm.com  Thu Oct 27 23:50:04 2011
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Fri, 28 Oct 2011 14:50:04 +0800
Subject: <Swing Dev> Unexpected NullPointerException by endComposition()
In-Reply-To: <4EA958C8.2030505@oracle.com>
References: <4E784792.7050202@linux.vnet.ibm.com>
	<4E79F8E4.8030509@oracle.com>	<4E7AD3E9.7020704@linux.vnet.ibm.com>
	<1316683094.13161.4.camel@chalkhill>	<4E817E18.5020209@linux.vnet.ibm.com>
	<4E8982FC.2030605@oracle.com>	<4E89B668.6020100@linux.vnet.ibm.com>
	<4E8EC246.6050409@oracle.com>	<4E8F1AF9.1010205@linux.vnet.ibm.com>
	<4E901AD3.9020805@oracle.com>	<4E915243.6080304@linux.vnet.ibm.com>
	<4E941174.9070709@oracle.com> <4E951B14.106@linux.vnet.ibm.com>
	<4E97ED87.2080304@oracle.com> <4E9E6017.8080501@linux.vnet.ibm.com>
	<4EA958C8.2030505@oracle.com>
Message-ID: <4EAA509C.1010009@linux.vnet.ibm.com>

On 10/27/2011 09:12 PM, Pavel Porvatov wrote:
> Hi Charles,
>> On 10/14/2011 04:06 PM, Pavel Porvatov wrote:
>>> Hi Charles,
>>>> On 10/11/2011 05:50 PM, Pavel Porvatov wrote:
>>>>> Hi Charles,
>>>>>> On 10/08/2011 05:41 PM, Pavel Porvatov wrote:
>>>>>> I got your point. What about this solution:
>>>>>> If in the compose mode, endCompositoin just sendComposedText 
>>>>>> instead of sendCommittedText.
>>>>>>
>>>>>> The patch is attached
>>>>>>
>>>>> Could you please explain the fix? May be it removes NPE but it 
>>>>> puzzles me. So if buffer.length() == 0 you invoke 
>>>>> sendCommittedText, right? But sendCommittedText commits buffer, 
>>>>> but buffer is empty. Looks strange...
>>>>>
>>>>> BTW: the code like "if (!notInCompositionMode) {" a little bit 
>>>>> difficult to understand =) I'd preffer to avoid two negations and 
>>>>> use "if (notInCompositionMode)" and swap if/else blocks...
>>>>>
>>>>> Regards, Pavel
>>>>>
>>>> Hi Pavel,
>>>>
>>>> Sorry for the confusion. Here is some explanation, please correct 
>>>> me if I am wrong:
>>>> 1. There two modes which is judge from the buffer size: composed 
>>>> mode when the buffer size is not zero and normal mode when the 
>>>> buffer size is zero.
>>> Right
>>>> 2. The original code make no difference whether it is in the 
>>>> composed mode or normal mode. In the normal mode, which buffer size 
>>>> is zero, it sends the committed text. In the composed mode, which 
>>>> buffer size is not zero, it also sends the committed code. And NPE 
>>>> occurred here.
>>>> 3. In the patch, I do not change the logic when in the normal mode. 
>>>> (notInCompositionMode branch)  Why? I guess it is the logic of 
>>>> "Ends any input composition that may currently be going on in this 
>>>> context. Depending on the platform and possibly user preferences, 
>>>> this may commit or delete uncommitted text." from the api spec....
>>> Yes. But after your change the following code looks strange for  me:
>>>         if (!notInCompositionMode) {
>>>            ....
>>>         } else {
>>> >>>>            sendCommittedText();
>>>         }
>>> So if we are not in composition mode we send something (empty string 
>>> actually). Logically we shouldn't send anything (IMO), because 
>>> buffer is empty. Why should we do something at all if endComposition 
>>> is invoked and we are not in composition mode?
>>>> 4. In the patch, the logic in the composed mode is that: if it is 
>>>> in the composed mode, keep every thing as just composed :-)
>>>
>>> I found a new bug (???) in the fix. If you apply the patch, run the 
>>> MouseEventTest2 test and follow the instructions from the bug 
>>> description NPE will not be thrown, but the JTextArea remains in 
>>> composition mode even after endComposition completion.
>>
>> Right. It seems that we have to do some thing in the jdk :-). Here it is:
>>
>> The patch attached is just adding a null check at the beginning of 
>> the mouseClicked method in DefaultCaret. So why the component is null 
>> in the DefaultCaret? That because the caret has already been 
>> deinstalled. It seems to be an order problem of mouse event and the 
>> event which endCompositon sent. The endComposition will exchange the 
>> caret and deinstall the old one. On the other hand, mouse click event 
>> was happening on the old caret. So the component of the old caret is 
>> null now. NPE happens.
> It looks that you are trying to fix the consequence, but not the root 
> of the problem. The endComposition method shouldn't send anything to 
> deinstalled DefaultCaret. I think the previous version of the fix was 
> much closer than this one.
>
> Regards, Pavel
Hi Pavel,

The problem is how should we deal with the uncommitted compose character 
when endComposition.
1. Remain the character. Not good, will remain in compose mode after 
endComposition.
2. Delete the character. I think it just like the cancelComposition. We 
have to send some thing to delete the characters which are already shown 
on the text area.

Here is a new patch which add a little bit logic in the endComposition 
method:
1. It still remain the null check in the mouseClick
2. It use cancelCompostion in the endComposition when in the compose mode.

Any idea?



-- 
Yours Charles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111028/5a572dfe/attachment.html 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch
Url: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111028/5a572dfe/patch.ksh 

From neil.richards at ngmr.net  Fri Oct 28 03:39:26 2011
From: neil.richards at ngmr.net (Neil Richards)
Date: Fri, 28 Oct 2011 11:39:26 +0100
Subject: <Swing Dev> code review request: 7049024: DnD fails with
 JTextArea and JTextField
In-Reply-To: <4EA95BF8.6010101@oracle.com>
References: <CAOo=rxVo3C=5nuzPksbCwVfTThkQeN=de4NxboVS+M8pnoL3EA@mail.gmail.com>
	<4E980143.6080800@oracle.com>
	<CAOo=rxW4mwTT127yzajYhYUQk5k8N-COZ_SF_aOefWjxB17fTw@mail.gmail.com>
	<4EA95BF8.6010101@oracle.com>
Message-ID: <1319798366.14435.92.camel@chalkhill>

On Thu, 2011-10-27 at 17:26 +0400, Pavel Porvatov wrote:
> Hi Sean, 
> > Hi Pavel, 
> > 
> > 
> >     Is there any update ? We are told to use this kind of copyright
> > for new files, I think there
> > should be some published agreements about it. 
> > 
> Unfortunately there are no news yet. Do you have some special reasons
> to keep IBM copyright there?

Hi Pavel,
I'm not sure I understand the problem here.

There have been several successful submissions previously committed
using exactly this form of copyright statement, eg:

http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/c0602036be5d
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/98688c4be64b
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/338c5b815ff2
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/c1e87a18e46a
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/28037efa90a3
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7d1b13126574

I'm sure if you check on your side you'll find that this is an accepted
and agreed form of statement for IBM folk to use (for IBM created
content, such as new testcases).

Regards, Neil

-- 
Unless stated above:
IBM email: neil_richards at uk.ibm.com
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From Alan.Bateman at oracle.com  Fri Oct 28 04:07:45 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 28 Oct 2011 12:07:45 +0100
Subject: <Swing Dev> code review request: 7049024: DnD fails with
 JTextArea and JTextField
In-Reply-To: <1319798366.14435.92.camel@chalkhill>
References: <CAOo=rxVo3C=5nuzPksbCwVfTThkQeN=de4NxboVS+M8pnoL3EA@mail.gmail.com>
	<4E980143.6080800@oracle.com>
	<CAOo=rxW4mwTT127yzajYhYUQk5k8N-COZ_SF_aOefWjxB17fTw@mail.gmail.com>
	<4EA95BF8.6010101@oracle.com> <1319798366.14435.92.camel@chalkhill>
Message-ID: <4EAA8D01.2000008@oracle.com>

On 28/10/2011 11:39, Neil Richards wrote:
> :
> Hi Pavel,
> I'm not sure I understand the problem here.
>
> There have been several successful submissions previously committed
> using exactly this form of copyright statement, eg:
>
> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/c0602036be5d
> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/98688c4be64b
> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/338c5b815ff2
> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/c1e87a18e46a
> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/28037efa90a3
> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7d1b13126574
>
> I'm sure if you check on your side you'll find that this is an accepted
> and agreed form of statement for IBM folk to use (for IBM created
> content, such as new testcases).
>
> Regards, Neil
Neil seems to have cc'ed me on this reply, I was otherwise not following 
this thread.

Pavel - we went through similar confusion on core-libs-dev a while back. 
Looking at this webrev, I don't see any issues as it's the same header 
that Neil, and his colleagues, have used on other tests that they have 
contributed.

-Alan.

From mark at klomp.org  Fri Oct 28 04:23:44 2011
From: mark at klomp.org (Mark Wielaard)
Date: Fri, 28 Oct 2011 13:23:44 +0200
Subject: <Swing Dev> code review request: 7049024: DnD fails with
 JTextArea and JTextField
In-Reply-To: <4EA95BF8.6010101@oracle.com>
References: <CAOo=rxVo3C=5nuzPksbCwVfTThkQeN=de4NxboVS+M8pnoL3EA@mail.gmail.com>
	<4E980143.6080800@oracle.com>
	<CAOo=rxW4mwTT127yzajYhYUQk5k8N-COZ_SF_aOefWjxB17fTw@mail.gmail.com>
	<4EA95BF8.6010101@oracle.com>
Message-ID: <1319801025.31834.1.camel@springer.wildebeest.org>

On Thu, 2011-10-27 at 17:26 +0400, Pavel Porvatov wrote:
> >     Is there any update ? We are told to use this kind of copyright 
> > for new files, I think there
> > should be some published agreements about it.
> Unfortunately there are no news yet. Do you have some special reasons to 
> keep IBM copyright there?

Assuming IBM contributes under the OCA then IBM keeps the copyright,
since the OCA isn't a copyright assignment. See also Mark Reinhold's
explanation:
http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000716.html

From pavel.porvatov at oracle.com  Sat Oct 29 06:14:41 2011
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Sat, 29 Oct 2011 17:14:41 +0400
Subject: <Swing Dev> Focus on image icons are not visible in javaws
 cache with high contrast mode
In-Reply-To: <CAOo=rxUw_JTkttdKUfUMcZsKhU_4JOJH5X96tm55tEySiJFi4A@mail.gmail.com>
References: <4e647dc3.82cde30a.3537.5eed@mx.google.com>
	<CAOo=rxWpsDbsS3GVaH8shVfu3NKr1gu2VRSOgmOgutQffWnxTQ@mail.gmail.com>
	<4E6A13ED.200@oracle.com>
	<CAOo=rxXAttuk+_dV9U39cjXtAt9XkGo3Pec9pJv2BE0NcCL=jQ@mail.gmail.com>
	<1316086740.27737.52.camel@chalkhill> <4E71F7D4.6000704@oracle.com>
	<1316098057.27737.111.camel@chalkhill>
	<4E732DB1.6070804@oracle.com>
	<CAOo=rxV3iW-2CM=NfOE9R+6fQm4P5jvCiJv77Ve_52aTRPDucQ@mail.gmail.com>
	<4EA8237B.4020407@oracle.com>
	<CAOo=rxUw_JTkttdKUfUMcZsKhU_4JOJH5X96tm55tEySiJFi4A@mail.gmail.com>
Message-ID: <4EABFC41.7040504@oracle.com>

Hi Sean,
>
>
>    It seems the black color for focus is set intentionally. If we set 
> it to "ControlTextColor ",
> the focus color may become red in above testcase, that's not what we want.
>    And I changed the color for all items listed with "3D object", the 
> focus remains black;
> maybe windows just uses "black" for focus color in normal mode, and 
> another color for
> high contrast mode.
>
>    However, the original patch posted is not right in this scenario. 
> I'll modify it. How about
> just uses white for high contrast mode ? As it simply uses black for 
> normal mode.
I'm not sure you can determine if high contrast mode is set... Every 
heuristic function for selection color can fail in some situation.

If somebody can take a look at source of 
ControlPaint::DrawFocusRectangle(Graphics, Rectangle) method (see 
http://msdn.microsoft.com/en-us/library/k2czzc46.aspx) and find out 
which colors uses .NET....

Regards, Pavel
>
> On Wed, Oct 26, 2011 at 11:12 PM, Pavel Porvatov 
> <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>> wrote:
>
>      Hi Sean,
>>     Hi Pavel,
>>
>>         From your image, I agree the focus color is not always the
>>     same with ControlTextColor,
>>     but I cannot recreate it. When I changed  color of "3D objects"
>>     to red, I got another image.
>>     Please have a look.
>     It seems you changed Color1, but not Color (which a little bit
>     lower then Color1)....
>>         I think your suggestion is reasonable, we'd better use the
>>     focus color from windows, but
>>     it maybe a problem to keep 100% the same, I still not found if
>>     there is a document for the
>>     focus color.
>     Yes, the MS documentation about focus color is the best way to fix
>     the bug. Can anybody point to such document?
>
>     Regards, Pavel
>
>>
>>     On Fri, Sep 16, 2011 at 7:06 PM, Pavel Porvatov
>>     <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>> wrote:
>>
>>         Hi Neil,
>>
>>             On Thu, 2011-09-15 at 17:04 +0400, Pavel Porvatov wrote:
>>
>>                 Hi Neil,
>>
>>                     On Wed, 2011-09-14 at 14:14 +0800, Sean Chou wrote:
>>
>>                         Hi Pavel,
>>
>>
>>                             I reported a bug there yesterday,
>>                         http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7089914
>>                             So far, I'm not sure if Windows use
>>                         ControlTextColor, I'll check
>>                         it.
>>
>>                     For ease of review, I've uploaded Sean's change
>>                     as a webrev [1].
>>
>>                     With the change, I see the following
>>                     focus-related color settings in the
>>                     WindowsLookAndFeel:
>>
>>                     Button.focus:           ControlTextColor
>>                     Checkbox.focus:         ControlTextColor
>>                     RadioButton.focus:      ControlTextColor
>>                     Slider.focus:           ControlDarkShadowColor
>>                     TabbedPane.focus:       ControlTextColor
>>                     ToggleButton.focus:     ControlTextColor
>>
>>                     So the change of setting for Button, Checkbox and
>>                     RadioButton conforms
>>                     to what is already used for TabbedPane and
>>                     ToggleButton.
>>
>>                 But doesn't conform to Slider.focus...
>>
>>             Are you recommending that Slider.focus should be changed to
>>             ControlTextColor too ?
>>
>>         No, I meant that we cannot fix some bugs by copy-paste method.
>>
>>                          From it's name, it's not entirely obvious to
>>                         me that 'ControlTextColor'
>>
>>                     is really the ideal setting to use here, but it's
>>                     also clear that it's a
>>                     far better setting to use than the current
>>                     hard-coded 'black'.
>>
>>                 Yes, of course. The last question is which color is
>>                 correct. We can't
>>                 change one incorrect color to another incorrect color...
>>
>>             I guess I hope that some knowledgeable person might be
>>             able to suggest /
>>             corroborate / refute the choice of setting here.
>>
>>             It seems worse to consider sticking with a hard-coded,
>>             un-configurable
>>             value that has been demonstrated to cause problems, than
>>             to use a
>>             setting whose value can at least be configured, in
>>             practice fixes the
>>             problem's symptoms, and is already used in most other
>>             similar contexts
>>             within the same look&  feel.
>>
>>
>>             Suggestions for how to improve things further are always
>>             welcome.
>>
>>         Your points sounds good. But as I said: we can't change one
>>         incorrect color to another incorrect color (doesn't matter
>>         configurable it or not). I attached  the screenshot that
>>         shows that ControlTextColor is not always equal to color of
>>         selection frame (to reproduce this image press the Advanced
>>         button and change color of "3D objects" to red).
>>
>>         Regards, Pavel
>>
>>
>>
>>
>>     -- 
>>     Best Regards,
>>     Sean Chou
>>
>
>
>
>
> -- 
> Best Regards,
> Sean Chou
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111029/40fae249/attachment.html 

From pavel.porvatov at oracle.com  Sat Oct 29 06:33:28 2011
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Sat, 29 Oct 2011 17:33:28 +0400
Subject: <Swing Dev> code review request: 7049024: DnD fails with
 JTextArea and JTextField
In-Reply-To: <4EAA8D01.2000008@oracle.com>
References: <CAOo=rxVo3C=5nuzPksbCwVfTThkQeN=de4NxboVS+M8pnoL3EA@mail.gmail.com>
	<4E980143.6080800@oracle.com>
	<CAOo=rxW4mwTT127yzajYhYUQk5k8N-COZ_SF_aOefWjxB17fTw@mail.gmail.com>
	<4EA95BF8.6010101@oracle.com> <1319798366.14435.92.camel@chalkhill>
	<4EAA8D01.2000008@oracle.com>
Message-ID: <4EAC00A8.6090100@oracle.com>

Hi all,
> On 28/10/2011 11:39, Neil Richards wrote:
>> :
>> Hi Pavel,
>> I'm not sure I understand the problem here.
>>
>> There have been several successful submissions previously committed
>> using exactly this form of copyright statement, eg:
>>
>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/c0602036be5d
>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/98688c4be64b
>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/338c5b815ff2
>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/c1e87a18e46a
>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/28037efa90a3
>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7d1b13126574
>>
>> I'm sure if you check on your side you'll find that this is an accepted
>> and agreed form of statement for IBM folk to use (for IBM created
>> content, such as new testcases).
>>
>> Regards, Neil
> Neil seems to have cc'ed me on this reply, I was otherwise not 
> following this thread.
>
> Pavel - we went through similar confusion on core-libs-dev a while 
> back. Looking at this webrev, I don't see any issues as it's the same 
> header that Neil, and his colleagues, have used on other tests that 
> they have contributed.
>
I don't see problems with the header now as well, because I got approve 
for this copyright a couple days ago... So I will commit the fix soon.

> Assuming IBM contributes under the OCA then IBM keeps the copyright,
> since the OCA isn't a copyright assignment. See also Mark Reinhold's
> explanation:
> http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000716.html
That an old explanation. Situation could be changed since that time...

Regards, Pavel

From linuxhippy at gmail.com  Sat Oct 29 12:07:44 2011
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Sat, 29 Oct 2011 21:07:44 +0200
Subject: <Swing Dev> May AbstractButton.doClick() be called by non-edt
	threads?
Message-ID: <CAFvQSYTOTrifEP6tqmxdnfu81HuG_B3RwnEwyuTMSKVNJHp1NQ@mail.gmail.com>

Hi,

I recently got a really strange NPE when running Java2Demo, and by
looking at the code it seems this NPE can only be caused by threading
violations.
(Component.maxSizeSet set to true, while Component.maxSize not visible)

I had a look at Java2Demo's source, where I found code like this
(ClipAnim.DemoControls.run()):

@Override
        public void run() {
            ((AbstractButton) toolbar.getComponentAtIndex(2)).doClick();
        }

According to CustomControls.start(), this overriden run-method is
executed on a fresh thread, so outside of the EDT.
May AbstractButton.doClick() be called from outside the EDT?

Furthermore, is there any reason CustomControls.stop() is
synchronized, while start() isn't?

Thanks, Clemens


Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
	at java.awt.Dimension.<init>(Dimension.java:111)
	at java.awt.Component.getMaximumSize(Component.java:2751)
	at java.awt.Container.getMaximumSize(Container.java:1887)
	at javax.swing.JComponent.getMaximumSize(JComponent.java:1698)
	at javax.swing.BoxLayout.checkRequests(BoxLayout.java:484)
	at javax.swing.BoxLayout.preferredLayoutSize(BoxLayout.java:300)
	at javax.swing.JToolBar$DefaultToolBarLayout.preferredLayoutSize(JToolBar.java:771)
	at java.awt.Container.preferredSize(Container.java:1788)
	at java.awt.Container.getPreferredSize(Container.java:1773)
	at javax.swing.JComponent.getPreferredSize(JComponent.java:1662)
	at java.awt.FlowLayout.layoutContainer(FlowLayout.java:609)
	at java.awt.Container.layout(Container.java:1503)
	at java.awt.Container.doLayout(Container.java:1492)
	at java.awt.Container.validateTree(Container.java:1688)
	at java.awt.Container.validateTree(Container.java:1697)
	at java.awt.Container.validateTree(Container.java:1697)
	at java.awt.Container.validateTree(Container.java:1697)
	at java.awt.Container.validateTree(Container.java:1697)
	at java.awt.Container.validateTree(Container.java:1697)
	at java.awt.Container.validateTree(Container.java:1697)
	at java.awt.Container.validateTree(Container.java:1697)
	at java.awt.Container.validateTree(Container.java:1697)
	at java.awt.Container.validateTree(Container.java:1697)
	at java.awt.Container.validate(Container.java:1623)
	at javax.swing.RepaintManager.validateInvalidComponents(RepaintManager.java:653)
	at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1620)
	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)


Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
	at javax.swing.BoxLayout.preferredLayoutSize(BoxLayout.java:301)
	at javax.swing.JToolBar$DefaultToolBarLayout.preferredLayoutSize(JToolBar.java:771)
	at java.awt.Container.preferredSize(Container.java:1788)
	at java.awt.Container.getPreferredSize(Container.java:1773)
	at javax.swing.JComponent.getPreferredSize(JComponent.java:1662)
	at java.awt.FlowLayout.layoutContainer(FlowLayout.java:609)
	at java.awt.Container.layout(Container.java:1503)
	at java.awt.Container.doLayout(Container.java:1492)
	at java.awt.Container.validateTree(Container.java:1688)
	at java.awt.Container.validateTree(Container.java:1697)
	at java.awt.Container.validateTree(Container.java:1697)
	at java.awt.Container.validateTree(Container.java:1697)
	at java.awt.Container.validateTree(Container.java:1697)
	at java.awt.Container.validateTree(Container.java:1697)
	at java.awt.Container.validate(Container.java:1623)
	at javax.swing.plaf.basic.BasicTabbedPaneUI.ensureCurrentLayout(BasicTabbedPaneUI.java:1446)
	at javax.swing.plaf.basic.BasicTabbedPaneUI.paint(BasicTabbedPaneUI.java:787)
	at javax.swing.plaf.metal.MetalTabbedPaneUI.paint(MetalTabbedPaneUI.java:843)
	at javax.swing.plaf.metal.MetalTabbedPaneUI.update(MetalTabbedPaneUI.java:724)
	at javax.swing.JComponent.paintComponent(JComponent.java:778)
	at javax.swing.JComponent.paint(JComponent.java:1054)
	at javax.swing.JComponent.paintChildren(JComponent.java:887)
	at javax.swing.JComponent.paint(JComponent.java:1063)
	at javax.swing.JComponent.paintToOffscreen(JComponent.java:5221)
	at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:295)
	at javax.swing.RepaintManager.paint(RepaintManager.java:1206)
	at javax.swing.JComponent._paintImmediately(JComponent.java:5169)
	at javax.swing.JComponent.paintImmediately(JComponent.java:4980)
	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:770)
	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:728)
	at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:677)
	at javax.swing.RepaintManager.access$700(RepaintManager.java:59)
	at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1621)
	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)

From sergey.malenkov at sun.com  Mon Oct 31 09:02:29 2011
From: sergey.malenkov at sun.com (sergey.malenkov at sun.com)
Date: Mon, 31 Oct 2011 16:02:29 +0000
Subject: <Swing Dev> hg: jdk8/swing/jdk: 7087429: Constructor
	of	java.beans.PropertyChangeEvent should declare thrown NPE
	for	null source
Message-ID: <20111031160304.5698A471DA@hg.openjdk.java.net>

Changeset: 9270a13fe24d
Author:    malenkov
Date:      2011-10-31 20:01 +0400
URL:       http://hg.openjdk.java.net/jdk8/swing/jdk/rev/9270a13fe24d

7087429: Constructor of java.beans.PropertyChangeEvent should declare thrown NPE for null source
Reviewed-by: rupashka

! src/share/classes/java/beans/PropertyChangeEvent.java
+ test/java/beans/PropertyChangeSupport/Test7087429.java