From prasanta.sadhukhan at oracle.com  Thu Jun  1 05:07:48 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 1 Jun 2017 10:37:48 +0530
Subject: <Swing Dev> [10] RFR 6962725:Regtest
 javax/swing/JFileChooser/6738668/bug6738668.java fails under Linux
In-Reply-To: <9d784fcb-21f1-4249-af2a-295836b63451@default>
References: <9d784fcb-21f1-4249-af2a-295836b63451@default>
Message-ID: <6ec490ec-2429-9c71-b055-19386e7add49@oracle.com>

I could not run jdk7u40 build with my jtreg harness as it cites the 
below problem. I do not have jtreg older than 4.2b03, nor I could find 
in jtreg site.

PRSADHUK-IN+prsadhuk at PRSADHUK-IN /cygdrive/c/jdk9/jtreg-42b03
$ ./bin/jtreg -jdk:/cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/ 
/cygdrive/d/jdk7u/jdk7u-dev/jdk/test/javax/swing/JFileChooser/6738668/bug6738668.java
java.lang.UnsupportedClassVersionError: 
com/sun/javatest/regtest/JDK$Fault : Unsupported major.minor version 52.0
         at java.lang.ClassLoader.defineClass1(Native Method)
         at java.lang.ClassLoader.defineClass(ClassLoader.java:642)

Regards
Prasanta
On 5/30/2017 10:28 PM, Sergey Bylokhov wrote:
> The new version fails even if run via jtreg?
>
> ----- prasanta.sadhukhan at oracle.com wrote:
>
>> OK. With revised command line, it fails with new updated test in 7b40
>>
>> and passed in 9b170
>>
>> /cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/bin/java
>> -Djava.security.manager -Djava.security.policy=security.policy
>> bug6738668
>> tmp dir C:\cygwin64\tmp\
>> Exception in thread "main" java.security.AccessControlException:
>> access
>> denied (java.io.FilePermission
>> C:\Users\prsadhuk\AppData\Roaming\Microsoft\Windows\Recent read)
>>           at
>> java.security.AccessControlContext.checkPermission(AccessControlContext.java:345)
>>           at
>> java.security.AccessController.checkPermission(AccessController.java:555)
>>           at
>> java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
>>           at
>> java.lang.SecurityManager.checkRead(SecurityManager.java:888)
>>
>> /cygdrive/d/Vbox_Shared/JDK/jdk9-b170/fastdebug/bin/java
>> -Djava.security.manager -Djava.security.policy=security.policy
>> bug6738668
>> tmp dir C:\cygwin64\tmp\
>> Test passed for LookAndFeel javax.swing.plaf.metal.MetalLookAndFeel
>> tmp dir C:\cygwin64\tmp\
>> Test passed for LookAndFeel javax.swing.plaf.nimbus.NimbusLookAndFeel
>> tmp dir C:\cygwin64\tmp\
>> Test passed for LookAndFeel
>> com.sun.java.swing.plaf.motif.MotifLookAndFeel
>> tmp dir C:\cygwin64\tmp\
>> Test passed for LookAndFeel
>> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>> tmp dir C:\cygwin64\tmp\
>> Test passed for LookAndFeel
>> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
>>
>> Regards
>> Prasanta
>> On 5/30/2017 2:59 AM, Sergey Bylokhov wrote:
>>> I guess you will need to set security manager which will use your
>> policy file:
>> https://docs.oracle.com/cd/E13222_01/wls/docs81b/secmanage/java.html
>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>
>>>> I am not sure why it is passing in my case. I thought it might be
>>>> taking
>>>> in some other security policy so I renamed and use a different
>> named
>>>> policy but it still passed in my windows 7.
>>>>
>>>> $ /cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/bin/java
>>>> -Djava.security.policy=my.policy bug6738668
>>>> Test passed for LookAndFeel
>> javax.swing.plaf.metal.MetalLookAndFeel
>>>> Test passed for LookAndFeel
>>>> com.sun.java.swing.plaf.motif.MotifLookAndFeel
>>>> Test passed for LookAndFeel
>>>> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>>>> Test passed for LookAndFeel
>>>> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
>>>>
>>>> PRSADHUK-IN+prsadhuk at PRSADHUK-IN
>>>> /cygdrive/d/jdk10/client/jdk/test/javax/swing/JFileChooser/6738668
>>>> $ cat my.policy
>>>> grant {
>>>>        permission java.io.FilePermission "C:\\temp\\*", "read";
>>>>        permission java.io.FilePermission "C:\\temp", "read";
>>>>        permission java.util.PropertyPermission "*", "read";
>>>> };
>>>>
>>>> PRSADHUK-IN+prsadhuk at PRSADHUK-IN
>>>> /cygdrive/d/jdk10/client/jdk/test/javax/swing/JFileChooser/6738668
>>>> $ /cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/bin/java
>>>> -version
>>>> java version "1.7.0-ea-fastdebug"
>>>> Java(TM) SE Runtime Environment (build 1.7.0-ea-fastdebug-b40)
>>>> Java HotSpot(TM) 64-Bit Server VM (build 14.0-b07-fastdebug, mixed
>>>> mode)
>>>>
>>>> BTW, does my updated test fail in your environment with b40?
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 5/28/2017 4:10 AM, Sergey Bylokhov wrote:
>>>>> There is a comment that JDK-6738668 a regression of JDK-6484091
>>>> which was pushed to b20.
>>>>> I just checked the test from the command line on b40 and it
>> fails,
>>>> but passed on b55.
>>>>> Can you please check why it was passed in your case.
>>>>>
>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>
>>>>>> Hi Sergey,
>>>>>>
>>>>>> I do not see any comment mention about failure in 7b20 but
>> anyways,
>>>> I
>>>>>> tried with 7b20,7b30,7b40,7b50 and all of them passed with
>>>> original
>>>>>> and
>>>>>> updated test in windows.
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 5/25/2017 2:30 AM, Sergey Bylokhov wrote:
>>>>>>> I am not sure but according to the comments of JDK-6738668 it
>> was
>>>> a
>>>>>> regression in 7b20.
>>>>>>> So I suggest to check a few build between b20 and b54
>>>>>>>
>>>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>>>
>>>>>>>> Hi Sergey,
>>>>>>>>
>>>>>>>> No, it is passing. Actually, the original test is also passing
>>>>>> with
>>>>>>>> 1.7.0 b05 (6738668 is supposedly fixed in 7b55), there's no
>>>>>>>> SecurityException
>>>>>>>>
>>>>>>>> jdk1.7.0/bin/java -Djava.security.policy=security.policy
>>>>>> bug6738668
>>>>>>>> Test passed for LookAndFeel
>>>>>> javax.swing.plaf.metal.MetalLookAndFeel
>>>>>>>> Test passed for LookAndFeel
>>>>>>>> com.sun.java.swing.plaf.motif.MotifLookAndFeel
>>>>>>>> Test passed for LookAndFeel
>>>>>>>> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>>>>>>>> Test passed for LookAndFeel
>>>>>>>> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
>>>>>>>>
>>>>>>>> jdk1.7.0/bin/java -version
>>>>>>>> java version "1.7.0-ea"
>>>>>>>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b05)
>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.7.0-ea-b05, mixed
>>>> mode)
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>> On 5/24/2017 11:48 AM, Sergey Bylokhov wrote:
>>>>>>>>> Hi, Prasanta.
>>>>>>>>> Please confirm that the updated test fails before JDK-6738668
>>>> was
>>>>>>>> fixed.
>>>>>>>>>> Hi ALl,
>>>>>>>>>>
>>>>>>>>>> Please review a testbug fix for an issue where this
>> regression
>>>>>> test
>>>>>>>> is failing in linux because
>>>>>>>>>> JFileChooser was trying to access C:/temp path which does
>> not
>>>>>> exist
>>>>>>>> in linux.
>>>>>>>>>> Proposed fix is to use java.io.tmpdir instead of hardcoded
>>>>>> windows
>>>>>>>> path.
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6962725
>>>>>>>>>> webrev:
>>>>>> http://cr.openjdk.java.net/~psadhukhan/6962725/webrev.00/
>>>>>>>>>> Regards
>>>>>>>>>> Prasanta



From prasanta.sadhukhan at oracle.com  Thu Jun  1 11:05:48 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 1 Jun 2017 16:35:48 +0530
Subject: <Swing Dev> [10] RFR JDK-8181421: 3 regtest fail on windows7 in
	Nimbus L&F
Message-ID: <23bb086e-5168-e2c9-b98c-703276418562@oracle.com>

Hi All,

Please review a subitem fix of JDK-7190554 
<https://bugs.openjdk.java.net/browse/JDK-7190554> where some closed 
regression test is failing with Nimbus L&F.

Issue was we were getting NPE
which is because a null style was used in SynthPanelUI to generate the 
SynthContext

java.lang.NullPointerException: You must supply a non-null component, 
region and style
     at 
java.desktop/javax.swing.plaf.synth.SynthContext.getContext(SynthContext.java:58)
     at 
java.desktop/javax.swing.plaf.synth.SynthContext.getContext(SynthContext.java:49)
     at 
java.desktop/javax.swing.plaf.synth.SynthPanelUI.getContext(SynthPanelUI.java:128)
     at 
java.desktop/javax.swing.plaf.synth.SynthPanelUI.updateStyle(SynthPanelUI.java:115)
     at 
java.desktop/javax.swing.plaf.synth.SynthPanelUI.installDefaults(SynthPanelUI.java:100)

Proposed fix is to generate a style before generating SynthContext 
because as per spec,
https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/plaf/synth/SynthContext.html
it should throw NPE||- if component, region or style is null.

Bug: https://bugs.openjdk.java.net/browse/JDK-8181421
webrev: http://cr.openjdk.java.net/~psadhukhan/8181421/webrev.00/

Regards
Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170601/92c451fb/attachment.html>

From sergey.bylokhov at oracle.com  Thu Jun  1 15:42:19 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 1 Jun 2017 08:42:19 -0700 (PDT)
Subject: <Swing Dev> [10] RFR 6962725:Regtest
 javax/swing/JFileChooser/6738668/bug6738668.java fails under Linux
Message-ID: <68eb1a2c-6ea1-4e32-81a7-4f094fce2e0e@default>

Hi, Prasanta.
You should set a JT_JAVA environment variable to jdk8 or jdk9 before running jtreg:
http://openjdk.java.net/jtreg/runtests.html

This java will be used to start a jtreg itself. And for the test the java passed to "-jdk" will be used.

----- prasanta.sadhukhan at oracle.com wrote:

> I could not run jdk7u40 build with my jtreg harness as it cites the 
> below problem. I do not have jtreg older than 4.2b03, nor I could find
> 
> in jtreg site.
> 
> PRSADHUK-IN+prsadhuk at PRSADHUK-IN /cygdrive/c/jdk9/jtreg-42b03
> $ ./bin/jtreg -jdk:/cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/
> 
> /cygdrive/d/jdk7u/jdk7u-dev/jdk/test/javax/swing/JFileChooser/6738668/bug6738668.java
> java.lang.UnsupportedClassVersionError: 
> com/sun/javatest/regtest/JDK$Fault : Unsupported major.minor version
> 52.0
>          at java.lang.ClassLoader.defineClass1(Native Method)
>          at java.lang.ClassLoader.defineClass(ClassLoader.java:642)
> 
> Regards
> Prasanta
> On 5/30/2017 10:28 PM, Sergey Bylokhov wrote:
> > The new version fails even if run via jtreg?
> >
> > ----- prasanta.sadhukhan at oracle.com wrote:
> >
> >> OK. With revised command line, it fails with new updated test in
> 7b40
> >>
> >> and passed in 9b170
> >>
> >> /cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/bin/java
> >> -Djava.security.manager -Djava.security.policy=security.policy
> >> bug6738668
> >> tmp dir C:\cygwin64\tmp\
> >> Exception in thread "main" java.security.AccessControlException:
> >> access
> >> denied (java.io.FilePermission
> >> C:\Users\prsadhuk\AppData\Roaming\Microsoft\Windows\Recent read)
> >>           at
> >>
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:345)
> >>           at
> >>
> java.security.AccessController.checkPermission(AccessController.java:555)
> >>           at
> >>
> java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> >>           at
> >> java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> >>
> >> /cygdrive/d/Vbox_Shared/JDK/jdk9-b170/fastdebug/bin/java
> >> -Djava.security.manager -Djava.security.policy=security.policy
> >> bug6738668
> >> tmp dir C:\cygwin64\tmp\
> >> Test passed for LookAndFeel
> javax.swing.plaf.metal.MetalLookAndFeel
> >> tmp dir C:\cygwin64\tmp\
> >> Test passed for LookAndFeel
> javax.swing.plaf.nimbus.NimbusLookAndFeel
> >> tmp dir C:\cygwin64\tmp\
> >> Test passed for LookAndFeel
> >> com.sun.java.swing.plaf.motif.MotifLookAndFeel
> >> tmp dir C:\cygwin64\tmp\
> >> Test passed for LookAndFeel
> >> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> >> tmp dir C:\cygwin64\tmp\
> >> Test passed for LookAndFeel
> >> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
> >>
> >> Regards
> >> Prasanta
> >> On 5/30/2017 2:59 AM, Sergey Bylokhov wrote:
> >>> I guess you will need to set security manager which will use your
> >> policy file:
> >>
> https://docs.oracle.com/cd/E13222_01/wls/docs81b/secmanage/java.html
> >>> ----- prasanta.sadhukhan at oracle.com wrote:
> >>>
> >>>> I am not sure why it is passing in my case. I thought it might
> be
> >>>> taking
> >>>> in some other security policy so I renamed and use a different
> >> named
> >>>> policy but it still passed in my windows 7.
> >>>>
> >>>> $ /cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/bin/java
> >>>> -Djava.security.policy=my.policy bug6738668
> >>>> Test passed for LookAndFeel
> >> javax.swing.plaf.metal.MetalLookAndFeel
> >>>> Test passed for LookAndFeel
> >>>> com.sun.java.swing.plaf.motif.MotifLookAndFeel
> >>>> Test passed for LookAndFeel
> >>>> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> >>>> Test passed for LookAndFeel
> >>>> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
> >>>>
> >>>> PRSADHUK-IN+prsadhuk at PRSADHUK-IN
> >>>>
> /cygdrive/d/jdk10/client/jdk/test/javax/swing/JFileChooser/6738668
> >>>> $ cat my.policy
> >>>> grant {
> >>>>        permission java.io.FilePermission "C:\\temp\\*", "read";
> >>>>        permission java.io.FilePermission "C:\\temp", "read";
> >>>>        permission java.util.PropertyPermission "*", "read";
> >>>> };
> >>>>
> >>>> PRSADHUK-IN+prsadhuk at PRSADHUK-IN
> >>>>
> /cygdrive/d/jdk10/client/jdk/test/javax/swing/JFileChooser/6738668
> >>>> $ /cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/bin/java
> >>>> -version
> >>>> java version "1.7.0-ea-fastdebug"
> >>>> Java(TM) SE Runtime Environment (build 1.7.0-ea-fastdebug-b40)
> >>>> Java HotSpot(TM) 64-Bit Server VM (build 14.0-b07-fastdebug,
> mixed
> >>>> mode)
> >>>>
> >>>> BTW, does my updated test fail in your environment with b40?
> >>>>
> >>>> Regards
> >>>> Prasanta
> >>>> On 5/28/2017 4:10 AM, Sergey Bylokhov wrote:
> >>>>> There is a comment that JDK-6738668 a regression of JDK-6484091
> >>>> which was pushed to b20.
> >>>>> I just checked the test from the command line on b40 and it
> >> fails,
> >>>> but passed on b55.
> >>>>> Can you please check why it was passed in your case.
> >>>>>
> >>>>> ----- prasanta.sadhukhan at oracle.com wrote:
> >>>>>
> >>>>>> Hi Sergey,
> >>>>>>
> >>>>>> I do not see any comment mention about failure in 7b20 but
> >> anyways,
> >>>> I
> >>>>>> tried with 7b20,7b30,7b40,7b50 and all of them passed with
> >>>> original
> >>>>>> and
> >>>>>> updated test in windows.
> >>>>>>
> >>>>>> Regards
> >>>>>> Prasanta
> >>>>>> On 5/25/2017 2:30 AM, Sergey Bylokhov wrote:
> >>>>>>> I am not sure but according to the comments of JDK-6738668 it
> >> was
> >>>> a
> >>>>>> regression in 7b20.
> >>>>>>> So I suggest to check a few build between b20 and b54
> >>>>>>>
> >>>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
> >>>>>>>
> >>>>>>>> Hi Sergey,
> >>>>>>>>
> >>>>>>>> No, it is passing. Actually, the original test is also
> passing
> >>>>>> with
> >>>>>>>> 1.7.0 b05 (6738668 is supposedly fixed in 7b55), there's no
> >>>>>>>> SecurityException
> >>>>>>>>
> >>>>>>>> jdk1.7.0/bin/java -Djava.security.policy=security.policy
> >>>>>> bug6738668
> >>>>>>>> Test passed for LookAndFeel
> >>>>>> javax.swing.plaf.metal.MetalLookAndFeel
> >>>>>>>> Test passed for LookAndFeel
> >>>>>>>> com.sun.java.swing.plaf.motif.MotifLookAndFeel
> >>>>>>>> Test passed for LookAndFeel
> >>>>>>>> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> >>>>>>>> Test passed for LookAndFeel
> >>>>>>>> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
> >>>>>>>>
> >>>>>>>> jdk1.7.0/bin/java -version
> >>>>>>>> java version "1.7.0-ea"
> >>>>>>>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b05)
> >>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.7.0-ea-b05, mixed
> >>>> mode)
> >>>>>>>> Regards
> >>>>>>>> Prasanta
> >>>>>>>> On 5/24/2017 11:48 AM, Sergey Bylokhov wrote:
> >>>>>>>>> Hi, Prasanta.
> >>>>>>>>> Please confirm that the updated test fails before
> JDK-6738668
> >>>> was
> >>>>>>>> fixed.
> >>>>>>>>>> Hi ALl,
> >>>>>>>>>>
> >>>>>>>>>> Please review a testbug fix for an issue where this
> >> regression
> >>>>>> test
> >>>>>>>> is failing in linux because
> >>>>>>>>>> JFileChooser was trying to access C:/temp path which does
> >> not
> >>>>>> exist
> >>>>>>>> in linux.
> >>>>>>>>>> Proposed fix is to use java.io.tmpdir instead of hardcoded
> >>>>>> windows
> >>>>>>>> path.
> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6962725
> >>>>>>>>>> webrev:
> >>>>>> http://cr.openjdk.java.net/~psadhukhan/6962725/webrev.00/
> >>>>>>>>>> Regards
> >>>>>>>>>> Prasanta


From sergey.bylokhov at oracle.com  Thu Jun  1 18:37:54 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 1 Jun 2017 11:37:54 -0700 (PDT)
Subject: <Swing Dev> [10] RFR: JDK-8043315: Nimbus: Setting
 Nimbus.Overrides property affects custom keymap installation
Message-ID: <54afabea-f351-4fd5-860a-29bd293b2c6d@default>

Hi, Prasanta.
Can you please clarify the fix a little bit. 
You have a static variable, which is set to "false" when the listener for "keymap" is triggered, and it seems that you never set it back to "true"? Is it intentional behavior?
Note that if there are a few objects of "SynthEditorPaneUI" then they will share this static field. Also it seems that the test can be automated, because currently it is requires from the user to press only one button("space").

----- prasanta.sadhukhan at oracle.com wrote:

> Hi All,
> 
> Please review a bug fix for Nimbus L&F where if app sets custom keymap
> 
> and then sets Nimbus.Overrides property,
> then the custom keymap is not honoured.
> For example, if testapp sets a new action for "space" key press and
> sets 
> sets Nimbus.Overrides property,
>   it will not be honoured and default action ie. inserting a "space" 
> character will be done.
> 
> Issue was NimbusLookAndFeel#shouldUpdateStyleOnEvent() returns true
> for 
> Nimbus.Override property which causes SynthEditorPaneUI#updateStyle()
> to 
> be called which
> uninstall set keyboard actions and sets up default keyboard action.
> 
> Proposed fix is to check if a keymap is already set (a propertyChange
> 
> event will be fired for when app calls setKeyMap()) then do not reset
> to 
> default keymap.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8043315
> webrev: http://cr.openjdk.java.net/~psadhukhan/8043315/webrev.00/
> 
> Regards
> Prasanta


From sergey.bylokhov at oracle.com  Thu Jun  1 19:03:24 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 1 Jun 2017 12:03:24 -0700 (PDT)
Subject: <Swing Dev> [10] RFR: JDK-8075918:The regression-swing case
 failed as the long Tab titles are not clipped with dots at the end with
 NimbusLookAndFeel
Message-ID: <a4a1ae6b-2d1c-4d99-abcf-e2a3cd24659d@default>

 - There is a problem in your algorithm which merges the old and new clips. The getClipBounds() returns a rectangle which is a bounds of the current clip(which is not necessary a rectangle but can be a shape). you can use the Graphics2D.clip(Shape) method which will intersect the passed shape and a current clip of the graphics.
 - In this version you forgot to restore the changed clip.
 - Also can you try to move the code which change a clip to the methods which currently ignore the passed clip(see below):
> >> BasicTabbedPaneUI.paintIcon() as well as
> >> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
> >>   - paintText() at line 681
> >>   - paintIcon() at line 634
> >> Both methods have a rectangle as a parameter, but it is ignored.


----- prasanta.sadhukhan at oracle.com wrote:

> I tried to incorporate your comments. Please find modified webrev
> 
> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.03/
> 
> Regards
> Prasanta
> On 5/28/2017 8:01 AM, Sergey Bylokhov wrote:
> > Note that you shouldn't replace the clip, but should apply the new
> clip on top of the old. This is necessary if the old clip is smaller
> than new.
> >
> > ----- sergey.bylokhov at oracle.com wrote:
> >
> >> Hi, Prasanta.
> >>
> >> BasicTabbedPaneUI.paintIcon() as well as
> >> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
> >>   - paintText() at line 681
> >>   - paintIcon() at line 634
> >> Both methods have a rectangle as a parameter, but it is ignored.
> >>
> >> ----- prasanta.sadhukhan at oracle.com wrote:
> >>
> >>> Hi Sergey,
> >>>
> >>> I could get your concern for paintText() but could not find
> >>> paintIcon()
> >>> in SynthGraphicsUtils() so not sure how icon drawing contradicts
> >>> spec.
> >>> Modified webrev:
> >>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/
> >>>
> >>> Also, if we are not calling
> SwingUtilities2.clipStringIfNecessary()
> >>> then
> >>> we are not going to get "..." at the end which this test expects.
> >> But
> >>> I
> >>> could not find anything in spec, that mandates ending with "..."
> for
> >>> long tab outside
> >>> tab bounds. If source change is ok, I guess we then need to
> modify
> >> the
> >>> html file modifying the expected result for NimbusL&F.
> >>>
> >>> Regards
> >>> Prasanta
> >>> On 5/25/2017 3:11 AM, Sergey Bylokhov wrote:
> >>>> Hi, Prasanta.
> >>>> Please take a look to my comments at:
> >>>>
> >>
> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html
> >>
> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html
> >>>> The two methods paintText() and paintIcon() are contradict the
> >> spec
> >>> and draw the text and icons outside of the tab.
> >>>> ----- prasanta.sadhukhan at oracle.com wrote:
> >>>>
> >>>>> Hi All,
> >>>>>
> >>>>> Please review a fix for an issue where long Tab titiles are not
> >>>>> clipped
> >>>>> with dots at end for NimbusLookAndFeel L&F.
> >>>>> Other L&Fs works ok.
> >>>>>
> >>>>> Issue was in SynthTabbedPaneUI#paintTab(), the title is not
> >>> clipped
> >>>>> but
> >>>>> passed to paintText() as it is received.
> >>>>> Other L&F such as Metal, Motif, Windows which uses
> >>>>> BasicTabbedPaneUI#paintTab(), the title is clipped
> >>>>>
> >>
> http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950
> >>>>> before it is passed to paintText().
> >>>>>
> >>>>> Proposed fix is to do the same for
> SynthTabbedPaneUI#paintTab().
> >>>>>
> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075918
> >>>>> webrev:
> >> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/
> >>>>> Regards
> >>>>> Prasanta


From sergey.bylokhov at oracle.com  Thu Jun  1 20:05:58 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 1 Jun 2017 13:05:58 -0700 (PDT)
Subject: <Swing Dev> [10] RFR JDK-8181421: 3 regtest fail on windows7 in
 Nimbus L&F
Message-ID: <7194c05f-f147-4df8-8947-7053a3d1d60b@default>

Hi, Prasanta. 
I have few small notes. 
- Did you check why the null value was passed to this method? 
- It seems that the tests are passed by default. It would be good to run them over the installed l&f. In this case they will fail before the fix. 
- Is it possible to remove the html files from the tests? 
- The tests also have some common issues, the Swing components are accessed on non-edt thread. some unnecessary commented code, etc. 

----- prasanta.sadhukhan at oracle.com wrote: 
> 


Hi All, 

Please review a subitem fix of JDK-7190554 where some closed regression test is failing with Nimbus L&F. Issue was we were getting NPE 
> which is because a null style was used in SynthPanelUI to generate the SynthContext 
> 
> java.lang.NullPointerException: You must supply a non-null component, region and style 
> at java.desktop/javax.swing.plaf.synth.SynthContext.getContext(SynthContext.java:58) 
> at java.desktop/javax.swing.plaf.synth.SynthContext.getContext(SynthContext.java:49) 
> at java.desktop/javax.swing.plaf.synth.SynthPanelUI.getContext(SynthPanelUI.java:128) 
> at java.desktop/javax.swing.plaf.synth.SynthPanelUI.updateStyle(SynthPanelUI.java:115) 
> at java.desktop/javax.swing.plaf.synth.SynthPanelUI.installDefaults(SynthPanelUI.java:100) 
> 
> Proposed fix is to generate a style before generating SynthContext because as per spec, 
> https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/plaf/synth/SynthContext.html 
> it should throw NPE - if component, region or style is null. 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8181421 
> webrev: http://cr.openjdk.java.net/~psadhukhan/8181421/webrev.00/ 
> 
> Regards 
> Prasanta 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170601/855ce738/attachment.html>

From prasanta.sadhukhan at oracle.com  Fri Jun  2 05:30:22 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 2 Jun 2017 11:00:22 +0530
Subject: <Swing Dev> [10] RFR 6962725:Regtest
 javax/swing/JFileChooser/6738668/bug6738668.java fails under Linux
In-Reply-To: <68eb1a2c-6ea1-4e32-81a7-4f094fce2e0e@default>
References: <68eb1a2c-6ea1-4e32-81a7-4f094fce2e0e@default>
Message-ID: <4567ce5a-25e9-03d0-eba3-3e9bbd002a66@oracle.com>

Thanks Sergey. I confirm new test fails with 7b40 in jtreg and pass with 
9b170.

Regards
Prasanta
On 6/1/2017 9:12 PM, Sergey Bylokhov wrote:
> Hi, Prasanta.
> You should set a JT_JAVA environment variable to jdk8 or jdk9 before running jtreg:
> http://openjdk.java.net/jtreg/runtests.html
>
> This java will be used to start a jtreg itself. And for the test the java passed to "-jdk" will be used.
>
> ----- prasanta.sadhukhan at oracle.com wrote:
>
>> I could not run jdk7u40 build with my jtreg harness as it cites the
>> below problem. I do not have jtreg older than 4.2b03, nor I could find
>>
>> in jtreg site.
>>
>> PRSADHUK-IN+prsadhuk at PRSADHUK-IN /cygdrive/c/jdk9/jtreg-42b03
>> $ ./bin/jtreg -jdk:/cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/
>>
>> /cygdrive/d/jdk7u/jdk7u-dev/jdk/test/javax/swing/JFileChooser/6738668/bug6738668.java
>> java.lang.UnsupportedClassVersionError:
>> com/sun/javatest/regtest/JDK$Fault : Unsupported major.minor version
>> 52.0
>>           at java.lang.ClassLoader.defineClass1(Native Method)
>>           at java.lang.ClassLoader.defineClass(ClassLoader.java:642)
>>
>> Regards
>> Prasanta
>> On 5/30/2017 10:28 PM, Sergey Bylokhov wrote:
>>> The new version fails even if run via jtreg?
>>>
>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>
>>>> OK. With revised command line, it fails with new updated test in
>> 7b40
>>>> and passed in 9b170
>>>>
>>>> /cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/bin/java
>>>> -Djava.security.manager -Djava.security.policy=security.policy
>>>> bug6738668
>>>> tmp dir C:\cygwin64\tmp\
>>>> Exception in thread "main" java.security.AccessControlException:
>>>> access
>>>> denied (java.io.FilePermission
>>>> C:\Users\prsadhuk\AppData\Roaming\Microsoft\Windows\Recent read)
>>>>            at
>>>>
>> java.security.AccessControlContext.checkPermission(AccessControlContext.java:345)
>>>>            at
>>>>
>> java.security.AccessController.checkPermission(AccessController.java:555)
>>>>            at
>>>>
>> java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
>>>>            at
>>>> java.lang.SecurityManager.checkRead(SecurityManager.java:888)
>>>>
>>>> /cygdrive/d/Vbox_Shared/JDK/jdk9-b170/fastdebug/bin/java
>>>> -Djava.security.manager -Djava.security.policy=security.policy
>>>> bug6738668
>>>> tmp dir C:\cygwin64\tmp\
>>>> Test passed for LookAndFeel
>> javax.swing.plaf.metal.MetalLookAndFeel
>>>> tmp dir C:\cygwin64\tmp\
>>>> Test passed for LookAndFeel
>> javax.swing.plaf.nimbus.NimbusLookAndFeel
>>>> tmp dir C:\cygwin64\tmp\
>>>> Test passed for LookAndFeel
>>>> com.sun.java.swing.plaf.motif.MotifLookAndFeel
>>>> tmp dir C:\cygwin64\tmp\
>>>> Test passed for LookAndFeel
>>>> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>>>> tmp dir C:\cygwin64\tmp\
>>>> Test passed for LookAndFeel
>>>> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 5/30/2017 2:59 AM, Sergey Bylokhov wrote:
>>>>> I guess you will need to set security manager which will use your
>>>> policy file:
>>>>
>> https://docs.oracle.com/cd/E13222_01/wls/docs81b/secmanage/java.html
>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>
>>>>>> I am not sure why it is passing in my case. I thought it might
>> be
>>>>>> taking
>>>>>> in some other security policy so I renamed and use a different
>>>> named
>>>>>> policy but it still passed in my windows 7.
>>>>>>
>>>>>> $ /cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/bin/java
>>>>>> -Djava.security.policy=my.policy bug6738668
>>>>>> Test passed for LookAndFeel
>>>> javax.swing.plaf.metal.MetalLookAndFeel
>>>>>> Test passed for LookAndFeel
>>>>>> com.sun.java.swing.plaf.motif.MotifLookAndFeel
>>>>>> Test passed for LookAndFeel
>>>>>> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>>>>>> Test passed for LookAndFeel
>>>>>> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
>>>>>>
>>>>>> PRSADHUK-IN+prsadhuk at PRSADHUK-IN
>>>>>>
>> /cygdrive/d/jdk10/client/jdk/test/javax/swing/JFileChooser/6738668
>>>>>> $ cat my.policy
>>>>>> grant {
>>>>>>         permission java.io.FilePermission "C:\\temp\\*", "read";
>>>>>>         permission java.io.FilePermission "C:\\temp", "read";
>>>>>>         permission java.util.PropertyPermission "*", "read";
>>>>>> };
>>>>>>
>>>>>> PRSADHUK-IN+prsadhuk at PRSADHUK-IN
>>>>>>
>> /cygdrive/d/jdk10/client/jdk/test/javax/swing/JFileChooser/6738668
>>>>>> $ /cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/bin/java
>>>>>> -version
>>>>>> java version "1.7.0-ea-fastdebug"
>>>>>> Java(TM) SE Runtime Environment (build 1.7.0-ea-fastdebug-b40)
>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 14.0-b07-fastdebug,
>> mixed
>>>>>> mode)
>>>>>>
>>>>>> BTW, does my updated test fail in your environment with b40?
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 5/28/2017 4:10 AM, Sergey Bylokhov wrote:
>>>>>>> There is a comment that JDK-6738668 a regression of JDK-6484091
>>>>>> which was pushed to b20.
>>>>>>> I just checked the test from the command line on b40 and it
>>>> fails,
>>>>>> but passed on b55.
>>>>>>> Can you please check why it was passed in your case.
>>>>>>>
>>>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>>>
>>>>>>>> Hi Sergey,
>>>>>>>>
>>>>>>>> I do not see any comment mention about failure in 7b20 but
>>>> anyways,
>>>>>> I
>>>>>>>> tried with 7b20,7b30,7b40,7b50 and all of them passed with
>>>>>> original
>>>>>>>> and
>>>>>>>> updated test in windows.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>> On 5/25/2017 2:30 AM, Sergey Bylokhov wrote:
>>>>>>>>> I am not sure but according to the comments of JDK-6738668 it
>>>> was
>>>>>> a
>>>>>>>> regression in 7b20.
>>>>>>>>> So I suggest to check a few build between b20 and b54
>>>>>>>>>
>>>>>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>>>>>
>>>>>>>>>> Hi Sergey,
>>>>>>>>>>
>>>>>>>>>> No, it is passing. Actually, the original test is also
>> passing
>>>>>>>> with
>>>>>>>>>> 1.7.0 b05 (6738668 is supposedly fixed in 7b55), there's no
>>>>>>>>>> SecurityException
>>>>>>>>>>
>>>>>>>>>> jdk1.7.0/bin/java -Djava.security.policy=security.policy
>>>>>>>> bug6738668
>>>>>>>>>> Test passed for LookAndFeel
>>>>>>>> javax.swing.plaf.metal.MetalLookAndFeel
>>>>>>>>>> Test passed for LookAndFeel
>>>>>>>>>> com.sun.java.swing.plaf.motif.MotifLookAndFeel
>>>>>>>>>> Test passed for LookAndFeel
>>>>>>>>>> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>>>>>>>>>> Test passed for LookAndFeel
>>>>>>>>>> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
>>>>>>>>>>
>>>>>>>>>> jdk1.7.0/bin/java -version
>>>>>>>>>> java version "1.7.0-ea"
>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b05)
>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.7.0-ea-b05, mixed
>>>>>> mode)
>>>>>>>>>> Regards
>>>>>>>>>> Prasanta
>>>>>>>>>> On 5/24/2017 11:48 AM, Sergey Bylokhov wrote:
>>>>>>>>>>> Hi, Prasanta.
>>>>>>>>>>> Please confirm that the updated test fails before
>> JDK-6738668
>>>>>> was
>>>>>>>>>> fixed.
>>>>>>>>>>>> Hi ALl,
>>>>>>>>>>>>
>>>>>>>>>>>> Please review a testbug fix for an issue where this
>>>> regression
>>>>>>>> test
>>>>>>>>>> is failing in linux because
>>>>>>>>>>>> JFileChooser was trying to access C:/temp path which does
>>>> not
>>>>>>>> exist
>>>>>>>>>> in linux.
>>>>>>>>>>>> Proposed fix is to use java.io.tmpdir instead of hardcoded
>>>>>>>> windows
>>>>>>>>>> path.
>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6962725
>>>>>>>>>>>> webrev:
>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/6962725/webrev.00/
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Prasanta



From prasanta.sadhukhan at oracle.com  Fri Jun  2 08:29:31 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 2 Jun 2017 13:59:31 +0530
Subject: <Swing Dev> [10] RFR: JDK-8043315: Nimbus: Setting
 Nimbus.Overrides property affects custom keymap installation
In-Reply-To: <54afabea-f351-4fd5-860a-29bd293b2c6d@default>
References: <54afabea-f351-4fd5-860a-29bd293b2c6d@default>
Message-ID: <8af41cf8-f51a-6322-9664-6d45fc640a80@oracle.com>

Hi Sergey,

I have modified webrev to remove static keyword and made the test automated
http://cr.openjdk.java.net/~psadhukhan/8043315/webrev.01/
Updated fix tests if app has fired a property change by calling 
setKeymap() then it will not uninstall custom keymap and let the custom 
keymap be honoured. If app again calls setKeymap(null) then the static 
variable will be "true" and it will reset back to default keymap.

Regards
Prasanta
On 6/2/2017 12:07 AM, Sergey Bylokhov wrote:
> Hi, Prasanta.
> Can you please clarify the fix a little bit.
> You have a static variable, which is set to "false" when the listener for "keymap" is triggered, and it seems that you never set it back to "true"? Is it intentional behavior?
> Note that if there are a few objects of "SynthEditorPaneUI" then they will share this static field. Also it seems that the test can be automated, because currently it is requires from the user to press only one button("space").
>
> ----- prasanta.sadhukhan at oracle.com wrote:
>
>> Hi All,
>>
>> Please review a bug fix for Nimbus L&F where if app sets custom keymap
>>
>> and then sets Nimbus.Overrides property,
>> then the custom keymap is not honoured.
>> For example, if testapp sets a new action for "space" key press and
>> sets
>> sets Nimbus.Overrides property,
>>    it will not be honoured and default action ie. inserting a "space"
>> character will be done.
>>
>> Issue was NimbusLookAndFeel#shouldUpdateStyleOnEvent() returns true
>> for
>> Nimbus.Override property which causes SynthEditorPaneUI#updateStyle()
>> to
>> be called which
>> uninstall set keyboard actions and sets up default keyboard action.
>>
>> Proposed fix is to check if a keymap is already set (a propertyChange
>>
>> event will be fired for when app calls setKeyMap()) then do not reset
>> to
>> default keymap.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8043315
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8043315/webrev.00/
>>
>> Regards
>> Prasanta



From prasanta.sadhukhan at oracle.com  Fri Jun  2 08:38:52 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 2 Jun 2017 14:08:52 +0530
Subject: <Swing Dev> [10] RFR JDK-8181401: Error in Javadoc for JTabbedPane
 getAccessibleName()
Message-ID: <93483c5a-2c90-fad3-b2ab-4177671defd0@oracle.com>

Hi All,

Please review a javadoc fix where it seems the documentation for 
JTabbedPane getAccessibleName() states "the accessible name of this 
object, nor null."
Where is should be "the accessible name of this object, or null."
Modified javadoc to update the same.

Bug: https://bugs.openjdk.java.net/browse/JDK-8181401
webrev: http://cr.openjdk.java.net/~psadhukhan/8181401/webrev.00/

Regards
Prasanta


From semyon.sadetsky at oracle.com  Fri Jun  2 14:46:57 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 2 Jun 2017 07:46:57 -0700
Subject: <Swing Dev> [10] RFR JDK-8181401: Error in Javadoc for
 JTabbedPane getAccessibleName()
In-Reply-To: <93483c5a-2c90-fad3-b2ab-4177671defd0@oracle.com>
References: <93483c5a-2c90-fad3-b2ab-4177671defd0@oracle.com>
Message-ID: <94b2351c-7d6c-c3c4-67f1-042c5ba429f1@oracle.com>

+1

--Semyon


On 06/02/2017 01:38 AM, Prasanta Sadhukhan wrote:
> Hi All,
>
> Please review a javadoc fix where it seems the documentation for 
> JTabbedPane getAccessibleName() states "the accessible name of this 
> object, nor null."
> Where is should be "the accessible name of this object, or null."
> Modified javadoc to update the same.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8181401
> webrev: http://cr.openjdk.java.net/~psadhukhan/8181401/webrev.00/
>
> Regards
> Prasanta



From sergey.bylokhov at oracle.com  Fri Jun  2 15:32:53 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 2 Jun 2017 08:32:53 -0700 (PDT)
Subject: <Swing Dev> [10] RFR JDK-8181401: Error in Javadoc for
 JTabbedPane getAccessibleName()
Message-ID: <1612152f-6c77-42e0-8ad8-80241c7b6769@default>

Looks fine.

----- prasanta.sadhukhan at oracle.com wrote:

> Hi All,
> 
> Please review a javadoc fix where it seems the documentation for 
> JTabbedPane getAccessibleName() states "the accessible name of this 
> object, nor null."
> Where is should be "the accessible name of this object, or null."
> Modified javadoc to update the same.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8181401
> webrev: http://cr.openjdk.java.net/~psadhukhan/8181401/webrev.00/
> 
> Regards
> Prasanta


From sergey.bylokhov at oracle.com  Mon Jun  5 00:53:35 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Sun, 4 Jun 2017 17:53:35 -0700 (PDT)
Subject: <Swing Dev> <Sound Dev> [9] Review Request: 8180326 Update the
 tables in java.desktop to be HTML-5 friendly
Message-ID: <4f6a1420-831d-4b6c-946c-05e770cb2f14@default>

If there are no objections I'll change the target ws from dev to client, to minimize the merges between some other javadoc fixes.

----- sergey.bylokhov at oracle.com wrote:

> Hello.
> Here is an updated version where most of the caption are visible.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
> Webrev can be found at:
> http://cr.openjdk.java.net/~serb/8180326/webrev.02/
> Specdiff:
> http://cr.openjdk.java.net/~serb/8180326/specdiff.02/overview-summary.html
> 
> You can use search to check the changes in some specific class:
> Old docs:
> http://cr.openjdk.java.net/~serb/8180326/api_old.02/overview-summary.html
> New docs:
> http://cr.openjdk.java.net/~serb/8180326/api.02/overview-summary.html
> 
> 
> ----- jonathan.gibbons at oracle.com wrote:
> 
> > Phil,
> > 
> > I have no evidence one way or the other whether screen readers pay 
> > attention
> > to undisplayed or invisible captions. It seemed safest to assume
> that
> > 
> > they would
> > read a visible caption, and that we should head in that general
> > direction.
> > 
> > -- Jon
> > 
> > 
> > On 05/17/2017 11:58 AM, Phil Race wrote:
> > > And PS I was not saying anything to contradict
> > > > tables should not have a summary attribute and should have a
> > caption.
> > >
> > > However that the docs I read on the web did seem to imply that
> > > summary was very much intended for ATs but it was not at all
> clear
> > this
> > > is the point of caption. I'm sure they can read it, but I don't
> get
> > 
> > > how making
> > > it visible matters to them so how it making it visible relates to
> 
> > > accessibility
> > > requirements is not an obvious connection to me. So why do we
> have
> > > to make it visible for ATs ?
> > >
> > > -phil.
> > >
> > > On 05/17/2017 11:54 AM, Phil Race wrote:
> > >> I will leave the decision on whether to do that now up to Sergey
> 
> > >> although
> > >> it seems all he has to do here is remove "invisible".
> > >> Many of the "summary" ones had wrong or misleading text but they
> > >> seem to have been all fixed.
> > >>
> > >> I'd want to see what the new HTML looks like with a visible
> title
> > of 
> > >> course ..
> > >>
> > >> -phil.
> > >>
> > >> On 05/17/2017 11:52 AM, Jonathan Gibbons wrote:
> > >>> Phil,
> > >>>
> > >>> The bottom line is that in the JDK docs, tables should not have
> a
> > 
> > >>> summary attribute and should have a caption. This comes down to
> 
> > >>> accessibility requirements, where we are slowly raising the bar
> on
> > 
> > >>> our docs, to be in accordance with Oracle's guidelines.
> > >>>
> > >>> Hiding the caption (style="display:none") is an interim measure
> we
> > 
> > >>> have been using during the HTML 5 updates, especially in cases
> > where 
> > >>> the person doing the markup changes did not know enough to
> create
> > an 
> > >>> appropriate caption that should be displayed. In time, we should
> 
> > >>> locate and update all table captions (in our standard docs
> bundle)
> > 
> > >>> that are not being displayed such that the text is both
> > appropriate 
> > >>> and visible. If you guys want to do that as part of this
> update,
> > go 
> > >>> ahead. FWIW, that is what we did for the java.xml module in the
> > jaxp 
> > >>> repo ... pretty much all tables there now have a reasonable,
> > visible 
> > >>> caption.
> > >>>
> > >>> -- Jon
> > >>>
> > >>>
> > >>>
> > >>> On 05/17/2017 11:19 AM, Phil Race wrote:
> > >>>> I am not sure we are using the summary in a way that makes it 
> > >>>> worthwhile.
> > >>>> As you noted in the other mail
> > >>>> "The summary attribute was used to give a more descriptive
> value
> > >>>> of the contents of the table.   A caption is more like a
> title"
> > >>>>
> > >>>> The values I see are more like a title and as you say that is
> not
> > 
> > >>>> the idea. See the example here
> > >>>>
> > >>>> https://www.w3.org/TR/WCAG20-TECHS/H73.html
> > >>>>
> > >>>> Caption sounds like a title so it might actually be more 
> > >>>> appropriate than summary
> > >>>> for the text we have except that its not clear why we'd want
> it
> > to 
> > >>>> be visible when we were fine without.
> > >>>>
> > >>>> But being there and invisible may be pointless unless screen 
> > >>>> readers look for it even if invisible.
> > >>>>
> > >>>> But if its not doing any harm I guess we can leave it as
> > proposed
> > >>>>
> > >>>> I still need to look at the rest of the changes.
> > >>>>
> > >>>> -phil.
> > >>>>
> > >>>> On 05/12/2017 05:11 PM, Jonathan Gibbons wrote:
> > >>>>> Sergey,
> > >>>>>
> > >>>>> FWIW, the invisible caption should be regarded as a temporary
> 
> > >>>>> solution, until content authors can review/update the text of
> > the 
> > >>>>> caption and make it visible.
> > >>>>>
> > >>>>> The general guideline in this conversion work has been to
> avoid
> > 
> > >>>>> changing the visible text of the specification, and captions
> > fall 
> > >>>>> into a grey area of whether the text is significant/normative
> or
> > 
> > >>>>> not.  Hence the temporary step to make them not displayed for
> > now.
> > >>>>>
> > >>>>> -- Jon
> > >>>>>
> > >>>>> On 05/12/2017 05:00 PM, Sergey Bylokhov wrote:
> > >>>>>> The "summary" is unsupported by the HTML5 and we replace it
> by
> > 
> > >>>>>> invisible caption.
> > >>>>>> These new styles are located in the stylesheet.css in the
> root
> > of 
> > >>>>>> the JavaDoc api folder, so I assume these styles should be
> used
> > 
> > >>>>>> by others as well.
> > >>>>>> They were added by this fix:
> > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8179479
> > >>>>>>
> > >>>>>> ----- philip.race at oracle.com wrote:
> > >>>>>>
> > >>>>>>> Does this in any way match the rest of the docs ? Or is
> > everyone 
> > >>>>>>> left
> > >>>>>>> to
> > >>>>>>> style things how they want.
> > >>>>>>> I thought (?) maybe there is to be some javadoc tool
> support
> > for 
> > >>>>>>> CSS
> > >>>>>>> styles.
> > >>>>>>>
> > >>>>>>> Also why are all the table summaries removed ?
> > >>>>>>>
> > >>>>>>> -phil.
> > >>>>>>>
> > >>>>>>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
> > >>>>>>>> This is because I use the same style for most of the
> tables
> > >>>>>>> 'class="striped"', which apply the same/unified style for 
> > >>>>>>> all(most) of
> > >>>>>>> our tables.
> > >>>>>>>> Also this is because I removed 'inlined' styles, like
> here:
> > >>>>>>>>
> > >>>>>>>
> >
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
> > 
> > >>>>>>>
> > >>>>>>>> ----- philip.race at oracle.com wrote:
> > >>>>>>>>
> > >>>>>>>>> Adding 2d-dev because a number of the files are 2D.
> > >>>>>>>>>
> > >>>>>>>>> What is the general reason for changing the appearance of
> > the
> > >>>>>>> tables?
> > >>>>>>>>> -phil.
> > >>>>>>>>>
> > >>>>>>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
> > >>>>>>>>>> Hello,
> > >>>>>>>>>> Please review the fix for jdk9-dev.
> > >>>>>>>>>>
> > >>>>>>>>>> This fix is a part of the effort to make all javadoc in
> > jdk9 be
> > >>>>>>>>> compatible to HTML5.
> > >>>>>>>>>> It covers all errors which are reported by the javadoc
> > tool
> > >>>>>>> during
> > >>>>>>>>> the build of jdk for java.desktop module.
> > >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
> > >>>>>>>>>> Webrev can be found at:
> > >>>>>>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
> > >>>>>>>>>> Note that an appearance of some tables were changed
> after
> > the
> > >>>>>>> fix:
> > >>>>>>>>>> Before:
> > >>>>>>>
> >
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
> > 
> > >>>>>>>
> > >>>>>>>>>> After:
> > >>>>>>>
> >
> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html
> > 
> > >>>>>>>
> > >>>>>>>>>> Before:
> > >>>>>>>
> >
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html
> > 
> > >>>>>>>
> > >>>>>>>>>> After :
> > >>>>>>>
> >
> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html
> > 
> > >>>>>>>
> > >>>>>>>>>> Before:
> > >>>>>>>
> >
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html
> > 
> > >>>>>>>
> > >>>>>>>>>> After:
> > >>>>>>>
> >
> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html
> > 
> > >>>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> > >


From philip.race at oracle.com  Mon Jun  5 01:12:28 2017
From: philip.race at oracle.com (Philip Race)
Date: Sun, 04 Jun 2017 18:12:28 -0700
Subject: <Swing Dev> <Sound Dev> [9] Review Request: 8180326 Update the
 tables in java.desktop to be HTML-5 friendly
In-Reply-To: <4f6a1420-831d-4b6c-946c-05e770cb2f14@default>
References: <4f6a1420-831d-4b6c-946c-05e770cb2f14@default>
Message-ID: <5934AFFC.8080805@oracle.com>

I don't remember anything left that I would object to .. and we'll push 
client changes
to dev this week anyway so it all sounds fine.

-phil.

On 6/4/17, 5:53 PM, Sergey Bylokhov wrote:
> If there are no objections I'll change the target ws from dev to client, to minimize the merges between some other javadoc fixes.
>
> ----- sergey.bylokhov at oracle.com wrote:
>
>> Hello.
>> Here is an updated version where most of the caption are visible.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>> Webrev can be found at:
>> http://cr.openjdk.java.net/~serb/8180326/webrev.02/
>> Specdiff:
>> http://cr.openjdk.java.net/~serb/8180326/specdiff.02/overview-summary.html
>>
>> You can use search to check the changes in some specific class:
>> Old docs:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.02/overview-summary.html
>> New docs:
>> http://cr.openjdk.java.net/~serb/8180326/api.02/overview-summary.html
>>
>>
>> ----- jonathan.gibbons at oracle.com wrote:
>>
>>> Phil,
>>>
>>> I have no evidence one way or the other whether screen readers pay
>>> attention
>>> to undisplayed or invisible captions. It seemed safest to assume
>> that
>>> they would
>>> read a visible caption, and that we should head in that general
>>> direction.
>>>
>>> -- Jon
>>>
>>>
>>> On 05/17/2017 11:58 AM, Phil Race wrote:
>>>> And PS I was not saying anything to contradict
>>>>> tables should not have a summary attribute and should have a
>>> caption.
>>>> However that the docs I read on the web did seem to imply that
>>>> summary was very much intended for ATs but it was not at all
>> clear
>>> this
>>>> is the point of caption. I'm sure they can read it, but I don't
>> get
>>>> how making
>>>> it visible matters to them so how it making it visible relates to
>>>> accessibility
>>>> requirements is not an obvious connection to me. So why do we
>> have
>>>> to make it visible for ATs ?
>>>>
>>>> -phil.
>>>>
>>>> On 05/17/2017 11:54 AM, Phil Race wrote:
>>>>> I will leave the decision on whether to do that now up to Sergey
>>>>> although
>>>>> it seems all he has to do here is remove "invisible".
>>>>> Many of the "summary" ones had wrong or misleading text but they
>>>>> seem to have been all fixed.
>>>>>
>>>>> I'd want to see what the new HTML looks like with a visible
>> title
>>> of
>>>>> course ..
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 05/17/2017 11:52 AM, Jonathan Gibbons wrote:
>>>>>> Phil,
>>>>>>
>>>>>> The bottom line is that in the JDK docs, tables should not have
>> a
>>>>>> summary attribute and should have a caption. This comes down to
>>>>>> accessibility requirements, where we are slowly raising the bar
>> on
>>>>>> our docs, to be in accordance with Oracle's guidelines.
>>>>>>
>>>>>> Hiding the caption (style="display:none") is an interim measure
>> we
>>>>>> have been using during the HTML 5 updates, especially in cases
>>> where
>>>>>> the person doing the markup changes did not know enough to
>> create
>>> an
>>>>>> appropriate caption that should be displayed. In time, we should
>>>>>> locate and update all table captions (in our standard docs
>> bundle)
>>>>>> that are not being displayed such that the text is both
>>> appropriate
>>>>>> and visible. If you guys want to do that as part of this
>> update,
>>> go
>>>>>> ahead. FWIW, that is what we did for the java.xml module in the
>>> jaxp
>>>>>> repo ... pretty much all tables there now have a reasonable,
>>> visible
>>>>>> caption.
>>>>>>
>>>>>> -- Jon
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 05/17/2017 11:19 AM, Phil Race wrote:
>>>>>>> I am not sure we are using the summary in a way that makes it
>>>>>>> worthwhile.
>>>>>>> As you noted in the other mail
>>>>>>> "The summary attribute was used to give a more descriptive
>> value
>>>>>>> of the contents of the table.   A caption is more like a
>> title"
>>>>>>> The values I see are more like a title and as you say that is
>> not
>>>>>>> the idea. See the example here
>>>>>>>
>>>>>>> https://www.w3.org/TR/WCAG20-TECHS/H73.html
>>>>>>>
>>>>>>> Caption sounds like a title so it might actually be more
>>>>>>> appropriate than summary
>>>>>>> for the text we have except that its not clear why we'd want
>> it
>>> to
>>>>>>> be visible when we were fine without.
>>>>>>>
>>>>>>> But being there and invisible may be pointless unless screen
>>>>>>> readers look for it even if invisible.
>>>>>>>
>>>>>>> But if its not doing any harm I guess we can leave it as
>>> proposed
>>>>>>> I still need to look at the rest of the changes.
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>> On 05/12/2017 05:11 PM, Jonathan Gibbons wrote:
>>>>>>>> Sergey,
>>>>>>>>
>>>>>>>> FWIW, the invisible caption should be regarded as a temporary
>>>>>>>> solution, until content authors can review/update the text of
>>> the
>>>>>>>> caption and make it visible.
>>>>>>>>
>>>>>>>> The general guideline in this conversion work has been to
>> avoid
>>>>>>>> changing the visible text of the specification, and captions
>>> fall
>>>>>>>> into a grey area of whether the text is significant/normative
>> or
>>>>>>>> not.  Hence the temporary step to make them not displayed for
>>> now.
>>>>>>>> -- Jon
>>>>>>>>
>>>>>>>> On 05/12/2017 05:00 PM, Sergey Bylokhov wrote:
>>>>>>>>> The "summary" is unsupported by the HTML5 and we replace it
>> by
>>>>>>>>> invisible caption.
>>>>>>>>> These new styles are located in the stylesheet.css in the
>> root
>>> of
>>>>>>>>> the JavaDoc api folder, so I assume these styles should be
>> used
>>>>>>>>> by others as well.
>>>>>>>>> They were added by this fix:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8179479
>>>>>>>>>
>>>>>>>>> ----- philip.race at oracle.com wrote:
>>>>>>>>>
>>>>>>>>>> Does this in any way match the rest of the docs ? Or is
>>> everyone
>>>>>>>>>> left
>>>>>>>>>> to
>>>>>>>>>> style things how they want.
>>>>>>>>>> I thought (?) maybe there is to be some javadoc tool
>> support
>>> for
>>>>>>>>>> CSS
>>>>>>>>>> styles.
>>>>>>>>>>
>>>>>>>>>> Also why are all the table summaries removed ?
>>>>>>>>>>
>>>>>>>>>> -phil.
>>>>>>>>>>
>>>>>>>>>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>>>>>>>>>>> This is because I use the same style for most of the
>> tables
>>>>>>>>>> 'class="striped"', which apply the same/unified style for
>>>>>>>>>> all(most) of
>>>>>>>>>> our tables.
>>>>>>>>>>> Also this is because I removed 'inlined' styles, like
>> here:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
>>>>>>>>>>> ----- philip.race at oracle.com wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Adding 2d-dev because a number of the files are 2D.
>>>>>>>>>>>>
>>>>>>>>>>>> What is the general reason for changing the appearance of
>>> the
>>>>>>>>>> tables?
>>>>>>>>>>>> -phil.
>>>>>>>>>>>>
>>>>>>>>>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>> Please review the fix for jdk9-dev.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This fix is a part of the effort to make all javadoc in
>>> jdk9 be
>>>>>>>>>>>> compatible to HTML5.
>>>>>>>>>>>>> It covers all errors which are reported by the javadoc
>>> tool
>>>>>>>>>> during
>>>>>>>>>>>> the build of jdk for java.desktop module.
>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>>>>>>>>>>>> Webrev can be found at:
>>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>>>>>>>>>>>> Note that an appearance of some tables were changed
>> after
>>> the
>>>>>>>>>> fix:
>>>>>>>>>>>>> Before:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
>>>>>>>>>>>>> After:
>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html
>>>>>>>>>>>>> Before:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html
>>>>>>>>>>>>> After :
>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html
>>>>>>>>>>>>> Before:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html
>>>>>>>>>>>>> After:
>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html


From prasanta.sadhukhan at oracle.com  Mon Jun  5 05:46:34 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 5 Jun 2017 11:16:34 +0530
Subject: <Swing Dev> [10] RFR JDK-8181401: Error in Javadoc for
 JTabbedPane getAccessibleName()
In-Reply-To: <1612152f-6c77-42e0-8ad8-80241c7b6769@default>
References: <1612152f-6c77-42e0-8ad8-80241c7b6769@default>
Message-ID: <849692bb-3111-f0b6-0bf0-0c4fd3d12f99@oracle.com>

Since we are in RDP2 and can push javadoc fixes, I intend to push this 
to jdk9. webrev for jdk9 ws is

http://cr.openjdk.java.net/~psadhukhan/8181401/9/webrev.00/

Regards
Prasanta
On 6/2/2017 9:02 PM, Sergey Bylokhov wrote:
> Looks fine.
>
> ----- prasanta.sadhukhan at oracle.com wrote:
>
>> Hi All,
>>
>> Please review a javadoc fix where it seems the documentation for
>> JTabbedPane getAccessibleName() states "the accessible name of this
>> object, nor null."
>> Where is should be "the accessible name of this object, or null."
>> Modified javadoc to update the same.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8181401
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8181401/webrev.00/
>>
>> Regards
>> Prasanta



From prasanta.sadhukhan at oracle.com  Mon Jun  5 11:26:12 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 5 Jun 2017 16:56:12 +0530
Subject: <Swing Dev> [10] RFR JDK-8181421: 3 regtest fail on windows7 in
 Nimbus L&F
In-Reply-To: <7194c05f-f147-4df8-8947-7053a3d1d60b@default>
References: <7194c05f-f147-4df8-8947-7053a3d1d60b@default>
Message-ID: <0b293f12-e1ad-f439-00e7-e3811e3275c4@oracle.com>

Hi Sergey,


It seems when SynthPanel.updateStyle is called,

private void updateStyle(JPanel c) {
         SynthContext context = getContext(c, ENABLED);
         style = SynthLookAndFeel.updateStyle(context, this);
     }
it calls getContext() which in turn calls SynthContext.getContext() with 
style variable.
private SynthContext getContext(JComponent c, int state) {
         return SynthContext.getContext(c, style, state);
     }
Now, "style"  variable seems to be null at this point in 
SYnthPanelUI.java and
it only gets updated after getContext() call when it calls then next 
line SynthLookAndFeel.updateStyle(context, this);

I could not remove the html file as I am getting some serialization 
issue if I moved from applet to main based so I retained applet based 
test, as of now. Also, due to it being applet, I am not sure how to run 
them over installed l&f inside the test.

Modified webrev with test issues rectfied
http://cr.openjdk.java.net/~psadhukhan/8181421/webrev.01/

Regards
Prasanta
On 6/2/2017 1:35 AM, Sergey Bylokhov wrote:
> Hi, Prasanta.
> I have few small notes.
>  - Did you check why the null value was passed to this method?
>  - It seems that the tests are passed by default. It would be good to 
> run them over the installed l&f. In this case they will fail before 
> the fix.
>  - Is it possible to remove the html files from the tests?
>  - The tests also have some common issues, the Swing components are 
> accessed on non-edt thread. some unnecessary commented code, etc.
>
> ----- prasanta.sadhukhan at oracle.com wrote:
> >
>
> Hi All,
>
> Please review a subitem fix of JDK-7190554 
> <https://bugs.openjdk.java.net/browse/JDK-7190554> where some closed 
> regression test is failing with Nimbus L&F.
>
> Issue was we were getting NPE
> > which is because a null style was used in SynthPanelUI to generate 
> the SynthContext
> >
> > java.lang.NullPointerException: You must supply a non-null 
> component, region and style
> >     at 
> java.desktop/javax.swing.plaf.synth.SynthContext.getContext(SynthContext.java:58)
> >     at 
> java.desktop/javax.swing.plaf.synth.SynthContext.getContext(SynthContext.java:49)
> >     at 
> java.desktop/javax.swing.plaf.synth.SynthPanelUI.getContext(SynthPanelUI.java:128)
> >     at 
> java.desktop/javax.swing.plaf.synth.SynthPanelUI.updateStyle(SynthPanelUI.java:115)
> >     at 
> java.desktop/javax.swing.plaf.synth.SynthPanelUI.installDefaults(SynthPanelUI.java:100)
> >
> > Proposed fix is to generate a style before generating SynthContext 
> because as per spec,
> > 
> https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/plaf/synth/SynthContext.html
> > it should throw NPE||- if component, region or style is null.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8181421
> > webrev: http://cr.openjdk.java.net/~psadhukhan/8181421/webrev.00/
> >
> > Regards
> > Prasanta
> >

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

From sergey.bylokhov at oracle.com  Tue Jun  6 01:42:03 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 5 Jun 2017 18:42:03 -0700 (PDT)
Subject: <Swing Dev> [10] RFR JDK-8181401: Error in Javadoc for
 JTabbedPane getAccessibleName()
Message-ID: <06d17b8d-2206-43ea-907d-4261aeca9d76@default>

+1

----- prasanta.sadhukhan at oracle.com wrote:

> Since we are in RDP2 and can push javadoc fixes, I intend to push this
> 
> to jdk9. webrev for jdk9 ws is
> 
> http://cr.openjdk.java.net/~psadhukhan/8181401/9/webrev.00/
> 
> Regards
> Prasanta
> On 6/2/2017 9:02 PM, Sergey Bylokhov wrote:
> > Looks fine.
> >
> > ----- prasanta.sadhukhan at oracle.com wrote:
> >
> >> Hi All,
> >>
> >> Please review a javadoc fix where it seems the documentation for
> >> JTabbedPane getAccessibleName() states "the accessible name of
> this
> >> object, nor null."
> >> Where is should be "the accessible name of this object, or null."
> >> Modified javadoc to update the same.
> >>
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8181401
> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8181401/webrev.00/
> >>
> >> Regards
> >> Prasanta


From sergey.bylokhov at oracle.com  Tue Jun  6 02:55:55 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 5 Jun 2017 19:55:55 -0700
Subject: <Swing Dev> [10] RFR 6962725:Regtest
 javax/swing/JFileChooser/6738668/bug6738668.java fails under Linux
In-Reply-To: <4567ce5a-25e9-03d0-eba3-3e9bbd002a66@oracle.com>
References: <68eb1a2c-6ea1-4e32-81a7-4f094fce2e0e@default>
 <4567ce5a-25e9-03d0-eba3-3e9bbd002a66@oracle.com>
Message-ID: <4727D569-7625-4AFE-BF97-6BF0D643D7ED@oracle.com>

Thanks. The fix looks fine.

> 
> Thanks Sergey. I confirm new test fails with 7b40 in jtreg and pass with 9b170.
> 
> Regards
> Prasanta
> On 6/1/2017 9:12 PM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>> You should set a JT_JAVA environment variable to jdk8 or jdk9 before running jtreg:
>> http://openjdk.java.net/jtreg/runtests.html
>> 
>> This java will be used to start a jtreg itself. And for the test the java passed to "-jdk" will be used.
>> 
>> ----- prasanta.sadhukhan at oracle.com wrote:
>> 
>>> I could not run jdk7u40 build with my jtreg harness as it cites the
>>> below problem. I do not have jtreg older than 4.2b03, nor I could find
>>> 
>>> in jtreg site.
>>> 
>>> PRSADHUK-IN+prsadhuk at PRSADHUK-IN /cygdrive/c/jdk9/jtreg-42b03
>>> $ ./bin/jtreg -jdk:/cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/
>>> 
>>> /cygdrive/d/jdk7u/jdk7u-dev/jdk/test/javax/swing/JFileChooser/6738668/bug6738668.java
>>> java.lang.UnsupportedClassVersionError:
>>> com/sun/javatest/regtest/JDK$Fault : Unsupported major.minor version
>>> 52.0
>>>          at java.lang.ClassLoader.defineClass1(Native Method)
>>>          at java.lang.ClassLoader.defineClass(ClassLoader.java:642)
>>> 
>>> Regards
>>> Prasanta
>>> On 5/30/2017 10:28 PM, Sergey Bylokhov wrote:
>>>> The new version fails even if run via jtreg?
>>>> 
>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>> 
>>>>> OK. With revised command line, it fails with new updated test in
>>> 7b40
>>>>> and passed in 9b170
>>>>> 
>>>>> /cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/bin/java
>>>>> -Djava.security.manager -Djava.security.policy=security.policy
>>>>> bug6738668
>>>>> tmp dir C:\cygwin64\tmp\
>>>>> Exception in thread "main" java.security.AccessControlException:
>>>>> access
>>>>> denied (java.io.FilePermission
>>>>> C:\Users\prsadhuk\AppData\Roaming\Microsoft\Windows\Recent read)
>>>>>           at
>>>>> 
>>> java.security.AccessControlContext.checkPermission(AccessControlContext.java:345)
>>>>>           at
>>>>> 
>>> java.security.AccessController.checkPermission(AccessController.java:555)
>>>>>           at
>>>>> 
>>> java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
>>>>>           at
>>>>> java.lang.SecurityManager.checkRead(SecurityManager.java:888)
>>>>> 
>>>>> /cygdrive/d/Vbox_Shared/JDK/jdk9-b170/fastdebug/bin/java
>>>>> -Djava.security.manager -Djava.security.policy=security.policy
>>>>> bug6738668
>>>>> tmp dir C:\cygwin64\tmp\
>>>>> Test passed for LookAndFeel
>>> javax.swing.plaf.metal.MetalLookAndFeel
>>>>> tmp dir C:\cygwin64\tmp\
>>>>> Test passed for LookAndFeel
>>> javax.swing.plaf.nimbus.NimbusLookAndFeel
>>>>> tmp dir C:\cygwin64\tmp\
>>>>> Test passed for LookAndFeel
>>>>> com.sun.java.swing.plaf.motif.MotifLookAndFeel
>>>>> tmp dir C:\cygwin64\tmp\
>>>>> Test passed for LookAndFeel
>>>>> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>>>>> tmp dir C:\cygwin64\tmp\
>>>>> Test passed for LookAndFeel
>>>>> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
>>>>> 
>>>>> Regards
>>>>> Prasanta
>>>>> On 5/30/2017 2:59 AM, Sergey Bylokhov wrote:
>>>>>> I guess you will need to set security manager which will use your
>>>>> policy file:
>>>>> 
>>> https://docs.oracle.com/cd/E13222_01/wls/docs81b/secmanage/java.html
>>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>> 
>>>>>>> I am not sure why it is passing in my case. I thought it might
>>> be
>>>>>>> taking
>>>>>>> in some other security policy so I renamed and use a different
>>>>> named
>>>>>>> policy but it still passed in my windows 7.
>>>>>>> 
>>>>>>> $ /cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/bin/java
>>>>>>> -Djava.security.policy=my.policy bug6738668
>>>>>>> Test passed for LookAndFeel
>>>>> javax.swing.plaf.metal.MetalLookAndFeel
>>>>>>> Test passed for LookAndFeel
>>>>>>> com.sun.java.swing.plaf.motif.MotifLookAndFeel
>>>>>>> Test passed for LookAndFeel
>>>>>>> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>>>>>>> Test passed for LookAndFeel
>>>>>>> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
>>>>>>> 
>>>>>>> PRSADHUK-IN+prsadhuk at PRSADHUK-IN
>>>>>>> 
>>> /cygdrive/d/jdk10/client/jdk/test/javax/swing/JFileChooser/6738668
>>>>>>> $ cat my.policy
>>>>>>> grant {
>>>>>>>        permission java.io.FilePermission "C:\\temp\\*", "read";
>>>>>>>        permission java.io.FilePermission "C:\\temp", "read";
>>>>>>>        permission java.util.PropertyPermission "*", "read";
>>>>>>> };
>>>>>>> 
>>>>>>> PRSADHUK-IN+prsadhuk at PRSADHUK-IN
>>>>>>> 
>>> /cygdrive/d/jdk10/client/jdk/test/javax/swing/JFileChooser/6738668
>>>>>>> $ /cygdrive/d/Vbox_Shared/JDK/jdk1.7.0-b40/fastdebug/bin/java
>>>>>>> -version
>>>>>>> java version "1.7.0-ea-fastdebug"
>>>>>>> Java(TM) SE Runtime Environment (build 1.7.0-ea-fastdebug-b40)
>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 14.0-b07-fastdebug,
>>> mixed
>>>>>>> mode)
>>>>>>> 
>>>>>>> BTW, does my updated test fail in your environment with b40?
>>>>>>> 
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 5/28/2017 4:10 AM, Sergey Bylokhov wrote:
>>>>>>>> There is a comment that JDK-6738668 a regression of JDK-6484091
>>>>>>> which was pushed to b20.
>>>>>>>> I just checked the test from the command line on b40 and it
>>>>> fails,
>>>>>>> but passed on b55.
>>>>>>>> Can you please check why it was passed in your case.
>>>>>>>> 
>>>>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>>>> 
>>>>>>>>> Hi Sergey,
>>>>>>>>> 
>>>>>>>>> I do not see any comment mention about failure in 7b20 but
>>>>> anyways,
>>>>>>> I
>>>>>>>>> tried with 7b20,7b30,7b40,7b50 and all of them passed with
>>>>>>> original
>>>>>>>>> and
>>>>>>>>> updated test in windows.
>>>>>>>>> 
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>> On 5/25/2017 2:30 AM, Sergey Bylokhov wrote:
>>>>>>>>>> I am not sure but according to the comments of JDK-6738668 it
>>>>> was
>>>>>>> a
>>>>>>>>> regression in 7b20.
>>>>>>>>>> So I suggest to check a few build between b20 and b54
>>>>>>>>>> 
>>>>>>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>>>>>> 
>>>>>>>>>>> Hi Sergey,
>>>>>>>>>>> 
>>>>>>>>>>> No, it is passing. Actually, the original test is also
>>> passing
>>>>>>>>> with
>>>>>>>>>>> 1.7.0 b05 (6738668 is supposedly fixed in 7b55), there's no
>>>>>>>>>>> SecurityException
>>>>>>>>>>> 
>>>>>>>>>>> jdk1.7.0/bin/java -Djava.security.policy=security.policy
>>>>>>>>> bug6738668
>>>>>>>>>>> Test passed for LookAndFeel
>>>>>>>>> javax.swing.plaf.metal.MetalLookAndFeel
>>>>>>>>>>> Test passed for LookAndFeel
>>>>>>>>>>> com.sun.java.swing.plaf.motif.MotifLookAndFeel
>>>>>>>>>>> Test passed for LookAndFeel
>>>>>>>>>>> com.sun.java.swing.plaf.windows.WindowsLookAndFeel
>>>>>>>>>>> Test passed for LookAndFeel
>>>>>>>>>>> com.sun.java.swing.plaf.windows.WindowsClassicLookAndFeel
>>>>>>>>>>> 
>>>>>>>>>>> jdk1.7.0/bin/java -version
>>>>>>>>>>> java version "1.7.0-ea"
>>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b05)
>>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.7.0-ea-b05, mixed
>>>>>>> mode)
>>>>>>>>>>> Regards
>>>>>>>>>>> Prasanta
>>>>>>>>>>> On 5/24/2017 11:48 AM, Sergey Bylokhov wrote:
>>>>>>>>>>>> Hi, Prasanta.
>>>>>>>>>>>> Please confirm that the updated test fails before
>>> JDK-6738668
>>>>>>> was
>>>>>>>>>>> fixed.
>>>>>>>>>>>>> Hi ALl,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Please review a testbug fix for an issue where this
>>>>> regression
>>>>>>>>> test
>>>>>>>>>>> is failing in linux because
>>>>>>>>>>>>> JFileChooser was trying to access C:/temp path which does
>>>>> not
>>>>>>>>> exist
>>>>>>>>>>> in linux.
>>>>>>>>>>>>> Proposed fix is to use java.io.tmpdir instead of hardcoded
>>>>>>>>> windows
>>>>>>>>>>> path.
>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6962725
>>>>>>>>>>>>> webrev:
>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/6962725/webrev.00/
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>> Prasanta
> 



From prasanta.sadhukhan at oracle.com  Tue Jun  6 06:00:33 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 6 Jun 2017 11:30:33 +0530
Subject: <Swing Dev> [9] RFR: JDK-8181640 : Spelling mistake in javadoc:
 javax.swing.JEditorPane.scrollToReference(String)
Message-ID: <bf0887b3-da26-740c-4c03-5703d802832c@oracle.com>

Hi All,

Please review this javadoc fix where 
JEditorPane.scrollToReference(String) mention UL.getRef() whereas it 
should mention URL.getRef().
Rectified javadoc to update to correct reference.

Bug: https://bugs.openjdk.java.net/browse/JDK-8181640
webrev: http://cr.openjdk.java.net/~psadhukhan/8181640/webrev.00/

Regards
Prasanta


From sergey.bylokhov at oracle.com  Tue Jun  6 06:17:56 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 5 Jun 2017 23:17:56 -0700
Subject: <Swing Dev> [9] RFR: JDK-8181640 : Spelling mistake in javadoc:
 javax.swing.JEditorPane.scrollToReference(String)
In-Reply-To: <bf0887b3-da26-740c-4c03-5703d802832c@oracle.com>
References: <bf0887b3-da26-740c-4c03-5703d802832c@oracle.com>
Message-ID: <9E235072-3B00-4CF0-9714-4811A1576023@oracle.com>

Looks fine.

> 
> Hi All,
> 
> Please review this javadoc fix where JEditorPane.scrollToReference(String) mention UL.getRef() whereas it should mention URL.getRef().
> Rectified javadoc to update to correct reference.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8181640
> webrev: http://cr.openjdk.java.net/~psadhukhan/8181640/webrev.00/
> 
> Regards
> Prasanta



From shashidhara.veerabhadraiah at oracle.com  Tue Jun  6 06:34:59 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Mon, 5 Jun 2017 23:34:59 -0700 (PDT)
Subject: <Swing Dev> [9] JDK-8165213: [TESTBUG] [PIT] consistent failure of
 a new regtest for 8163193
Message-ID: <e5caac0a-b6b8-4b02-9a3e-ece26162d3ef@default>

Hi All,
	Please review fix for JDK-8165213 where there is a consistent failure while testing for gradient color of the button.

Issue: The Robot's function to get the pixel's RGB values has an issue with its implementation and is currently getting resolved. Because of this issue, we are getting incorrect RGB values for the requested pixel and hence the test is getting failed.

Resolution\Fix: There is an alternate mechanism to capture the image to a buffer and use the buffer function to get the RGB values. This test is for HiDpi displays. In the image space, the images won't be scaled implicitly and hence they need to be applied with the scaling in the graphics space before painting on to the image buffer. This same is implemented.
Based on the test outputs, the tolerance band for color comparison is set at 11.

Test outputs: 
1. On a windows system, the pixel color values exactly matches.
2. On a Linux system, the pixel color values vary by a maximum difference of around 6.
3. On a mac system, the pixel color values vary by a maximum difference of around 10.

Bug: https://bugs.openjdk.java.net/browse/JDK-8165213
Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/8165213/webrev_01/

Thanks and regards,
Shashi


From prasanta.sadhukhan at oracle.com  Tue Jun  6 07:44:37 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 6 Jun 2017 13:14:37 +0530
Subject: <Swing Dev> [9] JDK-8165213: [TESTBUG] [PIT] consistent failure
 of a new regtest for 8163193
In-Reply-To: <e5caac0a-b6b8-4b02-9a3e-ece26162d3ef@default>
References: <e5caac0a-b6b8-4b02-9a3e-ece26162d3ef@default>
Message-ID: <6d82242f-f59e-cff5-3f94-666a1447a666@oracle.com>

Do you know the JBS bugid of Robot's issue that is being resolved?
I guess you need to call g2d.dispose() in printToBufferedImage() and can 
replace the wild card imports into specific imports. Also, take care of 
80characters per line.

Regards
Prasa
On 6/6/2017 12:04 PM, Shashidhara Veerabhadraiah wrote:
> Hi All,
> 	Please review fix for JDK-8165213 where there is a consistent failure while testing for gradient color of the button.
>
> Issue: The Robot's function to get the pixel's RGB values has an issue with its implementation and is currently getting resolved. Because of this issue, we are getting incorrect RGB values for the requested pixel and hence the test is getting failed.
>
> Resolution\Fix: There is an alternate mechanism to capture the image to a buffer and use the buffer function to get the RGB values. This test is for HiDpi displays. In the image space, the images won't be scaled implicitly and hence they need to be applied with the scaling in the graphics space before painting on to the image buffer. This same is implemented.
> Based on the test outputs, the tolerance band for color comparison is set at 11.
>
> Test outputs:
> 1. On a windows system, the pixel color values exactly matches.
> 2. On a Linux system, the pixel color values vary by a maximum difference of around 6.
> 3. On a mac system, the pixel color values vary by a maximum difference of around 10.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8165213
> Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/8165213/webrev_01/
>
> Thanks and regards,
> Shashi



From prasanta.sadhukhan at oracle.com  Tue Jun  6 08:17:54 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 6 Jun 2017 13:47:54 +0530
Subject: <Swing Dev> [10] RFR: JDK-8075918:The regression-swing case
 failed as the long Tab titles are not clipped with dots at the end with
 NimbusLookAndFeel
In-Reply-To: <a4a1ae6b-2d1c-4d99-abcf-e2a3cd24659d@default>
References: <a4a1ae6b-2d1c-4d99-abcf-e2a3cd24659d@default>
Message-ID: <27bb815b-ba6c-0b06-7cc2-a84fc38d8b57@oracle.com>

Please find the modified webrev incorporating your review comment

http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.04/

Regards
Prasanta
On 6/2/2017 12:33 AM, Sergey Bylokhov wrote:
>   - There is a problem in your algorithm which merges the old and new clips. The getClipBounds() returns a rectangle which is a bounds of the current clip(which is not necessary a rectangle but can be a shape). you can use the Graphics2D.clip(Shape) method which will intersect the passed shape and a current clip of the graphics.
>   - In this version you forgot to restore the changed clip.
>   - Also can you try to move the code which change a clip to the methods which currently ignore the passed clip(see below):
>>>> BasicTabbedPaneUI.paintIcon() as well as
>>>> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>>>>    - paintText() at line 681
>>>>    - paintIcon() at line 634
>>>> Both methods have a rectangle as a parameter, but it is ignored.
>
> ----- prasanta.sadhukhan at oracle.com wrote:
>
>> I tried to incorporate your comments. Please find modified webrev
>>
>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.03/
>>
>> Regards
>> Prasanta
>> On 5/28/2017 8:01 AM, Sergey Bylokhov wrote:
>>> Note that you shouldn't replace the clip, but should apply the new
>> clip on top of the old. This is necessary if the old clip is smaller
>> than new.
>>> ----- sergey.bylokhov at oracle.com wrote:
>>>
>>>> Hi, Prasanta.
>>>>
>>>> BasicTabbedPaneUI.paintIcon() as well as
>>>> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>>>>    - paintText() at line 681
>>>>    - paintIcon() at line 634
>>>> Both methods have a rectangle as a parameter, but it is ignored.
>>>>
>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>
>>>>> Hi Sergey,
>>>>>
>>>>> I could get your concern for paintText() but could not find
>>>>> paintIcon()
>>>>> in SynthGraphicsUtils() so not sure how icon drawing contradicts
>>>>> spec.
>>>>> Modified webrev:
>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/
>>>>>
>>>>> Also, if we are not calling
>> SwingUtilities2.clipStringIfNecessary()
>>>>> then
>>>>> we are not going to get "..." at the end which this test expects.
>>>> But
>>>>> I
>>>>> could not find anything in spec, that mandates ending with "..."
>> for
>>>>> long tab outside
>>>>> tab bounds. If source change is ok, I guess we then need to
>> modify
>>>> the
>>>>> html file modifying the expected result for NimbusL&F.
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 5/25/2017 3:11 AM, Sergey Bylokhov wrote:
>>>>>> Hi, Prasanta.
>>>>>> Please take a look to my comments at:
>>>>>>
>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html
>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html
>>>>>> The two methods paintText() and paintIcon() are contradict the
>>>> spec
>>>>> and draw the text and icons outside of the tab.
>>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Please review a fix for an issue where long Tab titiles are not
>>>>>>> clipped
>>>>>>> with dots at end for NimbusLookAndFeel L&F.
>>>>>>> Other L&Fs works ok.
>>>>>>>
>>>>>>> Issue was in SynthTabbedPaneUI#paintTab(), the title is not
>>>>> clipped
>>>>>>> but
>>>>>>> passed to paintText() as it is received.
>>>>>>> Other L&F such as Metal, Motif, Windows which uses
>>>>>>> BasicTabbedPaneUI#paintTab(), the title is clipped
>>>>>>>
>> http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950
>>>>>>> before it is passed to paintText().
>>>>>>>
>>>>>>> Proposed fix is to do the same for
>> SynthTabbedPaneUI#paintTab().
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075918
>>>>>>> webrev:
>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/
>>>>>>> Regards
>>>>>>> Prasanta



From shashidhara.veerabhadraiah at oracle.com  Tue Jun  6 09:22:11 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Tue, 6 Jun 2017 02:22:11 -0700 (PDT)
Subject: <Swing Dev> [9] JDK-8165213: [TESTBUG] [PIT] consistent failure
 of a new regtest for 8163193
In-Reply-To: <6d82242f-f59e-cff5-3f94-666a1447a666@oracle.com>
References: <e5caac0a-b6b8-4b02-9a3e-ece26162d3ef@default>
 <6d82242f-f59e-cff5-3f94-666a1447a666@oracle.com>
Message-ID: <0d6a4926-1ae5-4896-975c-4555d5672f63@default>

Hi, I have updated the Webrev with fixes for the comments @ http://cr.openjdk.java.net/~pkbalakr/shashi/8165213/webrev_02/.

Prasanth, I am not aware of the JBS id where this issue is going to be fixed.

Thanks and regards,
Shashi

-----Original Message-----
From: Prasanta Sadhukhan 
Sent: Tuesday, June 6, 2017 1:15 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; swing-dev at openjdk.java.net; Sergey Bylokhov <sergey.bylokhov at oracle.com>
Subject: Re: [9] JDK-8165213: [TESTBUG] [PIT] consistent failure of a new regtest for 8163193

Do you know the JBS bugid of Robot's issue that is being resolved?
I guess you need to call g2d.dispose() in printToBufferedImage() and can replace the wild card imports into specific imports. Also, take care of 80characters per line.

Regards
Prasa
On 6/6/2017 12:04 PM, Shashidhara Veerabhadraiah wrote:
> Hi All,
> 	Please review fix for JDK-8165213 where there is a consistent failure while testing for gradient color of the button.
>
> Issue: The Robot's function to get the pixel's RGB values has an issue with its implementation and is currently getting resolved. Because of this issue, we are getting incorrect RGB values for the requested pixel and hence the test is getting failed.
>
> Resolution\Fix: There is an alternate mechanism to capture the image to a buffer and use the buffer function to get the RGB values. This test is for HiDpi displays. In the image space, the images won't be scaled implicitly and hence they need to be applied with the scaling in the graphics space before painting on to the image buffer. This same is implemented.
> Based on the test outputs, the tolerance band for color comparison is set at 11.
>
> Test outputs:
> 1. On a windows system, the pixel color values exactly matches.
> 2. On a Linux system, the pixel color values vary by a maximum difference of around 6.
> 3. On a mac system, the pixel color values vary by a maximum difference of around 10.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8165213
> Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/8165213/webrev_01/
>
> Thanks and regards,
> Shashi



From prasanta.sadhukhan at oracle.com  Tue Jun  6 09:37:38 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 6 Jun 2017 15:07:38 +0530
Subject: <Swing Dev> [9] JDK-8165213: [TESTBUG] [PIT] consistent failure
 of a new regtest for 8163193
In-Reply-To: <0d6a4926-1ae5-4896-975c-4555d5672f63@default>
References: <e5caac0a-b6b8-4b02-9a3e-ece26162d3ef@default>
 <6d82242f-f59e-cff5-3f94-666a1447a666@oracle.com>
 <0d6a4926-1ae5-4896-975c-4555d5672f63@default>
Message-ID: <a2046608-33d1-8db0-faba-0ec2e24c33bd@oracle.com>

Looks better. One more thing, out of these lines, only frame.paint() 
needs to be in EDT as it is a swing component but in your code, all code 
are running under EDT which is not needed.

113
114 // Capture the frame to an buffered image file as an ARGB file
115 bi = new BufferedImage(300 * (int)(tx.getScaleX()),
116 300 * (int)(tx.getScaleY()), BufferedImage.TYPE_INT_ARGB);
117
118 // Print the frame to buffered image
119 printToBufferedImage();
120 }
121
122 private static void printToBufferedImage() {
123 Graphics2D g2d = bi.createGraphics();
124
125 // Set to the new transform as set by HiDpi display units.
126 g2d.setTransform(tx);
127 g2d.drawImage(bi, null, null);
128
129 // paint the buffered image with the newly created frame
130 frame.paint(g2d);
131 g2d.dispose();
  132     }

Regards
Prasanta
On 6/6/2017 2:52 PM, Shashidhara Veerabhadraiah wrote:
> Hi, I have updated the Webrev with fixes for the comments @ http://cr.openjdk.java.net/~pkbalakr/shashi/8165213/webrev_02/.
>
> Prasanth, I am not aware of the JBS id where this issue is going to be fixed.
>
> Thanks and regards,
> Shashi
>
> -----Original Message-----
> From: Prasanta Sadhukhan
> Sent: Tuesday, June 6, 2017 1:15 PM
> To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; swing-dev at openjdk.java.net; Sergey Bylokhov <sergey.bylokhov at oracle.com>
> Subject: Re: [9] JDK-8165213: [TESTBUG] [PIT] consistent failure of a new regtest for 8163193
>
> Do you know the JBS bugid of Robot's issue that is being resolved?
> I guess you need to call g2d.dispose() in printToBufferedImage() and can replace the wild card imports into specific imports. Also, take care of 80characters per line.
>
> Regards
> Prasa
> On 6/6/2017 12:04 PM, Shashidhara Veerabhadraiah wrote:
>> Hi All,
>> 	Please review fix for JDK-8165213 where there is a consistent failure while testing for gradient color of the button.
>>
>> Issue: The Robot's function to get the pixel's RGB values has an issue with its implementation and is currently getting resolved. Because of this issue, we are getting incorrect RGB values for the requested pixel and hence the test is getting failed.
>>
>> Resolution\Fix: There is an alternate mechanism to capture the image to a buffer and use the buffer function to get the RGB values. This test is for HiDpi displays. In the image space, the images won't be scaled implicitly and hence they need to be applied with the scaling in the graphics space before painting on to the image buffer. This same is implemented.
>> Based on the test outputs, the tolerance band for color comparison is set at 11.
>>
>> Test outputs:
>> 1. On a windows system, the pixel color values exactly matches.
>> 2. On a Linux system, the pixel color values vary by a maximum difference of around 6.
>> 3. On a mac system, the pixel color values vary by a maximum difference of around 10.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8165213
>> Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/8165213/webrev_01/
>>
>> Thanks and regards,
>> Shashi

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

From alexander.zvegintsev at oracle.com  Tue Jun  6 09:55:47 2017
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 6 Jun 2017 15:25:47 +0530
Subject: <Swing Dev> <Sound Dev> [9] Review Request: 8180326 Update the
 tables in java.desktop to be HTML-5 friendly
In-Reply-To: <4f6a1420-831d-4b6c-946c-05e770cb2f14@default>
References: <4f6a1420-831d-4b6c-946c-05e770cb2f14@default>
Message-ID: <1e7d4767-b747-cb0f-10ec-b1bd916d911f@oracle.com>

Hi Sergey,

Why do we omitting closing th tag?

e.g.

+ * <caption>Metal's system color mapping</caption>
+ * <thead>
+ * <tr>
+ * <th>Key
+ * <th>Value
+ * </thead>

I know that HTML parsers are usually forgiving such things. But 
sometimes it may make thing worse:

https://stackoverflow.com/questions/7125354/what-are-the-actual-problems-of-not-closing-tags-and-attributes-in-html/7135378#7135378

Thanks,
Alexander.

On 05/06/2017 06:23, Sergey Bylokhov wrote:
> If there are no objections I'll change the target ws from dev to client, to minimize the merges between some other javadoc fixes.
>
> ----- sergey.bylokhov at oracle.com wrote:
>
>> Hello.
>> Here is an updated version where most of the caption are visible.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>> Webrev can be found at:
>> http://cr.openjdk.java.net/~serb/8180326/webrev.02/
>> Specdiff:
>> http://cr.openjdk.java.net/~serb/8180326/specdiff.02/overview-summary.html
>>
>> You can use search to check the changes in some specific class:
>> Old docs:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.02/overview-summary.html
>> New docs:
>> http://cr.openjdk.java.net/~serb/8180326/api.02/overview-summary.html
>>
>>
>> ----- jonathan.gibbons at oracle.com wrote:
>>
>>> Phil,
>>>
>>> I have no evidence one way or the other whether screen readers pay
>>> attention
>>> to undisplayed or invisible captions. It seemed safest to assume
>> that
>>> they would
>>> read a visible caption, and that we should head in that general
>>> direction.
>>>
>>> -- Jon
>>>
>>>
>>> On 05/17/2017 11:58 AM, Phil Race wrote:
>>>> And PS I was not saying anything to contradict
>>>>> tables should not have a summary attribute and should have a
>>> caption.
>>>> However that the docs I read on the web did seem to imply that
>>>> summary was very much intended for ATs but it was not at all
>> clear
>>> this
>>>> is the point of caption. I'm sure they can read it, but I don't
>> get
>>>> how making
>>>> it visible matters to them so how it making it visible relates to
>>>> accessibility
>>>> requirements is not an obvious connection to me. So why do we
>> have
>>>> to make it visible for ATs ?
>>>>
>>>> -phil.
>>>>
>>>> On 05/17/2017 11:54 AM, Phil Race wrote:
>>>>> I will leave the decision on whether to do that now up to Sergey
>>>>> although
>>>>> it seems all he has to do here is remove "invisible".
>>>>> Many of the "summary" ones had wrong or misleading text but they
>>>>> seem to have been all fixed.
>>>>>
>>>>> I'd want to see what the new HTML looks like with a visible
>> title
>>> of
>>>>> course ..
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 05/17/2017 11:52 AM, Jonathan Gibbons wrote:
>>>>>> Phil,
>>>>>>
>>>>>> The bottom line is that in the JDK docs, tables should not have
>> a
>>>>>> summary attribute and should have a caption. This comes down to
>>>>>> accessibility requirements, where we are slowly raising the bar
>> on
>>>>>> our docs, to be in accordance with Oracle's guidelines.
>>>>>>
>>>>>> Hiding the caption (style="display:none") is an interim measure
>> we
>>>>>> have been using during the HTML 5 updates, especially in cases
>>> where
>>>>>> the person doing the markup changes did not know enough to
>> create
>>> an
>>>>>> appropriate caption that should be displayed. In time, we should
>>>>>> locate and update all table captions (in our standard docs
>> bundle)
>>>>>> that are not being displayed such that the text is both
>>> appropriate
>>>>>> and visible. If you guys want to do that as part of this
>> update,
>>> go
>>>>>> ahead. FWIW, that is what we did for the java.xml module in the
>>> jaxp
>>>>>> repo ... pretty much all tables there now have a reasonable,
>>> visible
>>>>>> caption.
>>>>>>
>>>>>> -- Jon
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 05/17/2017 11:19 AM, Phil Race wrote:
>>>>>>> I am not sure we are using the summary in a way that makes it
>>>>>>> worthwhile.
>>>>>>> As you noted in the other mail
>>>>>>> "The summary attribute was used to give a more descriptive
>> value
>>>>>>> of the contents of the table.   A caption is more like a
>> title"
>>>>>>> The values I see are more like a title and as you say that is
>> not
>>>>>>> the idea. See the example here
>>>>>>>
>>>>>>> https://www.w3.org/TR/WCAG20-TECHS/H73.html
>>>>>>>
>>>>>>> Caption sounds like a title so it might actually be more
>>>>>>> appropriate than summary
>>>>>>> for the text we have except that its not clear why we'd want
>> it
>>> to
>>>>>>> be visible when we were fine without.
>>>>>>>
>>>>>>> But being there and invisible may be pointless unless screen
>>>>>>> readers look for it even if invisible.
>>>>>>>
>>>>>>> But if its not doing any harm I guess we can leave it as
>>> proposed
>>>>>>> I still need to look at the rest of the changes.
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>> On 05/12/2017 05:11 PM, Jonathan Gibbons wrote:
>>>>>>>> Sergey,
>>>>>>>>
>>>>>>>> FWIW, the invisible caption should be regarded as a temporary
>>>>>>>> solution, until content authors can review/update the text of
>>> the
>>>>>>>> caption and make it visible.
>>>>>>>>
>>>>>>>> The general guideline in this conversion work has been to
>> avoid
>>>>>>>> changing the visible text of the specification, and captions
>>> fall
>>>>>>>> into a grey area of whether the text is significant/normative
>> or
>>>>>>>> not.  Hence the temporary step to make them not displayed for
>>> now.
>>>>>>>> -- Jon
>>>>>>>>
>>>>>>>> On 05/12/2017 05:00 PM, Sergey Bylokhov wrote:
>>>>>>>>> The "summary" is unsupported by the HTML5 and we replace it
>> by
>>>>>>>>> invisible caption.
>>>>>>>>> These new styles are located in the stylesheet.css in the
>> root
>>> of
>>>>>>>>> the JavaDoc api folder, so I assume these styles should be
>> used
>>>>>>>>> by others as well.
>>>>>>>>> They were added by this fix:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8179479
>>>>>>>>>
>>>>>>>>> ----- philip.race at oracle.com wrote:
>>>>>>>>>
>>>>>>>>>> Does this in any way match the rest of the docs ? Or is
>>> everyone
>>>>>>>>>> left
>>>>>>>>>> to
>>>>>>>>>> style things how they want.
>>>>>>>>>> I thought (?) maybe there is to be some javadoc tool
>> support
>>> for
>>>>>>>>>> CSS
>>>>>>>>>> styles.
>>>>>>>>>>
>>>>>>>>>> Also why are all the table summaries removed ?
>>>>>>>>>>
>>>>>>>>>> -phil.
>>>>>>>>>>
>>>>>>>>>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>>>>>>>>>>> This is because I use the same style for most of the
>> tables
>>>>>>>>>> 'class="striped"', which apply the same/unified style for
>>>>>>>>>> all(most) of
>>>>>>>>>> our tables.
>>>>>>>>>>> Also this is because I removed 'inlined' styles, like
>> here:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
>>>>>>>>>>> ----- philip.race at oracle.com wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Adding 2d-dev because a number of the files are 2D.
>>>>>>>>>>>>
>>>>>>>>>>>> What is the general reason for changing the appearance of
>>> the
>>>>>>>>>> tables?
>>>>>>>>>>>> -phil.
>>>>>>>>>>>>
>>>>>>>>>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>> Please review the fix for jdk9-dev.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This fix is a part of the effort to make all javadoc in
>>> jdk9 be
>>>>>>>>>>>> compatible to HTML5.
>>>>>>>>>>>>> It covers all errors which are reported by the javadoc
>>> tool
>>>>>>>>>> during
>>>>>>>>>>>> the build of jdk for java.desktop module.
>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>>>>>>>>>>>> Webrev can be found at:
>>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>>>>>>>>>>>> Note that an appearance of some tables were changed
>> after
>>> the
>>>>>>>>>> fix:
>>>>>>>>>>>>> Before:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
>>>>>>>>>>>>> After:
>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html
>>>>>>>>>>>>> Before:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html
>>>>>>>>>>>>> After :
>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html
>>>>>>>>>>>>> Before:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html
>>>>>>>>>>>>> After:
>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html

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

From shashidhara.veerabhadraiah at oracle.com  Tue Jun  6 15:24:53 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Tue, 6 Jun 2017 08:24:53 -0700 (PDT)
Subject: <Swing Dev> [9] JDK-8165213: [TESTBUG] [PIT] consistent failure
 of a new regtest for 8163193
In-Reply-To: <a2046608-33d1-8db0-faba-0ec2e24c33bd@oracle.com>
References: <e5caac0a-b6b8-4b02-9a3e-ece26162d3ef@default>
 <6d82242f-f59e-cff5-3f94-666a1447a666@oracle.com>
 <0d6a4926-1ae5-4896-975c-4555d5672f63@default>
 <a2046608-33d1-8db0-faba-0ec2e24c33bd@oracle.com>
Message-ID: <aa666916-a7fb-4b25-97e0-0ef389cf9ddf@default>

I checked with isEventDispatchThread() java api on the program and found that it is not running on EDT but running on the initial thread!! Is it really required to run the frame paint on the EDT as it is not a responsive GUI(non-event based) but an automatic test case to capture the image onto a buffer?

Thanks and regards,
Shashi

From: Prasanta Sadhukhan 
Sent: Tuesday, June 6, 2017 3:08 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; swing-dev at openjdk.java.net; Sergey Bylokhov <sergey.bylokhov at oracle.com>
Subject: Re: [9] JDK-8165213: [TESTBUG] [PIT] consistent failure of a new regtest for 8163193

Looks better. One more thing, out of these lines, only frame.paint() needs to be in EDT as it is a swing component but in your code, all code are running under EDT which is not needed.
113 
 114         // Capture the frame to an buffered image file as an ARGB file
 115         bi = new BufferedImage(300 * (int)(tx.getScaleX()),
 116                 300 * (int)(tx.getScaleY()), BufferedImage.TYPE_INT_ARGB);
 117 
 118         // Print the frame to buffered image
 119         printToBufferedImage();
 120     }
 121 
 122     private static void printToBufferedImage() {
 123         Graphics2D g2d = bi.createGraphics();
 124 
 125         // Set to the new transform as set by HiDpi display units.
 126         g2d.setTransform(tx);
 127         g2d.drawImage(bi, null, null);
 128 
 129         // paint the buffered image with the newly created frame
 130         frame.paint(g2d);
 131         g2d.dispose();
 132     }
Regards
Prasanta
On 6/6/2017 2:52 PM, Shashidhara Veerabhadraiah wrote:
Hi, I have updated the Webrev with fixes for the comments @ http://cr.openjdk.java.net/~pkbalakr/shashi/8165213/webrev_02/.

Prasanth, I am not aware of the JBS id where this issue is going to be fixed.

Thanks and regards,
Shashi

-----Original Message-----
From: Prasanta Sadhukhan 
Sent: Tuesday, June 6, 2017 1:15 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; swing-dev at openjdk.java.net; Sergey Bylokhov <sergey.bylokhov at oracle.com>
Subject: Re: [9] JDK-8165213: [TESTBUG] [PIT] consistent failure of a new regtest for 8163193

Do you know the JBS bugid of Robot's issue that is being resolved?
I guess you need to call g2d.dispose() in printToBufferedImage() and can replace the wild card imports into specific imports. Also, take care of 80characters per line.

Regards
Prasa
On 6/6/2017 12:04 PM, Shashidhara Veerabhadraiah wrote:
Hi All,
	Please review fix for JDK-8165213 where there is a consistent failure while testing for gradient color of the button.

Issue: The Robot's function to get the pixel's RGB values has an issue with its implementation and is currently getting resolved. Because of this issue, we are getting incorrect RGB values for the requested pixel and hence the test is getting failed.

Resolution\Fix: There is an alternate mechanism to capture the image to a buffer and use the buffer function to get the RGB values. This test is for HiDpi displays. In the image space, the images won't be scaled implicitly and hence they need to be applied with the scaling in the graphics space before painting on to the image buffer. This same is implemented.
Based on the test outputs, the tolerance band for color comparison is set at 11.

Test outputs:
1. On a windows system, the pixel color values exactly matches.
2. On a Linux system, the pixel color values vary by a maximum difference of around 6.
3. On a mac system, the pixel color values vary by a maximum difference of around 10.

Bug: https://bugs.openjdk.java.net/browse/JDK-8165213
Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/8165213/webrev_01/

Thanks and regards,
Shashi



From prasanta.sadhukhan at oracle.com  Wed Jun  7 08:10:59 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 7 Jun 2017 13:40:59 +0530
Subject: <Swing Dev> [10] RFR: JDK-7020860: BasicTreeUI contains
 getters/setters with unclear spec
Message-ID: <b70fd389-56b8-176f-4878-0d9d5d3da293@oracle.com>

Hi All,

This is a revisit of update in BasicTreeUI spec. It is same as previous 
webrev with only modification of isRootVisible() as per the comments 
posted last time.
ccc also seemed to be approved.
Bug: https://bugs.openjdk.java.net/browse/JDK-7020860
webrev: http://cr.openjdk.java.net/~psadhukhan/7020860/webrev.00/

Regards
Prasanta



From sergey.bylokhov at oracle.com  Wed Jun  7 17:52:57 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 7 Jun 2017 10:52:57 -0700 (PDT)
Subject: <Swing Dev> <Sound Dev> [9] Review Request: 8180326 Update the
 tables in java.desktop to be HTML-5 friendly
Message-ID: <975b438a-ad3e-4e1d-bb41-518ba4f9017b@default>

Hi, Alexander. 
These closing tags are optional in html5 standard [1]. On the link to the SO there are three the example which work differently but according standards[2][3][4]. 

[1] https://www.w3.org/TR/html5/syntax.html#syntax-tag-omission 

[2] http://jsfiddle.net/robertc/rNv93/1/ 
[3] http://jsfiddle.net/UqzEp/2/ 
[4] http://jsfiddle.net/UqzEp/3/ 

----- alexander.zvegintsev at oracle.com wrote: 
> 


Hi Sergey, 
> 

Why do we omitting closing th tag? 
> 

e.g. 
> 

+     * <caption>Metal's system color mapping</caption> +     * <thead> +     *  <tr> +     *    <th>Key +     *    <th>Value +     * </thead> 

I know that HTML parsers are usually forgiving such things. But sometimes it may make thing worse: 
> 

https://stackoverflow.com/questions/7125354/what-are-the-actual-problems-of-not-closing-tags-and-attributes-in-html/7135378#7135378 

Thanks,
Alexander. 
> On 05/06/2017 06:23, Sergey Bylokhov wrote: 
> 

If there are no objections I'll change the target ws from dev to client, to minimize the merges between some other javadoc fixes.

----- sergey.bylokhov at oracle.com wrote: 

Hello.
Here is an updated version where most of the caption are visible.
Bug: https://bugs.openjdk.java.net/browse/JDK-8180326 Webrev can be found at: http://cr.openjdk.java.net/~serb/8180326/webrev.02/ Specdiff: http://cr.openjdk.java.net/~serb/8180326/specdiff.02/overview-summary.html You can use search to check the changes in some specific class:
Old docs: http://cr.openjdk.java.net/~serb/8180326/api_old.02/overview-summary.html New docs: http://cr.openjdk.java.net/~serb/8180326/api.02/overview-summary.html ----- jonathan.gibbons at oracle.com wrote: 

Phil,

I have no evidence one way or the other whether screen readers pay 
attention
to undisplayed or invisible captions. It seemed safest to assume that 

they would
read a visible caption, and that we should head in that general
direction.

-- Jon


On 05/17/2017 11:58 AM, Phil Race wrote: 

And PS I was not saying anything to contradict 

tables should not have a summary attribute and should have a caption. 

However that the docs I read on the web did seem to imply that
summary was very much intended for ATs but it was not at all clear 

this 

is the point of caption. I'm sure they can read it, but I don't get 



how making
it visible matters to them so how it making it visible relates to 



accessibility
requirements is not an obvious connection to me. So why do we have 



to make it visible for ATs ?

-phil.

On 05/17/2017 11:54 AM, Phil Race wrote: 

I will leave the decision on whether to do that now up to Sergey 





although
it seems all he has to do here is remove "invisible".
Many of the "summary" ones had wrong or misleading text but they
seem to have been all fixed.

I'd want to see what the new HTML looks like with a visible title 

of 



course ..

-phil.

On 05/17/2017 11:52 AM, Jonathan Gibbons wrote: 

Phil,

The bottom line is that in the JDK docs, tables should not have a 







summary attribute and should have a caption. This comes down to 







accessibility requirements, where we are slowly raising the bar on 







our docs, to be in accordance with Oracle's guidelines.

Hiding the caption (style="display:none") is an interim measure we 







have been using during the HTML 5 updates, especially in cases where 





the person doing the markup changes did not know enough to create 

an 





appropriate caption that should be displayed. In time, we should 







locate and update all table captions (in our standard docs bundle) 







that are not being displayed such that the text is both appropriate 





and visible. If you guys want to do that as part of this update, 

go 





ahead. FWIW, that is what we did for the java.xml module in the jaxp 





repo ... pretty much all tables there now have a reasonable, visible 





caption.

-- Jon



On 05/17/2017 11:19 AM, Phil Race wrote: 

I am not sure we are using the summary in a way that makes it 
worthwhile.
As you noted in the other mail
"The summary attribute was used to give a more descriptive value 









of the contents of the table.   A caption is more like a title" 









The values I see are more like a title and as you say that is not 









the idea. See the example here https://www.w3.org/TR/WCAG20-TECHS/H73.html Caption sounds like a title so it might actually be more 
appropriate than summary
for the text we have except that its not clear why we'd want it 

to 







be visible when we were fine without.

But being there and invisible may be pointless unless screen 
readers look for it even if invisible.

But if its not doing any harm I guess we can leave it as proposed 







I still need to look at the rest of the changes.

-phil.

On 05/12/2017 05:11 PM, Jonathan Gibbons wrote: 

Sergey,

FWIW, the invisible caption should be regarded as a temporary 











solution, until content authors can review/update the text of the 









caption and make it visible.

The general guideline in this conversion work has been to avoid 











changing the visible text of the specification, and captions fall 









into a grey area of whether the text is significant/normative or 











not.  Hence the temporary step to make them not displayed for now. 









-- Jon

On 05/12/2017 05:00 PM, Sergey Bylokhov wrote: 

The "summary" is unsupported by the HTML5 and we replace it by 













invisible caption.
These new styles are located in the stylesheet.css in the root 

of 











the JavaDoc api folder, so I assume these styles should be used 













by others as well.
They were added by this fix: https://bugs.openjdk.java.net/browse/JDK-8179479 ----- philip.race at oracle.com wrote: 

Does this in any way match the rest of the docs ? Or is everyone 













left
to
style things how they want.
I thought (?) maybe there is to be some javadoc tool support 

for 













CSS
styles.

Also why are all the table summaries removed ?

-phil.

On 5/12/17, 4:52 PM, Sergey Bylokhov wrote: 

This is because I use the same style for most of the tables 















'class="striped"', which apply the same/unified style for 
all(most) of
our tables. 

Also this is because I removed 'inlined' styles, like here: 

















http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 

















----- philip.race at oracle.com wrote: 

Adding 2d-dev because a number of the files are 2D.

What is the general reason for changing the appearance of the 













tables? 



-phil.

On 5/12/17, 4:25 PM, Sergey Bylokhov wrote: 

Hello,
Please review the fix for jdk9-dev.

This fix is a part of the effort to make all javadoc in jdk9 be 

















compatible to HTML5. 

It covers all errors which are reported by the javadoc tool 













during 



the build of jdk for java.desktop module. 

Bug: https://bugs.openjdk.java.net/browse/JDK-8180326 Webrev can be found at: http://cr.openjdk.java.net/~serb/8180326/webrev.01 

Note that an appearance of some tables were changed after 

the 













fix: 





Before: http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 





















After: http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html 





















Before: http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html 





















After : http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html 





















Before: http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html 





















After: http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html 
















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

From alexander.zvegintsev at oracle.com  Thu Jun  8 04:22:25 2017
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 8 Jun 2017 09:52:25 +0530
Subject: <Swing Dev> <Sound Dev> [9] Review Request: 8180326 Update the
 tables in java.desktop to be HTML-5 friendly
In-Reply-To: <975b438a-ad3e-4e1d-bb41-518ba4f9017b@default>
References: <975b438a-ad3e-4e1d-bb41-518ba4f9017b@default>
Message-ID: <ad507f33-67ce-4036-8a0f-841f6cd100a0@oracle.com>

Thanks for clarification, looks good to me.

Thanks,
Alexander.

On 07/06/2017 23:22, Sergey Bylokhov wrote:
> Hi, Alexander.
> These closing tags are optional in html5 standard [1]. On the link to 
> the SO there are three the example which work differently but 
> according standards[2][3][4].
>
> [1] https://www.w3.org/TR/html5/syntax.html#syntax-tag-omission
>
> [2] http://jsfiddle.net/robertc/rNv93/1/
> [3] http://jsfiddle.net/UqzEp/2/
> [4] http://jsfiddle.net/UqzEp/3/
>
> ----- alexander.zvegintsev at oracle.com wrote:
> >
>
> Hi Sergey,
> >
>
> Why do we omitting closing th tag?
> >
>
> e.g.
> >
>
> + * <caption>Metal's system color mapping</caption>
> + * <thead>
> + * <tr>
> + * <th>Key
> + * <th>Value
> + * </thead>
>
> I know that HTML parsers are usually forgiving such things. But 
> sometimes it may make thing worse:
> >
>
> https://stackoverflow.com/questions/7125354/what-are-the-actual-problems-of-not-closing-tags-and-attributes-in-html/7135378#7135378
>
> Thanks,
> Alexander.
> > On 05/06/2017 06:23, Sergey Bylokhov wrote:
> >
>
>     If there are no objections I'll change the target ws from dev to client, to minimize the merges between some other javadoc fixes.
>
>     -----sergey.bylokhov at oracle.com  wrote:
>
>         Hello.
>         Here is an updated version where most of the caption are visible.
>         Bug:https://bugs.openjdk.java.net/browse/JDK-8180326
>         Webrev can be found at:
>         http://cr.openjdk.java.net/~serb/8180326/webrev.02/
>         Specdiff:
>         http://cr.openjdk.java.net/~serb/8180326/specdiff.02/overview-summary.html
>
>         You can use search to check the changes in some specific class:
>         Old docs:
>         http://cr.openjdk.java.net/~serb/8180326/api_old.02/overview-summary.html
>         New docs:
>         http://cr.openjdk.java.net/~serb/8180326/api.02/overview-summary.html
>
>
>         -----jonathan.gibbons at oracle.com  wrote:
>
>             Phil,
>
>             I have no evidence one way or the other whether screen readers pay
>             attention
>             to undisplayed or invisible captions. It seemed safest to assume
>
>         that
>
>             they would
>             read a visible caption, and that we should head in that general
>             direction.
>
>             -- Jon
>
>
>             On 05/17/2017 11:58 AM, Phil Race wrote:
>
>                 And PS I was not saying anything to contradict
>
>                     tables should not have a summary attribute and should have a
>
>             caption.
>
>                 However that the docs I read on the web did seem to imply that
>                 summary was very much intended for ATs but it was not at all
>
>         clear
>
>             this
>
>                 is the point of caption. I'm sure they can read it, but I don't
>
>         get
>
>                 how making
>                 it visible matters to them so how it making it visible relates to
>
>                 accessibility
>                 requirements is not an obvious connection to me. So why do we
>
>         have
>
>                 to make it visible for ATs ?
>
>                 -phil.
>
>                 On 05/17/2017 11:54 AM, Phil Race wrote:
>
>                     I will leave the decision on whether to do that now up to Sergey
>
>                     although
>                     it seems all he has to do here is remove "invisible".
>                     Many of the "summary" ones had wrong or misleading text but they
>                     seem to have been all fixed.
>
>                     I'd want to see what the new HTML looks like with a visible
>
>         title
>
>             of
>
>                     course ..
>
>                     -phil.
>
>                     On 05/17/2017 11:52 AM, Jonathan Gibbons wrote:
>
>                         Phil,
>
>                         The bottom line is that in the JDK docs, tables should not have
>
>         a
>
>                         summary attribute and should have a caption. This comes down to
>
>                         accessibility requirements, where we are slowly raising the bar
>
>         on
>
>                         our docs, to be in accordance with Oracle's guidelines.
>
>                         Hiding the caption (style="display:none") is an interim measure
>
>         we
>
>                         have been using during the HTML 5 updates, especially in cases
>
>             where
>
>                         the person doing the markup changes did not know enough to
>
>         create
>
>             an
>
>                         appropriate caption that should be displayed. In time, we should
>
>                         locate and update all table captions (in our standard docs
>
>         bundle)
>
>                         that are not being displayed such that the text is both
>
>             appropriate
>
>                         and visible. If you guys want to do that as part of this
>
>         update,
>
>             go
>
>                         ahead. FWIW, that is what we did for the java.xml module in the
>
>             jaxp
>
>                         repo ... pretty much all tables there now have a reasonable,
>
>             visible
>
>                         caption.
>
>                         -- Jon
>
>
>
>                         On 05/17/2017 11:19 AM, Phil Race wrote:
>
>                             I am not sure we are using the summary in a way that makes it
>                             worthwhile.
>                             As you noted in the other mail
>                             "The summary attribute was used to give a more descriptive
>
>         value
>
>                             of the contents of the table.   A caption is more like a
>
>         title"
>
>                             The values I see are more like a title and as you say that is
>
>         not
>
>                             the idea. See the example here
>
>                             https://www.w3.org/TR/WCAG20-TECHS/H73.html
>
>                             Caption sounds like a title so it might actually be more
>                             appropriate than summary
>                             for the text we have except that its not clear why we'd want
>
>         it
>
>             to
>
>                             be visible when we were fine without.
>
>                             But being there and invisible may be pointless unless screen
>                             readers look for it even if invisible.
>
>                             But if its not doing any harm I guess we can leave it as
>
>             proposed
>
>                             I still need to look at the rest of the changes.
>
>                             -phil.
>
>                             On 05/12/2017 05:11 PM, Jonathan Gibbons wrote:
>
>                                 Sergey,
>
>                                 FWIW, the invisible caption should be regarded as a temporary
>
>                                 solution, until content authors can review/update the text of
>
>             the
>
>                                 caption and make it visible.
>
>                                 The general guideline in this conversion work has been to
>
>         avoid
>
>                                 changing the visible text of the specification, and captions
>
>             fall
>
>                                 into a grey area of whether the text is significant/normative
>
>         or
>
>                                 not.  Hence the temporary step to make them not displayed for
>
>             now.
>
>                                 -- Jon
>
>                                 On 05/12/2017 05:00 PM, Sergey Bylokhov wrote:
>
>                                     The "summary" is unsupported by the HTML5 and we replace it
>
>         by
>
>                                     invisible caption.
>                                     These new styles are located in the stylesheet.css in the
>
>         root
>
>             of
>
>                                     the JavaDoc api folder, so I assume these styles should be
>
>         used
>
>                                     by others as well.
>                                     They were added by this fix:
>                                     https://bugs.openjdk.java.net/browse/JDK-8179479
>
>                                     -----philip.race at oracle.com  wrote:
>
>                                         Does this in any way match the rest of the docs ? Or is
>
>             everyone
>
>                                         left
>                                         to
>                                         style things how they want.
>                                         I thought (?) maybe there is to be some javadoc tool
>
>         support
>
>             for
>
>                                         CSS
>                                         styles.
>
>                                         Also why are all the table summaries removed ?
>
>                                         -phil.
>
>                                         On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>
>                                             This is because I use the same style for most of the
>
>         tables
>
>                                         'class="striped"', which apply the same/unified style for
>                                         all(most) of
>                                         our tables.
>
>                                             Also this is because I removed 'inlined' styles, like
>
>         here:
>
>         http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
>
>                                             -----philip.race at oracle.com  wrote:
>
>                                                 Adding 2d-dev because a number of the files are 2D.
>
>                                                 What is the general reason for changing the appearance of
>
>             the
>
>                                         tables?
>
>                                                 -phil.
>
>                                                 On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>
>                                                     Hello,
>                                                     Please review the fix for jdk9-dev.
>
>                                                     This fix is a part of the effort to make all javadoc in
>
>             jdk9 be
>
>                                                 compatible to HTML5.
>
>                                                     It covers all errors which are reported by the javadoc
>
>             tool
>
>                                         during
>
>                                                 the build of jdk for java.desktop module.
>
>                                                     Bug:https://bugs.openjdk.java.net/browse/JDK-8180326
>                                                     Webrev can be found at:
>
>                                                 http://cr.openjdk.java.net/~serb/8180326/webrev.01
>
>                                                     Note that an appearance of some tables were changed
>
>         after
>
>             the
>
>                                         fix:
>
>                                                     Before:
>
>         http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
>
>                                                     After:
>
>         http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html
>
>                                                     Before:
>
>         http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html
>
>                                                     After :
>
>         http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html
>
>                                                     Before:
>
>         http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html
>
>                                                     After:
>
>         http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html
>
>
> >

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

From sergey.bylokhov at oracle.com  Thu Jun  8 07:29:06 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 8 Jun 2017 00:29:06 -0700
Subject: <Swing Dev> [10] RFR: JDK-8075918:The regression-swing case
 failed as the long Tab titles are not clipped with dots at the end with
 NimbusLookAndFeel
In-Reply-To: <27bb815b-ba6c-0b06-7cc2-a84fc38d8b57@oracle.com>
References: <a4a1ae6b-2d1c-4d99-abcf-e2a3cd24659d@default>
 <27bb815b-ba6c-0b06-7cc2-a84fc38d8b57@oracle.com>
Message-ID: <A6A5EB65-4E18-47AB-8E1A-73B7FECDFB85@oracle.com>

But in this version the clip operation still not executed in methods mentioned here:
http://mail.openjdk.java.net/pipermail/swing-dev/2017-June/007419.html <http://mail.openjdk.java.net/pipermail/swing-dev/2017-June/007419.html>
http://mail.openjdk.java.net/pipermail/swing-dev/2017-May/007406.html

> 
> Please find the modified webrev incorporating your review comment
> 
> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.04/
> 
> Regards
> Prasanta
> On 6/2/2017 12:33 AM, Sergey Bylokhov wrote:
>>  - There is a problem in your algorithm which merges the old and new clips. The getClipBounds() returns a rectangle which is a bounds of the current clip(which is not necessary a rectangle but can be a shape). you can use the Graphics2D.clip(Shape) method which will intersect the passed shape and a current clip of the graphics.
>>  - In this version you forgot to restore the changed clip.
>>  - Also can you try to move the code which change a clip to the methods which currently ignore the passed clip(see below):
>>>>> BasicTabbedPaneUI.paintIcon() as well as
>>>>> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>>>>>   - paintText() at line 681
>>>>>   - paintIcon() at line 634
>>>>> Both methods have a rectangle as a parameter, but it is ignored.
>> 
>> ----- prasanta.sadhukhan at oracle.com wrote:
>> 
>>> I tried to incorporate your comments. Please find modified webrev
>>> 
>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.03/
>>> 
>>> Regards
>>> Prasanta
>>> On 5/28/2017 8:01 AM, Sergey Bylokhov wrote:
>>>> Note that you shouldn't replace the clip, but should apply the new
>>> clip on top of the old. This is necessary if the old clip is smaller
>>> than new.
>>>> ----- sergey.bylokhov at oracle.com wrote:
>>>> 
>>>>> Hi, Prasanta.
>>>>> 
>>>>> BasicTabbedPaneUI.paintIcon() as well as
>>>>> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>>>>>   - paintText() at line 681
>>>>>   - paintIcon() at line 634
>>>>> Both methods have a rectangle as a parameter, but it is ignored.
>>>>> 
>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>> 
>>>>>> Hi Sergey,
>>>>>> 
>>>>>> I could get your concern for paintText() but could not find
>>>>>> paintIcon()
>>>>>> in SynthGraphicsUtils() so not sure how icon drawing contradicts
>>>>>> spec.
>>>>>> Modified webrev:
>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/
>>>>>> 
>>>>>> Also, if we are not calling
>>> SwingUtilities2.clipStringIfNecessary()
>>>>>> then
>>>>>> we are not going to get "..." at the end which this test expects.
>>>>> But
>>>>>> I
>>>>>> could not find anything in spec, that mandates ending with "..."
>>> for
>>>>>> long tab outside
>>>>>> tab bounds. If source change is ok, I guess we then need to
>>> modify
>>>>> the
>>>>>> html file modifying the expected result for NimbusL&F.
>>>>>> 
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 5/25/2017 3:11 AM, Sergey Bylokhov wrote:
>>>>>>> Hi, Prasanta.
>>>>>>> Please take a look to my comments at:
>>>>>>> 
>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html
>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html
>>>>>>> The two methods paintText() and paintIcon() are contradict the
>>>>> spec
>>>>>> and draw the text and icons outside of the tab.
>>>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>>> 
>>>>>>>> Hi All,
>>>>>>>> 
>>>>>>>> Please review a fix for an issue where long Tab titiles are not
>>>>>>>> clipped
>>>>>>>> with dots at end for NimbusLookAndFeel L&F.
>>>>>>>> Other L&Fs works ok.
>>>>>>>> 
>>>>>>>> Issue was in SynthTabbedPaneUI#paintTab(), the title is not
>>>>>> clipped
>>>>>>>> but
>>>>>>>> passed to paintText() as it is received.
>>>>>>>> Other L&F such as Metal, Motif, Windows which uses
>>>>>>>> BasicTabbedPaneUI#paintTab(), the title is clipped
>>>>>>>> 
>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950
>>>>>>>> before it is passed to paintText().
>>>>>>>> 
>>>>>>>> Proposed fix is to do the same for
>>> SynthTabbedPaneUI#paintTab().
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075918
>>>>>>>> webrev:
>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/
>>>>>>>> Regards
>>>>>>>> Prasanta
> 

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

From sergey.bylokhov at oracle.com  Thu Jun  8 07:42:12 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 8 Jun 2017 00:42:12 -0700
Subject: <Swing Dev> [9] JDK-8165213: [TESTBUG] [PIT] consistent failure
 of a new regtest for 8163193
In-Reply-To: <e5caac0a-b6b8-4b02-9a3e-ece26162d3ef@default>
References: <e5caac0a-b6b8-4b02-9a3e-ece26162d3ef@default>
Message-ID: <D7F421A7-B1F6-4C06-A330-08C6B89ED052@oracle.com>

On what color profiles the test is executed? On macOS it should be Generic RGB. Also in jdk9 the new robot api for HiDPI was added, please try it also.
If it solve the problem on Mac then I suggest to try to investigate a problem on Linux and fix it if possible, instead of tweaking the test.

> 
> Hi All,
> 	Please review fix for JDK-8165213 where there is a consistent failure while testing for gradient color of the button.
> 
> Issue: The Robot's function to get the pixel's RGB values has an issue with its implementation and is currently getting resolved. Because of this issue, we are getting incorrect RGB values for the requested pixel and hence the test is getting failed.
> 
> Resolution\Fix: There is an alternate mechanism to capture the image to a buffer and use the buffer function to get the RGB values. This test is for HiDpi displays. In the image space, the images won't be scaled implicitly and hence they need to be applied with the scaling in the graphics space before painting on to the image buffer. This same is implemented.
> Based on the test outputs, the tolerance band for color comparison is set at 11.
> 
> Test outputs: 
> 1. On a windows system, the pixel color values exactly matches.
> 2. On a Linux system, the pixel color values vary by a maximum difference of around 6.
> 3. On a mac system, the pixel color values vary by a maximum difference of around 10.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8165213
> Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/8165213/webrev_01/
> 
> Thanks and regards,
> Shashi



From prasanta.sadhukhan at oracle.com  Thu Jun  8 08:11:31 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 8 Jun 2017 13:41:31 +0530
Subject: <Swing Dev> [10] RFR: JDK-8075918:The regression-swing case
 failed as the long Tab titles are not clipped with dots at the end with
 NimbusLookAndFeel
In-Reply-To: <A6A5EB65-4E18-47AB-8E1A-73B7FECDFB85@oracle.com>
References: <a4a1ae6b-2d1c-4d99-abcf-e2a3cd24659d@default>
 <27bb815b-ba6c-0b06-7cc2-a84fc38d8b57@oracle.com>
 <A6A5EB65-4E18-47AB-8E1A-73B7FECDFB85@oracle.com>
Message-ID: <7b5d79ce-3f1b-d7be-486b-e836bf3a5862@oracle.com>

Why? clip is invoked in SynthTabbedPaneUI#paintText() at line 687 and 
SynthTabbedPaneUI#paintTab() at line 637, where you asked for, I guess.

Regards
Prasanta
On 6/8/2017 12:59 PM, Sergey Bylokhov wrote:
> But in this version the clip operation still not executed in methods 
> mentioned here:
> http://mail.openjdk.java.net/pipermail/swing-dev/2017-June/007419.html
> http://mail.openjdk.java.net/pipermail/swing-dev/2017-May/007406.html
>
>>
>> Please find the modified webrev incorporating your review comment
>>
>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.04/ 
>> <http://cr.openjdk.java.net/%7Epsadhukhan/8075918/webrev.04/>
>>
>> Regards
>> Prasanta
>> On 6/2/2017 12:33 AM, Sergey Bylokhov wrote:
>>>  - There is a problem in your algorithm which merges the old and new 
>>> clips. The getClipBounds() returns a rectangle which is a bounds of 
>>> the current clip(which is not necessary a rectangle but can be a 
>>> shape). you can use the Graphics2D.clip(Shape) method which will 
>>> intersect the passed shape and a current clip of the graphics.
>>>  - In this version you forgot to restore the changed clip.
>>>  - Also can you try to move the code which change a clip to the 
>>> methods which currently ignore the passed clip(see below):
>>>>>> BasicTabbedPaneUI.paintIcon() as well as
>>>>>> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>>>>>>   - paintText() at line 681
>>>>>>   - paintIcon() at line 634
>>>>>> Both methods have a rectangle as a parameter, but it is ignored.
>>>
>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>
>>>> I tried to incorporate your comments. Please find modified webrev
>>>>
>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.03/
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 5/28/2017 8:01 AM, Sergey Bylokhov wrote:
>>>>> Note that you shouldn't replace the clip, but should apply the new
>>>> clip on top of the old. This is necessary if the old clip is smaller
>>>> than new.
>>>>> ----- sergey.bylokhov at oracle.com wrote:
>>>>>
>>>>>> Hi, Prasanta.
>>>>>>
>>>>>> BasicTabbedPaneUI.paintIcon() as well as
>>>>>> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>>>>>>   - paintText() at line 681
>>>>>>   - paintIcon() at line 634
>>>>>> Both methods have a rectangle as a parameter, but it is ignored.
>>>>>>
>>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>>
>>>>>>> Hi Sergey,
>>>>>>>
>>>>>>> I could get your concern for paintText() but could not find
>>>>>>> paintIcon()
>>>>>>> in SynthGraphicsUtils() so not sure how icon drawing contradicts
>>>>>>> spec.
>>>>>>> Modified webrev:
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/
>>>>>>>
>>>>>>> Also, if we are not calling
>>>> SwingUtilities2.clipStringIfNecessary()
>>>>>>> then
>>>>>>> we are not going to get "..." at the end which this test expects.
>>>>>> But
>>>>>>> I
>>>>>>> could not find anything in spec, that mandates ending with "..."
>>>> for
>>>>>>> long tab outside
>>>>>>> tab bounds. If source change is ok, I guess we then need to
>>>> modify
>>>>>> the
>>>>>>> html file modifying the expected result for NimbusL&F.
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 5/25/2017 3:11 AM, Sergey Bylokhov wrote:
>>>>>>>> Hi, Prasanta.
>>>>>>>> Please take a look to my comments at:
>>>>>>>>
>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html
>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html
>>>>>>>> The two methods paintText() and paintIcon() are contradict the
>>>>>> spec
>>>>>>> and draw the text and icons outside of the tab.
>>>>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Please review a fix for an issue where long Tab titiles are not
>>>>>>>>> clipped
>>>>>>>>> with dots at end for NimbusLookAndFeel L&F.
>>>>>>>>> Other L&Fs works ok.
>>>>>>>>>
>>>>>>>>> Issue was in SynthTabbedPaneUI#paintTab(), the title is not
>>>>>>> clipped
>>>>>>>>> but
>>>>>>>>> passed to paintText() as it is received.
>>>>>>>>> Other L&F such as Metal, Motif, Windows which uses
>>>>>>>>> BasicTabbedPaneUI#paintTab(), the title is clipped
>>>>>>>>>
>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950
>>>>>>>>> before it is passed to paintText().
>>>>>>>>>
>>>>>>>>> Proposed fix is to do the same for
>>>> SynthTabbedPaneUI#paintTab().
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075918
>>>>>>>>> webrev:
>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>
>

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

From sergey.bylokhov at oracle.com  Thu Jun  8 16:04:28 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 8 Jun 2017 09:04:28 -0700
Subject: <Swing Dev> [10] RFR: JDK-8075918:The regression-swing case
 failed as the long Tab titles are not clipped with dots at the end with
 NimbusLookAndFeel
In-Reply-To: <7b5d79ce-3f1b-d7be-486b-e836bf3a5862@oracle.com>
References: <a4a1ae6b-2d1c-4d99-abcf-e2a3cd24659d@default>
 <27bb815b-ba6c-0b06-7cc2-a84fc38d8b57@oracle.com>
 <A6A5EB65-4E18-47AB-8E1A-73B7FECDFB85@oracle.com>
 <7b5d79ce-3f1b-d7be-486b-e836bf3a5862@oracle.com>
Message-ID: <34003A0F-6EE2-42B6-A920-404769399E38@oracle.com>

I have referenced these methods:	

"BasicTabbedPaneUI.paintIcon() as well as SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
 - paintText() at line 681	
 - paintIcon() at line 634
Both methods have a rectangle as a parameter, but it is ignored."
The first is in the BasicTabbedPaneUI.java and the second is in the SynthGraphicsUtils.java

> 
> Why? clip is invoked in SynthTabbedPaneUI#paintText() at line 687 and SynthTabbedPaneUI#paintTab() at line 637, where you asked for, I guess.
> Regards
> Prasanta
> On 6/8/2017 12:59 PM, Sergey Bylokhov wrote:
>> But in this version the clip operation still not executed in methods mentioned here:
>> http://mail.openjdk.java.net/pipermail/swing-dev/2017-June/007419.html <http://mail.openjdk.java.net/pipermail/swing-dev/2017-June/007419.html>
>> http://mail.openjdk.java.net/pipermail/swing-dev/2017-May/007406.html <http://mail.openjdk.java.net/pipermail/swing-dev/2017-May/007406.html>
>> 
>>> 
>>> Please find the modified webrev incorporating your review comment
>>> 
>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.04/ <http://cr.openjdk.java.net/%7Epsadhukhan/8075918/webrev.04/>
>>> 
>>> Regards
>>> Prasanta
>>> On 6/2/2017 12:33 AM, Sergey Bylokhov wrote:
>>>>  - There is a problem in your algorithm which merges the old and new clips. The getClipBounds() returns a rectangle which is a bounds of the current clip(which is not necessary a rectangle but can be a shape). you can use the Graphics2D.clip(Shape) method which will intersect the passed shape and a current clip of the graphics.
>>>>  - In this version you forgot to restore the changed clip.
>>>>  - Also can you try to move the code which change a clip to the methods which currently ignore the passed clip(see below):
>>>>>>> BasicTabbedPaneUI.paintIcon() as well as
>>>>>>> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>>>>>>>   - paintText() at line 681
>>>>>>>   - paintIcon() at line 634
>>>>>>> Both methods have a rectangle as a parameter, but it is ignored.
>>>> 
>>>> ----- prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com> wrote:
>>>> 
>>>>> I tried to incorporate your comments. Please find modified webrev
>>>>> 
>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.03/ <http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.03/>
>>>>> 
>>>>> Regards
>>>>> Prasanta
>>>>> On 5/28/2017 8:01 AM, Sergey Bylokhov wrote:
>>>>>> Note that you shouldn't replace the clip, but should apply the new
>>>>> clip on top of the old. This is necessary if the old clip is smaller
>>>>> than new.
>>>>>> ----- sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com> wrote:
>>>>>> 
>>>>>>> Hi, Prasanta.
>>>>>>> 
>>>>>>> BasicTabbedPaneUI.paintIcon() as well as
>>>>>>> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>>>>>>>   - paintText() at line 681
>>>>>>>   - paintIcon() at line 634
>>>>>>> Both methods have a rectangle as a parameter, but it is ignored.
>>>>>>> 
>>>>>>> ----- prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com> wrote:
>>>>>>> 
>>>>>>>> Hi Sergey,
>>>>>>>> 
>>>>>>>> I could get your concern for paintText() but could not find
>>>>>>>> paintIcon()
>>>>>>>> in SynthGraphicsUtils() so not sure how icon drawing contradicts
>>>>>>>> spec.
>>>>>>>> Modified webrev:
>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/ <http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/>
>>>>>>>> 
>>>>>>>> Also, if we are not calling
>>>>> SwingUtilities2.clipStringIfNecessary()
>>>>>>>> then
>>>>>>>> we are not going to get "..." at the end which this test expects.
>>>>>>> But
>>>>>>>> I
>>>>>>>> could not find anything in spec, that mandates ending with "..."
>>>>> for
>>>>>>>> long tab outside
>>>>>>>> tab bounds. If source change is ok, I guess we then need to
>>>>> modify
>>>>>>> the
>>>>>>>> html file modifying the expected result for NimbusL&F.
>>>>>>>> 
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>> On 5/25/2017 3:11 AM, Sergey Bylokhov wrote:
>>>>>>>>> Hi, Prasanta.
>>>>>>>>> Please take a look to my comments at:
>>>>>>>>> 
>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html <http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html>
>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html <http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html>
>>>>>>>>> The two methods paintText() and paintIcon() are contradict the
>>>>>>> spec
>>>>>>>> and draw the text and icons outside of the tab.
>>>>>>>>> ----- prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com> wrote:
>>>>>>>>> 
>>>>>>>>>> Hi All,
>>>>>>>>>> 
>>>>>>>>>> Please review a fix for an issue where long Tab titiles are not
>>>>>>>>>> clipped
>>>>>>>>>> with dots at end for NimbusLookAndFeel L&F.
>>>>>>>>>> Other L&Fs works ok.
>>>>>>>>>> 
>>>>>>>>>> Issue was in SynthTabbedPaneUI#paintTab(), the title is not
>>>>>>>> clipped
>>>>>>>>>> but
>>>>>>>>>> passed to paintText() as it is received.
>>>>>>>>>> Other L&F such as Metal, Motif, Windows which uses
>>>>>>>>>> BasicTabbedPaneUI#paintTab(), the title is clipped
>>>>>>>>>> 
>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950 <http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950>
>>>>>>>>>> before it is passed to paintText().
>>>>>>>>>> 
>>>>>>>>>> Proposed fix is to do the same for
>>>>> SynthTabbedPaneUI#paintTab().
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075918 <https://bugs.openjdk.java.net/browse/JDK-8075918>
>>>>>>>>>> webrev:
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/ <http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/>
>>>>>>>>>> Regards
>>>>>>>>>> Prasanta
>>> 
>> 
> 

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

From sreeprakash.s at oracle.com  Thu Jun  8 20:08:44 2017
From: sreeprakash.s at oracle.com (Sreeprakash Sreedharan)
Date: Thu, 8 Jun 2017 13:08:44 -0700 (PDT)
Subject: <Swing Dev> [10] RFR: JDK-8181782:[TESTBUG] [Macosx]
 JTextAreaEmojiTest is not executed
Message-ID: <3dce1cd6-9150-4209-9377-325531403130@default>

Hi All,

Kindly review the fix for JDK10.

Bug: https://bugs.openjdk.java.net/browse/JDK-8181782

Webrev: http://cr.openjdk.java.net/~rpatil/8181782/webrev.00

Issue: JTREG was not executing the manual test JTextAreaEmojiTest and was always giving a passed result.

Fix: Made sure that main function waits for pass/fail events using a countdown latch and also added manual to the run tag

Regards,
Sreeprakash


From prasanta.sadhukhan at oracle.com  Fri Jun  9 06:03:05 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 9 Jun 2017 11:33:05 +0530
Subject: <Swing Dev> [10] RFR: JDK-8075918:The regression-swing case
 failed as the long Tab titles are not clipped with dots at the end with
 NimbusLookAndFeel
In-Reply-To: <34003A0F-6EE2-42B6-A920-404769399E38@oracle.com>
References: <a4a1ae6b-2d1c-4d99-abcf-e2a3cd24659d@default>
 <27bb815b-ba6c-0b06-7cc2-a84fc38d8b57@oracle.com>
 <A6A5EB65-4E18-47AB-8E1A-73B7FECDFB85@oracle.com>
 <7b5d79ce-3f1b-d7be-486b-e836bf3a5862@oracle.com>
 <34003A0F-6EE2-42B6-A920-404769399E38@oracle.com>
Message-ID: <be81fbcf-155b-5e9c-c40c-e9cf8a15447e@oracle.com>

Ok. Rectified. Please find the modified webrev with clip at correct place(s)

http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.05/

Regards
Prasanta
On 6/8/2017 9:34 PM, Sergey Bylokhov wrote:
> I have referenced these methods:
>
> "BasicTabbedPaneUI.paintIcon() as well as 
> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>  - paintText() at line 681
>  - paintIcon() at line 634
> Both methods have a rectangle as a parameter, but it is ignored."
> The first is in the BasicTabbedPaneUI.java and the second is in the 
> SynthGraphicsUtils.java
>
>>
>> Why? clip is invoked in SynthTabbedPaneUI#paintText() at line 687 and 
>> SynthTabbedPaneUI#paintTab() at line 637, where you asked for, I guess.
>>
>> Regards
>> Prasanta
>> On 6/8/2017 12:59 PM, Sergey Bylokhov wrote:
>>> But in this version the clip operation still not executed in methods 
>>> mentioned here:
>>> http://mail.openjdk.java.net/pipermail/swing-dev/2017-June/007419.html
>>> http://mail.openjdk.java.net/pipermail/swing-dev/2017-May/007406.html
>>>
>>>>
>>>> Please find the modified webrev incorporating your review comment
>>>>
>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.04/ 
>>>> <http://cr.openjdk.java.net/%7Epsadhukhan/8075918/webrev.04/>
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 6/2/2017 12:33 AM, Sergey Bylokhov wrote:
>>>>>  - There is a problem in your algorithm which merges the old and 
>>>>> new clips. The getClipBounds() returns a rectangle which is a 
>>>>> bounds of the current clip(which is not necessary a rectangle but 
>>>>> can be a shape). you can use the Graphics2D.clip(Shape) method 
>>>>> which will intersect the passed shape and a current clip of the 
>>>>> graphics.
>>>>>  - In this version you forgot to restore the changed clip.
>>>>>  - Also can you try to move the code which change a clip to the 
>>>>> methods which currently ignore the passed clip(see below):
>>>>>>>> BasicTabbedPaneUI.paintIcon() as well as
>>>>>>>> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>>>>>>>>   - paintText() at line 681
>>>>>>>>   - paintIcon() at line 634
>>>>>>>> Both methods have a rectangle as a parameter, but it is ignored.
>>>>>
>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>
>>>>>> I tried to incorporate your comments. Please find modified webrev
>>>>>>
>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.03/
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 5/28/2017 8:01 AM, Sergey Bylokhov wrote:
>>>>>>> Note that you shouldn't replace the clip, but should apply the new
>>>>>> clip on top of the old. This is necessary if the old clip is smaller
>>>>>> than new.
>>>>>>> ----- sergey.bylokhov at oracle.com wrote:
>>>>>>>
>>>>>>>> Hi, Prasanta.
>>>>>>>>
>>>>>>>> BasicTabbedPaneUI.paintIcon() as well as
>>>>>>>> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>>>>>>>>   - paintText() at line 681
>>>>>>>>   - paintIcon() at line 634
>>>>>>>> Both methods have a rectangle as a parameter, but it is ignored.
>>>>>>>>
>>>>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>>>>
>>>>>>>>> Hi Sergey,
>>>>>>>>>
>>>>>>>>> I could get your concern for paintText() but could not find
>>>>>>>>> paintIcon()
>>>>>>>>> in SynthGraphicsUtils() so not sure how icon drawing contradicts
>>>>>>>>> spec.
>>>>>>>>> Modified webrev:
>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/
>>>>>>>>>
>>>>>>>>> Also, if we are not calling
>>>>>> SwingUtilities2.clipStringIfNecessary()
>>>>>>>>> then
>>>>>>>>> we are not going to get "..." at the end which this test expects.
>>>>>>>> But
>>>>>>>>> I
>>>>>>>>> could not find anything in spec, that mandates ending with "..."
>>>>>> for
>>>>>>>>> long tab outside
>>>>>>>>> tab bounds. If source change is ok, I guess we then need to
>>>>>> modify
>>>>>>>> the
>>>>>>>>> html file modifying the expected result for NimbusL&F.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>> On 5/25/2017 3:11 AM, Sergey Bylokhov wrote:
>>>>>>>>>> Hi, Prasanta.
>>>>>>>>>> Please take a look to my comments at:
>>>>>>>>>>
>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html
>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html
>>>>>>>>>> The two methods paintText() and paintIcon() are contradict the
>>>>>>>> spec
>>>>>>>>> and draw the text and icons outside of the tab.
>>>>>>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> Please review a fix for an issue where long Tab titiles are not
>>>>>>>>>>> clipped
>>>>>>>>>>> with dots at end for NimbusLookAndFeel L&F.
>>>>>>>>>>> Other L&Fs works ok.
>>>>>>>>>>>
>>>>>>>>>>> Issue was in SynthTabbedPaneUI#paintTab(), the title is not
>>>>>>>>> clipped
>>>>>>>>>>> but
>>>>>>>>>>> passed to paintText() as it is received.
>>>>>>>>>>> Other L&F such as Metal, Motif, Windows which uses
>>>>>>>>>>> BasicTabbedPaneUI#paintTab(), the title is clipped
>>>>>>>>>>>
>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950
>>>>>>>>>>> before it is passed to paintText().
>>>>>>>>>>>
>>>>>>>>>>> Proposed fix is to do the same for
>>>>>> SynthTabbedPaneUI#paintTab().
>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075918
>>>>>>>>>>> webrev:
>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/
>>>>>>>>>>> Regards
>>>>>>>>>>> Prasanta
>>>>
>>>
>>
>

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

From sergey.bylokhov at oracle.com  Fri Jun  9 19:34:53 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 9 Jun 2017 12:34:53 -0700 (PDT)
Subject: <Swing Dev> [9] Review Request: 8181877 Cleanup of javadoc in
 javax.accessibility package
Message-ID: <b92f77d7-a7ff-4ed3-bb23-ac94f900cff8@default>

Hello,
Please review the fix for jdk9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8181877
Webrev can be found at: http://cr.openjdk.java.net/~serb/8181877/webrev.00
Specdiff: http://cr.openjdk.java.net/~serb/8181877/specdiff.00/overview-summary.html

In this fix the javadoc is updated and the next rules were applied:
 - <tag> should be replaced by {@tag }
 - 80 column limit
 - description of the class/method/field should be followed by dot
 - @param, @return should not end with a dot, except a case when more than one sentences are used
 - empty line after description/before the first tag was added
 - unnecessary empty lines were removed
 - sets of spaces in the middle of text were deleted
 - @param, @throws, @return should be aligned, to be more readable
 - unnecessary imports should be removed
 - the "null"/"true"/"false"/"this"/"ClassName" should be wrapped in {@code } when necessary
 - the order of different tags were unified across the package
There are also some mixing of different "reference usage", for example "InputStream" vs "input stream", "String" vs "string", etc. I tried to fix some of them.

During the cleanup I found that some of the specs are outdated, for example "package-summary" contains incorrect number of classes/interfaces. In such cases I leaved the spec as-is with intention to rework the text later.


From rocky.sloan at oracle.com  Fri Jun  9 22:19:06 2017
From: rocky.sloan at oracle.com (Rocky Sloan)
Date: Fri, 9 Jun 2017 15:19:06 -0700
Subject: <Swing Dev> [9] Review Request: 8181877 Cleanup of javadoc in
 javax.accessibility package
In-Reply-To: <b92f77d7-a7ff-4ed3-bb23-ac94f900cff8@default>
References: <b92f77d7-a7ff-4ed3-bb23-ac94f900cff8@default>
Message-ID: <10a1ffe1-3ae0-911f-4002-3581058f745f@oracle.com>

+1


On 6/9/2017 12:34 PM, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk9.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8181877
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8181877/webrev.00
> Specdiff: http://cr.openjdk.java.net/~serb/8181877/specdiff.00/overview-summary.html
>
> In this fix the javadoc is updated and the next rules were applied:
>   - <tag> should be replaced by {@tag }
>   - 80 column limit
>   - description of the class/method/field should be followed by dot
>   - @param, @return should not end with a dot, except a case when more than one sentences are used
>   - empty line after description/before the first tag was added
>   - unnecessary empty lines were removed
>   - sets of spaces in the middle of text were deleted
>   - @param, @throws, @return should be aligned, to be more readable
>   - unnecessary imports should be removed
>   - the "null"/"true"/"false"/"this"/"ClassName" should be wrapped in {@code } when necessary
>   - the order of different tags were unified across the package
> There are also some mixing of different "reference usage", for example "InputStream" vs "input stream", "String" vs "string", etc. I tried to fix some of them.
>
> During the cleanup I found that some of the specs are outdated, for example "package-summary" contains incorrect number of classes/interfaces. In such cases I leaved the spec as-is with intention to rework the text later.



From srinivas.mandalika at oracle.com  Mon Jun 12 08:20:13 2017
From: srinivas.mandalika at oracle.com (Srinivas Mandalika)
Date: Mon, 12 Jun 2017 01:20:13 -0700 (PDT)
Subject: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169954 :
 JFileChooser/8021253: java.lang.RuntimeException: Default button is not
 pressed
Message-ID: <12f70f31-3e5a-47cc-b607-4f0991bcaba6@default>

Hi All,

 

Please review the test bug fix for JDK-8169954 : JFileChooser/8021253: java.lang.RuntimeException: Default button is not pressed.

 

Issue:

The Test under  8021253 is opening up a filechooser iconified, causing a failure to hit Enter key on the filechooser. Test failure is intermittent and more pronounced when run along with the entire javax/swing suite.

 

Fix:

This is occurring due to synchronization issues in the previous test 7199708. 
The test for bug 7199708 checks if the filechooser can load up a large number of files without a crash. In doing so it also tries to sort the columns of the filechooser via Robot mouse move and click actions. 
Commenting out these robot actions ensured that the next test 8021253 was passing indicating that this was a problem of with synchronization of the filechooser UI sorting and disposal of filechooser and that root cause was that these were not synchronized properly. Hence fixed the code flow using the regtesthelpers classes, to ensure that this is working correctly now.

Also ensured the filechooser of test 8021253 is not opened iconified and has focus. 

 

Testing:

Tested the potential fix on winx64, linux  with JDK8, 9 several times with running tests individually clubbed with the previous test and the entire suite (i.e javax/swing) put to ensure that the issue is not repeated.

 

Bug Id:

https://bugs.openjdk.java.net/browse/JDK-8169954

 

WebRev Request:

http://cr.openjdk.java.net/~akolarkunnu/8169954/webrev.00/

 

 

Regards,

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

From srinivas.mandalika at oracle.com  Mon Jun 12 08:20:29 2017
From: srinivas.mandalika at oracle.com (Srinivas Mandalika)
Date: Mon, 12 Jun 2017 01:20:29 -0700 (PDT)
Subject: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169957:
 javax/swing/JScrollBar/4708809: The scrollbar moved with incorrect
 direction
Message-ID: <60b7457f-90ac-4e1a-afa4-4efdfd0e5599@default>

Hi All,

 

Please review the test bug fix for JDK-8169957: javax/swing/JScrollBar/4708809: The scrollbar moved with incorrect direction.

 

Issue:

This test checks whether a scrollbar drag moves in the correct direction. This behavior is working as expected when tested manually. The test was failing robot clicks out of sync with the yet to be maximized frame.

 

Fix:

Ensure the robot waits for the frame to be maximized before the scroll actions. Also ensure the main application frame is maximized explicitly.

 

Testing: 

Tested the potential fix on winx64, linux  with JDK8, 9 several times with running tests individually clubbed with the previous test and the entire suite (i.e javax/swing) put to ensure that the issue is not repeated.

 

Bug Id: https://bugs.openjdk.java.net/browse/JDK-8169957

Webrev: http://cr.openjdk.java.net/~akolarkunnu/8169957/webrev.00/

 

Thanks

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

From srinivas.mandalika at oracle.com  Mon Jun 12 08:20:33 2017
From: srinivas.mandalika at oracle.com (Srinivas Mandalika)
Date: Mon, 12 Jun 2017 01:20:33 -0700 (PDT)
Subject: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169958 :
 javax/swing/JSpinner/5012888: Spinner value should be more than 1
Message-ID: <0ce40baf-45ab-4dd4-bd95-d7b3bce5751b@default>

Hi All,

 

Please review the test bug fix for JDK-8169958 : javax/swing/JSpinner/5012888: Spinner value should be more than 1.

 

Issue: 

In this bug, click & hold on arrow of JSpinner only transfers focus and does not change spinner value. This behavior is intermittently seen in the automated test but is working as expected when checked for manualy. The test was failing robot clicks out of sync with the yet to be maximized frame.

 

Fix: 

Ensure the robot waits for the frame to be maximized before the clicks on the Spinner. Also ensure the main application frame is maximized explicitly.

 

Testing: 

Tested the potential fix on winx64, linux  with JDK8, 9 several times with running tests individually clubbed with the previous test and the entire suite (i.e javax/swing) put to ensure that the issue is not repeated.

 

Bug Id:

https://bugs.openjdk.java.net/browse/JDK-8169958

 

 

WebRev Request:

http://cr.openjdk.java.net/~akolarkunnu/8169958/webrev.00/

 

 

Regards,

Srinivas M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170612/043ae27b/attachment.html>

From ajit.ghaisas at oracle.com  Mon Jun 12 09:11:14 2017
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Mon, 12 Jun 2017 02:11:14 -0700 (PDT)
Subject: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169958 :
 javax/swing/JSpinner/5012888: Spinner value should be more than 1
In-Reply-To: <0ce40baf-45ab-4dd4-bd95-d7b3bce5751b@default>
References: <0ce40baf-45ab-4dd4-bd95-d7b3bce5751b@default>
Message-ID: <3cefd74c-a841-46db-881a-4b31b78c2363@default>

Hi Srinivas,

   Here are few review comments :
   1.  Add this bug id to the @bug jtreg tag in test
   2. Replace generic import statements with specific ones
   3. You are calling - b.doTest(); - in a try catch block. This will catch any exception and print stack trace. 
       I think we can remove this try-catch block - simply make a call to b.doTest(), if an exception is thrown, it is thrown out from main() and jtreg framework will catch it and mark the test as failed.
   4. Line 63 in your file has a throw error - this can be converted to exception.
   5. Keep four spaces indentation level

Regards,
Ajit


From: Srinivas Mandalika 
Sent: Monday, June 12, 2017 1:51 PM
To: swing-dev at openjdk.java.net
Subject: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169958 : javax/swing/JSpinner/5012888: Spinner value should be more than 1

Hi All,

Please review the test bug fix for JDK-8169958 : javax/swing/JSpinner/5012888: Spinner value should be more than 1.

Issue: 
In this bug, click & hold on arrow of JSpinner only transfers focus and does not change spinner value. This behavior is intermittently seen in the automated test but is working as expected when checked for manualy. The test was failing robot clicks out of sync with the yet to be maximized frame.

Fix: 
Ensure the robot waits for the frame to be maximized before the clicks on the Spinner. Also ensure the main application frame is maximized explicitly.

Testing: 
Tested the potential fix on winx64, linux ?with JDK8, 9 several times with running tests individually clubbed with the previous test and the entire suite (i.e javax/swing) put to ensure that the issue is not repeated.

Bug Id:
https://bugs.openjdk.java.net/browse/JDK-8169958


WebRev Request:
http://cr.openjdk.java.net/~akolarkunnu/8169958/webrev.00/


Regards,
Srinivas M


From prasanta.sadhukhan at oracle.com  Mon Jun 12 09:25:15 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 12 Jun 2017 14:55:15 +0530
Subject: <Swing Dev> [10] RFR: JDK-8181782:[TESTBUG] [Macosx]
 JTextAreaEmojiTest is not executed
In-Reply-To: <3dce1cd6-9150-4209-9377-325531403130@default>
References: <3dce1cd6-9150-4209-9377-325531403130@default>
Message-ID: <28680c63-44c2-8681-8469-cc93be3b91a9@oracle.com>

It seems the test is waiting infinitely instead of having a timeout. I 
amnot sure of jtreg timeout but it's better to rely on test's own 
timeout, so await(timeout) is a better call .

Also, please add @key headful tag to the test.

Regards
Prasanta
On 6/9/2017 1:38 AM, Sreeprakash Sreedharan wrote:
> Hi All,
>
> Kindly review the fix for JDK10.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8181782
>
> Webrev: http://cr.openjdk.java.net/~rpatil/8181782/webrev.00
>
> Issue: JTREG was not executing the manual test JTextAreaEmojiTest and was always giving a passed result.
>
> Fix: Made sure that main function waits for pass/fail events using a countdown latch and also added manual to the run tag
>
> Regards,
> Sreeprakash



From shashidhara.veerabhadraiah at oracle.com  Mon Jun 12 10:54:04 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Mon, 12 Jun 2017 03:54:04 -0700 (PDT)
Subject: <Swing Dev> [10] RFR JDK-6267105:UIDefaults.getUIError dumps error
 message to System.err and also throws Error.
Message-ID: <c2655a81-8016-4ab5-b44c-e5e158de8a51@default>

Hi All,
	Please review the code bug fix for JDK-6267105:UIDefaults.getUIError dumps error message to System.err and also throws Error.

Issue:
     Error message was getting dumped to the system.err even though the recovery actions were performed leading to unnecessary confusion regarding the actual behavior.

Fix:
    This fix removes the call which prints the message to the system.err and stores the message in the Error class. This same message can be retrieved after we catch the error and calling getMessage() of the Error class. Through catching the error, the user can perform necessary recovery actions without cluttering the system.err. This fix does not modifies the 'user effect' as the user would still get the same error as they were getting before this fix.

Test:
    Now the system.err does not get cluttered though we performed the necessary recovery actions. The error message string can be recovered by calling getMessage() if needed.
   
Bug:
https://bugs.openjdk.java.net/browse/JDK-6267105

Webrev:
http://cr.openjdk.java.net/~aghaisas/shashi/6267105/webrev_00/

Thanks and regards,
Shashi


From sreeprakash.s at oracle.com  Mon Jun 12 14:21:13 2017
From: sreeprakash.s at oracle.com (Sreeprakash Sreedharan)
Date: Mon, 12 Jun 2017 07:21:13 -0700 (PDT)
Subject: <Swing Dev> [10] RFR: JDK-8181782:[TESTBUG] [Macosx]
 JTextAreaEmojiTest is not executed
In-Reply-To: <28680c63-44c2-8681-8469-cc93be3b91a9@oracle.com>
References: <3dce1cd6-9150-4209-9377-325531403130@default>
 <28680c63-44c2-8681-8469-cc93be3b91a9@oracle.com>
Message-ID: <9c1fbf5c-e872-414e-84c1-fa533a21e1aa@default>

Thanks for the inputs, Prasanta. 

I have incorporated the changes mentioned.

Updated Webrev :  http://cr.openjdk.java.net/~rpatil/8181782/webrev.01

Regards,
Sreeprakash

-----Original Message-----
From: Prasanta Sadhukhan 
Sent: Monday, June 12, 2017 2:55 PM
To: Sreeprakash Sreedharan <sreeprakash.s at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10] RFR: JDK-8181782:[TESTBUG] [Macosx] JTextAreaEmojiTest is not executed

It seems the test is waiting infinitely instead of having a timeout. I amnot sure of jtreg timeout but it's better to rely on test's own timeout, so await(timeout) is a better call .

Also, please add @key headful tag to the test.

Regards
Prasanta
On 6/9/2017 1:38 AM, Sreeprakash Sreedharan wrote:
> Hi All,
>
> Kindly review the fix for JDK10.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8181782
>
> Webrev: http://cr.openjdk.java.net/~rpatil/8181782/webrev.00
>
> Issue: JTREG was not executing the manual test JTextAreaEmojiTest and was always giving a passed result.
>
> Fix: Made sure that main function waits for pass/fail events using a 
> countdown latch and also added manual to the run tag
>
> Regards,
> Sreeprakash



From semyon.sadetsky at oracle.com  Mon Jun 12 16:49:01 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 12 Jun 2017 09:49:01 -0700
Subject: <Swing Dev> [10] RFR JDK-6267105:UIDefaults.getUIError dumps
 error message to System.err and also throws Error.
In-Reply-To: <c2655a81-8016-4ab5-b44c-e5e158de8a51@default>
References: <c2655a81-8016-4ab5-b44c-e5e158de8a51@default>
Message-ID: <be0276b1-dbc9-f295-ddff-5bafcd406b98@oracle.com>

+1

--Semyon


On 06/12/2017 03:54 AM, Shashidhara Veerabhadraiah wrote:
> Hi All,
> 	Please review the code bug fix for JDK-6267105:UIDefaults.getUIError dumps error message to System.err and also throws Error.
>
> Issue:
>       Error message was getting dumped to the system.err even though the recovery actions were performed leading to unnecessary confusion regarding the actual behavior.
>
> Fix:
>      This fix removes the call which prints the message to the system.err and stores the message in the Error class. This same message can be retrieved after we catch the error and calling getMessage() of the Error class. Through catching the error, the user can perform necessary recovery actions without cluttering the system.err. This fix does not modifies the 'user effect' as the user would still get the same error as they were getting before this fix.
>
> Test:
>      Now the system.err does not get cluttered though we performed the necessary recovery actions. The error message string can be recovered by calling getMessage() if needed.
>     
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-6267105
>
> Webrev:
> http://cr.openjdk.java.net/~aghaisas/shashi/6267105/webrev_00/
>
> Thanks and regards,
> Shashi



From philip.race at oracle.com  Mon Jun 12 18:26:05 2017
From: philip.race at oracle.com (Philip Race)
Date: Mon, 12 Jun 2017 11:26:05 -0700
Subject: <Swing Dev> [10] RFR JDK-6267105:UIDefaults.getUIError dumps
 error message to System.err and also throws Error.
In-Reply-To: <c2655a81-8016-4ab5-b44c-e5e158de8a51@default>
References: <c2655a81-8016-4ab5-b44c-e5e158de8a51@default>
Message-ID: <593EDCBD.3030904@oracle.com>

The change is fine. If you can't find a way to easily write a regression 
test
(not sure this bug merits a lot of effort in that direction), then mark the
bug with an appropriate label.

-phil.

On 6/12/17, 3:54 AM, Shashidhara Veerabhadraiah wrote:
> Hi All,
> 	Please review the code bug fix for JDK-6267105:UIDefaults.getUIError dumps error message to System.err and also throws Error.
>
> Issue:
>       Error message was getting dumped to the system.err even though the recovery actions were performed leading to unnecessary confusion regarding the actual behavior.
>
> Fix:
>      This fix removes the call which prints the message to the system.err and stores the message in the Error class. This same message can be retrieved after we catch the error and calling getMessage() of the Error class. Through catching the error, the user can perform necessary recovery actions without cluttering the system.err. This fix does not modifies the 'user effect' as the user would still get the same error as they were getting before this fix.
>
> Test:
>      Now the system.err does not get cluttered though we performed the necessary recovery actions. The error message string can be recovered by calling getMessage() if needed.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-6267105
>
> Webrev:
> http://cr.openjdk.java.net/~aghaisas/shashi/6267105/webrev_00/
>
> Thanks and regards,
> Shashi


From philip.race at oracle.com  Mon Jun 12 18:32:24 2017
From: philip.race at oracle.com (Philip Race)
Date: Mon, 12 Jun 2017 11:32:24 -0700
Subject: <Swing Dev> [9] Review Request: 8181877 Cleanup of javadoc in
 javax.accessibility package
In-Reply-To: <b92f77d7-a7ff-4ed3-bb23-ac94f900cff8@default>
References: <b92f77d7-a7ff-4ed3-bb23-ac94f900cff8@default>
Message-ID: <593EDE38.9000902@oracle.com>

A couple of non-critical comments and I don't need to see an updated webrev
for it if you choose to make the changes below.


1)
I know they are only examples but maybe replace sun.com in the various
places it is used (eg this one below), with openjdk.java.net ?


89      * HREF="http://www.sun.com/access"&gt;Accessibility&lt;/a&gt; this method
   90      * would return a java.net.URL("http://www.sun.com/access.html");

2) http://cr.openjdk.java.net/~serb/8181877/webrev.00/src/java.desktop/share/classes/javax/accessibility/AccessibleValue.java.sdiff.html

66     // /**
   67     // * Get the description of the value of this object.
   68     // *
   69     // * @return description of the value of the object
   70     // */
   71     // public String getAccessibleValueDescription();

Instead of fixing the indentation .. why can't this just be deleted.

-phil.



On 6/9/17, 12:34 PM, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk9.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8181877
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8181877/webrev.00
> Specdiff: http://cr.openjdk.java.net/~serb/8181877/specdiff.00/overview-summary.html
>
> In this fix the javadoc is updated and the next rules were applied:
>   -<tag>  should be replaced by {@tag }
>   - 80 column limit
>   - description of the class/method/field should be followed by dot
>   - @param, @return should not end with a dot, except a case when more than one sentences are used
>   - empty line after description/before the first tag was added
>   - unnecessary empty lines were removed
>   - sets of spaces in the middle of text were deleted
>   - @param, @throws, @return should be aligned, to be more readable
>   - unnecessary imports should be removed
>   - the "null"/"true"/"false"/"this"/"ClassName" should be wrapped in {@code } when necessary
>   - the order of different tags were unified across the package
> There are also some mixing of different "reference usage", for example "InputStream" vs "input stream", "String" vs "string", etc. I tried to fix some of them.
>
> During the cleanup I found that some of the specs are outdated, for example "package-summary" contains incorrect number of classes/interfaces. In such cases I leaved the spec as-is with intention to rework the text later.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170612/d53f458e/attachment.html>

From prasanta.sadhukhan at oracle.com  Wed Jun 14 05:39:15 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 14 Jun 2017 11:09:15 +0530
Subject: <Swing Dev> [10] RFR JDK-8075063:Context menu closes on mouse scroll
Message-ID: <8c997c2e-bf01-7957-22fa-43ac18e9ca88@oracle.com>

Hi All,

Please review a fix for an issue whereby it is seen
hitting the scroll wheel by accident closes whole structure of context 
menus causing it to disappear and the user has to invoke the menu again.

Issue was popupMenu is getting closed for mouse wheel rotation if the 
menu is not from JComboBox.
If the context menu is opened from JMenuItem, JMenu then if the mouse 
wheel is rotated anywhere in frame, then it calls cancelPopupMenu() 
causing it to call setVisible(false) and so menu disappears.

Proposed fix is to check if the mouse wheel rotation is done in JMenu, 
JMenuItem or anywhere in frame, then if popup is present, then do not 
close the popupmenu.

Bug: https://bugs.openjdk.java.net/browse/JDK-8075063
webrev: http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.00/

Regards
Prasanta



From prasanta.sadhukhan at oracle.com  Wed Jun 14 06:33:21 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 14 Jun 2017 12:03:21 +0530
Subject: <Swing Dev> [10] JDK-8182031: Swing's ComboBox Popup opens and
	closes immediately
Message-ID: <f8a25a85-eec6-1cd4-0caa-131d2f47a5ff@oracle.com>

Hi All,

Please review a fix for an issue where it is seen that
when clicking the right-most pixel of a JComboBox the related Popup 
opens and closes immediately. This is non-standard behaviour.

Issue was, the bounds for popup was calculated 1 pixel short so 
rightmost edge was not considered.

Proposed fix is to increase the bounds by 1 pixel.
Bug: https://bugs.openjdk.java.net/browse/JDK-8182031
webrev: http://cr.openjdk.java.net/~psadhukhan/8182031/webrev.00/

Regards
Prasanta


From avik.niyogi at oracle.com  Wed Jun 14 06:37:47 2017
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Wed, 14 Jun 2017 12:07:47 +0530
Subject: <Swing Dev> [10] RFR: JDK-8181782:[TESTBUG] [Macosx]
	JTextAreaEmojiTest is not executed
In-Reply-To: <mailman.51.1497355201.13000.swing-dev@openjdk.java.net>
References: <mailman.51.1497355201.13000.swing-dev@openjdk.java.net>
Message-ID: <51C0E1CD-A1E5-4EBB-AFB6-7D70BE5DFC6F@oracle.com>

Fix looks good to me.

> On 13-Jun-2017, at 5:30 pm, swing-dev-request at openjdk.java.net wrote:
> 
> Date: Mon, 12 Jun 2017 07:21:13 -0700 (PDT)
> From: Sreeprakash Sreedharan <sreeprakash.s at oracle.com <mailto:sreeprakash.s at oracle.com>>
> To: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com>>,
> 	swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
> Subject: Re: <Swing Dev> [10] RFR: JDK-8181782:[TESTBUG] [Macosx]
> 	JTextAreaEmojiTest is not executed
> Message-ID: <9c1fbf5c-e872-414e-84c1-fa533a21e1aa at default>
> Content-Type: text/plain; charset=utf-8
> 
> Thanks for the inputs, Prasanta. 
> 
> I have incorporated the changes mentioned.
> 
> Updated Webrev :  http://cr.openjdk.java.net/~rpatil/8181782/webrev.01 <http://cr.openjdk.java.net/~rpatil/8181782/webrev.01>
> 
> Regards,
> Sreeprakash
> 
> -----Original Message-----
> From: Prasanta Sadhukhan 
> Sent: Monday, June 12, 2017 2:55 PM
> To: Sreeprakash Sreedharan <sreeprakash.s at oracle.com <mailto:sreeprakash.s at oracle.com>>; swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
> Subject: Re: <Swing Dev> [10] RFR: JDK-8181782:[TESTBUG] [Macosx] JTextAreaEmojiTest is not executed
> 
> It seems the test is waiting infinitely instead of having a timeout. I amnot sure of jtreg timeout but it's better to rely on test's own timeout, so await(timeout) is a better call .
> 
> Also, please add @key headful tag to the test.
> 
> Regards
> Prasanta
> On 6/9/2017 1:38 AM, Sreeprakash Sreedharan wrote:
>> Hi All,
>> 
>> Kindly review the fix for JDK10.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8181782 <https://bugs.openjdk.java.net/browse/JDK-8181782>
>> 
>> Webrev: http://cr.openjdk.java.net/~rpatil/8181782/webrev.00 <http://cr.openjdk.java.net/~rpatil/8181782/webrev.00>
>> 
>> Issue: JTREG was not executing the manual test JTextAreaEmojiTest and was always giving a passed result.
>> 
>> Fix: Made sure that main function waits for pass/fail events using a 
>> countdown latch and also added manual to the run tag
>> 
>> Regards,
>> Sreeprakash
> 

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

From prasanta.sadhukhan at oracle.com  Wed Jun 14 06:39:10 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 14 Jun 2017 12:09:10 +0530
Subject: <Swing Dev> [10] RFR: JDK-8181782:[TESTBUG] [Macosx]
 JTextAreaEmojiTest is not executed
In-Reply-To: <9c1fbf5c-e872-414e-84c1-fa533a21e1aa@default>
References: <3dce1cd6-9150-4209-9377-325531403130@default>
 <28680c63-44c2-8681-8469-cc93be3b91a9@oracle.com>
 <9c1fbf5c-e872-414e-84c1-fa533a21e1aa@default>
Message-ID: <1e28ea0e-5fc6-9191-1ed7-98777930f4f2@oracle.com>

Looks good to me. Only thing is in my opinion, 5 min timeout is too 
much. I guess 1 minutes should be sufficient. No need for webrev if you 
consider to make that change.

Regards
Prasanta
On 6/12/2017 7:51 PM, Sreeprakash Sreedharan wrote:
> Thanks for the inputs, Prasanta.
>
> I have incorporated the changes mentioned.
>
> Updated Webrev :  http://cr.openjdk.java.net/~rpatil/8181782/webrev.01
>
> Regards,
> Sreeprakash
>
> -----Original Message-----
> From: Prasanta Sadhukhan
> Sent: Monday, June 12, 2017 2:55 PM
> To: Sreeprakash Sreedharan <sreeprakash.s at oracle.com>; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [10] RFR: JDK-8181782:[TESTBUG] [Macosx] JTextAreaEmojiTest is not executed
>
> It seems the test is waiting infinitely instead of having a timeout. I amnot sure of jtreg timeout but it's better to rely on test's own timeout, so await(timeout) is a better call .
>
> Also, please add @key headful tag to the test.
>
> Regards
> Prasanta
> On 6/9/2017 1:38 AM, Sreeprakash Sreedharan wrote:
>> Hi All,
>>
>> Kindly review the fix for JDK10.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8181782
>>
>> Webrev: http://cr.openjdk.java.net/~rpatil/8181782/webrev.00
>>
>> Issue: JTREG was not executing the manual test JTextAreaEmojiTest and was always giving a passed result.
>>
>> Fix: Made sure that main function waits for pass/fail events using a
>> countdown latch and also added manual to the run tag
>>
>> Regards,
>> Sreeprakash



From alexander.zvegintsev at oracle.com  Wed Jun 14 07:04:04 2017
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Wed, 14 Jun 2017 12:34:04 +0530
Subject: <Swing Dev> [10] RFR: JDK-8043315: Nimbus: Setting
 Nimbus.Overrides property affects custom keymap installation
In-Reply-To: <8af41cf8-f51a-6322-9664-6d45fc640a80@oracle.com>
References: <54afabea-f351-4fd5-860a-29bd293b2c6d@default>
 <8af41cf8-f51a-6322-9664-6d45fc640a80@oracle.com>
Message-ID: <67b025e2-2134-a1fb-8769-078ff1f14081@oracle.com>

Hi Prasanta,

> If app again calls setKeymap(null) then the static variable will be 
> "true" and it will reset back to default keymap. 
It doesn't seem to be relevant to this fix. setKeymap(): " Setting to 
<code>null</code> effectively disables keyboard input." As it does with 
you fix.

Otherwise the fix looks good to me.

Thanks,
Alexander.

On 02/06/2017 13:59, Prasanta Sadhukhan wrote:
> Hi Sergey,
>
> I have modified webrev to remove static keyword and made the test 
> automated
> http://cr.openjdk.java.net/~psadhukhan/8043315/webrev.01/
> Updated fix tests if app has fired a property change by calling 
> setKeymap() then it will not uninstall custom keymap and let the 
> custom keymap be honoured. If app again calls setKeymap(null) then the 
> static variable will be "true" and it will reset back to default keymap.
>
> Regards
> Prasanta
> On 6/2/2017 12:07 AM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>> Can you please clarify the fix a little bit.
>> You have a static variable, which is set to "false" when the listener 
>> for "keymap" is triggered, and it seems that you never set it back to 
>> "true"? Is it intentional behavior?
>> Note that if there are a few objects of "SynthEditorPaneUI" then they 
>> will share this static field. Also it seems that the test can be 
>> automated, because currently it is requires from the user to press 
>> only one button("space").
>>
>> ----- prasanta.sadhukhan at oracle.com wrote:
>>
>>> Hi All,
>>>
>>> Please review a bug fix for Nimbus L&F where if app sets custom keymap
>>>
>>> and then sets Nimbus.Overrides property,
>>> then the custom keymap is not honoured.
>>> For example, if testapp sets a new action for "space" key press and
>>> sets
>>> sets Nimbus.Overrides property,
>>>    it will not be honoured and default action ie. inserting a "space"
>>> character will be done.
>>>
>>> Issue was NimbusLookAndFeel#shouldUpdateStyleOnEvent() returns true
>>> for
>>> Nimbus.Override property which causes SynthEditorPaneUI#updateStyle()
>>> to
>>> be called which
>>> uninstall set keyboard actions and sets up default keyboard action.
>>>
>>> Proposed fix is to check if a keymap is already set (a propertyChange
>>>
>>> event will be fired for when app calls setKeyMap()) then do not reset
>>> to
>>> default keymap.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8043315
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8043315/webrev.00/
>>>
>>> Regards
>>> Prasanta
>



From alexander.zvegintsev at oracle.com  Wed Jun 14 08:26:12 2017
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Wed, 14 Jun 2017 13:56:12 +0530
Subject: <Swing Dev> [10] JDK-8182031: Swing's ComboBox Popup opens and
 closes immediately
In-Reply-To: <f8a25a85-eec6-1cd4-0caa-131d2f47a5ff@oracle.com>
References: <f8a25a85-eec6-1cd4-0caa-131d2f47a5ff@oracle.com>
Message-ID: <b9da85ae-13e7-a5a7-f83c-33ce2d579eb5@oracle.com>

Looks good to me.

Thanks,
Alexander.

On 14/06/2017 12:03, Prasanta Sadhukhan wrote:
> Hi All,
>
> Please review a fix for an issue where it is seen that
> when clicking the right-most pixel of a JComboBox the related Popup 
> opens and closes immediately. This is non-standard behaviour.
>
> Issue was, the bounds for popup was calculated 1 pixel short so 
> rightmost edge was not considered.
>
> Proposed fix is to increase the bounds by 1 pixel.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8182031
> webrev: http://cr.openjdk.java.net/~psadhukhan/8182031/webrev.00/
>
> Regards
> Prasanta



From semyon.sadetsky at oracle.com  Wed Jun 14 14:56:37 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 14 Jun 2017 07:56:37 -0700
Subject: <Swing Dev> [10] RFR JDK-8075063:Context menu closes on mouse
 scroll
In-Reply-To: <8c997c2e-bf01-7957-22fa-43ac18e9ca88@oracle.com>
References: <8c997c2e-bf01-7957-22fa-43ac18e9ca88@oracle.com>
Message-ID: <be992d75-65cb-8c55-f3e6-d3685f5fa0e0@oracle.com>

Hi Prasanta,

I may be wrong, but it seems to me that the standard behavior is when 
any wheel event cannot close popups.

--Semyon


On 06/13/2017 10:39 PM, Prasanta Sadhukhan wrote:
> Hi All,
>
> Please review a fix for an issue whereby it is seen
> hitting the scroll wheel by accident closes whole structure of context 
> menus causing it to disappear and the user has to invoke the menu again.
>
> Issue was popupMenu is getting closed for mouse wheel rotation if the 
> menu is not from JComboBox.
> If the context menu is opened from JMenuItem, JMenu then if the mouse 
> wheel is rotated anywhere in frame, then it calls cancelPopupMenu() 
> causing it to call setVisible(false) and so menu disappears.
>
> Proposed fix is to check if the mouse wheel rotation is done in JMenu, 
> JMenuItem or anywhere in frame, then if popup is present, then do not 
> close the popupmenu.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8075063
> webrev: http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.00/
>
> Regards
> Prasanta
>



From prasanta.sadhukhan at oracle.com  Thu Jun 15 04:54:28 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 15 Jun 2017 10:24:28 +0530
Subject: <Swing Dev> [10] RFR JDK-8075063:Context menu closes on mouse
 scroll
In-Reply-To: <be992d75-65cb-8c55-f3e6-d3685f5fa0e0@oracle.com>
References: <8c997c2e-bf01-7957-22fa-43ac18e9ca88@oracle.com>
 <be992d75-65cb-8c55-f3e6-d3685f5fa0e0@oracle.com>
Message-ID: <9c06120b-c8c0-6ee2-048b-5626f9bea344@oracle.com>

Hi Semyon,

I tried on Firefox and other app. If popup or drop down menu is opened, 
then mouse wheel rotation is not closing the popups. In our case, it is 
closing the popups/menus.

Regards
Prasanta
On 6/14/2017 8:26 PM, Semyon Sadetsky wrote:
> Hi Prasanta,
>
> I may be wrong, but it seems to me that the standard behavior is when 
> any wheel event cannot close popups.
>
> --Semyon
>
>
> On 06/13/2017 10:39 PM, Prasanta Sadhukhan wrote:
>> Hi All,
>>
>> Please review a fix for an issue whereby it is seen
>> hitting the scroll wheel by accident closes whole structure of 
>> context menus causing it to disappear and the user has to invoke the 
>> menu again.
>>
>> Issue was popupMenu is getting closed for mouse wheel rotation if the 
>> menu is not from JComboBox.
>> If the context menu is opened from JMenuItem, JMenu then if the mouse 
>> wheel is rotated anywhere in frame, then it calls cancelPopupMenu() 
>> causing it to call setVisible(false) and so menu disappears.
>>
>> Proposed fix is to check if the mouse wheel rotation is done in 
>> JMenu, JMenuItem or anywhere in frame, then if popup is present, then 
>> do not close the popupmenu.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075063
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.00/
>>
>> Regards
>> Prasanta
>>
>



From prasanta.sadhukhan at oracle.com  Thu Jun 15 08:00:18 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 15 Jun 2017 13:30:18 +0530
Subject: <Swing Dev> [10] RFR JDK-8181421: 3 regtest fail on windows7 in
 Nimbus L&F
In-Reply-To: <0b293f12-e1ad-f439-00e7-e3811e3275c4@oracle.com>
References: <7194c05f-f147-4df8-8947-7053a3d1d60b@default>
 <0b293f12-e1ad-f439-00e7-e3811e3275c4@oracle.com>
Message-ID: <6cfbbf29-a2e2-de70-fb03-00e0f7c0de04@oracle.com>

Modified webrev removing html and relying on main-based tests

http://cr.openjdk.java.net/~psadhukhan/8181421/webrev.02/


Regards
Prasanta
On 6/5/2017 4:56 PM, Prasanta Sadhukhan wrote:
>
> Hi Sergey,
>
>
> It seems when SynthPanel.updateStyle is called,
>
> private void updateStyle(JPanel c) {
>         SynthContext context = getContext(c, ENABLED);
>         style = SynthLookAndFeel.updateStyle(context, this);
>     }
> it calls getContext() which in turn calls SynthContext.getContext() 
> with style variable.
> private SynthContext getContext(JComponent c, int state) {
>         return SynthContext.getContext(c, style, state);
>     }
> Now, "style"  variable seems to be null at this point in 
> SYnthPanelUI.java and
> it only gets updated after getContext() call when it calls then next 
> line SynthLookAndFeel.updateStyle(context, this);
>
> I could not remove the html file as I am getting some serialization 
> issue if I moved from applet to main based so I retained applet based 
> test, as of now. Also, due to it being applet, I am not sure how to 
> run them over installed l&f inside the test.
>
> Modified webrev with test issues rectfied
> http://cr.openjdk.java.net/~psadhukhan/8181421/webrev.01/
>
> Regards
> Prasanta
> On 6/2/2017 1:35 AM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>> I have few small notes.
>>  - Did you check why the null value was passed to this method?
>>  - It seems that the tests are passed by default. It would be good to 
>> run them over the installed l&f. In this case they will fail before 
>> the fix.
>>  - Is it possible to remove the html files from the tests?
>>  - The tests also have some common issues, the Swing components are 
>> accessed on non-edt thread. some unnecessary commented code, etc.
>>
>> ----- prasanta.sadhukhan at oracle.com wrote:
>> >
>>
>> Hi All,
>>
>> Please review a subitem fix of JDK-7190554 
>> <https://bugs.openjdk.java.net/browse/JDK-7190554> where some closed 
>> regression test is failing with Nimbus L&F.
>>
>> Issue was we were getting NPE
>> > which is because a null style was used in SynthPanelUI to generate 
>> the SynthContext
>> >
>> > java.lang.NullPointerException: You must supply a non-null 
>> component, region and style
>> >     at 
>> java.desktop/javax.swing.plaf.synth.SynthContext.getContext(SynthContext.java:58)
>> >     at 
>> java.desktop/javax.swing.plaf.synth.SynthContext.getContext(SynthContext.java:49)
>> >     at 
>> java.desktop/javax.swing.plaf.synth.SynthPanelUI.getContext(SynthPanelUI.java:128)
>> >     at 
>> java.desktop/javax.swing.plaf.synth.SynthPanelUI.updateStyle(SynthPanelUI.java:115)
>> >     at 
>> java.desktop/javax.swing.plaf.synth.SynthPanelUI.installDefaults(SynthPanelUI.java:100)
>> >
>> > Proposed fix is to generate a style before generating SynthContext 
>> because as per spec,
>> > 
>> https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/plaf/synth/SynthContext.html
>> > it should throw NPE||- if component, region or style is null.
>> >
>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8181421
>> > webrev: http://cr.openjdk.java.net/~psadhukhan/8181421/webrev.00/
>> >
>> > Regards
>> > Prasanta
>> >
>

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

From shashidhara.veerabhadraiah at oracle.com  Thu Jun 15 09:10:16 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Thu, 15 Jun 2017 02:10:16 -0700 (PDT)
Subject: <Swing Dev> [9] JDK-8165213: [TESTBUG] [PIT] consistent failure
 of a new regtest for 8163193
In-Reply-To: <D7F421A7-B1F6-4C06-A330-08C6B89ED052@oracle.com>
References: <e5caac0a-b6b8-4b02-9a3e-ece26162d3ef@default>
 <D7F421A7-B1F6-4C06-A330-08C6B89ED052@oracle.com>
Message-ID: <d1be7dfa-bda4-437b-a152-a4a0c5c9384f@default>

Hi Sergey,  The color profile on mac was generic RGB. Moreover the robot api takes the co-ordinates as input as against my implementation which takes the component as input and hence we always get the exact component image onto the buffered image. The component's coordinates may vary depending on the location of the task bar like on mac or linux(ubuntu), hence the supplied co-ordinates may go awry. I feel that capturing the component directly onto the buffered image is better considering the cross platforms. Please let me know if you feel otherwise.

 

Below is the image comparison between the windows(top) and linux(below), snapshot that was captured onto the buffered image as a png file. I see that the linux component is slightly bigger by around 4 pixel width(approx.). I think this is the reason behind the color differences across the platforms and the same reason why mac has color differences at the same location when compared with windows one. Same location means that the program supplies a size of 300 * 300 width component and the location where we extract the color is calculated automatically based on the component size.

 



 

I am not sure why there is a change in width. I am not sure should I continue to debug in that direction or not!!

 

This is the logical explanation that I could achieve for the color tolerance band that was used in the program. So please let me know what do you think of this.

 

Thanks and regards,

Shashi

 

-----Original Message-----
From: Sergey Bylokhov 
Sent: Thursday, June 8, 2017 1:12 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
Cc: swing-dev at openjdk.java.net; Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>
Subject: Re: [9] JDK-8165213: [TESTBUG] [PIT] consistent failure of a new regtest for 8163193

 

On what color profiles the test is executed? On macOS it should be Generic RGB. Also in jdk9 the new robot api for HiDPI was added, please try it also.

If it solve the problem on Mac then I suggest to try to investigate a problem on Linux and fix it if possible, instead of tweaking the test.

 

> 

> Hi All,

>             Please review fix for JDK-8165213 where there is a consistent failure while testing for gradient color of the button.

> 

> Issue: The Robot's function to get the pixel's RGB values has an issue with its implementation and is currently getting resolved. Because of this issue, we are getting incorrect RGB values for the requested pixel and hence the test is getting failed.

> 

> Resolution\Fix: There is an alternate mechanism to capture the image to a buffer and use the buffer function to get the RGB values. This test is for HiDpi displays. In the image space, the images won't be scaled implicitly and hence they need to be applied with the scaling in the graphics space before painting on to the image buffer. This same is implemented.

> Based on the test outputs, the tolerance band for color comparison is set at 11.

> 

> Test outputs: 

> 1. On a windows system, the pixel color values exactly matches.

> 2. On a Linux system, the pixel color values vary by a maximum difference of around 6.

> 3. On a mac system, the pixel color values vary by a maximum difference of around 10.

> 

> Bug: https://bugs.openjdk.java.net/browse/JDK-8165213

> Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/8165213/webrev_01/

> 

> Thanks and regards,

> Shashi

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170615/c08eb5b0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 73139 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170615/c08eb5b0/image001.jpg>

From semyon.sadetsky at oracle.com  Thu Jun 15 15:10:28 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 15 Jun 2017 08:10:28 -0700
Subject: <Swing Dev> [10] RFR JDK-8075063:Context menu closes on mouse
 scroll
In-Reply-To: <9c06120b-c8c0-6ee2-048b-5626f9bea344@oracle.com>
References: <8c997c2e-bf01-7957-22fa-43ac18e9ca88@oracle.com>
 <be992d75-65cb-8c55-f3e6-d3685f5fa0e0@oracle.com>
 <9c06120b-c8c0-6ee2-048b-5626f9bea344@oracle.com>
Message-ID: <04fa0a6c-6302-64f9-e6c7-f5342acab758@oracle.com>

On 06/14/2017 09:54 PM, Prasanta Sadhukhan wrote:
> Hi Semyon,
>
> I tried on Firefox and other app. If popup or drop down menu is 
> opened, then mouse wheel rotation is not closing the popups. In our 
> case, it is closing the popups/menus.
That is true. I meant you fixed only the case when the mouse wheel 
rotation is over java windows (wheel event's source != null). What will 
be if the wheel is rotated outside java (source == null), or it is not 
the case?

--Semyon
>
> Regards
> Prasanta
> On 6/14/2017 8:26 PM, Semyon Sadetsky wrote:
>> Hi Prasanta,
>>
>> I may be wrong, but it seems to me that the standard behavior is when 
>> any wheel event cannot close popups.
>>
>> --Semyon
>>
>>
>> On 06/13/2017 10:39 PM, Prasanta Sadhukhan wrote:
>>> Hi All,
>>>
>>> Please review a fix for an issue whereby it is seen
>>> hitting the scroll wheel by accident closes whole structure of 
>>> context menus causing it to disappear and the user has to invoke the 
>>> menu again.
>>>
>>> Issue was popupMenu is getting closed for mouse wheel rotation if 
>>> the menu is not from JComboBox.
>>> If the context menu is opened from JMenuItem, JMenu then if the 
>>> mouse wheel is rotated anywhere in frame, then it calls 
>>> cancelPopupMenu() causing it to call setVisible(false) and so menu 
>>> disappears.
>>>
>>> Proposed fix is to check if the mouse wheel rotation is done in 
>>> JMenu, JMenuItem or anywhere in frame, then if popup is present, 
>>> then do not close the popupmenu.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075063
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.00/
>>>
>>> Regards
>>> Prasanta
>>>
>>
>



From prasanta.sadhukhan at oracle.com  Thu Jun 15 15:18:41 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 15 Jun 2017 20:48:41 +0530
Subject: <Swing Dev> [10] RFR JDK-8075063:Context menu closes on mouse
 scroll
In-Reply-To: <04fa0a6c-6302-64f9-e6c7-f5342acab758@oracle.com>
References: <8c997c2e-bf01-7957-22fa-43ac18e9ca88@oracle.com>
 <be992d75-65cb-8c55-f3e6-d3685f5fa0e0@oracle.com>
 <9c06120b-c8c0-6ee2-048b-5626f9bea344@oracle.com>
 <04fa0a6c-6302-64f9-e6c7-f5342acab758@oracle.com>
Message-ID: <6f4d381f-1be5-7bca-6a7e-a17d621c85b1@oracle.com>



On 6/15/2017 8:40 PM, Semyon Sadetsky wrote:
> On 06/14/2017 09:54 PM, Prasanta Sadhukhan wrote:
>> Hi Semyon,
>>
>> I tried on Firefox and other app. If popup or drop down menu is 
>> opened, then mouse wheel rotation is not closing the popups. In our 
>> case, it is closing the popups/menus.
> That is true. I meant you fixed only the case when the mouse wheel 
> rotation is over java windows (wheel event's source != null). What 
> will be if the wheel is rotated outside java (source == null), or it 
> is not the case?
>
It is not closing in other app (if it rotated over non-app window) as 
well as in our java with my fix.

Regards
Prasanta
> --Semyon
>>
>> Regards
>> Prasanta
>> On 6/14/2017 8:26 PM, Semyon Sadetsky wrote:
>>> Hi Prasanta,
>>>
>>> I may be wrong, but it seems to me that the standard behavior is 
>>> when any wheel event cannot close popups.
>>>
>>> --Semyon
>>>
>>>
>>> On 06/13/2017 10:39 PM, Prasanta Sadhukhan wrote:
>>>> Hi All,
>>>>
>>>> Please review a fix for an issue whereby it is seen
>>>> hitting the scroll wheel by accident closes whole structure of 
>>>> context menus causing it to disappear and the user has to invoke 
>>>> the menu again.
>>>>
>>>> Issue was popupMenu is getting closed for mouse wheel rotation if 
>>>> the menu is not from JComboBox.
>>>> If the context menu is opened from JMenuItem, JMenu then if the 
>>>> mouse wheel is rotated anywhere in frame, then it calls 
>>>> cancelPopupMenu() causing it to call setVisible(false) and so menu 
>>>> disappears.
>>>>
>>>> Proposed fix is to check if the mouse wheel rotation is done in 
>>>> JMenu, JMenuItem or anywhere in frame, then if popup is present, 
>>>> then do not close the popupmenu.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075063
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.00/
>>>>
>>>> Regards
>>>> Prasanta
>>>>
>>>
>>
>



From semyon.sadetsky at oracle.com  Thu Jun 15 15:25:38 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 15 Jun 2017 08:25:38 -0700
Subject: <Swing Dev> [10] RFR JDK-8075063:Context menu closes on mouse
 scroll
In-Reply-To: <6f4d381f-1be5-7bca-6a7e-a17d621c85b1@oracle.com>
References: <8c997c2e-bf01-7957-22fa-43ac18e9ca88@oracle.com>
 <be992d75-65cb-8c55-f3e6-d3685f5fa0e0@oracle.com>
 <9c06120b-c8c0-6ee2-048b-5626f9bea344@oracle.com>
 <04fa0a6c-6302-64f9-e6c7-f5342acab758@oracle.com>
 <6f4d381f-1be5-7bca-6a7e-a17d621c85b1@oracle.com>
Message-ID: <17c5c10e-d0ad-c278-a9ab-038192b34fc6@oracle.com>

On 06/15/2017 08:18 AM, Prasanta Sadhukhan wrote:

>
>
> On 6/15/2017 8:40 PM, Semyon Sadetsky wrote:
>> On 06/14/2017 09:54 PM, Prasanta Sadhukhan wrote:
>>> Hi Semyon,
>>>
>>> I tried on Firefox and other app. If popup or drop down menu is 
>>> opened, then mouse wheel rotation is not closing the popups. In our 
>>> case, it is closing the popups/menus.
>> That is true. I meant you fixed only the case when the mouse wheel 
>> rotation is over java windows (wheel event's source != null). What 
>> will be if the wheel is rotated outside java (source == null), or it 
>> is not the case?
>>
> It is not closing in other app (if it rotated over non-app window) as 
> well as in our java with my fix.
Did you check this on all platforms? At least on my Ubuntu it is not so.

--Semyon
>
> Regards
> Prasanta
>> --Semyon
>>>
>>> Regards
>>> Prasanta
>>> On 6/14/2017 8:26 PM, Semyon Sadetsky wrote:
>>>> Hi Prasanta,
>>>>
>>>> I may be wrong, but it seems to me that the standard behavior is 
>>>> when any wheel event cannot close popups.
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 06/13/2017 10:39 PM, Prasanta Sadhukhan wrote:
>>>>> Hi All,
>>>>>
>>>>> Please review a fix for an issue whereby it is seen
>>>>> hitting the scroll wheel by accident closes whole structure of 
>>>>> context menus causing it to disappear and the user has to invoke 
>>>>> the menu again.
>>>>>
>>>>> Issue was popupMenu is getting closed for mouse wheel rotation if 
>>>>> the menu is not from JComboBox.
>>>>> If the context menu is opened from JMenuItem, JMenu then if the 
>>>>> mouse wheel is rotated anywhere in frame, then it calls 
>>>>> cancelPopupMenu() causing it to call setVisible(false) and so menu 
>>>>> disappears.
>>>>>
>>>>> Proposed fix is to check if the mouse wheel rotation is done in 
>>>>> JMenu, JMenuItem or anywhere in frame, then if popup is present, 
>>>>> then do not close the popupmenu.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075063
>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.00/
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>>
>>>>
>>>
>>
>



From prasanta.sadhukhan at oracle.com  Fri Jun 16 10:22:06 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 16 Jun 2017 15:52:06 +0530
Subject: <Swing Dev> [10] RFR JDK-8075063:Context menu closes on mouse
 scroll
In-Reply-To: <17c5c10e-d0ad-c278-a9ab-038192b34fc6@oracle.com>
References: <8c997c2e-bf01-7957-22fa-43ac18e9ca88@oracle.com>
 <be992d75-65cb-8c55-f3e6-d3685f5fa0e0@oracle.com>
 <9c06120b-c8c0-6ee2-048b-5626f9bea344@oracle.com>
 <04fa0a6c-6302-64f9-e6c7-f5342acab758@oracle.com>
 <6f4d381f-1be5-7bca-6a7e-a17d621c85b1@oracle.com>
 <17c5c10e-d0ad-c278-a9ab-038192b34fc6@oracle.com>
Message-ID: <0a7b852c-4c78-81ca-b2f6-ba1bb69736af@oracle.com>

Yes, it is failing in linux as it posts a UngrabEvent which causes the 
popup to be closed in BasicPopupMenuUI at eventDispatched()

if(ev instanceof sun.awt.UngrabEvent) {
                 // Popup should be canceled in case of ungrab event
                 cancelPopupMenu( );
                 return;
             }
I have modified to not post the ungrab event if mouse wheel is rotated 
by checking if button 4 or 5 is pressed or not.
as per https://stackoverflow.com/questions/15510472/scrollwheel-event-in-x11
and
ftp://www.x.org/pub/X11R6.8.0/doc/mouse.4.html [Wheel button events 
(typically buttons 4 and 5) are usually used for scrolling]

http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.01/

Regards
Prasanta
On 6/15/2017 8:55 PM, Semyon Sadetsky wrote:
> On 06/15/2017 08:18 AM, Prasanta Sadhukhan wrote:
>
>>
>>
>> On 6/15/2017 8:40 PM, Semyon Sadetsky wrote:
>>> On 06/14/2017 09:54 PM, Prasanta Sadhukhan wrote:
>>>> Hi Semyon,
>>>>
>>>> I tried on Firefox and other app. If popup or drop down menu is 
>>>> opened, then mouse wheel rotation is not closing the popups. In our 
>>>> case, it is closing the popups/menus.
>>> That is true. I meant you fixed only the case when the mouse wheel 
>>> rotation is over java windows (wheel event's source != null). What 
>>> will be if the wheel is rotated outside java (source == null), or it 
>>> is not the case?
>>>
>> It is not closing in other app (if it rotated over non-app window) as 
>> well as in our java with my fix.
> Did you check this on all platforms? At least on my Ubuntu it is not so.
>
> --Semyon
>>
>> Regards
>> Prasanta
>>> --Semyon
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 6/14/2017 8:26 PM, Semyon Sadetsky wrote:
>>>>> Hi Prasanta,
>>>>>
>>>>> I may be wrong, but it seems to me that the standard behavior is 
>>>>> when any wheel event cannot close popups.
>>>>>
>>>>> --Semyon
>>>>>
>>>>>
>>>>> On 06/13/2017 10:39 PM, Prasanta Sadhukhan wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Please review a fix for an issue whereby it is seen
>>>>>> hitting the scroll wheel by accident closes whole structure of 
>>>>>> context menus causing it to disappear and the user has to invoke 
>>>>>> the menu again.
>>>>>>
>>>>>> Issue was popupMenu is getting closed for mouse wheel rotation if 
>>>>>> the menu is not from JComboBox.
>>>>>> If the context menu is opened from JMenuItem, JMenu then if the 
>>>>>> mouse wheel is rotated anywhere in frame, then it calls 
>>>>>> cancelPopupMenu() causing it to call setVisible(false) and so 
>>>>>> menu disappears.
>>>>>>
>>>>>> Proposed fix is to check if the mouse wheel rotation is done in 
>>>>>> JMenu, JMenuItem or anywhere in frame, then if popup is present, 
>>>>>> then do not close the popupmenu.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075063
>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.00/
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>>
>>>>>
>>>>
>>>
>>
>



From semyon.sadetsky at oracle.com  Fri Jun 16 15:27:49 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 16 Jun 2017 08:27:49 -0700
Subject: <Swing Dev> [10] RFR JDK-8075063:Context menu closes on mouse
 scroll
In-Reply-To: <0a7b852c-4c78-81ca-b2f6-ba1bb69736af@oracle.com>
References: <8c997c2e-bf01-7957-22fa-43ac18e9ca88@oracle.com>
 <be992d75-65cb-8c55-f3e6-d3685f5fa0e0@oracle.com>
 <9c06120b-c8c0-6ee2-048b-5626f9bea344@oracle.com>
 <04fa0a6c-6302-64f9-e6c7-f5342acab758@oracle.com>
 <6f4d381f-1be5-7bca-6a7e-a17d621c85b1@oracle.com>
 <17c5c10e-d0ad-c278-a9ab-038192b34fc6@oracle.com>
 <0a7b852c-4c78-81ca-b2f6-ba1bb69736af@oracle.com>
Message-ID: <f5914b14-e791-5a9a-2ad5-56a172719488@oracle.com>

In lines 2337 and 2345 ungrab is also sent. Shouldn't the button number 
be checked there as well before ungrab?

--Semyon


On 06/16/2017 03:22 AM, Prasanta Sadhukhan wrote:
> Yes, it is failing in linux as it posts a UngrabEvent which causes the 
> popup to be closed in BasicPopupMenuUI at eventDispatched()
>
> if(ev instanceof sun.awt.UngrabEvent) {
>                 // Popup should be canceled in case of ungrab event
>                 cancelPopupMenu( );
>                 return;
>             }
> I have modified to not post the ungrab event if mouse wheel is rotated 
> by checking if button 4 or 5 is pressed or not.
> as per 
> https://stackoverflow.com/questions/15510472/scrollwheel-event-in-x11
> and
> ftp://www.x.org/pub/X11R6.8.0/doc/mouse.4.html [Wheel button events 
> (typically buttons 4 and 5) are usually used for scrolling]
>
> http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.01/
>
> Regards
> Prasanta
> On 6/15/2017 8:55 PM, Semyon Sadetsky wrote:
>> On 06/15/2017 08:18 AM, Prasanta Sadhukhan wrote:
>>
>>>
>>>
>>> On 6/15/2017 8:40 PM, Semyon Sadetsky wrote:
>>>> On 06/14/2017 09:54 PM, Prasanta Sadhukhan wrote:
>>>>> Hi Semyon,
>>>>>
>>>>> I tried on Firefox and other app. If popup or drop down menu is 
>>>>> opened, then mouse wheel rotation is not closing the popups. In 
>>>>> our case, it is closing the popups/menus.
>>>> That is true. I meant you fixed only the case when the mouse wheel 
>>>> rotation is over java windows (wheel event's source != null). What 
>>>> will be if the wheel is rotated outside java (source == null), or 
>>>> it is not the case?
>>>>
>>> It is not closing in other app (if it rotated over non-app window) 
>>> as well as in our java with my fix.
>> Did you check this on all platforms? At least on my Ubuntu it is not so.
>>
>> --Semyon
>>>
>>> Regards
>>> Prasanta
>>>> --Semyon
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 6/14/2017 8:26 PM, Semyon Sadetsky wrote:
>>>>>> Hi Prasanta,
>>>>>>
>>>>>> I may be wrong, but it seems to me that the standard behavior is 
>>>>>> when any wheel event cannot close popups.
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>>
>>>>>> On 06/13/2017 10:39 PM, Prasanta Sadhukhan wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Please review a fix for an issue whereby it is seen
>>>>>>> hitting the scroll wheel by accident closes whole structure of 
>>>>>>> context menus causing it to disappear and the user has to invoke 
>>>>>>> the menu again.
>>>>>>>
>>>>>>> Issue was popupMenu is getting closed for mouse wheel rotation 
>>>>>>> if the menu is not from JComboBox.
>>>>>>> If the context menu is opened from JMenuItem, JMenu then if the 
>>>>>>> mouse wheel is rotated anywhere in frame, then it calls 
>>>>>>> cancelPopupMenu() causing it to call setVisible(false) and so 
>>>>>>> menu disappears.
>>>>>>>
>>>>>>> Proposed fix is to check if the mouse wheel rotation is done in 
>>>>>>> JMenu, JMenuItem or anywhere in frame, then if popup is present, 
>>>>>>> then do not close the popupmenu.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075063
>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.00/
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From prasanta.sadhukhan at oracle.com  Fri Jun 16 15:49:41 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 16 Jun 2017 21:19:41 +0530
Subject: <Swing Dev> [10] RFR JDK-8075063:Context menu closes on mouse
 scroll
In-Reply-To: <f5914b14-e791-5a9a-2ad5-56a172719488@oracle.com>
References: <8c997c2e-bf01-7957-22fa-43ac18e9ca88@oracle.com>
 <be992d75-65cb-8c55-f3e6-d3685f5fa0e0@oracle.com>
 <9c06120b-c8c0-6ee2-048b-5626f9bea344@oracle.com>
 <04fa0a6c-6302-64f9-e6c7-f5342acab758@oracle.com>
 <6f4d381f-1be5-7bca-6a7e-a17d621c85b1@oracle.com>
 <17c5c10e-d0ad-c278-a9ab-038192b34fc6@oracle.com>
 <0a7b852c-4c78-81ca-b2f6-ba1bb69736af@oracle.com>
 <f5914b14-e791-5a9a-2ad5-56a172719488@oracle.com>
Message-ID: <924dd4d2-44bd-480c-72e1-193c9761c6fc@oracle.com>

I was not sure about the scenario at what condition those ungrabs are 
sent, so I did not modify those. For wheel event outside our java window 
was the scenario here and my modification fixed that.

// According to the specification of UngrabEvent, post it
    // when press occurs outside of the window and not on its owned windows

Regards
Prasanta
On 6/16/2017 8:57 PM, Semyon Sadetsky wrote:
> In lines 2337 and 2345 ungrab is also sent. Shouldn't the button 
> number be checked there as well before ungrab?
>
> --Semyon
>
>
> On 06/16/2017 03:22 AM, Prasanta Sadhukhan wrote:
>> Yes, it is failing in linux as it posts a UngrabEvent which causes 
>> the popup to be closed in BasicPopupMenuUI at eventDispatched()
>>
>> if(ev instanceof sun.awt.UngrabEvent) {
>>                 // Popup should be canceled in case of ungrab event
>>                 cancelPopupMenu( );
>>                 return;
>>             }
>> I have modified to not post the ungrab event if mouse wheel is 
>> rotated by checking if button 4 or 5 is pressed or not.
>> as per 
>> https://stackoverflow.com/questions/15510472/scrollwheel-event-in-x11
>> and
>> ftp://www.x.org/pub/X11R6.8.0/doc/mouse.4.html [Wheel button events 
>> (typically buttons 4 and 5) are usually used for scrolling]
>>
>> http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.01/
>>
>> Regards
>> Prasanta
>> On 6/15/2017 8:55 PM, Semyon Sadetsky wrote:
>>> On 06/15/2017 08:18 AM, Prasanta Sadhukhan wrote:
>>>
>>>>
>>>>
>>>> On 6/15/2017 8:40 PM, Semyon Sadetsky wrote:
>>>>> On 06/14/2017 09:54 PM, Prasanta Sadhukhan wrote:
>>>>>> Hi Semyon,
>>>>>>
>>>>>> I tried on Firefox and other app. If popup or drop down menu is 
>>>>>> opened, then mouse wheel rotation is not closing the popups. In 
>>>>>> our case, it is closing the popups/menus.
>>>>> That is true. I meant you fixed only the case when the mouse wheel 
>>>>> rotation is over java windows (wheel event's source != null). What 
>>>>> will be if the wheel is rotated outside java (source == null), or 
>>>>> it is not the case?
>>>>>
>>>> It is not closing in other app (if it rotated over non-app window) 
>>>> as well as in our java with my fix.
>>> Did you check this on all platforms? At least on my Ubuntu it is not 
>>> so.
>>>
>>> --Semyon
>>>>
>>>> Regards
>>>> Prasanta
>>>>> --Semyon
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 6/14/2017 8:26 PM, Semyon Sadetsky wrote:
>>>>>>> Hi Prasanta,
>>>>>>>
>>>>>>> I may be wrong, but it seems to me that the standard behavior is 
>>>>>>> when any wheel event cannot close popups.
>>>>>>>
>>>>>>> --Semyon
>>>>>>>
>>>>>>>
>>>>>>> On 06/13/2017 10:39 PM, Prasanta Sadhukhan wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Please review a fix for an issue whereby it is seen
>>>>>>>> hitting the scroll wheel by accident closes whole structure of 
>>>>>>>> context menus causing it to disappear and the user has to 
>>>>>>>> invoke the menu again.
>>>>>>>>
>>>>>>>> Issue was popupMenu is getting closed for mouse wheel rotation 
>>>>>>>> if the menu is not from JComboBox.
>>>>>>>> If the context menu is opened from JMenuItem, JMenu then if the 
>>>>>>>> mouse wheel is rotated anywhere in frame, then it calls 
>>>>>>>> cancelPopupMenu() causing it to call setVisible(false) and so 
>>>>>>>> menu disappears.
>>>>>>>>
>>>>>>>> Proposed fix is to check if the mouse wheel rotation is done in 
>>>>>>>> JMenu, JMenuItem or anywhere in frame, then if popup is 
>>>>>>>> present, then do not close the popupmenu.
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075063
>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.00/
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From semyon.sadetsky at oracle.com  Fri Jun 16 16:07:51 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 16 Jun 2017 09:07:51 -0700
Subject: <Swing Dev> [10] RFR JDK-8075063:Context menu closes on mouse
 scroll
In-Reply-To: <924dd4d2-44bd-480c-72e1-193c9761c6fc@oracle.com>
References: <8c997c2e-bf01-7957-22fa-43ac18e9ca88@oracle.com>
 <be992d75-65cb-8c55-f3e6-d3685f5fa0e0@oracle.com>
 <9c06120b-c8c0-6ee2-048b-5626f9bea344@oracle.com>
 <04fa0a6c-6302-64f9-e6c7-f5342acab758@oracle.com>
 <6f4d381f-1be5-7bca-6a7e-a17d621c85b1@oracle.com>
 <17c5c10e-d0ad-c278-a9ab-038192b34fc6@oracle.com>
 <0a7b852c-4c78-81ca-b2f6-ba1bb69736af@oracle.com>
 <f5914b14-e791-5a9a-2ad5-56a172719488@oracle.com>
 <924dd4d2-44bd-480c-72e1-193c9761c6fc@oracle.com>
Message-ID: <b9fd5984-a571-150d-8162-a23876b55976@oracle.com>

They are related to a wheel event happend in another java window (not 
outside the app).
My questions is if we do not ungrab on wheel event outside the app 
should we be consistent and do never ungrab on wheel event?

--Semyon


On 06/16/2017 08:49 AM, Prasanta Sadhukhan wrote:
> I was not sure about the scenario at what condition those ungrabs are 
> sent, so I did not modify those. For wheel event outside our java 
> window was the scenario here and my modification fixed that.
>
> // According to the specification of UngrabEvent, post it
>    // when press occurs outside of the window and not on its owned 
> windows
>
> Regards
> Prasanta
> On 6/16/2017 8:57 PM, Semyon Sadetsky wrote:
>> In lines 2337 and 2345 ungrab is also sent. Shouldn't the button 
>> number be checked there as well before ungrab?
>>
>> --Semyon
>>
>>
>> On 06/16/2017 03:22 AM, Prasanta Sadhukhan wrote:
>>> Yes, it is failing in linux as it posts a UngrabEvent which causes 
>>> the popup to be closed in BasicPopupMenuUI at eventDispatched()
>>>
>>> if(ev instanceof sun.awt.UngrabEvent) {
>>>                 // Popup should be canceled in case of ungrab event
>>>                 cancelPopupMenu( );
>>>                 return;
>>>             }
>>> I have modified to not post the ungrab event if mouse wheel is 
>>> rotated by checking if button 4 or 5 is pressed or not.
>>> as per 
>>> https://stackoverflow.com/questions/15510472/scrollwheel-event-in-x11
>>> and
>>> ftp://www.x.org/pub/X11R6.8.0/doc/mouse.4.html [Wheel button events 
>>> (typically buttons 4 and 5) are usually used for scrolling]
>>>
>>> http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.01/
>>>
>>> Regards
>>> Prasanta
>>> On 6/15/2017 8:55 PM, Semyon Sadetsky wrote:
>>>> On 06/15/2017 08:18 AM, Prasanta Sadhukhan wrote:
>>>>
>>>>>
>>>>>
>>>>> On 6/15/2017 8:40 PM, Semyon Sadetsky wrote:
>>>>>> On 06/14/2017 09:54 PM, Prasanta Sadhukhan wrote:
>>>>>>> Hi Semyon,
>>>>>>>
>>>>>>> I tried on Firefox and other app. If popup or drop down menu is 
>>>>>>> opened, then mouse wheel rotation is not closing the popups. In 
>>>>>>> our case, it is closing the popups/menus.
>>>>>> That is true. I meant you fixed only the case when the mouse 
>>>>>> wheel rotation is over java windows (wheel event's source != 
>>>>>> null). What will be if the wheel is rotated outside java (source 
>>>>>> == null), or it is not the case?
>>>>>>
>>>>> It is not closing in other app (if it rotated over non-app window) 
>>>>> as well as in our java with my fix.
>>>> Did you check this on all platforms? At least on my Ubuntu it is 
>>>> not so.
>>>>
>>>> --Semyon
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>>> --Semyon
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 6/14/2017 8:26 PM, Semyon Sadetsky wrote:
>>>>>>>> Hi Prasanta,
>>>>>>>>
>>>>>>>> I may be wrong, but it seems to me that the standard behavior 
>>>>>>>> is when any wheel event cannot close popups.
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>>
>>>>>>>> On 06/13/2017 10:39 PM, Prasanta Sadhukhan wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Please review a fix for an issue whereby it is seen
>>>>>>>>> hitting the scroll wheel by accident closes whole structure of 
>>>>>>>>> context menus causing it to disappear and the user has to 
>>>>>>>>> invoke the menu again.
>>>>>>>>>
>>>>>>>>> Issue was popupMenu is getting closed for mouse wheel rotation 
>>>>>>>>> if the menu is not from JComboBox.
>>>>>>>>> If the context menu is opened from JMenuItem, JMenu then if 
>>>>>>>>> the mouse wheel is rotated anywhere in frame, then it calls 
>>>>>>>>> cancelPopupMenu() causing it to call setVisible(false) and so 
>>>>>>>>> menu disappears.
>>>>>>>>>
>>>>>>>>> Proposed fix is to check if the mouse wheel rotation is done 
>>>>>>>>> in JMenu, JMenuItem or anywhere in frame, then if popup is 
>>>>>>>>> present, then do not close the popupmenu.
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075063
>>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.00/
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From sergey.bylokhov at oracle.com  Fri Jun 16 16:49:25 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 16 Jun 2017 19:49:25 +0300
Subject: <Swing Dev> [9] Review Request: 8181894 java.desktop module
 documentation has links to technotes
Message-ID: <BD53FA42-2911-4213-8338-ADF6E267A781@oracle.com>

Hello,
Please review the fix for jdk9-dev.

A few types of links were fixed:
 - The fix for JDK-8178412 missed some links to IMF.
 - The links to jar.html#service_provider were changed to {@link ServiceLoader}
 - The links to a.html were changed to ?{@docRoot}/specs/jar.html? see JDK-8150681

Bug: https://bugs.openjdk.java.net/browse/JDK-8181894
Webrev can be found at: http://cr.openjdk.java.net/~serb/8181894/webrev.00 <http://cr.openjdk.java.net/~serb/8181894/webrev.00>

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

From sergey.bylokhov at oracle.com  Fri Jun 16 19:52:02 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 16 Jun 2017 22:52:02 +0300
Subject: <Swing Dev> [10] RFR JDK-6267105:UIDefaults.getUIError dumps
 error message to System.err and also throws Error.
In-Reply-To: <be0276b1-dbc9-f295-ddff-5bafcd406b98@oracle.com>
References: <c2655a81-8016-4ab5-b44c-e5e158de8a51@default>
 <be0276b1-dbc9-f295-ddff-5bafcd406b98@oracle.com>
Message-ID: <7E2E238A-591F-4D0D-B4E3-D90CC3A6A98E@oracle.com>

Hi, Shashi.
Can you please clarify the purpose of this fix, because the bug states that the code prints traceback to the system.err, even if the user tries to catch/suppress an exception.
The current fix removed the system.err logging but the code which print trace still there:
    protected void getUIError(String msg) {
        try {
            throw new Error(msg);
        }
        catch (Throwable e) {
            e.printStackTrace();
        }
    }
>> Through catching the error, the user can perform necessary recovery actions without cluttering the system.err

I am not sure that the user is able to catch this error. So what is the difference when we had an additional message before and after the fix?

> 
> +1
> 
> --Semyon
> 
> 
> On 06/12/2017 03:54 AM, Shashidhara Veerabhadraiah wrote:
>> Hi All,
>> 	Please review the code bug fix for JDK-6267105:UIDefaults.getUIError dumps error message to System.err and also throws Error.
>> 
>> Issue:
>>      Error message was getting dumped to the system.err even though the recovery actions were performed leading to unnecessary confusion regarding the actual behavior.
>> 
>> Fix:
>>     This fix removes the call which prints the message to the system.err and stores the message in the Error class. This same message can be retrieved after we catch the error and calling getMessage() of the Error class. Through catching the error, the user can perform necessary recovery actions without cluttering the system.err. This fix does not modifies the 'user effect' as the user would still get the same error as they were getting before this fix.
>> 
>> Test:
>>     Now the system.err does not get cluttered though we performed the necessary recovery actions. The error message string can be recovered by calling getMessage() if needed.
>>    Bug:
>> https://bugs.openjdk.java.net/browse/JDK-6267105
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~aghaisas/shashi/6267105/webrev_00/
>> 
>> Thanks and regards,
>> Shashi
> 



From sergey.bylokhov at oracle.com  Fri Jun 16 20:10:14 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 16 Jun 2017 23:10:14 +0300
Subject: <Swing Dev> [10] RFR: JDK-8181782:[TESTBUG] [Macosx]
 JTextAreaEmojiTest is not executed
In-Reply-To: <1e28ea0e-5fc6-9191-1ed7-98777930f4f2@oracle.com>
References: <3dce1cd6-9150-4209-9377-325531403130@default>
 <28680c63-44c2-8681-8469-cc93be3b91a9@oracle.com>
 <9c1fbf5c-e872-414e-84c1-fa533a21e1aa@default>
 <1e28ea0e-5fc6-9191-1ed7-98777930f4f2@oracle.com>
Message-ID: <EC74656A-1E7A-46FF-83CB-E66C71B7A53B@oracle.com>

Hi, Sashi.
One, small non-critical remark if some similar code will be changed in future:
 - Note that you moved the cleanup() method after throw new AssertionError("Test case has failed!?) this means that the cleanup() will not be executed when the test fails. So if the test runs standalone the only possible way to close the frame is to press a ?pass? button.

> 
> Looks good to me. Only thing is in my opinion, 5 min timeout is too much. I guess 1 minutes should be sufficient. No need for webrev if you consider to make that change.
> 
> Regards
> Prasanta
> On 6/12/2017 7:51 PM, Sreeprakash Sreedharan wrote:
>> Thanks for the inputs, Prasanta.
>> 
>> I have incorporated the changes mentioned.
>> 
>> Updated Webrev :  http://cr.openjdk.java.net/~rpatil/8181782/webrev.01
>> 
>> Regards,
>> Sreeprakash
>> 
>> -----Original Message-----
>> From: Prasanta Sadhukhan
>> Sent: Monday, June 12, 2017 2:55 PM
>> To: Sreeprakash Sreedharan <sreeprakash.s at oracle.com>; swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> [10] RFR: JDK-8181782:[TESTBUG] [Macosx] JTextAreaEmojiTest is not executed
>> 
>> It seems the test is waiting infinitely instead of having a timeout. I amnot sure of jtreg timeout but it's better to rely on test's own timeout, so await(timeout) is a better call .
>> 
>> Also, please add @key headful tag to the test.
>> 
>> Regards
>> Prasanta
>> On 6/9/2017 1:38 AM, Sreeprakash Sreedharan wrote:
>>> Hi All,
>>> 
>>> Kindly review the fix for JDK10.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8181782
>>> 
>>> Webrev: http://cr.openjdk.java.net/~rpatil/8181782/webrev.00
>>> 
>>> Issue: JTREG was not executing the manual test JTextAreaEmojiTest and was always giving a passed result.
>>> 
>>> Fix: Made sure that main function waits for pass/fail events using a
>>> countdown latch and also added manual to the run tag
>>> 
>>> Regards,
>>> Sreeprakash
> 



From mandy.chung at oracle.com  Fri Jun 16 23:31:17 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 16 Jun 2017 16:31:17 -0700
Subject: <Swing Dev> [9] Review Request: 8181894 java.desktop module
	documentation has links to technotes
In-Reply-To: <BD53FA42-2911-4213-8338-ADF6E267A781@oracle.com>
References: <BD53FA42-2911-4213-8338-ADF6E267A781@oracle.com>
Message-ID: <DC107C80-B7C2-44D8-9780-C753C96F186C@oracle.com>


> On Jun 16, 2017, at 9:49 AM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hello,
> Please review the fix for jdk9-dev.
> 
> A few types of links were fixed:
>  - The fix for JDK-8178412 missed some links to IMF.
>  - The links to jar.html#service_provider were changed to {@link ServiceLoader}
>  - The links to a.html were changed to ?{@docRoot}/specs/jar.html? see JDK-8150681
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8181894 <https://bugs.openjdk.java.net/browse/JDK-8181894>
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8181894/webrev.00 <http://cr.openjdk.java.net/~serb/8181894/webrev.00>
> 

+ * <a href="{@docRoot}/specs/jar.html">JAR File Specification</a>.
This should be 
 
<a href="{@docRoot}/specs/jar/jar.html">

You should do a build to verify.
Mandy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170616/1c839638/attachment.html>

From sergey.bylokhov at oracle.com  Sat Jun 17 03:11:52 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 17 Jun 2017 06:11:52 +0300
Subject: <Swing Dev> [9] Review Request: 8181894 java.desktop module
 documentation has links to technotes
In-Reply-To: <DC107C80-B7C2-44D8-9780-C753C96F186C@oracle.com>
References: <BD53FA42-2911-4213-8338-ADF6E267A781@oracle.com>
 <DC107C80-B7C2-44D8-9780-C753C96F186C@oracle.com>
Message-ID: <DB1286BF-5D85-4405-A4B0-CE71FDF8D360@oracle.com>

Hi, Mandy.
I  rechecked this fix on top of JDK-8150681, and found that the jar/jar.html was not copied to the "/images/docs/specs/? but for example ?serialization? is copied. 


>>  - The links to a.html were changed to ?{@docRoot}/specs/jar.html? see JDK-8150681
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8181894 <https://bugs.openjdk.java.net/browse/JDK-8181894>
>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8181894/webrev.00 <http://cr.openjdk.java.net/~serb/8181894/webrev.00>
>> 
> 
> + * <a href="{@docRoot}/specs/jar.html">JAR File Specification</a>.
> This should be 
>  
> <a href="{@docRoot}/specs/jar/jar.html">
> 
> You should do a build to verify.
> Mandy

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

From mandy.chung at oracle.com  Sat Jun 17 06:11:27 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 16 Jun 2017 23:11:27 -0700
Subject: <Swing Dev> [9] Review Request: 8181894 java.desktop module
	documentation has links to technotes
In-Reply-To: <DB1286BF-5D85-4405-A4B0-CE71FDF8D360@oracle.com>
References: <BD53FA42-2911-4213-8338-ADF6E267A781@oracle.com>
 <DC107C80-B7C2-44D8-9780-C753C96F186C@oracle.com>
 <DB1286BF-5D85-4405-A4B0-CE71FDF8D360@oracle.com>
Message-ID: <8C67D508-9FB7-49BC-8339-CD1DDE0DDBE4@oracle.com>

It?s in my build:
   docs/specs/jar/jar.html

Do you pull in the up-to-date changeset? 

Mandy

> On Jun 16, 2017, at 8:11 PM, Sergey Bylokhov <sergey.bylokhov at oracle.com> wrote:
> 
> Hi, Mandy.
> I  rechecked this fix on top of JDK-8150681, and found that the jar/jar.html was not copied to the "/images/docs/specs/? but for example ?serialization? is copied. 
> 
> 
>>>  - The links to a.html were changed to ?{@docRoot}/specs/jar.html? see JDK-8150681
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8181894 <https://bugs.openjdk.java.net/browse/JDK-8181894>
>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8181894/webrev.00 <http://cr.openjdk.java.net/~serb/8181894/webrev.00>
>>> 
>> 
>> + * <a href="{@docRoot}/specs/jar.html">JAR File Specification</a>.
>> This should be 
>>  
>> <a href="{@docRoot}/specs/jar/jar.html">
>> 
>> You should do a build to verify.
>> Mandy
> 

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

From prasanta.sadhukhan at oracle.com  Sun Jun 18 14:31:09 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Sun, 18 Jun 2017 20:01:09 +0530
Subject: <Swing Dev> [10] RFR JDK-8075063:Context menu closes on mouse
 scroll
In-Reply-To: <b9fd5984-a571-150d-8162-a23876b55976@oracle.com>
References: <8c997c2e-bf01-7957-22fa-43ac18e9ca88@oracle.com>
 <be992d75-65cb-8c55-f3e6-d3685f5fa0e0@oracle.com>
 <9c06120b-c8c0-6ee2-048b-5626f9bea344@oracle.com>
 <04fa0a6c-6302-64f9-e6c7-f5342acab758@oracle.com>
 <6f4d381f-1be5-7bca-6a7e-a17d621c85b1@oracle.com>
 <17c5c10e-d0ad-c278-a9ab-038192b34fc6@oracle.com>
 <0a7b852c-4c78-81ca-b2f6-ba1bb69736af@oracle.com>
 <f5914b14-e791-5a9a-2ad5-56a172719488@oracle.com>
 <924dd4d2-44bd-480c-72e1-193c9761c6fc@oracle.com>
 <b9fd5984-a571-150d-8162-a23876b55976@oracle.com>
Message-ID: <97d37ed7-6f79-b940-29e6-d982645cb844@oracle.com>

Fair enough suggestion, modified webrev to never ungrab for wheel event

http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.02/

Regards
Prasanta
On 6/16/2017 9:37 PM, Semyon Sadetsky wrote:
> They are related to a wheel event happend in another java window (not 
> outside the app).
> My questions is if we do not ungrab on wheel event outside the app 
> should we be consistent and do never ungrab on wheel event?
>
> --Semyon
>
>
> On 06/16/2017 08:49 AM, Prasanta Sadhukhan wrote:
>> I was not sure about the scenario at what condition those ungrabs are 
>> sent, so I did not modify those. For wheel event outside our java 
>> window was the scenario here and my modification fixed that.
>>
>> // According to the specification of UngrabEvent, post it
>>    // when press occurs outside of the window and not on its owned 
>> windows
>>
>> Regards
>> Prasanta
>> On 6/16/2017 8:57 PM, Semyon Sadetsky wrote:
>>> In lines 2337 and 2345 ungrab is also sent. Shouldn't the button 
>>> number be checked there as well before ungrab?
>>>
>>> --Semyon
>>>
>>>
>>> On 06/16/2017 03:22 AM, Prasanta Sadhukhan wrote:
>>>> Yes, it is failing in linux as it posts a UngrabEvent which causes 
>>>> the popup to be closed in BasicPopupMenuUI at eventDispatched()
>>>>
>>>> if(ev instanceof sun.awt.UngrabEvent) {
>>>>                 // Popup should be canceled in case of ungrab event
>>>>                 cancelPopupMenu( );
>>>>                 return;
>>>>             }
>>>> I have modified to not post the ungrab event if mouse wheel is 
>>>> rotated by checking if button 4 or 5 is pressed or not.
>>>> as per 
>>>> https://stackoverflow.com/questions/15510472/scrollwheel-event-in-x11
>>>> and
>>>> ftp://www.x.org/pub/X11R6.8.0/doc/mouse.4.html [Wheel button events 
>>>> (typically buttons 4 and 5) are usually used for scrolling]
>>>>
>>>> http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.01/
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 6/15/2017 8:55 PM, Semyon Sadetsky wrote:
>>>>> On 06/15/2017 08:18 AM, Prasanta Sadhukhan wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 6/15/2017 8:40 PM, Semyon Sadetsky wrote:
>>>>>>> On 06/14/2017 09:54 PM, Prasanta Sadhukhan wrote:
>>>>>>>> Hi Semyon,
>>>>>>>>
>>>>>>>> I tried on Firefox and other app. If popup or drop down menu is 
>>>>>>>> opened, then mouse wheel rotation is not closing the popups. In 
>>>>>>>> our case, it is closing the popups/menus.
>>>>>>> That is true. I meant you fixed only the case when the mouse 
>>>>>>> wheel rotation is over java windows (wheel event's source != 
>>>>>>> null). What will be if the wheel is rotated outside java (source 
>>>>>>> == null), or it is not the case?
>>>>>>>
>>>>>> It is not closing in other app (if it rotated over non-app 
>>>>>> window) as well as in our java with my fix.
>>>>> Did you check this on all platforms? At least on my Ubuntu it is 
>>>>> not so.
>>>>>
>>>>> --Semyon
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>>> --Semyon
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>> On 6/14/2017 8:26 PM, Semyon Sadetsky wrote:
>>>>>>>>> Hi Prasanta,
>>>>>>>>>
>>>>>>>>> I may be wrong, but it seems to me that the standard behavior 
>>>>>>>>> is when any wheel event cannot close popups.
>>>>>>>>>
>>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 06/13/2017 10:39 PM, Prasanta Sadhukhan wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> Please review a fix for an issue whereby it is seen
>>>>>>>>>> hitting the scroll wheel by accident closes whole structure 
>>>>>>>>>> of context menus causing it to disappear and the user has to 
>>>>>>>>>> invoke the menu again.
>>>>>>>>>>
>>>>>>>>>> Issue was popupMenu is getting closed for mouse wheel 
>>>>>>>>>> rotation if the menu is not from JComboBox.
>>>>>>>>>> If the context menu is opened from JMenuItem, JMenu then if 
>>>>>>>>>> the mouse wheel is rotated anywhere in frame, then it calls 
>>>>>>>>>> cancelPopupMenu() causing it to call setVisible(false) and so 
>>>>>>>>>> menu disappears.
>>>>>>>>>>
>>>>>>>>>> Proposed fix is to check if the mouse wheel rotation is done 
>>>>>>>>>> in JMenu, JMenuItem or anywhere in frame, then if popup is 
>>>>>>>>>> present, then do not close the popupmenu.
>>>>>>>>>>
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075063
>>>>>>>>>> webrev: 
>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.00/
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Prasanta
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From ldubox-coding101 at yahoo.co.uk  Sun Jun 18 22:33:15 2017
From: ldubox-coding101 at yahoo.co.uk (Luke)
Date: Mon, 19 Jun 2017 00:33:15 +0200
Subject: <Swing Dev> [9] Crash tabbing to a checkbox with custom model (see
 e.g. 8074883)
Message-ID: <163b68b2-2eaa-2b09-9a1a-5e1f24e02ed2@yahoo.co.uk>


Good day,

I believe I've hit my first bug in occasional testingof the JDK-9 drops.
I hope this is an appropriate way to send feedback?

We use a customised "tri-state" checkbox, which triggers a crash when the
keyboard focus moves to it by pressing the TAB key. The issue seems related
to some focus logic changes with button-groups introduced in JDK-9.
(For example: 8074883?)

The top of the stack trace is:

java.lang.ClassCastException: 
com.example.TristateCheckBox$TristateDecorator cannot be cast to 
java.desktop/javax.swing.JToggleButton$ToggleButtonModel
     at 
java.desktop/javax.swing.LayoutFocusTraversalPolicy.accept(LayoutFocusTraversalPolicy.java:243)
     at 
java.desktop/javax.swing.SortingFocusTraversalPolicy.getComponentBefore(SortingFocusTraversalPolicy.java:435)
     at 
java.desktop/javax.swing.LayoutFocusTraversalPolicy.getComponentBefore(LayoutFocusTraversalPolicy.java:143)
     at 
java.desktop/java.awt.Component.transferFocusBackward(Component.java:8201)
     at 
java.desktop/java.awt.Component.transferFocusBackward(Component.java:8186)
     at 
java.desktop/java.awt.DefaultKeyboardFocusManager.focusPreviousComponent(DefaultKeyboardFocusManager.java:1388)
     at 
java.desktop/java.awt.DefaultKeyboardFocusManager.processKeyEvent(DefaultKeyboardFocusManager.java:1183)
     at 
java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4877)
     at 
java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2317)
     at java.desktop/java.awt.Component.dispatchEvent(Component.java:4793)
...

The relevant code in LayoutFocusTraversalPolicy.accept is:

     } else if (aComponent instanceof JComponent) {
         if (SunToolkit.isInstanceOf(aComponent,
"javax.swing.JToggleButton")) {
             JToggleButton.ToggleButtonModel model =
                     (JToggleButton.ToggleButtonModel) ((JToggleButton)
                             aComponent).getModel();   // <- Line 243
             if (model != null) {
                 ButtonGroup group = model.getGroup(); // <- Only use of 
'model'

For whatever reason (probably to do with the 3 states) the button model
is not a ToggleButtonModel, but derived from a DefaultButtonModel.

I think a simple solution is to (check? and) cast less specifically, to a
DefaultButtonModel instead. That looks to be sufficient here, and is also
what we find similar code in JToggleButton doing. For example in
JToggeleButton.getGroupSelection we see:

     if (model instanceof DefaultButtonModel) {
         ButtonGroup group = ((DefaultButtonModel) model).getGroup();
         //...

I note while JToggleButton creates a ToggleButtonModel by default, it
does not enforce it via setModel().


More background: I think we found this code (over a decade ago) from here

   http://www.javaspecialists.eu/archive/Issue082.html

(There are better solutions implementing this GUI control these days, but
I thought you might like to hear about it.)

Kind regards,
Luke Usherwood




From shashidhara.veerabhadraiah at oracle.com  Mon Jun 19 05:25:43 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Sun, 18 Jun 2017 22:25:43 -0700 (PDT)
Subject: <Swing Dev> [10] RFR JDK-6267105:UIDefaults.getUIError dumps
 error message to System.err and also throws Error.
In-Reply-To: <7E2E238A-591F-4D0D-B4E3-D90CC3A6A98E@oracle.com>
References: <c2655a81-8016-4ab5-b44c-e5e158de8a51@default>
 <be0276b1-dbc9-f295-ddff-5bafcd406b98@oracle.com>
 <7E2E238A-591F-4D0D-B4E3-D90CC3A6A98E@oracle.com>
Message-ID: <dd579c74-26c7-4462-9e0c-f2ac4afddacc@default>

Hi Sergey, The below marked stack trace would be hit if there is any exception raised while creating the Error object in the try block. But the user would still get the stack trace if the exception is not handled because the Error calls base class function of Throwable:

 

    public Throwable(String message) {

        fillInStackTrace();

        detailMessage = message;

    }

 

The stack trace would be printed by the above code in Throwable implementation. I believe it is inevitable to print this because this is one of the basic level implementation and we do have an unhandled exception. And I don't think I should do any change in here. Please let me know if you think otherwise.

 

I have attached the test file which I used to test the user level effects. The user won't be able to use the expressions like  this (if(UIManager.getUI(comp) == null)) as mentioned in the JIRA bug but he will be able to use the below catching code:

try {

    System.out.println("Updating UI");
    UIManager.getUI(comp);
} catch (Exception e) {
    System.out.println("GetUI is null");
    System.out.println(e.getMessage());
}

 

The output of this is as follows:

Updating UI

GetUI is null

Null

 

If the there is no exception catch performed then it would have the below output:

LAF State: [Custom LAF - CustomUI$1],LAF Class: com.sun.java.swing.plaf.windows.WindowsLookAndFeel

Exception in thread "main" java.lang.NullPointerException

               at java.desktop/javax.swing.MultiUIDefaults.getUIError(MultiUIDefaults.java:131)

               at java.desktop/javax.swing.UIDefaults.getUI(UIDefaults.java:790)

               at java.desktop/javax.swing.UIManager.getUI(UIManager.java:1065)

               at CustomUI.main(CustomUI.java:50)

 

Process finished with exit code 1

 

Please let me know if any part of my analysis is wrong or skewed.

 

Thanks and regards,

Shashi

 

-----Original Message-----
From: Sergey Bylokhov 
Sent: Saturday, June 17, 2017 1:22 AM
Cc: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; swing-dev <swing-dev at openjdk.java.net>; Philip Race <philip.race at oracle.com>; Semyon Sadetsky <semyon.sadetsky at oracle.com>
Subject: Re: <Swing Dev> [10] RFR JDK-6267105:UIDefaults.getUIError dumps error message to System.err and also throws Error.

 

Hi, Shashi.

Can you please clarify the purpose of this fix, because the bug states that the code prints traceback to the system.err, even if the user tries to catch/suppress an exception.

The current fix removed the system.err logging but the code which print trace still there:

    protected void getUIError(String msg) {

        try {

            throw new Error(msg);

        }

        catch (Throwable e) {

            e.printStackTrace();

        }

    }

>> Through catching the error, the user can perform necessary recovery actions without cluttering the system.err

 

I am not sure that the user is able to catch this error. So what is the difference when we had an additional message before and after the fix?

 

> 

> +1

> 

> --Semyon

> 

> 

> On 06/12/2017 03:54 AM, Shashidhara Veerabhadraiah wrote:

>> Hi All,

>>           Please review the code bug fix for JDK-6267105:UIDefaults.getUIError dumps error message to System.err and also throws Error.

>> 

>> Issue:

>>      Error message was getting dumped to the system.err even though the recovery actions were performed leading to unnecessary confusion regarding the actual behavior.

>> 

>> Fix:

>>     This fix removes the call which prints the message to the system.err and stores the message in the Error class. This same message can be retrieved after we catch the error and calling getMessage() of the Error class. Through catching the error, the user can perform necessary recovery actions without cluttering the system.err. This fix does not modifies the 'user effect' as the user would still get the same error as they were getting before this fix.

>> 

>> Test:

>>     Now the system.err does not get cluttered though we performed the necessary recovery actions. The error message string can be recovered by calling getMessage() if needed.

>>    Bug:

>> https://bugs.openjdk.java.net/browse/JDK-6267105

>> 

>> Webrev:

>> http://cr.openjdk.java.net/~aghaisas/shashi/6267105/webrev_00/

>> 

>> Thanks and regards,

>> Shashi

> 

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170618/c8b13a52/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CustomUI.JAVA
Type: application/octet-stream
Size: 1676 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170618/c8b13a52/CustomUI.JAVA>

From avik.niyogi at oracle.com  Mon Jun 19 09:36:34 2017
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Mon, 19 Jun 2017 15:06:34 +0530
Subject: <Swing Dev> swing-dev Digest, Vol 122, Issue 16
In-Reply-To: <mailman.51.1497441602.20681.swing-dev@openjdk.java.net>
References: <mailman.51.1497441602.20681.swing-dev@openjdk.java.net>
Message-ID: <BAB31B68-E98B-454B-8289-452F2632B560@oracle.com>

Fix looks good to me.

> On 14-Jun-2017, at 5:30 pm, swing-dev-request at openjdk.java.net wrote:
> 
> Date: Wed, 14 Jun 2017 12:34:04 +0530
> From: Alexander Zvegintsev <alexander.zvegintsev at oracle.com <mailto:alexander.zvegintsev at oracle.com>>
> To: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com>>, Sergey
> 	Bylokhov <sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com>>
> Cc: swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
> Subject: Re: <Swing Dev> [10] RFR: JDK-8043315: Nimbus: Setting
> 	Nimbus.Overrides property affects custom keymap installation
> Message-ID: <67b025e2-2134-a1fb-8769-078ff1f14081 at oracle.com <mailto:67b025e2-2134-a1fb-8769-078ff1f14081 at oracle.com>>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Hi Prasanta,
> 
>> If app again calls setKeymap(null) then the static variable will be 
>> "true" and it will reset back to default keymap. 
> It doesn't seem to be relevant to this fix. setKeymap(): " Setting to 
> <code>null</code> effectively disables keyboard input." As it does with 
> you fix.
> 
> Otherwise the fix looks good to me.
> 
> Thanks,
> Alexander.
> 
> On 02/06/2017 13:59, Prasanta Sadhukhan wrote:
>> Hi Sergey,
>> 
>> I have modified webrev to remove static keyword and made the test 
>> automated
>> http://cr.openjdk.java.net/~psadhukhan/8043315/webrev.01/ <http://cr.openjdk.java.net/~psadhukhan/8043315/webrev.01/>
>> Updated fix tests if app has fired a property change by calling 
>> setKeymap() then it will not uninstall custom keymap and let the 
>> custom keymap be honoured. If app again calls setKeymap(null) then the 
>> static variable will be "true" and it will reset back to default keymap.
>> 
>> Regards
>> Prasanta
>> On 6/2/2017 12:07 AM, Sergey Bylokhov wrote:
>>> Hi, Prasanta.
>>> Can you please clarify the fix a little bit.
>>> You have a static variable, which is set to "false" when the listener 
>>> for "keymap" is triggered, and it seems that you never set it back to 
>>> "true"? Is it intentional behavior?
>>> Note that if there are a few objects of "SynthEditorPaneUI" then they 
>>> will share this static field. Also it seems that the test can be 
>>> automated, because currently it is requires from the user to press 
>>> only one button("space").
>>> 
>>> ----- prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com> wrote:
>>> 
>>>> Hi All,
>>>> 
>>>> Please review a bug fix for Nimbus L&F where if app sets custom keymap
>>>> 
>>>> and then sets Nimbus.Overrides property,
>>>> then the custom keymap is not honoured.
>>>> For example, if testapp sets a new action for "space" key press and
>>>> sets
>>>> sets Nimbus.Overrides property,
>>>>   it will not be honoured and default action ie. inserting a "space"
>>>> character will be done.
>>>> 
>>>> Issue was NimbusLookAndFeel#shouldUpdateStyleOnEvent() returns true
>>>> for
>>>> Nimbus.Override property which causes SynthEditorPaneUI#updateStyle()
>>>> to
>>>> be called which
>>>> uninstall set keyboard actions and sets up default keyboard action.
>>>> 
>>>> Proposed fix is to check if a keymap is already set (a propertyChange
>>>> 
>>>> event will be fired for when app calls setKeyMap()) then do not reset
>>>> to
>>>> default keymap.
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8043315 <https://bugs.openjdk.java.net/browse/JDK-8043315>
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8043315/webrev.00/ <http://cr.openjdk.java.net/~psadhukhan/8043315/webrev.00/>
>>>> 
>>>> Regards
>>>> Prasanta
>> 
> 

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

From prasanta.sadhukhan at oracle.com  Mon Jun 19 10:12:33 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 19 Jun 2017 15:42:33 +0530
Subject: <Swing Dev> [10] RFR: JDK-8075918:The regression-swing case
 failed as the long Tab titles are not clipped with dots at the end with
 NimbusLookAndFeel
In-Reply-To: <be81fbcf-155b-5e9c-c40c-e9cf8a15447e@oracle.com>
References: <a4a1ae6b-2d1c-4d99-abcf-e2a3cd24659d@default>
 <27bb815b-ba6c-0b06-7cc2-a84fc38d8b57@oracle.com>
 <A6A5EB65-4E18-47AB-8E1A-73B7FECDFB85@oracle.com>
 <7b5d79ce-3f1b-d7be-486b-e836bf3a5862@oracle.com>
 <34003A0F-6EE2-42B6-A920-404769399E38@oracle.com>
 <be81fbcf-155b-5e9c-c40c-e9cf8a15447e@oracle.com>
Message-ID: <066deef0-4b60-d430-2f25-2aa699eb0c57@oracle.com>

Hi Sergey,

Is anything more needed to be done for this? I guess I have modified as 
per the review comment.

Regards
Prasanta
On 6/9/2017 11:33 AM, Prasanta Sadhukhan wrote:
>
> Ok. Rectified. Please find the modified webrev with clip at correct 
> place(s)
>
> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.05/
>
> Regards
> Prasanta
> On 6/8/2017 9:34 PM, Sergey Bylokhov wrote:
>> I have referenced these methods:
>>
>> "BasicTabbedPaneUI.paintIcon() as well as 
>> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>> ?- paintText() at line 681
>> ?- paintIcon() at line 634
>> Both methods have a rectangle as a parameter, but it is ignored."
>> The first is in the BasicTabbedPaneUI.java and the second is in the 
>> SynthGraphicsUtils.java
>>
>>>
>>> Why? clip is invoked in SynthTabbedPaneUI#paintText() at line 687 
>>> and SynthTabbedPaneUI#paintTab() at line 637, where you asked for, I 
>>> guess.
>>>
>>> Regards
>>> Prasanta
>>> On 6/8/2017 12:59 PM, Sergey Bylokhov wrote:
>>>> But in this version the clip operation still not executed in 
>>>> methods mentioned here:
>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2017-June/007419.html
>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2017-May/007406.html
>>>>
>>>>>
>>>>> Please find the modified webrev incorporating your review comment
>>>>>
>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.04/ 
>>>>> <http://cr.openjdk.java.net/%7Epsadhukhan/8075918/webrev.04/>
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 6/2/2017 12:33 AM, Sergey Bylokhov wrote:
>>>>>> ?- There is a problem in your algorithm which merges the old and 
>>>>>> new clips. The getClipBounds() returns a rectangle which is a 
>>>>>> bounds of the current clip(which is not necessary a rectangle but 
>>>>>> can be a shape). you can use the Graphics2D.clip(Shape) method 
>>>>>> which will intersect the passed shape and a current clip of the 
>>>>>> graphics.
>>>>>> ?- In this version you forgot to restore the changed clip.
>>>>>> ?- Also can you try to move the code which change a clip to the 
>>>>>> methods which currently ignore the passed clip(see below):
>>>>>>>>> BasicTabbedPaneUI.paintIcon() as well as
>>>>>>>>> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>>>>>>>>> ??- paintText() at line 681
>>>>>>>>> ??- paintIcon() at line 634
>>>>>>>>> Both methods have a rectangle as a parameter, but it is ignored.
>>>>>>
>>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>>
>>>>>>> I tried to incorporate your comments. Please find modified webrev
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.03/
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 5/28/2017 8:01 AM, Sergey Bylokhov wrote:
>>>>>>>> Note that you shouldn't replace the clip, but should apply the new
>>>>>>> clip on top of the old. This is necessary if the old clip is smaller
>>>>>>> than new.
>>>>>>>> ----- sergey.bylokhov at oracle.com wrote:
>>>>>>>>
>>>>>>>>> Hi, Prasanta.
>>>>>>>>>
>>>>>>>>> BasicTabbedPaneUI.paintIcon() as well as
>>>>>>>>> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>>>>>>>>> ??- paintText() at line 681
>>>>>>>>> ??- paintIcon() at line 634
>>>>>>>>> Both methods have a rectangle as a parameter, but it is ignored.
>>>>>>>>>
>>>>>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>>>>>
>>>>>>>>>> Hi Sergey,
>>>>>>>>>>
>>>>>>>>>> I could get your concern for paintText() but could not find
>>>>>>>>>> paintIcon()
>>>>>>>>>> in SynthGraphicsUtils() so not sure how icon drawing contradicts
>>>>>>>>>> spec.
>>>>>>>>>> Modified webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/
>>>>>>>>>>
>>>>>>>>>> Also, if we are not calling
>>>>>>> SwingUtilities2.clipStringIfNecessary()
>>>>>>>>>> then
>>>>>>>>>> we are not going to get "..." at the end which this test expects.
>>>>>>>>> But
>>>>>>>>>> I
>>>>>>>>>> could not find anything in spec, that mandates ending with "..."
>>>>>>> for
>>>>>>>>>> long tab outside
>>>>>>>>>> tab bounds. If source change is ok, I guess we then need to
>>>>>>> modify
>>>>>>>>> the
>>>>>>>>>> html file modifying the expected result for NimbusL&F.
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Prasanta
>>>>>>>>>> On 5/25/2017 3:11 AM, Sergey Bylokhov wrote:
>>>>>>>>>>> Hi, Prasanta.
>>>>>>>>>>> Please take a look to my comments at:
>>>>>>>>>>>
>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html
>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html
>>>>>>>>>>> The two methods paintText() and paintIcon() are contradict the
>>>>>>>>> spec
>>>>>>>>>> and draw the text and icons outside of the tab.
>>>>>>>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>
>>>>>>>>>>>> Please review a fix for an issue where long Tab titiles are not
>>>>>>>>>>>> clipped
>>>>>>>>>>>> with dots at end for NimbusLookAndFeel L&F.
>>>>>>>>>>>> Other L&Fs works ok.
>>>>>>>>>>>>
>>>>>>>>>>>> Issue was in SynthTabbedPaneUI#paintTab(), the title is not
>>>>>>>>>> clipped
>>>>>>>>>>>> but
>>>>>>>>>>>> passed to paintText() as it is received.
>>>>>>>>>>>> Other L&F such as Metal, Motif, Windows which uses
>>>>>>>>>>>> BasicTabbedPaneUI#paintTab(), the title is clipped
>>>>>>>>>>>>
>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950
>>>>>>>>>>>> before it is passed to paintText().
>>>>>>>>>>>>
>>>>>>>>>>>> Proposed fix is to do the same for
>>>>>>> SynthTabbedPaneUI#paintTab().
>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075918
>>>>>>>>>>>> webrev:
>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Prasanta
>>>>>
>>>>
>>>
>>
>

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

From srinivas.mandalika at oracle.com  Mon Jun 19 11:26:14 2017
From: srinivas.mandalika at oracle.com (Srinivas Mandalika)
Date: Mon, 19 Jun 2017 04:26:14 -0700 (PDT)
Subject: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169958 :
 javax/swing/JSpinner/5012888: Spinner value should be more than 1
In-Reply-To: <3cefd74c-a841-46db-881a-4b31b78c2363@default>
References: <0ce40baf-45ab-4dd4-bd95-d7b3bce5751b@default>
 <3cefd74c-a841-46db-881a-4b31b78c2363@default>
Message-ID: <a0fc42d0-ffdf-488f-bddb-650c6726697b@default>

Hi Ajit,

Thank you for your comments. I have incorporated all your comments.  There are also a few additional changes of invoking code on EDT that I made while executing this fix to validate the test stability. 

Updated webrev: http://cr.openjdk.java.net/~akolarkunnu/8169958/webrev.01/


Thanks,
Srinivas M

-----Original Message-----
From: Ajit Ghaisas 
Sent: Monday, June 12, 2017 2:41 PM
To: Srinivas Mandalika <srinivas.mandalika at oracle.com>; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169958 : javax/swing/JSpinner/5012888: Spinner value should be more than 1

Hi Srinivas,

   Here are few review comments :
   1.  Add this bug id to the @bug jtreg tag in test
   2. Replace generic import statements with specific ones
   3. You are calling - b.doTest(); - in a try catch block. This will catch any exception and print stack trace. 
       I think we can remove this try-catch block - simply make a call to b.doTest(), if an exception is thrown, it is thrown out from main() and jtreg framework will catch it and mark the test as failed.
   4. Line 63 in your file has a throw error - this can be converted to exception.
   5. Keep four spaces indentation level

Regards,
Ajit


From: Srinivas Mandalika 
Sent: Monday, June 12, 2017 1:51 PM
To: swing-dev at openjdk.java.net
Subject: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169958 : javax/swing/JSpinner/5012888: Spinner value should be more than 1

Hi All,

Please review the test bug fix for JDK-8169958 : javax/swing/JSpinner/5012888: Spinner value should be more than 1.

Issue: 
In this bug, click & hold on arrow of JSpinner only transfers focus and does not change spinner value. This behavior is intermittently seen in the automated test but is working as expected when checked for manualy. The test was failing robot clicks out of sync with the yet to be maximized frame.

Fix: 
Ensure the robot waits for the frame to be maximized before the clicks on the Spinner. Also ensure the main application frame is maximized explicitly.

Testing: 
Tested the potential fix on winx64, linux ?with JDK8, 9 several times with running tests individually clubbed with the previous test and the entire suite (i.e javax/swing) put to ensure that the issue is not repeated.

Bug Id:
https://bugs.openjdk.java.net/browse/JDK-8169958


WebRev Request:
http://cr.openjdk.java.net/~akolarkunnu/8169958/webrev.00/


Regards,
Srinivas M


From srinivas.mandalika at oracle.com  Mon Jun 19 11:40:52 2017
From: srinivas.mandalika at oracle.com (Srinivas Mandalika)
Date: Mon, 19 Jun 2017 04:40:52 -0700 (PDT)
Subject: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169954 :
 JFileChooser/8021253: java.lang.RuntimeException: Default button is not
 pressed
In-Reply-To: <aa42ae40-b3f4-4797-a51d-5fb10ca7601d@default>
References: <aa42ae40-b3f4-4797-a51d-5fb10ca7601d@default>
Message-ID: <bf3d766e-9f5b-44a5-9fc9-f4c7a7b74019@default>

Hi All,

 

Please review the test bug fix for JDK-8169954 : JFileChooser/8021253: java.lang.RuntimeException: Default button is not pressed.

 

Regards

Srinivas M

 

 

From: Srinivas Mandalika 
Sent: Monday, June 12, 2017 1:50 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169954 : JFileChooser/8021253: java.lang.RuntimeException: Default button is not pressed

 

Hi All,

 

Please review the test bug fix for JDK-8169954 : JFileChooser/8021253: java.lang.RuntimeException: Default button is not pressed.

 

Issue:

The Test under  8021253 is opening up a filechooser iconified, causing a failure to hit Enter key on the filechooser. Test failure is intermittent and more pronounced when run along with the entire javax/swing suite.

 

Fix:

This is occurring due to synchronization issues in the previous test 7199708. 
The test for bug 7199708 checks if the filechooser can load up a large number of files without a crash. In doing so it also tries to sort the columns of the filechooser via Robot mouse move and click actions. 
Commenting out these robot actions ensured that the next test 8021253 was passing indicating that this was a problem of with synchronization of the filechooser UI sorting and disposal of filechooser and that root cause was that these were not synchronized properly. Hence fixed the code flow using the regtesthelpers classes, to ensure that this is working correctly now.

Also ensured the filechooser of test 8021253 is not opened iconified and has focus. 

 

Testing:

Tested the potential fix on winx64, linux  with JDK8, 9 several times with running tests individually clubbed with the previous test and the entire suite (i.e javax/swing) put to ensure that the issue is not repeated.

 

Bug Id:

https://bugs.openjdk.java.net/browse/JDK-8169954

 

WebRev Request:

http://cr.openjdk.java.net/~akolarkunnu/8169954/webrev.00/

 

 

Regards,

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

From srinivas.mandalika at oracle.com  Mon Jun 19 11:41:51 2017
From: srinivas.mandalika at oracle.com (Srinivas Mandalika)
Date: Mon, 19 Jun 2017 04:41:51 -0700 (PDT)
Subject: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169957:
 javax/swing/JScrollBar/4708809: The scrollbar moved with incorrect
 direction
In-Reply-To: <1c655c5f-2a5e-4d69-8dad-f0eac75bc8fe@default>
References: <1c655c5f-2a5e-4d69-8dad-f0eac75bc8fe@default>
Message-ID: <247bfc02-342b-4cb5-a7e8-f0d187fb1d33@default>

Hi All,

 

Please review the test bug fix for JDK-8169957: javax/swing/JScrollBar/4708809: The scrollbar moved with incorrect direction.

 

Regards,

Srinivas M

 

From: Srinivas Mandalika 
Sent: Monday, June 12, 2017 1:50 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169957: javax/swing/JScrollBar/4708809: The scrollbar moved with incorrect direction

 

Hi All,

 

Please review the test bug fix for JDK-8169957: javax/swing/JScrollBar/4708809: The scrollbar moved with incorrect direction.

 

Issue:

This test checks whether a scrollbar drag moves in the correct direction. This behavior is working as expected when tested manually. The test was failing robot clicks out of sync with the yet to be maximized frame.

 

Fix:

Ensure the robot waits for the frame to be maximized before the scroll actions. Also ensure the main application frame is maximized explicitly.

 

Testing: 

Tested the potential fix on winx64, linux  with JDK8, 9 several times with running tests individually clubbed with the previous test and the entire suite (i.e javax/swing) put to ensure that the issue is not repeated.

 

Bug Id: https://bugs.openjdk.java.net/browse/JDK-8169957

Webrev: http://cr.openjdk.java.net/~akolarkunnu/8169957/webrev.00/

 

Thanks

Srinivas M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170619/2273fd7f/attachment.html>

From sergey.bylokhov at oracle.com  Mon Jun 19 14:03:36 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 19 Jun 2017 17:03:36 +0300
Subject: <Swing Dev> [10] RFR JDK-6267105:UIDefaults.getUIError dumps
 error message to System.err and also throws Error.
In-Reply-To: <dd579c74-26c7-4462-9e0c-f2ac4afddacc@default>
References: <c2655a81-8016-4ab5-b44c-e5e158de8a51@default>
 <be0276b1-dbc9-f295-ddff-5bafcd406b98@oracle.com>
 <7E2E238A-591F-4D0D-B4E3-D90CC3A6A98E@oracle.com>
 <dd579c74-26c7-4462-9e0c-f2ac4afddacc@default>
Message-ID: <259AF4C7-785A-40B0-9037-342607161D3E@oracle.com>

Error class is a subclass of Throwable, so currently the code throw an Error and immediately catch it, then print stack trace.

> 
> Hi Sergey, The below marked stack trace would be hit if there is any exception raised while creating the Error object in the try block. But the user would still get the stack trace if the exception is not handled because the Error calls base class function of Throwable:
>  
>     public Throwable(String message) {
>         fillInStackTrace();
>         detailMessage = message;
>     }
> ? <>
> The stack trace would be printed by the above code in Throwable implementation. I believe it is inevitable to print this because this is one of the basic level implementation and we do have an unhandled exception. And I don?t think I should do any change in here. Please let me know if you think otherwise.
>  
> I have attached the test file which I used to test the user level effects. The user won?t be able to use the expressions like  this (if(UIManager.getUI(comp) == null)) as mentioned in the JIRA bug but he will be able to use the below catching code:
> try {
>     System.out.println("Updating UI");
>     UIManager.getUI(comp);
> } catch (Exception e) {
>     System.out.println("GetUI is null");
>     System.out.println(e.getMessage());
> }
>  
> The output of this is as follows:
> Updating UI
> GetUI is null
> Null
>  
> If the there is no exception catch performed then it would have the below output:
> LAF State: [Custom LAF - CustomUI$1],LAF Class: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
> Exception in thread "main" java.lang.NullPointerException
>                at java.desktop/javax.swing.MultiUIDefaults.getUIError(MultiUIDefaults.java:131)
>                at java.desktop/javax.swing.UIDefaults.getUI(UIDefaults.java:790)
>                at java.desktop/javax.swing.UIManager.getUI(UIManager.java:1065)
>                at CustomUI.main(CustomUI.java:50)
>  
> Process finished with exit code 1
>  
> Please let me know if any part of my analysis is wrong or skewed.
>  
> Thanks and regards,
> Shashi
>  
> -----Original Message-----
> From: Sergey Bylokhov 
> Sent: Saturday, June 17, 2017 1:22 AM
> Cc: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com <mailto:shashidhara.veerabhadraiah at oracle.com>>; swing-dev <swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>>; Philip Race <philip.race at oracle.com <mailto:philip.race at oracle.com>>; Semyon Sadetsky <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>>
> Subject: Re: <Swing Dev> [10] RFR JDK-6267105:UIDefaults.getUIError dumps error message to System.err and also throws Error.
>  
> Hi, Shashi.
> Can you please clarify the purpose of this fix, because the bug states that the code prints traceback to the system.err, even if the user tries to catch/suppress an exception.
> The current fix removed the system.err logging but the code which print trace still there:
>     protected void getUIError(String msg) {
>         try {
>             throw new Error(msg);
>         }
>         catch (Throwable e) {
>             e.printStackTrace();
>         }
>     }
> >> Through catching the error, the user can perform necessary recovery actions without cluttering the system.err
>  
> I am not sure that the user is able to catch this error. So what is the difference when we had an additional message before and after the fix?
>  
> > 
> > +1
> > 
> > --Semyon
> > 
> > 
> > On 06/12/2017 03:54 AM, Shashidhara Veerabhadraiah wrote:
> >> Hi All,
> >>           Please review the code bug fix for JDK-6267105:UIDefaults.getUIError dumps error message to System.err and also throws Error.
> >> 
> >> Issue:
> >>      Error message was getting dumped to the system.err even though the recovery actions were performed leading to unnecessary confusion regarding the actual behavior.
> >> 
> >> Fix:
> >>     This fix removes the call which prints the message to the system.err and stores the message in the Error class. This same message can be retrieved after we catch the error and calling getMessage() of the Error class. Through catching the error, the user can perform necessary recovery actions without cluttering the system.err. This fix does not modifies the 'user effect' as the user would still get the same error as they were getting before this fix.
> >> 
> >> Test:
> >>     Now the system.err does not get cluttered though we performed the necessary recovery actions. The error message string can be recovered by calling getMessage() if needed.
> >>    Bug:
> >> https://bugs.openjdk.java.net/browse/JDK-6267105 <https://bugs.openjdk.java.net/browse/JDK-6267105>
> >> 
> >> Webrev:
> >> http://cr.openjdk.java.net/~aghaisas/shashi/6267105/webrev_00/ <http://cr.openjdk.java.net/~aghaisas/shashi/6267105/webrev_00/>
> >> 
> >> Thanks and regards,
> >> Shashi
> > 
>  
>  
> <CustomUI.JAVA>

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

From sergey.bylokhov at oracle.com  Mon Jun 19 14:29:04 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 19 Jun 2017 17:29:04 +0300
Subject: <Swing Dev> [10] RFR JDK-8075063:Context menu closes on mouse
 scroll
In-Reply-To: <97d37ed7-6f79-b940-29e6-d982645cb844@oracle.com>
References: <8c997c2e-bf01-7957-22fa-43ac18e9ca88@oracle.com>
 <be992d75-65cb-8c55-f3e6-d3685f5fa0e0@oracle.com>
 <9c06120b-c8c0-6ee2-048b-5626f9bea344@oracle.com>
 <04fa0a6c-6302-64f9-e6c7-f5342acab758@oracle.com>
 <6f4d381f-1be5-7bca-6a7e-a17d621c85b1@oracle.com>
 <17c5c10e-d0ad-c278-a9ab-038192b34fc6@oracle.com>
 <0a7b852c-4c78-81ca-b2f6-ba1bb69736af@oracle.com>
 <f5914b14-e791-5a9a-2ad5-56a172719488@oracle.com>
 <924dd4d2-44bd-480c-72e1-193c9761c6fc@oracle.com>
 <b9fd5984-a571-150d-8162-a23876b55976@oracle.com>
 <97d37ed7-6f79-b940-29e6-d982645cb844@oracle.com>
Message-ID: <69267B5A-794D-439B-A9CE-8153C7C05013@oracle.com>

The fix added a number of checks to exclude execution of ?cancelPopupMenu? on MOUSE_WHEEL, so I wonder in which situations we should execute cancelPopupMenu?

> 
> Fair enough suggestion, modified webrev to never ungrab for wheel event
> 
> http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.02/
> 
> Regards
> Prasanta
> On 6/16/2017 9:37 PM, Semyon Sadetsky wrote:
>> They are related to a wheel event happend in another java window (not outside the app).
>> My questions is if we do not ungrab on wheel event outside the app should we be consistent and do never ungrab on wheel event?
>> 
>> --Semyon
>> 
>> 
>> On 06/16/2017 08:49 AM, Prasanta Sadhukhan wrote:
>>> I was not sure about the scenario at what condition those ungrabs are sent, so I did not modify those. For wheel event outside our java window was the scenario here and my modification fixed that.
>>> 
>>> // According to the specification of UngrabEvent, post it
>>>   // when press occurs outside of the window and not on its owned windows
>>> 
>>> Regards
>>> Prasanta
>>> On 6/16/2017 8:57 PM, Semyon Sadetsky wrote:
>>>> In lines 2337 and 2345 ungrab is also sent. Shouldn't the button number be checked there as well before ungrab?
>>>> 
>>>> --Semyon
>>>> 
>>>> 
>>>> On 06/16/2017 03:22 AM, Prasanta Sadhukhan wrote:
>>>>> Yes, it is failing in linux as it posts a UngrabEvent which causes the popup to be closed in BasicPopupMenuUI at eventDispatched()
>>>>> 
>>>>> if(ev instanceof sun.awt.UngrabEvent) {
>>>>>                // Popup should be canceled in case of ungrab event
>>>>>                cancelPopupMenu( );
>>>>>                return;
>>>>>            }
>>>>> I have modified to not post the ungrab event if mouse wheel is rotated by checking if button 4 or 5 is pressed or not.
>>>>> as per https://stackoverflow.com/questions/15510472/scrollwheel-event-in-x11
>>>>> and
>>>>> ftp://www.x.org/pub/X11R6.8.0/doc/mouse.4.html [Wheel button events (typically buttons 4 and 5) are usually used for scrolling]
>>>>> 
>>>>> http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.01/
>>>>> 
>>>>> Regards
>>>>> Prasanta
>>>>> On 6/15/2017 8:55 PM, Semyon Sadetsky wrote:
>>>>>> On 06/15/2017 08:18 AM, Prasanta Sadhukhan wrote:
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 6/15/2017 8:40 PM, Semyon Sadetsky wrote:
>>>>>>>> On 06/14/2017 09:54 PM, Prasanta Sadhukhan wrote:
>>>>>>>>> Hi Semyon,
>>>>>>>>> 
>>>>>>>>> I tried on Firefox and other app. If popup or drop down menu is opened, then mouse wheel rotation is not closing the popups. In our case, it is closing the popups/menus.
>>>>>>>> That is true. I meant you fixed only the case when the mouse wheel rotation is over java windows (wheel event's source != null). What will be if the wheel is rotated outside java (source == null), or it is not the case?
>>>>>>>> 
>>>>>>> It is not closing in other app (if it rotated over non-app window) as well as in our java with my fix.
>>>>>> Did you check this on all platforms? At least on my Ubuntu it is not so.
>>>>>> 
>>>>>> --Semyon
>>>>>>> 
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>>> --Semyon
>>>>>>>>> 
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>> On 6/14/2017 8:26 PM, Semyon Sadetsky wrote:
>>>>>>>>>> Hi Prasanta,
>>>>>>>>>> 
>>>>>>>>>> I may be wrong, but it seems to me that the standard behavior is when any wheel event cannot close popups.
>>>>>>>>>> 
>>>>>>>>>> --Semyon
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On 06/13/2017 10:39 PM, Prasanta Sadhukhan wrote:
>>>>>>>>>>> Hi All,
>>>>>>>>>>> 
>>>>>>>>>>> Please review a fix for an issue whereby it is seen
>>>>>>>>>>> hitting the scroll wheel by accident closes whole structure of context menus causing it to disappear and the user has to invoke the menu again.
>>>>>>>>>>> 
>>>>>>>>>>> Issue was popupMenu is getting closed for mouse wheel rotation if the menu is not from JComboBox.
>>>>>>>>>>> If the context menu is opened from JMenuItem, JMenu then if the mouse wheel is rotated anywhere in frame, then it calls cancelPopupMenu() causing it to call setVisible(false) and so menu disappears.
>>>>>>>>>>> 
>>>>>>>>>>> Proposed fix is to check if the mouse wheel rotation is done in JMenu, JMenuItem or anywhere in frame, then if popup is present, then do not close the popupmenu.
>>>>>>>>>>> 
>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075063
>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.00/
>>>>>>>>>>> 
>>>>>>>>>>> Regards
>>>>>>>>>>> Prasanta
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 



From sergey.bylokhov at oracle.com  Mon Jun 19 14:34:28 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 19 Jun 2017 17:34:28 +0300
Subject: <Swing Dev> [10] RFR JDK-8181421: 3 regtest fail on windows7 in
 Nimbus L&F
In-Reply-To: <0b293f12-e1ad-f439-00e7-e3811e3275c4@oracle.com>
References: <7194c05f-f147-4df8-8947-7053a3d1d60b@default>
 <0b293f12-e1ad-f439-00e7-e3811e3275c4@oracle.com>
Message-ID: <A7815852-ED9D-4546-A805-1C8E32B8D858@oracle.com>


> private void updateStyle(JPanel c) {
>         SynthContext context = getContext(c, ENABLED);
>         style = SynthLookAndFeel.updateStyle(context, this);
>     }
> it calls getContext() which in turn calls SynthContext.getContext() with style variable. 
> private SynthContext getContext(JComponent c, int state) {
>         return SynthContext.getContext(c, style, state);
>     }
> Now, "style"  variable seems to be null at this point in SYnthPanelUI.java and 
> it only gets updated after getContext() call when it calls then next line SynthLookAndFeel.updateStyle(context, this);

And the question why it is null here in these test cases, but correct value in others tests.

> 
> I could not remove the html file as I am getting some serialization issue if I moved from applet to main based so I retained applet based test, as of now. Also, due to it being applet, I am not sure how to run them over installed l&f inside the test.

I see that in the latest version you remove html files, and now you can iterate over all installed l&f.

> 
> Modified webrev with test issues rectfied
> http://cr.openjdk.java.net/~psadhukhan/8181421/webrev.01/ <http://cr.openjdk.java.net/~psadhukhan/8181421/webrev.01/>
> 
> Regards
> Prasanta
> On 6/2/2017 1:35 AM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>> I have few small notes.
>>  - Did you check why the null value was passed to this method?
>>  - It seems that the tests are passed by default. It would be good to run them over the installed l&f. In this case they will fail before the fix.
>>  - Is it possible to remove the html files from the tests?
>>  - The tests also have some common issues, the Swing components are accessed on non-edt thread. some unnecessary commented code, etc.
>> 
>> ----- prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com> wrote: 
>> >
>> Hi All,
>> Please review a subitem fix of JDK-7190554 <https://bugs.openjdk.java.net/browse/JDK-7190554> where some closed regression test is failing with Nimbus L&F.
>> Issue was we were getting NPE 
>> > which is because a null style was used in SynthPanelUI to generate the SynthContext
>> > 
>> > java.lang.NullPointerException: You must supply a non-null component, region and style
>> >     at java.desktop/javax.swing.plaf.synth.SynthContext.getContext(SynthContext.java:58)
>> >     at java.desktop/javax.swing.plaf.synth.SynthContext.getContext(SynthContext.java:49)
>> >     at java.desktop/javax.swing.plaf.synth.SynthPanelUI.getContext(SynthPanelUI.java:128)
>> >     at java.desktop/javax.swing.plaf.synth.SynthPanelUI.updateStyle(SynthPanelUI.java:115)
>> >     at java.desktop/javax.swing.plaf.synth.SynthPanelUI.installDefaults(SynthPanelUI.java:100)
>> > 
>> > Proposed fix is to generate a style before generating SynthContext because as per spec,
>> > https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/plaf/synth/SynthContext.html <https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/plaf/synth/SynthContext.html>
>> > it should throw NPE - if component, region or style is null.
>> > 
>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8181421 <https://bugs.openjdk.java.net/browse/JDK-8181421>
>> > webrev: http://cr.openjdk.java.net/~psadhukhan/8181421/webrev.00/ <http://cr.openjdk.java.net/%7Epsadhukhan/8181421/webrev.00/>
>> > 
>> > Regards
>> > Prasanta
>> > 
> 
> 

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

From sergey.bylokhov at oracle.com  Mon Jun 19 14:44:25 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 19 Jun 2017 17:44:25 +0300
Subject: <Swing Dev> [10] RFR: JDK-7020860: BasicTreeUI contains
 getters/setters with unclear spec
In-Reply-To: <b70fd389-56b8-176f-4878-0d9d5d3da293@oracle.com>
References: <b70fd389-56b8-176f-4878-0d9d5d3da293@oracle.com>
Message-ID: <8D67BC7D-27C8-4BE3-830A-97547CEE5DDD@oracle.com>

Hi, Prasanta.
Please take a look to my comments here:
http://mail.openjdk.java.net/pipermail/swing-dev/2016-October/006816.html <http://mail.openjdk.java.net/pipermail/swing-dev/2016-October/006816.html>
We can append the text instead of replacing it, the docs will look like: What it will do, when it will be called.
We need to check other methods in this class also.

> 
> Hi All,
> 
> This is a revisit of update in BasicTreeUI spec. It is same as previous webrev with only modification of isRootVisible() as per the comments posted last time.
> ccc also seemed to be approved.
> Bug: https://bugs.openjdk.java.net/browse/JDK-7020860
> webrev: http://cr.openjdk.java.net/~psadhukhan/7020860/webrev.00/
> 
> Regards
> Prasanta
> 

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

From sergey.bylokhov at oracle.com  Mon Jun 19 15:02:03 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 19 Jun 2017 18:02:03 +0300
Subject: <Swing Dev> [10] RFR: JDK-8043315: Nimbus: Setting
 Nimbus.Overrides property affects custom keymap installation
In-Reply-To: <8af41cf8-f51a-6322-9664-6d45fc640a80@oracle.com>
References: <54afabea-f351-4fd5-860a-29bd293b2c6d@default>
 <8af41cf8-f51a-6322-9664-6d45fc640a80@oracle.com>
Message-ID: <FF30652A-0A02-4BA9-A491-0A7CEC58F498@oracle.com>


> I have modified webrev to remove static keyword and made the test automated

Should the same change be applied to SynthTextAreaUI/SynthTextFieldUI?
In the test you should throw an exception if Nimbus cannot be set, or you can iterate over all installed l&f.

> http://cr.openjdk.java.net/~psadhukhan/8043315/webrev.01/
> Updated fix tests if app has fired a property change by calling setKeymap() then it will not uninstall custom keymap and let the custom keymap be honoured. If app again calls setKeymap(null) then the static variable will be "true" and it will reset back to default keymap.
> 
> Regards
> Prasanta
> On 6/2/2017 12:07 AM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>> Can you please clarify the fix a little bit.
>> You have a static variable, which is set to "false" when the listener for "keymap" is triggered, and it seems that you never set it back to "true"? Is it intentional behavior?
>> Note that if there are a few objects of "SynthEditorPaneUI" then they will share this static field. Also it seems that the test can be automated, because currently it is requires from the user to press only one button("space").
>> 
>> ----- prasanta.sadhukhan at oracle.com wrote:
>> 
>>> Hi All,
>>> 
>>> Please review a bug fix for Nimbus L&F where if app sets custom keymap
>>> 
>>> and then sets Nimbus.Overrides property,
>>> then the custom keymap is not honoured.
>>> For example, if testapp sets a new action for "space" key press and
>>> sets
>>> sets Nimbus.Overrides property,
>>>   it will not be honoured and default action ie. inserting a "space"
>>> character will be done.
>>> 
>>> Issue was NimbusLookAndFeel#shouldUpdateStyleOnEvent() returns true
>>> for
>>> Nimbus.Override property which causes SynthEditorPaneUI#updateStyle()
>>> to
>>> be called which
>>> uninstall set keyboard actions and sets up default keyboard action.
>>> 
>>> Proposed fix is to check if a keymap is already set (a propertyChange
>>> 
>>> event will be fired for when app calls setKeyMap()) then do not reset
>>> to
>>> default keymap.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8043315
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8043315/webrev.00/
>>> 
>>> Regards
>>> Prasanta
> 



From sergey.bylokhov at oracle.com  Mon Jun 19 15:08:46 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 19 Jun 2017 18:08:46 +0300
Subject: <Swing Dev> [10] RFR: JDK-8075918:The regression-swing case
 failed as the long Tab titles are not clipped with dots at the end with
 NimbusLookAndFeel
In-Reply-To: <066deef0-4b60-d430-2f25-2aa699eb0c57@oracle.com>
References: <a4a1ae6b-2d1c-4d99-abcf-e2a3cd24659d@default>
 <27bb815b-ba6c-0b06-7cc2-a84fc38d8b57@oracle.com>
 <A6A5EB65-4E18-47AB-8E1A-73B7FECDFB85@oracle.com>
 <7b5d79ce-3f1b-d7be-486b-e836bf3a5862@oracle.com>
 <34003A0F-6EE2-42B6-A920-404769399E38@oracle.com>
 <be81fbcf-155b-5e9c-c40c-e9cf8a15447e@oracle.com>
 <066deef0-4b60-d430-2f25-2aa699eb0c57@oracle.com>
Message-ID: <50FCC80B-1D8A-4701-82CB-03BBBE2FC519@oracle.com>

I am only not sure about type casting w/o instanceof, if we always have Graphics2D then this fix looks fine.

> Hi Sergey,
> Is anything more needed to be done for this? I guess I have modified as per the review comment.
> 
> Regards
> Prasanta
> On 6/9/2017 11:33 AM, Prasanta Sadhukhan wrote:
>> Ok. Rectified. Please find the modified webrev with clip at correct place(s)
>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.05/ <http://cr.openjdk.java.net/%7Epsadhukhan/8075918/webrev.05/>
>> 
>> Regards
>> Prasanta
>> On 6/8/2017 9:34 PM, Sergey Bylokhov wrote:
>>> I have referenced these methods:	
>>> 
>>> "BasicTabbedPaneUI.paintIcon() as well as SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>>> ?- paintText() at line 681	
>>> ?- paintIcon() at line 634
>>> Both methods have a rectangle as a parameter, but it is ignored."
>>> The first is in the BasicTabbedPaneUI.java and the second is in the SynthGraphicsUtils.java
>>> 
>>>> 
>>>> Why? clip is invoked in SynthTabbedPaneUI#paintText() at line 687 and SynthTabbedPaneUI#paintTab() at line 637, where you asked for, I guess.
>>>> Regards
>>>> Prasanta
>>>> On 6/8/2017 12:59 PM, Sergey Bylokhov wrote:
>>>>> But in this version the clip operation still not executed in methods mentioned here:
>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2017-June/007419.html <http://mail.openjdk.java.net/pipermail/swing-dev/2017-June/007419.html>
>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2017-May/007406.html <http://mail.openjdk.java.net/pipermail/swing-dev/2017-May/007406.html>
>>>>> 
>>>>>> 
>>>>>> Please find the modified webrev incorporating your review comment
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.04/ <http://cr.openjdk.java.net/%7Epsadhukhan/8075918/webrev.04/>
>>>>>> 
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 6/2/2017 12:33 AM, Sergey Bylokhov wrote:
>>>>>>> ?- There is a problem in your algorithm which merges the old and new clips. The getClipBounds() returns a rectangle which is a bounds of the current clip(which is not necessary a rectangle but can be a shape). you can use the Graphics2D.clip(Shape) method which will intersect the passed shape and a current clip of the graphics.
>>>>>>> ?- In this version you forgot to restore the changed clip.
>>>>>>> ?- Also can you try to move the code which change a clip to the methods which currently ignore the passed clip(see below):
>>>>>>>>>> BasicTabbedPaneUI.paintIcon() as well as
>>>>>>>>>> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>>>>>>>>>> ??- paintText() at line 681
>>>>>>>>>> ??- paintIcon() at line 634
>>>>>>>>>> Both methods have a rectangle as a parameter, but it is ignored.
>>>>>>> 
>>>>>>> ----- prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com> wrote:
>>>>>>> 
>>>>>>>> I tried to incorporate your comments. Please find modified webrev
>>>>>>>> 
>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.03/ <http://cr.openjdk.java.net/%7Epsadhukhan/8075918/webrev.03/>
>>>>>>>> 
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>> On 5/28/2017 8:01 AM, Sergey Bylokhov wrote:
>>>>>>>>> Note that you shouldn't replace the clip, but should apply the new
>>>>>>>> clip on top of the old. This is necessary if the old clip is smaller
>>>>>>>> than new.
>>>>>>>>> ----- sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com> wrote:
>>>>>>>>> 
>>>>>>>>>> Hi, Prasanta.
>>>>>>>>>> 
>>>>>>>>>> BasicTabbedPaneUI.paintIcon() as well as
>>>>>>>>>> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>>>>>>>>>> ??- paintText() at line 681
>>>>>>>>>> ??- paintIcon() at line 634
>>>>>>>>>> Both methods have a rectangle as a parameter, but it is ignored.
>>>>>>>>>> 
>>>>>>>>>> ----- prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Hi Sergey,
>>>>>>>>>>> 
>>>>>>>>>>> I could get your concern for paintText() but could not find
>>>>>>>>>>> paintIcon()
>>>>>>>>>>> in SynthGraphicsUtils() so not sure how icon drawing contradicts
>>>>>>>>>>> spec.
>>>>>>>>>>> Modified webrev:
>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/ <http://cr.openjdk.java.net/%7Epsadhukhan/8075918/webrev.01/>
>>>>>>>>>>> 
>>>>>>>>>>> Also, if we are not calling
>>>>>>>> SwingUtilities2.clipStringIfNecessary()
>>>>>>>>>>> then
>>>>>>>>>>> we are not going to get "..." at the end which this test expects.
>>>>>>>>>> But
>>>>>>>>>>> I
>>>>>>>>>>> could not find anything in spec, that mandates ending with "..."
>>>>>>>> for
>>>>>>>>>>> long tab outside
>>>>>>>>>>> tab bounds. If source change is ok, I guess we then need to
>>>>>>>> modify
>>>>>>>>>> the
>>>>>>>>>>> html file modifying the expected result for NimbusL&F.
>>>>>>>>>>> 
>>>>>>>>>>> Regards
>>>>>>>>>>> Prasanta
>>>>>>>>>>> On 5/25/2017 3:11 AM, Sergey Bylokhov wrote:
>>>>>>>>>>>> Hi, Prasanta.
>>>>>>>>>>>> Please take a look to my comments at:
>>>>>>>>>>>> 
>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html <http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html>
>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html <http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html>
>>>>>>>>>>>> The two methods paintText() and paintIcon() are contradict the
>>>>>>>>>> spec
>>>>>>>>>>> and draw the text and icons outside of the tab.
>>>>>>>>>>>> ----- prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Please review a fix for an issue where long Tab titiles are not
>>>>>>>>>>>>> clipped
>>>>>>>>>>>>> with dots at end for NimbusLookAndFeel L&F.
>>>>>>>>>>>>> Other L&Fs works ok.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Issue was in SynthTabbedPaneUI#paintTab(), the title is not
>>>>>>>>>>> clipped
>>>>>>>>>>>>> but
>>>>>>>>>>>>> passed to paintText() as it is received.
>>>>>>>>>>>>> Other L&F such as Metal, Motif, Windows which uses
>>>>>>>>>>>>> BasicTabbedPaneUI#paintTab(), the title is clipped
>>>>>>>>>>>>> 
>>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950 <http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950>
>>>>>>>>>>>>> before it is passed to paintText().
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Proposed fix is to do the same for
>>>>>>>> SynthTabbedPaneUI#paintTab().
>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075918 <https://bugs.openjdk.java.net/browse/JDK-8075918>
>>>>>>>>>>>>> webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/ <http://cr.openjdk.java.net/%7Epsadhukhan/8075918/webrev.00/>
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>> Prasanta
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

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

From sergey.bylokhov at oracle.com  Mon Jun 19 15:29:55 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 19 Jun 2017 18:29:55 +0300
Subject: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169958 :
 javax/swing/JSpinner/5012888: Spinner value should be more than 1
In-Reply-To: <0ce40baf-45ab-4dd4-bd95-d7b3bce5751b@default>
References: <0ce40baf-45ab-4dd4-bd95-d7b3bce5751b@default>
Message-ID: <57613095-3833-484F-AF8D-69060D98CED7@oracle.com>

Hi,
When I run the updated test case I got this error in the log[1].
You will need to rethrow all exception from the catch block, instead of printStackTrace

[1]
java.lang.IllegalThreadStateException: Cannot call method from the event dispatcher thread
	at java.awt.Robot.checkNotDispatchThread(Robot.java:573)
	at java.awt.Robot.waitForIdle(Robot.java:552)
	at bug5012888.doTest(bug5012888.java:55)
	at bug5012888$2.run(bug5012888.java:76)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
	at java.awt.EventQueue.access$500(EventQueue.java:97)
	at java.awt.EventQueue$3.run(EventQueue.java:709)
	at java.awt.EventQueue$3.run(EventQueue.java:703)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

> 
> Hi All,
>  
> Please review the test bug fix for JDK-8169958 : javax/swing/JSpinner/5012888: Spinner value should be more than 1.
>  
> Issue: 
> In this bug, click & hold on arrow of JSpinner only transfers focus and does not change spinner value. This behavior is intermittently seen in the automated test but is working as expected when checked for manualy. The test was failing robot clicks out of sync with the yet to be maximized frame.
>  
> Fix: 
> Ensure the robot waits for the frame to be maximized before the clicks on the Spinner. Also ensure the main application frame is maximized explicitly.
>  
> Testing: 
> Tested the potential fix on winx64, linux  with JDK8, 9 several times with running tests individually clubbed with the previous test and the entire suite (i.e javax/swing) put to ensure that the issue is not repeated.
>  
> Bug Id:
> https://bugs.openjdk.java.net/browse/JDK-8169958 <https://bugs.openjdk.java.net/browse/JDK-8169958>
>  
>  
> WebRev Request:
> http://cr.openjdk.java.net/~akolarkunnu/8169958/webrev.00/ <http://cr.openjdk.java.net/~akolarkunnu/8169958/webrev.00/>
>  
>  
> Regards,
> Srinivas M

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

From sergey.bylokhov at oracle.com  Mon Jun 19 15:32:52 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 19 Jun 2017 18:32:52 +0300
Subject: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169958 :
 javax/swing/JSpinner/5012888: Spinner value should be more than 1
In-Reply-To: <a0fc42d0-ffdf-488f-bddb-650c6726697b@default>
References: <0ce40baf-45ab-4dd4-bd95-d7b3bce5751b@default>
 <3cefd74c-a841-46db-881a-4b31b78c2363@default>
 <a0fc42d0-ffdf-488f-bddb-650c6726697b@default>
Message-ID: <D2D70735-D08B-4C41-9F61-7BC07529458E@oracle.com>

Hi, Srinivas.
You will need to dispose the frame at the end of the test(when the test fails or pass).
> 
> Hi Ajit,
> 
> Thank you for your comments. I have incorporated all your comments.  There are also a few additional changes of invoking code on EDT that I made while executing this fix to validate the test stability. 
> 
> Updated webrev: http://cr.openjdk.java.net/~akolarkunnu/8169958/webrev.01/
> 
> 
> Thanks,
> Srinivas M
> 
> -----Original Message-----
> From: Ajit Ghaisas 
> Sent: Monday, June 12, 2017 2:41 PM
> To: Srinivas Mandalika <srinivas.mandalika at oracle.com>; swing-dev at openjdk.java.net
> Subject: RE: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169958 : javax/swing/JSpinner/5012888: Spinner value should be more than 1
> 
> Hi Srinivas,
> 
>   Here are few review comments :
>   1.  Add this bug id to the @bug jtreg tag in test
>   2. Replace generic import statements with specific ones
>   3. You are calling - b.doTest(); - in a try catch block. This will catch any exception and print stack trace. 
>       I think we can remove this try-catch block - simply make a call to b.doTest(), if an exception is thrown, it is thrown out from main() and jtreg framework will catch it and mark the test as failed.
>   4. Line 63 in your file has a throw error - this can be converted to exception.
>   5. Keep four spaces indentation level
> 
> Regards,
> Ajit
> 
> 
> From: Srinivas Mandalika 
> Sent: Monday, June 12, 2017 1:51 PM
> To: swing-dev at openjdk.java.net
> Subject: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169958 : javax/swing/JSpinner/5012888: Spinner value should be more than 1
> 
> Hi All,
> 
> Please review the test bug fix for JDK-8169958 : javax/swing/JSpinner/5012888: Spinner value should be more than 1.
> 
> Issue: 
> In this bug, click & hold on arrow of JSpinner only transfers focus and does not change spinner value. This behavior is intermittently seen in the automated test but is working as expected when checked for manualy. The test was failing robot clicks out of sync with the yet to be maximized frame.
> 
> Fix: 
> Ensure the robot waits for the frame to be maximized before the clicks on the Spinner. Also ensure the main application frame is maximized explicitly.
> 
> Testing: 
> Tested the potential fix on winx64, linux  with JDK8, 9 several times with running tests individually clubbed with the previous test and the entire suite (i.e javax/swing) put to ensure that the issue is not repeated.
> 
> Bug Id:
> https://bugs.openjdk.java.net/browse/JDK-8169958
> 
> 
> WebRev Request:
> http://cr.openjdk.java.net/~akolarkunnu/8169958/webrev.00/
> 
> 
> Regards,
> Srinivas M



From sergey.bylokhov at oracle.com  Mon Jun 19 16:00:55 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 19 Jun 2017 19:00:55 +0300
Subject: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169954 :
 JFileChooser/8021253: java.lang.RuntimeException: Default button is not
 pressed
In-Reply-To: <12f70f31-3e5a-47cc-b607-4f0991bcaba6@default>
References: <12f70f31-3e5a-47cc-b607-4f0991bcaba6@default>
Message-ID: <FB72E097-B880-457D-AB87-130C7DD81DBE@oracle.com>

Hi, Srinivas.
A few comments:
  * bug8021253.java:
      - You should not delete this lone "74 robot.waitForIdle()? because it is waits while the previous clicks are executed, w/o this line you can get a situation when defaultKeyPressed will be false because the code on EDT is in progress.
      - Do not use JRobot if it is not strictly necessary because this additional dependency will make harder to run the test standalone, w/o jtreg.
  * bug7199708.java:
      - Always rethrow an exception instead of e.printStackTrace();
      - I am not sure that SwingTestHelper is necessary here, it was useful while java had no lamda, so the code was quite long when we executed a number or ?InvokeAndWait?, but now it should be compact.(Even in the current code it is visible that after the fix the code became longer).
      - Please confirm that the test still fails before 7199708 was fixed.
      - The new line ?85? is too long please split it to fit 80 chars per line.
      - Please add a code to dispose the frame after test execution.

> Hi All,
>  
> Please review the test bug fix for JDK-8169954 : JFileChooser/8021253: java.lang.RuntimeException: Default button is not pressed.
>  
> Issue:
> The Test under  8021253 is opening up a filechooser iconified, causing a failure to hit Enter key on the filechooser. Test failure is intermittent and more pronounced when run along with the entire javax/swing suite.
>  
> Fix:
> This is occurring due to synchronization issues in the previous test 7199708. 
> The test for bug 7199708 checks if the filechooser can load up a large number of files without a crash. In doing so it also tries to sort the columns of the filechooser via Robot mouse move and click actions. 
> Commenting out these robot actions ensured that the next test 8021253 was passing indicating that this was a problem of with synchronization of the filechooser UI sorting and disposal of filechooser and that root cause was that these were not synchronized properly. Hence fixed the code flow using the regtesthelpers classes, to ensure that this is working correctly now.
> Also ensured the filechooser of test 8021253 is not opened iconified and has focus. 
>  
> Testing:
> Tested the potential fix on winx64, linux  with JDK8, 9 several times with running tests individually clubbed with the previous test and the entire suite (i.e javax/swing) put to ensure that the issue is not repeated.
>  
> Bug Id:
> https://bugs.openjdk.java.net/browse/JDK-8169954 <https://bugs.openjdk.java.net/browse/JDK-8169954>
>  
> WebRev Request:
> http://cr.openjdk.java.net/~akolarkunnu/8169954/webrev.00/ <http://cr.openjdk.java.net/~akolarkunnu/8169954/webrev.00/>
>  
>  
> Regards,
> Srinivas M

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

From sergey.bylokhov at oracle.com  Mon Jun 19 16:26:39 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 19 Jun 2017 19:26:39 +0300
Subject: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169957:
 javax/swing/JScrollBar/4708809: The scrollbar moved with incorrect
 direction
In-Reply-To: <247bfc02-342b-4cb5-a7e8-f0d187fb1d33@default>
References: <1c655c5f-2a5e-4d69-8dad-f0eac75bc8fe@default>
 <247bfc02-342b-4cb5-a7e8-f0d187fb1d33@default>
Message-ID: <B9F72A9B-CBC3-4796-9C67-8D6C1CEB0719@oracle.com>

Hi, Srinivas.
Can you please clarify the fix a little bit. You changed the type of the frame to the NORMAL, but this is a default type. So it is unclear what was the reason of the test failure.
Also please add a code which will dispose the frame at the end of the test.

> 
> Hi All,
>  
> Please review the test bug fix for JDK-8169957: javax/swing/JScrollBar/4708809: The scrollbar moved with incorrect direction.
>  
> Regards,
> Srinivas M
>  
> From: Srinivas Mandalika 
> Sent: Monday, June 12, 2017 1:50 PM
> To: swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
> Subject: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169957: javax/swing/JScrollBar/4708809: The scrollbar moved with incorrect direction
>  
> Hi All,
>  
> Please review the test bug fix for JDK-8169957: javax/swing/JScrollBar/4708809: The scrollbar moved with incorrect direction.
>  
> Issue:
> This test checks whether a scrollbar drag moves in the correct direction. This behavior is working as expected when tested manually. The test was failing robot clicks out of sync with the yet to be maximized frame.
>  
> Fix:
> Ensure the robot waits for the frame to be maximized before the scroll actions. Also ensure the main application frame is maximized explicitly.
>  
> Testing: 
> Tested the potential fix on winx64, linux  with JDK8, 9 several times with running tests individually clubbed with the previous test and the entire suite (i.e javax/swing) put to ensure that the issue is not repeated.
>  
> Bug Id: https://bugs.openjdk.java.net/browse/JDK-8169957 <https://bugs.openjdk.java.net/browse/JDK-8169957>
> Webrev: http://cr.openjdk.java.net/~akolarkunnu/8169957/webrev.00/ <http://cr.openjdk.java.net/~akolarkunnu/8169957/webrev.00/>
>  
> Thanks
> Srinivas M

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

From sergey.bylokhov at oracle.com  Mon Jun 19 16:47:31 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 19 Jun 2017 19:47:31 +0300
Subject: <Swing Dev> [9] Crash tabbing to a checkbox with custom model
 (see e.g. 8074883)
In-Reply-To: <163b68b2-2eaa-2b09-9a1a-5e1f24e02ed2@yahoo.co.uk>
References: <163b68b2-2eaa-2b09-9a1a-5e1f24e02ed2@yahoo.co.uk>
Message-ID: <BEBA5954-0D5E-450F-B8DE-CD03492CB3A2@oracle.com>

Hi,
Can you please create a new CR using http://bugs.java.com <http://bugs.java.com/> ?
It is too late to fix it in jdk9, but I think it will be possible to fix it in 10 and then backport to some update of jdk9.

> 
> Good day,
> 
> I believe I've hit my first bug in occasional testingof the JDK-9 drops.
> I hope this is an appropriate way to send feedback?
> 
> We use a customised "tri-state" checkbox, which triggers a crash when the
> keyboard focus moves to it by pressing the TAB key. The issue seems related
> to some focus logic changes with button-groups introduced in JDK-9.
> (For example: 8074883?)
> 
> The top of the stack trace is:
> 
> java.lang.ClassCastException: com.example.TristateCheckBox$TristateDecorator cannot be cast to java.desktop/javax.swing.JToggleButton$ToggleButtonModel
>    at java.desktop/javax.swing.LayoutFocusTraversalPolicy.accept(LayoutFocusTraversalPolicy.java:243)
>    at java.desktop/javax.swing.SortingFocusTraversalPolicy.getComponentBefore(SortingFocusTraversalPolicy.java:435)
>    at java.desktop/javax.swing.LayoutFocusTraversalPolicy.getComponentBefore(LayoutFocusTraversalPolicy.java:143)
>    at java.desktop/java.awt.Component.transferFocusBackward(Component.java:8201)
>    at java.desktop/java.awt.Component.transferFocusBackward(Component.java:8186)
>    at java.desktop/java.awt.DefaultKeyboardFocusManager.focusPreviousComponent(DefaultKeyboardFocusManager.java:1388)
>    at java.desktop/java.awt.DefaultKeyboardFocusManager.processKeyEvent(DefaultKeyboardFocusManager.java:1183)
>    at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4877)
>    at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2317)
>    at java.desktop/java.awt.Component.dispatchEvent(Component.java:4793)
> ...
> 
> The relevant code in LayoutFocusTraversalPolicy.accept is:
> 
>    } else if (aComponent instanceof JComponent) {
>        if (SunToolkit.isInstanceOf(aComponent,
> "javax.swing.JToggleButton")) {
>            JToggleButton.ToggleButtonModel model =
>                    (JToggleButton.ToggleButtonModel) ((JToggleButton)
>                            aComponent).getModel();   // <- Line 243
>            if (model != null) {
>                ButtonGroup group = model.getGroup(); // <- Only use of 'model'
> 
> For whatever reason (probably to do with the 3 states) the button model
> is not a ToggleButtonModel, but derived from a DefaultButtonModel.
> 
> I think a simple solution is to (check? and) cast less specifically, to a
> DefaultButtonModel instead. That looks to be sufficient here, and is also
> what we find similar code in JToggleButton doing. For example in
> JToggeleButton.getGroupSelection we see:
> 
>    if (model instanceof DefaultButtonModel) {
>        ButtonGroup group = ((DefaultButtonModel) model).getGroup();
>        //...
> 
> I note while JToggleButton creates a ToggleButtonModel by default, it
> does not enforce it via setModel().
> 
> 
> More background: I think we found this code (over a decade ago) from here
> 
>  http://www.javaspecialists.eu/archive/Issue082.html
> 
> (There are better solutions implementing this GUI control these days, but
> I thought you might like to hear about it.)
> 
> Kind regards,
> Luke Usherwood
> 
> 

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

From ldubox-coding101 at yahoo.co.uk  Mon Jun 19 19:33:03 2017
From: ldubox-coding101 at yahoo.co.uk (Luke)
Date: Mon, 19 Jun 2017 21:33:03 +0200
Subject: <Swing Dev> [9] Crash tabbing to a checkbox with custom model
 (see e.g. 8074883)
In-Reply-To: <BEBA5954-0D5E-450F-B8DE-CD03492CB3A2@oracle.com>
References: <163b68b2-2eaa-2b09-9a1a-5e1f24e02ed2@yahoo.co.uk>
 <BEBA5954-0D5E-450F-B8DE-CD03492CB3A2@oracle.com>
Message-ID: <ed8a9c39-3be1-f641-1d73-a71bc09daa7d@yahoo.co.uk>

Hi Sergey,

Assuming CR is crash report, I've filed a bug report - assigned internal 
review ID : 9049636.

I included some minimal code to repo the issue there.

Kind regards,
Luke

On 19/06/2017 6:47 PM, Sergey Bylokhov wrote:
> Hi,
> Can you please create a new CR using http://bugs.java.com ?
> It is too late to fix it in jdk9, but I think it will be possible to 
> fix it in 10 and then backport to some update of jdk9.
>
>>
>> Good day,
>>
>> I believe I've hit my first bug in occasional testingof the JDK-9 drops.
>> I hope this is an appropriate way to send feedback?
>>
>> We use a customised "tri-state" checkbox, which triggers a crash when the
>> keyboard focus moves to it by pressing the TAB key. The issue seems 
>> related
>> to some focus logic changes with button-groups introduced in JDK-9.
>> (For example: 8074883?)
>>
>> The top of the stack trace is:
>>
>> java.lang.ClassCastException: 
>> com.example.TristateCheckBox$TristateDecorator cannot be cast to 
>> java.desktop/javax.swing.JToggleButton$ToggleButtonModel
>>    at 
>> java.desktop/javax.swing.LayoutFocusTraversalPolicy.accept(LayoutFocusTraversalPolicy.java:243)
>>    at 
>> java.desktop/javax.swing.SortingFocusTraversalPolicy.getComponentBefore(SortingFocusTraversalPolicy.java:435)
>>    at 
>> java.desktop/javax.swing.LayoutFocusTraversalPolicy.getComponentBefore(LayoutFocusTraversalPolicy.java:143)
>>    at 
>> java.desktop/java.awt.Component.transferFocusBackward(Component.java:8201)
>>    at 
>> java.desktop/java.awt.Component.transferFocusBackward(Component.java:8186)
>>    at 
>> java.desktop/java.awt.DefaultKeyboardFocusManager.focusPreviousComponent(DefaultKeyboardFocusManager.java:1388)
>>    at 
>> java.desktop/java.awt.DefaultKeyboardFocusManager.processKeyEvent(DefaultKeyboardFocusManager.java:1183)
>>    at 
>> java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4877)
>>    at 
>> java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2317)
>>    at java.desktop/java.awt.Component.dispatchEvent(Component.java:4793)
>> ...
>>
>> The relevant code in LayoutFocusTraversalPolicy.accept is:
>>
>>    } else if (aComponent instanceof JComponent) {
>>        if (SunToolkit.isInstanceOf(aComponent,
>> "javax.swing.JToggleButton")) {
>>            JToggleButton.ToggleButtonModel model =
>>                    (JToggleButton.ToggleButtonModel) ((JToggleButton)
>>                            aComponent).getModel();   // <- Line 243
>>            if (model != null) {
>>                ButtonGroup group = model.getGroup(); // <- Only use 
>> of 'model'
>>
>> For whatever reason (probably to do with the 3 states) the button model
>> is not a ToggleButtonModel, but derived from a DefaultButtonModel.
>>
>> I think a simple solution is to (check? and) cast less specifically, to a
>> DefaultButtonModel instead. That looks to be sufficient here, and is also
>> what we find similar code in JToggleButton doing. For example in
>> JToggeleButton.getGroupSelection we see:
>>
>>    if (model instanceof DefaultButtonModel) {
>>        ButtonGroup group = ((DefaultButtonModel) model).getGroup();
>>        //...
>>
>> I note while JToggleButton creates a ToggleButtonModel by default, it
>> does not enforce it via setModel().
>>
>>
>> More background: I think we found this code (over a decade ago) from here
>>
>> http://www.javaspecialists.eu/archive/Issue082.html
>>
>> (There are better solutions implementing this GUI control these days, but
>> I thought you might like to hear about it.)
>>
>> Kind regards,
>> Luke Usherwood
>>
>>
>



From prasanta.sadhukhan at oracle.com  Tue Jun 20 05:06:03 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 20 Jun 2017 10:36:03 +0530
Subject: <Swing Dev> [10] RFR JDK-8075063:Context menu closes on mouse
 scroll
In-Reply-To: <69267B5A-794D-439B-A9CE-8153C7C05013@oracle.com>
References: <8c997c2e-bf01-7957-22fa-43ac18e9ca88@oracle.com>
 <be992d75-65cb-8c55-f3e6-d3685f5fa0e0@oracle.com>
 <9c06120b-c8c0-6ee2-048b-5626f9bea344@oracle.com>
 <04fa0a6c-6302-64f9-e6c7-f5342acab758@oracle.com>
 <6f4d381f-1be5-7bca-6a7e-a17d621c85b1@oracle.com>
 <17c5c10e-d0ad-c278-a9ab-038192b34fc6@oracle.com>
 <0a7b852c-4c78-81ca-b2f6-ba1bb69736af@oracle.com>
 <f5914b14-e791-5a9a-2ad5-56a172719488@oracle.com>
 <924dd4d2-44bd-480c-72e1-193c9761c6fc@oracle.com>
 <b9fd5984-a571-150d-8162-a23876b55976@oracle.com>
 <97d37ed7-6f79-b940-29e6-d982645cb844@oracle.com>
 <69267B5A-794D-439B-A9CE-8153C7C05013@oracle.com>
Message-ID: <a0e3aeec-6d59-616c-a970-617fc5b7b9f4@oracle.com>

I also thought about it and thought of removing cancelPopupMenu 
altogether first but decided not to remove it and added this conditions 
(in case there are some conditions which we are not thinking of)

((src instanceof JWindow) && ((JWindow)src).isVisible())
                     || ((src instanceof JMenuItem) && 
((JMenuItem)src).isVisible())
                     || (src instanceof JFrame))

I am not sure in which case it should execute cancelPopupMenu in mouse 
-wheel events. If you want, I can remove this "case".

Regards
Prasanta
On 6/19/2017 7:59 PM, Sergey Bylokhov wrote:
> The fix added a number of checks to exclude execution of ?cancelPopupMenu? on MOUSE_WHEEL, so I wonder in which situations we should execute cancelPopupMenu?
>
>> Fair enough suggestion, modified webrev to never ungrab for wheel event
>>
>> http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.02/
>>
>> Regards
>> Prasanta
>> On 6/16/2017 9:37 PM, Semyon Sadetsky wrote:
>>> They are related to a wheel event happend in another java window (not outside the app).
>>> My questions is if we do not ungrab on wheel event outside the app should we be consistent and do never ungrab on wheel event?
>>>
>>> --Semyon
>>>
>>>
>>> On 06/16/2017 08:49 AM, Prasanta Sadhukhan wrote:
>>>> I was not sure about the scenario at what condition those ungrabs are sent, so I did not modify those. For wheel event outside our java window was the scenario here and my modification fixed that.
>>>>
>>>> // According to the specification of UngrabEvent, post it
>>>>    // when press occurs outside of the window and not on its owned windows
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 6/16/2017 8:57 PM, Semyon Sadetsky wrote:
>>>>> In lines 2337 and 2345 ungrab is also sent. Shouldn't the button number be checked there as well before ungrab?
>>>>>
>>>>> --Semyon
>>>>>
>>>>>
>>>>> On 06/16/2017 03:22 AM, Prasanta Sadhukhan wrote:
>>>>>> Yes, it is failing in linux as it posts a UngrabEvent which causes the popup to be closed in BasicPopupMenuUI at eventDispatched()
>>>>>>
>>>>>> if(ev instanceof sun.awt.UngrabEvent) {
>>>>>>                 // Popup should be canceled in case of ungrab event
>>>>>>                 cancelPopupMenu( );
>>>>>>                 return;
>>>>>>             }
>>>>>> I have modified to not post the ungrab event if mouse wheel is rotated by checking if button 4 or 5 is pressed or not.
>>>>>> as per https://stackoverflow.com/questions/15510472/scrollwheel-event-in-x11
>>>>>> and
>>>>>> ftp://www.x.org/pub/X11R6.8.0/doc/mouse.4.html [Wheel button events (typically buttons 4 and 5) are usually used for scrolling]
>>>>>>
>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.01/
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 6/15/2017 8:55 PM, Semyon Sadetsky wrote:
>>>>>>> On 06/15/2017 08:18 AM, Prasanta Sadhukhan wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On 6/15/2017 8:40 PM, Semyon Sadetsky wrote:
>>>>>>>>> On 06/14/2017 09:54 PM, Prasanta Sadhukhan wrote:
>>>>>>>>>> Hi Semyon,
>>>>>>>>>>
>>>>>>>>>> I tried on Firefox and other app. If popup or drop down menu is opened, then mouse wheel rotation is not closing the popups. In our case, it is closing the popups/menus.
>>>>>>>>> That is true. I meant you fixed only the case when the mouse wheel rotation is over java windows (wheel event's source != null). What will be if the wheel is rotated outside java (source == null), or it is not the case?
>>>>>>>>>
>>>>>>>> It is not closing in other app (if it rotated over non-app window) as well as in our java with my fix.
>>>>>>> Did you check this on all platforms? At least on my Ubuntu it is not so.
>>>>>>>
>>>>>>> --Semyon
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>>> --Semyon
>>>>>>>>>> Regards
>>>>>>>>>> Prasanta
>>>>>>>>>> On 6/14/2017 8:26 PM, Semyon Sadetsky wrote:
>>>>>>>>>>> Hi Prasanta,
>>>>>>>>>>>
>>>>>>>>>>> I may be wrong, but it seems to me that the standard behavior is when any wheel event cannot close popups.
>>>>>>>>>>>
>>>>>>>>>>> --Semyon
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 06/13/2017 10:39 PM, Prasanta Sadhukhan wrote:
>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>
>>>>>>>>>>>> Please review a fix for an issue whereby it is seen
>>>>>>>>>>>> hitting the scroll wheel by accident closes whole structure of context menus causing it to disappear and the user has to invoke the menu again.
>>>>>>>>>>>>
>>>>>>>>>>>> Issue was popupMenu is getting closed for mouse wheel rotation if the menu is not from JComboBox.
>>>>>>>>>>>> If the context menu is opened from JMenuItem, JMenu then if the mouse wheel is rotated anywhere in frame, then it calls cancelPopupMenu() causing it to call setVisible(false) and so menu disappears.
>>>>>>>>>>>>
>>>>>>>>>>>> Proposed fix is to check if the mouse wheel rotation is done in JMenu, JMenuItem or anywhere in frame, then if popup is present, then do not close the popupmenu.
>>>>>>>>>>>>
>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075063
>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.00/
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Prasanta
>>>>>>>>>>>>



From prasanta.sadhukhan at oracle.com  Tue Jun 20 08:00:41 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 20 Jun 2017 13:30:41 +0530
Subject: <Swing Dev> [10] RFR: JDK-8075918:The regression-swing case
 failed as the long Tab titles are not clipped with dots at the end with
 NimbusLookAndFeel
In-Reply-To: <50FCC80B-1D8A-4701-82CB-03BBBE2FC519@oracle.com>
References: <a4a1ae6b-2d1c-4d99-abcf-e2a3cd24659d@default>
 <27bb815b-ba6c-0b06-7cc2-a84fc38d8b57@oracle.com>
 <A6A5EB65-4E18-47AB-8E1A-73B7FECDFB85@oracle.com>
 <7b5d79ce-3f1b-d7be-486b-e836bf3a5862@oracle.com>
 <34003A0F-6EE2-42B6-A920-404769399E38@oracle.com>
 <be81fbcf-155b-5e9c-c40c-e9cf8a15447e@oracle.com>
 <066deef0-4b60-d430-2f25-2aa699eb0c57@oracle.com>
 <50FCC80B-1D8A-4701-82CB-03BBBE2FC519@oracle.com>
Message-ID: <d86e2a2b-d503-3185-34d1-2950ce15aea8@oracle.com>

So far I have checked, it is always sun.awt.SunGraphics2D instance. If 
there is no more objection, I would proceed to commit this.

Regards
Prasanta
On 6/19/2017 8:38 PM, Sergey Bylokhov wrote:
> I am only not sure about type casting w/o instanceof, if we always 
> have Graphics2D then this fix looks fine.
>
>> Hi Sergey,
>>
>> Is anything more needed to be done for this? I guess I have modified 
>> as per the review comment.
>>
>> Regards
>> Prasanta
>> On 6/9/2017 11:33 AM, Prasanta Sadhukhan wrote:
>>>
>>> Ok. Rectified. Please find the modified webrev with clip at correct 
>>> place(s)
>>>
>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.05/
>>>
>>> Regards
>>> Prasanta
>>> On 6/8/2017 9:34 PM, Sergey Bylokhov wrote:
>>>> I have referenced these methods:
>>>>
>>>> "BasicTabbedPaneUI.paintIcon() as well as 
>>>> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>>>> ?- paintText() at line 681
>>>> ?- paintIcon() at line 634
>>>> Both methods have a rectangle as a parameter, but it is ignored."
>>>> The first is in the BasicTabbedPaneUI.java and the second is in the 
>>>> SynthGraphicsUtils.java
>>>>
>>>>>
>>>>> Why? clip is invoked in SynthTabbedPaneUI#paintText() at line 687 
>>>>> and SynthTabbedPaneUI#paintTab() at line 637, where you asked for, 
>>>>> I guess.
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 6/8/2017 12:59 PM, Sergey Bylokhov wrote:
>>>>>> But in this version the clip operation still not executed in 
>>>>>> methods mentioned here:
>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2017-June/007419.html
>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2017-May/007406.html
>>>>>>
>>>>>>>
>>>>>>> Please find the modified webrev incorporating your review comment
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.04/ 
>>>>>>> <http://cr.openjdk.java.net/%7Epsadhukhan/8075918/webrev.04/>
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 6/2/2017 12:33 AM, Sergey Bylokhov wrote:
>>>>>>>> ?- There is a problem in your algorithm which merges the old 
>>>>>>>> and new clips. The getClipBounds() returns a rectangle which is 
>>>>>>>> a bounds of the current clip(which is not necessary a rectangle 
>>>>>>>> but can be a shape). you can use the Graphics2D.clip(Shape) 
>>>>>>>> method which will intersect the passed shape and a current clip 
>>>>>>>> of the graphics.
>>>>>>>> ?- In this version you forgot to restore the changed clip.
>>>>>>>> ?- Also can you try to move the code which change a clip to the 
>>>>>>>> methods which currently ignore the passed clip(see below):
>>>>>>>>>>> BasicTabbedPaneUI.paintIcon() as well as
>>>>>>>>>>> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>>>>>>>>>>> ??- paintText() at line 681
>>>>>>>>>>> ??- paintIcon() at line 634
>>>>>>>>>>> Both methods have a rectangle as a parameter, but it is ignored.
>>>>>>>>
>>>>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>>>>
>>>>>>>>> I tried to incorporate your comments. Please find modified webrev
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.03/
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>> On 5/28/2017 8:01 AM, Sergey Bylokhov wrote:
>>>>>>>>>> Note that you shouldn't replace the clip, but should apply 
>>>>>>>>>> the new
>>>>>>>>> clip on top of the old. This is necessary if the old clip is 
>>>>>>>>> smaller
>>>>>>>>> than new.
>>>>>>>>>> ----- sergey.bylokhov at oracle.com wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi, Prasanta.
>>>>>>>>>>>
>>>>>>>>>>> BasicTabbedPaneUI.paintIcon() as well as
>>>>>>>>>>> SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI.
>>>>>>>>>>> ??- paintText() at line 681
>>>>>>>>>>> ??- paintIcon() at line 634
>>>>>>>>>>> Both methods have a rectangle as a parameter, but it is ignored.
>>>>>>>>>>>
>>>>>>>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Sergey,
>>>>>>>>>>>>
>>>>>>>>>>>> I could get your concern for paintText() but could not find
>>>>>>>>>>>> paintIcon()
>>>>>>>>>>>> in SynthGraphicsUtils() so not sure how icon drawing 
>>>>>>>>>>>> contradicts
>>>>>>>>>>>> spec.
>>>>>>>>>>>> Modified webrev:
>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/
>>>>>>>>>>>>
>>>>>>>>>>>> Also, if we are not calling
>>>>>>>>> SwingUtilities2.clipStringIfNecessary()
>>>>>>>>>>>> then
>>>>>>>>>>>> we are not going to get "..." at the end which this test 
>>>>>>>>>>>> expects.
>>>>>>>>>>> But
>>>>>>>>>>>> I
>>>>>>>>>>>> could not find anything in spec, that mandates ending with 
>>>>>>>>>>>> "..."
>>>>>>>>> for
>>>>>>>>>>>> long tab outside
>>>>>>>>>>>> tab bounds. If source change is ok, I guess we then need to
>>>>>>>>> modify
>>>>>>>>>>> the
>>>>>>>>>>>> html file modifying the expected result for NimbusL&F.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Prasanta
>>>>>>>>>>>> On 5/25/2017 3:11 AM, Sergey Bylokhov wrote:
>>>>>>>>>>>>> Hi, Prasanta.
>>>>>>>>>>>>> Please take a look to my comments at:
>>>>>>>>>>>>>
>>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html
>>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html
>>>>>>>>>>>>> The two methods paintText() and paintIcon() are contradict the
>>>>>>>>>>> spec
>>>>>>>>>>>> and draw the text and icons outside of the tab.
>>>>>>>>>>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please review a fix for an issue where long Tab titiles 
>>>>>>>>>>>>>> are not
>>>>>>>>>>>>>> clipped
>>>>>>>>>>>>>> with dots at end for NimbusLookAndFeel L&F.
>>>>>>>>>>>>>> Other L&Fs works ok.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Issue was in SynthTabbedPaneUI#paintTab(), the title is not
>>>>>>>>>>>> clipped
>>>>>>>>>>>>>> but
>>>>>>>>>>>>>> passed to paintText() as it is received.
>>>>>>>>>>>>>> Other L&F such as Metal, Motif, Windows which uses
>>>>>>>>>>>>>> BasicTabbedPaneUI#paintTab(), the title is clipped
>>>>>>>>>>>>>>
>>>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950
>>>>>>>>>>>>>> before it is passed to paintText().
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Proposed fix is to do the same for
>>>>>>>>> SynthTabbedPaneUI#paintTab().
>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075918
>>>>>>>>>>>>>> webrev:
>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/
>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>> Prasanta
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From prasanta.sadhukhan at oracle.com  Tue Jun 20 10:16:28 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 20 Jun 2017 15:46:28 +0530
Subject: <Swing Dev> [10] RFR: JDK-8043315: Nimbus: Setting
 Nimbus.Overrides property affects custom keymap installation
In-Reply-To: <FF30652A-0A02-4BA9-A491-0A7CEC58F498@oracle.com>
References: <54afabea-f351-4fd5-860a-29bd293b2c6d@default>
 <8af41cf8-f51a-6322-9664-6d45fc640a80@oracle.com>
 <FF30652A-0A02-4BA9-A491-0A7CEC58F498@oracle.com>
Message-ID: <4ebae06f-55e4-387c-6453-57c25a140fa3@oracle.com>

Yes, it fails for SynthTextAreaUI/SynthTextFieldUI so change applied to 
those files too. Since the test is in nimbus folder, I went for throwing 
an exception if Nimbus cannot be set.

http://cr.openjdk.java.net/~psadhukhan/8043315/webrev.03/

Regards
Prasanta
On 6/19/2017 8:32 PM, Sergey Bylokhov wrote:
>> I have modified webrev to remove static keyword and made the test automated
> Should the same change be applied to SynthTextAreaUI/SynthTextFieldUI?
> In the test you should throw an exception if Nimbus cannot be set, or you can iterate over all installed l&f.
>
>> http://cr.openjdk.java.net/~psadhukhan/8043315/webrev.01/
>> Updated fix tests if app has fired a property change by calling setKeymap() then it will not uninstall custom keymap and let the custom keymap be honoured. If app again calls setKeymap(null) then the static variable will be "true" and it will reset back to default keymap.
>>
>> Regards
>> Prasanta
>> On 6/2/2017 12:07 AM, Sergey Bylokhov wrote:
>>> Hi, Prasanta.
>>> Can you please clarify the fix a little bit.
>>> You have a static variable, which is set to "false" when the listener for "keymap" is triggered, and it seems that you never set it back to "true"? Is it intentional behavior?
>>> Note that if there are a few objects of "SynthEditorPaneUI" then they will share this static field. Also it seems that the test can be automated, because currently it is requires from the user to press only one button("space").
>>>
>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>
>>>> Hi All,
>>>>
>>>> Please review a bug fix for Nimbus L&F where if app sets custom keymap
>>>>
>>>> and then sets Nimbus.Overrides property,
>>>> then the custom keymap is not honoured.
>>>> For example, if testapp sets a new action for "space" key press and
>>>> sets
>>>> sets Nimbus.Overrides property,
>>>>    it will not be honoured and default action ie. inserting a "space"
>>>> character will be done.
>>>>
>>>> Issue was NimbusLookAndFeel#shouldUpdateStyleOnEvent() returns true
>>>> for
>>>> Nimbus.Override property which causes SynthEditorPaneUI#updateStyle()
>>>> to
>>>> be called which
>>>> uninstall set keyboard actions and sets up default keyboard action.
>>>>
>>>> Proposed fix is to check if a keymap is already set (a propertyChange
>>>>
>>>> event will be fired for when app calls setKeyMap()) then do not reset
>>>> to
>>>> default keymap.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8043315
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8043315/webrev.00/
>>>>
>>>> Regards
>>>> Prasanta



From prasanta.sadhukhan at oracle.com  Tue Jun 20 17:21:12 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 20 Jun 2017 22:51:12 +0530
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus to a
 JCheckbox with a custom ButtonModel
Message-ID: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>

Hi All,

Please review a fix for an issue where a crash is reported when focus is 
moved with custom ButtonModel.
Issue was in LayoutFocusTraversalPolicy, the ButtonModel was wrongly 
typecasted to JToggleButton when the button model is DefaultButtonModel, 
resulting in ClassCastException.

Proposed fix is to cast to super class DefaultButtonModel and then check 
for JToggleButton member.

Bug: https://bugs.openjdk.java.net/browse/JDK-8182577
webrev: http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.00/

Regards
Prasanta


From semyon.sadetsky at oracle.com  Tue Jun 20 17:46:53 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 20 Jun 2017 10:46:53 -0700
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>
References: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>
Message-ID: <f27d0da1-72c1-7903-c5bb-302e4c9a64af@oracle.com>

Hi Prasanta,

With the DefaultButtonModel we can get the same exception if a custom 
implementation of the ButtonModel is used.

So, it is better check whether  the model is a DefaultButtonModel and 
skip if grouping is not supported. Or, perhaps, it is reasonable to pull 
up the getGroup() into the ButtonModel interface which already has 
setGroup().

--Semyon


On 06/20/2017 10:21 AM, Prasanta Sadhukhan wrote:
> Hi All,
>
> Please review a fix for an issue where a crash is reported when focus 
> is moved with custom ButtonModel.
> Issue was in LayoutFocusTraversalPolicy, the ButtonModel was wrongly 
> typecasted to JToggleButton when the button model is 
> DefaultButtonModel, resulting in ClassCastException.
>
> Proposed fix is to cast to super class DefaultButtonModel and then 
> check for JToggleButton member.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8182577
> webrev: http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.00/
>
> Regards
> Prasanta



From prasanta.sadhukhan at oracle.com  Wed Jun 21 05:36:27 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 21 Jun 2017 11:06:27 +0530
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <f27d0da1-72c1-7903-c5bb-302e4c9a64af@oracle.com>
References: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>
 <f27d0da1-72c1-7903-c5bb-302e4c9a64af@oracle.com>
Message-ID: <c5d59af0-bf79-5e1c-2d78-8264551e6a77@oracle.com>

Hi Semyon,

Yes, it seems the problem will be there in that case. Modified to have 
getGroup() in the interface
http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.01/

Regards
Prasanta
On 6/20/2017 11:16 PM, Semyon Sadetsky wrote:
> Hi Prasanta,
>
> With the DefaultButtonModel we can get the same exception if a custom 
> implementation of the ButtonModel is used.
>
> So, it is better check whether  the model is a DefaultButtonModel and 
> skip if grouping is not supported. Or, perhaps, it is reasonable to 
> pull up the getGroup() into the ButtonModel interface which already 
> has setGroup().
>
> --Semyon
>
>
> On 06/20/2017 10:21 AM, Prasanta Sadhukhan wrote:
>> Hi All,
>>
>> Please review a fix for an issue where a crash is reported when focus 
>> is moved with custom ButtonModel.
>> Issue was in LayoutFocusTraversalPolicy, the ButtonModel was wrongly 
>> typecasted to JToggleButton when the button model is 
>> DefaultButtonModel, resulting in ClassCastException.
>>
>> Proposed fix is to cast to super class DefaultButtonModel and then 
>> check for JToggleButton member.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8182577
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.00/
>>
>> Regards
>> Prasanta
>



From prasanta.sadhukhan at oracle.com  Wed Jun 21 08:43:55 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 21 Jun 2017 14:13:55 +0530
Subject: <Swing Dev> [10] RFR JDK-8182402:Tooltip for Desktop button is in
 English when non-English locale is set
Message-ID: <f4419133-0aa0-0b99-c733-a1586cd04533@oracle.com>

Hi All,

Please review a fix for an issue where tooltip for "Home" or Desktop 
button is in English even though locale is non-English.
This is because even though i18n properties has

FileChooser.homeFolderToolTip.textAndMnemonic=Home

in English, Dutch,chinese etc
./share/classes/com/sun/java/swing/plaf/windows/resources/windows.properties
share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties

in MetalFileChooserUI.java and SynthFileChooserUIImpl.java, it is 
replaced by "Desktop" text which do not have corresponding i18N resources.
There is a corresponding bug JDK-8179346 
<https://bugs.openjdk.java.net/browse/JDK-8179346> which says pressing 
"home" button should not go to Desktop so probably desktop is not 
correct name for home folder.

Proposed fix is to use "Home" tooltip text so that it can be displayed 
in different locale.

Bug: https://bugs.openjdk.java.net/browse/JDK-8182402
webrev: http://cr.openjdk.java.net/~psadhukhan/8182402/webrev.00/

Regards
Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170621/5220dbd7/attachment.html>

From prasanta.sadhukhan at oracle.com  Wed Jun 21 08:51:47 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 21 Jun 2017 14:21:47 +0530
Subject: <Swing Dev> [10] RFR JDK-8181421: 3 regtest fail on windows7 in
 Nimbus L&F
In-Reply-To: <A7815852-ED9D-4546-A805-1C8E32B8D858@oracle.com>
References: <7194c05f-f147-4df8-8947-7053a3d1d60b@default>
 <0b293f12-e1ad-f439-00e7-e3811e3275c4@oracle.com>
 <A7815852-ED9D-4546-A805-1C8E32B8D858@oracle.com>
Message-ID: <ce06157a-d897-4449-f342-9b50f046fb36@oracle.com>

I am withdrawing this RFR as it seems even without code change, the 
tests are passing once converted to main based and also it was causing a 
regression in one of the issue I was investigating.

--Prasanta
On 6/19/2017 8:04 PM, Sergey Bylokhov wrote:
>
>> private void updateStyle(JPanel c) {
>>         SynthContext context = getContext(c, ENABLED);
>>         style = SynthLookAndFeel.updateStyle(context, this);
>>     }
>> it calls getContext() which in turn calls SynthContext.getContext() 
>> with style variable.
>> private SynthContext getContext(JComponent c, int state) {
>>         return SynthContext.getContext(c, style, state);
>>     }
>> Now, "style"  variable seems to be null at this point in 
>> SYnthPanelUI.java and
>> it only gets updated after getContext() call when it calls then next 
>> line SynthLookAndFeel.updateStyle(context, this);
>
> And the question why it is null here in these test cases, but correct 
> value in others tests.
>
>>
>> I could not remove the html file as I am getting some serialization 
>> issue if I moved from applet to main based so I retained applet based 
>> test, as of now. Also, due to it being applet, I am not sure how to 
>> run them over installed l&f inside the test.
>
> I see that in the latest version you remove html files, and now you 
> can iterate over all installed l&f.
>
>>
>> Modified webrev with test issues rectfied
>> http://cr.openjdk.java.net/~psadhukhan/8181421/webrev.01/
>>
>> Regards
>> Prasanta
>> On 6/2/2017 1:35 AM, Sergey Bylokhov wrote:
>>> Hi, Prasanta.
>>> I have few small notes.
>>>  - Did you check why the null value was passed to this method?
>>>  - It seems that the tests are passed by default. It would be good 
>>> to run them over the installed l&f. In this case they will fail 
>>> before the fix.
>>>  - Is it possible to remove the html files from the tests?
>>>  - The tests also have some common issues, the Swing components are 
>>> accessed on non-edt thread. some unnecessary commented code, etc.
>>>
>>> -----prasanta.sadhukhan at oracle.comwrote:
>>> >
>>> Hi All,
>>> Please review a subitem fix ofJDK-7190554 
>>> <https://bugs.openjdk.java.net/browse/JDK-7190554>where some closed 
>>> regression test is failing with Nimbus L&F.
>>> Issue was we were getting NPE
>>> > which is because a null style was used in SynthPanelUI to generate 
>>> the SynthContext
>>> >
>>> > java.lang.NullPointerException: You must supply a non-null 
>>> component, region and style
>>> >     at 
>>> java.desktop/javax.swing.plaf.synth.SynthContext.getContext(SynthContext.java:58)
>>> >     at 
>>> java.desktop/javax.swing.plaf.synth.SynthContext.getContext(SynthContext.java:49)
>>> >     at 
>>> java.desktop/javax.swing.plaf.synth.SynthPanelUI.getContext(SynthPanelUI.java:128)
>>> >     at 
>>> java.desktop/javax.swing.plaf.synth.SynthPanelUI.updateStyle(SynthPanelUI.java:115)
>>> >     at 
>>> java.desktop/javax.swing.plaf.synth.SynthPanelUI.installDefaults(SynthPanelUI.java:100)
>>> >
>>> > Proposed fix is to generate a style before generating SynthContext 
>>> because as per spec,
>>> >https://docs.oracle.com/javase/8/docs/api/index.html?javax/swing/plaf/synth/SynthContext.html
>>> > it should throw NPE||- if component, region or style is null.
>>> >
>>> > Bug:https://bugs.openjdk.java.net/browse/JDK-8181421
>>> > webrev:http://cr.openjdk.java.net/~psadhukhan/8181421/webrev.00/
>>> >
>>> > Regards
>>> > Prasanta
>>> >
>>
>>
>

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

From prasanta.sadhukhan at oracle.com  Wed Jun 21 11:03:04 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 21 Jun 2017 16:33:04 +0530
Subject: <Swing Dev> [10] RFR JDK-8075063:Context menu closes on mouse
 scroll
In-Reply-To: <a0e3aeec-6d59-616c-a970-617fc5b7b9f4@oracle.com>
References: <8c997c2e-bf01-7957-22fa-43ac18e9ca88@oracle.com>
 <be992d75-65cb-8c55-f3e6-d3685f5fa0e0@oracle.com>
 <9c06120b-c8c0-6ee2-048b-5626f9bea344@oracle.com>
 <04fa0a6c-6302-64f9-e6c7-f5342acab758@oracle.com>
 <6f4d381f-1be5-7bca-6a7e-a17d621c85b1@oracle.com>
 <17c5c10e-d0ad-c278-a9ab-038192b34fc6@oracle.com>
 <0a7b852c-4c78-81ca-b2f6-ba1bb69736af@oracle.com>
 <f5914b14-e791-5a9a-2ad5-56a172719488@oracle.com>
 <924dd4d2-44bd-480c-72e1-193c9761c6fc@oracle.com>
 <b9fd5984-a571-150d-8162-a23876b55976@oracle.com>
 <97d37ed7-6f79-b940-29e6-d982645cb844@oracle.com>
 <69267B5A-794D-439B-A9CE-8153C7C05013@oracle.com>
 <a0e3aeec-6d59-616c-a970-617fc5b7b9f4@oracle.com>
Message-ID: <51b8f7f1-f0bb-fb73-b894-b4aa61c98b23@oracle.com>



On 6/20/2017 10:36 AM, Prasanta Sadhukhan wrote:
> I also thought about it and thought of removing cancelPopupMenu 
> altogether first but decided not to remove it and added this 
> conditions (in case there are some conditions which we are not 
> thinking of)
>
> ((src instanceof JWindow) && ((JWindow)src).isVisible())
>                     || ((src instanceof JMenuItem) && 
> ((JMenuItem)src).isVisible())
>                     || (src instanceof JFrame))
>
> I am not sure in which case it should execute cancelPopupMenu in mouse 
> -wheel events. If you want, I can remove this "case".
>
It seems if (c instanceof Applet || c instanceof Window) [although not 
Popup#HeavyWeightWindow which is a JWindow] then cancelPopMenu will be 
executed.
> Regards
> Prasanta
> On 6/19/2017 7:59 PM, Sergey Bylokhov wrote:
>> The fix added a number of checks to exclude execution of 
>> ?cancelPopupMenu? on MOUSE_WHEEL, so I wonder in which situations we 
>> should execute cancelPopupMenu?
>>
>>> Fair enough suggestion, modified webrev to never ungrab for wheel event
>>>
>>> http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.02/
>>>
>>> Regards
>>> Prasanta
>>> On 6/16/2017 9:37 PM, Semyon Sadetsky wrote:
>>>> They are related to a wheel event happend in another java window 
>>>> (not outside the app).
>>>> My questions is if we do not ungrab on wheel event outside the app 
>>>> should we be consistent and do never ungrab on wheel event?
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 06/16/2017 08:49 AM, Prasanta Sadhukhan wrote:
>>>>> I was not sure about the scenario at what condition those ungrabs 
>>>>> are sent, so I did not modify those. For wheel event outside our 
>>>>> java window was the scenario here and my modification fixed that.
>>>>>
>>>>> // According to the specification of UngrabEvent, post it
>>>>>    // when press occurs outside of the window and not on its owned 
>>>>> windows
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 6/16/2017 8:57 PM, Semyon Sadetsky wrote:
>>>>>> In lines 2337 and 2345 ungrab is also sent. Shouldn't the button 
>>>>>> number be checked there as well before ungrab?
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>>
>>>>>> On 06/16/2017 03:22 AM, Prasanta Sadhukhan wrote:
>>>>>>> Yes, it is failing in linux as it posts a UngrabEvent which 
>>>>>>> causes the popup to be closed in BasicPopupMenuUI at eventDispatched()
>>>>>>>
>>>>>>> if(ev instanceof sun.awt.UngrabEvent) {
>>>>>>>                 // Popup should be canceled in case of ungrab event
>>>>>>>                 cancelPopupMenu( );
>>>>>>>                 return;
>>>>>>>             }
>>>>>>> I have modified to not post the ungrab event if mouse wheel is 
>>>>>>> rotated by checking if button 4 or 5 is pressed or not.
>>>>>>> as per 
>>>>>>> https://stackoverflow.com/questions/15510472/scrollwheel-event-in-x11 
>>>>>>>
>>>>>>> and
>>>>>>> ftp://www.x.org/pub/X11R6.8.0/doc/mouse.4.html [Wheel button 
>>>>>>> events (typically buttons 4 and 5) are usually used for scrolling]
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.01/
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 6/15/2017 8:55 PM, Semyon Sadetsky wrote:
>>>>>>>> On 06/15/2017 08:18 AM, Prasanta Sadhukhan wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 6/15/2017 8:40 PM, Semyon Sadetsky wrote:
>>>>>>>>>> On 06/14/2017 09:54 PM, Prasanta Sadhukhan wrote:
>>>>>>>>>>> Hi Semyon,
>>>>>>>>>>>
>>>>>>>>>>> I tried on Firefox and other app. If popup or drop down menu 
>>>>>>>>>>> is opened, then mouse wheel rotation is not closing the 
>>>>>>>>>>> popups. In our case, it is closing the popups/menus.
>>>>>>>>>> That is true. I meant you fixed only the case when the mouse 
>>>>>>>>>> wheel rotation is over java windows (wheel event's source != 
>>>>>>>>>> null). What will be if the wheel is rotated outside java 
>>>>>>>>>> (source == null), or it is not the case?
>>>>>>>>>>
>>>>>>>>> It is not closing in other app (if it rotated over non-app 
>>>>>>>>> window) as well as in our java with my fix.
>>>>>>>> Did you check this on all platforms? At least on my Ubuntu it 
>>>>>>>> is not so.
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>>> --Semyon
>>>>>>>>>>> Regards
>>>>>>>>>>> Prasanta
>>>>>>>>>>> On 6/14/2017 8:26 PM, Semyon Sadetsky wrote:
>>>>>>>>>>>> Hi Prasanta,
>>>>>>>>>>>>
>>>>>>>>>>>> I may be wrong, but it seems to me that the standard 
>>>>>>>>>>>> behavior is when any wheel event cannot close popups.
>>>>>>>>>>>>
>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 06/13/2017 10:39 PM, Prasanta Sadhukhan wrote:
>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please review a fix for an issue whereby it is seen
>>>>>>>>>>>>> hitting the scroll wheel by accident closes whole 
>>>>>>>>>>>>> structure of context menus causing it to disappear and the 
>>>>>>>>>>>>> user has to invoke the menu again.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Issue was popupMenu is getting closed for mouse wheel 
>>>>>>>>>>>>> rotation if the menu is not from JComboBox.
>>>>>>>>>>>>> If the context menu is opened from JMenuItem, JMenu then 
>>>>>>>>>>>>> if the mouse wheel is rotated anywhere in frame, then it 
>>>>>>>>>>>>> calls cancelPopupMenu() causing it to call 
>>>>>>>>>>>>> setVisible(false) and so menu disappears.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Proposed fix is to check if the mouse wheel rotation is 
>>>>>>>>>>>>> done in JMenu, JMenuItem or anywhere in frame, then if 
>>>>>>>>>>>>> popup is present, then do not close the popupmenu.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075063
>>>>>>>>>>>>> webrev: 
>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.00/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>> Prasanta
>>>>>>>>>>>>>
>



From sergey.bylokhov at oracle.com  Wed Jun 21 12:56:54 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 21 Jun 2017 05:56:54 -0700 (PDT)
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
Message-ID: <8648bf73-be86-46dc-a8d2-19406e2900e6@default>

Hi, Prasanta.
This can be a good fix for jdk10, but since it is a regression in jdk9 we should try to backport the fix jdk10->jdk9. Note that we cannot introduce the new method in jdk9.

----- prasanta.sadhukhan at oracle.com wrote:

> Hi Semyon,
> 
> Yes, it seems the problem will be there in that case. Modified to have
> 
> getGroup() in the interface
> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.01/
> 
> Regards
> Prasanta
> On 6/20/2017 11:16 PM, Semyon Sadetsky wrote:
> > Hi Prasanta,
> >
> > With the DefaultButtonModel we can get the same exception if a
> custom 
> > implementation of the ButtonModel is used.
> >
> > So, it is better check whether  the model is a DefaultButtonModel
> and 
> > skip if grouping is not supported. Or, perhaps, it is reasonable to
> 
> > pull up the getGroup() into the ButtonModel interface which already
> 
> > has setGroup().
> >
> > --Semyon
> >
> >
> > On 06/20/2017 10:21 AM, Prasanta Sadhukhan wrote:
> >> Hi All,
> >>
> >> Please review a fix for an issue where a crash is reported when
> focus 
> >> is moved with custom ButtonModel.
> >> Issue was in LayoutFocusTraversalPolicy, the ButtonModel was
> wrongly 
> >> typecasted to JToggleButton when the button model is 
> >> DefaultButtonModel, resulting in ClassCastException.
> >>
> >> Proposed fix is to cast to super class DefaultButtonModel and then
> 
> >> check for JToggleButton member.
> >>
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8182577
> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.00/
> >>
> >> Regards
> >> Prasanta
> >


From sergey.bylokhov at oracle.com  Wed Jun 21 13:10:00 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 21 Jun 2017 06:10:00 -0700 (PDT)
Subject: <Swing Dev> [10] RFR: JDK-8075918:The regression-swing case
 failed as the long Tab titles are not clipped with dots at the end with
 NimbusLookAndFeel
Message-ID: <af045af5-1e93-4209-a412-f7ff7eef372f@default>

ok. 

----- prasanta.sadhukhan at oracle.com wrote: 
> 


So far I have checked, it is always sun.awt.SunGraphics2D instance. If there is no more objection, I would proceed to commit this. 
> Regards 
> Prasanta 
> 
> On 6/19/2017 8:38 PM, Sergey Bylokhov wrote: 
> 

I am only not sure about type casting w/o instanceof, if we always have Graphics2D then this fix looks fine. 
> 




> 
> 

Hi Sergey, 
Is anything more needed to be done for this? I guess I have modified as per the review comment. 

Regards 
Prasanta 

> On 6/9/2017 11:33 AM, Prasanta Sadhukhan wrote: 




Ok. Rectified. Please find the modified webrev with clip at correct place(s) 
http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.05/ 

Regards 
Prasanta 

> On 6/8/2017 9:34 PM, Sergey Bylokhov wrote: 


I have referenced these methods: 
> 

> "BasicTabbedPaneUI.paintIcon() as well as SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI. 
> ?- paintText() at line 681 
> ?- paintIcon() at line 634 
> Both methods have a rectangle as a parameter, but it is ignored." 
> The first is in the BasicTabbedPaneUI.java and the second is in the SynthGraphicsUtils.java 
> 

> 



> 
> 

Why? clip is invoked in SynthTabbedPaneUI#paintText() at line 687 and SynthTabbedPaneUI#paintTab() at line 637, where you asked for, I guess. 
Regards 
Prasanta 

> On 6/8/2017 12:59 PM, Sergey Bylokhov wrote: 


But in this version the clip operation still not executed in methods mentioned here: 
> http://mail.openjdk.java.net/pipermail/swing-dev/2017-June/007419.html 
> http://mail.openjdk.java.net/pipermail/swing-dev/2017-May/007406.html 
> 

> 



> 
> Please find the modified webrev incorporating your review comment 

http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.04/ 

Regards 
Prasanta 
On 6/2/2017 12:33 AM, Sergey Bylokhov wrote: 


?- There is a problem in your algorithm which merges the old and new clips. The getClipBounds() returns a rectangle which is a bounds of the current clip(which is not necessary a rectangle but can be a shape). you can use the Graphics2D.clip(Shape) method which will intersect the passed shape and a current clip of the graphics. 
?- In this version you forgot to restore the changed clip. 
?- Also can you try to move the code which change a clip to the methods which currently ignore the passed clip(see below): 






BasicTabbedPaneUI.paintIcon() as well as 
SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI. 
??- paintText() at line 681 
??- paintIcon() at line 634 
Both methods have a rectangle as a parameter, but it is ignored. 

----- prasanta.sadhukhan at oracle.com wrote: 



I tried to incorporate your comments. Please find modified webrev 

http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.03/ 

Regards 
Prasanta 
On 5/28/2017 8:01 AM, Sergey Bylokhov wrote: 


Note that you shouldn't replace the clip, but should apply the new 
clip on top of the old. This is necessary if the old clip is smaller 
than new. 


----- sergey.bylokhov at oracle.com wrote: 



Hi, Prasanta. 

BasicTabbedPaneUI.paintIcon() as well as 
SynthGraphicsUtils.paintText() are called in SynthTabbedPaneUI. 
??- paintText() at line 681 
??- paintIcon() at line 634 
Both methods have a rectangle as a parameter, but it is ignored. 

----- prasanta.sadhukhan at oracle.com wrote: 



Hi Sergey, 

I could get your concern for paintText() but could not find 
paintIcon() 
in SynthGraphicsUtils() so not sure how icon drawing contradicts 
spec. 
Modified webrev: 
http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.01/ 

Also, if we are not calling 
SwingUtilities2.clipStringIfNecessary() 






then 
we are not going to get "..." at the end which this test expects. 
But 


I 
could not find anything in spec, that mandates ending with "..." 
for 






long tab outside 
tab bounds. If source change is ok, I guess we then need to 
modify 




the 


html file modifying the expected result for NimbusL&F. 

Regards 
Prasanta 
On 5/25/2017 3:11 AM, Sergey Bylokhov wrote: 


Hi, Prasanta. 
Please take a look to my comments at: 

http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006931.html 
http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006902.html 








The two methods paintText() and paintIcon() are contradict the 
spec 


and draw the text and icons outside of the tab. 


----- prasanta.sadhukhan at oracle.com wrote: 



Hi All, 

Please review a fix for an issue where long Tab titiles are not 
clipped 
with dots at end for NimbusLookAndFeel L&F. 
Other L&Fs works ok. 

Issue was in SynthTabbedPaneUI#paintTab(), the title is not 
clipped 




but 
passed to paintText() as it is received. 
Other L&F such as Metal, Motif, Windows which uses 
BasicTabbedPaneUI#paintTab(), the title is clipped 

http://hg.openjdk.java.net/jdk9/client/jdk/file/e748c6a2d2e6/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#l950 










before it is passed to paintText(). 

Proposed fix is to do the same for 
SynthTabbedPaneUI#paintTab(). 










Bug: https://bugs.openjdk.java.net/browse/JDK-8075918 
webrev: 
http://cr.openjdk.java.net/~psadhukhan/8075918/webrev.00/ 






Regards 
Prasanta 








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

From semyon.sadetsky at oracle.com  Wed Jun 21 14:15:13 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 21 Jun 2017 07:15:13 -0700
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <c5d59af0-bf79-5e1c-2d78-8264551e6a77@oracle.com>
References: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>
 <f27d0da1-72c1-7903-c5bb-302e4c9a64af@oracle.com>
 <c5d59af0-bf79-5e1c-2d78-8264551e6a77@oracle.com>
Message-ID: <5b9b2e34-cdd8-f8a9-ea14-ccb80b8f5925@oracle.com>

Hi Prasanta,

Ii is not necessary to cast to DefaultButtonModel after you add 
getGroup() to ButtonModel:

241                 ButtonModel model = 
((JToggleButton)aComponent).getModel();

--Semyon

On 06/20/2017 10:36 PM, Prasanta Sadhukhan wrote:
> Hi Semyon,
>
> Yes, it seems the problem will be there in that case. Modified to have 
> getGroup() in the interface
> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.01/
>
> Regards
> Prasanta
> On 6/20/2017 11:16 PM, Semyon Sadetsky wrote:
>> Hi Prasanta,
>>
>> With the DefaultButtonModel we can get the same exception if a custom 
>> implementation of the ButtonModel is used.
>>
>> So, it is better check whether  the model is a DefaultButtonModel and 
>> skip if grouping is not supported. Or, perhaps, it is reasonable to 
>> pull up the getGroup() into the ButtonModel interface which already 
>> has setGroup().
>>
>> --Semyon
>>
>>
>> On 06/20/2017 10:21 AM, Prasanta Sadhukhan wrote:
>>> Hi All,
>>>
>>> Please review a fix for an issue where a crash is reported when 
>>> focus is moved with custom ButtonModel.
>>> Issue was in LayoutFocusTraversalPolicy, the ButtonModel was wrongly 
>>> typecasted to JToggleButton when the button model is 
>>> DefaultButtonModel, resulting in ClassCastException.
>>>
>>> Proposed fix is to cast to super class DefaultButtonModel and then 
>>> check for JToggleButton member.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8182577
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.00/
>>>
>>> Regards
>>> Prasanta
>>
>



From prasanta.sadhukhan at oracle.com  Wed Jun 21 14:55:05 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 21 Jun 2017 20:25:05 +0530
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <5b9b2e34-cdd8-f8a9-ea14-ccb80b8f5925@oracle.com>
References: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>
 <f27d0da1-72c1-7903-c5bb-302e4c9a64af@oracle.com>
 <c5d59af0-bf79-5e1c-2d78-8264551e6a77@oracle.com>
 <5b9b2e34-cdd8-f8a9-ea14-ccb80b8f5925@oracle.com>
Message-ID: <66792efd-e60a-30d5-b5e5-87193e6c665d@oracle.com>

ok. Modified webrev:

http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.02/

Regards
Prasanta
On 6/21/2017 7:45 PM, Semyon Sadetsky wrote:
> Hi Prasanta,
>
> Ii is not necessary to cast to DefaultButtonModel after you add 
> getGroup() to ButtonModel:
>
> 241                 ButtonModel model = 
> ((JToggleButton)aComponent).getModel();
>
> --Semyon
>
> On 06/20/2017 10:36 PM, Prasanta Sadhukhan wrote:
>> Hi Semyon,
>>
>> Yes, it seems the problem will be there in that case. Modified to 
>> have getGroup() in the interface
>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.01/
>>
>> Regards
>> Prasanta
>> On 6/20/2017 11:16 PM, Semyon Sadetsky wrote:
>>> Hi Prasanta,
>>>
>>> With the DefaultButtonModel we can get the same exception if a 
>>> custom implementation of the ButtonModel is used.
>>>
>>> So, it is better check whether  the model is a DefaultButtonModel 
>>> and skip if grouping is not supported. Or, perhaps, it is reasonable 
>>> to pull up the getGroup() into the ButtonModel interface which 
>>> already has setGroup().
>>>
>>> --Semyon
>>>
>>>
>>> On 06/20/2017 10:21 AM, Prasanta Sadhukhan wrote:
>>>> Hi All,
>>>>
>>>> Please review a fix for an issue where a crash is reported when 
>>>> focus is moved with custom ButtonModel.
>>>> Issue was in LayoutFocusTraversalPolicy, the ButtonModel was 
>>>> wrongly typecasted to JToggleButton when the button model is 
>>>> DefaultButtonModel, resulting in ClassCastException.
>>>>
>>>> Proposed fix is to cast to super class DefaultButtonModel and then 
>>>> check for JToggleButton member.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8182577
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.00/
>>>>
>>>> Regards
>>>> Prasanta
>>>
>>
>



From semyon.sadetsky at oracle.com  Wed Jun 21 14:58:25 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 21 Jun 2017 07:58:25 -0700
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <66792efd-e60a-30d5-b5e5-87193e6c665d@oracle.com>
References: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>
 <f27d0da1-72c1-7903-c5bb-302e4c9a64af@oracle.com>
 <c5d59af0-bf79-5e1c-2d78-8264551e6a77@oracle.com>
 <5b9b2e34-cdd8-f8a9-ea14-ccb80b8f5925@oracle.com>
 <66792efd-e60a-30d5-b5e5-87193e6c665d@oracle.com>
Message-ID: <c01dcc9d-eaf4-cf4e-b5c5-2276894c9eb3@oracle.com>

Looks good. You will need to have CCC approval before push.

--Semyon


On 06/21/2017 07:55 AM, Prasanta Sadhukhan wrote:
> ok. Modified webrev:
>
> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.02/
>
> Regards
> Prasanta
> On 6/21/2017 7:45 PM, Semyon Sadetsky wrote:
>> Hi Prasanta,
>>
>> Ii is not necessary to cast to DefaultButtonModel after you add 
>> getGroup() to ButtonModel:
>>
>> 241                 ButtonModel model = 
>> ((JToggleButton)aComponent).getModel();
>>
>> --Semyon
>>
>> On 06/20/2017 10:36 PM, Prasanta Sadhukhan wrote:
>>> Hi Semyon,
>>>
>>> Yes, it seems the problem will be there in that case. Modified to 
>>> have getGroup() in the interface
>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.01/
>>>
>>> Regards
>>> Prasanta
>>> On 6/20/2017 11:16 PM, Semyon Sadetsky wrote:
>>>> Hi Prasanta,
>>>>
>>>> With the DefaultButtonModel we can get the same exception if a 
>>>> custom implementation of the ButtonModel is used.
>>>>
>>>> So, it is better check whether  the model is a DefaultButtonModel 
>>>> and skip if grouping is not supported. Or, perhaps, it is 
>>>> reasonable to pull up the getGroup() into the ButtonModel interface 
>>>> which already has setGroup().
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 06/20/2017 10:21 AM, Prasanta Sadhukhan wrote:
>>>>> Hi All,
>>>>>
>>>>> Please review a fix for an issue where a crash is reported when 
>>>>> focus is moved with custom ButtonModel.
>>>>> Issue was in LayoutFocusTraversalPolicy, the ButtonModel was 
>>>>> wrongly typecasted to JToggleButton when the button model is 
>>>>> DefaultButtonModel, resulting in ClassCastException.
>>>>>
>>>>> Proposed fix is to cast to super class DefaultButtonModel and then 
>>>>> check for JToggleButton member.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8182577
>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.00/
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>
>>>
>>
>



From sergey.bylokhov at oracle.com  Wed Jun 21 15:12:25 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 21 Jun 2017 18:12:25 +0300
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <66792efd-e60a-30d5-b5e5-87193e6c665d@oracle.com>
References: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>
 <f27d0da1-72c1-7903-c5bb-302e4c9a64af@oracle.com>
 <c5d59af0-bf79-5e1c-2d78-8264551e6a77@oracle.com>
 <5b9b2e34-cdd8-f8a9-ea14-ccb80b8f5925@oracle.com>
 <66792efd-e60a-30d5-b5e5-87193e6c665d@oracle.com>
Message-ID: <F2703F0F-CA4B-4031-A65D-62D1444E0DDC@oracle.com>

I think that the current version is not applicable to jdk10. We cannot add a new non-default methods to the interface, because this will break all subclasses.  

> 
> ok. Modified webrev:
> 
> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.02/
> 
> Regards
> Prasanta
> On 6/21/2017 7:45 PM, Semyon Sadetsky wrote:
>> Hi Prasanta,
>> 
>> Ii is not necessary to cast to DefaultButtonModel after you add getGroup() to ButtonModel:
>> 
>> 241                 ButtonModel model = ((JToggleButton)aComponent).getModel();
>> 
>> --Semyon
>> 
>> On 06/20/2017 10:36 PM, Prasanta Sadhukhan wrote:
>>> Hi Semyon,
>>> 
>>> Yes, it seems the problem will be there in that case. Modified to have getGroup() in the interface
>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.01/
>>> 
>>> Regards
>>> Prasanta
>>> On 6/20/2017 11:16 PM, Semyon Sadetsky wrote:
>>>> Hi Prasanta,
>>>> 
>>>> With the DefaultButtonModel we can get the same exception if a custom implementation of the ButtonModel is used.
>>>> 
>>>> So, it is better check whether  the model is a DefaultButtonModel and skip if grouping is not supported. Or, perhaps, it is reasonable to pull up the getGroup() into the ButtonModel interface which already has setGroup().
>>>> 
>>>> --Semyon
>>>> 
>>>> 
>>>> On 06/20/2017 10:21 AM, Prasanta Sadhukhan wrote:
>>>>> Hi All,
>>>>> 
>>>>> Please review a fix for an issue where a crash is reported when focus is moved with custom ButtonModel.
>>>>> Issue was in LayoutFocusTraversalPolicy, the ButtonModel was wrongly typecasted to JToggleButton when the button model is DefaultButtonModel, resulting in ClassCastException.
>>>>> 
>>>>> Proposed fix is to cast to super class DefaultButtonModel and then check for JToggleButton member.
>>>>> 
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8182577
>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.00/
>>>>> 
>>>>> Regards
>>>>> Prasanta
>>>> 
>>> 
>> 
> 



From kevin.rushforth at oracle.com  Wed Jun 21 15:19:21 2017
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 21 Jun 2017 08:19:21 -0700
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <c01dcc9d-eaf4-cf4e-b5c5-2276894c9eb3@oracle.com>
References: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>
 <f27d0da1-72c1-7903-c5bb-302e4c9a64af@oracle.com>
 <c5d59af0-bf79-5e1c-2d78-8264551e6a77@oracle.com>
 <5b9b2e34-cdd8-f8a9-ea14-ccb80b8f5925@oracle.com>
 <66792efd-e60a-30d5-b5e5-87193e6c665d@oracle.com>
 <c01dcc9d-eaf4-cf4e-b5c5-2276894c9eb3@oracle.com>
Message-ID: <594A8E79.8080100@oracle.com>

Two quick comments:

1) Is ButtonModel an interface that applications would ever implement? 
If so, then it is an incompatible change, since there is no default 
implementation of the new method.

2) You should add the '@since 10' javadoc tag to the new method.

-- Kevin


Semyon Sadetsky wrote:
> Looks good. You will need to have CCC approval before push.
>
> --Semyon
>
>
> On 06/21/2017 07:55 AM, Prasanta Sadhukhan wrote:
>> ok. Modified webrev:
>>
>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.02/
>>
>> Regards
>> Prasanta
>> On 6/21/2017 7:45 PM, Semyon Sadetsky wrote:
>>> Hi Prasanta,
>>>
>>> Ii is not necessary to cast to DefaultButtonModel after you add 
>>> getGroup() to ButtonModel:
>>>
>>> 241                 ButtonModel model = 
>>> ((JToggleButton)aComponent).getModel();
>>>
>>> --Semyon
>>>
>>> On 06/20/2017 10:36 PM, Prasanta Sadhukhan wrote:
>>>> Hi Semyon,
>>>>
>>>> Yes, it seems the problem will be there in that case. Modified to 
>>>> have getGroup() in the interface
>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.01/
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 6/20/2017 11:16 PM, Semyon Sadetsky wrote:
>>>>> Hi Prasanta,
>>>>>
>>>>> With the DefaultButtonModel we can get the same exception if a 
>>>>> custom implementation of the ButtonModel is used.
>>>>>
>>>>> So, it is better check whether  the model is a DefaultButtonModel 
>>>>> and skip if grouping is not supported. Or, perhaps, it is 
>>>>> reasonable to pull up the getGroup() into the ButtonModel 
>>>>> interface which already has setGroup().
>>>>>
>>>>> --Semyon
>>>>>
>>>>>
>>>>> On 06/20/2017 10:21 AM, Prasanta Sadhukhan wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Please review a fix for an issue where a crash is reported when 
>>>>>> focus is moved with custom ButtonModel.
>>>>>> Issue was in LayoutFocusTraversalPolicy, the ButtonModel was 
>>>>>> wrongly typecasted to JToggleButton when the button model is 
>>>>>> DefaultButtonModel, resulting in ClassCastException.
>>>>>>
>>>>>> Proposed fix is to cast to super class DefaultButtonModel and 
>>>>>> then check for JToggleButton member.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8182577
>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.00/
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>
>>>>
>>>
>>
>


From prasanta.sadhukhan at oracle.com  Wed Jun 21 16:20:53 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 21 Jun 2017 21:50:53 +0530
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <594A8E79.8080100@oracle.com>
References: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>
 <f27d0da1-72c1-7903-c5bb-302e4c9a64af@oracle.com>
 <c5d59af0-bf79-5e1c-2d78-8264551e6a77@oracle.com>
 <5b9b2e34-cdd8-f8a9-ea14-ccb80b8f5925@oracle.com>
 <66792efd-e60a-30d5-b5e5-87193e6c665d@oracle.com>
 <c01dcc9d-eaf4-cf4e-b5c5-2276894c9eb3@oracle.com>
 <594A8E79.8080100@oracle.com>
Message-ID: <3721ab7d-d7f8-d519-5f9e-46011065bd84@oracle.com>

Modified webrev to give default implementation of the new method

http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.03/

Regards
Prasanta
On 6/21/2017 8:49 PM, Kevin Rushforth wrote:
> Two quick comments:
>
> 1) Is ButtonModel an interface that applications would ever implement? 
> If so, then it is an incompatible change, since there is no default 
> implementation of the new method.
>
> 2) You should add the '@since 10' javadoc tag to the new method.
>
> -- Kevin
>
>
> Semyon Sadetsky wrote:
>> Looks good. You will need to have CCC approval before push.
>>
>> --Semyon
>>
>>
>> On 06/21/2017 07:55 AM, Prasanta Sadhukhan wrote:
>>> ok. Modified webrev:
>>>
>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.02/
>>>
>>> Regards
>>> Prasanta
>>> On 6/21/2017 7:45 PM, Semyon Sadetsky wrote:
>>>> Hi Prasanta,
>>>>
>>>> Ii is not necessary to cast to DefaultButtonModel after you add 
>>>> getGroup() to ButtonModel:
>>>>
>>>> 241                 ButtonModel model = 
>>>> ((JToggleButton)aComponent).getModel();
>>>>
>>>> --Semyon
>>>>
>>>> On 06/20/2017 10:36 PM, Prasanta Sadhukhan wrote:
>>>>> Hi Semyon,
>>>>>
>>>>> Yes, it seems the problem will be there in that case. Modified to 
>>>>> have getGroup() in the interface
>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.01/
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 6/20/2017 11:16 PM, Semyon Sadetsky wrote:
>>>>>> Hi Prasanta,
>>>>>>
>>>>>> With the DefaultButtonModel we can get the same exception if a 
>>>>>> custom implementation of the ButtonModel is used.
>>>>>>
>>>>>> So, it is better check whether  the model is a DefaultButtonModel 
>>>>>> and skip if grouping is not supported. Or, perhaps, it is 
>>>>>> reasonable to pull up the getGroup() into the ButtonModel 
>>>>>> interface which already has setGroup().
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>>
>>>>>> On 06/20/2017 10:21 AM, Prasanta Sadhukhan wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Please review a fix for an issue where a crash is reported when 
>>>>>>> focus is moved with custom ButtonModel.
>>>>>>> Issue was in LayoutFocusTraversalPolicy, the ButtonModel was 
>>>>>>> wrongly typecasted to JToggleButton when the button model is 
>>>>>>> DefaultButtonModel, resulting in ClassCastException.
>>>>>>>
>>>>>>> Proposed fix is to cast to super class DefaultButtonModel and 
>>>>>>> then check for JToggleButton member.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8182577
>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.00/
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>
>>>>>
>>>>
>>>
>>



From srinivas.mandalika at oracle.com  Thu Jun 22 04:05:32 2017
From: srinivas.mandalika at oracle.com (Srinivas Mandalika)
Date: Wed, 21 Jun 2017 21:05:32 -0700 (PDT)
Subject: <Swing Dev> [10][TESTBUG]: Review Request for JDK-8169958 :
 javax/swing/JSpinner/5012888: Spinner value should be more than 1
Message-ID: <c64e6751-bdeb-4c0c-90d3-ac0f0db97fa6@default>

Hi Sergey,

I have added the change for the frame being disposed in both the test pass/fail conditions.
Please note that this fix is now targeted for jdk10 and has been tested on it as well.

Updated webrev: http://cr.openjdk.java.net/~akolarkunnu/8169958/webrev.02/


Regards,
Srinivas M

-----Original Message-----
From: Sergey Bylokhov 
Sent: Monday, June 19, 2017 9:03 PM
To: Srinivas Mandalika <srinivas.mandalika at oracle.com>
Cc: Ajit Ghaisas <ajit.ghaisas at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169958 : javax/swing/JSpinner/5012888: Spinner value should be more than 1

Hi, Srinivas.
You will need to dispose the frame at the end of the test(when the test fails or pass).
> 
> Hi Ajit,
> 
> Thank you for your comments. I have incorporated all your comments.  There are also a few additional changes of invoking code on EDT that I made while executing this fix to validate the test stability. 
> 
> Updated webrev: http://cr.openjdk.java.net/~akolarkunnu/8169958/webrev.01/
> 
> 
> Thanks,
> Srinivas M
> 
> -----Original Message-----
> From: Ajit Ghaisas 
> Sent: Monday, June 12, 2017 2:41 PM
> To: Srinivas Mandalika <srinivas.mandalika at oracle.com>; swing-dev at openjdk.java.net
> Subject: RE: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169958 : javax/swing/JSpinner/5012888: Spinner value should be more than 1
> 
> Hi Srinivas,
> 
>   Here are few review comments :
>   1.  Add this bug id to the @bug jtreg tag in test
>   2. Replace generic import statements with specific ones
>   3. You are calling - b.doTest(); - in a try catch block. This will catch any exception and print stack trace. 
>       I think we can remove this try-catch block - simply make a call to b.doTest(), if an exception is thrown, it is thrown out from main() and jtreg framework will catch it and mark the test as failed.
>   4. Line 63 in your file has a throw error - this can be converted to exception.
>   5. Keep four spaces indentation level
> 
> Regards,
> Ajit
> 
> 
> From: Srinivas Mandalika 
> Sent: Monday, June 12, 2017 1:51 PM
> To: swing-dev at openjdk.java.net
> Subject: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169958 : javax/swing/JSpinner/5012888: Spinner value should be more than 1
> 
> Hi All,
> 
> Please review the test bug fix for JDK-8169958 : javax/swing/JSpinner/5012888: Spinner value should be more than 1.
> 
> Issue: 
> In this bug, click & hold on arrow of JSpinner only transfers focus and does not change spinner value. This behavior is intermittently seen in the automated test but is working as expected when checked for manualy. The test was failing robot clicks out of sync with the yet to be maximized frame.
> 
> Fix: 
> Ensure the robot waits for the frame to be maximized before the clicks on the Spinner. Also ensure the main application frame is maximized explicitly.
> 
> Testing: 
> Tested the potential fix on winx64, linux  with JDK8, 9 several times with running tests individually clubbed with the previous test and the entire suite (i.e javax/swing) put to ensure that the issue is not repeated.
> 
> Bug Id:
> https://bugs.openjdk.java.net/browse/JDK-8169958
> 
> 
> WebRev Request:
> http://cr.openjdk.java.net/~akolarkunnu/8169958/webrev.00/
> 
> 
> Regards,
> Srinivas M



From srinivas.mandalika at oracle.com  Thu Jun 22 04:16:06 2017
From: srinivas.mandalika at oracle.com (Srinivas Mandalika)
Date: Wed, 21 Jun 2017 21:16:06 -0700 (PDT)
Subject: <Swing Dev> [10][TESTBUG]: Review Request for JDK-8169954 :
 JFileChooser/8021253: java.lang.RuntimeException: Default button is not
 pressed
Message-ID: <8114f4b2-2e95-47ab-b530-e5e27dda2443@default>

Hi Sergey

?

Thank you for the detailed comments.

* bug8021253.java

1.?????? Added back the waitForIdle statement.

2.?????? Reverted to Robot instead of JRobot.

?*?bug7199708.java:

3.?????? Rethrowing the exception instead of e.printStackTrace() 

4.?????? Using SwingTestHelper - I had understood wrongly that this is still a recommended approach. I have reverted to original code and added the ?filechooser?s table sort mouse action sync? fix to it, instead of doing it by using the SwigTestHelper dependencies

5.?????? Earlier, both test passed when run alone. When 7199708 is run before 8021253, 7199708 passed but then 8021253 fails as the UI opens up minimized which I believe were due to stray robot actions on to the desktop. For this the fix was put in 7199807. 8021253 code change was to make it more stable.? 

6.?????? Code formatted to wrap after 80 characters.

7.?????? The fileChooser cancelSelection is called now.

??????????????? 

Please note that this code is now targeted for jdk10 and was tested on the same as well.

?

Updated webrev: 

http://cr.openjdk.java.net/~akolarkunnu/8169954/webrev.01/

?

Thanks,

Srinivas M

From: Sergey Bylokhov 
Sent: Monday, June 19, 2017 9:31 PM
To: Srinivas Mandalika <srinivas.mandalika at oracle.com>
Cc: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169954 : JFileChooser/8021253: java.lang.RuntimeException: Default button is not pressed

?

Hi,?Srinivas.

A few comments:

? * bug8021253.java:

? ? ? - You should not delete this lone "74 robot.waitForIdle()? because it is waits while the previous clicks are executed, w/o this line you can get a situation when defaultKeyPressed will be false because the code on EDT is in progress.

? ? ? - Do not use JRobot if it is not strictly necessary because this additional dependency will make harder to run the test standalone, w/o jtreg.

? *?bug7199708.java:

? ? ? - Always rethrow an exception instead of e.printStackTrace();

? ? ? - I am not sure that SwingTestHelper is necessary here, it was useful while java had no lamda, so the code was quite long when we executed a number or ?InvokeAndWait?, but now it should be compact.(Even in the current code it is visible that after the fix the code became longer).

? ? ? - Please confirm that the test still fails before 7199708 was fixed.

? ? ? - The new line ?85? is too long please split it to fit 80 chars per line.

? ? ? - Please add a code to dispose the frame after test execution.

?

Hi All,

?

Please review the test bug fix for JDK-8169954 : JFileChooser/8021253: java.lang.RuntimeException: Default button is not pressed.

?

Issue:

The Test under ?8021253 is opening up a filechooser iconified, causing a failure to hit Enter key on the filechooser. Test failure is intermittent and more pronounced when run along with the entire javax/swing suite.

?

Fix:

This is occurring due to synchronization issues in the previous test 7199708.?
The test for bug 7199708 checks if the filechooser can load up a large number of files without a crash. In doing so it also tries to sort the columns of the filechooser via Robot mouse move and click actions.?
Commenting out these robot actions ensured that the next test 8021253 was passing indicating that this was a problem of with synchronization of the filechooser UI sorting and disposal of filechooser and that root cause was that these were not synchronized properly.?Hence fixed the code flow using the regtesthelpers classes, to ensure that this is working correctly now.

Also ensured the filechooser of test 8021253 is not opened iconified and has focus.?

?

Testing:

Tested the potential fix on winx64, linux ?with JDK8, 9 several times with running tests individually clubbed with the previous test and the entire suite (i.e javax/swing) put to ensure that the issue is not repeated.

?

Bug Id:

https://bugs.openjdk.java.net/browse/JDK-8169954

?

WebRev Request:

http://cr.openjdk.java.net/~akolarkunnu/8169954/webrev.00/

?

?

Regards,

Srinivas M

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

From shashidhara.veerabhadraiah at oracle.com  Thu Jun 22 09:20:39 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Thu, 22 Jun 2017 02:20:39 -0700 (PDT)
Subject: <Swing Dev> [9] JDK-8165213: [TESTBUG] [PIT] consistent failure
 of a new regtest for 8163193
In-Reply-To: <d1be7dfa-bda4-437b-a152-a4a0c5c9384f@default>
References: <e5caac0a-b6b8-4b02-9a3e-ece26162d3ef@default>
 <D7F421A7-B1F6-4C06-A330-08C6B89ED052@oracle.com>
 <d1be7dfa-bda4-437b-a152-a4a0c5c9384f@default>
Message-ID: <e43d4a92-c324-417a-a667-8dcc970338be@default>

Hi Sergey, I have uploaded test per our discussion and is available at:

http://cr.openjdk.java.net/~pkbalakr/shashi/8165213/webrev_03/

 

Please review and do provide the comments if any.

 

Thanks and regards,

Shashi

 

From: Shashidhara Veerabhadraiah 
Sent: Thursday, June 15, 2017 2:40 PM
To: Sergey Bylokhov <sergey.bylokhov at oracle.com>
Cc: swing-dev at openjdk.java.net; Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>
Subject: RE: [9] JDK-8165213: [TESTBUG] [PIT] consistent failure of a new regtest for 8163193

 

Hi Sergey,  The color profile on mac was generic RGB. Moreover the robot api takes the co-ordinates as input as against my implementation which takes the component as input and hence we always get the exact component image onto the buffered image. The component's coordinates may vary depending on the location of the task bar like on mac or linux(ubuntu), hence the supplied co-ordinates may go awry. I feel that capturing the component directly onto the buffered image is better considering the cross platforms. Please let me know if you feel otherwise.

 

Below is the image comparison between the windows(top) and linux(below), snapshot that was captured onto the buffered image as a png file. I see that the linux component is slightly bigger by around 4 pixel width(approx.). I think this is the reason behind the color differences across the platforms and the same reason why mac has color differences at the same location when compared with windows one. Same location means that the program supplies a size of 300 * 300 width component and the location where we extract the color is calculated automatically based on the component size.

 



 

I am not sure why there is a change in width. I am not sure should I continue to debug in that direction or not!!

 

This is the logical explanation that I could achieve for the color tolerance band that was used in the program. So please let me know what do you think of this.

 

Thanks and regards,

Shashi

 

-----Original Message-----
From: Sergey Bylokhov 
Sent: Thursday, June 8, 2017 1:12 PM
To: Shashidhara Veerabhadraiah <HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com>
Cc: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Prasanta Sadhukhan <HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"prasanta.sadhukhan at oracle.com>
Subject: Re: [9] JDK-8165213: [TESTBUG] [PIT] consistent failure of a new regtest for 8163193

 

On what color profiles the test is executed? On macOS it should be Generic RGB. Also in jdk9 the new robot api for HiDPI was added, please try it also.

If it solve the problem on Mac then I suggest to try to investigate a problem on Linux and fix it if possible, instead of tweaking the test.

 

> 

> Hi All,

>             Please review fix for JDK-8165213 where there is a consistent failure while testing for gradient color of the button.

> 

> Issue: The Robot's function to get the pixel's RGB values has an issue with its implementation and is currently getting resolved. Because of this issue, we are getting incorrect RGB values for the requested pixel and hence the test is getting failed.

> 

> Resolution\Fix: There is an alternate mechanism to capture the image to a buffer and use the buffer function to get the RGB values. This test is for HiDpi displays. In the image space, the images won't be scaled implicitly and hence they need to be applied with the scaling in the graphics space before painting on to the image buffer. This same is implemented.

> Based on the test outputs, the tolerance band for color comparison is set at 11.

> 

> Test outputs: 

> 1. On a windows system, the pixel color values exactly matches.

> 2. On a Linux system, the pixel color values vary by a maximum difference of around 6.

> 3. On a mac system, the pixel color values vary by a maximum difference of around 10.

> 

> Bug: https://bugs.openjdk.java.net/browse/JDK-8165213

> Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/8165213/webrev_01/

> 

> Thanks and regards,

> Shashi

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170622/17049c98/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 70419 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170622/17049c98/image002.jpg>

From kevin.rushforth at oracle.com  Thu Jun 22 12:22:31 2017
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 22 Jun 2017 05:22:31 -0700
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <3721ab7d-d7f8-d519-5f9e-46011065bd84@oracle.com>
References: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>
 <f27d0da1-72c1-7903-c5bb-302e4c9a64af@oracle.com>
 <c5d59af0-bf79-5e1c-2d78-8264551e6a77@oracle.com>
 <5b9b2e34-cdd8-f8a9-ea14-ccb80b8f5925@oracle.com>
 <66792efd-e60a-30d5-b5e5-87193e6c665d@oracle.com>
 <c01dcc9d-eaf4-cf4e-b5c5-2276894c9eb3@oracle.com>
 <594A8E79.8080100@oracle.com>
 <3721ab7d-d7f8-d519-5f9e-46011065bd84@oracle.com>
Message-ID: <594BB687.9030505@oracle.com>

The change to the public API for the ButtonModel interface looks OK to 
me now, but I am not familiar enough with the rest to review it.

Thanks.

-- Kevin


Prasanta Sadhukhan wrote:
> Modified webrev to give default implementation of the new method
>
> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.03/
>
> Regards
> Prasanta
> On 6/21/2017 8:49 PM, Kevin Rushforth wrote:
>> Two quick comments:
>>
>> 1) Is ButtonModel an interface that applications would ever 
>> implement? If so, then it is an incompatible change, since there is 
>> no default implementation of the new method.
>>
>> 2) You should add the '@since 10' javadoc tag to the new method.
>>
>> -- Kevin
>>
>>
>> Semyon Sadetsky wrote:
>>> Looks good. You will need to have CCC approval before push.
>>>
>>> --Semyon
>>>
>>>
>>> On 06/21/2017 07:55 AM, Prasanta Sadhukhan wrote:
>>>> ok. Modified webrev:
>>>>
>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.02/
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 6/21/2017 7:45 PM, Semyon Sadetsky wrote:
>>>>> Hi Prasanta,
>>>>>
>>>>> Ii is not necessary to cast to DefaultButtonModel after you add 
>>>>> getGroup() to ButtonModel:
>>>>>
>>>>> 241                 ButtonModel model = 
>>>>> ((JToggleButton)aComponent).getModel();
>>>>>
>>>>> --Semyon
>>>>>
>>>>> On 06/20/2017 10:36 PM, Prasanta Sadhukhan wrote:
>>>>>> Hi Semyon,
>>>>>>
>>>>>> Yes, it seems the problem will be there in that case. Modified to 
>>>>>> have getGroup() in the interface
>>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.01/
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 6/20/2017 11:16 PM, Semyon Sadetsky wrote:
>>>>>>> Hi Prasanta,
>>>>>>>
>>>>>>> With the DefaultButtonModel we can get the same exception if a 
>>>>>>> custom implementation of the ButtonModel is used.
>>>>>>>
>>>>>>> So, it is better check whether  the model is a 
>>>>>>> DefaultButtonModel and skip if grouping is not supported. Or, 
>>>>>>> perhaps, it is reasonable to pull up the getGroup() into the 
>>>>>>> ButtonModel interface which already has setGroup().
>>>>>>>
>>>>>>> --Semyon
>>>>>>>
>>>>>>>
>>>>>>> On 06/20/2017 10:21 AM, Prasanta Sadhukhan wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Please review a fix for an issue where a crash is reported when 
>>>>>>>> focus is moved with custom ButtonModel.
>>>>>>>> Issue was in LayoutFocusTraversalPolicy, the ButtonModel was 
>>>>>>>> wrongly typecasted to JToggleButton when the button model is 
>>>>>>>> DefaultButtonModel, resulting in ClassCastException.
>>>>>>>>
>>>>>>>> Proposed fix is to cast to super class DefaultButtonModel and 
>>>>>>>> then check for JToggleButton member.
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8182577
>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.00/
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>


From sergey.bylokhov at oracle.com  Wed Jun 21 16:08:46 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 21 Jun 2017 19:08:46 +0300
Subject: <Swing Dev> [10] RFR: JDK-8043315: Nimbus: Setting
 Nimbus.Overrides property affects custom keymap installation
In-Reply-To: <4ebae06f-55e4-387c-6453-57c25a140fa3@oracle.com>
References: <54afabea-f351-4fd5-860a-29bd293b2c6d@default>
 <8af41cf8-f51a-6322-9664-6d45fc640a80@oracle.com>
 <FF30652A-0A02-4BA9-A491-0A7CEC58F498@oracle.com>
 <4ebae06f-55e4-387c-6453-57c25a140fa3@oracle.com>
Message-ID: <9AA1012D-781F-4331-9727-75078FFCC822@oracle.com>

Looks fine.

> 
> Yes, it fails for SynthTextAreaUI/SynthTextFieldUI so change applied to those files too. Since the test is in nimbus folder, I went for throwing an exception if Nimbus cannot be set.
> 
> http://cr.openjdk.java.net/~psadhukhan/8043315/webrev.03/
> 
> Regards
> Prasanta
> On 6/19/2017 8:32 PM, Sergey Bylokhov wrote:
>>> I have modified webrev to remove static keyword and made the test automated
>> Should the same change be applied to SynthTextAreaUI/SynthTextFieldUI?
>> In the test you should throw an exception if Nimbus cannot be set, or you can iterate over all installed l&f.
>> 
>>> http://cr.openjdk.java.net/~psadhukhan/8043315/webrev.01/
>>> Updated fix tests if app has fired a property change by calling setKeymap() then it will not uninstall custom keymap and let the custom keymap be honoured. If app again calls setKeymap(null) then the static variable will be "true" and it will reset back to default keymap.
>>> 
>>> Regards
>>> Prasanta
>>> On 6/2/2017 12:07 AM, Sergey Bylokhov wrote:
>>>> Hi, Prasanta.
>>>> Can you please clarify the fix a little bit.
>>>> You have a static variable, which is set to "false" when the listener for "keymap" is triggered, and it seems that you never set it back to "true"? Is it intentional behavior?
>>>> Note that if there are a few objects of "SynthEditorPaneUI" then they will share this static field. Also it seems that the test can be automated, because currently it is requires from the user to press only one button("space").
>>>> 
>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>> 
>>>>> Hi All,
>>>>> 
>>>>> Please review a bug fix for Nimbus L&F where if app sets custom keymap
>>>>> 
>>>>> and then sets Nimbus.Overrides property,
>>>>> then the custom keymap is not honoured.
>>>>> For example, if testapp sets a new action for "space" key press and
>>>>> sets
>>>>> sets Nimbus.Overrides property,
>>>>>   it will not be honoured and default action ie. inserting a "space"
>>>>> character will be done.
>>>>> 
>>>>> Issue was NimbusLookAndFeel#shouldUpdateStyleOnEvent() returns true
>>>>> for
>>>>> Nimbus.Override property which causes SynthEditorPaneUI#updateStyle()
>>>>> to
>>>>> be called which
>>>>> uninstall set keyboard actions and sets up default keyboard action.
>>>>> 
>>>>> Proposed fix is to check if a keymap is already set (a propertyChange
>>>>> 
>>>>> event will be fired for when app calls setKeyMap()) then do not reset
>>>>> to
>>>>> default keymap.
>>>>> 
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8043315
>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8043315/webrev.00/
>>>>> 
>>>>> Regards
>>>>> Prasanta
> 



From sergey.bylokhov at oracle.com  Thu Jun 22 14:52:06 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 22 Jun 2017 17:52:06 +0300
Subject: <Swing Dev> [9] JDK-8165213: [TESTBUG] [PIT] consistent failure
 of a new regtest for 8163193
In-Reply-To: <e43d4a92-c324-417a-a667-8dcc970338be@default>
References: <e5caac0a-b6b8-4b02-9a3e-ece26162d3ef@default>
 <D7F421A7-B1F6-4C06-A330-08C6B89ED052@oracle.com>
 <d1be7dfa-bda4-437b-a152-a4a0c5c9384f@default>
 <e43d4a92-c324-417a-a667-8dcc970338be@default>
Message-ID: <DD3CF64D-A30D-4642-BA3E-8E278B0D2579@oracle.com>

Hi, Shashi.

Please do not use the empty catch blocks, always rethrow an exception.
Note that you need to check the count of images returned by getResolutionVariants(), it will be one image on non-hopi screen. It seems that the ?images;? field may be local in testGradient() method.

> Hi Sergey, I have uploaded test per our discussion and is available at:
> http://cr.openjdk.java.net/~pkbalakr/shashi/8165213/webrev_03/ <http://cr.openjdk.java.net/~pkbalakr/shashi/8165213/webrev_03/>
>  
> Please review and do provide the comments if any.
>  
> Thanks and regards,
> Shashi
> ? <>
> From: Shashidhara Veerabhadraiah 
> Sent: Thursday, June 15, 2017 2:40 PM
> To: Sergey Bylokhov <sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com>>
> Cc: swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>; Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com>>
> Subject: RE: [9] JDK-8165213: [TESTBUG] [PIT] consistent failure of a new regtest for 8163193
>  
> Hi Sergey,  The color profile on mac was generic RGB. Moreover the robot api takes the co-ordinates as input as against my implementation which takes the component as input and hence we always get the exact component image onto the buffered image. The component?s coordinates may vary depending on the location of the task bar like on mac or linux(ubuntu), hence the supplied co-ordinates may go awry. I feel that capturing the component directly onto the buffered image is better considering the cross platforms. Please let me know if you feel otherwise.
>  
> Below is the image comparison between the windows(top) and linux(below), snapshot that was captured onto the buffered image as a png file. I see that the linux component is slightly bigger by around 4 pixel width(approx.). I think this is the reason behind the color differences across the platforms and the same reason why mac has color differences at the same location when compared with windows one. Same location means that the program supplies a size of 300 * 300 width component and the location where we extract the color is calculated automatically based on the component size.
>  
> <image002.jpg>
>  
> I am not sure why there is a change in width. I am not sure should I continue to debug in that direction or not!!
>  
> This is the logical explanation that I could achieve for the color tolerance band that was used in the program. So please let me know what do you think of this.
>  
> Thanks and regards,
> Shashi
>  
> -----Original Message-----
> From: Sergey Bylokhov 
> Sent: Thursday, June 8, 2017 1:12 PM
> To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com <mailto:shashidhara.veerabhadraiah at oracle.com>>
> Cc: swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>; Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com>>
> Subject: Re: [9] JDK-8165213: [TESTBUG] [PIT] consistent failure of a new regtest for 8163193
>  
> On what color profiles the test is executed? On macOS it should be Generic RGB. Also in jdk9 the new robot api for HiDPI was added, please try it also.
> If it solve the problem on Mac then I suggest to try to investigate a problem on Linux and fix it if possible, instead of tweaking the test.
>  
> > 
> > Hi All,
> >             Please review fix for JDK-8165213 where there is a consistent failure while testing for gradient color of the button.
> > 
> > Issue: The Robot's function to get the pixel's RGB values has an issue with its implementation and is currently getting resolved. Because of this issue, we are getting incorrect RGB values for the requested pixel and hence the test is getting failed.
> > 
> > Resolution\Fix: There is an alternate mechanism to capture the image to a buffer and use the buffer function to get the RGB values. This test is for HiDpi displays. In the image space, the images won't be scaled implicitly and hence they need to be applied with the scaling in the graphics space before painting on to the image buffer. This same is implemented.
> > Based on the test outputs, the tolerance band for color comparison is set at 11.
> > 
> > Test outputs: 
> > 1. On a windows system, the pixel color values exactly matches.
> > 2. On a Linux system, the pixel color values vary by a maximum difference of around 6.
> > 3. On a mac system, the pixel color values vary by a maximum difference of around 10.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8165213 <https://bugs.openjdk.java.net/browse/JDK-8165213>
> > Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/8165213/webrev_01/ <http://cr.openjdk.java.net/~pkbalakr/shashi/8165213/webrev_01/>
> > 
> > Thanks and regards,
> > Shashi

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

From semyon.sadetsky at oracle.com  Thu Jun 22 14:57:17 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 22 Jun 2017 07:57:17 -0700
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <594BB687.9030505@oracle.com>
References: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>
 <f27d0da1-72c1-7903-c5bb-302e4c9a64af@oracle.com>
 <c5d59af0-bf79-5e1c-2d78-8264551e6a77@oracle.com>
 <5b9b2e34-cdd8-f8a9-ea14-ccb80b8f5925@oracle.com>
 <66792efd-e60a-30d5-b5e5-87193e6c665d@oracle.com>
 <c01dcc9d-eaf4-cf4e-b5c5-2276894c9eb3@oracle.com>
 <594A8E79.8080100@oracle.com>
 <3721ab7d-d7f8-d519-5f9e-46011065bd84@oracle.com>
 <594BB687.9030505@oracle.com>
Message-ID: <b1881cce-2114-d1b4-a3f1-f6c07be51ece@oracle.com>

+1

--Semyon


On 06/22/2017 05:22 AM, Kevin Rushforth wrote:
> The change to the public API for the ButtonModel interface looks OK to 
> me now, but I am not familiar enough with the rest to review it.
>
> Thanks.
>
> -- Kevin
>
>
> Prasanta Sadhukhan wrote:
>> Modified webrev to give default implementation of the new method
>>
>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.03/
>>
>> Regards
>> Prasanta
>> On 6/21/2017 8:49 PM, Kevin Rushforth wrote:
>>> Two quick comments:
>>>
>>> 1) Is ButtonModel an interface that applications would ever 
>>> implement? If so, then it is an incompatible change, since there is 
>>> no default implementation of the new method.
>>>
>>> 2) You should add the '@since 10' javadoc tag to the new method.
>>>
>>> -- Kevin
>>>
>>>
>>> Semyon Sadetsky wrote:
>>>> Looks good. You will need to have CCC approval before push.
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 06/21/2017 07:55 AM, Prasanta Sadhukhan wrote:
>>>>> ok. Modified webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.02/
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 6/21/2017 7:45 PM, Semyon Sadetsky wrote:
>>>>>> Hi Prasanta,
>>>>>>
>>>>>> Ii is not necessary to cast to DefaultButtonModel after you add 
>>>>>> getGroup() to ButtonModel:
>>>>>>
>>>>>> 241                 ButtonModel model = 
>>>>>> ((JToggleButton)aComponent).getModel();
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>> On 06/20/2017 10:36 PM, Prasanta Sadhukhan wrote:
>>>>>>> Hi Semyon,
>>>>>>>
>>>>>>> Yes, it seems the problem will be there in that case. Modified 
>>>>>>> to have getGroup() in the interface
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.01/
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 6/20/2017 11:16 PM, Semyon Sadetsky wrote:
>>>>>>>> Hi Prasanta,
>>>>>>>>
>>>>>>>> With the DefaultButtonModel we can get the same exception if a 
>>>>>>>> custom implementation of the ButtonModel is used.
>>>>>>>>
>>>>>>>> So, it is better check whether  the model is a 
>>>>>>>> DefaultButtonModel and skip if grouping is not supported. Or, 
>>>>>>>> perhaps, it is reasonable to pull up the getGroup() into the 
>>>>>>>> ButtonModel interface which already has setGroup().
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>>
>>>>>>>> On 06/20/2017 10:21 AM, Prasanta Sadhukhan wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Please review a fix for an issue where a crash is reported 
>>>>>>>>> when focus is moved with custom ButtonModel.
>>>>>>>>> Issue was in LayoutFocusTraversalPolicy, the ButtonModel was 
>>>>>>>>> wrongly typecasted to JToggleButton when the button model is 
>>>>>>>>> DefaultButtonModel, resulting in ClassCastException.
>>>>>>>>>
>>>>>>>>> Proposed fix is to cast to super class DefaultButtonModel and 
>>>>>>>>> then check for JToggleButton member.
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8182577
>>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.00/
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>



From sergey.bylokhov at oracle.com  Thu Jun 22 15:08:10 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 22 Jun 2017 18:08:10 +0300
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <594BB687.9030505@oracle.com>
References: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>
 <f27d0da1-72c1-7903-c5bb-302e4c9a64af@oracle.com>
 <c5d59af0-bf79-5e1c-2d78-8264551e6a77@oracle.com>
 <5b9b2e34-cdd8-f8a9-ea14-ccb80b8f5925@oracle.com>
 <66792efd-e60a-30d5-b5e5-87193e6c665d@oracle.com>
 <c01dcc9d-eaf4-cf4e-b5c5-2276894c9eb3@oracle.com>
 <594A8E79.8080100@oracle.com>
 <3721ab7d-d7f8-d519-5f9e-46011065bd84@oracle.com>
 <594BB687.9030505@oracle.com>
Message-ID: <C576FC01-1498-42F1-98AF-D63CFD0E7A00@oracle.com>

I do not remember should we describe default implementation via @implNote or something like that?

> 
> The change to the public API for the ButtonModel interface looks OK to me now, but I am not familiar enough with the rest to review it.
> 
> Thanks.
> 
> -- Kevin
> 
> 
> Prasanta Sadhukhan wrote:
>> Modified webrev to give default implementation of the new method
>> 
>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.03/
>> 
>> Regards
>> Prasanta
>> On 6/21/2017 8:49 PM, Kevin Rushforth wrote:
>>> Two quick comments:
>>> 
>>> 1) Is ButtonModel an interface that applications would ever implement? If so, then it is an incompatible change, since there is no default implementation of the new method.
>>> 
>>> 2) You should add the '@since 10' javadoc tag to the new method.
>>> 
>>> -- Kevin
>>> 
>>> 
>>> Semyon Sadetsky wrote:
>>>> Looks good. You will need to have CCC approval before push.
>>>> 
>>>> --Semyon
>>>> 
>>>> 
>>>> On 06/21/2017 07:55 AM, Prasanta Sadhukhan wrote:
>>>>> ok. Modified webrev:
>>>>> 
>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.02/
>>>>> 
>>>>> Regards
>>>>> Prasanta
>>>>> On 6/21/2017 7:45 PM, Semyon Sadetsky wrote:
>>>>>> Hi Prasanta,
>>>>>> 
>>>>>> Ii is not necessary to cast to DefaultButtonModel after you add getGroup() to ButtonModel:
>>>>>> 
>>>>>> 241                 ButtonModel model = ((JToggleButton)aComponent).getModel();
>>>>>> 
>>>>>> --Semyon
>>>>>> 
>>>>>> On 06/20/2017 10:36 PM, Prasanta Sadhukhan wrote:
>>>>>>> Hi Semyon,
>>>>>>> 
>>>>>>> Yes, it seems the problem will be there in that case. Modified to have getGroup() in the interface
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.01/
>>>>>>> 
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 6/20/2017 11:16 PM, Semyon Sadetsky wrote:
>>>>>>>> Hi Prasanta,
>>>>>>>> 
>>>>>>>> With the DefaultButtonModel we can get the same exception if a custom implementation of the ButtonModel is used.
>>>>>>>> 
>>>>>>>> So, it is better check whether  the model is a DefaultButtonModel and skip if grouping is not supported. Or, perhaps, it is reasonable to pull up the getGroup() into the ButtonModel interface which already has setGroup().
>>>>>>>> 
>>>>>>>> --Semyon
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 06/20/2017 10:21 AM, Prasanta Sadhukhan wrote:
>>>>>>>>> Hi All,
>>>>>>>>> 
>>>>>>>>> Please review a fix for an issue where a crash is reported when focus is moved with custom ButtonModel.
>>>>>>>>> Issue was in LayoutFocusTraversalPolicy, the ButtonModel was wrongly typecasted to JToggleButton when the button model is DefaultButtonModel, resulting in ClassCastException.
>>>>>>>>> 
>>>>>>>>> Proposed fix is to cast to super class DefaultButtonModel and then check for JToggleButton member.
>>>>>>>>> 
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8182577
>>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.00/
>>>>>>>>> 
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 



From shashidhara.veerabhadraiah at oracle.com  Fri Jun 23 04:51:34 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Thu, 22 Jun 2017 21:51:34 -0700 (PDT)
Subject: <Swing Dev> [9] JDK-8165213: [TESTBUG] [PIT] consistent failure
 of a new regtest for 8163193
In-Reply-To: <DD3CF64D-A30D-4642-BA3E-8E278B0D2579@oracle.com>
References: <e5caac0a-b6b8-4b02-9a3e-ece26162d3ef@default>
 <D7F421A7-B1F6-4C06-A330-08C6B89ED052@oracle.com>
 <d1be7dfa-bda4-437b-a152-a4a0c5c9384f@default>
 <e43d4a92-c324-417a-a667-8dcc970338be@default>
 <DD3CF64D-A30D-4642-BA3E-8E278B0D2579@oracle.com>
Message-ID: <cfbf0507-c1cf-4d25-acd8-e23b050794de@default>

Hi Sergey, Thank you for the comments. Here is the updated Webrev for the comment fixes:

?

http://cr.openjdk.java.net/~aghaisas/shashi/8165213/webrev_04/

?

Thanks and regards,

Shashi

?

From: Sergey Bylokhov 
Sent: Thursday, June 22, 2017 8:22 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
Cc: swing-dev at openjdk.java.net; Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>
Subject: Re: [9] JDK-8165213: [TESTBUG] [PIT] consistent failure of a new regtest for 8163193

?

Hi, Shashi.

?

Please do not use the empty catch blocks, always rethrow an exception.

Note that you need to check the count of images returned by getResolutionVariants(), it will be one image on non-hopi screen. It seems that the ?images;? field may be local in testGradient() method.

?

Hi Sergey, I have uploaded test per our discussion and is available at:

http://cr.openjdk.java.net/~pkbalakr/shashi/8165213/webrev_03/

?

Please review and do provide the comments if any.

?

Thanks and regards,

Shashi

?

From:?Shashidhara Veerabhadraiah?
Sent:?Thursday, June 15, 2017 2:40 PM
To:?Sergey Bylokhov <HYPERLINK "mailto:sergey.bylokhov at oracle.com"sergey.bylokhov at oracle.com>
Cc:?HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Prasanta Sadhukhan <HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"prasanta.sadhukhan at oracle.com>
Subject:?RE: [9] JDK-8165213: [TESTBUG] [PIT] consistent failure of a new regtest for 8163193

?

Hi Sergey, ?The color profile on mac was generic RGB. Moreover the robot api takes the co-ordinates as input as against my implementation which takes the component as input and hence we always get the exact component image onto the buffered image. The component?s coordinates may vary depending on the location of the task bar like on mac or linux(ubuntu), hence the supplied co-ordinates may go awry. I feel that capturing the component directly onto the buffered image is better considering the cross platforms. Please let me know if you feel otherwise.

?

Below is the image comparison between the windows(top) and linux(below), snapshot that was captured onto the buffered image as a png file. I see that the linux component is slightly bigger by around 4 pixel width(approx.). I think this is the reason behind the color differences across the platforms and the same reason why mac has color differences at the same location when compared with windows one. Same location means that the program supplies a size of 300 * 300 width component and the location where we extract the color is calculated automatically based on the component size.

?

<image002.jpg>

?

I am not sure why there is a change in width. I am not sure should I continue to debug in that direction or not!!

?

This is the logical explanation that I could achieve for the color tolerance band that was used in the program. So please let me know what do you think of this.

?

Thanks and regards,

Shashi

?

-----Original Message-----
From: Sergey Bylokhov?
Sent: Thursday, June 8, 2017 1:12 PM
To: Shashidhara Veerabhadraiah <HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com>
Cc:?HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Prasanta Sadhukhan <HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"prasanta.sadhukhan at oracle.com>
Subject: Re: [9] JDK-8165213: [TESTBUG] [PIT] consistent failure of a new regtest for 8163193

?

On what color profiles the test is executed? On macOS it should be Generic RGB. Also in jdk9 the new robot api for HiDPI was added, please try it also.

If it solve the problem on Mac then I suggest to try to investigate a problem on Linux and fix it if possible, instead of tweaking the test.

?

>?

> Hi All,

> ??????????? Please review fix for JDK-8165213 where there is a consistent failure while testing for gradient color of the button.

>?

> Issue: The Robot's function to get the pixel's RGB values has an issue with its implementation and is currently getting resolved. Because of this issue, we are getting incorrect RGB values for the requested pixel and hence the test is getting failed.

>?

> Resolution\Fix: There is an alternate mechanism to capture the image to a buffer and use the buffer function to get the RGB values. This test is for HiDpi displays. In the image space, the images won't be scaled implicitly and hence they need to be applied with the scaling in the graphics space before painting on to the image buffer. This same is implemented.

> Based on the test outputs, the tolerance band for color comparison is set at 11.

>?

> Test outputs:?

> 1. On a windows system, the pixel color values exactly matches.

> 2. On a Linux system, the pixel color values vary by a maximum difference of around 6.

> 3. On a mac system, the pixel color values vary by a maximum difference of around 10.

>?

> Bug:?https://bugs.openjdk.java.net/browse/JDK-8165213

> Webrev:?http://cr.openjdk.java.net/~pkbalakr/shashi/8165213/webrev_01/

>?

> Thanks and regards,

> Shashi

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

From prasanta.sadhukhan at oracle.com  Fri Jun 23 08:19:42 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 23 Jun 2017 13:49:42 +0530
Subject: <Swing Dev> [10] RFR JDK-8173739: JPopupMenu does not disappear on
	KeyEvent
Message-ID: <91504250-9f8b-cf12-07b1-4d6db1a3c4bc@oracle.com>

Hi All,

Please review a fix for an issue where it is seen that if a popup menu 
is shown in an internal frame and
another internal frame is shown on top of 1st frame, then even though 
1st internal frame gets hidden, the popup is still visible.

Issue was popup menu was not getting cancelled when the 1st internal 
frame gets hidden/deactivated.
Poprosed fix is to send an UngrabEventwhen the 1st internal frame gets 
deactivated
  so that BasicPopupMenuUI can catch the UngrabEvent and cancel the 
popupmenu .

Bug: https://bugs.openjdk.java.net/browse/JDK-8173739
webrev: http://cr.openjdk.java.net/~psadhukhan/8173739/webrev.00/

Regards
Prasanta


From prasanta.sadhukhan at oracle.com  Fri Jun 23 08:41:54 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 23 Jun 2017 14:11:54 +0530
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <C576FC01-1498-42F1-98AF-D63CFD0E7A00@oracle.com>
References: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>
 <f27d0da1-72c1-7903-c5bb-302e4c9a64af@oracle.com>
 <c5d59af0-bf79-5e1c-2d78-8264551e6a77@oracle.com>
 <5b9b2e34-cdd8-f8a9-ea14-ccb80b8f5925@oracle.com>
 <66792efd-e60a-30d5-b5e5-87193e6c665d@oracle.com>
 <c01dcc9d-eaf4-cf4e-b5c5-2276894c9eb3@oracle.com>
 <594A8E79.8080100@oracle.com>
 <3721ab7d-d7f8-d519-5f9e-46011065bd84@oracle.com>
 <594BB687.9030505@oracle.com>
 <C576FC01-1498-42F1-98AF-D63CFD0E7A00@oracle.com>
Message-ID: <21e4231d-facd-366e-c843-e00bcd777ad7@oracle.com>

I could not find any default implementation having @implNote

http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/javax/swing/Action.java#l390
http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthIcon.java#l69

@implNote is present here but it is not for default methods
http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/java/awt/Desktop.java#l771
http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/java/awt/Taskbar.java#l40
http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#l120

Regards
Prasanta
On 6/22/2017 8:38 PM, Sergey Bylokhov wrote:
> I do not remember should we describe default implementation via @implNote or something like that?
>
>> The change to the public API for the ButtonModel interface looks OK to me now, but I am not familiar enough with the rest to review it.
>>
>> Thanks.
>>
>> -- Kevin
>>
>>
>> Prasanta Sadhukhan wrote:
>>> Modified webrev to give default implementation of the new method
>>>
>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.03/
>>>
>>> Regards
>>> Prasanta
>>> On 6/21/2017 8:49 PM, Kevin Rushforth wrote:
>>>> Two quick comments:
>>>>
>>>> 1) Is ButtonModel an interface that applications would ever implement? If so, then it is an incompatible change, since there is no default implementation of the new method.
>>>>
>>>> 2) You should add the '@since 10' javadoc tag to the new method.
>>>>
>>>> -- Kevin
>>>>
>>>>
>>>> Semyon Sadetsky wrote:
>>>>> Looks good. You will need to have CCC approval before push.
>>>>>
>>>>> --Semyon
>>>>>
>>>>>
>>>>> On 06/21/2017 07:55 AM, Prasanta Sadhukhan wrote:
>>>>>> ok. Modified webrev:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.02/
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 6/21/2017 7:45 PM, Semyon Sadetsky wrote:
>>>>>>> Hi Prasanta,
>>>>>>>
>>>>>>> Ii is not necessary to cast to DefaultButtonModel after you add getGroup() to ButtonModel:
>>>>>>>
>>>>>>> 241                 ButtonModel model = ((JToggleButton)aComponent).getModel();
>>>>>>>
>>>>>>> --Semyon
>>>>>>>
>>>>>>> On 06/20/2017 10:36 PM, Prasanta Sadhukhan wrote:
>>>>>>>> Hi Semyon,
>>>>>>>>
>>>>>>>> Yes, it seems the problem will be there in that case. Modified to have getGroup() in the interface
>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.01/
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>> On 6/20/2017 11:16 PM, Semyon Sadetsky wrote:
>>>>>>>>> Hi Prasanta,
>>>>>>>>>
>>>>>>>>> With the DefaultButtonModel we can get the same exception if a custom implementation of the ButtonModel is used.
>>>>>>>>>
>>>>>>>>> So, it is better check whether  the model is a DefaultButtonModel and skip if grouping is not supported. Or, perhaps, it is reasonable to pull up the getGroup() into the ButtonModel interface which already has setGroup().
>>>>>>>>>
>>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 06/20/2017 10:21 AM, Prasanta Sadhukhan wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> Please review a fix for an issue where a crash is reported when focus is moved with custom ButtonModel.
>>>>>>>>>> Issue was in LayoutFocusTraversalPolicy, the ButtonModel was wrongly typecasted to JToggleButton when the button model is DefaultButtonModel, resulting in ClassCastException.
>>>>>>>>>>
>>>>>>>>>> Proposed fix is to cast to super class DefaultButtonModel and then check for JToggleButton member.
>>>>>>>>>>
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8182577
>>>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.00/
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Prasanta



From sergey.bylokhov at oracle.com  Fri Jun 23 21:43:00 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 23 Jun 2017 14:43:00 -0700 (PDT)
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
Message-ID: <5b371eb0-5869-4e95-84c1-59e25eb4d949@default>

ok, +1

----- prasanta.sadhukhan at oracle.com wrote:

> I could not find any default implementation having @implNote
> 
> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/javax/swing/Action.java#l390
> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthIcon.java#l69
> 
> @implNote is present here but it is not for default methods
> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/java/awt/Desktop.java#l771
> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/java/awt/Taskbar.java#l40
> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#l120
> 
> Regards
> Prasanta
> On 6/22/2017 8:38 PM, Sergey Bylokhov wrote:
> > I do not remember should we describe default implementation via
> @implNote or something like that?
> >
> >> The change to the public API for the ButtonModel interface looks OK
> to me now, but I am not familiar enough with the rest to review it.
> >>
> >> Thanks.
> >>
> >> -- Kevin
> >>
> >>
> >> Prasanta Sadhukhan wrote:
> >>> Modified webrev to give default implementation of the new method
> >>>
> >>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.03/
> >>>
> >>> Regards
> >>> Prasanta
> >>> On 6/21/2017 8:49 PM, Kevin Rushforth wrote:
> >>>> Two quick comments:
> >>>>
> >>>> 1) Is ButtonModel an interface that applications would ever
> implement? If so, then it is an incompatible change, since there is no
> default implementation of the new method.
> >>>>
> >>>> 2) You should add the '@since 10' javadoc tag to the new method.
> >>>>
> >>>> -- Kevin
> >>>>
> >>>>
> >>>> Semyon Sadetsky wrote:
> >>>>> Looks good. You will need to have CCC approval before push.
> >>>>>
> >>>>> --Semyon
> >>>>>
> >>>>>
> >>>>> On 06/21/2017 07:55 AM, Prasanta Sadhukhan wrote:
> >>>>>> ok. Modified webrev:
> >>>>>>
> >>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.02/
> >>>>>>
> >>>>>> Regards
> >>>>>> Prasanta
> >>>>>> On 6/21/2017 7:45 PM, Semyon Sadetsky wrote:
> >>>>>>> Hi Prasanta,
> >>>>>>>
> >>>>>>> Ii is not necessary to cast to DefaultButtonModel after you
> add getGroup() to ButtonModel:
> >>>>>>>
> >>>>>>> 241                 ButtonModel model =
> ((JToggleButton)aComponent).getModel();
> >>>>>>>
> >>>>>>> --Semyon
> >>>>>>>
> >>>>>>> On 06/20/2017 10:36 PM, Prasanta Sadhukhan wrote:
> >>>>>>>> Hi Semyon,
> >>>>>>>>
> >>>>>>>> Yes, it seems the problem will be there in that case.
> Modified to have getGroup() in the interface
> >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.01/
> >>>>>>>>
> >>>>>>>> Regards
> >>>>>>>> Prasanta
> >>>>>>>> On 6/20/2017 11:16 PM, Semyon Sadetsky wrote:
> >>>>>>>>> Hi Prasanta,
> >>>>>>>>>
> >>>>>>>>> With the DefaultButtonModel we can get the same exception if
> a custom implementation of the ButtonModel is used.
> >>>>>>>>>
> >>>>>>>>> So, it is better check whether  the model is a
> DefaultButtonModel and skip if grouping is not supported. Or, perhaps,
> it is reasonable to pull up the getGroup() into the ButtonModel
> interface which already has setGroup().
> >>>>>>>>>
> >>>>>>>>> --Semyon
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 06/20/2017 10:21 AM, Prasanta Sadhukhan wrote:
> >>>>>>>>>> Hi All,
> >>>>>>>>>>
> >>>>>>>>>> Please review a fix for an issue where a crash is reported
> when focus is moved with custom ButtonModel.
> >>>>>>>>>> Issue was in LayoutFocusTraversalPolicy, the ButtonModel
> was wrongly typecasted to JToggleButton when the button model is
> DefaultButtonModel, resulting in ClassCastException.
> >>>>>>>>>>
> >>>>>>>>>> Proposed fix is to cast to super class DefaultButtonModel
> and then check for JToggleButton member.
> >>>>>>>>>>
> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8182577
> >>>>>>>>>> webrev:
> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.00/
> >>>>>>>>>>
> >>>>>>>>>> Regards
> >>>>>>>>>> Prasanta


From prasanta.sadhukhan at oracle.com  Tue Jun 27 05:11:07 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 27 Jun 2017 10:41:07 +0530
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <5b371eb0-5869-4e95-84c1-59e25eb4d949@default>
References: <5b371eb0-5869-4e95-84c1-59e25eb4d949@default>
Message-ID: <64794ded-a434-628c-8055-7bc4ced533b4@oracle.com>

It seems we need to add @implSpec for default method as suggested by CSR 
group. Modified webrev to add @implSpec in the default method.

http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.04/

Regards
Prasanta
On 6/24/2017 3:13 AM, Sergey Bylokhov wrote:
> ok, +1
>
> ----- prasanta.sadhukhan at oracle.com wrote:
>
>> I could not find any default implementation having @implNote
>>
>> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/javax/swing/Action.java#l390
>> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthIcon.java#l69
>>
>> @implNote is present here but it is not for default methods
>> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/java/awt/Desktop.java#l771
>> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/java/awt/Taskbar.java#l40
>> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#l120
>>
>> Regards
>> Prasanta
>> On 6/22/2017 8:38 PM, Sergey Bylokhov wrote:
>>> I do not remember should we describe default implementation via
>> @implNote or something like that?
>>>> The change to the public API for the ButtonModel interface looks OK
>> to me now, but I am not familiar enough with the rest to review it.
>>>> Thanks.
>>>>
>>>> -- Kevin
>>>>
>>>>
>>>> Prasanta Sadhukhan wrote:
>>>>> Modified webrev to give default implementation of the new method
>>>>>
>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.03/
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 6/21/2017 8:49 PM, Kevin Rushforth wrote:
>>>>>> Two quick comments:
>>>>>>
>>>>>> 1) Is ButtonModel an interface that applications would ever
>> implement? If so, then it is an incompatible change, since there is no
>> default implementation of the new method.
>>>>>> 2) You should add the '@since 10' javadoc tag to the new method.
>>>>>>
>>>>>> -- Kevin
>>>>>>
>>>>>>
>>>>>> Semyon Sadetsky wrote:
>>>>>>> Looks good. You will need to have CCC approval before push.
>>>>>>>
>>>>>>> --Semyon
>>>>>>>
>>>>>>>
>>>>>>> On 06/21/2017 07:55 AM, Prasanta Sadhukhan wrote:
>>>>>>>> ok. Modified webrev:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.02/
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>> On 6/21/2017 7:45 PM, Semyon Sadetsky wrote:
>>>>>>>>> Hi Prasanta,
>>>>>>>>>
>>>>>>>>> Ii is not necessary to cast to DefaultButtonModel after you
>> add getGroup() to ButtonModel:
>>>>>>>>> 241                 ButtonModel model =
>> ((JToggleButton)aComponent).getModel();
>>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>> On 06/20/2017 10:36 PM, Prasanta Sadhukhan wrote:
>>>>>>>>>> Hi Semyon,
>>>>>>>>>>
>>>>>>>>>> Yes, it seems the problem will be there in that case.
>> Modified to have getGroup() in the interface
>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.01/
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Prasanta
>>>>>>>>>> On 6/20/2017 11:16 PM, Semyon Sadetsky wrote:
>>>>>>>>>>> Hi Prasanta,
>>>>>>>>>>>
>>>>>>>>>>> With the DefaultButtonModel we can get the same exception if
>> a custom implementation of the ButtonModel is used.
>>>>>>>>>>> So, it is better check whether  the model is a
>> DefaultButtonModel and skip if grouping is not supported. Or, perhaps,
>> it is reasonable to pull up the getGroup() into the ButtonModel
>> interface which already has setGroup().
>>>>>>>>>>> --Semyon
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 06/20/2017 10:21 AM, Prasanta Sadhukhan wrote:
>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>
>>>>>>>>>>>> Please review a fix for an issue where a crash is reported
>> when focus is moved with custom ButtonModel.
>>>>>>>>>>>> Issue was in LayoutFocusTraversalPolicy, the ButtonModel
>> was wrongly typecasted to JToggleButton when the button model is
>> DefaultButtonModel, resulting in ClassCastException.
>>>>>>>>>>>> Proposed fix is to cast to super class DefaultButtonModel
>> and then check for JToggleButton member.
>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8182577
>>>>>>>>>>>> webrev:
>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.00/
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Prasanta



From shashidhara.veerabhadraiah at oracle.com  Tue Jun 27 09:25:37 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Tue, 27 Jun 2017 02:25:37 -0700 (PDT)
Subject: <Swing Dev> [10] JDK-6919529: NPE from MultiUIDefaults.getUIError
Message-ID: <fe595fe8-8483-400d-bfe3-6ade3231e272@default>

Hi All,

       Please review the fix for the JDK-6919529 where there is a NPE at MultiUIDefaults.

 

Issue: NPE at MultiUIDefaults overridden method of getUIError(String) which does not initializes the tables[0] object. There are 2 ways to initialize the tables[0] object either via the default constructor or parametric constructor. Since the method that is being overridden has the signature of getUIError(String), there is no way it can accept the UIDefault instance as an input but the code assumes that the default 'UIDefaults' instance be the one that is local to the MultiUIDefaults class and assumes that the object is fully constructed and hence defaults to the tables[] usage as the default behavior to get the UI error.

 

Resolution: The default assumption that the class instance is fully constructed is checked for it's completeness before it's usage. All the other methods including overridden methods checks the tables[] is null or not whereas only the getUIError() methods does not. This is fixed in this fix.

 

Test outputs: No NPE at the end of this fix.

 

Bug: https://bugs.openjdk.java.net/browse/JDK-6919529

Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/6919529/webrev_00/

 

Thanks and regards,

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

From ajit.ghaisas at oracle.com  Tue Jun 27 09:52:07 2017
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Tue, 27 Jun 2017 02:52:07 -0700 (PDT)
Subject: <Swing Dev> [10] JDK-6919529: NPE from
	MultiUIDefaults.getUIError
In-Reply-To: <fe595fe8-8483-400d-bfe3-6ade3231e272@default>
References: <fe595fe8-8483-400d-bfe3-6ade3231e272@default>
Message-ID: <e5e2c509-2165-45e4-88fd-f07a024685c8@default>

1. You are not checking whether 'tables' is null.

I think the condition check should be in following order :
if (tables != null && tables.length > 0 && tables[0] != null)

2.  Can you please add a regression test for this fix?

Regards,
Ajit

From: Shashidhara Veerabhadraiah 
Sent: Tuesday, June 27, 2017 2:56 PM
To: swing-dev at openjdk.java.net; Philip Race; Sergey Bylokhov
Subject: <Swing Dev> [10] JDK-6919529: NPE from MultiUIDefaults.getUIError

Hi All,
?????? Please review the fix for the JDK-6919529 where there is a NPE at MultiUIDefaults.

Issue: NPE at MultiUIDefaults overridden method of getUIError(String) which does not initializes the tables[0] object. There are 2 ways to initialize the tables[0] object either via the default constructor or parametric constructor. Since the method that is being overridden has the signature of getUIError(String), there is no way it can accept the UIDefault instance as an input but the code assumes that the default 'UIDefaults' instance be the one that is local to the MultiUIDefaults class and assumes that the object is fully constructed and hence defaults to the tables[] usage as the default behavior to get the UI error.

Resolution: The default assumption that the class instance is fully constructed is checked for it's completeness before it's usage. All the other methods including overridden methods checks the tables[] is null or not whereas only the getUIError() methods does not. This is fixed in this fix.

Test outputs: No NPE at the end of this fix.

Bug: https://bugs.openjdk.java.net/browse/JDK-6919529
Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/6919529/webrev_00/

Thanks and regards,
Shashi


From sergey.bylokhov at oracle.com  Tue Jun 27 13:28:26 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 27 Jun 2017 06:28:26 -0700 (PDT)
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
Message-ID: <b436bcb2-5aea-415a-acf4-144f347e1894@default>

Looks fine.

----- prasanta.sadhukhan at oracle.com wrote:

> It seems we need to add @implSpec for default method as suggested by
> CSR 
> group. Modified webrev to add @implSpec in the default method.
> 
> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.04/
> 
> Regards
> Prasanta
> On 6/24/2017 3:13 AM, Sergey Bylokhov wrote:
> > ok, +1
> >
> > ----- prasanta.sadhukhan at oracle.com wrote:
> >
> >> I could not find any default implementation having @implNote
> >>
> >>
> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/javax/swing/Action.java#l390
> >>
> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthIcon.java#l69
> >>
> >> @implNote is present here but it is not for default methods
> >>
> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/java/awt/Desktop.java#l771
> >>
> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/java/awt/Taskbar.java#l40
> >>
> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#l120
> >>
> >> Regards
> >> Prasanta
> >> On 6/22/2017 8:38 PM, Sergey Bylokhov wrote:
> >>> I do not remember should we describe default implementation via
> >> @implNote or something like that?
> >>>> The change to the public API for the ButtonModel interface looks
> OK
> >> to me now, but I am not familiar enough with the rest to review
> it.
> >>>> Thanks.
> >>>>
> >>>> -- Kevin
> >>>>
> >>>>
> >>>> Prasanta Sadhukhan wrote:
> >>>>> Modified webrev to give default implementation of the new
> method
> >>>>>
> >>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.03/
> >>>>>
> >>>>> Regards
> >>>>> Prasanta
> >>>>> On 6/21/2017 8:49 PM, Kevin Rushforth wrote:
> >>>>>> Two quick comments:
> >>>>>>
> >>>>>> 1) Is ButtonModel an interface that applications would ever
> >> implement? If so, then it is an incompatible change, since there is
> no
> >> default implementation of the new method.
> >>>>>> 2) You should add the '@since 10' javadoc tag to the new
> method.
> >>>>>>
> >>>>>> -- Kevin
> >>>>>>
> >>>>>>
> >>>>>> Semyon Sadetsky wrote:
> >>>>>>> Looks good. You will need to have CCC approval before push.
> >>>>>>>
> >>>>>>> --Semyon
> >>>>>>>
> >>>>>>>
> >>>>>>> On 06/21/2017 07:55 AM, Prasanta Sadhukhan wrote:
> >>>>>>>> ok. Modified webrev:
> >>>>>>>>
> >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.02/
> >>>>>>>>
> >>>>>>>> Regards
> >>>>>>>> Prasanta
> >>>>>>>> On 6/21/2017 7:45 PM, Semyon Sadetsky wrote:
> >>>>>>>>> Hi Prasanta,
> >>>>>>>>>
> >>>>>>>>> Ii is not necessary to cast to DefaultButtonModel after you
> >> add getGroup() to ButtonModel:
> >>>>>>>>> 241                 ButtonModel model =
> >> ((JToggleButton)aComponent).getModel();
> >>>>>>>>> --Semyon
> >>>>>>>>>
> >>>>>>>>> On 06/20/2017 10:36 PM, Prasanta Sadhukhan wrote:
> >>>>>>>>>> Hi Semyon,
> >>>>>>>>>>
> >>>>>>>>>> Yes, it seems the problem will be there in that case.
> >> Modified to have getGroup() in the interface
> >>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.01/
> >>>>>>>>>>
> >>>>>>>>>> Regards
> >>>>>>>>>> Prasanta
> >>>>>>>>>> On 6/20/2017 11:16 PM, Semyon Sadetsky wrote:
> >>>>>>>>>>> Hi Prasanta,
> >>>>>>>>>>>
> >>>>>>>>>>> With the DefaultButtonModel we can get the same exception
> if
> >> a custom implementation of the ButtonModel is used.
> >>>>>>>>>>> So, it is better check whether  the model is a
> >> DefaultButtonModel and skip if grouping is not supported. Or,
> perhaps,
> >> it is reasonable to pull up the getGroup() into the ButtonModel
> >> interface which already has setGroup().
> >>>>>>>>>>> --Semyon
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On 06/20/2017 10:21 AM, Prasanta Sadhukhan wrote:
> >>>>>>>>>>>> Hi All,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please review a fix for an issue where a crash is
> reported
> >> when focus is moved with custom ButtonModel.
> >>>>>>>>>>>> Issue was in LayoutFocusTraversalPolicy, the ButtonModel
> >> was wrongly typecasted to JToggleButton when the button model is
> >> DefaultButtonModel, resulting in ClassCastException.
> >>>>>>>>>>>> Proposed fix is to cast to super class
> DefaultButtonModel
> >> and then check for JToggleButton member.
> >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8182577
> >>>>>>>>>>>> webrev:
> >> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.00/
> >>>>>>>>>>>> Regards
> >>>>>>>>>>>> Prasanta


From semyon.sadetsky at oracle.com  Tue Jun 27 16:00:31 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 27 Jun 2017 09:00:31 -0700
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <64794ded-a434-628c-8055-7bc4ced533b4@oracle.com>
References: <5b371eb0-5869-4e95-84c1-59e25eb4d949@default>
 <64794ded-a434-628c-8055-7bc4ced533b4@oracle.com>
Message-ID: <98c3e1f1-f0f6-f39f-794a-eba3e85bb253@oracle.com>

+1

Please, fix formatting (some modified lines are longer then 80)

--Semyon


On 06/26/2017 10:11 PM, Prasanta Sadhukhan wrote:
> It seems we need to add @implSpec for default method as suggested by 
> CSR group. Modified webrev to add @implSpec in the default method.
>
> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.04/
>
> Regards
> Prasanta
> On 6/24/2017 3:13 AM, Sergey Bylokhov wrote:
>> ok, +1
>>
>> ----- prasanta.sadhukhan at oracle.com wrote:
>>
>>> I could not find any default implementation having @implNote
>>>
>>> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/javax/swing/Action.java#l390 
>>>
>>> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthIcon.java#l69 
>>>
>>>
>>> @implNote is present here but it is not for default methods
>>> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/java/awt/Desktop.java#l771 
>>>
>>> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/java/awt/Taskbar.java#l40 
>>>
>>> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#l120 
>>>
>>>
>>> Regards
>>> Prasanta
>>> On 6/22/2017 8:38 PM, Sergey Bylokhov wrote:
>>>> I do not remember should we describe default implementation via
>>> @implNote or something like that?
>>>>> The change to the public API for the ButtonModel interface looks OK
>>> to me now, but I am not familiar enough with the rest to review it.
>>>>> Thanks.
>>>>>
>>>>> -- Kevin
>>>>>
>>>>>
>>>>> Prasanta Sadhukhan wrote:
>>>>>> Modified webrev to give default implementation of the new method
>>>>>>
>>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.03/
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 6/21/2017 8:49 PM, Kevin Rushforth wrote:
>>>>>>> Two quick comments:
>>>>>>>
>>>>>>> 1) Is ButtonModel an interface that applications would ever
>>> implement? If so, then it is an incompatible change, since there is no
>>> default implementation of the new method.
>>>>>>> 2) You should add the '@since 10' javadoc tag to the new method.
>>>>>>>
>>>>>>> -- Kevin
>>>>>>>
>>>>>>>
>>>>>>> Semyon Sadetsky wrote:
>>>>>>>> Looks good. You will need to have CCC approval before push.
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>>
>>>>>>>> On 06/21/2017 07:55 AM, Prasanta Sadhukhan wrote:
>>>>>>>>> ok. Modified webrev:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.02/
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>> On 6/21/2017 7:45 PM, Semyon Sadetsky wrote:
>>>>>>>>>> Hi Prasanta,
>>>>>>>>>>
>>>>>>>>>> Ii is not necessary to cast to DefaultButtonModel after you
>>> add getGroup() to ButtonModel:
>>>>>>>>>> 241 ButtonModel model =
>>> ((JToggleButton)aComponent).getModel();
>>>>>>>>>> --Semyon
>>>>>>>>>>
>>>>>>>>>> On 06/20/2017 10:36 PM, Prasanta Sadhukhan wrote:
>>>>>>>>>>> Hi Semyon,
>>>>>>>>>>>
>>>>>>>>>>> Yes, it seems the problem will be there in that case.
>>> Modified to have getGroup() in the interface
>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.01/
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Prasanta
>>>>>>>>>>> On 6/20/2017 11:16 PM, Semyon Sadetsky wrote:
>>>>>>>>>>>> Hi Prasanta,
>>>>>>>>>>>>
>>>>>>>>>>>> With the DefaultButtonModel we can get the same exception if
>>> a custom implementation of the ButtonModel is used.
>>>>>>>>>>>> So, it is better check whether  the model is a
>>> DefaultButtonModel and skip if grouping is not supported. Or, perhaps,
>>> it is reasonable to pull up the getGroup() into the ButtonModel
>>> interface which already has setGroup().
>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 06/20/2017 10:21 AM, Prasanta Sadhukhan wrote:
>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please review a fix for an issue where a crash is reported
>>> when focus is moved with custom ButtonModel.
>>>>>>>>>>>>> Issue was in LayoutFocusTraversalPolicy, the ButtonModel
>>> was wrongly typecasted to JToggleButton when the button model is
>>> DefaultButtonModel, resulting in ClassCastException.
>>>>>>>>>>>>> Proposed fix is to cast to super class DefaultButtonModel
>>> and then check for JToggleButton member.
>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8182577
>>>>>>>>>>>>> webrev:
>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.00/
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>> Prasanta
>



From luke.usherwood at yahoo.co.uk  Fri Jun 23 10:07:01 2017
From: luke.usherwood at yahoo.co.uk (Luke Usherwood)
Date: Fri, 23 Jun 2017 11:07:01 +0100
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <3721ab7d-d7f8-d519-5f9e-46011065bd84@oracle.com>
References: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>
 <f27d0da1-72c1-7903-c5bb-302e4c9a64af@oracle.com>
 <c5d59af0-bf79-5e1c-2d78-8264551e6a77@oracle.com>
 <5b9b2e34-cdd8-f8a9-ea14-ccb80b8f5925@oracle.com>
 <66792efd-e60a-30d5-b5e5-87193e6c665d@oracle.com>
 <c01dcc9d-eaf4-cf4e-b5c5-2276894c9eb3@oracle.com>
 <594A8E79.8080100@oracle.com>
 <3721ab7d-d7f8-d519-5f9e-46011065bd84@oracle.com>
Message-ID: <af115b28-91c7-1236-a5c9-e64248ad3280@yahoo.co.uk>


Hi,

Sorry for the late reply - I've been travelling. As the bug reporter, 
would you mind if I gave a few passing thoughts?

On 6/20/2017 11:16 PM, Semyon Sadetsky wrote:
 > Hi Prasanta,
 >
 >So, it is better check whether  the model is a DefaultButtonModel and 
skip if grouping is not supported. Or, perhaps, it is reasonable to pull 
up the > getGroup() into the ButtonModel interface which already has 
setGroup().

On one hand, it seems the best default methods are the ones able to 
produce correct behaviours w.r.t. the other interface methods when 
retrofitted, to avoid any 'surprises'. For example if some other code 
decides to switch from DefaultButtonModel to accept any ButtonModel - 
that would happily compile but it might be easy to miss the changed 
semantics: that calling getGroup may not necessarily give back a value 
passed in to setGroup any more, and hence there's scope for a subtle 
runtime crash bug to be introduced.

Also, would the change that pulls up a new default method into 
ButtonModel be permitted if this fix were back-ported to JDK-9?

On the other hand I suppose there's no other choice if you want to patch 
this oversight in the interface design (which looks like it was wanted 
since Java 1.3!) ... so this is the trade-off you've taken. The 
likelihood of an actual crash in practice is low, and more so because 
most calling code would test for a null value anyway. So I guess on 
balance this may be reasonable.

If you do proceed with default method solution...

1)  should the javadoc for state that all implementers are expected to 
override the default implementation of getGroup(), and callers should 
always test for a null value (even when that might not be expected) to 
account for legacy implementations where the method might not be 
implemented?

2) will you change similar code in the JDK - such as found in 
JToggleButton.getGroupSelection() - to avoid the check-and-cast to 
DefaultButtonModel. This would seem required to ensure that all 
ButtonModels implementing getGroup() are treated consistently to other 
DefaultButtonModel instances.

Kind regards,
Luke









From semyon.sadetsky at oracle.com  Wed Jun 28 14:59:15 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 28 Jun 2017 07:59:15 -0700
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <af115b28-91c7-1236-a5c9-e64248ad3280@yahoo.co.uk>
References: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>
 <f27d0da1-72c1-7903-c5bb-302e4c9a64af@oracle.com>
 <c5d59af0-bf79-5e1c-2d78-8264551e6a77@oracle.com>
 <5b9b2e34-cdd8-f8a9-ea14-ccb80b8f5925@oracle.com>
 <66792efd-e60a-30d5-b5e5-87193e6c665d@oracle.com>
 <c01dcc9d-eaf4-cf4e-b5c5-2276894c9eb3@oracle.com>
 <594A8E79.8080100@oracle.com>
 <3721ab7d-d7f8-d519-5f9e-46011065bd84@oracle.com>
 <af115b28-91c7-1236-a5c9-e64248ad3280@yahoo.co.uk>
Message-ID: <a60b8600-f56d-17d7-4c04-c8fa975f36ac@oracle.com>

Hello,


On 06/23/2017 03:07 AM, Luke Usherwood wrote:
>
> Hi,
>
> Sorry for the late reply - I've been travelling. As the bug reporter, 
> would you mind if I gave a few passing thoughts?
>
> On 6/20/2017 11:16 PM, Semyon Sadetsky wrote:
> > Hi Prasanta,
> >
> >So, it is better check whether  the model is a DefaultButtonModel and 
> skip if grouping is not supported. Or, perhaps, it is reasonable to 
> pull up the > getGroup() into the ButtonModel interface which already 
> has setGroup().
>
> On one hand, it seems the best default methods are the ones able to 
> produce correct behaviours w.r.t. the other interface methods when 
> retrofitted, to avoid any 'surprises'. For example if some other code 
> decides to switch from DefaultButtonModel to accept any ButtonModel - 
> that would happily compile but it might be easy to miss the changed 
> semantics: that calling getGroup may not necessarily give back a value 
> passed in to setGroup any more, and hence there's scope for a subtle 
> runtime crash bug to be introduced.
Not sure that I fully understood this. According to the spec there is 
the only group the button belongs to, and this group should be returned 
in getGroup().
>
> Also, would the change that pulls up a new default method into 
> ButtonModel be permitted if this fix were back-ported to JDK-9?
No. JDK9 backport  should be different since no API changes are allowed 
anymore.
>
> On the other hand I suppose there's no other choice if you want to 
> patch this oversight in the interface design (which looks like it was 
> wanted since Java 1.3!) ... so this is the trade-off you've taken. The 
> likelihood of an actual crash in practice is low, and more so because 
> most calling code would test for a null value anyway. So I guess on 
> balance this may be reasonable.
>
> If you do proceed with default method solution...
>
> 1)  should the javadoc for state that all implementers are expected to 
> override the default implementation of getGroup(), and callers should 
> always test for a null value (even when that might not be expected) to 
> account for legacy implementations where the method might not be 
> implemented?
I think nothing was changed here. Before the fix there was possibility 
for setGroup(null).
>
> 2) will you change similar code in the JDK - such as found in 
> JToggleButton.getGroupSelection() - to avoid the check-and-cast to 
> DefaultButtonModel. This would seem required to ensure that all 
> ButtonModels implementing getGroup() are treated consistently to other 
> DefaultButtonModel instances.
That is good point. Group selection can be supported for custom 
ButtonGroup implementations as well.

@Prasanta: it is up to you to file another bug or do this as a part of 
the current fix.

--Semyon
>
> Kind regards,
> Luke
>
>
>
>
>
>
>



From ldubox-coding101 at yahoo.co.uk  Wed Jun 28 15:06:58 2017
From: ldubox-coding101 at yahoo.co.uk (Luke)
Date: Wed, 28 Jun 2017 17:06:58 +0200
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <af115b28-91c7-1236-a5c9-e64248ad3280@yahoo.co.uk>
References: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>
 <f27d0da1-72c1-7903-c5bb-302e4c9a64af@oracle.com>
 <c5d59af0-bf79-5e1c-2d78-8264551e6a77@oracle.com>
 <5b9b2e34-cdd8-f8a9-ea14-ccb80b8f5925@oracle.com>
 <66792efd-e60a-30d5-b5e5-87193e6c665d@oracle.com>
 <c01dcc9d-eaf4-cf4e-b5c5-2276894c9eb3@oracle.com>
 <594A8E79.8080100@oracle.com>
 <3721ab7d-d7f8-d519-5f9e-46011065bd84@oracle.com>
 <af115b28-91c7-1236-a5c9-e64248ad3280@yahoo.co.uk>
Message-ID: <fd0e6a6e-3fcc-4c5d-a94e-ea94f1328eef@yahoo.co.uk>

Hi,

A second apology is needed: I had sent this from the wrong email 
account, so it got blocked for moderation. By the time I'd realised that 
wasn't normal / something was wrong, it was past the 3-day limit to 
cancel it. The discussion had progressed by then, and I'd more or less 
convinced myself the current fix & javadoc is good.

So feel free to ignore my email.

Kind regards,
Luke

On 23/06/2017 12:07, Luke Usherwood wrote:
>
> Hi,
>
> Sorry for the late reply - I've been travelling. As the bug reporter, 
> would you mind if I gave a few passing thoughts?
>
> On 6/20/2017 11:16 PM, Semyon Sadetsky wrote:
> > Hi Prasanta,
> >
> >So, it is better check whether  the model is a DefaultButtonModel and 
> skip if grouping is not supported. Or, perhaps, it is reasonable to 
> pull up the > getGroup() into the ButtonModel interface which already 
> has setGroup().
>
> On one hand, it seems the best default methods are the ones able to 
> produce correct behaviours w.r.t. the other interface methods when 
> retrofitted, to avoid any 'surprises'. For example if some other code 
> decides to switch from DefaultButtonModel to accept any ButtonModel - 
> that would happily compile but it might be easy to miss the changed 
> semantics: that calling getGroup may not necessarily give back a value 
> passed in to setGroup any more, and hence there's scope for a subtle 
> runtime crash bug to be introduced.
>
> Also, would the change that pulls up a new default method into 
> ButtonModel be permitted if this fix were back-ported to JDK-9?
>
> On the other hand I suppose there's no other choice if you want to 
> patch this oversight in the interface design (which looks like it was 
> wanted since Java 1.3!) ... so this is the trade-off you've taken. The 
> likelihood of an actual crash in practice is low, and more so because 
> most calling code would test for a null value anyway. So I guess on 
> balance this may be reasonable.
>
> If you do proceed with default method solution...
>
> 1)  should the javadoc for state that all implementers are expected to 
> override the default implementation of getGroup(), and callers should 
> always test for a null value (even when that might not be expected) to 
> account for legacy implementations where the method might not be 
> implemented?
>
> 2) will you change similar code in the JDK - such as found in 
> JToggleButton.getGroupSelection() - to avoid the check-and-cast to 
> DefaultButtonModel. This would seem required to ensure that all 
> ButtonModels implementing getGroup() are treated consistently to other 
> DefaultButtonModel instances.
>
> Kind regards,
> Luke
>
>
>
>
>
>
>



From ldubox-coding101 at yahoo.co.uk  Wed Jun 28 15:29:33 2017
From: ldubox-coding101 at yahoo.co.uk (Luke)
Date: Wed, 28 Jun 2017 17:29:33 +0200
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <a60b8600-f56d-17d7-4c04-c8fa975f36ac@oracle.com>
References: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>
 <f27d0da1-72c1-7903-c5bb-302e4c9a64af@oracle.com>
 <c5d59af0-bf79-5e1c-2d78-8264551e6a77@oracle.com>
 <5b9b2e34-cdd8-f8a9-ea14-ccb80b8f5925@oracle.com>
 <66792efd-e60a-30d5-b5e5-87193e6c665d@oracle.com>
 <c01dcc9d-eaf4-cf4e-b5c5-2276894c9eb3@oracle.com>
 <594A8E79.8080100@oracle.com>
 <3721ab7d-d7f8-d519-5f9e-46011065bd84@oracle.com>
 <af115b28-91c7-1236-a5c9-e64248ad3280@yahoo.co.uk>
 <a60b8600-f56d-17d7-4c04-c8fa975f36ac@oracle.com>
Message-ID: <e65bc0db-4a04-919d-63a3-43fa02a2072b@yahoo.co.uk>

Hi Semyon,

On 28/06/2017 16:59, Semyon Sadetsky wrote:
>
>>
>> On one hand, it seems the best default methods are the ones able to 
>> produce correct behaviours w.r.t. the other interface methods when 
>> retrofitted, to avoid any 'surprises'. For example if some other code 
>> decides to switch from DefaultButtonModel to accept any ButtonModel - 
>> that would happily compile but it might be easy to miss the changed 
>> semantics: that calling getGroup may not necessarily give back a 
>> value passed in to setGroup any more, and hence there's scope for a 
>> subtle runtime crash bug to be introduced.
> Not sure that I fully understood this. According to the spec there is 
> the only group the button belongs to, and this group should be 
> returned in getGroup(). 

The spec can of course only apply to code written in Java 10+, legacy 
implementations ButtonModel will still return null.

So say a helper function in a shared library does an "instanceof 
DefaultButtonModel" check, and that it calls both setGroup(ButtonGroup) 
and getGroup() - and for whatever reason pulls the group back out rather 
than storing it in a local variable.

When porting that library to Java 10, a programmer might think "great, 
now I can support all ButtonModels" and drop the instanceof check.

Some other app not yet ported to Java 10 passes that utility method a 
custom ButtonModel, as it has always done. Instead of the utility 
function doing nothing with it, it now throws a NPE.

I just raised this because I know how ultra-concerned the JDK is with 
compatibility - but even by the JDK's high standards it does still seem 
like a fairly theoretical-only issue.

Is the @implSpec already sufficient warning to a programmer porting code 
to Java 10 to always deal with the null possibility? Perhaps it is.

Kind regards,
Luke



From semyon.sadetsky at oracle.com  Thu Jun 29 00:51:46 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 28 Jun 2017 17:51:46 -0700
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <e65bc0db-4a04-919d-63a3-43fa02a2072b@yahoo.co.uk>
References: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>
 <f27d0da1-72c1-7903-c5bb-302e4c9a64af@oracle.com>
 <c5d59af0-bf79-5e1c-2d78-8264551e6a77@oracle.com>
 <5b9b2e34-cdd8-f8a9-ea14-ccb80b8f5925@oracle.com>
 <66792efd-e60a-30d5-b5e5-87193e6c665d@oracle.com>
 <c01dcc9d-eaf4-cf4e-b5c5-2276894c9eb3@oracle.com>
 <594A8E79.8080100@oracle.com>
 <3721ab7d-d7f8-d519-5f9e-46011065bd84@oracle.com>
 <af115b28-91c7-1236-a5c9-e64248ad3280@yahoo.co.uk>
 <a60b8600-f56d-17d7-4c04-c8fa975f36ac@oracle.com>
 <e65bc0db-4a04-919d-63a3-43fa02a2072b@yahoo.co.uk>
Message-ID: <24752572-721b-15bc-aa65-45d999d99d63@oracle.com>

Hello Luke,

DefaultButtonModel ::getGroup has never been being required to return 
not-null. Can you clarify which new pitfall is introduced by the fix, so 
that we should specify it explicitly?

--Semyon

On 06/28/2017 08:29 AM, Luke wrote:
> Hi Semyon,
>
> On 28/06/2017 16:59, Semyon Sadetsky wrote:
>>
>>>
>>> On one hand, it seems the best default methods are the ones able to 
>>> produce correct behaviours w.r.t. the other interface methods when 
>>> retrofitted, to avoid any 'surprises'. For example if some other 
>>> code decides to switch from DefaultButtonModel to accept any 
>>> ButtonModel - that would happily compile but it might be easy to 
>>> miss the changed semantics: that calling getGroup may not 
>>> necessarily give back a value passed in to setGroup any more, and 
>>> hence there's scope for a subtle runtime crash bug to be introduced.
>> Not sure that I fully understood this. According to the spec there is 
>> the only group the button belongs to, and this group should be 
>> returned in getGroup(). 
>
> The spec can of course only apply to code written in Java 10+, legacy 
> implementations ButtonModel will still return null.
>
> So say a helper function in a shared library does an "instanceof 
> DefaultButtonModel" check, and that it calls both 
> setGroup(ButtonGroup) and getGroup() - and for whatever reason pulls 
> the group back out rather than storing it in a local variable.
>
> When porting that library to Java 10, a programmer might think "great, 
> now I can support all ButtonModels" and drop the instanceof check.
>
> Some other app not yet ported to Java 10 passes that utility method a 
> custom ButtonModel, as it has always done. Instead of the utility 
> function doing nothing with it, it now throws a NPE.
>
> I just raised this because I know how ultra-concerned the JDK is with 
> compatibility - but even by the JDK's high standards it does still 
> seem like a fairly theoretical-only issue.
>
> Is the @implSpec already sufficient warning to a programmer porting 
> code to Java 10 to always deal with the null possibility? Perhaps it is.
>
> Kind regards,
> Luke
>



From prasanta.sadhukhan at oracle.com  Thu Jun 29 05:07:42 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 29 Jun 2017 10:37:42 +0530
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <98c3e1f1-f0f6-f39f-794a-eba3e85bb253@oracle.com>
References: <5b371eb0-5869-4e95-84c1-59e25eb4d949@default>
 <64794ded-a434-628c-8055-7bc4ced533b4@oracle.com>
 <98c3e1f1-f0f6-f39f-794a-eba3e85bb253@oracle.com>
Message-ID: <a011bf5d-9f8a-9659-f4a2-db9717ce4d82@oracle.com>

Modified JToogleButton.getGroupSelection() to remove check-and-cast to 
DefautlButtonModel since we have added getGroup() to ButtonModel interface.

Also, slight modification of @implSpec as per CSR suggestion and to be 
more explicit.

http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.05/

Regards
Prasanta
On 6/27/2017 9:30 PM, Semyon Sadetsky wrote:
> +1
>
> Please, fix formatting (some modified lines are longer then 80)
>
> --Semyon
>
>
> On 06/26/2017 10:11 PM, Prasanta Sadhukhan wrote:
>> It seems we need to add @implSpec for default method as suggested by 
>> CSR group. Modified webrev to add @implSpec in the default method.
>>
>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.04/
>>
>> Regards
>> Prasanta
>> On 6/24/2017 3:13 AM, Sergey Bylokhov wrote:
>>> ok, +1
>>>
>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>
>>>> I could not find any default implementation having @implNote
>>>>
>>>> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/javax/swing/Action.java#l390 
>>>>
>>>> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthIcon.java#l69 
>>>>
>>>>
>>>> @implNote is present here but it is not for default methods
>>>> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/java/awt/Desktop.java#l771 
>>>>
>>>> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/java/awt/Taskbar.java#l40 
>>>>
>>>> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#l120 
>>>>
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 6/22/2017 8:38 PM, Sergey Bylokhov wrote:
>>>>> I do not remember should we describe default implementation via
>>>> @implNote or something like that?
>>>>>> The change to the public API for the ButtonModel interface looks OK
>>>> to me now, but I am not familiar enough with the rest to review it.
>>>>>> Thanks.
>>>>>>
>>>>>> -- Kevin
>>>>>>
>>>>>>
>>>>>> Prasanta Sadhukhan wrote:
>>>>>>> Modified webrev to give default implementation of the new method
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.03/
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 6/21/2017 8:49 PM, Kevin Rushforth wrote:
>>>>>>>> Two quick comments:
>>>>>>>>
>>>>>>>> 1) Is ButtonModel an interface that applications would ever
>>>> implement? If so, then it is an incompatible change, since there is no
>>>> default implementation of the new method.
>>>>>>>> 2) You should add the '@since 10' javadoc tag to the new method.
>>>>>>>>
>>>>>>>> -- Kevin
>>>>>>>>
>>>>>>>>
>>>>>>>> Semyon Sadetsky wrote:
>>>>>>>>> Looks good. You will need to have CCC approval before push.
>>>>>>>>>
>>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 06/21/2017 07:55 AM, Prasanta Sadhukhan wrote:
>>>>>>>>>> ok. Modified webrev:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.02/
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Prasanta
>>>>>>>>>> On 6/21/2017 7:45 PM, Semyon Sadetsky wrote:
>>>>>>>>>>> Hi Prasanta,
>>>>>>>>>>>
>>>>>>>>>>> Ii is not necessary to cast to DefaultButtonModel after you
>>>> add getGroup() to ButtonModel:
>>>>>>>>>>> 241 ButtonModel model =
>>>> ((JToggleButton)aComponent).getModel();
>>>>>>>>>>> --Semyon
>>>>>>>>>>>
>>>>>>>>>>> On 06/20/2017 10:36 PM, Prasanta Sadhukhan wrote:
>>>>>>>>>>>> Hi Semyon,
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, it seems the problem will be there in that case.
>>>> Modified to have getGroup() in the interface
>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.01/
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Prasanta
>>>>>>>>>>>> On 6/20/2017 11:16 PM, Semyon Sadetsky wrote:
>>>>>>>>>>>>> Hi Prasanta,
>>>>>>>>>>>>>
>>>>>>>>>>>>> With the DefaultButtonModel we can get the same exception if
>>>> a custom implementation of the ButtonModel is used.
>>>>>>>>>>>>> So, it is better check whether  the model is a
>>>> DefaultButtonModel and skip if grouping is not supported. Or, perhaps,
>>>> it is reasonable to pull up the getGroup() into the ButtonModel
>>>> interface which already has setGroup().
>>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 06/20/2017 10:21 AM, Prasanta Sadhukhan wrote:
>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please review a fix for an issue where a crash is reported
>>>> when focus is moved with custom ButtonModel.
>>>>>>>>>>>>>> Issue was in LayoutFocusTraversalPolicy, the ButtonModel
>>>> was wrongly typecasted to JToggleButton when the button model is
>>>> DefaultButtonModel, resulting in ClassCastException.
>>>>>>>>>>>>>> Proposed fix is to cast to super class DefaultButtonModel
>>>> and then check for JToggleButton member.
>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8182577
>>>>>>>>>>>>>> webrev:
>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.00/
>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>> Prasanta
>>
>



From prasanta.sadhukhan at oracle.com  Thu Jun 29 05:15:10 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 29 Jun 2017 10:45:10 +0530
Subject: <Swing Dev> [10] RFR JDK-8075063:Context menu closes on mouse
 scroll
In-Reply-To: <97d37ed7-6f79-b940-29e6-d982645cb844@oracle.com>
References: <8c997c2e-bf01-7957-22fa-43ac18e9ca88@oracle.com>
 <be992d75-65cb-8c55-f3e6-d3685f5fa0e0@oracle.com>
 <9c06120b-c8c0-6ee2-048b-5626f9bea344@oracle.com>
 <04fa0a6c-6302-64f9-e6c7-f5342acab758@oracle.com>
 <6f4d381f-1be5-7bca-6a7e-a17d621c85b1@oracle.com>
 <17c5c10e-d0ad-c278-a9ab-038192b34fc6@oracle.com>
 <0a7b852c-4c78-81ca-b2f6-ba1bb69736af@oracle.com>
 <f5914b14-e791-5a9a-2ad5-56a172719488@oracle.com>
 <924dd4d2-44bd-480c-72e1-193c9761c6fc@oracle.com>
 <b9fd5984-a571-150d-8162-a23876b55976@oracle.com>
 <97d37ed7-6f79-b940-29e6-d982645cb844@oracle.com>
Message-ID: <5f7e8d81-52ec-b30e-5c1f-8ab0ecfadc6a@oracle.com>

Is there anything more to be done? Can I commit this?

Regards
Prasanta
On 6/18/2017 8:01 PM, Prasanta Sadhukhan wrote:
> Fair enough suggestion, modified webrev to never ungrab for wheel event
>
> http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.02/
>
> Regards
> Prasanta
> On 6/16/2017 9:37 PM, Semyon Sadetsky wrote:
>> They are related to a wheel event happend in another java window (not 
>> outside the app).
>> My questions is if we do not ungrab on wheel event outside the app 
>> should we be consistent and do never ungrab on wheel event?
>>
>> --Semyon
>>
>>
>> On 06/16/2017 08:49 AM, Prasanta Sadhukhan wrote:
>>> I was not sure about the scenario at what condition those ungrabs 
>>> are sent, so I did not modify those. For wheel event outside our 
>>> java window was the scenario here and my modification fixed that.
>>>
>>> // According to the specification of UngrabEvent, post it
>>>    // when press occurs outside of the window and not on its owned 
>>> windows
>>>
>>> Regards
>>> Prasanta
>>> On 6/16/2017 8:57 PM, Semyon Sadetsky wrote:
>>>> In lines 2337 and 2345 ungrab is also sent. Shouldn't the button 
>>>> number be checked there as well before ungrab?
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 06/16/2017 03:22 AM, Prasanta Sadhukhan wrote:
>>>>> Yes, it is failing in linux as it posts a UngrabEvent which causes 
>>>>> the popup to be closed in BasicPopupMenuUI at eventDispatched()
>>>>>
>>>>> if(ev instanceof sun.awt.UngrabEvent) {
>>>>>                 // Popup should be canceled in case of ungrab event
>>>>>                 cancelPopupMenu( );
>>>>>                 return;
>>>>>             }
>>>>> I have modified to not post the ungrab event if mouse wheel is 
>>>>> rotated by checking if button 4 or 5 is pressed or not.
>>>>> as per 
>>>>> https://stackoverflow.com/questions/15510472/scrollwheel-event-in-x11
>>>>> and
>>>>> ftp://www.x.org/pub/X11R6.8.0/doc/mouse.4.html [Wheel button 
>>>>> events (typically buttons 4 and 5) are usually used for scrolling]
>>>>>
>>>>> http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.01/
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 6/15/2017 8:55 PM, Semyon Sadetsky wrote:
>>>>>> On 06/15/2017 08:18 AM, Prasanta Sadhukhan wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 6/15/2017 8:40 PM, Semyon Sadetsky wrote:
>>>>>>>> On 06/14/2017 09:54 PM, Prasanta Sadhukhan wrote:
>>>>>>>>> Hi Semyon,
>>>>>>>>>
>>>>>>>>> I tried on Firefox and other app. If popup or drop down menu 
>>>>>>>>> is opened, then mouse wheel rotation is not closing the 
>>>>>>>>> popups. In our case, it is closing the popups/menus.
>>>>>>>> That is true. I meant you fixed only the case when the mouse 
>>>>>>>> wheel rotation is over java windows (wheel event's source != 
>>>>>>>> null). What will be if the wheel is rotated outside java 
>>>>>>>> (source == null), or it is not the case?
>>>>>>>>
>>>>>>> It is not closing in other app (if it rotated over non-app 
>>>>>>> window) as well as in our java with my fix.
>>>>>> Did you check this on all platforms? At least on my Ubuntu it is 
>>>>>> not so.
>>>>>>
>>>>>> --Semyon
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>> On 6/14/2017 8:26 PM, Semyon Sadetsky wrote:
>>>>>>>>>> Hi Prasanta,
>>>>>>>>>>
>>>>>>>>>> I may be wrong, but it seems to me that the standard behavior 
>>>>>>>>>> is when any wheel event cannot close popups.
>>>>>>>>>>
>>>>>>>>>> --Semyon
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 06/13/2017 10:39 PM, Prasanta Sadhukhan wrote:
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> Please review a fix for an issue whereby it is seen
>>>>>>>>>>> hitting the scroll wheel by accident closes whole structure 
>>>>>>>>>>> of context menus causing it to disappear and the user has to 
>>>>>>>>>>> invoke the menu again.
>>>>>>>>>>>
>>>>>>>>>>> Issue was popupMenu is getting closed for mouse wheel 
>>>>>>>>>>> rotation if the menu is not from JComboBox.
>>>>>>>>>>> If the context menu is opened from JMenuItem, JMenu then if 
>>>>>>>>>>> the mouse wheel is rotated anywhere in frame, then it calls 
>>>>>>>>>>> cancelPopupMenu() causing it to call setVisible(false) and 
>>>>>>>>>>> so menu disappears.
>>>>>>>>>>>
>>>>>>>>>>> Proposed fix is to check if the mouse wheel rotation is done 
>>>>>>>>>>> in JMenu, JMenuItem or anywhere in frame, then if popup is 
>>>>>>>>>>> present, then do not close the popupmenu.
>>>>>>>>>>>
>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075063
>>>>>>>>>>> webrev: 
>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8075063/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Prasanta
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From srinivas.mandalika at oracle.com  Thu Jun 29 12:47:43 2017
From: srinivas.mandalika at oracle.com (Srinivas Mandalika)
Date: Thu, 29 Jun 2017 05:47:43 -0700 (PDT)
Subject: <Swing Dev> [10][TESTBUG]: Review Request for JDK-8169958 :
 javax/swing/JSpinner/5012888: Spinner value should be more than 1
In-Reply-To: <c64e6751-bdeb-4c0c-90d3-ac0f0db97fa6@default>
References: <c64e6751-bdeb-4c0c-90d3-ac0f0db97fa6@default>
Message-ID: <2867be98-ec6d-48af-b4a3-5f252514a1b7@default>

Hi All,
Please let me know if there are any other comments on this issue.

Updated webrev: http://cr.openjdk.java.net/~akolarkunnu/8169958/webrev.02/


Regards
Srinivas M

-----Original Message-----
From: Srinivas Mandalika 
Sent: Thursday, June 22, 2017 9:36 AM
To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][TESTBUG]: Review Request for JDK-8169958 : javax/swing/JSpinner/5012888: Spinner value should be more than 1

Hi Sergey,

I have added the change for the frame being disposed in both the test pass/fail conditions.
Please note that this fix is now targeted for jdk10 and has been tested on it as well.

Updated webrev: http://cr.openjdk.java.net/~akolarkunnu/8169958/webrev.02/


Regards,
Srinivas M

-----Original Message-----
From: Sergey Bylokhov 
Sent: Monday, June 19, 2017 9:03 PM
To: Srinivas Mandalika <srinivas.mandalika at oracle.com>
Cc: Ajit Ghaisas <ajit.ghaisas at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169958 : javax/swing/JSpinner/5012888: Spinner value should be more than 1

Hi, Srinivas.
You will need to dispose the frame at the end of the test(when the test fails or pass).
> 
> Hi Ajit,
> 
> Thank you for your comments. I have incorporated all your comments.  There are also a few additional changes of invoking code on EDT that I made while executing this fix to validate the test stability. 
> 
> Updated webrev: http://cr.openjdk.java.net/~akolarkunnu/8169958/webrev.01/
> 
> 
> Thanks,
> Srinivas M
> 
> -----Original Message-----
> From: Ajit Ghaisas 
> Sent: Monday, June 12, 2017 2:41 PM
> To: Srinivas Mandalika <srinivas.mandalika at oracle.com>; swing-dev at openjdk.java.net
> Subject: RE: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169958 : javax/swing/JSpinner/5012888: Spinner value should be more than 1
> 
> Hi Srinivas,
> 
>   Here are few review comments :
>   1.  Add this bug id to the @bug jtreg tag in test
>   2. Replace generic import statements with specific ones
>   3. You are calling - b.doTest(); - in a try catch block. This will catch any exception and print stack trace. 
>       I think we can remove this try-catch block - simply make a call to b.doTest(), if an exception is thrown, it is thrown out from main() and jtreg framework will catch it and mark the test as failed.
>   4. Line 63 in your file has a throw error - this can be converted to exception.
>   5. Keep four spaces indentation level
> 
> Regards,
> Ajit
> 
> 
> From: Srinivas Mandalika 
> Sent: Monday, June 12, 2017 1:51 PM
> To: swing-dev at openjdk.java.net
> Subject: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169958 : javax/swing/JSpinner/5012888: Spinner value should be more than 1
> 
> Hi All,
> 
> Please review the test bug fix for JDK-8169958 : javax/swing/JSpinner/5012888: Spinner value should be more than 1.
> 
> Issue: 
> In this bug, click & hold on arrow of JSpinner only transfers focus and does not change spinner value. This behavior is intermittently seen in the automated test but is working as expected when checked for manualy. The test was failing robot clicks out of sync with the yet to be maximized frame.
> 
> Fix: 
> Ensure the robot waits for the frame to be maximized before the clicks on the Spinner. Also ensure the main application frame is maximized explicitly.
> 
> Testing: 
> Tested the potential fix on winx64, linux  with JDK8, 9 several times with running tests individually clubbed with the previous test and the entire suite (i.e javax/swing) put to ensure that the issue is not repeated.
> 
> Bug Id:
> https://bugs.openjdk.java.net/browse/JDK-8169958
> 
> 
> WebRev Request:
> http://cr.openjdk.java.net/~akolarkunnu/8169958/webrev.00/
> 
> 
> Regards,
> Srinivas M



From srinivas.mandalika at oracle.com  Thu Jun 29 12:48:42 2017
From: srinivas.mandalika at oracle.com (Srinivas Mandalika)
Date: Thu, 29 Jun 2017 05:48:42 -0700 (PDT)
Subject: <Swing Dev> [10][TESTBUG]: Review Request for JDK-8169954 :
 JFileChooser/8021253: java.lang.RuntimeException: Default button is not
 pressed
In-Reply-To: <8114f4b2-2e95-47ab-b530-e5e27dda2443@default>
References: <8114f4b2-2e95-47ab-b530-e5e27dda2443@default>
Message-ID: <c7528537-ff25-4f35-a843-3d2fd76f042c@default>

Hi All,

?

Please let me know if there are any other comments on this issue.

?

Updated webrev: 

http://cr.openjdk.java.net/~akolarkunnu/8169954/webrev.01/

?

Regards

Srinivas M

?

?

From: Srinivas Mandalika 
Sent: Thursday, June 22, 2017 9:46 AM
To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][TESTBUG]: Review Request for JDK-8169954 : JFileChooser/8021253: java.lang.RuntimeException: Default button is not pressed

?

Hi Sergey

?

Thank you for the detailed comments.

* bug8021253.java

1.?????? Added back the waitForIdle statement.

2.?????? Reverted to Robot instead of JRobot.

?*?bug7199708.java:

3.?????? Rethrowing the exception instead of e.printStackTrace() 

4.?????? Using SwingTestHelper - I had understood wrongly that this is still a recommended approach. I have reverted to original code and added the ?filechooser?s table sort mouse action sync? fix to it, instead of doing it by using the SwigTestHelper dependencies

5.?????? Earlier, both test passed when run alone. When 7199708 is run before 8021253, 7199708 passed but then 8021253 fails as the UI opens up minimized which I believe were due to stray robot actions on to the desktop. For this the fix was put in 7199807. 8021253 code change was to make it more stable.? 

6.?????? Code formatted to wrap after 80 characters.

7.?????? The fileChooser cancelSelection is called now.

??????????????? 

Please note that this code is now targeted for jdk10 and was tested on the same as well.

?

Updated webrev: 

http://cr.openjdk.java.net/~akolarkunnu/8169954/webrev.01/

?

Thanks,

Srinivas M

From: Sergey Bylokhov 
Sent: Monday, June 19, 2017 9:31 PM
To: Srinivas Mandalika <HYPERLINK "mailto:srinivas.mandalika at oracle.com"srinivas.mandalika at oracle.com>
Cc: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [9][TESTBUG]: Review Request for JDK-8169954 : JFileChooser/8021253: java.lang.RuntimeException: Default button is not pressed

?

Hi,?Srinivas.

A few comments:

? * bug8021253.java:

? ? ? - You should not delete this lone "74 robot.waitForIdle()? because it is waits while the previous clicks are executed, w/o this line you can get a situation when defaultKeyPressed will be false because the code on EDT is in progress.

? ? ? - Do not use JRobot if it is not strictly necessary because this additional dependency will make harder to run the test standalone, w/o jtreg.

? *?bug7199708.java:

? ? ? - Always rethrow an exception instead of e.printStackTrace();

? ? ? - I am not sure that SwingTestHelper is necessary here, it was useful while java had no lamda, so the code was quite long when we executed a number or ?InvokeAndWait?, but now it should be compact.(Even in the current code it is visible that after the fix the code became longer).

? ? ? - Please confirm that the test still fails before 7199708 was fixed.

? ? ? - The new line ?85? is too long please split it to fit 80 chars per line.

? ? ? - Please add a code to dispose the frame after test execution.

?

Hi All,

?

Please review the test bug fix for JDK-8169954 : JFileChooser/8021253: java.lang.RuntimeException: Default button is not pressed.

?

Issue:

The Test under ?8021253 is opening up a filechooser iconified, causing a failure to hit Enter key on the filechooser. Test failure is intermittent and more pronounced when run along with the entire javax/swing suite.

?

Fix:

This is occurring due to synchronization issues in the previous test 7199708.?
The test for bug 7199708 checks if the filechooser can load up a large number of files without a crash. In doing so it also tries to sort the columns of the filechooser via Robot mouse move and click actions.?
Commenting out these robot actions ensured that the next test 8021253 was passing indicating that this was a problem of with synchronization of the filechooser UI sorting and disposal of filechooser and that root cause was that these were not synchronized properly.?Hence fixed the code flow using the regtesthelpers classes, to ensure that this is working correctly now.

Also ensured the filechooser of test 8021253 is not opened iconified and has focus.?

?

Testing:

Tested the potential fix on winx64, linux ?with JDK8, 9 several times with running tests individually clubbed with the previous test and the entire suite (i.e javax/swing) put to ensure that the issue is not repeated.

?

Bug Id:

https://bugs.openjdk.java.net/browse/JDK-8169954

?

WebRev Request:

http://cr.openjdk.java.net/~akolarkunnu/8169954/webrev.00/

?

?

Regards,

Srinivas M

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

From ldubox-coding101 at yahoo.co.uk  Thu Jun 29 12:50:36 2017
From: ldubox-coding101 at yahoo.co.uk (Luke)
Date: Thu, 29 Jun 2017 14:50:36 +0200
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <24752572-721b-15bc-aa65-45d999d99d63@oracle.com>
References: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>
 <f27d0da1-72c1-7903-c5bb-302e4c9a64af@oracle.com>
 <c5d59af0-bf79-5e1c-2d78-8264551e6a77@oracle.com>
 <5b9b2e34-cdd8-f8a9-ea14-ccb80b8f5925@oracle.com>
 <66792efd-e60a-30d5-b5e5-87193e6c665d@oracle.com>
 <c01dcc9d-eaf4-cf4e-b5c5-2276894c9eb3@oracle.com>
 <594A8E79.8080100@oracle.com>
 <3721ab7d-d7f8-d519-5f9e-46011065bd84@oracle.com>
 <af115b28-91c7-1236-a5c9-e64248ad3280@yahoo.co.uk>
 <a60b8600-f56d-17d7-4c04-c8fa975f36ac@oracle.com>
 <e65bc0db-4a04-919d-63a3-43fa02a2072b@yahoo.co.uk>
 <24752572-721b-15bc-aa65-45d999d99d63@oracle.com>
Message-ID: <62e284f7-f66e-3a07-6af6-d9c299e2ad61@yahoo.co.uk>

Hi Semyon,

On 29/06/2017 02:51, Semyon Sadetsky wrote:
> Hello Luke,
>
> DefaultButtonModel ::getGroup has never been being required to return 
> not-null. Can you clarify which new pitfall is introduced by the fix, 
> so that we should specify it explicitly?
>
> --Semyon

Code using a ButtonModel might assume that after calling setGroup that 
the same instance would thereafter be returned by getGroup. However any 
code taking advantage of getGroup having being "pulled up" into 
ButtonModel should not make that natural assumption, as a legacy 
ButtonModel may still return null.

So this forms part of the method's contract for the caller too. If the 
caller is expected to read and understand the implications of the 
implSpec, then what is written already may be sufficient. I guess that's 
the question.

How about these changes (based on webrev.05)?

      /**
       * Returns the group that the button belongs to.
       * Normally used with radio buttons, which are mutually
       * exclusive within their group.
       *
       * @implSpec The default implementation of this method returns {@code null}.
-     * Subclasses should return the group set by setGroup() to avoid NPE.
+     * Subclasses should return the group set by setGroup().
       *
-     * @return the <code>ButtonGroup</code> that the button belongs to
+     * @return the <code>ButtonGroup</code> that the button belongs to, if any.
+     * Null may also be returned where a legacy ButtonGroup inherits the
+     * default implementation.
       * @since 10
       */
      default ButtonGroup getGroup() {
          return null;
      }

I think this makes the contract more explicit.

Kind regards,
Luke

> On 06/28/2017 08:29 AM, Luke wrote:
>> Hi Semyon,
>>
>> On 28/06/2017 16:59, Semyon Sadetsky wrote:
>>>
>>>>
>>>> On one hand, it seems the best default methods are the ones able to 
>>>> produce correct behaviours w.r.t. the other interface methods when 
>>>> retrofitted, to avoid any 'surprises'. For example if some other 
>>>> code decides to switch from DefaultButtonModel to accept any 
>>>> ButtonModel - that would happily compile but it might be easy to 
>>>> miss the changed semantics: that calling getGroup may not 
>>>> necessarily give back a value passed in to setGroup any more, and 
>>>> hence there's scope for a subtle runtime crash bug to be introduced.
>>> Not sure that I fully understood this. According to the spec there 
>>> is the only group the button belongs to, and this group should be 
>>> returned in getGroup(). 
>>
>> The spec can of course only apply to code written in Java 10+, legacy 
>> implementations ButtonModel will still return null.
>>
>> So say a helper function in a shared library does an "instanceof 
>> DefaultButtonModel" check, and that it calls both 
>> setGroup(ButtonGroup) and getGroup() - and for whatever reason pulls 
>> the group back out rather than storing it in a local variable.
>>
>> When porting that library to Java 10, a programmer might think 
>> "great, now I can support all ButtonModels" and drop the instanceof 
>> check.
>>
>> Some other app not yet ported to Java 10 passes that utility method a 
>> custom ButtonModel, as it has always done. Instead of the utility 
>> function doing nothing with it, it now throws a NPE.
>>
>> I just raised this because I know how ultra-concerned the JDK is with 
>> compatibility - but even by the JDK's high standards it does still 
>> seem like a fairly theoretical-only issue.
>>
>> Is the @implSpec already sufficient warning to a programmer porting 
>> code to Java 10 to always deal with the null possibility? Perhaps it is.
>>
>> Kind regards,
>> Luke
>>
>



From semyon.sadetsky at oracle.com  Thu Jun 29 15:16:50 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 29 Jun 2017 08:16:50 -0700
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <62e284f7-f66e-3a07-6af6-d9c299e2ad61@yahoo.co.uk>
References: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>
 <f27d0da1-72c1-7903-c5bb-302e4c9a64af@oracle.com>
 <c5d59af0-bf79-5e1c-2d78-8264551e6a77@oracle.com>
 <5b9b2e34-cdd8-f8a9-ea14-ccb80b8f5925@oracle.com>
 <66792efd-e60a-30d5-b5e5-87193e6c665d@oracle.com>
 <c01dcc9d-eaf4-cf4e-b5c5-2276894c9eb3@oracle.com>
 <594A8E79.8080100@oracle.com>
 <3721ab7d-d7f8-d519-5f9e-46011065bd84@oracle.com>
 <af115b28-91c7-1236-a5c9-e64248ad3280@yahoo.co.uk>
 <a60b8600-f56d-17d7-4c04-c8fa975f36ac@oracle.com>
 <e65bc0db-4a04-919d-63a3-43fa02a2072b@yahoo.co.uk>
 <24752572-721b-15bc-aa65-45d999d99d63@oracle.com>
 <62e284f7-f66e-3a07-6af6-d9c299e2ad61@yahoo.co.uk>
Message-ID: <1328a171-5b4b-80de-ccb7-39786f9ed479@oracle.com>

Hi Luke,

I think a newly created method that accepts the ButtonModel instance 
argument and calls setGroup/getGroup on it should always check the 
getGroup() return for null before using it just from general 
consideration because the real implementation is unknown. Your 
suggestion to highlight the legacy implementation as a possible source 
for NPE seems unreasonable in that it suggests an assumption that after 
ButtonModel implementations cannot return null from getGroup(), which is 
not true.

--Semyon

On 06/29/2017 05:50 AM, Luke wrote:

> Hi Semyon,
>
> On 29/06/2017 02:51, Semyon Sadetsky wrote:
>> Hello Luke,
>>
>> DefaultButtonModel ::getGroup has never been being required to return 
>> not-null. Can you clarify which new pitfall is introduced by the fix, 
>> so that we should specify it explicitly?
>>
>> --Semyon
>
> Code using a ButtonModel might assume that after calling setGroup that 
> the same instance would thereafter be returned by getGroup. However 
> any code taking advantage of getGroup having being "pulled up" into 
> ButtonModel should not make that natural assumption, as a legacy 
> ButtonModel may still return null.
>
> So this forms part of the method's contract for the caller too. If the 
> caller is expected to read and understand the implications of the 
> implSpec, then what is written already may be sufficient. I guess 
> that's the question.
>
> How about these changes (based on webrev.05)?
>
>      /**
>       * Returns the group that the button belongs to.
>       * Normally used with radio buttons, which are mutually
>       * exclusive within their group.
>       *
>       * @implSpec The default implementation of this method returns 
> {@code null}.
> -     * Subclasses should return the group set by setGroup() to avoid 
> NPE.
> +     * Subclasses should return the group set by setGroup().
>       *
> -     * @return the <code>ButtonGroup</code> that the button belongs to
> +     * @return the <code>ButtonGroup</code> that the button belongs 
> to, if any.
> +     * Null may also be returned where a legacy ButtonGroup inherits the
> +     * default implementation.
>       * @since 10
>       */
>      default ButtonGroup getGroup() {
>          return null;
>      }
>
> I think this makes the contract more explicit.
>
> Kind regards,
> Luke
>
>> On 06/28/2017 08:29 AM, Luke wrote:
>>> Hi Semyon,
>>>
>>> On 28/06/2017 16:59, Semyon Sadetsky wrote:
>>>>
>>>>>
>>>>> On one hand, it seems the best default methods are the ones able 
>>>>> to produce correct behaviours w.r.t. the other interface methods 
>>>>> when retrofitted, to avoid any 'surprises'. For example if some 
>>>>> other code decides to switch from DefaultButtonModel to accept any 
>>>>> ButtonModel - that would happily compile but it might be easy to 
>>>>> miss the changed semantics: that calling getGroup may not 
>>>>> necessarily give back a value passed in to setGroup any more, and 
>>>>> hence there's scope for a subtle runtime crash bug to be introduced.
>>>> Not sure that I fully understood this. According to the spec there 
>>>> is the only group the button belongs to, and this group should be 
>>>> returned in getGroup(). 
>>>
>>> The spec can of course only apply to code written in Java 10+, 
>>> legacy implementations ButtonModel will still return null.
>>>
>>> So say a helper function in a shared library does an "instanceof 
>>> DefaultButtonModel" check, and that it calls both 
>>> setGroup(ButtonGroup) and getGroup() - and for whatever reason pulls 
>>> the group back out rather than storing it in a local variable.
>>>
>>> When porting that library to Java 10, a programmer might think 
>>> "great, now I can support all ButtonModels" and drop the instanceof 
>>> check.
>>>
>>> Some other app not yet ported to Java 10 passes that utility method 
>>> a custom ButtonModel, as it has always done. Instead of the utility 
>>> function doing nothing with it, it now throws a NPE.
>>>
>>> I just raised this because I know how ultra-concerned the JDK is 
>>> with compatibility - but even by the JDK's high standards it does 
>>> still seem like a fairly theoretical-only issue.
>>>
>>> Is the @implSpec already sufficient warning to a programmer porting 
>>> code to Java 10 to always deal with the null possibility? Perhaps it 
>>> is.
>>>
>>> Kind regards,
>>> Luke
>>>
>>
>



From alexander.zvegintsev at oracle.com  Fri Jun 30 04:08:45 2017
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Fri, 30 Jun 2017 09:38:45 +0530
Subject: <Swing Dev> [10] RFR JDK-8182402:Tooltip for Desktop button is
 in English when non-English locale is set
In-Reply-To: <f4419133-0aa0-0b99-c733-a1586cd04533@oracle.com>
References: <f4419133-0aa0-0b99-c733-a1586cd04533@oracle.com>
Message-ID: <e253e635-494a-b686-adef-a4aa303cb00c@oracle.com>

Looks good to me.

Thanks,
Alexander.

On 21/06/2017 14:13, Prasanta Sadhukhan wrote:
> Hi All,
>
> Please review a fix for an issue where tooltip for "Home" or Desktop 
> button is in English even though locale is non-English.
> This is because even though i18n properties has
> FileChooser.homeFolderToolTip.textAndMnemonic=Home
> in English, Dutch,chinese etc
> ./share/classes/com/sun/java/swing/plaf/windows/resources/windows.properties
> share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties
>
> in MetalFileChooserUI.java and SynthFileChooserUIImpl.java, it is 
> replaced by "Desktop" text which do not have corresponding i18N resources.
> There is a corresponding bug JDK-8179346 
> <https://bugs.openjdk.java.net/browse/JDK-8179346> which says pressing 
> "home" button should not go to Desktop so probably desktop is not 
> correct name for home folder.
>
> Proposed fix is to use "Home" tooltip text so that it can be displayed 
> in different locale.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8182402
> webrev: http://cr.openjdk.java.net/~psadhukhan/8182402/webrev.00/
>
> Regards
> Prasanta

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

From prasanta.sadhukhan at oracle.com  Fri Jun 30 04:14:47 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 30 Jun 2017 09:44:47 +0530
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <a011bf5d-9f8a-9659-f4a2-db9717ce4d82@oracle.com>
References: <5b371eb0-5869-4e95-84c1-59e25eb4d949@default>
 <64794ded-a434-628c-8055-7bc4ced533b4@oracle.com>
 <98c3e1f1-f0f6-f39f-794a-eba3e85bb253@oracle.com>
 <a011bf5d-9f8a-9659-f4a2-db9717ce4d82@oracle.com>
Message-ID: <a8d81d8d-af8a-d062-5b98-e5f944a178b7@oracle.com>

Since CSR is approved, and if there is no objection to this, I will 
commit this fix today.

Regards
Prasanta
On 6/29/2017 10:37 AM, Prasanta Sadhukhan wrote:
> Modified JToogleButton.getGroupSelection() to remove check-and-cast to 
> DefautlButtonModel since we have added getGroup() to ButtonModel 
> interface.
>
> Also, slight modification of @implSpec as per CSR suggestion and to be 
> more explicit.
>
> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.05/
>
> Regards
> Prasanta
> On 6/27/2017 9:30 PM, Semyon Sadetsky wrote:
>> +1
>>
>> Please, fix formatting (some modified lines are longer then 80)
>>
>> --Semyon
>>
>>
>> On 06/26/2017 10:11 PM, Prasanta Sadhukhan wrote:
>>> It seems we need to add @implSpec for default method as suggested by 
>>> CSR group. Modified webrev to add @implSpec in the default method.
>>>
>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.04/
>>>
>>> Regards
>>> Prasanta
>>> On 6/24/2017 3:13 AM, Sergey Bylokhov wrote:
>>>> ok, +1
>>>>
>>>> ----- prasanta.sadhukhan at oracle.com wrote:
>>>>
>>>>> I could not find any default implementation having @implNote
>>>>>
>>>>> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/javax/swing/Action.java#l390 
>>>>>
>>>>> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthIcon.java#l69 
>>>>>
>>>>>
>>>>> @implNote is present here but it is not for default methods
>>>>> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/java/awt/Desktop.java#l771 
>>>>>
>>>>> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/java/awt/Taskbar.java#l40 
>>>>>
>>>>> http://hg.openjdk.java.net/jdk10/client/jdk/file/4cdd5d954479/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#l120 
>>>>>
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 6/22/2017 8:38 PM, Sergey Bylokhov wrote:
>>>>>> I do not remember should we describe default implementation via
>>>>> @implNote or something like that?
>>>>>>> The change to the public API for the ButtonModel interface looks OK
>>>>> to me now, but I am not familiar enough with the rest to review it.
>>>>>>> Thanks.
>>>>>>>
>>>>>>> -- Kevin
>>>>>>>
>>>>>>>
>>>>>>> Prasanta Sadhukhan wrote:
>>>>>>>> Modified webrev to give default implementation of the new method
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.03/
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>> On 6/21/2017 8:49 PM, Kevin Rushforth wrote:
>>>>>>>>> Two quick comments:
>>>>>>>>>
>>>>>>>>> 1) Is ButtonModel an interface that applications would ever
>>>>> implement? If so, then it is an incompatible change, since there 
>>>>> is no
>>>>> default implementation of the new method.
>>>>>>>>> 2) You should add the '@since 10' javadoc tag to the new method.
>>>>>>>>>
>>>>>>>>> -- Kevin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Semyon Sadetsky wrote:
>>>>>>>>>> Looks good. You will need to have CCC approval before push.
>>>>>>>>>>
>>>>>>>>>> --Semyon
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 06/21/2017 07:55 AM, Prasanta Sadhukhan wrote:
>>>>>>>>>>> ok. Modified webrev:
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.02/
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Prasanta
>>>>>>>>>>> On 6/21/2017 7:45 PM, Semyon Sadetsky wrote:
>>>>>>>>>>>> Hi Prasanta,
>>>>>>>>>>>>
>>>>>>>>>>>> Ii is not necessary to cast to DefaultButtonModel after you
>>>>> add getGroup() to ButtonModel:
>>>>>>>>>>>> 241 ButtonModel model =
>>>>> ((JToggleButton)aComponent).getModel();
>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>
>>>>>>>>>>>> On 06/20/2017 10:36 PM, Prasanta Sadhukhan wrote:
>>>>>>>>>>>>> Hi Semyon,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, it seems the problem will be there in that case.
>>>>> Modified to have getGroup() in the interface
>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.01/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>> Prasanta
>>>>>>>>>>>>> On 6/20/2017 11:16 PM, Semyon Sadetsky wrote:
>>>>>>>>>>>>>> Hi Prasanta,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> With the DefaultButtonModel we can get the same exception if
>>>>> a custom implementation of the ButtonModel is used.
>>>>>>>>>>>>>> So, it is better check whether  the model is a
>>>>> DefaultButtonModel and skip if grouping is not supported. Or, 
>>>>> perhaps,
>>>>> it is reasonable to pull up the getGroup() into the ButtonModel
>>>>> interface which already has setGroup().
>>>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 06/20/2017 10:21 AM, Prasanta Sadhukhan wrote:
>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please review a fix for an issue where a crash is reported
>>>>> when focus is moved with custom ButtonModel.
>>>>>>>>>>>>>>> Issue was in LayoutFocusTraversalPolicy, the ButtonModel
>>>>> was wrongly typecasted to JToggleButton when the button model is
>>>>> DefaultButtonModel, resulting in ClassCastException.
>>>>>>>>>>>>>>> Proposed fix is to cast to super class DefaultButtonModel
>>>>> and then check for JToggleButton member.
>>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8182577
>>>>>>>>>>>>>>> webrev:
>>>>> http://cr.openjdk.java.net/~psadhukhan/8182577/webrev.00/
>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>> Prasanta
>>>
>>
>



From ldubox-coding101 at yahoo.co.uk  Fri Jun 30 09:52:19 2017
From: ldubox-coding101 at yahoo.co.uk (Luke)
Date: Fri, 30 Jun 2017 11:52:19 +0200
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <1328a171-5b4b-80de-ccb7-39786f9ed479@oracle.com>
References: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>
 <f27d0da1-72c1-7903-c5bb-302e4c9a64af@oracle.com>
 <c5d59af0-bf79-5e1c-2d78-8264551e6a77@oracle.com>
 <5b9b2e34-cdd8-f8a9-ea14-ccb80b8f5925@oracle.com>
 <66792efd-e60a-30d5-b5e5-87193e6c665d@oracle.com>
 <c01dcc9d-eaf4-cf4e-b5c5-2276894c9eb3@oracle.com>
 <594A8E79.8080100@oracle.com>
 <3721ab7d-d7f8-d519-5f9e-46011065bd84@oracle.com>
 <af115b28-91c7-1236-a5c9-e64248ad3280@yahoo.co.uk>
 <a60b8600-f56d-17d7-4c04-c8fa975f36ac@oracle.com>
 <e65bc0db-4a04-919d-63a3-43fa02a2072b@yahoo.co.uk>
 <24752572-721b-15bc-aa65-45d999d99d63@oracle.com>
 <62e284f7-f66e-3a07-6af6-d9c299e2ad61@yahoo.co.uk>
 <1328a171-5b4b-80de-ccb7-39786f9ed479@oracle.com>
Message-ID: <d0c40a0f-e109-5956-a8de-49c0195c4e43@yahoo.co.uk>

Hi Semyon,

On 29/06/2017 17:16, Semyon Sadetsky wrote:
> Hi Luke,
>
> I think a newly created method that accepts the ButtonModel instance 
> argument and calls setGroup/getGroup on it should always check the 
> getGroup() return for null before using it just from general 
> consideration because the real implementation is unknown.

I agree, callers should & hopefully will.

> Your suggestion to highlight the legacy implementation as a possible 
> source for NPE seems unreasonable in that it suggests an assumption 
> that after ButtonModel implementations cannot return null from 
> getGroup(), which is not true.

I'm not sure I follow this sentence. My Javadoc suggestion was aiming to 
make the *two* situations in which a null is returned more explicit, 
since null has two meanings now. Since it does have real implications 
for the caller (don't assume standard set/get behaviour) I felt it 
should be mentioned in the API Specification[1] section of the Javadoc 
to draw attention to it.

Generalising to a rule: a default method pulled-up with a stub 
implementation will always _broaden_ the original contract. Even if all 
known sub-classes _refine_ it back to the original contract there is now 
a possibility of unknown sub-classes, which callers will now need to 
take into consideration.

I'm not sure what "standard practice" is for documenting such corner 
cases arising from interface evolution. Does @implSpec form part of the 
API specification for callers too?

Anyway, I feel I'm nit-picking, since (for this specific interface) it 
is very unlikely to cause real-world bugs. Don't take this email as an 
objection to proceeding "as it is", I just wanted to clarify any points 
that might have been misunderstood.

-- Luke

[1]  http://openjdk.java.net/jeps/8068562


> On 06/29/2017 05:50 AM, Luke wrote:
>
>> Hi Semyon,
>>
>> On 29/06/2017 02:51, Semyon Sadetsky wrote:
>>> Hello Luke,
>>>
>>> DefaultButtonModel ::getGroup has never been being required to 
>>> return not-null. Can you clarify which new pitfall is introduced by 
>>> the fix, so that we should specify it explicitly?
>>>
>>> --Semyon
>>
>> Code using a ButtonModel might assume that after calling setGroup 
>> that the same instance would thereafter be returned by getGroup. 
>> However any code taking advantage of getGroup having being "pulled 
>> up" into ButtonModel should not make that natural assumption, as a 
>> legacy ButtonModel may still return null.
>>
>> So this forms part of the method's contract for the caller too. If 
>> the caller is expected to read and understand the implications of the 
>> implSpec, then what is written already may be sufficient. I guess 
>> that's the question.
>>
>> How about these changes (based on webrev.05)?
>>
>>      /**
>>       * Returns the group that the button belongs to.
>>       * Normally used with radio buttons, which are mutually
>>       * exclusive within their group.
>>       *
>>       * @implSpec The default implementation of this method returns 
>> {@code null}.
>> -     * Subclasses should return the group set by setGroup() to avoid 
>> NPE.
>> +     * Subclasses should return the group set by setGroup().
>>       *
>> -     * @return the <code>ButtonGroup</code> that the button belongs to
>> +     * @return the <code>ButtonGroup</code> that the button belongs 
>> to, if any.
>> +     * Null may also be returned where a legacy ButtonGroup inherits 
>> the
>> +     * default implementation.
>>       * @since 10
>>       */
>>      default ButtonGroup getGroup() {
>>          return null;
>>      }
>>
>> I think this makes the contract more explicit.
>>
>> Kind regards,
>> Luke 



From semyon.sadetsky at oracle.com  Fri Jun 30 15:45:23 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 30 Jun 2017 08:45:23 -0700
Subject: <Swing Dev> [10] RFR: 8182577: Crash when Tab key moves focus
 to a JCheckbox with a custom ButtonModel
In-Reply-To: <d0c40a0f-e109-5956-a8de-49c0195c4e43@yahoo.co.uk>
References: <5da97ee0-0639-40d7-8da7-33dcb1f2c189@oracle.com>
 <f27d0da1-72c1-7903-c5bb-302e4c9a64af@oracle.com>
 <c5d59af0-bf79-5e1c-2d78-8264551e6a77@oracle.com>
 <5b9b2e34-cdd8-f8a9-ea14-ccb80b8f5925@oracle.com>
 <66792efd-e60a-30d5-b5e5-87193e6c665d@oracle.com>
 <c01dcc9d-eaf4-cf4e-b5c5-2276894c9eb3@oracle.com>
 <594A8E79.8080100@oracle.com>
 <3721ab7d-d7f8-d519-5f9e-46011065bd84@oracle.com>
 <af115b28-91c7-1236-a5c9-e64248ad3280@yahoo.co.uk>
 <a60b8600-f56d-17d7-4c04-c8fa975f36ac@oracle.com>
 <e65bc0db-4a04-919d-63a3-43fa02a2072b@yahoo.co.uk>
 <24752572-721b-15bc-aa65-45d999d99d63@oracle.com>
 <62e284f7-f66e-3a07-6af6-d9c299e2ad61@yahoo.co.uk>
 <1328a171-5b4b-80de-ccb7-39786f9ed479@oracle.com>
 <d0c40a0f-e109-5956-a8de-49c0195c4e43@yahoo.co.uk>
Message-ID: <4843befd-cb0e-c7ce-bf94-53021c54056d@oracle.com>

Hi Like,

You suggested the next change for the spec:

-     * @return the <code>ButtonGroup</code> that the button belongs to

+     * @return the <code>ButtonGroup</code> that the button belongs to, 
if any.
+     * Null may also be returned where a legacy ButtonGroup inherits the
+     * default implementation.

In my opinion highlighting legacy implementation here is not justified. 
Such a note is more suitable for the release notes.

I would change the spec to

+    * @return the <code>ButtonGroup</code> that the button belongs to 
or null otherwise

Because if the getter returns null the button doesn't actually belong to 
any group, and this is true for both legacy and after implementations.
But the current spec looks ok to me as well.

--Semyon

On 06/30/2017 02:52 AM, Luke wrote:
> Hi Semyon,
>
> On 29/06/2017 17:16, Semyon Sadetsky wrote:
>> Hi Luke,
>>
>> I think a newly created method that accepts the ButtonModel instance 
>> argument and calls setGroup/getGroup on it should always check the 
>> getGroup() return for null before using it just from general 
>> consideration because the real implementation is unknown.
>
> I agree, callers should & hopefully will.
>
>> Your suggestion to highlight the legacy implementation as a possible 
>> source for NPE seems unreasonable in that it suggests an assumption 
>> that after ButtonModel implementations cannot return null from 
>> getGroup(), which is not true.
>
> I'm not sure I follow this sentence. My Javadoc suggestion was aiming 
> to make the *two* situations in which a null is returned more 
> explicit, since null has two meanings now. Since it does have real 
> implications for the caller (don't assume standard set/get behaviour) 
> I felt it should be mentioned in the API Specification[1] section of 
> the Javadoc to draw attention to it.

You suggested the next change for the spec:

-     * @return the <code>ButtonGroup</code> that the button belongs to

+     * @return the <code>ButtonGroup</code> that the button belongs to, 
if any.
+     * Null may also be returned where a legacy ButtonGroup inherits the
+     * default implementation.

In my opinion highlighting legacy implementation here is not justified. 
Such a note is more suitable for the release notes.

Instead I would change the spec to

+    * @return the <code>ButtonGroup</code> that the button belongs to 
or null otherwise

Because if the getter returns null the button doesn't actually belong to 
any group, and this is true for both legacy and after implementations.
But the current spec looks ok to me as well.

What do you mean under standard set/get behavior? Do you mean that 
getter should always return the value provided with the previous setter 
call?

>
> Generalising to a rule: a default method pulled-up with a stub 
> implementation will always _broaden_ the original contract. Even if 
> all known sub-classes _refine_ it back to the original contract there 
> is now a possibility of unknown sub-classes, which callers will now 
> need to take into consideration.
It doesn't seem mandatory, since the caller should be aware about the 
method to call it.
>
> I'm not sure what "standard practice" is for documenting such corner 
> cases arising from interface evolution. Does @implSpec form part of 
> the API specification for callers too?
I don't see a method caller mentioned in the @implSpec description. I 
think this is more related to class usage.

--Semyon
>
> Anyway, I feel I'm nit-picking, since (for this specific interface) it 
> is very unlikely to cause real-world bugs. Don't take this email as an 
> objection to proceeding "as it is", I just wanted to clarify any 
> points that might have been misunderstood.
>
> -- Luke
>
> [1]  http://openjdk.java.net/jeps/8068562
>
>
>> On 06/29/2017 05:50 AM, Luke wrote:
>>
>>> Hi Semyon,
>>>
>>> On 29/06/2017 02:51, Semyon Sadetsky wrote:
>>>> Hello Luke,
>>>>
>>>> DefaultButtonModel ::getGroup has never been being required to 
>>>> return not-null. Can you clarify which new pitfall is introduced by 
>>>> the fix, so that we should specify it explicitly?
>>>>
>>>> --Semyon
>>>
>>> Code using a ButtonModel might assume that after calling setGroup 
>>> that the same instance would thereafter be returned by getGroup. 
>>> However any code taking advantage of getGroup having being "pulled 
>>> up" into ButtonModel should not make that natural assumption, as a 
>>> legacy ButtonModel may still return null.
>>>
>>> So this forms part of the method's contract for the caller too. If 
>>> the caller is expected to read and understand the implications of 
>>> the implSpec, then what is written already may be sufficient. I 
>>> guess that's the question.
>>>
>>> How about these changes (based on webrev.05)?
>>>
>>>      /**
>>>       * Returns the group that the button belongs to.
>>>       * Normally used with radio buttons, which are mutually
>>>       * exclusive within their group.
>>>       *
>>>       * @implSpec The default implementation of this method returns 
>>> {@code null}.
>>> -     * Subclasses should return the group set by setGroup() to 
>>> avoid NPE.
>>> +     * Subclasses should return the group set by setGroup().
>>>       *
>>> -     * @return the <code>ButtonGroup</code> that the button belongs to
>>> +     * @return the <code>ButtonGroup</code> that the button belongs 
>>> to, if any.
>>> +     * Null may also be returned where a legacy ButtonGroup 
>>> inherits the
>>> +     * default implementation.
>>>       * @since 10
>>>       */
>>>      default ButtonGroup getGroup() {
>>>          return null;
>>>      }
>>>
>>> I think this makes the contract more explicit.
>>>
>>> Kind regards,
>>> Luke 
>