From leonid.romanov at oracle.com  Thu Jan 10 10:24:52 2013
From: leonid.romanov at oracle.com (Leonid Romanov)
Date: Thu, 10 Jan 2013 10:24:52 -0000
Subject: <Swing Dev> [8] Review request for 8003978
 closed/javax/swing/JRootPane/bug4670486.java fails since jdk7u12b01 on
 macosx
In-Reply-To: <50C0B33F.2040903@oracle.com>
References: <50C0B33F.2040903@oracle.com>
Message-ID: <50864FA5.2060809@oracle.com>

Hi,
Are you sure that is is a right fix? I'm asking because Apple JDK 6 
works fine with Alt+U as a menu accelerator.

On Dec 6, 2012, at 7:01 PM, Alexander Scherbatiy 
<alexandr.scherbatiy at oracle.com> wrote:

>
> Hello,
>
> Could you review the fix:
> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003978
> webrev: http://cr.openjdk.java.net/~alexsch/8003978/webrev.00
>
>  The test fails because now Alt+U key combination returns right dead 
> key code instead of the key code for the 'U' key.
>  The solution is to use Ctrl+Alt key combination for menu mnemonics 
> like it is done for button mnemonics.
>
>  The fix uses SunToolkit getFocusAcceleratorKeyMask() method to get 
> the system depended mnemonic key mask and puts it to the 
> Menu.shortcutKeys property in the BasicLookAndFeel.
>
> Thanks,
> Alexandr.
>




From alexandr.scherbatiy at oracle.com  Thu Jan 10 10:48:30 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 10 Jan 2013 14:48:30 +0400
Subject: <Swing Dev> [8] Review request for 8003978
 closed/javax/swing/JRootPane/bug4670486.java fails since jdk7u12b01 on
 macosx
In-Reply-To: <50864FA5.2060809@oracle.com>
References: <50C0B33F.2040903@oracle.com> <50864FA5.2060809@oracle.com>
Message-ID: <50EE9C7E.7090708@oracle.com>

On 10/23/2012 12:04 PM, Leonid Romanov wrote:
> Hi,
> Are you sure that is is a right fix? I'm asking because Apple JDK 6 
> works fine with Alt+U as a menu accelerator.
      I have done it in the same way as it fixed for the button mnemonics.
      Apple JDK 6 uses Alt+Key for the button mnemonics. It is changed 
to Ctrl+Alt+Key in the JDK 7.

      Thanks,
      Alexandr.

>
> On Dec 6, 2012, at 7:01 PM, Alexander Scherbatiy 
> <alexandr.scherbatiy at oracle.com> wrote:
>
>>
>> Hello,
>>
>> Could you review the fix:
>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003978
>> webrev: http://cr.openjdk.java.net/~alexsch/8003978/webrev.00
>>
>>  The test fails because now Alt+U key combination returns right dead 
>> key code instead of the key code for the 'U' key.
>>  The solution is to use Ctrl+Alt key combination for menu mnemonics 
>> like it is done for button mnemonics.
>>
>>  The fix uses SunToolkit getFocusAcceleratorKeyMask() method to get 
>> the system depended mnemonic key mask and puts it to the 
>> Menu.shortcutKeys property in the BasicLookAndFeel.
>>
>> Thanks,
>> Alexandr.
>>
>
>



From alexandr.scherbatiy at oracle.com  Thu Jan 10 11:41:39 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 10 Jan 2013 15:41:39 +0400
Subject: <Swing Dev> [8] Review request for 8004298 NPE in
	WindowsTreeUI.ensureRowsAreVisible
Message-ID: <50EEA8F3.8040804@oracle.com>


Hello,

Could you review the fix:
   bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004298
   webrev: http://cr.openjdk.java.net/~alexsch/8004298/webrev.00

   The getPathBounds() method can return null under certain circumstances.
   The fix checks this before using the testRect variable.

Thanks,
Alexandr.



From leonid.romanov at oracle.com  Thu Jan 10 08:57:02 2013
From: leonid.romanov at oracle.com (Leonid Romanov)
Date: Thu, 10 Jan 2013 12:57:02 +0400
Subject: <Swing Dev> [8] Review request for 8003978
 closed/javax/swing/JRootPane/bug4670486.java fails since jdk7u12b01 on
 macosx
In-Reply-To: <50EE9C7E.7090708@oracle.com>
References: <50C0B33F.2040903@oracle.com> <50864FA5.2060809@oracle.com>
	<50EE9C7E.7090708@oracle.com>
Message-ID: <50EE825E.6060400@oracle.com>

In this case, I'm ok with the fix.

On 10/01/2013 14:48, Alexander Scherbatiy wrote:
> On 10/23/2012 12:04 PM, Leonid Romanov wrote:
>> Hi,
>> Are you sure that is is a right fix? I'm asking because Apple JDK 6 
>> works fine with Alt+U as a menu accelerator.
>      I have done it in the same way as it fixed for the button mnemonics.
>      Apple JDK 6 uses Alt+Key for the button mnemonics. It is changed 
> to Ctrl+Alt+Key in the JDK 7.
>
>      Thanks,
>      Alexandr.
>
>>
>> On Dec 6, 2012, at 7:01 PM, Alexander Scherbatiy 
>> <alexandr.scherbatiy at oracle.com> wrote:
>>
>>>
>>> Hello,
>>>
>>> Could you review the fix:
>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003978
>>> webrev: http://cr.openjdk.java.net/~alexsch/8003978/webrev.00
>>>
>>>  The test fails because now Alt+U key combination returns right dead 
>>> key code instead of the key code for the 'U' key.
>>>  The solution is to use Ctrl+Alt key combination for menu mnemonics 
>>> like it is done for button mnemonics.
>>>
>>>  The fix uses SunToolkit getFocusAcceleratorKeyMask() method to get 
>>> the system depended mnemonic key mask and puts it to the 
>>> Menu.shortcutKeys property in the BasicLookAndFeel.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>
>>
>


From jaroslav.tulach at oracle.com  Thu Jan 10 11:47:27 2013
From: jaroslav.tulach at oracle.com (Jaroslav Tulach)
Date: Thu, 10 Jan 2013 12:47:27 +0100
Subject: <Swing Dev> [8] Review request for 8004298 NPE in
	WindowsTreeUI.ensureRowsAreVisible
In-Reply-To: <50EEA8F3.8040804@oracle.com>
References: <50EEA8F3.8040804@oracle.com>
Message-ID: <1373998.uOXT1KJYW5@logouticek>

Dne ?t 10. ledna 2013 15:41:39, Alexander Scherbatiy napsal(a):
> Hello,
> 
> Could you review the fix:
>    bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004298
>    webrev: http://cr.openjdk.java.net/~alexsch/8004298/webrev.00
> 
>    The getPathBounds() method can return null under certain circumstances.
>    The fix checks this before using the testRect variable.

Looks safer to me.
-jt



From Sergey.Bylokhov at oracle.com  Thu Jan 10 12:05:33 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 10 Jan 2013 16:05:33 +0400
Subject: <Swing Dev> [8] Review request for 8004298 NPE in
	WindowsTreeUI.ensureRowsAreVisible
In-Reply-To: <50EEA8F3.8040804@oracle.com>
References: <50EEA8F3.8040804@oracle.com>
Message-ID: <50EEAE8D.2090903@oracle.com>

Hi, Alexander.
Fix looks good. Probably it is possible to create a test for it?

10.01.2013 15:41, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the fix:
>   bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004298
>   webrev: http://cr.openjdk.java.net/~alexsch/8004298/webrev.00
>
>   The getPathBounds() method can return null under certain circumstances.
>   The fix checks this before using the testRect variable.
>
> Thanks,
> Alexandr.
>


-- 
Best regards, Sergey.



From alexandr.scherbatiy at oracle.com  Thu Jan 10 13:25:23 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 10 Jan 2013 17:25:23 +0400
Subject: <Swing Dev> [8] Review request for 7166409 bug4331515.java fail
 with NullPointerException on ubuntu10.04-x86 for JDK8
Message-ID: <50EEC143.1010806@oracle.com>


Hello,

Could you review the fix:
   bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7166409
   webrev: http://cr.openjdk.java.net/~alexsch/7166409/webrev.00

The test passes on JDK 6 because it catches and ignores the 
"NumberFormatException: multiple points".
After fixing the NumberFormatException in JDK 7 the test fails with the 
NPE because "win.highContrast.on" property returns null.
The fix treats the null value of the "win.highContrast.on" property as 
false.


Thanks,
Alexandr.



From Sergey.Bylokhov at oracle.com  Thu Jan 10 13:44:47 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 10 Jan 2013 17:44:47 +0400
Subject: <Swing Dev> [8] Review request for 7166409 bug4331515.java fail
 with NullPointerException on ubuntu10.04-x86 for JDK8
In-Reply-To: <50EEC143.1010806@oracle.com>
References: <50EEC143.1010806@oracle.com>
Message-ID: <50EEC5CF.6030002@oracle.com>

Hi, Alexander.
Fix looks fine. It would be good to fix typo: Fallback value is never 
used *bacause*.

10.01.2013 17:25, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the fix:
>   bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7166409
>   webrev: http://cr.openjdk.java.net/~alexsch/7166409/webrev.00
>
> The test passes on JDK 6 because it catches and ignores the 
> "NumberFormatException: multiple points".
> After fixing the NumberFormatException in JDK 7 the test fails with 
> the NPE because "win.highContrast.on" property returns null.
> The fix treats the null value of the "win.highContrast.on" property as 
> false.
>
>
> Thanks,
> Alexandr.
>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20130110/cf6b49b4/attachment.html>

From swingler at apple.com  Thu Jan 10 19:41:15 2013
From: swingler at apple.com (Mike Swingler)
Date: Thu, 10 Jan 2013 11:41:15 -0800
Subject: <Swing Dev> [8] Review request for 8003978
 closed/javax/swing/JRootPane/bug4670486.java fails since jdk7u12b01 on
 macosx
In-Reply-To: <50EE9C7E.7090708@oracle.com>
References: <50C0B33F.2040903@oracle.com> <50864FA5.2060809@oracle.com>
	<50EE9C7E.7090708@oracle.com>
Message-ID: <0BAC87B7-653C-4A23-A134-00C17AE9DEE5@apple.com>

Ctrl-Alt always worked on Apple's Java SE 6, and it is simply unfortunate that Alt also worked, because it collides with the system input methods (Alt-U in this case being the dead-key you hit before typing a vowel to put an umlaut on top of it). This lead people to mistakenly believe that Alt alone was the "proper" mnemonic key, and resulted in endless confusion when a text input area was focused.

Regards,
Mike Swingler
Apple Inc.

On Jan 10, 2013, at 2:48 AM, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:

> On 10/23/2012 12:04 PM, Leonid Romanov wrote:
>> Hi,
>> Are you sure that is is a right fix? I'm asking because Apple JDK 6 works fine with Alt+U as a menu accelerator.
>     I have done it in the same way as it fixed for the button mnemonics.
>     Apple JDK 6 uses Alt+Key for the button mnemonics. It is changed to Ctrl+Alt+Key in the JDK 7.
> 
>     Thanks,
>     Alexandr.
> 
>> 
>> On Dec 6, 2012, at 7:01 PM, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>> 
>>> 
>>> Hello,
>>> 
>>> Could you review the fix:
>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003978
>>> webrev: http://cr.openjdk.java.net/~alexsch/8003978/webrev.00
>>> 
>>> The test fails because now Alt+U key combination returns right dead key code instead of the key code for the 'U' key.
>>> The solution is to use Ctrl+Alt key combination for menu mnemonics like it is done for button mnemonics.
>>> 
>>> The fix uses SunToolkit getFocusAcceleratorKeyMask() method to get the system depended mnemonic key mask and puts it to the Menu.shortcutKeys property in the BasicLookAndFeel.
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
>> 
>> 
> 



From alexandr.scherbatiy at oracle.com  Mon Jan 14 10:14:16 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 14 Jan 2013 14:14:16 +0400
Subject: <Swing Dev> [8] Request for review: 7124525 [macosx] No
 animation on certain Swing components in Aqua LaF
In-Reply-To: <50DDA70A.9050806@oracle.com>
References: <50DDA70A.9050806@oracle.com>
Message-ID: <50F3DA78.2060701@oracle.com>


    The fix looks good for me.

    Thanks,
    Alexandr.

On 12/28/2012 6:04 PM, Sergey Bylokhov wrote:
> Hello,
> Please review the fix.
> Change description:
>     - ImageCache shouldn't cache images for animated components + cleanup.
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124525
> Webrev can be found at: http://cr.openjdk.java.net/~serb/7124525/webrev.00
>
> -- 
> Best regards, Sergey.



From Sergey.Bylokhov at oracle.com  Mon Jan 14 13:26:54 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 14 Jan 2013 17:26:54 +0400
Subject: <Swing Dev> [8] Review request for 8003978
 closed/javax/swing/JRootPane/bug4670486.java fails since jdk7u12b01 on
 macosx
In-Reply-To: <50C0B842.4050806@oracle.com>
References: <50C0B33F.2040903@oracle.com> <50C0B697.4090904@oracle.com>
	<50C0B842.4050806@oracle.com>
Message-ID: <50F4079E.8010006@oracle.com>

Hi, Alexander.
Fix look good.

06.12.2012 19:22, Alexander Scherbatiy wrote:
> On 12/6/2012 7:15 PM, Sergey Bylokhov wrote:
>> Hi, Alexander.
>> Does motif l&f work on macosx with META_MASK - MotifLookAndFeel.java:?
>      Yes, it does.
>
>    Thanks,
>    Alexandr.
>
>>
>> 633             "Menu.shortcutKeys", new int[]{
>>  634                 SwingUtilities2.getSystemMnemonicKeyMask(),
>>  635                 KeyEvent.META_MASK
>>  636             },
>>
>>
>> 06.12.2012 19:01, Alexander Scherbatiy wrote:
>>>
>>> Hello,
>>>
>>> Could you review the fix:
>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003978
>>> webrev: http://cr.openjdk.java.net/~alexsch/8003978/webrev.00
>>>
>>>   The test fails because now Alt+U key combination returns right 
>>> dead key code instead of the key code for the 'U' key.
>>>   The solution is to use Ctrl+Alt key combination for menu mnemonics 
>>> like it is done for button mnemonics.
>>>
>>>   The fix uses SunToolkit getFocusAcceleratorKeyMask() method to get 
>>> the system depended mnemonic key mask and puts it to the 
>>> Menu.shortcutKeys property in the BasicLookAndFeel.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>
>>
>


-- 
Best regards, Sergey.



From konstantin.shefov at oracle.com  Wed Jan 16 07:50:24 2013
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Wed, 16 Jan 2013 11:50:24 +0400
Subject: <Swing Dev> [8] Request for approval for CR 8004693 - TEST_BUG:
 java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java
 fails
In-Reply-To: <50A62B1E.4010607@oracle.com>
References: <50A64219.4080409@oracle.com> <50A62B1E.4010607@oracle.com>
Message-ID: <50F65BC0.8070202@oracle.com>

Hello,

Please review a fix for the issue:

8004693 - TEST_BUG: 
java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java 
fails

The webrev is http://cr.openjdk.java.net/~kshefov/8004693/webrev.00/

This test is broken.

The test tells the AWT EventQueue to run the method 
DefaultPolicyChange_Swing.runTestSwing() (which contains all the actual 
test code) at a later time (EventQueue.invokeLater(Runnable)). By adding 
a few printlns to that function, it's easy to see that it starts to run 
but never finishes. In particular, it never reaches any of the actual 
test code.

First, "((SunToolkit) SunToolkit.getDefaultToolkit()).realSync();" 
should be added after EventQueue.invokeLater() call for all procedures 
in this call to be run.

After this test starts to fail. It fails since jdk 7 fcs.

The fail is caused because test is corrupted.

The test should compare JFrame, JWindow and JDialog 
FocusTraversalPolicies before 
"currentKFM.setDefaultFocusTraversalPolicy(newFTP)" call and after this 
call. But instead the test compares something different.

In the current variant of this test we see:

    FocusTraversalPolicy defaultFTP = 
currentKFM.getDefaultFocusTraversalPolicy();

It returns object java.awt.DefaultFocusTraversalPolicy at 5fe2d461.

But JFrame, JWindow and JDialog objects initially have 
"javax.swing.LayoutFocusTraversalPolicy at 2f81dd44" policy.
After "currentKFM.setDefaultFocusTraversalPolicy(newFTP)" call they 
still have javax.swing.LayoutFocusTraversalPolicy at 2f81dd44.

So test should not fail, but it fails.

Test needs to be fixed.

Thanks,
Konstantin



From konstantin.shefov at oracle.com  Wed Jan 16 07:54:57 2013
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Wed, 16 Jan 2013 11:54:57 +0400
Subject: <Swing Dev> [8] Review request for 7124209 [macosx]
 SpringLayout issue. BASELINE is not in the range: [NORTH, SOUTH]
In-Reply-To: <50B63EB3.6000703@oracle.com>
References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com>
	<509A77A0.4080901@oracle.com> <509B9F57.4000304@oracle.com>
	<509BA4B7.2060506@oracle.com> <509CC335.2010908@oracle.com>
	<50AE0D17.3070102@oracle.com> <50AE2CF1.5010905@oracle.com>
	<50B63EB3.6000703@oracle.com>
Message-ID: <50F65CD1.2090207@oracle.com>

REMINDER

On 28-Nov-12 20:41, Konstantin Shefov wrote:
> Could you please look at this test fix?
> Webrev: http://cr.openjdk.java.net/~kshefov/7124209/webrev.02
> (already approved by Alexander Scherbatiy)
>
> On 22-Nov-12 17:47, Anthony Petrov wrote:
>> I'm not a Swing expert, but since the test is simply moved from
>> closed repos, I guess it looks fine.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 11/22/12 15:31, Konstantin Shefov wrote:
>>> Please review a fix for this issue:
>>> http://cr.openjdk.java.net/~kshefov/7124209/webrev.02
>>>
>>> On 09-Nov-12 12:47, Alexander Scherbatiy wrote:
>>>> On 11/8/2012 4:25 PM, Konstantin Shefov wrote:
>>>>> http://cr.openjdk.java.net/~kshefov/7124209/webrev.02/
>>>>> <http://cr.openjdk.java.net/%7Ekshefov/7124209/webrev.02/>
>>>>
>>>> The fix looks good for me.
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>>>
>>>>> On 08-Nov-12 16:02, Alexander Scherbatiy wrote:
>>>>>> On 11/7/2012 7:00 PM, Konstantin Shefov wrote:
>>>>>>> Please, look at modified fix:
>>>>>>> http://cr.openjdk.java.net/~kshefov/7124209/webrev.01/
>>>>>>> <http://cr.openjdk.java.net/%7Ekshefov/7124209/webrev.01/>
>>>>>>
>>>>>> Try/catch block in the main method catches RuntimeException as well.
>>>>>> So the jtreg passes the test even it really fails.
>>>>>> It is also a good idea to fail the test if the
>>>>>> SwingUtilities.invokeAndWait() throws an exception because it is
>>>>>> also a wrong situation.
>>>>>>
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>
>>>>>>>
>>>>>>> On 01-Nov-12 17:45, Alexander Scherbatiy wrote:
>>>>>>>>
>>>>>>>> - Please, remove comments and unnecessary System.out from the fix
>>>>>>>> - Create and check swing components on EDT. Avoiding this rule can
>>>>>>>> leads to unpredictable test failures.
>>>>>>>> - Swing tests usually have bugBugID.java or some meaningful name.
>>>>>>>> - It is better to use the swing-dev at openjdk.java.net alias to
>>>>>>>> review the swing tests.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alexandr.
>>>>>>>>
>>>>>>>> On 10/31/2012 7:06 PM, Konstantin Shefov wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Please review a fix for the issue:
>>>>>>>>>
>>>>>>>>> 7124209 [macosx] SpringLayout issue. BASELINE is not in the
>>>>>>>>> range: [NORTH, SOUTH]
>>>>>>>>>
>>>>>>>>> The webrev is http://cr.openjdk.java.net/~kshefov/7124209/webrev/
>>>>>>>>>
>>>>>>>>> It is suggested to move the test to open jdk.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Konstantin
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>


From Vladislav.Karnaukhov at oracle.com  Wed Jan 16 12:58:23 2013
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Wed, 16 Jan 2013 16:58:23 +0400
Subject: <Swing Dev> [8] Review request for 4199622 RFE: JComboBox shouldn't
 sending ActionEvents for keyboard navigation
Message-ID: <50F6A3EF.3000705@oracle.com>

Hello,

could you please review the fix:
bug: http://bugs.sun.com/view_bug.do?bug_id=4199622
webrev: http://cr.openjdk.java.net/~vkarnauk/4199622/webrev.00/

The fix uses new property to disable ActionEvent generation in 
JComboBox' drop-down window when an user navigates with keyboard.
The fix works only when property is explicitly set by a developer; 
otherwise default JComboBox' behavior doesn't change.

Regards,
- Vlad


From alexandr.scherbatiy at oracle.com  Wed Jan 16 13:28:51 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 16 Jan 2013 17:28:51 +0400
Subject: <Swing Dev> [8] Review request for 8004298 NPE in
	WindowsTreeUI.ensureRowsAreVisible
In-Reply-To: <50EEAE8D.2090903@oracle.com>
References: <50EEA8F3.8040804@oracle.com> <50EEAE8D.2090903@oracle.com>
Message-ID: <50F6AB13.7070706@oracle.com>


  Could you review the updated fix:
    http://cr.openjdk.java.net/~alexsch/8004298/webrev.02/

   - The test case is added.
     There are no exact steps to reproduce the issue so I just use the 
idea to override the getPathBounds() method
        from the fix 
http://hg.openjdk.java.net/jdk8/awt/jdk/rev/bd175c70684c

   Thanks,
   Alexandr.


On 1/10/2013 4:05 PM, Sergey Bylokhov wrote:
> Hi, Alexander.
> Fix looks good. Probably it is possible to create a test for it?
>
> 10.01.2013 15:41, Alexander Scherbatiy wrote:
>>
>> Hello,
>>
>> Could you review the fix:
>>   bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004298
>>   webrev: http://cr.openjdk.java.net/~alexsch/8004298/webrev.00
>>
>>   The getPathBounds() method can return null under certain 
>> circumstances.
>>   The fix checks this before using the testRect variable.
>>
>> Thanks,
>> Alexandr.
>>
>
>



From alexander.potochkin at oracle.com  Wed Jan 16 13:45:58 2013
From: alexander.potochkin at oracle.com (Alexander Potochkin)
Date: Wed, 16 Jan 2013 17:45:58 +0400
Subject: <Swing Dev> [8] Review request for 4199622 RFE: JComboBox
 shouldn't sending ActionEvents for keyboard navigation
In-Reply-To: <50F6A3EF.3000705@oracle.com>
References: <50F6A3EF.3000705@oracle.com>
Message-ID: <50F6AF16.6010400@oracle.com>

Hello Vlad

The fix overall looks good,
however there are some comments:

it is better to use UIManager.getBoolean() in this case,
it will enable you to skip the null check

in the test you should use SunToolkit.realSync() instead of sleep()
(please also call realSync in the very beginning of the test method to 
wait for focus to come)
and define boolean noAction as volatile since you are accessing it on 
two threads

Thanks
alexp

On 1/16/2013 4:58 PM, Vladislav Karnaukhov wrote:
> Hello,
>
> could you please review the fix:
> bug: http://bugs.sun.com/view_bug.do?bug_id=4199622
> webrev: http://cr.openjdk.java.net/~vkarnauk/4199622/webrev.00/
>
> The fix uses new property to disable ActionEvent generation in 
> JComboBox' drop-down window when an user navigates with keyboard.
> The fix works only when property is explicitly set by a developer; 
> otherwise default JComboBox' behavior doesn't change.
>
> Regards,
> - Vlad


From Sergey.Malenkov at oracle.com  Wed Jan 16 13:29:23 2013
From: Sergey.Malenkov at oracle.com (Sergey Malenkov)
Date: Wed, 16 Jan 2013 17:29:23 +0400
Subject: <Swing Dev> [8] Review request for 8003400: JTree scrolling problem
 when using large model
Message-ID: <50F6AB33.1030807@oracle.com>

Hello,

Could you please review the following fix:
bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003400
fix: http://cr.openjdk.java.net/~malenkov/8003400.0/

JTree with the large model calculates widths for visible rows only. The 
problem is that the horizontal scroll bar appears after moving to the 
end and hides the last row. The automatic test is included.

Thanks,
SAM



From Vladislav.Karnaukhov at oracle.com  Wed Jan 16 14:04:37 2013
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Wed, 16 Jan 2013 18:04:37 +0400
Subject: <Swing Dev> [8] Review request for 4199622 RFE: JComboBox
 shouldn't sending ActionEvents for keyboard navigation
In-Reply-To: <50F6AF16.6010400@oracle.com>
References: <50F6A3EF.3000705@oracle.com> <50F6AF16.6010400@oracle.com>
Message-ID: <50F6B375.2040802@oracle.com>

Hello Alex,

thanks for the review.

Please find a new version here: 
http://cr.openjdk.java.net/~vkarnauk/4199622/webrev.01/

Regards,
- Vlad

On 1/16/2013 05:45 PM, Alexander Potochkin wrote:
> Hello Vlad
>
> The fix overall looks good,
> however there are some comments:
>
> it is better to use UIManager.getBoolean() in this case,
> it will enable you to skip the null check
>
> in the test you should use SunToolkit.realSync() instead of sleep()
> (please also call realSync in the very beginning of the test method to 
> wait for focus to come)
> and define boolean noAction as volatile since you are accessing it on 
> two threads
>
> Thanks
> alexp
>
> On 1/16/2013 4:58 PM, Vladislav Karnaukhov wrote:
>> Hello,
>>
>> could you please review the fix:
>> bug: http://bugs.sun.com/view_bug.do?bug_id=4199622
>> webrev: http://cr.openjdk.java.net/~vkarnauk/4199622/webrev.00/
>>
>> The fix uses new property to disable ActionEvent generation in 
>> JComboBox' drop-down window when an user navigates with keyboard.
>> The fix works only when property is explicitly set by a developer; 
>> otherwise default JComboBox' behavior doesn't change.
>>
>> Regards,
>> - Vlad




From jaroslav.tulach at oracle.com  Wed Jan 16 14:16:18 2013
From: jaroslav.tulach at oracle.com (Jaroslav Tulach)
Date: Wed, 16 Jan 2013 15:16:18 +0100
Subject: <Swing Dev> [8] Review request for 8004298 NPE in
	WindowsTreeUI.ensureRowsAreVisible
In-Reply-To: <50F6AB13.7070706@oracle.com>
References: <50EEA8F3.8040804@oracle.com> <50EEAE8D.2090903@oracle.com>
	<50F6AB13.7070706@oracle.com>
Message-ID: <1861921.p9bJJpCBn5@logouticek>

Dne St 16. ledna 2013 17:28:51, Alexander Scherbatiy napsal(a):
>      There are no exact steps to reproduce the issue so I just use the 
> idea to override the getPathBounds() method

I am glad the idea becomes popular. 

>   Could you review the updated fix:
>     http://cr.openjdk.java.net/~alexsch/8004298/webrev.02/

As far as I can see the test is using the idea properly. If it passes OK, the 
fix is good.
-jt



From Sergey.Bylokhov at oracle.com  Wed Jan 16 14:46:08 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 16 Jan 2013 18:46:08 +0400
Subject: <Swing Dev> [8] Review request for 8004298 NPE in
	WindowsTreeUI.ensureRowsAreVisible
In-Reply-To: <50F6AB13.7070706@oracle.com>
References: <50EEA8F3.8040804@oracle.com> <50EEAE8D.2090903@oracle.com>
	<50F6AB13.7070706@oracle.com>
Message-ID: <50F6BD30.6060109@oracle.com>

Hi, Alexander.
Fix looks good.

16.01.2013 17:28, Alexander Scherbatiy wrote:
>
>  Could you review the updated fix:
>    http://cr.openjdk.java.net/~alexsch/8004298/webrev.02/
>
>   - The test case is added.
>     There are no exact steps to reproduce the issue so I just use the 
> idea to override the getPathBounds() method
>        from the fix 
> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/bd175c70684c
>
>   Thanks,
>   Alexandr.
>
>
> On 1/10/2013 4:05 PM, Sergey Bylokhov wrote:
>> Hi, Alexander.
>> Fix looks good. Probably it is possible to create a test for it?
>>
>> 10.01.2013 15:41, Alexander Scherbatiy wrote:
>>>
>>> Hello,
>>>
>>> Could you review the fix:
>>>   bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004298
>>>   webrev: http://cr.openjdk.java.net/~alexsch/8004298/webrev.00
>>>
>>>   The getPathBounds() method can return null under certain 
>>> circumstances.
>>>   The fix checks this before using the testRect variable.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>
>>
>


-- 
Best regards, Sergey.



From Sergey.Bylokhov at oracle.com  Wed Jan 16 15:20:49 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 16 Jan 2013 19:20:49 +0400
Subject: <Swing Dev> [8] Review request for 4199622 RFE: JComboBox
 shouldn't sending ActionEvents for keyboard navigation
In-Reply-To: <50F6B375.2040802@oracle.com>
References: <50F6A3EF.3000705@oracle.com> <50F6AF16.6010400@oracle.com>
	<50F6B375.2040802@oracle.com>
Message-ID: <50F6C551.30307@oracle.com>

Hi, Vladislav.
 From the bug description:
"When the user pops up a JComboBox (hits the spacebar for Metal L&F), 
and then tries to navigate with the arrow keys, any ActionListeners for 
that CB will have their actionPerformed methods called, and there isn't 
any information in the given ActionEvent to show that this was only a 
navigation action rather than a selection (spacebar) action."
I do not see a problem here, because "navigation action" is an action 
and so ActionEvent is posted in this case. Does somebody complains about it?
I am not sure but what about the case when the user change selection 
view mouseover? Is it possible?

16.01.2013 18:04, Vladislav Karnaukhov wrote:
> Hello Alex,
>
> thanks for the review.
>
> Please find a new version here: 
> http://cr.openjdk.java.net/~vkarnauk/4199622/webrev.01/
>
> Regards,
> - Vlad
>
> On 1/16/2013 05:45 PM, Alexander Potochkin wrote:
>> Hello Vlad
>>
>> The fix overall looks good,
>> however there are some comments:
>>
>> it is better to use UIManager.getBoolean() in this case,
>> it will enable you to skip the null check
>>
>> in the test you should use SunToolkit.realSync() instead of sleep()
>> (please also call realSync in the very beginning of the test method 
>> to wait for focus to come)
>> and define boolean noAction as volatile since you are accessing it on 
>> two threads
>>
>> Thanks
>> alexp
>>
>> On 1/16/2013 4:58 PM, Vladislav Karnaukhov wrote:
>>> Hello,
>>>
>>> could you please review the fix:
>>> bug: http://bugs.sun.com/view_bug.do?bug_id=4199622
>>> webrev: http://cr.openjdk.java.net/~vkarnauk/4199622/webrev.00/
>>>
>>> The fix uses new property to disable ActionEvent generation in 
>>> JComboBox' drop-down window when an user navigates with keyboard.
>>> The fix works only when property is explicitly set by a developer; 
>>> otherwise default JComboBox' behavior doesn't change.
>>>
>>> Regards,
>>> - Vlad
>
>


-- 
Best regards, Sergey.



From alexander.potochkin at oracle.com  Wed Jan 16 15:30:15 2013
From: alexander.potochkin at oracle.com (Alexander Potochkin)
Date: Wed, 16 Jan 2013 19:30:15 +0400
Subject: <Swing Dev> [8] Review request for 4199622 RFE: JComboBox
 shouldn't sending ActionEvents for keyboard navigation
In-Reply-To: <50F6B375.2040802@oracle.com>
References: <50F6A3EF.3000705@oracle.com> <50F6AF16.6010400@oracle.com>
	<50F6B375.2040802@oracle.com>
Message-ID: <50F6C787.8060701@oracle.com>

Hello Vlad

Looks good for me,
let's wait for one more reviewer to have a look

Thanks
alexp

On 1/16/2013 6:04 PM, Vladislav Karnaukhov wrote:
> Hello Alex,
>
> thanks for the review.
>
> Please find a new version here: 
> http://cr.openjdk.java.net/~vkarnauk/4199622/webrev.01/
>
> Regards,
> - Vlad
>
> On 1/16/2013 05:45 PM, Alexander Potochkin wrote:
>> Hello Vlad
>>
>> The fix overall looks good,
>> however there are some comments:
>>
>> it is better to use UIManager.getBoolean() in this case,
>> it will enable you to skip the null check
>>
>> in the test you should use SunToolkit.realSync() instead of sleep()
>> (please also call realSync in the very beginning of the test method 
>> to wait for focus to come)
>> and define boolean noAction as volatile since you are accessing it on 
>> two threads
>>
>> Thanks
>> alexp
>>
>> On 1/16/2013 4:58 PM, Vladislav Karnaukhov wrote:
>>> Hello,
>>>
>>> could you please review the fix:
>>> bug: http://bugs.sun.com/view_bug.do?bug_id=4199622
>>> webrev: http://cr.openjdk.java.net/~vkarnauk/4199622/webrev.00/
>>>
>>> The fix uses new property to disable ActionEvent generation in 
>>> JComboBox' drop-down window when an user navigates with keyboard.
>>> The fix works only when property is explicitly set by a developer; 
>>> otherwise default JComboBox' behavior doesn't change.
>>>
>>> Regards,
>>> - Vlad
>
>


From Sergey.Bylokhov at oracle.com  Wed Jan 16 15:28:01 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 16 Jan 2013 19:28:01 +0400
Subject: <Swing Dev> [8] Review request for 7124209 [macosx]
 SpringLayout issue. BASELINE is not in the range: [NORTH, SOUTH]
In-Reply-To: <509BA4B7.2060506@oracle.com>
References: <50913E63.4080507@oracle.com> <50927D0F.1070609@oracle.com>
	<509A77A0.4080901@oracle.com> <509B9F57.4000304@oracle.com>
	<509BA4B7.2060506@oracle.com>
Message-ID: <50F6C701.4080809@oracle.com>

Hi, Konstantin.
Fix looks good.

08.11.2012 16:25, Konstantin Shefov wrote:
> http://cr.openjdk.java.net/~kshefov/7124209/webrev.02/ 
> <http://cr.openjdk.java.net/%7Ekshefov/7124209/webrev.02/>
>
> On 08-Nov-12 16:02, Alexander Scherbatiy wrote:
>> On 11/7/2012 7:00 PM, Konstantin Shefov wrote:
>>> Please, look at modified fix:
>>> http://cr.openjdk.java.net/~kshefov/7124209/webrev.01/ 
>>> <http://cr.openjdk.java.net/%7Ekshefov/7124209/webrev.01/>
>>
>>    Try/catch block in the main method catches RuntimeException as 
>> well. So the jtreg passes the test even it really fails.
>>    It is also a good idea to fail the test if the 
>> SwingUtilities.invokeAndWait() throws an exception because it is also 
>> a wrong situation.
>>
>>    Thanks,
>>    Alexandr.
>>
>>>
>>> On 01-Nov-12 17:45, Alexander Scherbatiy wrote:
>>>>
>>>>   - Please, remove comments and unnecessary System.out from the fix
>>>>   - Create and check swing components on EDT. Avoiding this rule 
>>>> can leads to unpredictable test failures.
>>>>   - Swing tests usually have bugBugID.java or some meaningful name.
>>>>   - It is better to use  the swing-dev at openjdk.java.net alias to 
>>>> review the swing tests.
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>> On 10/31/2012 7:06 PM, Konstantin Shefov wrote:
>>>>> Hello,
>>>>>
>>>>> Please review a fix for the issue:
>>>>>
>>>>> 7124209 [macosx] SpringLayout issue. BASELINE is not in the range: 
>>>>> [NORTH, SOUTH]
>>>>>
>>>>> The webrev is http://cr.openjdk.java.net/~kshefov/7124209/webrev/
>>>>>
>>>>> It is suggested to move the test to open jdk.
>>>>>
>>>>> Thanks,
>>>>> Konstantin
>>>>>
>>>>
>>


-- 
Best regards, Sergey.



From Sergey.Malenkov at oracle.com  Wed Jan 16 15:16:12 2013
From: Sergey.Malenkov at oracle.com (Sergey Malenkov)
Date: Wed, 16 Jan 2013 19:16:12 +0400
Subject: <Swing Dev> [8] Review request for 8003400: JTree scrolling
 problem when using large model
In-Reply-To: <50F6AB33.1030807@oracle.com>
References: <50F6AB33.1030807@oracle.com>
Message-ID: <50F6C43C.7030203@oracle.com>

Hello,

This is the second version, in which the automatic test is stabilized. 
I've added a lock to ensure that JavaTest does not close the window 
before the test is finished.

Thanks,
SAM

On 16.01.2013 17:29, Sergey Malenkov wrote:
> Hello,
>
> Could you please review the following fix:
> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003400
> fix: http://cr.openjdk.java.net/~malenkov/8003400.0/
>
> JTree with the large model calculates widths for visible rows only. The
> problem is that the horizontal scroll bar appears after moving to the
> end and hides the last row. The automatic test is included.
>
> Thanks,
> SAM


From Vladislav.Karnaukhov at oracle.com  Wed Jan 16 15:27:26 2013
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Wed, 16 Jan 2013 19:27:26 +0400
Subject: <Swing Dev> [8] Review request for 4199622 RFE: JComboBox
 shouldn't sending ActionEvents for keyboard navigation
In-Reply-To: <50F6C551.30307@oracle.com>
References: <50F6A3EF.3000705@oracle.com> <50F6AF16.6010400@oracle.com>
	<50F6B375.2040802@oracle.com> <50F6C551.30307@oracle.com>
Message-ID: <50F6C6DE.30105@oracle.com>

Hello Sergey,

please see inline.

On 1/16/2013 07:20 PM, Sergey Bylokhov wrote:
> Hi, Vladislav.
> From the bug description:
> "When the user pops up a JComboBox (hits the spacebar for Metal L&F), 
> and then tries to navigate with the arrow keys, any ActionListeners 
> for that CB will have their actionPerformed methods called, and there 
> isn't any information in the given ActionEvent to show that this was 
> only a navigation action rather than a selection (spacebar) action."
> I do not see a problem here, because "navigation action" is an action 
> and so ActionEvent is posted in this case. Does somebody complains 
> about it?
Yes, it was escalated. Customer would like to have an enhancement to 
JComboBox behavior (just an enhancement; they fully realize that default 
JComboBox behavior mustn't change, because backward compatibility impact 
would be tremendous).

> I am not sure but what about the case when the user change selection 
> view mouseover? Is it possible?
The customer would like to see an enhancement when keyboard navigation 
duplicates that of with mouse. They have some resource-consuming task 
placed on actionPerformed, and if an end-user accidentally uses keyboard 
for navigation, it greatly affects system load.

>
>
> 16.01.2013 18:04, Vladislav Karnaukhov wrote:
>> Hello Alex,
>>
>> thanks for the review.
>>
>> Please find a new version here: 
>> http://cr.openjdk.java.net/~vkarnauk/4199622/webrev.01/
>>
>> Regards,
>> - Vlad
>>
>> On 1/16/2013 05:45 PM, Alexander Potochkin wrote:
>>> Hello Vlad
>>>
>>> The fix overall looks good,
>>> however there are some comments:
>>>
>>> it is better to use UIManager.getBoolean() in this case,
>>> it will enable you to skip the null check
>>>
>>> in the test you should use SunToolkit.realSync() instead of sleep()
>>> (please also call realSync in the very beginning of the test method 
>>> to wait for focus to come)
>>> and define boolean noAction as volatile since you are accessing it 
>>> on two threads
>>>
>>> Thanks
>>> alexp
>>>
>>> On 1/16/2013 4:58 PM, Vladislav Karnaukhov wrote:
>>>> Hello,
>>>>
>>>> could you please review the fix:
>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=4199622
>>>> webrev: http://cr.openjdk.java.net/~vkarnauk/4199622/webrev.00/
>>>>
>>>> The fix uses new property to disable ActionEvent generation in 
>>>> JComboBox' drop-down window when an user navigates with keyboard.
>>>> The fix works only when property is explicitly set by a developer; 
>>>> otherwise default JComboBox' behavior doesn't change.
>>>>
>>>> Regards,
>>>> - Vlad
>>
>>
>
>




From Sergey.Bylokhov at oracle.com  Wed Jan 16 15:55:44 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 16 Jan 2013 19:55:44 +0400
Subject: <Swing Dev> [8] Review request for 8003400: JTree scrolling
 problem when using large model
In-Reply-To: <50F6C43C.7030203@oracle.com>
References: <50F6AB33.1030807@oracle.com> <50F6C43C.7030203@oracle.com>
Message-ID: <50F6CD80.8060201@oracle.com>

Hi, Sergey.
Looks like in the updateCachedPreferredSize we should add size of 
scrollbar not a rowSize, since they can be different. In this case new 
invokeLater is not necessary. Also it would be good to dispose the frame 
in the test.

16.01.2013 19:16, Sergey Malenkov wrote:
> Hello,
>
> This is the second version, in which the automatic test is stabilized. 
> I've added a lock to ensure that JavaTest does not close the window 
> before the test is finished.
>
> Thanks,
> SAM
>
> On 16.01.2013 17:29, Sergey Malenkov wrote:
>> Hello,
>>
>> Could you please review the following fix:
>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003400
>> fix: http://cr.openjdk.java.net/~malenkov/8003400.0/
>>
>> JTree with the large model calculates widths for visible rows only. The
>> problem is that the horizontal scroll bar appears after moving to the
>> end and hides the last row. The automatic test is included.
>>
>> Thanks,
>> SAM


-- 
Best regards, Sergey.



From Sergey.Malenkov at oracle.com  Wed Jan 16 17:46:58 2013
From: Sergey.Malenkov at oracle.com (Sergey Malenkov)
Date: Wed, 16 Jan 2013 21:46:58 +0400
Subject: <Swing Dev> [8] Review request for 8003400: JTree scrolling
 problem when using large model
In-Reply-To: <50F6CD80.8060201@oracle.com>
References: <50F6AB33.1030807@oracle.com> <50F6C43C.7030203@oracle.com>
	<50F6CD80.8060201@oracle.com>
Message-ID: <50F6E792.2000108@oracle.com>

Hi Sergey,

 > Looks like in the updateCachedPreferredSize we should add
 > size of scrollbar not a rowSize, since they can be different.

Good point. I've prepared the third version of the fix:
http://cr.openjdk.java.net/~malenkov/8003400.2/

 > In this case new invokeLater is not necessary.

It is needed because we should ensure that selected row is visible after 
then the horizontal scroll bar is added.

 > Also it would be good to dispose the frame in the test.

It is disposed, but only for JavaTest.
For manual testing it is useful to see the result.


Thanks,
SAM

On 16.01.2013 19:55, Sergey Bylokhov wrote:
> Looks like in the updateCachedPreferredSize we should add size of
> scrollbar not a rowSize, since they can be different. In this case new
> invokeLater is not necessary. Also it would be good to dispose the frame
> in the test.
>
> 16.01.2013 19:16, Sergey Malenkov wrote:
>> Hello,
>>
>> This is the second version, in which the automatic test is stabilized.
>> I've added a lock to ensure that JavaTest does not close the window
>> before the test is finished.
>>
>> Thanks,
>> SAM
>>
>> On 16.01.2013 17:29, Sergey Malenkov wrote:
>>> Hello,
>>>
>>> Could you please review the following fix:
>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003400
>>> fix: http://cr.openjdk.java.net/~malenkov/8003400.0/
>>>
>>> JTree with the large model calculates widths for visible rows only. The
>>> problem is that the horizontal scroll bar appears after moving to the
>>> end and hides the last row. The automatic test is included.
>>>
>>> Thanks,
>>> SAM
>
>


From Vladislav.Karnaukhov at oracle.com  Thu Jan 17 13:33:24 2013
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Thu, 17 Jan 2013 17:33:24 +0400
Subject: <Swing Dev> [8] Review request for 4199622 RFE: JComboBox
 shouldn't sending ActionEvents for keyboard navigation
In-Reply-To: <50F6A3EF.3000705@oracle.com>
References: <50F6A3EF.3000705@oracle.com>
Message-ID: <50F7FDA4.9040600@oracle.com>

Hello,

please review a new version of the fix: 
http://cr.openjdk.java.net/~vkarnauk/4199622/webrev.02/

Support for VK_PAGE_DOWN/VK_PAGE_UP and VK_HOME/VK_END keys was added; 
test routine was altered accordingly.

Regards,
- Vlad


From dingxmin at linux.vnet.ibm.com  Fri Jan 18 06:50:50 2013
From: dingxmin at linux.vnet.ibm.com (Frank Ding)
Date: Fri, 18 Jan 2013 14:50:50 +0800
Subject: <Swing Dev> 7189299 DefaultButtonModel instance keeps stale
 listeners of JButton in case of multiple
 SwingUtilities.updateComponentTreeUI() calls
In-Reply-To: <50DD0EF1.9070908@linux.vnet.ibm.com>
References: <501F6E2E.1020608@linux.vnet.ibm.com> <5051C86A.5040907@oracle.com>
	<5056C45B.9030905@linux.vnet.ibm.com>	<506ED516.5020706@oracle.com>
	<50727AFF.3060004@linux.vnet.ibm.com>	<507440C4.9060504@oracle.com>
	<50751427.4040706@linux.vnet.ibm.com>	<50778B0F.6040407@linux.vnet.ibm.com>
	<507BD467.2000405@oracle.com>	<507E4752.3040302@linux.vnet.ibm.com>
	<508E34D7.1060308@linux.vnet.ibm.com> <508FD85D.6010600@oracle.com>
	<5092184A.2040303@linux.vnet.ibm.com> <5092664A.4010504@oracle.com>
	<509768B0.6000802@linux.vnet.ibm.com> <5099101D.1020507@oracle.com>
	<509A0639.1030806@linux.vnet.ibm.com> <509BC7EE.7000801@oracle.com>
	<50A1FC8F.7060107@linux.vnet.ibm.com> <50A233B2.5020602@oracle.com>
	<50A338B5.7070302@linux.vnet.ibm.com> <50A4B369.3030009@oracle.com>
	<50B5AF37.3070307@linux.vnet.ibm.com> <50BC8497.5030409@oracle.com>
	<50BEE5DE.9020803@linux.vnet.ibm.com>	<50C059CF.4090806@linux.vnet.ibm.com>
	<50C5BC18.8030009@oracle.com> <50DD0EF1.9070908@linux.vnet.ibm.com>
Message-ID: <50F8F0CA.1070403@linux.vnet.ibm.com>

Hi Alexandr,
   Do you have any idea?

Best regards,
Frank

On 12/28/2012 11:16 AM, Frank Ding wrote:
> Hi Alexandr,
>   I did some more investigations.
>   1. The model can be accessed as below which is also illustrated in 
> the jtreg test
> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/test/javax/swing/text/html/7189299/bug7189299.java.html 
>
>
>   HTMLEditorKit htmlEditorKit = (HTMLEditorKit) html.getEditorKit();
>   StyleContext.NamedStyle style = ((StyleContext.NamedStyle) 
> htmlEditorKit.getInputAttributes());
>   DefaultButtonModel model = ((DefaultButtonModel) 
> style.getAttribute(StyleConstants.ModelAttribute));
>
>   Though it needs type conversion, model can be exposed to client 
> code.  This implies client code has the chance to add listeners.
>   Another way of updating listener in model is by first getting 
> JButton or other html Swing components and then call listener related 
> api that affects model.  I dumped vars above but did not find out 
> possibility for application to get Swing component reference.
>
>   2. As of swing.text.html library, I searched 'ModelAttribute' under 
> javax/swing directory with command "grep -R 'ModelAttribute' ." which 
> shows aside from FormView and StyleConstants, the classes referencing 
> it are HTMLDocument, HTMLWriter.  This means only FormView adds 
> listeners to model.
>
>   My first attempt at fixing the problem (only for JButton listener 
> leak) is trying to remove all listeners completely.  See 
> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.01/.  Pavel argued 
> that it may cause existing application to malfunction. Then I came up 
> with http://cr.openjdk.java.net/~dingxmin/7189299/webrev.02/ where 
> only stale listeners are identified and removed using reflection.  But 
> Pavel insisted reflection should be prohibited.  So I tried to work 
> around it by extending JButton in FormView to access the private 
> listener instance such that only stale listener is removed.  The 
> perfect revision is 
> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/.
>
>   I propose we fix JButton issue as it leads to NPE visible to 
> application.  Bug in other components can be put off if Swing team 
> intend to fix it elegantly or duplicate code like what is in v.07.
>   Any idea or comment, please let me know.
>
>   Thanks and best regards,
>   Frank
>
> On 12/10/2012 6:40 PM, Alexander Scherbatiy wrote:
>> On 12/6/2012 12:39 PM, Frank Ding wrote:
>>> Hi Alexandr,
>>>    I did several attempts but still have hang issues somewhere. It 
>>> seems the new approach of caching gui components created each time 
>>> is not practical because of the threading restriction already 
>>> imposed on HTMLDocument.
>>>    Can we make compromise by turning to previous solution (v7 in 
>>> particular) and generalize it to other gui components (which means 
>>> there would be JCheckBoxWrapper, JRadioButtonWrapper,
>>
>>     The issue is that models contain listeners from all previous 
>> components. Models are used to store data and state of components 
>> when form view is recreated.
>>     FormView adds it's own listeners to components (and as result to 
>> the models). Could you make a little investigation to check which 
>> other listeners can the models hold?
>>     Can a user adds a listener?  Can listeners be added by other 
>> parts of the swing.text.html library?
>>
>>     If old listeners does not play role, it is possible just to 
>> remove them all.
>>
>>     Thanks,
>>     Alexandr.
>>
>>> JPasswordFieldWrapper, JTextFieldWrapper, JListWrapper, 
>>> JComboBoxWrapper, and JButtonWrapper).  Or shall we fix JButton only 
>>> because it causes obvious exception visible to client?  I am short 
>>> of ideas...
>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/
>>>
>>> Best regards,
>>> Frank
>>>
>>> On 12/5/2012 2:12 PM, Frank Ding wrote:
>>>> Hi Alexandr,
>>>>   I observed the same issue in my environment as well.  My proposed 
>>>> patch would cause severe regression issues.  I am looking into the 
>>>> locking issue.
>>>>
>>>> Thanks,
>>>> Frank
>>>>
>>>> On 12/3/2012 6:53 PM, Alexander Scherbatiy wrote:
>>>>>
>>>>>
>>>>>  Could you check the following sample with your latest fix? It 
>>>>> just hangs on my side.
>>>>>
>>>>>    - put the sample.html  and the response.html  files on a server
>>>>>    - update path to the html files in the 
>>>>> LoadingWebPageToJEditorPane class
>>>>>
>>>>> -------------     sample.html  ------------
>>>>> <form name="input" action="response.html" method="get">
>>>>> Username: <input type="text" name="user">
>>>>> <input type="submit" value="Submit">
>>>>> </form>
>>>>> -------------     response.html  ------------
>>>>> <html>
>>>>> <body>
>>>>> Hello World!
>>>>> </body>
>>>>> </html>
>>>>> -------------     LoadingWebPageToJEditorPane.html ------------
>>>>> import java.net.URL;
>>>>> import javax.swing.JEditorPane;
>>>>> import javax.swing.JFrame;
>>>>> import javax.swing.JScrollPane;
>>>>> import javax.swing.SwingUtilities;
>>>>>
>>>>> public class LoadingWebPageToJEditorPane {
>>>>>
>>>>>     private static final String HTML_PATH = 
>>>>> "http://serever/path/sample.html";
>>>>>
>>>>>     public static void main(String[] a) throws Exception {
>>>>>
>>>>>         SwingUtilities.invokeAndWait(new Runnable() {
>>>>>
>>>>>             @Override
>>>>>             public void run() {
>>>>>                 try {
>>>>>
>>>>>                     JFrame frame = new JFrame();
>>>>> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>>>>
>>>>>                     JEditorPane editorPane = new JEditorPane();
>>>>>                     editorPane.setPage(new URL(HTML_PATH));
>>>>>
>>>>>                     frame.add(new JScrollPane(editorPane));
>>>>>                     frame.setSize(300, 200);
>>>>>                     frame.setVisible(true);
>>>>> SwingUtilities.updateComponentTreeUI(editorPane);
>>>>>                 } catch (Exception ex) {
>>>>>                     throw new RuntimeException(ex);
>>>>>                 }
>>>>>             }
>>>>>         });
>>>>>     }
>>>>> }
>>>>> ---------------------------------------
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>>>
>>>>> On 11/28/2012 10:29 AM, Frank Ding wrote:
>>>>>> Hi Alexandr,
>>>>>>   I created a new patch v8 @ 
>>>>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.08/. It uses 
>>>>>> the newly proposed approach mentioned in my last email. Could you 
>>>>>> please help to review it again?
>>>>>>
>>>>>>   The patch, of course, passed jtreg test bug7189299.java in the 
>>>>>> patch.  What's more, I did additional tests for JComboBox, 
>>>>>> JTextField and JList in my IDE by comparing listener numbers 
>>>>>> observed during debugging with/without my patch.  The listener 
>>>>>> numbers were doubled without the fix.  This proves that v8 patch 
>>>>>> works for all components. I think I can write those additional 
>>>>>> tests as jtreg tests after the patch passes review.
>>>>>>
>>>>>>    One notable change is that I had to restrict the scope of 
>>>>>> holding a write lock in DefaultStyledDocument because otherwise, 
>>>>>> we cannot store the new component created in 
>>>>>> FormView.createComponent().  The stack trace is pasted below for 
>>>>>> reference.
>>>>>>
>>>>>> Exception in thread "main" 
>>>>>> java.lang.reflect.InvocationTargetException
>>>>>>     at java.awt.EventQueue.invokeAndWait(EventQueue.java:1270)
>>>>>>     at 
>>>>>> javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1350)
>>>>>>     at bug7189299.main(bug7189299.java:116)
>>>>>> Caused by: java.lang.IllegalStateException: Attempt to mutate in 
>>>>>> notification
>>>>>>     at 
>>>>>> javax.swing.text.AbstractDocument.writeLock(AbstractDocument.java:1357) 
>>>>>>
>>>>>>     at 
>>>>>> javax.swing.text.html.HTMLDocument.obtainLock(HTMLDocument.java:1708) 
>>>>>>
>>>>>>     at 
>>>>>> javax.swing.text.html.FormView.createComponent(FormView.java:211)
>>>>>> ......(omitted)......
>>>>>>     at 
>>>>>> javax.swing.plaf.basic.BasicTextUI$RootView.insertUpdate(BasicTextUI.java:1602)
>>>>>>     at 
>>>>>> javax.swing.plaf.basic.BasicTextUI$UpdateHandler.insertUpdate(BasicTextUI.java:1861)
>>>>>>     at 
>>>>>> javax.swing.text.AbstractDocument.fireInsertUpdate(AbstractDocument.java:201) 
>>>>>>
>>>>>>     at 
>>>>>> javax.swing.text.DefaultStyledDocument.create(DefaultStyledDocument.java:155) 
>>>>>> <------   FormView.createComponent is triggered by this call 
>>>>>> which has already held the lock
>>>>>>     at 
>>>>>> javax.swing.text.html.HTMLDocument.create(HTMLDocument.java:469)
>>>>>> ......(omitted)......
>>>>>>
>>>>>> This change did violate what is documented in 
>>>>>> AbstractDocument.writeLock that "This situation violates the bean 
>>>>>> event model where order of delivery is not guaranteed and all 
>>>>>> listeners should be notified before further mutations are 
>>>>>> allowed. "  However, without the change of shrinking lock scope, 
>>>>>> the component cannot be saved once it is created in 
>>>>>> FormView.createComponent(). I found it is even harder to save it 
>>>>>> later in code but perhaps there does exist a more appropriate 
>>>>>> place to do this.  If you have any better suggestion, I am glad 
>>>>>> to know.
>>>>>>
>>>>>>   Also I searched references to 
>>>>>> 'StyleConstants.ComponentAttribute' as you asked.  The result is 
>>>>>> listed below.  Note that the command 'grep' is invoked under 
>>>>>> openjdk 8 top directory.
>>>>>> $ grep -R 'ComponentAttribute' .
>>>>>> ./jdk/src/share/classes/javax/swing/text/StyleConstants.java: 
>>>>>> public static final Object ComponentAttribute = new 
>>>>>> CharacterConstants("component");
>>>>>> ./jdk/src/share/classes/javax/swing/text/StyleConstants.java: 
>>>>>> return (Component) a.getAttribute(ComponentAttribute);
>>>>>> ./jdk/src/share/classes/javax/swing/text/StyleConstants.java: 
>>>>>> a.addAttribute(ComponentAttribute, c);
>>>>>> ./jdk/src/share/classes/javax/swing/text/StyleConstants.java: 
>>>>>> Background, ComponentAttribute, IconAttribute,
>>>>>> ./jdk/src/share/classes/javax/swing/text/StyledEditorKit.java: 
>>>>>> set.removeAttribute(StyleConstants.ComponentAttribute);
>>>>>> Binary file ./jdk/test/sun/tools/jhat/jmap.bin matches
>>>>>>
>>>>>> So ComponentAttribute is not referenced by other classes except 
>>>>>> StyledEditorKit.  StyleConstants exposes ComponentAttribute in 
>>>>>> getComponent() and setComponent() methods.  References to 
>>>>>> StyleConstants.getComponent and StyleConstants.setComponent are 
>>>>>> further searched in repo.
>>>>>>
>>>>>> $ grep -R 'StyleConstants.getComponent' .
>>>>>> ./jdk/src/share/classes/javax/swing/text/ComponentView.java: * 
>>>>>> the element (by calling StyleConstants.getComponent). A
>>>>>> ./jdk/src/share/classes/javax/swing/text/ComponentView.java: 
>>>>>> Component comp = StyleConstants.getComponent(attr);
>>>>>>
>>>>>> $ grep -R 'StyleConstants.setComponent' .
>>>>>> ./jdk/src/share/classes/javax/swing/JTextPane.java: 
>>>>>> StyleConstants.setComponent(inputAttributes, c);
>>>>>>
>>>>>> From the facts above, I think we are sufficiently confident to 
>>>>>> use ComponentAttribute.
>>>>>>
>>>>>> Please let me know if you have any comments and I can do more 
>>>>>> regression tests and provide more jtreg test cases as next step.
>>>>>>
>>>>>> Thanks and regards,
>>>>>> Frank
>>>>>>
>>>>>> On 11/15/2012 5:18 PM, Alexander Scherbatiy wrote:
>>>>>>> On 11/14/2012 10:22 AM, Frank Ding wrote:
>>>>>>>> Hi Alexandr,
>>>>>>>>   After a couple of hours investigating the possibility of 
>>>>>>>> fixing JComboBox.setModel(null) and 
>>>>>>>> JTextComponent.setComponent(null), I found that
>>>>>>>> 1. In JComboBox.setModel, the new model, null in this case, is 
>>>>>>>> eventually passed to BasicComboPopup.propertyChange where 
>>>>>>>> JList.setModel is called.  JList.setModel rejects the null 
>>>>>>>> model because of its api restriction.  Below I listed the 
>>>>>>>> offending call stacks in my IDE.  This makes sense as the 
>>>>>>>> associated drop down JList needs new model. However, it makes 
>>>>>>>> fixing JComboBox.setModel(null) hard or impossible.
>>>>>>>> Exception in thread "main" java.lang.IllegalArgumentException: 
>>>>>>>> model must be non null
>>>>>>>>     at javax.swing.JList.setModel(JList.java:1674)
>>>>>>>>     at 
>>>>>>>> javax.swing.plaf.basic.BasicComboPopup$Handler.propertyChange(BasicComboPopup.java:939)
>>>>>>>>     at 
>>>>>>>> java.beans.PropertyChangeSupport.fire(PropertyChangeSupport.java:335) 
>>>>>>>>
>>>>>>>>     at 
>>>>>>>> java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:327)
>>>>>>>>     at 
>>>>>>>> java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:263)
>>>>>>>>     at java.awt.Component.firePropertyChange(Component.java:8413)
>>>>>>>>     at javax.swing.JComboBox.setModel(JComboBox.java:322)
>>>>>>>>
>>>>>>>> 2. JTextComponent.setComponent(null) can be fixed but code 
>>>>>>>> change in BasicTextUI is also required.
>>>>>>>>
>>>>>>>> Since setting null model to JComboBox, JList and JTextComponent 
>>>>>>>> is impossible or dangerous, just as you mentioned, we could set 
>>>>>>>> a non null new model to these UI components just for the 
>>>>>>>> purpose of having the side effect of removing listeners from 
>>>>>>>> old model. Are you ok with this approach?
>>>>>>>      Yes. Please, try this and run the html swing automated 
>>>>>>> tests from the test/javax/swing/text/html diroctory to check 
>>>>>>> possible regressions.
>>>>>>>
>>>>>>>      Thanks,
>>>>>>>      Alexandr.
>>>>>>>
>>>>>>>> By the way, I will investigate your another question "Could you 
>>>>>>>> also check that the StyleConstants.ComponentAttribute property 
>>>>>>>> value can't be rewritten by the JDK code or by public methods." 
>>>>>>>> and reply soon.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Frank
>>>>>>>>
>>>>>>>> On 11/13/2012 7:49 PM, Alexander Scherbatiy wrote:
>>>>>>>>> On 11/13/2012 11:53 AM, Frank Ding wrote:
>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>   As for your comment "Could you create an issue that a 
>>>>>>>>>> JComboBox.setModel(null) call throws NPE? You could fix it 
>>>>>>>>>> before the 7189299 issue. ", I created a bug with internal 
>>>>>>>>>> review ID of 2381499 on JComboBox.setModel(null).  But test 
>>>>>>>>>> shows that JPasswordField.setDocument(null), 
>>>>>>>>>> JTextField.setDocument(null), JList.setModel(null) and 
>>>>>>>>>> JTextArea.setDocument(null) all throw NPE. Particularly, 
>>>>>>>>>> JList.setModel(null) has null check and throws 
>>>>>>>>>> IllegalArgumentException("model" must be non null").  Shall I 
>>>>>>>>>> include those components as well?
>>>>>>>>>
>>>>>>>>>     There is the javadoc for the JList setModel() method: 
>>>>>>>>> Throws IllegalArgumentException - if model is null.  So it is 
>>>>>>>>> undesirable to change the public API.
>>>>>>>>>     However, it is possible to set a new empty model for the 
>>>>>>>>> JList. The list listeners should be removed from the old model 
>>>>>>>>> in this case.
>>>>>>>>>
>>>>>>>>>     You could have only 2 issues: one for components that 
>>>>>>>>> allow to set a null model but throws NPE (like JComboBox) and 
>>>>>>>>> another for components that does not allow to set null model 
>>>>>>>>> but they do not remove listeners from the old model in case if 
>>>>>>>>> a new model is set.
>>>>>>>>>
>>>>>>>>>   Thanks,
>>>>>>>>>   Alexandr.
>>>>>>>>>
>>>>>>>>>>   Thanks for your guidance in advance.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Frank
>>>>>>>>>>
>>>>>>>>>> On 11/8/2012 10:55 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>> On 11/7/2012 10:56 AM, Frank Ding wrote:
>>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>>   Unfortunately, all the JComponents involved in 
>>>>>>>>>>>> FormView.createComponent() have bugs!
>>>>>>>>>>>>   I have done tests for all other swing components, i.e. 
>>>>>>>>>>>> JCheckBox, JRadioButton, JPasswordField, JTextField, JList, 
>>>>>>>>>>>> JComboBox and JTextField. Sadder news is that if we fix all 
>>>>>>>>>>>> components in the same way as I did for JButton, we need to 
>>>>>>>>>>>> subclass them all, resulting in JCheckBoxWrapper, 
>>>>>>>>>>>> JRadioButtonWrapper, JPasswordFieldWrapper, 
>>>>>>>>>>>> JTextFieldWrapper, JListWrapper, JComboBoxWrapper, 
>>>>>>>>>>>> JTextFieldWrapper plus JButtonWrapper!  This approach 
>>>>>>>>>>>> becomes unacceptable when all swing components are affected.
>>>>>>>>>>>>   Shall we fix it in other way illustrated below?
>>>>>>>>>>>> 1. Whenever a swing component is created, it is kept in 
>>>>>>>>>>>> AttributeSet, as what is now for model.
>>>>>>>>>>>> 2. In FormView.createComponent(), the old swing component 
>>>>>>>>>>>> can be retrieved via 
>>>>>>>>>>>> attr.getAttribute(StyleConstants.ComponentAttribute). Note 
>>>>>>>>>>>> that ComponentAttribute is newly added.
>>>>>>>>>>>       This way should be carefully investigated that it does 
>>>>>>>>>>> not introduce new memory leaks.
>>>>>>>>>>>       Could you also check that the 
>>>>>>>>>>> StyleConstants.ComponentAttribute property value can't be 
>>>>>>>>>>> rewritten by the JDK code or by public methods.
>>>>>>>>>>>
>>>>>>>>>>>> 3. Before setting shared model to a newly initialized swing 
>>>>>>>>>>>> component, call oldComp.setModel(null), delegating 
>>>>>>>>>>>> deregistration to setModel method.
>>>>>>>>>>>> 4. Seems some setModel such as AbstractButton.setModel() 
>>>>>>>>>>>> can function well when the param, new model, is null while 
>>>>>>>>>>>> JComboBox.setModel() will throw NPE in case of null param.
>>>>>>>>>>>      Could you create an issue that a 
>>>>>>>>>>> JComboBox.setModel(null) call throws NPE? You could fix it 
>>>>>>>>>>> before the 7189299 issue.
>>>>>>>>>>>
>>>>>>>>>>>      Thanks,
>>>>>>>>>>>      Alexandr.
>>>>>>>>>>>
>>>>>>>>>>>> 5. Add null check code in those problematic setModel or 
>>>>>>>>>>>> setDocument methods.
>>>>>>>>>>>>
>>>>>>>>>>>> Any idea is appreciated.  Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Frank
>>>>>>>>>>>>
>>>>>>>>>>>> On 11/6/2012 9:26 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>> On 11/5/2012 11:20 AM, Frank Ding wrote:
>>>>>>>>>>>>>> Hi Alexander,
>>>>>>>>>>>>>>   Based on your comments last time, I refined my patch of 
>>>>>>>>>>>>>> v6 and offered v7 @
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/
>>>>>>>>>>>>>
>>>>>>>>>>>>>      This version of the fix looks good for me.
>>>>>>>>>>>>>      It seems that it is the only good way to check that a 
>>>>>>>>>>>>> button model contains AbstarctButton.Handler listener.
>>>>>>>>>>>>>
>>>>>>>>>>>>>     Could you also check that others models used in the 
>>>>>>>>>>>>> createComponent() method do not have such memory leaks 
>>>>>>>>>>>>> (even the NPE is not thrown)?
>>>>>>>>>>>>>
>>>>>>>>>>>>>>   4.  Could you add the check that the action listener is 
>>>>>>>>>>>>>> invoked only once after a component tree updating and the 
>>>>>>>>>>>>>> action does the same that it does before a component tree 
>>>>>>>>>>>>>> updating?
>>>>>>>>>>>>>>   Answer:  I am afraid I could not make it in the auto 
>>>>>>>>>>>>>> test (bug7189299.java) but I can achieve it to some 
>>>>>>>>>>>>>> degree in manual test FormSubmit, the one you illustrated 
>>>>>>>>>>>>>> below.
>>>>>>>>>>>>>>   My idea of checking it in FormSubmit.java is 
>>>>>>>>>>>>>> subclassing JEditorPane and overriding 'public EditorKit 
>>>>>>>>>>>>>> getEditorKit()' where stack traces can be examined in the 
>>>>>>>>>>>>>> overridden method to make sure FormView.submitData occurs 
>>>>>>>>>>>>>> only once.  This approach works because 
>>>>>>>>>>>>>> FormView.submitData() calls JEditorPane.getEditorKit but 
>>>>>>>>>>>>>> is tricky. However, it's the only way I can think of 
>>>>>>>>>>>>>> without any additional framework support. If you are in 
>>>>>>>>>>>>>> favor of adding the check in FormSubmit.java, I am 
>>>>>>>>>>>>>> willing to do that.
>>>>>>>>>>>>>
>>>>>>>>>>>>>       At least a separated manual test can be added that 
>>>>>>>>>>>>> asks a user to put a response.html file to a server and 
>>>>>>>>>>>>> according to the server url checks that JTeditor pane show 
>>>>>>>>>>>>> the response text after a button pressing.
>>>>>>>>>>>>>
>>>>>>>>>>>>>         html = new JEditorPane("text/html",
>>>>>>>>>>>>> "<html><body><form action=\"" + userURL + "\">"
>>>>>>>>>>>>>                         + "<input type=submit name=submit 
>>>>>>>>>>>>> value=\"submit\"/>"
>>>>>>>>>>>>>                         + "</form></body></html>");
>>>>>>>>>>>>>
>>>>>>>>>>>>>  response.html:
>>>>>>>>>>>>> <html> <body> Hello World! </body> </html>
>>>>>>>>>>>>>
>>>>>>>>>>>>>   Thanks,
>>>>>>>>>>>>>   Alexandr.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>   Thanks again for all your comments and your support. 
>>>>>>>>>>>>>> Once again, if you have any further concern or comment, 
>>>>>>>>>>>>>> please don't hesitate to let me know.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>> Frank
>>>>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From dingxmin at linux.vnet.ibm.com  Fri Jan 18 06:53:19 2013
From: dingxmin at linux.vnet.ibm.com (Frank Ding)
Date: Fri, 18 Jan 2013 14:53:19 +0800
Subject: <Swing Dev> [Accessibility]Focus unable to traverse in the
	menubar
In-Reply-To: <50D00ED2.4060502@linux.vnet.ibm.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>
	<1318258874.7676.33.camel@chalkhill> <4E958E1D.7030205@oracle.com>
	<4EB0E593.8050909@linux.vnet.ibm.com> <4EB1307D.8040301@oracle.com>
	<4EBA3F1D.8070201@linux.vnet.ibm.com> <4EBA633A.9000101@oracle.com>
	<5056D00F.3030100@linux.vnet.ibm.com> <506B08DC.3080005@oracle.com>
	<5072A466.6070106@linux.vnet.ibm.com> <5072BD4E.6040203@oracle.com>
	<50C58A60.1020100@linux.vnet.ibm.com> <50C88FB6.20103@oracle.com>
	<50C99982.4040307@linux.vnet.ibm.com> <50CB1E36.6020000@oracle.com>
	<50D00ED2.4060502@linux.vnet.ibm.com>
Message-ID: <50F8F15F.9010200@linux.vnet.ibm.com>

Hi Alexandr,
   Could you please let me know if there is any update on review 
result?  I did not receive any review information of 2401619 which means 
it's still not public/reviewed yet, right?

Best regards,
Frank

On 12/18/2012 2:36 PM, Frank Ding wrote:
> Thanks, Alexandr.
>
> On 12/14/2012 8:40 PM, Alexander Scherbatiy wrote:
>> On 12/13/2012 1:01 PM, Frank Ding wrote:
>>> Hi Alexandr,
>>>   I made another change according to your comment @ 
>>> http://cr.openjdk.java.net/~dingxmin/8000326/webrev.02 . Please 
>>> review it.
>>>   I submitted a bug whose internal review ID is 2401619 about one 
>>> wording mistake in ContainerOrderFocusTraversalPolicy. But since the 
>>> bug system transition, newly submitted bugs cannot pass review and 
>>> get publicly available.  Can you help me to have somebody review it?
>>
>>      I resent the both issues 8000326 and 2401619 to the JDK doc team 
>> to review.
>>
>>      Thanks,
>>      Alexandr.
>>
>>>
>>>   Thanks and Best regards,
>>>   Frank
>>>
>>> On 12/12/2012 10:07 PM, Alexander Scherbatiy wrote:
>>>> On 12/10/2012 11:08 AM, Frank Ding wrote:
>>>>> Hi Pavel,
>>>>>   I think pointing out the special behavior in javadoc makes more 
>>>>> sense.  Could you please take a look at my draft below?
>>>>>   http://cr.openjdk.java.net/~dingxmin/8000326/webrev.01
>>>>      I think that It has more sense to point this special behavior 
>>>> in the JMenuBar class itself.
>>>>      It looks more naturally to read about the JMenuBar focus 
>>>> traversal behaviour from the JMenuBar javadoc.
>>>>
>>>>>   Note that I think in the sentence "By default, methods of this 
>>>>> class with return a Component only if it is" it should be "will" 
>>>>> not "with", shouldn't it?
>>>>      Thank you that you point it out. Could you create an issue on it?
>>>>
>>>>     Thanks,
>>>>     Alexandr.
>>>>>
>>>>>   Expecting your reply.
>>>>> Best regards,
>>>>> Frank
>>>>>
>>>>> On 10/8/2012 7:47 PM, pavel porvatov wrote:
>>>>>> Hi Jonathan,
>>>>>>> Hi Pavel,
>>>>>>>
>>>>>>> On 10/02/2012 11:31 PM, Pavel Porvatov wrote:
>>>>>>>> Hi Jonathan,
>>>>>>>>> Hi Pavel,
>>>>>>>>>
>>>>>>>>> I've filed bug 7198816 for this problem,
>>>>>>>>>
>>>>>>>>> Regards, Pavel
>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=7198816
>>>>>>>> This bug was not ported to jira, so I created another bug:
>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8000326
>>>>>>>
>>>>>>> Thanks for porting, but I have trouble with opening that link.
>>>>>> Sorry, use the following link:
>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000326
>>>>>>
>>>>>> but the bug is not available yet... It contains the same 
>>>>>> description as the original bug.
>>>>>>
>>>>>>> Any comments on the patch?
>>>>>> The fix looks dangerous for me. After the fix the 
>>>>>> setFocusTraversalKeysEnabled method doesn't work for JMenuBar 
>>>>>> (when ContainerOrderFocusTraversalPolicy is used) - it ignores 
>>>>>> this property...
>>>>>>
>>>>>> Regards, Pavel
>>>>>>>
>>>>>>> best regards
>>>>>>> Jonathan
>>>>>>>
>>>>>>>>
>>>>>>>> Regards, Pavel
>>>>>>>>>
>>>>>>>>> On 11/09/2011 07:25 PM, Pavel Porvatov wrote:
>>>>>>>>>> Hi Jing,
>>>>>>>>>>> Thanks Pavel,
>>>>>>>>>>>
>>>>>>>>>>>      It seems fine to me, if no other suggestions/opinions, 
>>>>>>>>>>> I guess we can move on with this?
>>>>>>>>>> Yes, we can. Could you please file a bug for the problem as 
>>>>>>>>>> well?
>>>>>>>>>>
>>>>>>>>>> Thanks, Pavel
>>>>>>>>>>>
>>>>>>>>>>> On 2011/11/2 19:58, Pavel Porvatov wrote:
>>>>>>>>>>>> Hi Jing,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hello Anton,
>>>>>>>>>>>>>
>>>>>>>>>>>>>     Thanks for the review. I am still trying to figure out 
>>>>>>>>>>>>> some real case and provide more detail the customer may fail.
>>>>>>>>>>>>>     Anyway, I agree we'd better update the java spec to 
>>>>>>>>>>>>> make it clear for the customers. I'd like to know if 
>>>>>>>>>>>>> anyone can help with that?
>>>>>>>>>>>> I'm not sure that javadoc changing is a good decision in 
>>>>>>>>>>>> this case. ContainerOrderFocusTraversalPolicy is designed 
>>>>>>>>>>>> for AWT, but I don't know why that policy cannot be used 
>>>>>>>>>>>> for Swing components as well. I see several problems:
>>>>>>>>>>>> 1. We cannot change javadoc of 
>>>>>>>>>>>> ContainerOrderFocusTraversalPolicy because of backward 
>>>>>>>>>>>> compatibility
>>>>>>>>>>>> 2. We cannot remove setFocusTraversalKeysEnabled(false) 
>>>>>>>>>>>> from the JMenuBar#JMenuBar() constructor because of 
>>>>>>>>>>>> backward compatibility
>>>>>>>>>>>>
>>>>>>>>>>>> May be the best decision is to specify, that JMenuBar 
>>>>>>>>>>>> creates menu with the focusTraversalKeysEnabled = false
>>>>>>>>>
>>>>>>>>> Did you mean that for the new menu 
>>>>>>>>> setFocusTraversalKeysEnabled(false) ? I've tried, but it does 
>>>>>>>>> not seem to work for this problem.
>>>>>>>>>
>>>>>>>>>  if my understanding is incorrect, please help to fix me.
>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards, Pavel
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2011/10/12 20:54, Anton Tarasov wrote:
>>>>>>>>>>>>>> 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).
>>>>>>>>>
>>>>>>>>> I agree that backward compatibility should not be broken by 
>>>>>>>>> the fix, so here's a patch from me for the worst case, could 
>>>>>>>>> you please help to take a look?
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~luchsh/7198816/
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Jonathan
>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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 alexander.potochkin at oracle.com  Fri Jan 18 15:01:57 2013
From: alexander.potochkin at oracle.com (Alexander Potochkin)
Date: Fri, 18 Jan 2013 19:01:57 +0400
Subject: <Swing Dev> [8] Review request for 4199622 RFE: JComboBox
 shouldn't sending ActionEvents for keyboard navigation
In-Reply-To: <50F7FDA4.9040600@oracle.com>
References: <50F6A3EF.3000705@oracle.com> <50F7FDA4.9040600@oracle.com>
Message-ID: <50F963E5.8070002@oracle.com>

Hello Vlad

> Hello,
>
> please review a new version of the fix: 
> http://cr.openjdk.java.net/~vkarnauk/4199622/webrev.02/
>
> Support for VK_PAGE_DOWN/VK_PAGE_UP and VK_HOME/VK_END keys was added; 
> test routine was altered accordingly.
nice catch

approved

Thanks
alexp
>
> Regards,
> - Vlad


From alexandr.scherbatiy at oracle.com  Mon Jan 21 10:02:05 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 21 Jan 2013 14:02:05 +0400
Subject: <Swing Dev> [Accessibility]Focus unable to traverse in the
	menubar
In-Reply-To: <50F8F15F.9010200@linux.vnet.ibm.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>
	<1318258874.7676.33.camel@chalkhill> <4E958E1D.7030205@oracle.com>
	<4EB0E593.8050909@linux.vnet.ibm.com> <4EB1307D.8040301@oracle.com>
	<4EBA3F1D.8070201@linux.vnet.ibm.com> <4EBA633A.9000101@oracle.com>
	<5056D00F.3030100@linux.vnet.ibm.com> <506B08DC.3080005@oracle.com>
	<5072A466.6070106@linux.vnet.ibm.com> <5072BD4E.6040203@oracle.com>
	<50C58A60.1020100@linux.vnet.ibm.com> <50C88FB6.20103@oracle.com>
	<50C99982.4040307@linux.vnet.ibm.com> <50CB1E36.6020000@oracle.com>
	<50D00ED2.4060502@linux.vnet.ibm.com>
	<50F8F15F.9010200@linux.vnet.ibm.com>
Message-ID: <50FD121D.2000905@oracle.com>

On 1/18/2013 10:53 AM, Frank Ding wrote:
> Hi Alexandr,
>   Could you please let me know if there is any update on review 
> result?  I did not receive any review information of 2401619 which 
> means it's still not public/reviewed yet, right?
      I got answers from the javadoc team:
       8000326
        The JMenuBar javadoc could be updated to
       -------------------------
       By default, pressing the Tab key does not transfer focus from a 
<code>JMenuBar</code> which is added to a container together with other 
Swing components, because the <code>focusTraversalKeysEnabled</code> 
property of <code>JMenuBar</code> is set to <code>false</code>. To 
resolve this, you should call the 
<code>JMenuBar.setFocusTraversalKeysEnabled(true)</code> method.
       -------------------------

      2401619
         Yes, there should be "will return" expression instead of the 
"with return"?
          The 2401619 java incident has not been migrated yet to the bug 
system.

     Thanks,
     Alexandr.


>
> Best regards,
> Frank
>
> On 12/18/2012 2:36 PM, Frank Ding wrote:
>> Thanks, Alexandr.
>>
>> On 12/14/2012 8:40 PM, Alexander Scherbatiy wrote:
>>> On 12/13/2012 1:01 PM, Frank Ding wrote:
>>>> Hi Alexandr,
>>>>   I made another change according to your comment @ 
>>>> http://cr.openjdk.java.net/~dingxmin/8000326/webrev.02 . Please 
>>>> review it.
>>>>   I submitted a bug whose internal review ID is 2401619 about one 
>>>> wording mistake in ContainerOrderFocusTraversalPolicy. But since 
>>>> the bug system transition, newly submitted bugs cannot pass review 
>>>> and get publicly available.  Can you help me to have somebody 
>>>> review it?
>>>
>>>      I resent the both issues 8000326 and 2401619 to the JDK doc 
>>> team to review.
>>>
>>>      Thanks,
>>>      Alexandr.
>>>
>>>>
>>>>   Thanks and Best regards,
>>>>   Frank
>>>>
>>>> On 12/12/2012 10:07 PM, Alexander Scherbatiy wrote:
>>>>> On 12/10/2012 11:08 AM, Frank Ding wrote:
>>>>>> Hi Pavel,
>>>>>>   I think pointing out the special behavior in javadoc makes more 
>>>>>> sense.  Could you please take a look at my draft below?
>>>>>>   http://cr.openjdk.java.net/~dingxmin/8000326/webrev.01
>>>>>      I think that It has more sense to point this special behavior 
>>>>> in the JMenuBar class itself.
>>>>>      It looks more naturally to read about the JMenuBar focus 
>>>>> traversal behaviour from the JMenuBar javadoc.
>>>>>
>>>>>>   Note that I think in the sentence "By default, methods of this 
>>>>>> class with return a Component only if it is" it should be "will" 
>>>>>> not "with", shouldn't it?
>>>>>      Thank you that you point it out. Could you create an issue on 
>>>>> it?
>>>>>
>>>>>     Thanks,
>>>>>     Alexandr.
>>>>>>
>>>>>>   Expecting your reply.
>>>>>> Best regards,
>>>>>> Frank
>>>>>>
>>>>>> On 10/8/2012 7:47 PM, pavel porvatov wrote:
>>>>>>> Hi Jonathan,
>>>>>>>> Hi Pavel,
>>>>>>>>
>>>>>>>> On 10/02/2012 11:31 PM, Pavel Porvatov wrote:
>>>>>>>>> Hi Jonathan,
>>>>>>>>>> Hi Pavel,
>>>>>>>>>>
>>>>>>>>>> I've filed bug 7198816 for this problem,
>>>>>>>>>>
>>>>>>>>>> Regards, Pavel
>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=7198816
>>>>>>>>> This bug was not ported to jira, so I created another bug:
>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8000326
>>>>>>>>
>>>>>>>> Thanks for porting, but I have trouble with opening that link.
>>>>>>> Sorry, use the following link:
>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000326
>>>>>>>
>>>>>>> but the bug is not available yet... It contains the same 
>>>>>>> description as the original bug.
>>>>>>>
>>>>>>>> Any comments on the patch?
>>>>>>> The fix looks dangerous for me. After the fix the 
>>>>>>> setFocusTraversalKeysEnabled method doesn't work for JMenuBar 
>>>>>>> (when ContainerOrderFocusTraversalPolicy is used) - it ignores 
>>>>>>> this property...
>>>>>>>
>>>>>>> Regards, Pavel
>>>>>>>>
>>>>>>>> best regards
>>>>>>>> Jonathan
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards, Pavel
>>>>>>>>>>
>>>>>>>>>> On 11/09/2011 07:25 PM, Pavel Porvatov wrote:
>>>>>>>>>>> Hi Jing,
>>>>>>>>>>>> Thanks Pavel,
>>>>>>>>>>>>
>>>>>>>>>>>>      It seems fine to me, if no other suggestions/opinions, 
>>>>>>>>>>>> I guess we can move on with this?
>>>>>>>>>>> Yes, we can. Could you please file a bug for the problem as 
>>>>>>>>>>> well?
>>>>>>>>>>>
>>>>>>>>>>> Thanks, Pavel
>>>>>>>>>>>>
>>>>>>>>>>>> On 2011/11/2 19:58, Pavel Porvatov wrote:
>>>>>>>>>>>>> Hi Jing,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello Anton,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     Thanks for the review. I am still trying to figure 
>>>>>>>>>>>>>> out some real case and provide more detail the customer 
>>>>>>>>>>>>>> may fail.
>>>>>>>>>>>>>>     Anyway, I agree we'd better update the java spec to 
>>>>>>>>>>>>>> make it clear for the customers. I'd like to know if 
>>>>>>>>>>>>>> anyone can help with that?
>>>>>>>>>>>>> I'm not sure that javadoc changing is a good decision in 
>>>>>>>>>>>>> this case. ContainerOrderFocusTraversalPolicy is designed 
>>>>>>>>>>>>> for AWT, but I don't know why that policy cannot be used 
>>>>>>>>>>>>> for Swing components as well. I see several problems:
>>>>>>>>>>>>> 1. We cannot change javadoc of 
>>>>>>>>>>>>> ContainerOrderFocusTraversalPolicy because of backward 
>>>>>>>>>>>>> compatibility
>>>>>>>>>>>>> 2. We cannot remove setFocusTraversalKeysEnabled(false) 
>>>>>>>>>>>>> from the JMenuBar#JMenuBar() constructor because of 
>>>>>>>>>>>>> backward compatibility
>>>>>>>>>>>>>
>>>>>>>>>>>>> May be the best decision is to specify, that JMenuBar 
>>>>>>>>>>>>> creates menu with the focusTraversalKeysEnabled = false
>>>>>>>>>>
>>>>>>>>>> Did you mean that for the new menu 
>>>>>>>>>> setFocusTraversalKeysEnabled(false) ? I've tried, but it does 
>>>>>>>>>> not seem to work for this problem.
>>>>>>>>>>
>>>>>>>>>>  if my understanding is incorrect, please help to fix me.
>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards, Pavel
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2011/10/12 20:54, Anton Tarasov wrote:
>>>>>>>>>>>>>>> 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).
>>>>>>>>>>
>>>>>>>>>> I agree that backward compatibility should not be broken by 
>>>>>>>>>> the fix, so here's a patch from me for the worst case, could 
>>>>>>>>>> you please help to take a look?
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~luchsh/7198816/
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Jonathan
>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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 Sergey.Malenkov at oracle.com  Mon Jan 21 10:40:33 2013
From: Sergey.Malenkov at oracle.com (Sergey Malenkov)
Date: Mon, 21 Jan 2013 14:40:33 +0400
Subject: <Swing Dev> [8] Review request for 6817933: Setting the background
 of an HTML Widget changes the native Windows JFileChooser
Message-ID: <50FD1B21.60302@oracle.com>

Hello,

Could you please review the following fix:
bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6817933
fix: http://cr.openjdk.java.net/~malenkov/6817933.0/

The styleSheet property of the HTMLEditorKit class have a static 
behavior. It must be non-static because of JavaBeans spec. The automatic 
test is included.

Thanks,
SAM


From Sergey.Bylokhov at oracle.com  Mon Jan 21 11:11:40 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 21 Jan 2013 15:11:40 +0400
Subject: <Swing Dev> [8] Review request for 6817933: Setting the
 background of an HTML Widget changes the native Windows JFileChooser
In-Reply-To: <50FD1B21.60302@oracle.com>
References: <50FD1B21.60302@oracle.com>
Message-ID: <50FD226C.7000704@oracle.com>

Hi, Sergey
Not sure that this change correspond to documentation:
"

  373     /**
  374      * Get the set of styles currently being used to render the
  375      * HTML elements.  By default the resource specified by
  376      * DEFAULT_CSS gets loaded, and is*shared*  by all HTMLEditorKit
  377      * instances.
  378      */

"
What does it mean: "shared"?

21.01.2013 14:40, Sergey Malenkov wrote:
> Hello,
>
> Could you please review the following fix:
> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6817933
> fix: http://cr.openjdk.java.net/~malenkov/6817933.0/
>
> The styleSheet property of the HTMLEditorKit class have a static 
> behavior. It must be non-static because of JavaBeans spec. The 
> automatic test is included.
>
> Thanks,
> SAM


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20130121/51d3b388/attachment.html>

From alexandr.scherbatiy at oracle.com  Mon Jan 21 13:14:59 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 21 Jan 2013 17:14:59 +0400
Subject: <Swing Dev> [8] Review request for 4199622 RFE: JComboBox
 shouldn't sending ActionEvents for keyboard navigation
In-Reply-To: <50F7FDA4.9040600@oracle.com>
References: <50F6A3EF.3000705@oracle.com> <50F7FDA4.9040600@oracle.com>
Message-ID: <50FD3F53.901@oracle.com>


    Some small comments:
     - Keys Up and Down do not work with WindowsLookAndFeel and enabled 
ComboBox.noActionOnKeyNavigation property. Is it expected behavior?
     - Method getNextIndex from the BasicComboBoxUI class is private, so 
it is possible to pass the ui variable as an argument rather to obtain 
it one more time
     - Cancel action does not set the ui.listBox selected index to the 
initial state. However,  it seems that it works correct when the popup 
is opened next time.

   Thanks,
   Alexandr.

On 1/17/2013 5:33 PM, Vladislav Karnaukhov wrote:
> Hello,
>
> please review a new version of the fix: 
> http://cr.openjdk.java.net/~vkarnauk/4199622/webrev.02/
>
> Support for VK_PAGE_DOWN/VK_PAGE_UP and VK_HOME/VK_END keys was added; 
> test routine was altered accordingly.
>
> Regards,
> - Vlad



From Vladislav.Karnaukhov at oracle.com  Mon Jan 21 13:19:19 2013
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Mon, 21 Jan 2013 17:19:19 +0400
Subject: <Swing Dev> [8] Review request for 4199622 RFE: JComboBox
 shouldn't sending ActionEvents for keyboard navigation
In-Reply-To: <50FD3F53.901@oracle.com>
References: <50F6A3EF.3000705@oracle.com> <50F7FDA4.9040600@oracle.com>
	<50FD3F53.901@oracle.com>
Message-ID: <50FD4057.1070400@oracle.com>

Alexander,

thanks for the review.

On 1/21/2013 05:14 PM, Alexander Scherbatiy wrote:
>
>     Some small comments:
>      - Keys Up and Down do not work with WindowsLookAndFeel and enabled
> ComboBox.noActionOnKeyNavigation property. Is it expected behavior?
No. It's a regression and we can't continue with such errors in code. 
Ideally the fix mustn't change look and feel except for firing 
actionPerformed events.

I'll continue to work on the fix.

Regards,
- Vlad

>      - Method getNextIndex from the BasicComboBoxUI class is private, so
> it is possible to pass the ui variable as an argument rather to obtain
> it one more time
>      - Cancel action does not set the ui.listBox selected index to the
> initial state. However,  it seems that it works correct when the popup
> is opened next time.
>
>    Thanks,
>    Alexandr.
>
> On 1/17/2013 5:33 PM, Vladislav Karnaukhov wrote:
>> Hello,
>>
>> please review a new version of the fix:
>> http://cr.openjdk.java.net/~vkarnauk/4199622/webrev.02/
>>
>> Support for VK_PAGE_DOWN/VK_PAGE_UP and VK_HOME/VK_END keys was added;
>> test routine was altered accordingly.
>>
>> Regards,
>> - Vlad
>




From alexandr.scherbatiy at oracle.com  Mon Jan 21 13:41:00 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 21 Jan 2013 17:41:00 +0400
Subject: <Swing Dev> 7189299 DefaultButtonModel instance keeps stale
 listeners of JButton in case of multiple
 SwingUtilities.updateComponentTreeUI() calls
In-Reply-To: <50F8F0CA.1070403@linux.vnet.ibm.com>
References: <501F6E2E.1020608@linux.vnet.ibm.com>
	<5056C45B.9030905@linux.vnet.ibm.com>	<506ED516.5020706@oracle.com>
	<50727AFF.3060004@linux.vnet.ibm.com>	<507440C4.9060504@oracle.com>
	<50751427.4040706@linux.vnet.ibm.com>	<50778B0F.6040407@linux.vnet.ibm.com>
	<507BD467.2000405@oracle.com>	<507E4752.3040302@linux.vnet.ibm.com>
	<508E34D7.1060308@linux.vnet.ibm.com> <508FD85D.6010600@oracle.com>
	<5092184A.2040303@linux.vnet.ibm.com> <5092664A.4010504@oracle.com>
	<509768B0.6000802@linux.vnet.ibm.com> <5099101D.1020507@oracle.com>
	<509A0639.1030806@linux.vnet.ibm.com> <509BC7EE.7000801@oracle.com>
	<50A1FC8F.7060107@linux.vnet.ibm.com> <50A233B2.5020602@oracle.com>
	<50A338B5.7070302@linux.vnet.ibm.com> <50A4B369.3030009@oracle.com>
	<50B5AF37.3070307@linux.vnet.ibm.com> <50BC8497.5030409@oracle.com>
	<50BEE5DE.9020803@linux.vnet.ibm.com>	<50C059CF.4090806@linux.vnet.ibm.com>
	<50C5BC18.8030009@oracle.com> <50DD0EF1.9070908@linux.vnet.ibm.com>
	<50F8F0CA.1070403@linux.vnet.ibm.com>
Message-ID: <50FD456C.20601@oracle.com>

On 1/18/2013 10:50 AM, Frank Ding wrote:
> Hi Alexandr,
>   Do you have any idea?

    What about one more way removing listeners:
     - disadvantage: listeners are hardcoded
     - advantage: there is no need to override JButton, JList,... classes

      ------------------------------------------
     private void clearModel(Object model) {
         if (model instanceof DefaultButtonModel) {
             DefaultButtonModel buttonModel = (DefaultButtonModel) model;
             String listenerClass = "javax.swing.AbstractButton$Handler";

             for (ActionListener listener : 
buttonModel.getActionListeners()) {
                 if (listenerClass.equals(listener.getClass().getName())) {
                     buttonModel.removeActionListener(listener);
                 }
             }
             // remove change listeners
             // remove item listeners

         } else if(model instanceof ListModel){
             // remove list listeners
         }
     }
      ------------------------------------------

    Thanks,
     Alexandr.

>
> Best regards,
> Frank
>
> On 12/28/2012 11:16 AM, Frank Ding wrote:
>> Hi Alexandr,
>>   I did some more investigations.
>>   1. The model can be accessed as below which is also illustrated in 
>> the jtreg test
>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/test/javax/swing/text/html/7189299/bug7189299.java.html 
>>
>>
>>   HTMLEditorKit htmlEditorKit = (HTMLEditorKit) html.getEditorKit();
>>   StyleContext.NamedStyle style = ((StyleContext.NamedStyle) 
>> htmlEditorKit.getInputAttributes());
>>   DefaultButtonModel model = ((DefaultButtonModel) 
>> style.getAttribute(StyleConstants.ModelAttribute));
>>
>>   Though it needs type conversion, model can be exposed to client 
>> code.  This implies client code has the chance to add listeners.
>>   Another way of updating listener in model is by first getting 
>> JButton or other html Swing components and then call listener related 
>> api that affects model.  I dumped vars above but did not find out 
>> possibility for application to get Swing component reference.
>>
>>   2. As of swing.text.html library, I searched 'ModelAttribute' under 
>> javax/swing directory with command "grep -R 'ModelAttribute' ." which 
>> shows aside from FormView and StyleConstants, the classes referencing 
>> it are HTMLDocument, HTMLWriter.  This means only FormView adds 
>> listeners to model.
>>
>>   My first attempt at fixing the problem (only for JButton listener 
>> leak) is trying to remove all listeners completely.  See 
>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.01/.  Pavel 
>> argued that it may cause existing application to malfunction. Then I 
>> came up with http://cr.openjdk.java.net/~dingxmin/7189299/webrev.02/ 
>> where only stale listeners are identified and removed using 
>> reflection.  But Pavel insisted reflection should be prohibited.  So 
>> I tried to work around it by extending JButton in FormView to access 
>> the private listener instance such that only stale listener is 
>> removed.  The perfect revision is 
>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/.
>>
>>   I propose we fix JButton issue as it leads to NPE visible to 
>> application.  Bug in other components can be put off if Swing team 
>> intend to fix it elegantly or duplicate code like what is in v.07.
>>   Any idea or comment, please let me know.
>>
>>   Thanks and best regards,
>>   Frank
>>
>> On 12/10/2012 6:40 PM, Alexander Scherbatiy wrote:
>>> On 12/6/2012 12:39 PM, Frank Ding wrote:
>>>> Hi Alexandr,
>>>>    I did several attempts but still have hang issues somewhere. It 
>>>> seems the new approach of caching gui components created each time 
>>>> is not practical because of the threading restriction already 
>>>> imposed on HTMLDocument.
>>>>    Can we make compromise by turning to previous solution (v7 in 
>>>> particular) and generalize it to other gui components (which means 
>>>> there would be JCheckBoxWrapper, JRadioButtonWrapper,
>>>
>>>     The issue is that models contain listeners from all previous 
>>> components. Models are used to store data and state of components 
>>> when form view is recreated.
>>>     FormView adds it's own listeners to components (and as result to 
>>> the models). Could you make a little investigation to check which 
>>> other listeners can the models hold?
>>>     Can a user adds a listener?  Can listeners be added by other 
>>> parts of the swing.text.html library?
>>>
>>>     If old listeners does not play role, it is possible just to 
>>> remove them all.
>>>
>>>     Thanks,
>>>     Alexandr.
>>>
>>>> JPasswordFieldWrapper, JTextFieldWrapper, JListWrapper, 
>>>> JComboBoxWrapper, and JButtonWrapper).  Or shall we fix JButton 
>>>> only because it causes obvious exception visible to client?  I am 
>>>> short of ideas...
>>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/
>>>>
>>>> Best regards,
>>>> Frank
>>>>
>>>> On 12/5/2012 2:12 PM, Frank Ding wrote:
>>>>> Hi Alexandr,
>>>>>   I observed the same issue in my environment as well.  My 
>>>>> proposed patch would cause severe regression issues.  I am looking 
>>>>> into the locking issue.
>>>>>
>>>>> Thanks,
>>>>> Frank
>>>>>
>>>>> On 12/3/2012 6:53 PM, Alexander Scherbatiy wrote:
>>>>>>
>>>>>>
>>>>>>  Could you check the following sample with your latest fix? It 
>>>>>> just hangs on my side.
>>>>>>
>>>>>>    - put the sample.html  and the response.html  files on a server
>>>>>>    - update path to the html files in the 
>>>>>> LoadingWebPageToJEditorPane class
>>>>>>
>>>>>> -------------     sample.html  ------------
>>>>>> <form name="input" action="response.html" method="get">
>>>>>> Username: <input type="text" name="user">
>>>>>> <input type="submit" value="Submit">
>>>>>> </form>
>>>>>> -------------     response.html  ------------
>>>>>> <html>
>>>>>> <body>
>>>>>> Hello World!
>>>>>> </body>
>>>>>> </html>
>>>>>> -------------     LoadingWebPageToJEditorPane.html ------------
>>>>>> import java.net.URL;
>>>>>> import javax.swing.JEditorPane;
>>>>>> import javax.swing.JFrame;
>>>>>> import javax.swing.JScrollPane;
>>>>>> import javax.swing.SwingUtilities;
>>>>>>
>>>>>> public class LoadingWebPageToJEditorPane {
>>>>>>
>>>>>>     private static final String HTML_PATH = 
>>>>>> "http://serever/path/sample.html";
>>>>>>
>>>>>>     public static void main(String[] a) throws Exception {
>>>>>>
>>>>>>         SwingUtilities.invokeAndWait(new Runnable() {
>>>>>>
>>>>>>             @Override
>>>>>>             public void run() {
>>>>>>                 try {
>>>>>>
>>>>>>                     JFrame frame = new JFrame();
>>>>>> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>>>>>
>>>>>>                     JEditorPane editorPane = new JEditorPane();
>>>>>>                     editorPane.setPage(new URL(HTML_PATH));
>>>>>>
>>>>>>                     frame.add(new JScrollPane(editorPane));
>>>>>>                     frame.setSize(300, 200);
>>>>>>                     frame.setVisible(true);
>>>>>> SwingUtilities.updateComponentTreeUI(editorPane);
>>>>>>                 } catch (Exception ex) {
>>>>>>                     throw new RuntimeException(ex);
>>>>>>                 }
>>>>>>             }
>>>>>>         });
>>>>>>     }
>>>>>> }
>>>>>> ---------------------------------------
>>>>>>
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>
>>>>>>
>>>>>> On 11/28/2012 10:29 AM, Frank Ding wrote:
>>>>>>> Hi Alexandr,
>>>>>>>   I created a new patch v8 @ 
>>>>>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.08/. It uses 
>>>>>>> the newly proposed approach mentioned in my last email. Could 
>>>>>>> you please help to review it again?
>>>>>>>
>>>>>>>   The patch, of course, passed jtreg test bug7189299.java in the 
>>>>>>> patch.  What's more, I did additional tests for JComboBox, 
>>>>>>> JTextField and JList in my IDE by comparing listener numbers 
>>>>>>> observed during debugging with/without my patch.  The listener 
>>>>>>> numbers were doubled without the fix.  This proves that v8 patch 
>>>>>>> works for all components. I think I can write those additional 
>>>>>>> tests as jtreg tests after the patch passes review.
>>>>>>>
>>>>>>>    One notable change is that I had to restrict the scope of 
>>>>>>> holding a write lock in DefaultStyledDocument because otherwise, 
>>>>>>> we cannot store the new component created in 
>>>>>>> FormView.createComponent().  The stack trace is pasted below for 
>>>>>>> reference.
>>>>>>>
>>>>>>> Exception in thread "main" 
>>>>>>> java.lang.reflect.InvocationTargetException
>>>>>>>     at java.awt.EventQueue.invokeAndWait(EventQueue.java:1270)
>>>>>>>     at 
>>>>>>> javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1350)
>>>>>>>     at bug7189299.main(bug7189299.java:116)
>>>>>>> Caused by: java.lang.IllegalStateException: Attempt to mutate in 
>>>>>>> notification
>>>>>>>     at 
>>>>>>> javax.swing.text.AbstractDocument.writeLock(AbstractDocument.java:1357) 
>>>>>>>
>>>>>>>     at 
>>>>>>> javax.swing.text.html.HTMLDocument.obtainLock(HTMLDocument.java:1708) 
>>>>>>>
>>>>>>>     at 
>>>>>>> javax.swing.text.html.FormView.createComponent(FormView.java:211)
>>>>>>> ......(omitted)......
>>>>>>>     at 
>>>>>>> javax.swing.plaf.basic.BasicTextUI$RootView.insertUpdate(BasicTextUI.java:1602)
>>>>>>>     at 
>>>>>>> javax.swing.plaf.basic.BasicTextUI$UpdateHandler.insertUpdate(BasicTextUI.java:1861)
>>>>>>>     at 
>>>>>>> javax.swing.text.AbstractDocument.fireInsertUpdate(AbstractDocument.java:201) 
>>>>>>>
>>>>>>>     at 
>>>>>>> javax.swing.text.DefaultStyledDocument.create(DefaultStyledDocument.java:155) 
>>>>>>> <------   FormView.createComponent is triggered by this call 
>>>>>>> which has already held the lock
>>>>>>>     at 
>>>>>>> javax.swing.text.html.HTMLDocument.create(HTMLDocument.java:469)
>>>>>>> ......(omitted)......
>>>>>>>
>>>>>>> This change did violate what is documented in 
>>>>>>> AbstractDocument.writeLock that "This situation violates the 
>>>>>>> bean event model where order of delivery is not guaranteed and 
>>>>>>> all listeners should be notified before further mutations are 
>>>>>>> allowed. "  However, without the change of shrinking lock scope, 
>>>>>>> the component cannot be saved once it is created in 
>>>>>>> FormView.createComponent(). I found it is even harder to save it 
>>>>>>> later in code but perhaps there does exist a more appropriate 
>>>>>>> place to do this.  If you have any better suggestion, I am glad 
>>>>>>> to know.
>>>>>>>
>>>>>>>   Also I searched references to 
>>>>>>> 'StyleConstants.ComponentAttribute' as you asked.  The result is 
>>>>>>> listed below.  Note that the command 'grep' is invoked under 
>>>>>>> openjdk 8 top directory.
>>>>>>> $ grep -R 'ComponentAttribute' .
>>>>>>> ./jdk/src/share/classes/javax/swing/text/StyleConstants.java: 
>>>>>>> public static final Object ComponentAttribute = new 
>>>>>>> CharacterConstants("component");
>>>>>>> ./jdk/src/share/classes/javax/swing/text/StyleConstants.java: 
>>>>>>> return (Component) a.getAttribute(ComponentAttribute);
>>>>>>> ./jdk/src/share/classes/javax/swing/text/StyleConstants.java: 
>>>>>>> a.addAttribute(ComponentAttribute, c);
>>>>>>> ./jdk/src/share/classes/javax/swing/text/StyleConstants.java: 
>>>>>>> Background, ComponentAttribute, IconAttribute,
>>>>>>> ./jdk/src/share/classes/javax/swing/text/StyledEditorKit.java: 
>>>>>>> set.removeAttribute(StyleConstants.ComponentAttribute);
>>>>>>> Binary file ./jdk/test/sun/tools/jhat/jmap.bin matches
>>>>>>>
>>>>>>> So ComponentAttribute is not referenced by other classes except 
>>>>>>> StyledEditorKit.  StyleConstants exposes ComponentAttribute in 
>>>>>>> getComponent() and setComponent() methods.  References to 
>>>>>>> StyleConstants.getComponent and StyleConstants.setComponent are 
>>>>>>> further searched in repo.
>>>>>>>
>>>>>>> $ grep -R 'StyleConstants.getComponent' .
>>>>>>> ./jdk/src/share/classes/javax/swing/text/ComponentView.java: * 
>>>>>>> the element (by calling StyleConstants.getComponent). A
>>>>>>> ./jdk/src/share/classes/javax/swing/text/ComponentView.java: 
>>>>>>> Component comp = StyleConstants.getComponent(attr);
>>>>>>>
>>>>>>> $ grep -R 'StyleConstants.setComponent' .
>>>>>>> ./jdk/src/share/classes/javax/swing/JTextPane.java: 
>>>>>>> StyleConstants.setComponent(inputAttributes, c);
>>>>>>>
>>>>>>> From the facts above, I think we are sufficiently confident to 
>>>>>>> use ComponentAttribute.
>>>>>>>
>>>>>>> Please let me know if you have any comments and I can do more 
>>>>>>> regression tests and provide more jtreg test cases as next step.
>>>>>>>
>>>>>>> Thanks and regards,
>>>>>>> Frank
>>>>>>>
>>>>>>> On 11/15/2012 5:18 PM, Alexander Scherbatiy wrote:
>>>>>>>> On 11/14/2012 10:22 AM, Frank Ding wrote:
>>>>>>>>> Hi Alexandr,
>>>>>>>>>   After a couple of hours investigating the possibility of 
>>>>>>>>> fixing JComboBox.setModel(null) and 
>>>>>>>>> JTextComponent.setComponent(null), I found that
>>>>>>>>> 1. In JComboBox.setModel, the new model, null in this case, is 
>>>>>>>>> eventually passed to BasicComboPopup.propertyChange where 
>>>>>>>>> JList.setModel is called.  JList.setModel rejects the null 
>>>>>>>>> model because of its api restriction.  Below I listed the 
>>>>>>>>> offending call stacks in my IDE.  This makes sense as the 
>>>>>>>>> associated drop down JList needs new model. However, it makes 
>>>>>>>>> fixing JComboBox.setModel(null) hard or impossible.
>>>>>>>>> Exception in thread "main" java.lang.IllegalArgumentException: 
>>>>>>>>> model must be non null
>>>>>>>>>     at javax.swing.JList.setModel(JList.java:1674)
>>>>>>>>>     at 
>>>>>>>>> javax.swing.plaf.basic.BasicComboPopup$Handler.propertyChange(BasicComboPopup.java:939)
>>>>>>>>>     at 
>>>>>>>>> java.beans.PropertyChangeSupport.fire(PropertyChangeSupport.java:335) 
>>>>>>>>>
>>>>>>>>>     at 
>>>>>>>>> java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:327)
>>>>>>>>>     at 
>>>>>>>>> java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:263)
>>>>>>>>>     at java.awt.Component.firePropertyChange(Component.java:8413)
>>>>>>>>>     at javax.swing.JComboBox.setModel(JComboBox.java:322)
>>>>>>>>>
>>>>>>>>> 2. JTextComponent.setComponent(null) can be fixed but code 
>>>>>>>>> change in BasicTextUI is also required.
>>>>>>>>>
>>>>>>>>> Since setting null model to JComboBox, JList and 
>>>>>>>>> JTextComponent is impossible or dangerous, just as you 
>>>>>>>>> mentioned, we could set a non null new model to these UI 
>>>>>>>>> components just for the purpose of having the side effect of 
>>>>>>>>> removing listeners from old model. Are you ok with this approach?
>>>>>>>>      Yes. Please, try this and run the html swing automated 
>>>>>>>> tests from the test/javax/swing/text/html diroctory to check 
>>>>>>>> possible regressions.
>>>>>>>>
>>>>>>>>      Thanks,
>>>>>>>>      Alexandr.
>>>>>>>>
>>>>>>>>> By the way, I will investigate your another question "Could 
>>>>>>>>> you also check that the StyleConstants.ComponentAttribute 
>>>>>>>>> property value can't be rewritten by the JDK code or by public 
>>>>>>>>> methods." and reply soon.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Frank
>>>>>>>>>
>>>>>>>>> On 11/13/2012 7:49 PM, Alexander Scherbatiy wrote:
>>>>>>>>>> On 11/13/2012 11:53 AM, Frank Ding wrote:
>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>   As for your comment "Could you create an issue that a 
>>>>>>>>>>> JComboBox.setModel(null) call throws NPE? You could fix it 
>>>>>>>>>>> before the 7189299 issue. ", I created a bug with internal 
>>>>>>>>>>> review ID of 2381499 on JComboBox.setModel(null).  But test 
>>>>>>>>>>> shows that JPasswordField.setDocument(null), 
>>>>>>>>>>> JTextField.setDocument(null), JList.setModel(null) and 
>>>>>>>>>>> JTextArea.setDocument(null) all throw NPE. Particularly, 
>>>>>>>>>>> JList.setModel(null) has null check and throws 
>>>>>>>>>>> IllegalArgumentException("model" must be non null").  Shall 
>>>>>>>>>>> I include those components as well?
>>>>>>>>>>
>>>>>>>>>>     There is the javadoc for the JList setModel() method: 
>>>>>>>>>> Throws IllegalArgumentException - if model is null.  So it is 
>>>>>>>>>> undesirable to change the public API.
>>>>>>>>>>     However, it is possible to set a new empty model for the 
>>>>>>>>>> JList. The list listeners should be removed from the old 
>>>>>>>>>> model in this case.
>>>>>>>>>>
>>>>>>>>>>     You could have only 2 issues: one for components that 
>>>>>>>>>> allow to set a null model but throws NPE (like JComboBox) and 
>>>>>>>>>> another for components that does not allow to set null model 
>>>>>>>>>> but they do not remove listeners from the old model in case 
>>>>>>>>>> if a new model is set.
>>>>>>>>>>
>>>>>>>>>>   Thanks,
>>>>>>>>>>   Alexandr.
>>>>>>>>>>
>>>>>>>>>>>   Thanks for your guidance in advance.
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Frank
>>>>>>>>>>>
>>>>>>>>>>> On 11/8/2012 10:55 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>> On 11/7/2012 10:56 AM, Frank Ding wrote:
>>>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>>>   Unfortunately, all the JComponents involved in 
>>>>>>>>>>>>> FormView.createComponent() have bugs!
>>>>>>>>>>>>>   I have done tests for all other swing components, i.e. 
>>>>>>>>>>>>> JCheckBox, JRadioButton, JPasswordField, JTextField, 
>>>>>>>>>>>>> JList, JComboBox and JTextField. Sadder news is that if we 
>>>>>>>>>>>>> fix all components in the same way as I did for JButton, 
>>>>>>>>>>>>> we need to subclass them all, resulting in 
>>>>>>>>>>>>> JCheckBoxWrapper, JRadioButtonWrapper, 
>>>>>>>>>>>>> JPasswordFieldWrapper, JTextFieldWrapper, JListWrapper, 
>>>>>>>>>>>>> JComboBoxWrapper, JTextFieldWrapper plus JButtonWrapper!  
>>>>>>>>>>>>> This approach becomes unacceptable when all swing 
>>>>>>>>>>>>> components are affected.
>>>>>>>>>>>>>   Shall we fix it in other way illustrated below?
>>>>>>>>>>>>> 1. Whenever a swing component is created, it is kept in 
>>>>>>>>>>>>> AttributeSet, as what is now for model.
>>>>>>>>>>>>> 2. In FormView.createComponent(), the old swing component 
>>>>>>>>>>>>> can be retrieved via 
>>>>>>>>>>>>> attr.getAttribute(StyleConstants.ComponentAttribute). Note 
>>>>>>>>>>>>> that ComponentAttribute is newly added.
>>>>>>>>>>>>       This way should be carefully investigated that it 
>>>>>>>>>>>> does not introduce new memory leaks.
>>>>>>>>>>>>       Could you also check that the 
>>>>>>>>>>>> StyleConstants.ComponentAttribute property value can't be 
>>>>>>>>>>>> rewritten by the JDK code or by public methods.
>>>>>>>>>>>>
>>>>>>>>>>>>> 3. Before setting shared model to a newly initialized 
>>>>>>>>>>>>> swing component, call oldComp.setModel(null), delegating 
>>>>>>>>>>>>> deregistration to setModel method.
>>>>>>>>>>>>> 4. Seems some setModel such as AbstractButton.setModel() 
>>>>>>>>>>>>> can function well when the param, new model, is null while 
>>>>>>>>>>>>> JComboBox.setModel() will throw NPE in case of null param.
>>>>>>>>>>>>      Could you create an issue that a 
>>>>>>>>>>>> JComboBox.setModel(null) call throws NPE? You could fix it 
>>>>>>>>>>>> before the 7189299 issue.
>>>>>>>>>>>>
>>>>>>>>>>>>      Thanks,
>>>>>>>>>>>>      Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>>> 5. Add null check code in those problematic setModel or 
>>>>>>>>>>>>> setDocument methods.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Any idea is appreciated.  Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>> Frank
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/6/2012 9:26 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>> On 11/5/2012 11:20 AM, Frank Ding wrote:
>>>>>>>>>>>>>>> Hi Alexander,
>>>>>>>>>>>>>>>   Based on your comments last time, I refined my patch 
>>>>>>>>>>>>>>> of v6 and offered v7 @
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>      This version of the fix looks good for me.
>>>>>>>>>>>>>>      It seems that it is the only good way to check that 
>>>>>>>>>>>>>> a button model contains AbstarctButton.Handler listener.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     Could you also check that others models used in the 
>>>>>>>>>>>>>> createComponent() method do not have such memory leaks 
>>>>>>>>>>>>>> (even the NPE is not thrown)?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   4.  Could you add the check that the action listener 
>>>>>>>>>>>>>>> is invoked only once after a component tree updating and 
>>>>>>>>>>>>>>> the action does the same that it does before a component 
>>>>>>>>>>>>>>> tree updating?
>>>>>>>>>>>>>>>   Answer:  I am afraid I could not make it in the auto 
>>>>>>>>>>>>>>> test (bug7189299.java) but I can achieve it to some 
>>>>>>>>>>>>>>> degree in manual test FormSubmit, the one you 
>>>>>>>>>>>>>>> illustrated below.
>>>>>>>>>>>>>>>   My idea of checking it in FormSubmit.java is 
>>>>>>>>>>>>>>> subclassing JEditorPane and overriding 'public EditorKit 
>>>>>>>>>>>>>>> getEditorKit()' where stack traces can be examined in 
>>>>>>>>>>>>>>> the overridden method to make sure FormView.submitData 
>>>>>>>>>>>>>>> occurs only once.  This approach works because 
>>>>>>>>>>>>>>> FormView.submitData() calls JEditorPane.getEditorKit but 
>>>>>>>>>>>>>>> is tricky. However, it's the only way I can think of 
>>>>>>>>>>>>>>> without any additional framework support. If you are in 
>>>>>>>>>>>>>>> favor of adding the check in FormSubmit.java, I am 
>>>>>>>>>>>>>>> willing to do that.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>       At least a separated manual test can be added that 
>>>>>>>>>>>>>> asks a user to put a response.html file to a server and 
>>>>>>>>>>>>>> according to the server url checks that JTeditor pane 
>>>>>>>>>>>>>> show the response text after a button pressing.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         html = new JEditorPane("text/html",
>>>>>>>>>>>>>> "<html><body><form action=\"" + userURL + "\">"
>>>>>>>>>>>>>>                         + "<input type=submit name=submit 
>>>>>>>>>>>>>> value=\"submit\"/>"
>>>>>>>>>>>>>>                         + "</form></body></html>");
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  response.html:
>>>>>>>>>>>>>> <html> <body> Hello World! </body> </html>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   Thanks,
>>>>>>>>>>>>>>   Alexandr.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Thanks again for all your comments and your support. 
>>>>>>>>>>>>>>> Once again, if you have any further concern or comment, 
>>>>>>>>>>>>>>> please don't hesitate to let me know.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>> Frank
>>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From dingxmin at linux.vnet.ibm.com  Tue Jan 22 05:21:33 2013
From: dingxmin at linux.vnet.ibm.com (Frank Ding)
Date: Tue, 22 Jan 2013 13:21:33 +0800
Subject: <Swing Dev> [Accessibility]Focus unable to traverse in the
	menubar
In-Reply-To: <50FD121D.2000905@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>
	<1318258874.7676.33.camel@chalkhill> <4E958E1D.7030205@oracle.com>
	<4EB0E593.8050909@linux.vnet.ibm.com> <4EB1307D.8040301@oracle.com>
	<4EBA3F1D.8070201@linux.vnet.ibm.com> <4EBA633A.9000101@oracle.com>
	<5056D00F.3030100@linux.vnet.ibm.com> <506B08DC.3080005@oracle.com>
	<5072A466.6070106@linux.vnet.ibm.com> <5072BD4E.6040203@oracle.com>
	<50C58A60.1020100@linux.vnet.ibm.com> <50C88FB6.20103@oracle.com>
	<50C99982.4040307@linux.vnet.ibm.com> <50CB1E36.6020000@oracle.com>
	<50D00ED2.4060502@linux.vnet.ibm.com>
	<50F8F15F.9010200@linux.vnet.ibm.com> <50FD121D.2000905@oracle.com>
Message-ID: <50FE21DD.4040305@linux.vnet.ibm.com>

Hi Alexandr,
   Thanks for your information.  I have created a new webrev review @
http://cr.openjdk.java.net/~dingxmin/8000326/webrev.03/
   Pls take a look.
   By the way, please let me know once 2401619 is migrated to the bug 
system.

Best regards,
Frank

On 1/21/2013 6:02 PM, Alexander Scherbatiy wrote:
> On 1/18/2013 10:53 AM, Frank Ding wrote:
>> Hi Alexandr,
>>   Could you please let me know if there is any update on review 
>> result?  I did not receive any review information of 2401619 which 
>> means it's still not public/reviewed yet, right?
>      I got answers from the javadoc team:
>       8000326
>        The JMenuBar javadoc could be updated to
>       -------------------------
>       By default, pressing the Tab key does not transfer focus from a 
> <code>JMenuBar</code> which is added to a container together with 
> other Swing components, because the 
> <code>focusTraversalKeysEnabled</code> property of 
> <code>JMenuBar</code> is set to <code>false</code>. To resolve this, 
> you should call the 
> <code>JMenuBar.setFocusTraversalKeysEnabled(true)</code> method.
>       -------------------------
>
>      2401619
>         Yes, there should be "will return" expression instead of the 
> "with return"?
>          The 2401619 java incident has not been migrated yet to the 
> bug system.
>
>     Thanks,
>     Alexandr.
>
>
>>
>> Best regards,
>> Frank
>>
>> On 12/18/2012 2:36 PM, Frank Ding wrote:
>>> Thanks, Alexandr.
>>>
>>> On 12/14/2012 8:40 PM, Alexander Scherbatiy wrote:
>>>> On 12/13/2012 1:01 PM, Frank Ding wrote:
>>>>> Hi Alexandr,
>>>>>   I made another change according to your comment @ 
>>>>> http://cr.openjdk.java.net/~dingxmin/8000326/webrev.02 . Please 
>>>>> review it.
>>>>>   I submitted a bug whose internal review ID is 2401619 about one 
>>>>> wording mistake in ContainerOrderFocusTraversalPolicy. But since 
>>>>> the bug system transition, newly submitted bugs cannot pass review 
>>>>> and get publicly available.  Can you help me to have somebody 
>>>>> review it?
>>>>
>>>>      I resent the both issues 8000326 and 2401619 to the JDK doc 
>>>> team to review.
>>>>
>>>>      Thanks,
>>>>      Alexandr.
>>>>
>>>>>
>>>>>   Thanks and Best regards,
>>>>>   Frank
>>>>>
>>>>> On 12/12/2012 10:07 PM, Alexander Scherbatiy wrote:
>>>>>> On 12/10/2012 11:08 AM, Frank Ding wrote:
>>>>>>> Hi Pavel,
>>>>>>>   I think pointing out the special behavior in javadoc makes 
>>>>>>> more sense.  Could you please take a look at my draft below?
>>>>>>> http://cr.openjdk.java.net/~dingxmin/8000326/webrev.01
>>>>>>      I think that It has more sense to point this special 
>>>>>> behavior in the JMenuBar class itself.
>>>>>>      It looks more naturally to read about the JMenuBar focus 
>>>>>> traversal behaviour from the JMenuBar javadoc.
>>>>>>
>>>>>>>   Note that I think in the sentence "By default, methods of this 
>>>>>>> class with return a Component only if it is" it should be "will" 
>>>>>>> not "with", shouldn't it?
>>>>>>      Thank you that you point it out. Could you create an issue 
>>>>>> on it?
>>>>>>
>>>>>>     Thanks,
>>>>>>     Alexandr.
>>>>>>>
>>>>>>>   Expecting your reply.
>>>>>>> Best regards,
>>>>>>> Frank
>>>>>>>
>>>>>>> On 10/8/2012 7:47 PM, pavel porvatov wrote:
>>>>>>>> Hi Jonathan,
>>>>>>>>> Hi Pavel,
>>>>>>>>>
>>>>>>>>> On 10/02/2012 11:31 PM, Pavel Porvatov wrote:
>>>>>>>>>> Hi Jonathan,
>>>>>>>>>>> Hi Pavel,
>>>>>>>>>>>
>>>>>>>>>>> I've filed bug 7198816 for this problem,
>>>>>>>>>>>
>>>>>>>>>>> Regards, Pavel
>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=7198816
>>>>>>>>>> This bug was not ported to jira, so I created another bug:
>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8000326
>>>>>>>>>
>>>>>>>>> Thanks for porting, but I have trouble with opening that link.
>>>>>>>> Sorry, use the following link:
>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000326
>>>>>>>>
>>>>>>>> but the bug is not available yet... It contains the same 
>>>>>>>> description as the original bug.
>>>>>>>>
>>>>>>>>> Any comments on the patch?
>>>>>>>> The fix looks dangerous for me. After the fix the 
>>>>>>>> setFocusTraversalKeysEnabled method doesn't work for JMenuBar 
>>>>>>>> (when ContainerOrderFocusTraversalPolicy is used) - it ignores 
>>>>>>>> this property...
>>>>>>>>
>>>>>>>> Regards, Pavel
>>>>>>>>>
>>>>>>>>> best regards
>>>>>>>>> Jonathan
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards, Pavel
>>>>>>>>>>>
>>>>>>>>>>> On 11/09/2011 07:25 PM, Pavel Porvatov wrote:
>>>>>>>>>>>> Hi Jing,
>>>>>>>>>>>>> Thanks Pavel,
>>>>>>>>>>>>>
>>>>>>>>>>>>>      It seems fine to me, if no other 
>>>>>>>>>>>>> suggestions/opinions, I guess we can move on with this?
>>>>>>>>>>>> Yes, we can. Could you please file a bug for the problem as 
>>>>>>>>>>>> well?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks, Pavel
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2011/11/2 19:58, Pavel Porvatov wrote:
>>>>>>>>>>>>>> Hi Jing,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello Anton,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     Thanks for the review. I am still trying to figure 
>>>>>>>>>>>>>>> out some real case and provide more detail the customer 
>>>>>>>>>>>>>>> may fail.
>>>>>>>>>>>>>>>     Anyway, I agree we'd better update the java spec to 
>>>>>>>>>>>>>>> make it clear for the customers. I'd like to know if 
>>>>>>>>>>>>>>> anyone can help with that?
>>>>>>>>>>>>>> I'm not sure that javadoc changing is a good decision in 
>>>>>>>>>>>>>> this case. ContainerOrderFocusTraversalPolicy is designed 
>>>>>>>>>>>>>> for AWT, but I don't know why that policy cannot be used 
>>>>>>>>>>>>>> for Swing components as well. I see several problems:
>>>>>>>>>>>>>> 1. We cannot change javadoc of 
>>>>>>>>>>>>>> ContainerOrderFocusTraversalPolicy because of backward 
>>>>>>>>>>>>>> compatibility
>>>>>>>>>>>>>> 2. We cannot remove setFocusTraversalKeysEnabled(false) 
>>>>>>>>>>>>>> from the JMenuBar#JMenuBar() constructor because of 
>>>>>>>>>>>>>> backward compatibility
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> May be the best decision is to specify, that JMenuBar 
>>>>>>>>>>>>>> creates menu with the focusTraversalKeysEnabled = false
>>>>>>>>>>>
>>>>>>>>>>> Did you mean that for the new menu 
>>>>>>>>>>> setFocusTraversalKeysEnabled(false) ? I've tried, but it 
>>>>>>>>>>> does not seem to work for this problem.
>>>>>>>>>>>
>>>>>>>>>>>  if my understanding is incorrect, please help to fix me.
>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards, Pavel
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 2011/10/12 20:54, Anton Tarasov wrote:
>>>>>>>>>>>>>>>> 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).
>>>>>>>>>>>
>>>>>>>>>>> I agree that backward compatibility should not be broken by 
>>>>>>>>>>> the fix, so here's a patch from me for the worst case, could 
>>>>>>>>>>> you please help to take a look?
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~luchsh/7198816/
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Jonathan
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 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 alexandr.scherbatiy at oracle.com  Tue Jan 22 13:29:58 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 22 Jan 2013 17:29:58 +0400
Subject: <Swing Dev> [8] Review request for 8003400: JTree scrolling
 problem when using large model
In-Reply-To: <50F6E792.2000108@oracle.com>
References: <50F6AB33.1030807@oracle.com>
	<50F6C43C.7030203@oracle.com>	<50F6CD80.8060201@oracle.com>
	<50F6E792.2000108@oracle.com>
Message-ID: <50FE9456.5040502@oracle.com>


   I see that some swing classes use SwingUtilities.getUnwrappedParent() 
method to get the first non JLayer parent.
   Does it have sense to skip JLayer components to get the JViewport in 
this fix too?

   Thanks,
   Alexandr.

On 1/16/2013 9:46 PM, Sergey Malenkov wrote:
> Hi Sergey,
>
> > Looks like in the updateCachedPreferredSize we should add
> > size of scrollbar not a rowSize, since they can be different.
>
> Good point. I've prepared the third version of the fix:
> http://cr.openjdk.java.net/~malenkov/8003400.2/
>
> > In this case new invokeLater is not necessary.
>
> It is needed because we should ensure that selected row is visible 
> after then the horizontal scroll bar is added.
>
> > Also it would be good to dispose the frame in the test.
>
> It is disposed, but only for JavaTest.
> For manual testing it is useful to see the result.
>
>
> Thanks,
> SAM
>
> On 16.01.2013 19:55, Sergey Bylokhov wrote:
>> Looks like in the updateCachedPreferredSize we should add size of
>> scrollbar not a rowSize, since they can be different. In this case new
>> invokeLater is not necessary. Also it would be good to dispose the frame
>> in the test.
>>
>> 16.01.2013 19:16, Sergey Malenkov wrote:
>>> Hello,
>>>
>>> This is the second version, in which the automatic test is stabilized.
>>> I've added a lock to ensure that JavaTest does not close the window
>>> before the test is finished.
>>>
>>> Thanks,
>>> SAM
>>>
>>> On 16.01.2013 17:29, Sergey Malenkov wrote:
>>>> Hello,
>>>>
>>>> Could you please review the following fix:
>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003400
>>>> fix: http://cr.openjdk.java.net/~malenkov/8003400.0/
>>>>
>>>> JTree with the large model calculates widths for visible rows only. 
>>>> The
>>>> problem is that the horizontal scroll bar appears after moving to the
>>>> end and hides the last row. The automatic test is included.
>>>>
>>>> Thanks,
>>>> SAM
>>
>>



From alexandr.scherbatiy at oracle.com  Tue Jan 22 14:54:48 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 22 Jan 2013 18:54:48 +0400
Subject: <Swing Dev> [Accessibility]Focus unable to traverse in the
	menubar
In-Reply-To: <50FE21DD.4040305@linux.vnet.ibm.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>
	<1318258874.7676.33.camel@chalkhill> <4E958E1D.7030205@oracle.com>
	<4EB0E593.8050909@linux.vnet.ibm.com> <4EB1307D.8040301@oracle.com>
	<4EBA3F1D.8070201@linux.vnet.ibm.com> <4EBA633A.9000101@oracle.com>
	<5056D00F.3030100@linux.vnet.ibm.com> <506B08DC.3080005@oracle.com>
	<5072A466.6070106@linux.vnet.ibm.com> <5072BD4E.6040203@oracle.com>
	<50C58A60.1020100@linux.vnet.ibm.com> <50C88FB6.20103@oracle.com>
	<50C99982.4040307@linux.vnet.ibm.com> <50CB1E36.6020000@oracle.com>
	<50D00ED2.4060502@linux.vnet.ibm.com>
	<50F8F15F.9010200@linux.vnet.ibm.com> <50FD121D.2000905@oracle.com>
	<50FE21DD.4040305@linux.vnet.ibm.com>
Message-ID: <50FEA838.5010404@oracle.com>

On 1/22/2013 9:21 AM, Frank Ding wrote:
> Hi Alexandr,
>   Thanks for your information.  I have created a new webrev review @
> http://cr.openjdk.java.net/~dingxmin/8000326/webrev.03/
>   Pls take a look.

        The fix looks good for me.

>   By the way, please let me know once 2401619 is migrated to the bug 
> system.
        I will let you know.

        Thanks,
        Alexandr.
>
> Best regards,
> Frank
>
> On 1/21/2013 6:02 PM, Alexander Scherbatiy wrote:
>> On 1/18/2013 10:53 AM, Frank Ding wrote:
>>> Hi Alexandr,
>>>   Could you please let me know if there is any update on review 
>>> result?  I did not receive any review information of 2401619 which 
>>> means it's still not public/reviewed yet, right?
>>      I got answers from the javadoc team:
>>       8000326
>>        The JMenuBar javadoc could be updated to
>>       -------------------------
>>       By default, pressing the Tab key does not transfer focus from a 
>> <code>JMenuBar</code> which is added to a container together with 
>> other Swing components, because the 
>> <code>focusTraversalKeysEnabled</code> property of 
>> <code>JMenuBar</code> is set to <code>false</code>. To resolve this, 
>> you should call the 
>> <code>JMenuBar.setFocusTraversalKeysEnabled(true)</code> method.
>>       -------------------------
>>
>>      2401619
>>         Yes, there should be "will return" expression instead of the 
>> "with return"?
>>          The 2401619 java incident has not been migrated yet to the 
>> bug system.
>>
>>     Thanks,
>>     Alexandr.
>>
>>
>>>
>>> Best regards,
>>> Frank
>>>
>>> On 12/18/2012 2:36 PM, Frank Ding wrote:
>>>> Thanks, Alexandr.
>>>>
>>>> On 12/14/2012 8:40 PM, Alexander Scherbatiy wrote:
>>>>> On 12/13/2012 1:01 PM, Frank Ding wrote:
>>>>>> Hi Alexandr,
>>>>>>   I made another change according to your comment @ 
>>>>>> http://cr.openjdk.java.net/~dingxmin/8000326/webrev.02 . Please 
>>>>>> review it.
>>>>>>   I submitted a bug whose internal review ID is 2401619 about one 
>>>>>> wording mistake in ContainerOrderFocusTraversalPolicy. But since 
>>>>>> the bug system transition, newly submitted bugs cannot pass 
>>>>>> review and get publicly available.  Can you help me to have 
>>>>>> somebody review it?
>>>>>
>>>>>      I resent the both issues 8000326 and 2401619 to the JDK doc 
>>>>> team to review.
>>>>>
>>>>>      Thanks,
>>>>>      Alexandr.
>>>>>
>>>>>>
>>>>>>   Thanks and Best regards,
>>>>>>   Frank
>>>>>>
>>>>>> On 12/12/2012 10:07 PM, Alexander Scherbatiy wrote:
>>>>>>> On 12/10/2012 11:08 AM, Frank Ding wrote:
>>>>>>>> Hi Pavel,
>>>>>>>>   I think pointing out the special behavior in javadoc makes 
>>>>>>>> more sense.  Could you please take a look at my draft below?
>>>>>>>> http://cr.openjdk.java.net/~dingxmin/8000326/webrev.01
>>>>>>>      I think that It has more sense to point this special 
>>>>>>> behavior in the JMenuBar class itself.
>>>>>>>      It looks more naturally to read about the JMenuBar focus 
>>>>>>> traversal behaviour from the JMenuBar javadoc.
>>>>>>>
>>>>>>>>   Note that I think in the sentence "By default, methods of 
>>>>>>>> this class with return a Component only if it is" it should be 
>>>>>>>> "will" not "with", shouldn't it?
>>>>>>>      Thank you that you point it out. Could you create an issue 
>>>>>>> on it?
>>>>>>>
>>>>>>>     Thanks,
>>>>>>>     Alexandr.
>>>>>>>>
>>>>>>>>   Expecting your reply.
>>>>>>>> Best regards,
>>>>>>>> Frank
>>>>>>>>
>>>>>>>> On 10/8/2012 7:47 PM, pavel porvatov wrote:
>>>>>>>>> Hi Jonathan,
>>>>>>>>>> Hi Pavel,
>>>>>>>>>>
>>>>>>>>>> On 10/02/2012 11:31 PM, Pavel Porvatov wrote:
>>>>>>>>>>> Hi Jonathan,
>>>>>>>>>>>> Hi Pavel,
>>>>>>>>>>>>
>>>>>>>>>>>> I've filed bug 7198816 for this problem,
>>>>>>>>>>>>
>>>>>>>>>>>> Regards, Pavel
>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=7198816
>>>>>>>>>>> This bug was not ported to jira, so I created another bug:
>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8000326
>>>>>>>>>>
>>>>>>>>>> Thanks for porting, but I have trouble with opening that link.
>>>>>>>>> Sorry, use the following link:
>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000326
>>>>>>>>>
>>>>>>>>> but the bug is not available yet... It contains the same 
>>>>>>>>> description as the original bug.
>>>>>>>>>
>>>>>>>>>> Any comments on the patch?
>>>>>>>>> The fix looks dangerous for me. After the fix the 
>>>>>>>>> setFocusTraversalKeysEnabled method doesn't work for JMenuBar 
>>>>>>>>> (when ContainerOrderFocusTraversalPolicy is used) - it ignores 
>>>>>>>>> this property...
>>>>>>>>>
>>>>>>>>> Regards, Pavel
>>>>>>>>>>
>>>>>>>>>> best regards
>>>>>>>>>> Jonathan
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Regards, Pavel
>>>>>>>>>>>>
>>>>>>>>>>>> On 11/09/2011 07:25 PM, Pavel Porvatov wrote:
>>>>>>>>>>>>> Hi Jing,
>>>>>>>>>>>>>> Thanks Pavel,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>      It seems fine to me, if no other 
>>>>>>>>>>>>>> suggestions/opinions, I guess we can move on with this?
>>>>>>>>>>>>> Yes, we can. Could you please file a bug for the problem 
>>>>>>>>>>>>> as well?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks, Pavel
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2011/11/2 19:58, Pavel Porvatov wrote:
>>>>>>>>>>>>>>> Hi Jing,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hello Anton,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     Thanks for the review. I am still trying to figure 
>>>>>>>>>>>>>>>> out some real case and provide more detail the customer 
>>>>>>>>>>>>>>>> may fail.
>>>>>>>>>>>>>>>>     Anyway, I agree we'd better update the java spec to 
>>>>>>>>>>>>>>>> make it clear for the customers. I'd like to know if 
>>>>>>>>>>>>>>>> anyone can help with that?
>>>>>>>>>>>>>>> I'm not sure that javadoc changing is a good decision in 
>>>>>>>>>>>>>>> this case. ContainerOrderFocusTraversalPolicy is 
>>>>>>>>>>>>>>> designed for AWT, but I don't know why that policy 
>>>>>>>>>>>>>>> cannot be used for Swing components as well. I see 
>>>>>>>>>>>>>>> several problems:
>>>>>>>>>>>>>>> 1. We cannot change javadoc of 
>>>>>>>>>>>>>>> ContainerOrderFocusTraversalPolicy because of backward 
>>>>>>>>>>>>>>> compatibility
>>>>>>>>>>>>>>> 2. We cannot remove setFocusTraversalKeysEnabled(false) 
>>>>>>>>>>>>>>> from the JMenuBar#JMenuBar() constructor because of 
>>>>>>>>>>>>>>> backward compatibility
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> May be the best decision is to specify, that JMenuBar 
>>>>>>>>>>>>>>> creates menu with the focusTraversalKeysEnabled = false
>>>>>>>>>>>>
>>>>>>>>>>>> Did you mean that for the new menu 
>>>>>>>>>>>> setFocusTraversalKeysEnabled(false) ? I've tried, but it 
>>>>>>>>>>>> does not seem to work for this problem.
>>>>>>>>>>>>
>>>>>>>>>>>>  if my understanding is incorrect, please help to fix me.
>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards, Pavel
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 2011/10/12 20:54, Anton Tarasov wrote:
>>>>>>>>>>>>>>>>> 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).
>>>>>>>>>>>>
>>>>>>>>>>>> I agree that backward compatibility should not be broken by 
>>>>>>>>>>>> the fix, so here's a patch from me for the worst case, 
>>>>>>>>>>>> could you please help to take a look?
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~luchsh/7198816/
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Jonathan
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 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 Sergey.Malenkov at oracle.com  Tue Jan 22 17:07:41 2013
From: Sergey.Malenkov at oracle.com (Sergey Malenkov)
Date: Tue, 22 Jan 2013 21:07:41 +0400
Subject: <Swing Dev> [8] Review request for 6817933: Setting the
 background of an HTML Widget changes the native Windows JFileChooser
In-Reply-To: <50FD226C.7000704@oracle.com>
References: <50FD1B21.60302@oracle.com> <50FD226C.7000704@oracle.com>
Message-ID: <50FEC75D.9020405@oracle.com>

Hi Sergey,

After the discussion offline we decided to fix the WindowsPlacesBar 
class instead of the API-related change.

Could you please review the following fix:
bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6817933
fix: http://cr.openjdk.java.net/~malenkov/6817933.1/

I removed HTML-based text from the JToggleButton. The automatic test is 
included.

Thanks,
SAM

On 21.01.2013 15:11, Sergey Bylokhov wrote:
> Hi, Sergey
> Not sure that this change correspond to documentation:
> "
>
>   373     /**
>   374      * Get the set of styles currently being used to render the
>   375      * HTML elements.  By default the resource specified by
>   376      * DEFAULT_CSS gets loaded, and is*shared*  by all HTMLEditorKit
>   377      * instances.
>   378      */
>
> "
> What does it mean: "shared"?
>
> 21.01.2013 14:40, Sergey Malenkov wrote:
>> Hello,
>>
>> Could you please review the following fix:
>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6817933
>> fix: http://cr.openjdk.java.net/~malenkov/6817933.0/
>>
>> The styleSheet property of the HTMLEditorKit class have a static
>> behavior. It must be non-static because of JavaBeans spec. The
>> automatic test is included.
>>
>> Thanks,
>> SAM


From dingxmin at linux.vnet.ibm.com  Wed Jan 23 03:00:27 2013
From: dingxmin at linux.vnet.ibm.com (Frank Ding)
Date: Wed, 23 Jan 2013 11:00:27 +0800
Subject: <Swing Dev> [Accessibility]Focus unable to traverse in the
	menubar
In-Reply-To: <50FEA838.5010404@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>
	<1318258874.7676.33.camel@chalkhill> <4E958E1D.7030205@oracle.com>
	<4EB0E593.8050909@linux.vnet.ibm.com> <4EB1307D.8040301@oracle.com>
	<4EBA3F1D.8070201@linux.vnet.ibm.com> <4EBA633A.9000101@oracle.com>
	<5056D00F.3030100@linux.vnet.ibm.com> <506B08DC.3080005@oracle.com>
	<5072A466.6070106@linux.vnet.ibm.com> <5072BD4E.6040203@oracle.com>
	<50C58A60.1020100@linux.vnet.ibm.com> <50C88FB6.20103@oracle.com>
	<50C99982.4040307@linux.vnet.ibm.com> <50CB1E36.6020000@oracle.com>
	<50D00ED2.4060502@linux.vnet.ibm.com>
	<50F8F15F.9010200@linux.vnet.ibm.com> <50FD121D.2000905@oracle.com>
	<50FE21DD.4040305@linux.vnet.ibm.com> <50FEA838.5010404@oracle.com>
Message-ID: <50FF524B.7000609@linux.vnet.ibm.com>

Hi Alexandr.
   Thanks.

To swing-dev, seems I still need anther member review before 
committing.  Is there anybody who would like to review it?

Best regards,
Frank

On 1/22/2013 10:54 PM, Alexander Scherbatiy wrote:
> On 1/22/2013 9:21 AM, Frank Ding wrote:
>> Hi Alexandr,
>>   Thanks for your information.  I have created a new webrev review @
>> http://cr.openjdk.java.net/~dingxmin/8000326/webrev.03/
>>   Pls take a look.
>
>        The fix looks good for me.
>
>>   By the way, please let me know once 2401619 is migrated to the bug 
>> system.
>        I will let you know.
>
>        Thanks,
>        Alexandr.
>>
>> Best regards,
>> Frank
>>
>> On 1/21/2013 6:02 PM, Alexander Scherbatiy wrote:
>>> On 1/18/2013 10:53 AM, Frank Ding wrote:
>>>> Hi Alexandr,
>>>>   Could you please let me know if there is any update on review 
>>>> result?  I did not receive any review information of 2401619 which 
>>>> means it's still not public/reviewed yet, right?
>>>      I got answers from the javadoc team:
>>>       8000326
>>>        The JMenuBar javadoc could be updated to
>>>       -------------------------
>>>       By default, pressing the Tab key does not transfer focus from 
>>> a <code>JMenuBar</code> which is added to a container together with 
>>> other Swing components, because the 
>>> <code>focusTraversalKeysEnabled</code> property of 
>>> <code>JMenuBar</code> is set to <code>false</code>. To resolve this, 
>>> you should call the 
>>> <code>JMenuBar.setFocusTraversalKeysEnabled(true)</code> method.
>>>       -------------------------
>>>
>>>      2401619
>>>         Yes, there should be "will return" expression instead of the 
>>> "with return"?
>>>          The 2401619 java incident has not been migrated yet to the 
>>> bug system.
>>>
>>>     Thanks,
>>>     Alexandr.
>>>
>>>
>>>>
>>>> Best regards,
>>>> Frank
>>>>
>>>> On 12/18/2012 2:36 PM, Frank Ding wrote:
>>>>> Thanks, Alexandr.
>>>>>
>>>>> On 12/14/2012 8:40 PM, Alexander Scherbatiy wrote:
>>>>>> On 12/13/2012 1:01 PM, Frank Ding wrote:
>>>>>>> Hi Alexandr,
>>>>>>>   I made another change according to your comment @ 
>>>>>>> http://cr.openjdk.java.net/~dingxmin/8000326/webrev.02 . Please 
>>>>>>> review it.
>>>>>>>   I submitted a bug whose internal review ID is 2401619 about 
>>>>>>> one wording mistake in ContainerOrderFocusTraversalPolicy. But 
>>>>>>> since the bug system transition, newly submitted bugs cannot 
>>>>>>> pass review and get publicly available.  Can you help me to have 
>>>>>>> somebody review it?
>>>>>>
>>>>>>      I resent the both issues 8000326 and 2401619 to the JDK doc 
>>>>>> team to review.
>>>>>>
>>>>>>      Thanks,
>>>>>>      Alexandr.
>>>>>>
>>>>>>>
>>>>>>>   Thanks and Best regards,
>>>>>>>   Frank
>>>>>>>
>>>>>>> On 12/12/2012 10:07 PM, Alexander Scherbatiy wrote:
>>>>>>>> On 12/10/2012 11:08 AM, Frank Ding wrote:
>>>>>>>>> Hi Pavel,
>>>>>>>>>   I think pointing out the special behavior in javadoc makes 
>>>>>>>>> more sense.  Could you please take a look at my draft below?
>>>>>>>>> http://cr.openjdk.java.net/~dingxmin/8000326/webrev.01
>>>>>>>>      I think that It has more sense to point this special 
>>>>>>>> behavior in the JMenuBar class itself.
>>>>>>>>      It looks more naturally to read about the JMenuBar focus 
>>>>>>>> traversal behaviour from the JMenuBar javadoc.
>>>>>>>>
>>>>>>>>>   Note that I think in the sentence "By default, methods of 
>>>>>>>>> this class with return a Component only if it is" it should be 
>>>>>>>>> "will" not "with", shouldn't it?
>>>>>>>>      Thank you that you point it out. Could you create an issue 
>>>>>>>> on it?
>>>>>>>>
>>>>>>>>     Thanks,
>>>>>>>>     Alexandr.
>>>>>>>>>
>>>>>>>>>   Expecting your reply.
>>>>>>>>> Best regards,
>>>>>>>>> Frank
>>>>>>>>>
>>>>>>>>> On 10/8/2012 7:47 PM, pavel porvatov wrote:
>>>>>>>>>> Hi Jonathan,
>>>>>>>>>>> Hi Pavel,
>>>>>>>>>>>
>>>>>>>>>>> On 10/02/2012 11:31 PM, Pavel Porvatov wrote:
>>>>>>>>>>>> Hi Jonathan,
>>>>>>>>>>>>> Hi Pavel,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've filed bug 7198816 for this problem,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards, Pavel
>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=7198816
>>>>>>>>>>>> This bug was not ported to jira, so I created another bug:
>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8000326
>>>>>>>>>>>
>>>>>>>>>>> Thanks for porting, but I have trouble with opening that link.
>>>>>>>>>> Sorry, use the following link:
>>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000326
>>>>>>>>>>
>>>>>>>>>> but the bug is not available yet... It contains the same 
>>>>>>>>>> description as the original bug.
>>>>>>>>>>
>>>>>>>>>>> Any comments on the patch?
>>>>>>>>>> The fix looks dangerous for me. After the fix the 
>>>>>>>>>> setFocusTraversalKeysEnabled method doesn't work for JMenuBar 
>>>>>>>>>> (when ContainerOrderFocusTraversalPolicy is used) - it 
>>>>>>>>>> ignores this property...
>>>>>>>>>>
>>>>>>>>>> Regards, Pavel
>>>>>>>>>>>
>>>>>>>>>>> best regards
>>>>>>>>>>> Jonathan
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards, Pavel
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/09/2011 07:25 PM, Pavel Porvatov wrote:
>>>>>>>>>>>>>> Hi Jing,
>>>>>>>>>>>>>>> Thanks Pavel,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>      It seems fine to me, if no other 
>>>>>>>>>>>>>>> suggestions/opinions, I guess we can move on with this?
>>>>>>>>>>>>>> Yes, we can. Could you please file a bug for the problem 
>>>>>>>>>>>>>> as well?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks, Pavel
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 2011/11/2 19:58, Pavel Porvatov wrote:
>>>>>>>>>>>>>>>> Hi Jing,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hello Anton,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     Thanks for the review. I am still trying to figure 
>>>>>>>>>>>>>>>>> out some real case and provide more detail the 
>>>>>>>>>>>>>>>>> customer may fail.
>>>>>>>>>>>>>>>>>     Anyway, I agree we'd better update the java spec 
>>>>>>>>>>>>>>>>> to make it clear for the customers. I'd like to know 
>>>>>>>>>>>>>>>>> if anyone can help with that?
>>>>>>>>>>>>>>>> I'm not sure that javadoc changing is a good decision 
>>>>>>>>>>>>>>>> in this case. ContainerOrderFocusTraversalPolicy is 
>>>>>>>>>>>>>>>> designed for AWT, but I don't know why that policy 
>>>>>>>>>>>>>>>> cannot be used for Swing components as well. I see 
>>>>>>>>>>>>>>>> several problems:
>>>>>>>>>>>>>>>> 1. We cannot change javadoc of 
>>>>>>>>>>>>>>>> ContainerOrderFocusTraversalPolicy because of backward 
>>>>>>>>>>>>>>>> compatibility
>>>>>>>>>>>>>>>> 2. We cannot remove setFocusTraversalKeysEnabled(false) 
>>>>>>>>>>>>>>>> from the JMenuBar#JMenuBar() constructor because of 
>>>>>>>>>>>>>>>> backward compatibility
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> May be the best decision is to specify, that JMenuBar 
>>>>>>>>>>>>>>>> creates menu with the focusTraversalKeysEnabled = false
>>>>>>>>>>>>>
>>>>>>>>>>>>> Did you mean that for the new menu 
>>>>>>>>>>>>> setFocusTraversalKeysEnabled(false) ? I've tried, but it 
>>>>>>>>>>>>> does not seem to work for this problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>>  if my understanding is incorrect, please help to fix me.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regards, Pavel
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 2011/10/12 20:54, Anton Tarasov wrote:
>>>>>>>>>>>>>>>>>> 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).
>>>>>>>>>>>>>
>>>>>>>>>>>>> I agree that backward compatibility should not be broken 
>>>>>>>>>>>>> by the fix, so here's a patch from me for the worst case, 
>>>>>>>>>>>>> could you please help to take a look?
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~luchsh/7198816/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Jonathan
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 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 Sergey.Malenkov at oracle.com  Wed Jan 23 14:21:38 2013
From: Sergey.Malenkov at oracle.com (Sergey Malenkov)
Date: Wed, 23 Jan 2013 18:21:38 +0400
Subject: <Swing Dev> [8] Review request for 8003400: JTree scrolling
 problem when using large model
In-Reply-To: <50FE9456.5040502@oracle.com>
References: <50F6AB33.1030807@oracle.com>
	<50F6C43C.7030203@oracle.com>	<50F6CD80.8060201@oracle.com>
	<50F6E792.2000108@oracle.com> <50FE9456.5040502@oracle.com>
Message-ID: <50FFF1F2.5000503@oracle.com>

Hi Alexander,

I agree, because someone could use new JLayer to wrap JTree.

Could you please review the next version of the fix:
http://cr.openjdk.java.net/~malenkov/8003400.3/

Thanks,
SAM

On 22.01.2013 17:29, Alexander Scherbatiy wrote:
>
>    I see that some swing classes use SwingUtilities.getUnwrappedParent()
> method to get the first non JLayer parent.
>    Does it have sense to skip JLayer components to get the JViewport in
> this fix too?
>
>    Thanks,
>    Alexandr.
>
> On 1/16/2013 9:46 PM, Sergey Malenkov wrote:
>> Hi Sergey,
>>
>> > Looks like in the updateCachedPreferredSize we should add
>> > size of scrollbar not a rowSize, since they can be different.
>>
>> Good point. I've prepared the third version of the fix:
>> http://cr.openjdk.java.net/~malenkov/8003400.2/
>>
>> > In this case new invokeLater is not necessary.
>>
>> It is needed because we should ensure that selected row is visible
>> after then the horizontal scroll bar is added.
>>
>> > Also it would be good to dispose the frame in the test.
>>
>> It is disposed, but only for JavaTest.
>> For manual testing it is useful to see the result.
>>
>>
>> Thanks,
>> SAM
>>
>> On 16.01.2013 19:55, Sergey Bylokhov wrote:
>>> Looks like in the updateCachedPreferredSize we should add size of
>>> scrollbar not a rowSize, since they can be different. In this case new
>>> invokeLater is not necessary. Also it would be good to dispose the frame
>>> in the test.
>>>
>>> 16.01.2013 19:16, Sergey Malenkov wrote:
>>>> Hello,
>>>>
>>>> This is the second version, in which the automatic test is stabilized.
>>>> I've added a lock to ensure that JavaTest does not close the window
>>>> before the test is finished.
>>>>
>>>> Thanks,
>>>> SAM
>>>>
>>>> On 16.01.2013 17:29, Sergey Malenkov wrote:
>>>>> Hello,
>>>>>
>>>>> Could you please review the following fix:
>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003400
>>>>> fix: http://cr.openjdk.java.net/~malenkov/8003400.0/
>>>>>
>>>>> JTree with the large model calculates widths for visible rows only.
>>>>> The
>>>>> problem is that the horizontal scroll bar appears after moving to the
>>>>> end and hides the last row. The automatic test is included.
>>>>>
>>>>> Thanks,
>>>>> SAM


From Vladislav.Karnaukhov at oracle.com  Thu Jan 24 08:32:20 2013
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Thu, 24 Jan 2013 12:32:20 +0400
Subject: <Swing Dev> [8] Review request for 4199622 RFE: JComboBox
 shouldn't sending ActionEvents for keyboard navigation
In-Reply-To: <50FD3F53.901@oracle.com>
References: <50F6A3EF.3000705@oracle.com> <50F7FDA4.9040600@oracle.com>
	<50FD3F53.901@oracle.com>
Message-ID: <5100F194.2000102@oracle.com>

Hello Alexander, all,

please find the new version here: 
http://cr.openjdk.java.net/~vkarnauk/4199622/webrev.03/

Please see comments inline.

Regards,
- Vlad

On 1/21/2013 05:14 PM, Alexander Scherbatiy wrote:
>
>     Some small comments:
>      - Keys Up and Down do not work with WindowsLookAndFeel and enabled
> ComboBox.noActionOnKeyNavigation property. Is it expected behavior?
The fix was changed so now it will disable actionPerformed events only 
when the drop-down list is visible. This will eliminate Windows L&F 
issue. All LAFs will work in the same manner.

>      - Method getNextIndex from the BasicComboBoxUI class is private, so
> it is possible to pass the ui variable as an argument rather to obtain
> it one more time
Fixed.

>      - Cancel action does not set the ui.listBox selected index to the
> initial state. However,  it seems that it works correct when the popup
> is opened next time.
Could you please elaborate more on this? I'm afraid I didn't quite 
understand the issue here...

>
>    Thanks,
>    Alexandr.
>
> On 1/17/2013 5:33 PM, Vladislav Karnaukhov wrote:
>> Hello,
>>
>> please review a new version of the fix:
>> http://cr.openjdk.java.net/~vkarnauk/4199622/webrev.02/
>>
>> Support for VK_PAGE_DOWN/VK_PAGE_UP and VK_HOME/VK_END keys was added;
>> test routine was altered accordingly.
>>
>> Regards,
>> - Vlad
>




From alexandr.scherbatiy at oracle.com  Thu Jan 24 08:42:25 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 24 Jan 2013 12:42:25 +0400
Subject: <Swing Dev> [8] Review request for 8003400: JTree scrolling
 problem when using large model
In-Reply-To: <50FFF1F2.5000503@oracle.com>
References: <50F6AB33.1030807@oracle.com>
	<50F6C43C.7030203@oracle.com>	<50F6CD80.8060201@oracle.com>
	<50F6E792.2000108@oracle.com> <50FE9456.5040502@oracle.com>
	<50FFF1F2.5000503@oracle.com>
Message-ID: <5100F3F1.3000405@oracle.com>


    The fix looks good for me.

    Thanks,
    Alexandr.

On 1/23/2013 6:21 PM, Sergey Malenkov wrote:
> Hi Alexander,
>
> I agree, because someone could use new JLayer to wrap JTree.
>
> Could you please review the next version of the fix:
> http://cr.openjdk.java.net/~malenkov/8003400.3/
>
> Thanks,
> SAM
>
> On 22.01.2013 17:29, Alexander Scherbatiy wrote:
>>
>>    I see that some swing classes use SwingUtilities.getUnwrappedParent()
>> method to get the first non JLayer parent.
>>    Does it have sense to skip JLayer components to get the JViewport in
>> this fix too?
>>
>>    Thanks,
>>    Alexandr.
>>
>> On 1/16/2013 9:46 PM, Sergey Malenkov wrote:
>>> Hi Sergey,
>>>
>>> > Looks like in the updateCachedPreferredSize we should add
>>> > size of scrollbar not a rowSize, since they can be different.
>>>
>>> Good point. I've prepared the third version of the fix:
>>> http://cr.openjdk.java.net/~malenkov/8003400.2/
>>>
>>> > In this case new invokeLater is not necessary.
>>>
>>> It is needed because we should ensure that selected row is visible
>>> after then the horizontal scroll bar is added.
>>>
>>> > Also it would be good to dispose the frame in the test.
>>>
>>> It is disposed, but only for JavaTest.
>>> For manual testing it is useful to see the result.
>>>
>>>
>>> Thanks,
>>> SAM
>>>
>>> On 16.01.2013 19:55, Sergey Bylokhov wrote:
>>>> Looks like in the updateCachedPreferredSize we should add size of
>>>> scrollbar not a rowSize, since they can be different. In this case new
>>>> invokeLater is not necessary. Also it would be good to dispose the 
>>>> frame
>>>> in the test.
>>>>
>>>> 16.01.2013 19:16, Sergey Malenkov wrote:
>>>>> Hello,
>>>>>
>>>>> This is the second version, in which the automatic test is 
>>>>> stabilized.
>>>>> I've added a lock to ensure that JavaTest does not close the window
>>>>> before the test is finished.
>>>>>
>>>>> Thanks,
>>>>> SAM
>>>>>
>>>>> On 16.01.2013 17:29, Sergey Malenkov wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Could you please review the following fix:
>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003400
>>>>>> fix: http://cr.openjdk.java.net/~malenkov/8003400.0/
>>>>>>
>>>>>> JTree with the large model calculates widths for visible rows only.
>>>>>> The
>>>>>> problem is that the horizontal scroll bar appears after moving to 
>>>>>> the
>>>>>> end and hides the last row. The automatic test is included.
>>>>>>
>>>>>> Thanks,
>>>>>> SAM



From Sergey.Bylokhov at oracle.com  Thu Jan 24 11:18:41 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 24 Jan 2013 15:18:41 +0400
Subject: <Swing Dev> [8] Review request for 8003400: JTree scrolling
 problem when using large model
In-Reply-To: <50FFF1F2.5000503@oracle.com>
References: <50F6AB33.1030807@oracle.com>
	<50F6C43C.7030203@oracle.com>	<50F6CD80.8060201@oracle.com>
	<50F6E792.2000108@oracle.com> <50FE9456.5040502@oracle.com>
	<50FFF1F2.5000503@oracle.com>
Message-ID: <51011891.30007@oracle.com>

Hi, Sergey.
Fix looks good.

23.01.2013 18:21, Sergey Malenkov wrote:
> Hi Alexander,
>
> I agree, because someone could use new JLayer to wrap JTree.
>
> Could you please review the next version of the fix:
> http://cr.openjdk.java.net/~malenkov/8003400.3/
>
> Thanks,
> SAM
>
> On 22.01.2013 17:29, Alexander Scherbatiy wrote:
>>
>>    I see that some swing classes use SwingUtilities.getUnwrappedParent()
>> method to get the first non JLayer parent.
>>    Does it have sense to skip JLayer components to get the JViewport in
>> this fix too?
>>
>>    Thanks,
>>    Alexandr.
>>
>> On 1/16/2013 9:46 PM, Sergey Malenkov wrote:
>>> Hi Sergey,
>>>
>>> > Looks like in the updateCachedPreferredSize we should add
>>> > size of scrollbar not a rowSize, since they can be different.
>>>
>>> Good point. I've prepared the third version of the fix:
>>> http://cr.openjdk.java.net/~malenkov/8003400.2/
>>>
>>> > In this case new invokeLater is not necessary.
>>>
>>> It is needed because we should ensure that selected row is visible
>>> after then the horizontal scroll bar is added.
>>>
>>> > Also it would be good to dispose the frame in the test.
>>>
>>> It is disposed, but only for JavaTest.
>>> For manual testing it is useful to see the result.
>>>
>>>
>>> Thanks,
>>> SAM
>>>
>>> On 16.01.2013 19:55, Sergey Bylokhov wrote:
>>>> Looks like in the updateCachedPreferredSize we should add size of
>>>> scrollbar not a rowSize, since they can be different. In this case new
>>>> invokeLater is not necessary. Also it would be good to dispose the 
>>>> frame
>>>> in the test.
>>>>
>>>> 16.01.2013 19:16, Sergey Malenkov wrote:
>>>>> Hello,
>>>>>
>>>>> This is the second version, in which the automatic test is 
>>>>> stabilized.
>>>>> I've added a lock to ensure that JavaTest does not close the window
>>>>> before the test is finished.
>>>>>
>>>>> Thanks,
>>>>> SAM
>>>>>
>>>>> On 16.01.2013 17:29, Sergey Malenkov wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Could you please review the following fix:
>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003400
>>>>>> fix: http://cr.openjdk.java.net/~malenkov/8003400.0/
>>>>>>
>>>>>> JTree with the large model calculates widths for visible rows only.
>>>>>> The
>>>>>> problem is that the horizontal scroll bar appears after moving to 
>>>>>> the
>>>>>> end and hides the last row. The automatic test is included.
>>>>>>
>>>>>> Thanks,
>>>>>> SAM


-- 
Best regards, Sergey.



From Sergey.Bylokhov at oracle.com  Thu Jan 24 11:35:05 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 24 Jan 2013 15:35:05 +0400
Subject: <Swing Dev> [8] Review request for 6817933: Setting the
 background of an HTML Widget changes the native Windows JFileChooser
In-Reply-To: <50FEC75D.9020405@oracle.com>
References: <50FD1B21.60302@oracle.com> <50FD226C.7000704@oracle.com>
	<50FEC75D.9020405@oracle.com>
Message-ID: <51011C69.3070205@oracle.com>

Hi Sergey,
Fix looks good.

22.01.2013 21:07, Sergey Malenkov wrote:
> Hi Sergey,
>
> After the discussion offline we decided to fix the WindowsPlacesBar 
> class instead of the API-related change.
>
> Could you please review the following fix:
> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6817933
> fix: http://cr.openjdk.java.net/~malenkov/6817933.1/
>
> I removed HTML-based text from the JToggleButton. The automatic test 
> is included.
>
> Thanks,
> SAM
>
> On 21.01.2013 15:11, Sergey Bylokhov wrote:
>> Hi, Sergey
>> Not sure that this change correspond to documentation:
>> "
>>
>>   373     /**
>>   374      * Get the set of styles currently being used to render the
>>   375      * HTML elements.  By default the resource specified by
>>   376      * DEFAULT_CSS gets loaded, and is*shared*  by all 
>> HTMLEditorKit
>>   377      * instances.
>>   378      */
>>
>> "
>> What does it mean: "shared"?
>>
>> 21.01.2013 14:40, Sergey Malenkov wrote:
>>> Hello,
>>>
>>> Could you please review the following fix:
>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6817933
>>> fix: http://cr.openjdk.java.net/~malenkov/6817933.0/
>>>
>>> The styleSheet property of the HTMLEditorKit class have a static
>>> behavior. It must be non-static because of JavaBeans spec. The
>>> automatic test is included.
>>>
>>> Thanks,
>>> SAM


-- 
Best regards, Sergey.



From alexandr.scherbatiy at oracle.com  Thu Jan 24 12:05:37 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 24 Jan 2013 16:05:37 +0400
Subject: <Swing Dev> [8] Review request for 6817933: Setting the
 background of an HTML Widget changes the native Windows JFileChooser
In-Reply-To: <50FEC75D.9020405@oracle.com>
References: <50FD1B21.60302@oracle.com> <50FD226C.7000704@oracle.com>
	<50FEC75D.9020405@oracle.com>
Message-ID: <51012391.8000600@oracle.com>


   The fix looks good for me.

   Thanks,
   Alexandr.

On 1/22/2013 9:07 PM, Sergey Malenkov wrote:
> Hi Sergey,
>
> After the discussion offline we decided to fix the WindowsPlacesBar 
> class instead of the API-related change.
>
> Could you please review the following fix:
> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6817933
> fix: http://cr.openjdk.java.net/~malenkov/6817933.1/
>
> I removed HTML-based text from the JToggleButton. The automatic test 
> is included.
>
> Thanks,
> SAM
>
> On 21.01.2013 15:11, Sergey Bylokhov wrote:
>> Hi, Sergey
>> Not sure that this change correspond to documentation:
>> "
>>
>>   373     /**
>>   374      * Get the set of styles currently being used to render the
>>   375      * HTML elements.  By default the resource specified by
>>   376      * DEFAULT_CSS gets loaded, and is*shared*  by all 
>> HTMLEditorKit
>>   377      * instances.
>>   378      */
>>
>> "
>> What does it mean: "shared"?
>>
>> 21.01.2013 14:40, Sergey Malenkov wrote:
>>> Hello,
>>>
>>> Could you please review the following fix:
>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6817933
>>> fix: http://cr.openjdk.java.net/~malenkov/6817933.0/
>>>
>>> The styleSheet property of the HTMLEditorKit class have a static
>>> behavior. It must be non-static because of JavaBeans spec. The
>>> automatic test is included.
>>>
>>> Thanks,
>>> SAM



From alexandr.scherbatiy at oracle.com  Thu Jan 24 13:57:28 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 24 Jan 2013 17:57:28 +0400
Subject: <Swing Dev> [8] Review request for 4199622 RFE: JComboBox
 shouldn't sending ActionEvents for keyboard navigation
In-Reply-To: <5100F194.2000102@oracle.com>
References: <50F6A3EF.3000705@oracle.com>
	<50F7FDA4.9040600@oracle.com>	<50FD3F53.901@oracle.com>
	<5100F194.2000102@oracle.com>
Message-ID: <51013DC8.70609@oracle.com>


- MetalLookAndFeel and ComboBox.noActionOnKeyNavigation property is set
     Press down, select an item, press enter. The drop down list is not 
closed
- WindowsLookAndFeel and ComboBox.noActionOnKeyNavigation property is set
    Home/End and PgUp/PgDn keys do not work

On 1/24/2013 12:32 PM, Vladislav Karnaukhov wrote:
> Hello Alexander, all,
>
> please find the new version here: 
> http://cr.openjdk.java.net/~vkarnauk/4199622/webrev.03/
>
> Please see comments inline.
>
> Regards,
> - Vlad
>
> On 1/21/2013 05:14 PM, Alexander Scherbatiy wrote:
>>      - Cancel action does not set the ui.listBox selected index to the
>> initial state. However,  it seems that it works correct when the popup
>> is opened next time.
> Could you please elaborate more on this? I'm afraid I didn't quite 
> understand the issue here...

       Use case: Press down on a JComboBox, select an item which is 
deffirent from the initial item, press escape. The combobox selected 
item has the initial value but the ui.listBox has another.
       It could leads to some sort of synchronization issues.

     Thanks,
     Alexandr.

>
>>
>>    Thanks,
>>    Alexandr.
>>
>> On 1/17/2013 5:33 PM, Vladislav Karnaukhov wrote:
>>> Hello,
>>>
>>> please review a new version of the fix:
>>> http://cr.openjdk.java.net/~vkarnauk/4199622/webrev.02/
>>>
>>> Support for VK_PAGE_DOWN/VK_PAGE_UP and VK_HOME/VK_END keys was added;
>>> test routine was altered accordingly.
>>>
>>> Regards,
>>> - Vlad
>>
>
>



From Vladislav.Karnaukhov at oracle.com  Thu Jan 24 14:12:28 2013
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Thu, 24 Jan 2013 18:12:28 +0400
Subject: <Swing Dev> [8] Review request for 4199622 RFE: JComboBox
 shouldn't sending ActionEvents for keyboard navigation
In-Reply-To: <51013DC8.70609@oracle.com>
References: <50F6A3EF.3000705@oracle.com>
	<50F7FDA4.9040600@oracle.com>	<50FD3F53.901@oracle.com>
	<5100F194.2000102@oracle.com> <51013DC8.70609@oracle.com>
Message-ID: <5101414C.4000002@oracle.com>

Hi Alexander,

On 1/24/2013 05:57 PM, Alexander Scherbatiy wrote:
>
> - MetalLookAndFeel and ComboBox.noActionOnKeyNavigation property is set
>      Press down, select an item, press enter. The drop down list is not
> closed
Oops, forgot one comboBox.setPopupVisible(false); call... Fixed.

> - WindowsLookAndFeel and ComboBox.noActionOnKeyNavigation property is set
>     Home/End and PgUp/PgDn keys do not work
This one is more complex. Working on it...

Thanks for the review!



From dingxmin at linux.vnet.ibm.com  Mon Jan 28 09:04:56 2013
From: dingxmin at linux.vnet.ibm.com (Frank Ding)
Date: Mon, 28 Jan 2013 17:04:56 +0800
Subject: <Swing Dev> 7189299 DefaultButtonModel instance keeps stale
 listeners of JButton in case of multiple
 SwingUtilities.updateComponentTreeUI() calls
In-Reply-To: <50FD456C.20601@oracle.com>
References: <501F6E2E.1020608@linux.vnet.ibm.com> <506ED516.5020706@oracle.com>
	<50727AFF.3060004@linux.vnet.ibm.com>	<507440C4.9060504@oracle.com>
	<50751427.4040706@linux.vnet.ibm.com>	<50778B0F.6040407@linux.vnet.ibm.com>
	<507BD467.2000405@oracle.com>	<507E4752.3040302@linux.vnet.ibm.com>
	<508E34D7.1060308@linux.vnet.ibm.com> <508FD85D.6010600@oracle.com>
	<5092184A.2040303@linux.vnet.ibm.com> <5092664A.4010504@oracle.com>
	<509768B0.6000802@linux.vnet.ibm.com> <5099101D.1020507@oracle.com>
	<509A0639.1030806@linux.vnet.ibm.com> <509BC7EE.7000801@oracle.com>
	<50A1FC8F.7060107@linux.vnet.ibm.com> <50A233B2.5020602@oracle.com>
	<50A338B5.7070302@linux.vnet.ibm.com> <50A4B369.3030009@oracle.com>
	<50B5AF37.3070307@linux.vnet.ibm.com> <50BC8497.5030409@oracle.com>
	<50BEE5DE.9020803@linux.vnet.ibm.com>	<50C059CF.4090806@linux.vnet.ibm.com>
	<50C5BC18.8030009@oracle.com> <50DD0EF1.9070908@linux.vnet.ibm.com>
	<50F8F0CA.1070403@linux.vnet.ibm.com> <50FD456C.20601@oracle.com>
Message-ID: <51063F38.4050906@linux.vnet.ibm.com>

Hi Alexandr,
   Thanks for your suggestion.  I will prepare a patch according to it soon.

Best regards,
Frank

On 1/21/2013 9:41 PM, Alexander Scherbatiy wrote:
> On 1/18/2013 10:50 AM, Frank Ding wrote:
>> Hi Alexandr,
>>   Do you have any idea?
>
>    What about one more way removing listeners:
>     - disadvantage: listeners are hardcoded
>     - advantage: there is no need to override JButton, JList,... classes
>
>      ------------------------------------------
>     private void clearModel(Object model) {
>         if (model instanceof DefaultButtonModel) {
>             DefaultButtonModel buttonModel = (DefaultButtonModel) model;
>             String listenerClass = "javax.swing.AbstractButton$Handler";
>
>             for (ActionListener listener : 
> buttonModel.getActionListeners()) {
>                 if 
> (listenerClass.equals(listener.getClass().getName())) {
>                     buttonModel.removeActionListener(listener);
>                 }
>             }
>             // remove change listeners
>             // remove item listeners
>
>         } else if(model instanceof ListModel){
>             // remove list listeners
>         }
>     }
>      ------------------------------------------
>
>    Thanks,
>     Alexandr.
>
>>
>> Best regards,
>> Frank
>>
>> On 12/28/2012 11:16 AM, Frank Ding wrote:
>>> Hi Alexandr,
>>>   I did some more investigations.
>>>   1. The model can be accessed as below which is also illustrated in 
>>> the jtreg test
>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/test/javax/swing/text/html/7189299/bug7189299.java.html 
>>>
>>>
>>>   HTMLEditorKit htmlEditorKit = (HTMLEditorKit) html.getEditorKit();
>>>   StyleContext.NamedStyle style = ((StyleContext.NamedStyle) 
>>> htmlEditorKit.getInputAttributes());
>>>   DefaultButtonModel model = ((DefaultButtonModel) 
>>> style.getAttribute(StyleConstants.ModelAttribute));
>>>
>>>   Though it needs type conversion, model can be exposed to client 
>>> code.  This implies client code has the chance to add listeners.
>>>   Another way of updating listener in model is by first getting 
>>> JButton or other html Swing components and then call listener 
>>> related api that affects model.  I dumped vars above but did not 
>>> find out possibility for application to get Swing component reference.
>>>
>>>   2. As of swing.text.html library, I searched 'ModelAttribute' 
>>> under javax/swing directory with command "grep -R 'ModelAttribute' 
>>> ." which shows aside from FormView and StyleConstants, the classes 
>>> referencing it are HTMLDocument, HTMLWriter.  This means only 
>>> FormView adds listeners to model.
>>>
>>>   My first attempt at fixing the problem (only for JButton listener 
>>> leak) is trying to remove all listeners completely. See 
>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.01/. Pavel 
>>> argued that it may cause existing application to malfunction. Then I 
>>> came up with http://cr.openjdk.java.net/~dingxmin/7189299/webrev.02/ 
>>> where only stale listeners are identified and removed using 
>>> reflection.  But Pavel insisted reflection should be prohibited.  So 
>>> I tried to work around it by extending JButton in FormView to access 
>>> the private listener instance such that only stale listener is 
>>> removed.  The perfect revision is 
>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/.
>>>
>>>   I propose we fix JButton issue as it leads to NPE visible to 
>>> application.  Bug in other components can be put off if Swing team 
>>> intend to fix it elegantly or duplicate code like what is in v.07.
>>>   Any idea or comment, please let me know.
>>>
>>>   Thanks and best regards,
>>>   Frank
>>>
>>> On 12/10/2012 6:40 PM, Alexander Scherbatiy wrote:
>>>> On 12/6/2012 12:39 PM, Frank Ding wrote:
>>>>> Hi Alexandr,
>>>>>    I did several attempts but still have hang issues somewhere. It 
>>>>> seems the new approach of caching gui components created each time 
>>>>> is not practical because of the threading restriction already 
>>>>> imposed on HTMLDocument.
>>>>>    Can we make compromise by turning to previous solution (v7 in 
>>>>> particular) and generalize it to other gui components (which means 
>>>>> there would be JCheckBoxWrapper, JRadioButtonWrapper,
>>>>
>>>>     The issue is that models contain listeners from all previous 
>>>> components. Models are used to store data and state of components 
>>>> when form view is recreated.
>>>>     FormView adds it's own listeners to components (and as result 
>>>> to the models). Could you make a little investigation to check 
>>>> which other listeners can the models hold?
>>>>     Can a user adds a listener?  Can listeners be added by other 
>>>> parts of the swing.text.html library?
>>>>
>>>>     If old listeners does not play role, it is possible just to 
>>>> remove them all.
>>>>
>>>>     Thanks,
>>>>     Alexandr.
>>>>
>>>>> JPasswordFieldWrapper, JTextFieldWrapper, JListWrapper, 
>>>>> JComboBoxWrapper, and JButtonWrapper).  Or shall we fix JButton 
>>>>> only because it causes obvious exception visible to client?  I am 
>>>>> short of ideas...
>>>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/
>>>>>
>>>>> Best regards,
>>>>> Frank
>>>>>
>>>>> On 12/5/2012 2:12 PM, Frank Ding wrote:
>>>>>> Hi Alexandr,
>>>>>>   I observed the same issue in my environment as well. My 
>>>>>> proposed patch would cause severe regression issues. I am looking 
>>>>>> into the locking issue.
>>>>>>
>>>>>> Thanks,
>>>>>> Frank
>>>>>>
>>>>>> On 12/3/2012 6:53 PM, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>>
>>>>>>>  Could you check the following sample with your latest fix? It 
>>>>>>> just hangs on my side.
>>>>>>>
>>>>>>>    - put the sample.html  and the response.html  files on a server
>>>>>>>    - update path to the html files in the 
>>>>>>> LoadingWebPageToJEditorPane class
>>>>>>>
>>>>>>> -------------     sample.html  ------------
>>>>>>> <form name="input" action="response.html" method="get">
>>>>>>> Username: <input type="text" name="user">
>>>>>>> <input type="submit" value="Submit">
>>>>>>> </form>
>>>>>>> -------------     response.html  ------------
>>>>>>> <html>
>>>>>>> <body>
>>>>>>> Hello World!
>>>>>>> </body>
>>>>>>> </html>
>>>>>>> -------------     LoadingWebPageToJEditorPane.html ------------
>>>>>>> import java.net.URL;
>>>>>>> import javax.swing.JEditorPane;
>>>>>>> import javax.swing.JFrame;
>>>>>>> import javax.swing.JScrollPane;
>>>>>>> import javax.swing.SwingUtilities;
>>>>>>>
>>>>>>> public class LoadingWebPageToJEditorPane {
>>>>>>>
>>>>>>>     private static final String HTML_PATH = 
>>>>>>> "http://serever/path/sample.html";
>>>>>>>
>>>>>>>     public static void main(String[] a) throws Exception {
>>>>>>>
>>>>>>>         SwingUtilities.invokeAndWait(new Runnable() {
>>>>>>>
>>>>>>>             @Override
>>>>>>>             public void run() {
>>>>>>>                 try {
>>>>>>>
>>>>>>>                     JFrame frame = new JFrame();
>>>>>>> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>>>>>>
>>>>>>>                     JEditorPane editorPane = new JEditorPane();
>>>>>>>                     editorPane.setPage(new URL(HTML_PATH));
>>>>>>>
>>>>>>>                     frame.add(new JScrollPane(editorPane));
>>>>>>>                     frame.setSize(300, 200);
>>>>>>>                     frame.setVisible(true);
>>>>>>> SwingUtilities.updateComponentTreeUI(editorPane);
>>>>>>>                 } catch (Exception ex) {
>>>>>>>                     throw new RuntimeException(ex);
>>>>>>>                 }
>>>>>>>             }
>>>>>>>         });
>>>>>>>     }
>>>>>>> }
>>>>>>> ---------------------------------------
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexandr.
>>>>>>>
>>>>>>>
>>>>>>> On 11/28/2012 10:29 AM, Frank Ding wrote:
>>>>>>>> Hi Alexandr,
>>>>>>>>   I created a new patch v8 @ 
>>>>>>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.08/. It 
>>>>>>>> uses the newly proposed approach mentioned in my last email. 
>>>>>>>> Could you please help to review it again?
>>>>>>>>
>>>>>>>>   The patch, of course, passed jtreg test bug7189299.java in 
>>>>>>>> the patch.  What's more, I did additional tests for JComboBox, 
>>>>>>>> JTextField and JList in my IDE by comparing listener numbers 
>>>>>>>> observed during debugging with/without my patch.  The listener 
>>>>>>>> numbers were doubled without the fix.  This proves that v8 
>>>>>>>> patch works for all components. I think I can write those 
>>>>>>>> additional tests as jtreg tests after the patch passes review.
>>>>>>>>
>>>>>>>>    One notable change is that I had to restrict the scope of 
>>>>>>>> holding a write lock in DefaultStyledDocument because 
>>>>>>>> otherwise, we cannot store the new component created in 
>>>>>>>> FormView.createComponent().  The stack trace is pasted below 
>>>>>>>> for reference.
>>>>>>>>
>>>>>>>> Exception in thread "main" 
>>>>>>>> java.lang.reflect.InvocationTargetException
>>>>>>>>     at java.awt.EventQueue.invokeAndWait(EventQueue.java:1270)
>>>>>>>>     at 
>>>>>>>> javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1350)
>>>>>>>>     at bug7189299.main(bug7189299.java:116)
>>>>>>>> Caused by: java.lang.IllegalStateException: Attempt to mutate 
>>>>>>>> in notification
>>>>>>>>     at 
>>>>>>>> javax.swing.text.AbstractDocument.writeLock(AbstractDocument.java:1357) 
>>>>>>>>
>>>>>>>>     at 
>>>>>>>> javax.swing.text.html.HTMLDocument.obtainLock(HTMLDocument.java:1708) 
>>>>>>>>
>>>>>>>>     at 
>>>>>>>> javax.swing.text.html.FormView.createComponent(FormView.java:211)
>>>>>>>> ......(omitted)......
>>>>>>>>     at 
>>>>>>>> javax.swing.plaf.basic.BasicTextUI$RootView.insertUpdate(BasicTextUI.java:1602)
>>>>>>>>     at 
>>>>>>>> javax.swing.plaf.basic.BasicTextUI$UpdateHandler.insertUpdate(BasicTextUI.java:1861)
>>>>>>>>     at 
>>>>>>>> javax.swing.text.AbstractDocument.fireInsertUpdate(AbstractDocument.java:201) 
>>>>>>>>
>>>>>>>>     at 
>>>>>>>> javax.swing.text.DefaultStyledDocument.create(DefaultStyledDocument.java:155) 
>>>>>>>> <------   FormView.createComponent is triggered by this call 
>>>>>>>> which has already held the lock
>>>>>>>>     at 
>>>>>>>> javax.swing.text.html.HTMLDocument.create(HTMLDocument.java:469)
>>>>>>>> ......(omitted)......
>>>>>>>>
>>>>>>>> This change did violate what is documented in 
>>>>>>>> AbstractDocument.writeLock that "This situation violates the 
>>>>>>>> bean event model where order of delivery is not guaranteed and 
>>>>>>>> all listeners should be notified before further mutations are 
>>>>>>>> allowed. " However, without the change of shrinking lock scope, 
>>>>>>>> the component cannot be saved once it is created in 
>>>>>>>> FormView.createComponent(). I found it is even harder to save 
>>>>>>>> it later in code but perhaps there does exist a more 
>>>>>>>> appropriate place to do this.  If you have any better 
>>>>>>>> suggestion, I am glad to know.
>>>>>>>>
>>>>>>>>   Also I searched references to 
>>>>>>>> 'StyleConstants.ComponentAttribute' as you asked. The result is 
>>>>>>>> listed below.  Note that the command 'grep' is invoked under 
>>>>>>>> openjdk 8 top directory.
>>>>>>>> $ grep -R 'ComponentAttribute' .
>>>>>>>> ./jdk/src/share/classes/javax/swing/text/StyleConstants.java: 
>>>>>>>> public static final Object ComponentAttribute = new 
>>>>>>>> CharacterConstants("component");
>>>>>>>> ./jdk/src/share/classes/javax/swing/text/StyleConstants.java: 
>>>>>>>> return (Component) a.getAttribute(ComponentAttribute);
>>>>>>>> ./jdk/src/share/classes/javax/swing/text/StyleConstants.java: 
>>>>>>>> a.addAttribute(ComponentAttribute, c);
>>>>>>>> ./jdk/src/share/classes/javax/swing/text/StyleConstants.java: 
>>>>>>>> Background, ComponentAttribute, IconAttribute,
>>>>>>>> ./jdk/src/share/classes/javax/swing/text/StyledEditorKit.java: 
>>>>>>>> set.removeAttribute(StyleConstants.ComponentAttribute);
>>>>>>>> Binary file ./jdk/test/sun/tools/jhat/jmap.bin matches
>>>>>>>>
>>>>>>>> So ComponentAttribute is not referenced by other classes except 
>>>>>>>> StyledEditorKit.  StyleConstants exposes ComponentAttribute in 
>>>>>>>> getComponent() and setComponent() methods.  References to 
>>>>>>>> StyleConstants.getComponent and StyleConstants.setComponent are 
>>>>>>>> further searched in repo.
>>>>>>>>
>>>>>>>> $ grep -R 'StyleConstants.getComponent' .
>>>>>>>> ./jdk/src/share/classes/javax/swing/text/ComponentView.java: * 
>>>>>>>> the element (by calling StyleConstants.getComponent). A
>>>>>>>> ./jdk/src/share/classes/javax/swing/text/ComponentView.java: 
>>>>>>>> Component comp = StyleConstants.getComponent(attr);
>>>>>>>>
>>>>>>>> $ grep -R 'StyleConstants.setComponent' .
>>>>>>>> ./jdk/src/share/classes/javax/swing/JTextPane.java: 
>>>>>>>> StyleConstants.setComponent(inputAttributes, c);
>>>>>>>>
>>>>>>>> From the facts above, I think we are sufficiently confident to 
>>>>>>>> use ComponentAttribute.
>>>>>>>>
>>>>>>>> Please let me know if you have any comments and I can do more 
>>>>>>>> regression tests and provide more jtreg test cases as next step.
>>>>>>>>
>>>>>>>> Thanks and regards,
>>>>>>>> Frank
>>>>>>>>
>>>>>>>> On 11/15/2012 5:18 PM, Alexander Scherbatiy wrote:
>>>>>>>>> On 11/14/2012 10:22 AM, Frank Ding wrote:
>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>   After a couple of hours investigating the possibility of 
>>>>>>>>>> fixing JComboBox.setModel(null) and 
>>>>>>>>>> JTextComponent.setComponent(null), I found that
>>>>>>>>>> 1. In JComboBox.setModel, the new model, null in this case, 
>>>>>>>>>> is eventually passed to BasicComboPopup.propertyChange where 
>>>>>>>>>> JList.setModel is called.  JList.setModel rejects the null 
>>>>>>>>>> model because of its api restriction.  Below I listed the 
>>>>>>>>>> offending call stacks in my IDE.  This makes sense as the 
>>>>>>>>>> associated drop down JList needs new model. However, it makes 
>>>>>>>>>> fixing JComboBox.setModel(null) hard or impossible.
>>>>>>>>>> Exception in thread "main" 
>>>>>>>>>> java.lang.IllegalArgumentException: model must be non null
>>>>>>>>>>     at javax.swing.JList.setModel(JList.java:1674)
>>>>>>>>>>     at 
>>>>>>>>>> javax.swing.plaf.basic.BasicComboPopup$Handler.propertyChange(BasicComboPopup.java:939)
>>>>>>>>>>     at 
>>>>>>>>>> java.beans.PropertyChangeSupport.fire(PropertyChangeSupport.java:335) 
>>>>>>>>>>
>>>>>>>>>>     at 
>>>>>>>>>> java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:327)
>>>>>>>>>>     at 
>>>>>>>>>> java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:263)
>>>>>>>>>>     at 
>>>>>>>>>> java.awt.Component.firePropertyChange(Component.java:8413)
>>>>>>>>>>     at javax.swing.JComboBox.setModel(JComboBox.java:322)
>>>>>>>>>>
>>>>>>>>>> 2. JTextComponent.setComponent(null) can be fixed but code 
>>>>>>>>>> change in BasicTextUI is also required.
>>>>>>>>>>
>>>>>>>>>> Since setting null model to JComboBox, JList and 
>>>>>>>>>> JTextComponent is impossible or dangerous, just as you 
>>>>>>>>>> mentioned, we could set a non null new model to these UI 
>>>>>>>>>> components just for the purpose of having the side effect of 
>>>>>>>>>> removing listeners from old model. Are you ok with this 
>>>>>>>>>> approach?
>>>>>>>>>      Yes. Please, try this and run the html swing automated 
>>>>>>>>> tests from the test/javax/swing/text/html diroctory to check 
>>>>>>>>> possible regressions.
>>>>>>>>>
>>>>>>>>>      Thanks,
>>>>>>>>>      Alexandr.
>>>>>>>>>
>>>>>>>>>> By the way, I will investigate your another question "Could 
>>>>>>>>>> you also check that the StyleConstants.ComponentAttribute 
>>>>>>>>>> property value can't be rewritten by the JDK code or by 
>>>>>>>>>> public methods." and reply soon.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Frank
>>>>>>>>>>
>>>>>>>>>> On 11/13/2012 7:49 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>> On 11/13/2012 11:53 AM, Frank Ding wrote:
>>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>>   As for your comment "Could you create an issue that a 
>>>>>>>>>>>> JComboBox.setModel(null) call throws NPE? You could fix it 
>>>>>>>>>>>> before the 7189299 issue. ", I created a bug with internal 
>>>>>>>>>>>> review ID of 2381499 on JComboBox.setModel(null).  But test 
>>>>>>>>>>>> shows that JPasswordField.setDocument(null), 
>>>>>>>>>>>> JTextField.setDocument(null), JList.setModel(null) and 
>>>>>>>>>>>> JTextArea.setDocument(null) all throw NPE. Particularly, 
>>>>>>>>>>>> JList.setModel(null) has null check and throws 
>>>>>>>>>>>> IllegalArgumentException("model" must be non null").  Shall 
>>>>>>>>>>>> I include those components as well?
>>>>>>>>>>>
>>>>>>>>>>>     There is the javadoc for the JList setModel() method: 
>>>>>>>>>>> Throws IllegalArgumentException - if model is null. So it is 
>>>>>>>>>>> undesirable to change the public API.
>>>>>>>>>>>     However, it is possible to set a new empty model for the 
>>>>>>>>>>> JList. The list listeners should be removed from the old 
>>>>>>>>>>> model in this case.
>>>>>>>>>>>
>>>>>>>>>>>     You could have only 2 issues: one for components that 
>>>>>>>>>>> allow to set a null model but throws NPE (like JComboBox) 
>>>>>>>>>>> and another for components that does not allow to set null 
>>>>>>>>>>> model but they do not remove listeners from the old model in 
>>>>>>>>>>> case if a new model is set.
>>>>>>>>>>>
>>>>>>>>>>>   Thanks,
>>>>>>>>>>>   Alexandr.
>>>>>>>>>>>
>>>>>>>>>>>>   Thanks for your guidance in advance.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Frank
>>>>>>>>>>>>
>>>>>>>>>>>> On 11/8/2012 10:55 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>> On 11/7/2012 10:56 AM, Frank Ding wrote:
>>>>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>>>>   Unfortunately, all the JComponents involved in 
>>>>>>>>>>>>>> FormView.createComponent() have bugs!
>>>>>>>>>>>>>>   I have done tests for all other swing components, i.e. 
>>>>>>>>>>>>>> JCheckBox, JRadioButton, JPasswordField, JTextField, 
>>>>>>>>>>>>>> JList, JComboBox and JTextField. Sadder news is that if 
>>>>>>>>>>>>>> we fix all components in the same way as I did for 
>>>>>>>>>>>>>> JButton, we need to subclass them all, resulting in 
>>>>>>>>>>>>>> JCheckBoxWrapper, JRadioButtonWrapper, 
>>>>>>>>>>>>>> JPasswordFieldWrapper, JTextFieldWrapper, JListWrapper, 
>>>>>>>>>>>>>> JComboBoxWrapper, JTextFieldWrapper plus JButtonWrapper!  
>>>>>>>>>>>>>> This approach becomes unacceptable when all swing 
>>>>>>>>>>>>>> components are affected.
>>>>>>>>>>>>>>   Shall we fix it in other way illustrated below?
>>>>>>>>>>>>>> 1. Whenever a swing component is created, it is kept in 
>>>>>>>>>>>>>> AttributeSet, as what is now for model.
>>>>>>>>>>>>>> 2. In FormView.createComponent(), the old swing component 
>>>>>>>>>>>>>> can be retrieved via 
>>>>>>>>>>>>>> attr.getAttribute(StyleConstants.ComponentAttribute). 
>>>>>>>>>>>>>> Note that ComponentAttribute is newly added.
>>>>>>>>>>>>>       This way should be carefully investigated that it 
>>>>>>>>>>>>> does not introduce new memory leaks.
>>>>>>>>>>>>>       Could you also check that the 
>>>>>>>>>>>>> StyleConstants.ComponentAttribute property value can't be 
>>>>>>>>>>>>> rewritten by the JDK code or by public methods.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 3. Before setting shared model to a newly initialized 
>>>>>>>>>>>>>> swing component, call oldComp.setModel(null), delegating 
>>>>>>>>>>>>>> deregistration to setModel method.
>>>>>>>>>>>>>> 4. Seems some setModel such as AbstractButton.setModel() 
>>>>>>>>>>>>>> can function well when the param, new model, is null 
>>>>>>>>>>>>>> while JComboBox.setModel() will throw NPE in case of null 
>>>>>>>>>>>>>> param.
>>>>>>>>>>>>>      Could you create an issue that a 
>>>>>>>>>>>>> JComboBox.setModel(null) call throws NPE? You could fix it 
>>>>>>>>>>>>> before the 7189299 issue.
>>>>>>>>>>>>>
>>>>>>>>>>>>>      Thanks,
>>>>>>>>>>>>>      Alexandr.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 5. Add null check code in those problematic setModel or 
>>>>>>>>>>>>>> setDocument methods.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Any idea is appreciated.  Thanks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>> Frank
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 11/6/2012 9:26 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>> On 11/5/2012 11:20 AM, Frank Ding wrote:
>>>>>>>>>>>>>>>> Hi Alexander,
>>>>>>>>>>>>>>>>   Based on your comments last time, I refined my patch 
>>>>>>>>>>>>>>>> of v6 and offered v7 @
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>      This version of the fix looks good for me.
>>>>>>>>>>>>>>>      It seems that it is the only good way to check that 
>>>>>>>>>>>>>>> a button model contains AbstarctButton.Handler listener.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     Could you also check that others models used in the 
>>>>>>>>>>>>>>> createComponent() method do not have such memory leaks 
>>>>>>>>>>>>>>> (even the NPE is not thrown)?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   4.  Could you add the check that the action listener 
>>>>>>>>>>>>>>>> is invoked only once after a component tree updating 
>>>>>>>>>>>>>>>> and the action does the same that it does before a 
>>>>>>>>>>>>>>>> component tree updating?
>>>>>>>>>>>>>>>>   Answer:  I am afraid I could not make it in the auto 
>>>>>>>>>>>>>>>> test (bug7189299.java) but I can achieve it to some 
>>>>>>>>>>>>>>>> degree in manual test FormSubmit, the one you 
>>>>>>>>>>>>>>>> illustrated below.
>>>>>>>>>>>>>>>>   My idea of checking it in FormSubmit.java is 
>>>>>>>>>>>>>>>> subclassing JEditorPane and overriding 'public 
>>>>>>>>>>>>>>>> EditorKit getEditorKit()' where stack traces can be 
>>>>>>>>>>>>>>>> examined in the overridden method to make sure 
>>>>>>>>>>>>>>>> FormView.submitData occurs only once.  This approach 
>>>>>>>>>>>>>>>> works because FormView.submitData() calls 
>>>>>>>>>>>>>>>> JEditorPane.getEditorKit but is tricky. However, it's 
>>>>>>>>>>>>>>>> the only way I can think of without any additional 
>>>>>>>>>>>>>>>> framework support. If you are in favor of adding the 
>>>>>>>>>>>>>>>> check in FormSubmit.java, I am willing to do that.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       At least a separated manual test can be added that 
>>>>>>>>>>>>>>> asks a user to put a response.html file to a server and 
>>>>>>>>>>>>>>> according to the server url checks that JTeditor pane 
>>>>>>>>>>>>>>> show the response text after a button pressing.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>         html = new JEditorPane("text/html",
>>>>>>>>>>>>>>> "<html><body><form action=\"" + userURL + "\">"
>>>>>>>>>>>>>>>                         + "<input type=submit 
>>>>>>>>>>>>>>> name=submit value=\"submit\"/>"
>>>>>>>>>>>>>>>                         + "</form></body></html>");
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  response.html:
>>>>>>>>>>>>>>> <html> <body> Hello World! </body> </html>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Thanks,
>>>>>>>>>>>>>>>   Alexandr.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Thanks again for all your comments and your support. 
>>>>>>>>>>>>>>>> Once again, if you have any further concern or comment, 
>>>>>>>>>>>>>>>> please don't hesitate to let me know.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>> Frank
>>>>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From konstantin.shefov at oracle.com  Mon Jan 28 13:06:56 2013
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Mon, 28 Jan 2013 17:06:56 +0400
Subject: <Swing Dev> [8] Review request for CR 7077259 [TEST_BUG] [macosx]
 Test work correctly only when default L&F is Metal.
Message-ID: <510677F0.9000204@oracle.com>

Hello,

Please review a fix for the issue:

7077259 [TEST_BUG] [macosx] Test work correctly only when default L&F is 
Metal.

Since all three tests:
    javax/swing/plaf/metal/MetalSliderUI/Test6657026.java
    javax/swing/JSpinner/6532833/bug6532833.java
    javax/swing/JSlider/4252173/bug4252173.java
are specific only for Metal LaF, than using of Metal LaF should be 
forced: UIManager.setLookAndFeel(new MetalLookAndFeel());

The webrev is: http://cr.openjdk.java.net/~kshefov/7077259/webrev.00

Thanks,
Konstantin


From Sergey.Bylokhov at oracle.com  Mon Jan 28 18:39:21 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 28 Jan 2013 22:39:21 +0400
Subject: <Swing Dev> [8] Review request for CR 7077259 [TEST_BUG]
 [macosx] Test work correctly only when default L&F is Metal.
In-Reply-To: <510677F0.9000204@oracle.com>
References: <510677F0.9000204@oracle.com>
Message-ID: <5106C5D9.2070003@oracle.com>

Hi, Konstantin.
Could you add additional options to the test via @run tag. For example, 
how to run test 2 times with different lafs:
/*
  * @test
  * @bug bug6438430
  * @summary ....
  * @run main/othervm 
-Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel bug6438430
  * @run main/othervm 
-Dswing.defaultlaf=com.sun.java.swing.plaf.motif.MotifLookAndFeel 
bug6438430
  */

Also

* Copyright (c) 2007, 2008, 2013, Oracle and/or its affiliates. All rights reserved.
should be changed to
* Copyright (c) 2007, 2013, Oracle and/or its affiliates. All rights reserved.


28.01.2013 17:06, Konstantin Shefov wrote:
> Hello,
>
> Please review a fix for the issue:
>
> 7077259 [TEST_BUG] [macosx] Test work correctly only when default L&F 
> is Metal.
>
> Since all three tests:
>    javax/swing/plaf/metal/MetalSliderUI/Test6657026.java
>    javax/swing/JSpinner/6532833/bug6532833.java
>    javax/swing/JSlider/4252173/bug4252173.java
> are specific only for Metal LaF, than using of Metal LaF should be 
> forced: UIManager.setLookAndFeel(new MetalLookAndFeel());
>
> The webrev is: http://cr.openjdk.java.net/~kshefov/7077259/webrev.00
>
> Thanks,
> Konstantin


-- 
Best regards, Sergey.



From dingxmin at linux.vnet.ibm.com  Tue Jan 29 05:31:17 2013
From: dingxmin at linux.vnet.ibm.com (Frank Ding)
Date: Tue, 29 Jan 2013 13:31:17 +0800
Subject: <Swing Dev> 7189299 DefaultButtonModel instance keeps stale
 listeners of JButton in case of multiple
 SwingUtilities.updateComponentTreeUI() calls
In-Reply-To: <51063F38.4050906@linux.vnet.ibm.com>
References: <501F6E2E.1020608@linux.vnet.ibm.com>
	<50727AFF.3060004@linux.vnet.ibm.com>
	<507440C4.9060504@oracle.com>	<50751427.4040706@linux.vnet.ibm.com>
	<50778B0F.6040407@linux.vnet.ibm.com>	<507BD467.2000405@oracle.com>
	<507E4752.3040302@linux.vnet.ibm.com>	<508E34D7.1060308@linux.vnet.ibm.com>
	<508FD85D.6010600@oracle.com>	<5092184A.2040303@linux.vnet.ibm.com>
	<5092664A.4010504@oracle.com>	<509768B0.6000802@linux.vnet.ibm.com>
	<5099101D.1020507@oracle.com>	<509A0639.1030806@linux.vnet.ibm.com>
	<509BC7EE.7000801@oracle.com>	<50A1FC8F.7060107@linux.vnet.ibm.com>
	<50A233B2.5020602@oracle.com>	<50A338B5.7070302@linux.vnet.ibm.com>
	<50A4B369.3030009@oracle.com>	<50B5AF37.3070307@linux.vnet.ibm.com>
	<50BC8497.5030409@oracle.com>	<50BEE5DE.9020803@linux.vnet.ibm.com>
	<50C059CF.4090806@linux.vnet.ibm.com>	<50C5BC18.8030009@oracle.com>
	<50DD0EF1.9070908@linux.vnet.ibm.com>	<50F8F0CA.1070403@linux.vnet.ibm.com>
	<50FD456C.20601@oracle.com> <51063F38.4050906@linux.vnet.ibm.com>
Message-ID: <51075EA5.4040300@linux.vnet.ibm.com>

Hi Alexandr,
   Please review my 9th attempt @
   http://cr.openjdk.java.net/~dingxmin/7189299/webrev.09/
   The revision also passed test LoadingWebPageToJEditorPane.

Thanks && Best regards,
Frank

On 1/28/2013 5:04 PM, Frank Ding wrote:
> Hi Alexandr,
>   Thanks for your suggestion.  I will prepare a patch according to it 
> soon.
>
> Best regards,
> Frank
>
> On 1/21/2013 9:41 PM, Alexander Scherbatiy wrote:
>> On 1/18/2013 10:50 AM, Frank Ding wrote:
>>> Hi Alexandr,
>>>   Do you have any idea?
>>
>>    What about one more way removing listeners:
>>     - disadvantage: listeners are hardcoded
>>     - advantage: there is no need to override JButton, JList,... classes
>>
>>      ------------------------------------------
>>     private void clearModel(Object model) {
>>         if (model instanceof DefaultButtonModel) {
>>             DefaultButtonModel buttonModel = (DefaultButtonModel) model;
>>             String listenerClass = "javax.swing.AbstractButton$Handler";
>>
>>             for (ActionListener listener : 
>> buttonModel.getActionListeners()) {
>>                 if 
>> (listenerClass.equals(listener.getClass().getName())) {
>>                     buttonModel.removeActionListener(listener);
>>                 }
>>             }
>>             // remove change listeners
>>             // remove item listeners
>>
>>         } else if(model instanceof ListModel){
>>             // remove list listeners
>>         }
>>     }
>>      ------------------------------------------
>>
>>    Thanks,
>>     Alexandr.
>>
>>>
>>> Best regards,
>>> Frank
>>>
>>> On 12/28/2012 11:16 AM, Frank Ding wrote:
>>>> Hi Alexandr,
>>>>   I did some more investigations.
>>>>   1. The model can be accessed as below which is also illustrated 
>>>> in the jtreg test
>>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/test/javax/swing/text/html/7189299/bug7189299.java.html 
>>>>
>>>>
>>>>   HTMLEditorKit htmlEditorKit = (HTMLEditorKit) html.getEditorKit();
>>>>   StyleContext.NamedStyle style = ((StyleContext.NamedStyle) 
>>>> htmlEditorKit.getInputAttributes());
>>>>   DefaultButtonModel model = ((DefaultButtonModel) 
>>>> style.getAttribute(StyleConstants.ModelAttribute));
>>>>
>>>>   Though it needs type conversion, model can be exposed to client 
>>>> code.  This implies client code has the chance to add listeners.
>>>>   Another way of updating listener in model is by first getting 
>>>> JButton or other html Swing components and then call listener 
>>>> related api that affects model.  I dumped vars above but did not 
>>>> find out possibility for application to get Swing component reference.
>>>>
>>>>   2. As of swing.text.html library, I searched 'ModelAttribute' 
>>>> under javax/swing directory with command "grep -R 'ModelAttribute' 
>>>> ." which shows aside from FormView and StyleConstants, the classes 
>>>> referencing it are HTMLDocument, HTMLWriter.  This means only 
>>>> FormView adds listeners to model.
>>>>
>>>>   My first attempt at fixing the problem (only for JButton listener 
>>>> leak) is trying to remove all listeners completely. See 
>>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.01/. Pavel 
>>>> argued that it may cause existing application to malfunction. Then 
>>>> I came up with 
>>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.02/ where only 
>>>> stale listeners are identified and removed using reflection.  But 
>>>> Pavel insisted reflection should be prohibited.  So I tried to work 
>>>> around it by extending JButton in FormView to access the private 
>>>> listener instance such that only stale listener is removed.  The 
>>>> perfect revision is 
>>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/.
>>>>
>>>>   I propose we fix JButton issue as it leads to NPE visible to 
>>>> application.  Bug in other components can be put off if Swing team 
>>>> intend to fix it elegantly or duplicate code like what is in v.07.
>>>>   Any idea or comment, please let me know.
>>>>
>>>>   Thanks and best regards,
>>>>   Frank
>>>>
>>>> On 12/10/2012 6:40 PM, Alexander Scherbatiy wrote:
>>>>> On 12/6/2012 12:39 PM, Frank Ding wrote:
>>>>>> Hi Alexandr,
>>>>>>    I did several attempts but still have hang issues somewhere. 
>>>>>> It seems the new approach of caching gui components created each 
>>>>>> time is not practical because of the threading restriction 
>>>>>> already imposed on HTMLDocument.
>>>>>>    Can we make compromise by turning to previous solution (v7 in 
>>>>>> particular) and generalize it to other gui components (which 
>>>>>> means there would be JCheckBoxWrapper, JRadioButtonWrapper,
>>>>>
>>>>>     The issue is that models contain listeners from all previous 
>>>>> components. Models are used to store data and state of components 
>>>>> when form view is recreated.
>>>>>     FormView adds it's own listeners to components (and as result 
>>>>> to the models). Could you make a little investigation to check 
>>>>> which other listeners can the models hold?
>>>>>     Can a user adds a listener?  Can listeners be added by other 
>>>>> parts of the swing.text.html library?
>>>>>
>>>>>     If old listeners does not play role, it is possible just to 
>>>>> remove them all.
>>>>>
>>>>>     Thanks,
>>>>>     Alexandr.
>>>>>
>>>>>> JPasswordFieldWrapper, JTextFieldWrapper, JListWrapper, 
>>>>>> JComboBoxWrapper, and JButtonWrapper).  Or shall we fix JButton 
>>>>>> only because it causes obvious exception visible to client?  I am 
>>>>>> short of ideas...
>>>>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/
>>>>>>
>>>>>> Best regards,
>>>>>> Frank
>>>>>>
>>>>>> On 12/5/2012 2:12 PM, Frank Ding wrote:
>>>>>>> Hi Alexandr,
>>>>>>>   I observed the same issue in my environment as well. My 
>>>>>>> proposed patch would cause severe regression issues. I am 
>>>>>>> looking into the locking issue.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Frank
>>>>>>>
>>>>>>> On 12/3/2012 6:53 PM, Alexander Scherbatiy wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>  Could you check the following sample with your latest fix? It 
>>>>>>>> just hangs on my side.
>>>>>>>>
>>>>>>>>    - put the sample.html  and the response.html files on a server
>>>>>>>>    - update path to the html files in the 
>>>>>>>> LoadingWebPageToJEditorPane class
>>>>>>>>
>>>>>>>> -------------     sample.html  ------------
>>>>>>>> <form name="input" action="response.html" method="get">
>>>>>>>> Username: <input type="text" name="user">
>>>>>>>> <input type="submit" value="Submit">
>>>>>>>> </form>
>>>>>>>> -------------     response.html  ------------
>>>>>>>> <html>
>>>>>>>> <body>
>>>>>>>> Hello World!
>>>>>>>> </body>
>>>>>>>> </html>
>>>>>>>> -------------     LoadingWebPageToJEditorPane.html ------------
>>>>>>>> import java.net.URL;
>>>>>>>> import javax.swing.JEditorPane;
>>>>>>>> import javax.swing.JFrame;
>>>>>>>> import javax.swing.JScrollPane;
>>>>>>>> import javax.swing.SwingUtilities;
>>>>>>>>
>>>>>>>> public class LoadingWebPageToJEditorPane {
>>>>>>>>
>>>>>>>>     private static final String HTML_PATH = 
>>>>>>>> "http://serever/path/sample.html";
>>>>>>>>
>>>>>>>>     public static void main(String[] a) throws Exception {
>>>>>>>>
>>>>>>>>         SwingUtilities.invokeAndWait(new Runnable() {
>>>>>>>>
>>>>>>>>             @Override
>>>>>>>>             public void run() {
>>>>>>>>                 try {
>>>>>>>>
>>>>>>>>                     JFrame frame = new JFrame();
>>>>>>>> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>>>>>>>
>>>>>>>>                     JEditorPane editorPane = new JEditorPane();
>>>>>>>>                     editorPane.setPage(new URL(HTML_PATH));
>>>>>>>>
>>>>>>>>                     frame.add(new JScrollPane(editorPane));
>>>>>>>>                     frame.setSize(300, 200);
>>>>>>>>                     frame.setVisible(true);
>>>>>>>> SwingUtilities.updateComponentTreeUI(editorPane);
>>>>>>>>                 } catch (Exception ex) {
>>>>>>>>                     throw new RuntimeException(ex);
>>>>>>>>                 }
>>>>>>>>             }
>>>>>>>>         });
>>>>>>>>     }
>>>>>>>> }
>>>>>>>> ---------------------------------------
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alexandr.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/28/2012 10:29 AM, Frank Ding wrote:
>>>>>>>>> Hi Alexandr,
>>>>>>>>>   I created a new patch v8 @ 
>>>>>>>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.08/. It 
>>>>>>>>> uses the newly proposed approach mentioned in my last email. 
>>>>>>>>> Could you please help to review it again?
>>>>>>>>>
>>>>>>>>>   The patch, of course, passed jtreg test bug7189299.java in 
>>>>>>>>> the patch.  What's more, I did additional tests for JComboBox, 
>>>>>>>>> JTextField and JList in my IDE by comparing listener numbers 
>>>>>>>>> observed during debugging with/without my patch. The listener 
>>>>>>>>> numbers were doubled without the fix.  This proves that v8 
>>>>>>>>> patch works for all components. I think I can write those 
>>>>>>>>> additional tests as jtreg tests after the patch passes review.
>>>>>>>>>
>>>>>>>>>    One notable change is that I had to restrict the scope of 
>>>>>>>>> holding a write lock in DefaultStyledDocument because 
>>>>>>>>> otherwise, we cannot store the new component created in 
>>>>>>>>> FormView.createComponent().  The stack trace is pasted below 
>>>>>>>>> for reference.
>>>>>>>>>
>>>>>>>>> Exception in thread "main" 
>>>>>>>>> java.lang.reflect.InvocationTargetException
>>>>>>>>>     at java.awt.EventQueue.invokeAndWait(EventQueue.java:1270)
>>>>>>>>>     at 
>>>>>>>>> javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1350) 
>>>>>>>>>
>>>>>>>>>     at bug7189299.main(bug7189299.java:116)
>>>>>>>>> Caused by: java.lang.IllegalStateException: Attempt to mutate 
>>>>>>>>> in notification
>>>>>>>>>     at 
>>>>>>>>> javax.swing.text.AbstractDocument.writeLock(AbstractDocument.java:1357) 
>>>>>>>>>
>>>>>>>>>     at 
>>>>>>>>> javax.swing.text.html.HTMLDocument.obtainLock(HTMLDocument.java:1708) 
>>>>>>>>>
>>>>>>>>>     at 
>>>>>>>>> javax.swing.text.html.FormView.createComponent(FormView.java:211)
>>>>>>>>> ......(omitted)......
>>>>>>>>>     at 
>>>>>>>>> javax.swing.plaf.basic.BasicTextUI$RootView.insertUpdate(BasicTextUI.java:1602)
>>>>>>>>>     at 
>>>>>>>>> javax.swing.plaf.basic.BasicTextUI$UpdateHandler.insertUpdate(BasicTextUI.java:1861)
>>>>>>>>>     at 
>>>>>>>>> javax.swing.text.AbstractDocument.fireInsertUpdate(AbstractDocument.java:201) 
>>>>>>>>>
>>>>>>>>>     at 
>>>>>>>>> javax.swing.text.DefaultStyledDocument.create(DefaultStyledDocument.java:155) 
>>>>>>>>> <------   FormView.createComponent is triggered by this call 
>>>>>>>>> which has already held the lock
>>>>>>>>>     at 
>>>>>>>>> javax.swing.text.html.HTMLDocument.create(HTMLDocument.java:469)
>>>>>>>>> ......(omitted)......
>>>>>>>>>
>>>>>>>>> This change did violate what is documented in 
>>>>>>>>> AbstractDocument.writeLock that "This situation violates the 
>>>>>>>>> bean event model where order of delivery is not guaranteed and 
>>>>>>>>> all listeners should be notified before further mutations are 
>>>>>>>>> allowed. " However, without the change of shrinking lock 
>>>>>>>>> scope, the component cannot be saved once it is created in 
>>>>>>>>> FormView.createComponent(). I found it is even harder to save 
>>>>>>>>> it later in code but perhaps there does exist a more 
>>>>>>>>> appropriate place to do this. If you have any better 
>>>>>>>>> suggestion, I am glad to know.
>>>>>>>>>
>>>>>>>>>   Also I searched references to 
>>>>>>>>> 'StyleConstants.ComponentAttribute' as you asked. The result 
>>>>>>>>> is listed below.  Note that the command 'grep' is invoked 
>>>>>>>>> under openjdk 8 top directory.
>>>>>>>>> $ grep -R 'ComponentAttribute' .
>>>>>>>>> ./jdk/src/share/classes/javax/swing/text/StyleConstants.java: 
>>>>>>>>> public static final Object ComponentAttribute = new 
>>>>>>>>> CharacterConstants("component");
>>>>>>>>> ./jdk/src/share/classes/javax/swing/text/StyleConstants.java: 
>>>>>>>>> return (Component) a.getAttribute(ComponentAttribute);
>>>>>>>>> ./jdk/src/share/classes/javax/swing/text/StyleConstants.java: 
>>>>>>>>> a.addAttribute(ComponentAttribute, c);
>>>>>>>>> ./jdk/src/share/classes/javax/swing/text/StyleConstants.java: 
>>>>>>>>> Background, ComponentAttribute, IconAttribute,
>>>>>>>>> ./jdk/src/share/classes/javax/swing/text/StyledEditorKit.java: 
>>>>>>>>> set.removeAttribute(StyleConstants.ComponentAttribute);
>>>>>>>>> Binary file ./jdk/test/sun/tools/jhat/jmap.bin matches
>>>>>>>>>
>>>>>>>>> So ComponentAttribute is not referenced by other classes 
>>>>>>>>> except StyledEditorKit.  StyleConstants exposes 
>>>>>>>>> ComponentAttribute in getComponent() and setComponent() 
>>>>>>>>> methods.  References to StyleConstants.getComponent and 
>>>>>>>>> StyleConstants.setComponent are further searched in repo.
>>>>>>>>>
>>>>>>>>> $ grep -R 'StyleConstants.getComponent' .
>>>>>>>>> ./jdk/src/share/classes/javax/swing/text/ComponentView.java: * 
>>>>>>>>> the element (by calling StyleConstants.getComponent). A
>>>>>>>>> ./jdk/src/share/classes/javax/swing/text/ComponentView.java: 
>>>>>>>>> Component comp = StyleConstants.getComponent(attr);
>>>>>>>>>
>>>>>>>>> $ grep -R 'StyleConstants.setComponent' .
>>>>>>>>> ./jdk/src/share/classes/javax/swing/JTextPane.java: 
>>>>>>>>> StyleConstants.setComponent(inputAttributes, c);
>>>>>>>>>
>>>>>>>>> From the facts above, I think we are sufficiently confident to 
>>>>>>>>> use ComponentAttribute.
>>>>>>>>>
>>>>>>>>> Please let me know if you have any comments and I can do more 
>>>>>>>>> regression tests and provide more jtreg test cases as next step.
>>>>>>>>>
>>>>>>>>> Thanks and regards,
>>>>>>>>> Frank
>>>>>>>>>
>>>>>>>>> On 11/15/2012 5:18 PM, Alexander Scherbatiy wrote:
>>>>>>>>>> On 11/14/2012 10:22 AM, Frank Ding wrote:
>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>   After a couple of hours investigating the possibility of 
>>>>>>>>>>> fixing JComboBox.setModel(null) and 
>>>>>>>>>>> JTextComponent.setComponent(null), I found that
>>>>>>>>>>> 1. In JComboBox.setModel, the new model, null in this case, 
>>>>>>>>>>> is eventually passed to BasicComboPopup.propertyChange where 
>>>>>>>>>>> JList.setModel is called.  JList.setModel rejects the null 
>>>>>>>>>>> model because of its api restriction.  Below I listed the 
>>>>>>>>>>> offending call stacks in my IDE.  This makes sense as the 
>>>>>>>>>>> associated drop down JList needs new model. However, it 
>>>>>>>>>>> makes fixing JComboBox.setModel(null) hard or impossible.
>>>>>>>>>>> Exception in thread "main" 
>>>>>>>>>>> java.lang.IllegalArgumentException: model must be non null
>>>>>>>>>>>     at javax.swing.JList.setModel(JList.java:1674)
>>>>>>>>>>>     at 
>>>>>>>>>>> javax.swing.plaf.basic.BasicComboPopup$Handler.propertyChange(BasicComboPopup.java:939)
>>>>>>>>>>>     at 
>>>>>>>>>>> java.beans.PropertyChangeSupport.fire(PropertyChangeSupport.java:335) 
>>>>>>>>>>>
>>>>>>>>>>>     at 
>>>>>>>>>>> java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:327)
>>>>>>>>>>>     at 
>>>>>>>>>>> java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:263)
>>>>>>>>>>>     at 
>>>>>>>>>>> java.awt.Component.firePropertyChange(Component.java:8413)
>>>>>>>>>>>     at javax.swing.JComboBox.setModel(JComboBox.java:322)
>>>>>>>>>>>
>>>>>>>>>>> 2. JTextComponent.setComponent(null) can be fixed but code 
>>>>>>>>>>> change in BasicTextUI is also required.
>>>>>>>>>>>
>>>>>>>>>>> Since setting null model to JComboBox, JList and 
>>>>>>>>>>> JTextComponent is impossible or dangerous, just as you 
>>>>>>>>>>> mentioned, we could set a non null new model to these UI 
>>>>>>>>>>> components just for the purpose of having the side effect of 
>>>>>>>>>>> removing listeners from old model. Are you ok with this 
>>>>>>>>>>> approach?
>>>>>>>>>>      Yes. Please, try this and run the html swing automated 
>>>>>>>>>> tests from the test/javax/swing/text/html diroctory to check 
>>>>>>>>>> possible regressions.
>>>>>>>>>>
>>>>>>>>>>      Thanks,
>>>>>>>>>>      Alexandr.
>>>>>>>>>>
>>>>>>>>>>> By the way, I will investigate your another question "Could 
>>>>>>>>>>> you also check that the StyleConstants.ComponentAttribute 
>>>>>>>>>>> property value can't be rewritten by the JDK code or by 
>>>>>>>>>>> public methods." and reply soon.
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Frank
>>>>>>>>>>>
>>>>>>>>>>> On 11/13/2012 7:49 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>> On 11/13/2012 11:53 AM, Frank Ding wrote:
>>>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>>>   As for your comment "Could you create an issue that a 
>>>>>>>>>>>>> JComboBox.setModel(null) call throws NPE? You could fix it 
>>>>>>>>>>>>> before the 7189299 issue. ", I created a bug with internal 
>>>>>>>>>>>>> review ID of 2381499 on JComboBox.setModel(null).  But 
>>>>>>>>>>>>> test shows that JPasswordField.setDocument(null), 
>>>>>>>>>>>>> JTextField.setDocument(null), JList.setModel(null) and 
>>>>>>>>>>>>> JTextArea.setDocument(null) all throw NPE. Particularly, 
>>>>>>>>>>>>> JList.setModel(null) has null check and throws 
>>>>>>>>>>>>> IllegalArgumentException("model" must be non null").  
>>>>>>>>>>>>> Shall I include those components as well?
>>>>>>>>>>>>
>>>>>>>>>>>>     There is the javadoc for the JList setModel() method: 
>>>>>>>>>>>> Throws IllegalArgumentException - if model is null. So it 
>>>>>>>>>>>> is undesirable to change the public API.
>>>>>>>>>>>>     However, it is possible to set a new empty model for 
>>>>>>>>>>>> the JList. The list listeners should be removed from the 
>>>>>>>>>>>> old model in this case.
>>>>>>>>>>>>
>>>>>>>>>>>>     You could have only 2 issues: one for components that 
>>>>>>>>>>>> allow to set a null model but throws NPE (like JComboBox) 
>>>>>>>>>>>> and another for components that does not allow to set null 
>>>>>>>>>>>> model but they do not remove listeners from the old model 
>>>>>>>>>>>> in case if a new model is set.
>>>>>>>>>>>>
>>>>>>>>>>>>   Thanks,
>>>>>>>>>>>>   Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>>>   Thanks for your guidance in advance.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>> Frank
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/8/2012 10:55 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>> On 11/7/2012 10:56 AM, Frank Ding wrote:
>>>>>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>>>>>   Unfortunately, all the JComponents involved in 
>>>>>>>>>>>>>>> FormView.createComponent() have bugs!
>>>>>>>>>>>>>>>   I have done tests for all other swing components, i.e. 
>>>>>>>>>>>>>>> JCheckBox, JRadioButton, JPasswordField, JTextField, 
>>>>>>>>>>>>>>> JList, JComboBox and JTextField. Sadder news is that if 
>>>>>>>>>>>>>>> we fix all components in the same way as I did for 
>>>>>>>>>>>>>>> JButton, we need to subclass them all, resulting in 
>>>>>>>>>>>>>>> JCheckBoxWrapper, JRadioButtonWrapper, 
>>>>>>>>>>>>>>> JPasswordFieldWrapper, JTextFieldWrapper, JListWrapper, 
>>>>>>>>>>>>>>> JComboBoxWrapper, JTextFieldWrapper plus 
>>>>>>>>>>>>>>> JButtonWrapper!  This approach becomes unacceptable when 
>>>>>>>>>>>>>>> all swing components are affected.
>>>>>>>>>>>>>>>   Shall we fix it in other way illustrated below?
>>>>>>>>>>>>>>> 1. Whenever a swing component is created, it is kept in 
>>>>>>>>>>>>>>> AttributeSet, as what is now for model.
>>>>>>>>>>>>>>> 2. In FormView.createComponent(), the old swing 
>>>>>>>>>>>>>>> component can be retrieved via 
>>>>>>>>>>>>>>> attr.getAttribute(StyleConstants.ComponentAttribute). 
>>>>>>>>>>>>>>> Note that ComponentAttribute is newly added.
>>>>>>>>>>>>>>       This way should be carefully investigated that it 
>>>>>>>>>>>>>> does not introduce new memory leaks.
>>>>>>>>>>>>>>       Could you also check that the 
>>>>>>>>>>>>>> StyleConstants.ComponentAttribute property value can't be 
>>>>>>>>>>>>>> rewritten by the JDK code or by public methods.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 3. Before setting shared model to a newly initialized 
>>>>>>>>>>>>>>> swing component, call oldComp.setModel(null), delegating 
>>>>>>>>>>>>>>> deregistration to setModel method.
>>>>>>>>>>>>>>> 4. Seems some setModel such as AbstractButton.setModel() 
>>>>>>>>>>>>>>> can function well when the param, new model, is null 
>>>>>>>>>>>>>>> while JComboBox.setModel() will throw NPE in case of 
>>>>>>>>>>>>>>> null param.
>>>>>>>>>>>>>>      Could you create an issue that a 
>>>>>>>>>>>>>> JComboBox.setModel(null) call throws NPE? You could fix 
>>>>>>>>>>>>>> it before the 7189299 issue.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>      Thanks,
>>>>>>>>>>>>>>      Alexandr.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 5. Add null check code in those problematic setModel or 
>>>>>>>>>>>>>>> setDocument methods.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any idea is appreciated.  Thanks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>> Frank
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 11/6/2012 9:26 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>> On 11/5/2012 11:20 AM, Frank Ding wrote:
>>>>>>>>>>>>>>>>> Hi Alexander,
>>>>>>>>>>>>>>>>>   Based on your comments last time, I refined my patch 
>>>>>>>>>>>>>>>>> of v6 and offered v7 @
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.07/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>      This version of the fix looks good for me.
>>>>>>>>>>>>>>>>      It seems that it is the only good way to check 
>>>>>>>>>>>>>>>> that a button model contains AbstarctButton.Handler 
>>>>>>>>>>>>>>>> listener.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     Could you also check that others models used in the 
>>>>>>>>>>>>>>>> createComponent() method do not have such memory leaks 
>>>>>>>>>>>>>>>> (even the NPE is not thrown)?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>   4.  Could you add the check that the action listener 
>>>>>>>>>>>>>>>>> is invoked only once after a component tree updating 
>>>>>>>>>>>>>>>>> and the action does the same that it does before a 
>>>>>>>>>>>>>>>>> component tree updating?
>>>>>>>>>>>>>>>>>   Answer:  I am afraid I could not make it in the auto 
>>>>>>>>>>>>>>>>> test (bug7189299.java) but I can achieve it to some 
>>>>>>>>>>>>>>>>> degree in manual test FormSubmit, the one you 
>>>>>>>>>>>>>>>>> illustrated below.
>>>>>>>>>>>>>>>>>   My idea of checking it in FormSubmit.java is 
>>>>>>>>>>>>>>>>> subclassing JEditorPane and overriding 'public 
>>>>>>>>>>>>>>>>> EditorKit getEditorKit()' where stack traces can be 
>>>>>>>>>>>>>>>>> examined in the overridden method to make sure 
>>>>>>>>>>>>>>>>> FormView.submitData occurs only once.  This approach 
>>>>>>>>>>>>>>>>> works because FormView.submitData() calls 
>>>>>>>>>>>>>>>>> JEditorPane.getEditorKit but is tricky. However, it's 
>>>>>>>>>>>>>>>>> the only way I can think of without any additional 
>>>>>>>>>>>>>>>>> framework support. If you are in favor of adding the 
>>>>>>>>>>>>>>>>> check in FormSubmit.java, I am willing to do that.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>       At least a separated manual test can be added 
>>>>>>>>>>>>>>>> that asks a user to put a response.html file to a 
>>>>>>>>>>>>>>>> server and according to the server url checks that 
>>>>>>>>>>>>>>>> JTeditor pane show the response text after a button 
>>>>>>>>>>>>>>>> pressing.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>         html = new JEditorPane("text/html",
>>>>>>>>>>>>>>>> "<html><body><form action=\"" + userURL + "\">"
>>>>>>>>>>>>>>>>                         + "<input type=submit 
>>>>>>>>>>>>>>>> name=submit value=\"submit\"/>"
>>>>>>>>>>>>>>>>                         + "</form></body></html>");
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  response.html:
>>>>>>>>>>>>>>>> <html> <body> Hello World! </body> </html>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Thanks,
>>>>>>>>>>>>>>>>   Alexandr.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>   Thanks again for all your comments and your support. 
>>>>>>>>>>>>>>>>> Once again, if you have any further concern or 
>>>>>>>>>>>>>>>>> comment, please don't hesitate to let me know.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>> Frank
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From konstantin.shefov at oracle.com  Tue Jan 29 13:36:29 2013
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Tue, 29 Jan 2013 17:36:29 +0400
Subject: <Swing Dev> [8] Review request for CR 7077259 [TEST_BUG]
 [macosx] Test work correctly only when default L&F is Metal.
In-Reply-To: <5106C5D9.2070003@oracle.com>
References: <510677F0.9000204@oracle.com> <5106C5D9.2070003@oracle.com>
Message-ID: <5107D05D.9070908@oracle.com>

Thanks, it works.

Here is new webrev: http://cr.openjdk.java.net/~kshefov/7077259/webrev.01

On 28-Jan-13 22:39, Sergey Bylokhov wrote:
> Hi, Konstantin.
> Could you add additional options to the test via @run tag. For 
> example, how to run test 2 times with different lafs:
> /*
>  * @test
>  * @bug bug6438430
>  * @summary ....
>  * @run main/othervm 
> -Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel bug6438430
>  * @run main/othervm 
> -Dswing.defaultlaf=com.sun.java.swing.plaf.motif.MotifLookAndFeel 
> bug6438430
>  */
>
> Also
>
> * Copyright (c) 2007, 2008, 2013, Oracle and/or its affiliates. All 
> rights reserved.
> should be changed to
> * Copyright (c) 2007, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>
>
> 28.01.2013 17:06, Konstantin Shefov wrote:
>> Hello,
>>
>> Please review a fix for the issue:
>>
>> 7077259 [TEST_BUG] [macosx] Test work correctly only when default L&F 
>> is Metal.
>>
>> Since all three tests:
>>    javax/swing/plaf/metal/MetalSliderUI/Test6657026.java
>>    javax/swing/JSpinner/6532833/bug6532833.java
>>    javax/swing/JSlider/4252173/bug4252173.java
>> are specific only for Metal LaF, than using of Metal LaF should be 
>> forced: UIManager.setLookAndFeel(new MetalLookAndFeel());
>>
>> The webrev is: http://cr.openjdk.java.net/~kshefov/7077259/webrev.00
>>
>> Thanks,
>> Konstantin
>
>


From Sergey.Bylokhov at oracle.com  Tue Jan 29 13:59:37 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 29 Jan 2013 17:59:37 +0400
Subject: <Swing Dev> [8] Review request for CR 7077259 [TEST_BUG]
 [macosx] Test work correctly only when default L&F is Metal.
In-Reply-To: <5107D05D.9070908@oracle.com>
References: <510677F0.9000204@oracle.com> <5106C5D9.2070003@oracle.com>
	<5107D05D.9070908@oracle.com>
Message-ID: <5107D5C9.6070209@oracle.com>

Hi, Konstantin.
Fix looks good.

29.01.2013 17:36, Konstantin Shefov ?????:
> Thanks, it works.
>
> Here is new webrev: http://cr.openjdk.java.net/~kshefov/7077259/webrev.01
>
> On 28-Jan-13 22:39, Sergey Bylokhov wrote:
>> Hi, Konstantin.
>> Could you add additional options to the test via @run tag. For 
>> example, how to run test 2 times with different lafs:
>> /*
>>  * @test
>>  * @bug bug6438430
>>  * @summary ....
>>  * @run main/othervm 
>> -Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel bug6438430
>>  * @run main/othervm 
>> -Dswing.defaultlaf=com.sun.java.swing.plaf.motif.MotifLookAndFeel 
>> bug6438430
>>  */
>>
>> Also
>>
>> * Copyright (c) 2007, 2008, 2013, Oracle and/or its affiliates. All 
>> rights reserved.
>> should be changed to
>> * Copyright (c) 2007, 2013, Oracle and/or its affiliates. All rights 
>> reserved.
>>
>>
>> 28.01.2013 17:06, Konstantin Shefov wrote:
>>> Hello,
>>>
>>> Please review a fix for the issue:
>>>
>>> 7077259 [TEST_BUG] [macosx] Test work correctly only when default 
>>> L&F is Metal.
>>>
>>> Since all three tests:
>>>    javax/swing/plaf/metal/MetalSliderUI/Test6657026.java
>>>    javax/swing/JSpinner/6532833/bug6532833.java
>>>    javax/swing/JSlider/4252173/bug4252173.java
>>> are specific only for Metal LaF, than using of Metal LaF should be 
>>> forced: UIManager.setLookAndFeel(new MetalLookAndFeel());
>>>
>>> The webrev is: http://cr.openjdk.java.net/~kshefov/7077259/webrev.00
>>>
>>> Thanks,
>>> Konstantin
>>
>>


-- 
Best regards, Sergey.



From Vladislav.Karnaukhov at oracle.com  Tue Jan 29 14:17:28 2013
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Tue, 29 Jan 2013 18:17:28 +0400
Subject: <Swing Dev> [8] Review request for 4199622 RFE: JComboBox
 shouldn't sending ActionEvents for keyboard navigation
In-Reply-To: <51013DC8.70609@oracle.com>
References: <50F6A3EF.3000705@oracle.com>
	<50F7FDA4.9040600@oracle.com>	<50FD3F53.901@oracle.com>
	<5100F194.2000102@oracle.com> <51013DC8.70609@oracle.com>
Message-ID: <5107D9F8.5040308@oracle.com>

Hello Alexander, all,

please review a new version: 
http://cr.openjdk.java.net/~vkarnauk/4199622/webrev.04/

On 1/24/2013 05:57 PM, Alexander Scherbatiy wrote:
>
> - MetalLookAndFeel and ComboBox.noActionOnKeyNavigation property is set
>      Press down, select an item, press enter. The drop down list is not
> closed
Fixed.

> - WindowsLookAndFeel and ComboBox.noActionOnKeyNavigation property is set
>     Home/End and PgUp/PgDn keys do not work
>
Fixed.

The reg test was completely re-written. 2 additional runs were added: 
one with Windows LAF if under Microsoft OS; another when editable flag 
is set. I've checked on Mac OS X to ensure cross-platform compatibility.

Regards,
- Vlad


From alexandr.scherbatiy at oracle.com  Tue Jan 29 15:26:37 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 29 Jan 2013 19:26:37 +0400
Subject: <Swing Dev> [8] Review request for 4199622 RFE: JComboBox
 shouldn't sending ActionEvents for keyboard navigation
In-Reply-To: <5107D9F8.5040308@oracle.com>
References: <50F6A3EF.3000705@oracle.com>
	<50F7FDA4.9040600@oracle.com>	<50FD3F53.901@oracle.com>
	<5100F194.2000102@oracle.com> <51013DC8.70609@oracle.com>
	<5107D9F8.5040308@oracle.com>
Message-ID: <5107EA2D.9000000@oracle.com>


- WindowsLookAndFeel and ComboBox.noActionOnKeyNavigation property is set
    Press down. Next item is selected and the action listener is 
invoked. Is it expected behavior (the drop down list is not shown in 
this case)?

- It seems that the code below can have a shorter form:
                 if 
(UIManager.getBoolean("ComboBox.noActionOnKeyNavigation")) {
                     if (!comboBox.isPopupVisible()) {
                         comboBox.setSelectedIndex(si+1);
                     }
                 } else {
                     comboBox.setSelectedIndex(si+1);
                }
   ->
     if ( !(UIManager.getBoolean("ComboBox.noActionOnKeyNavigation") && 
comboBox.isPopupVisible()) ) {
           comboBox.setSelectedIndex(si+1);
      }

- doTest() method in the test throws some exception. It can throw robot 
and toolkit exceptions as well.

Thanks,
  Alexandr.


On 1/29/2013 6:17 PM, Vladislav Karnaukhov wrote:
> Hello Alexander, all,
>
> please review a new version: 
> http://cr.openjdk.java.net/~vkarnauk/4199622/webrev.04/
>
> On 1/24/2013 05:57 PM, Alexander Scherbatiy wrote:
>>
>> - MetalLookAndFeel and ComboBox.noActionOnKeyNavigation property is set
>>      Press down, select an item, press enter. The drop down list is not
>> closed
> Fixed.
>
>> - WindowsLookAndFeel and ComboBox.noActionOnKeyNavigation property is 
>> set
>>     Home/End and PgUp/PgDn keys do not work
>>
> Fixed.
>
> The reg test was completely re-written. 2 additional runs were added: 
> one with Windows LAF if under Microsoft OS; another when editable flag 
> is set. I've checked on Mac OS X to ensure cross-platform compatibility.
>
> Regards,
> - Vlad



From Vladislav.Karnaukhov at oracle.com  Wed Jan 30 10:36:33 2013
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Wed, 30 Jan 2013 14:36:33 +0400
Subject: <Swing Dev> [8] Review request for 4199622 RFE: JComboBox
 shouldn't sending ActionEvents for keyboard navigation
In-Reply-To: <5107EA2D.9000000@oracle.com>
References: <50F6A3EF.3000705@oracle.com>
	<50F7FDA4.9040600@oracle.com>	<50FD3F53.901@oracle.com>
	<5100F194.2000102@oracle.com> <51013DC8.70609@oracle.com>
	<5107D9F8.5040308@oracle.com> <5107EA2D.9000000@oracle.com>
Message-ID: <5108F7B1.8020001@oracle.com>

Hello Alexandr, all,

please find a new version here: 
http://cr.openjdk.java.net/~vkarnauk/4199622/webrev.05/

On 1/29/2013 07:26 PM, Alexander Scherbatiy wrote:
>
> - WindowsLookAndFeel and ComboBox.noActionOnKeyNavigation property is set
>     Press down. Next item is selected and the action listener is
> invoked. Is it expected behavior (the drop down list is not shown in
> this case)?
Yes, it's expected. Customer would like to turn off event firing only 
when popup is open. To keep consistency over different LAFs, I only 
handle the new flag when drop-down is showing. Under Windows, if drop 
list wasn't shown, JComboBox will work as usual even if the flag was set.

>
> - It seems that the code below can have a shorter form:
>                  if
> (UIManager.getBoolean("ComboBox.noActionOnKeyNavigation")) {
>                      if (!comboBox.isPopupVisible()) {
>                          comboBox.setSelectedIndex(si+1);
>                      }
>                  } else {
>                      comboBox.setSelectedIndex(si+1);
>                 }
>    ->
>      if ( !(UIManager.getBoolean("ComboBox.noActionOnKeyNavigation") &&
> comboBox.isPopupVisible()) ) {
>            comboBox.setSelectedIndex(si+1);
>       }
Agree; fixed.

>
> - doTest() method in the test throws some exception. It can throw robot
> and toolkit exceptions as well.
Agree; fixed.

>
> Thanks,
>   Alexandr.
>