Re: RFR: JDK-8273312 : [TESTBUG] sanity/client/SwingSet/src/ButtonDemoScreenshotTest.java fails intermittently on Windows OS.

[Pankaj Bansal]

On Mon, 6 Sep 2021 11:35:05 GMT, Amresh Sahu 
 wrote:

> Problem: In Windows look and feel, Button(in test case ui) starts animating 
> to show the selection and test case captures the animated button image to do 
> the comparisons with initial button image and this comparison fails with 
> Timeout Exception exception. 
> 
> Solution: TestHelper class provides the list of look and feel. One more 
> method added to this class to exclude the windows look and feel.
> 
> This test has been tested  20 times on mach5 and It is passing.

Is there a specific reason why this comparison only times out for windows L 
and the test passes on other L I mean should not a bug be filled to 
investigate the reason for the same instead of excluding the Windows L from 
the tested L

-

PR: https://git.openjdk.java.net/jdk/pull/5380

Re: RFR: 8272148: JDesktopPane:getComponentCount() returns one extra than expected with GTKLookAndFeel [v2]

[Pankaj Bansal]

On Wed, 25 Aug 2021 10:39:42 GMT, Pankaj Bansal  wrote:

>> A container may include few default components as children, which are added 
>> to it during creation. Due to this, calling function getChildrenCount on a 
>> new created instance may return non zero value. This behaviour may vary 
>> according to L also, as some L may add some default components to a 
>> container, but other L may choose not to do so.
>> 
>> The current bugs reports that this behaviour looks suspicious as it is 
>> expected that a newly created container will have zero  children.
>> 
>> Current specification is not clear on this whether it is allowed for a 
>> container to contain default components or not. The fix make changes to the 
>> specification to clarify the same.
>> 
>> Note: I think this will need a CSR, I will file one after the review is 
>> completed
>
> Pankaj Bansal has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Review Comments

The CSR is created for this issue 
https://bugs.openjdk.java.net/browse/JDK-8273356

-

PR: https://git.openjdk.java.net/jdk/pull/5121

Re: RFR: 8272148: JDesktopPane:getComponentCount() returns one extra than expected with GTKLookAndFeel [v2]

[Pankaj Bansal]

On Mon, 23 Aug 2021 17:05:25 GMT, Phil Race  wrote:

>> Pankaj Bansal has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Review Comments
>
>> > I wonder how the other components handle that. For example, the JComboBox 
>> > in Aqua L is a "compound" element and it contains a text field and 
>> > button, what does the "getComponentCount" return in that case, wIll we 
>> > hide internal data from the user?
>> 
>> I just ran the following test for JComboBox for all L on my Mac. It fails 
>> for everyone of them. The test and output is as below. Looks like this test 
>> is not being run for all components for all L It should give lot of 
>> failures I guess.
> 
> Yep not unexpected which is why I said this needed to be documented at least 
> as high up as JComponent.
> And FWIW since nothing said that JComponents are created with no children it 
> is a very weak bug/complaint to begin with !

Gentle Reminder to the reviewers @prrace @mrserb

-

PR: https://git.openjdk.java.net/jdk/pull/5121

Re: RFR: 8272229: BasicSplitPaneDivider:oneTouchExpandableChanged() returns letButton and rightButton as null with GTKLookAndFeel.

[Pankaj Bansal]

On Thu, 26 Aug 2021 22:10:52 GMT, Sergey Bylokhov  wrote:

> I think that the current test case is wrong, the oneTouchExpandableChanged() 
> should not be called directly, only when the "oneTouchExpandable" property is 
> changed.
> 
> So to consider this as a bug the test should trigger the call to the 
> oneTouchExpandableChanged() as a result of the " oneTouchExpandable value 
> change" and then validate the state of the buttons.

The bug is filled to make the specification to clarify that the behaviour 
mentioned in specification can change according to the L currently being 
used. That is what the current change is doing. If some L does not support 
oneTouchButtons, the function will not do anything and return.

-

PR: https://git.openjdk.java.net/jdk/pull/5263

Re: RFR: 8273043: [TEST_BUG] Automate NimbusJTreeSelTextColor.java [v2]

[Pankaj Bansal]

On Thu, 26 Aug 2021 22:22:54 GMT, Alexey Ivanov  wrote:

>> Automated NimbusJTreeSelTextColor.java test which is added under 
>> [JDK-8271315](https://bugs.openjdk.java.net/browse/JDK-8271315).
>> 
>> It passes with the recent build of JDK 18.  
>> It fails with JDK 18 build 7 where 
>> [JDK-8266510](https://bugs.openjdk.java.net/browse/JDK-8266510) is not fixed 
>> yet:
>> 
>> 
>> Exception in thread "main" java.lang.RuntimeException: Unexpected color 
>> found: ff00 at (4, 9);
>> foreground: ; background: ff39698a - check image.png
>> at 
>> NimbusJTreeSelTextColor.checkColors(NimbusJTreeSelTextColor.java:106)
>> at NimbusJTreeSelTextColor.main(NimbusJTreeSelTextColor.java:70)
>> 
>> 
>> The line is wrapped for readability. In this case the text is black instead 
>> of white.
>
> Alexey Ivanov has updated the pull request incrementally with two additional 
> commits since the last revision:
> 
>  - Mark the test headless
>  - Paint JTree into BufferedImage

I assume you must have tested this on headless environment and it must have 
passed. But is it really necessary to make this headless as we are showing 
JFrame and setting L I mean these things mostly associate with headful 
environment.

-

PR: https://git.openjdk.java.net/jdk/pull/5269

Withdrawn: 8272229: BasicSplitPaneDivider:oneTouchExpandableChanged() returns letButton and rightButton as null with GTKLookAndFeel.

[Pankaj Bansal]

On Thu, 26 Aug 2021 07:18:43 GMT, Pankaj Bansal  wrote:

> The function documentation for oneTouchExpandableChanged states that the 
> function does couple of things, but in reality  it only does those things if 
> the Look and Feel supports the supportsOneTouchButtons. In case the Look and 
> Feel does not support supportsOneTouchButtons, this functions just returns in 
> beginning and does not do anything.
> This change clarifies the above in function documentation.

This pull request has been closed without being integrated.

-

PR: https://git.openjdk.java.net/jdk/pull/5263

RFR: 8272229: BasicSplitPaneDivider:oneTouchExpandableChanged() returns letButton and rightButton as null with GTKLookAndFeel.

[Pankaj Bansal]

The function documentation for oneTouchExpandableChanged states that the 
function does couple of things, but in reality  it only does those things if 
the Look and Feel supports the supportsOneTouchButtons. In case the Look and 
Feel does not support supportsOneTouchButtons, this functions just returns in 
beginning and does not do anything.
This change clarifies the above in function documentation.

-

Commit messages:
 - 8272229: BasicSplitPaneDivider:oneTouchExpandableChanged() returns 
leftButton and rightButton as null with GTKLookAndFeel.

Changes: https://git.openjdk.java.net/jdk/pull/5263/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5263=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272229
  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5263.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5263/head:pull/5263

PR: https://git.openjdk.java.net/jdk/pull/5263

Re: RFR: 8272148: JDesktopPane:getComponentCount() returns one extra than expected with GTKLookAndFeel [v2]

[Pankaj Bansal]

On Mon, 23 Aug 2021 17:01:46 GMT, Phil Race  wrote:

>> Pankaj Bansal has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Review Comments
>
> src/java.desktop/share/classes/javax/swing/JComponent.java line 188:
> 
>> 186:  * change according to look and feel, as some look and feels may add a
>> 187:  * default component to a container, where as other look and feels may
>> 188:  * choose not to do so.
> 
> "a" is not "any number" so you need to make your wording consistent.
> Also I think you need to say that even for a specific L it may vary 
> depending on configuration properties of the 
> JComponent.
> 
> And perhaps finish with
> "In summary, it is not valid to assume a JComponent has no children just 
> because the application did not directly add them"  ?

Done

-

PR: https://git.openjdk.java.net/jdk/pull/5121

Re: RFR: 8272148: JDesktopPane:getComponentCount() returns one extra than expected with GTKLookAndFeel [v2]

[Pankaj Bansal]

On Mon, 23 Aug 2021 23:04:29 GMT, Sergey Bylokhov  wrote:

>> src/java.desktop/share/classes/javax/swing/JComponent.java line 185:
>> 
>>> 183:  * 
>>> 184:  * Containers inherited from JComponent can contain any
>>> 185:  * number of default components as children. This behaviour can also
>> 
>> can we say "default or initial"
>
> Do we need to say "Containers inherited from JComponent"? For example, 
> JComboBox is just a component, and it is not necessary will be used as a 
> container by the user.
> I meant all components inherited from the JComponent are Containers per 
> specification, but not all of them are used as such. And this new statement 
> is applicable to all "JComponents".

I have changed default to "default or initial". I also changed "Containers 
inherited from JComponent" to just JComponent as I feel Sergey's point makes 
sense.

-

PR: https://git.openjdk.java.net/jdk/pull/5121

Re: RFR: 8272148: JDesktopPane:getComponentCount() returns one extra than expected with GTKLookAndFeel [v2]

[Pankaj Bansal]

> A container may include few default components as children, which are added 
> to it during creation. Due to this, calling function getChildrenCount on a 
> new created instance may return non zero value. This behaviour may vary 
> according to L also, as some L may add some default components to a 
> container, but other L may choose not to do so.
> 
> The current bugs reports that this behaviour looks suspicious as it is 
> expected that a newly created container will have zero  children.
> 
> Current specification is not clear on this whether it is allowed for a 
> container to contain default components or not. The fix make changes to the 
> specification to clarify the same.
> 
> Note: I think this will need a CSR, I will file one after the review is 
> completed

Pankaj Bansal has updated the pull request incrementally with one additional 
commit since the last revision:

  Review Comments

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5121/files
  - new: https://git.openjdk.java.net/jdk/pull/5121/files/86a488c5..ff7edbde

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=5121=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5121=00-01

  Stats: 9 lines in 1 file changed: 4 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5121.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5121/head:pull/5121

PR: https://git.openjdk.java.net/jdk/pull/5121

Re: RFR: 8272148: JDesktopPane:getComponentCount() returns one extra than expected with GTKLookAndFeel

[Pankaj Bansal]

On Mon, 16 Aug 2021 08:22:35 GMT, Pankaj Bansal  wrote:

> A container may include few default components as children, which are added 
> to it during creation. Due to this, calling function getChildrenCount on a 
> new created instance may return non zero value. This behaviour may vary 
> according to L also, as some L may add some default components to a 
> container, but other L may choose not to do so.
> 
> The current bugs reports that this behaviour looks suspicious as it is 
> expected that a newly created container will have zero  children.
> 
> Current specification is not clear on this whether it is allowed for a 
> container to contain default components or not. The fix make changes to the 
> specification to clarify the same.
> 
> Note: I think this will need a CSR, I will file one after the review is 
> completed

Gentle Reminder to the reviewers

-

PR: https://git.openjdk.java.net/jdk/pull/5121

Re: RFR: 8272148: JDesktopPane:getComponentCount() returns one extra than expected with GTKLookAndFeel

[Pankaj Bansal]

On Thu, 19 Aug 2021 22:41:04 GMT, Sergey Bylokhov  wrote:

> I wonder how the other components handle that. For example, the JComboBox in 
> Aqua L is a "compound" element and it contains a text field and button, 
> what does the "getComponentCount" return in that case, wIll we hide internal 
> data from the user?

I just ran the following test for JComboBox for all L on my Mac. It fails 
for everyone of them. The test and output is as below. Looks like this test is 
not being run for all components for all L It should give lot of failures I 
guess.

`

public static void main(String[] args) throws Exception{
for (UIManager.LookAndFeelInfo info : 
UIManager.getInstalledLookAndFeels()) {
JComboBox container = new JComboBox();
System.out.println("**");
UIManager.setLookAndFeel(info.getClassName());
System.out.println("Current Look and Feel is "+info.getName());
if (container.getComponentCount() == 0) {
System.out.println("Expected : no child components present");
} else {
System.out.println("Unexpected : by default the Container has 
components size " + container.getComponentCount());
System.out.println("Following are the components present");
for (Component c : container.getComponents())
System.out.println(c);
}
System.out.println("**");
System.out.println();
}
}
   
`

`

**
Current Look and Feel is Metal
Unexpected : by default the Container has components size 2
Following are the components present
com.apple.laf.AquaComboBoxButton[,0,0,0x0,invalid,alignmentX=0.0,alignmentY=0.5,border=com.apple.laf.AquaButtonBorder$Named@3bfdc050,flags=12583200,maximumSize=,minimumSize=,preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=javax.swing.plaf.InsetsUIResource[top=0,left=2,bottom=0,right=2],paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=false,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=,defaultCapable=true]
javax.swing.CellRendererPane[,0,0,0x0,invalid,hidden]
**

**
Current Look and Feel is Nimbus
Unexpected : by default the Container has components size 2
Following are the components present
javax.swing.plaf.metal.MetalComboBoxButton[,0,0,0x0,invalid,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource@5bb21b69,flags=12583208,maximumSize=,minimumSize=,preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=java.awt.Insets[top=0,left=1,bottom=1,right=3],paintBorder=true,paintFocus=false,pressedIcon=,rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=,defaultCapable=true]
javax.swing.CellRendererPane[,0,0,0x0,invalid,hidden]
**

**
Current Look and Feel is CDE/Motif
Unexpected : by default the Container has components size 2
Following are the components present
javax.swing.plaf.synth.SynthArrowButton[ComboBox.arrowButton,0,0,0x0,invalid,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.synth.SynthBorder@4690b489,flags=12583200,maximumSize=,minimumSize=,preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=javax.swing.plaf.InsetsUIResource[top=0,left=0,bottom=0,right=0],paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=,defaultCapable=false]
javax.swing.CellRendererPane[,0,0,0x0,invalid,hidden]
**

**
Current Look and Feel is Mac OS X
Unexpected : by default the Container has components size 1
Following are the components present
javax.swing.CellRendererPane[,0,0,0x0,invalid,hidden]
**

`

-

PR: https://git.openjdk.java.net/jdk/pull/5121

Re: RFR: 8272148: JDesktopPane:getComponentCount() returns one extra than expected with GTKLookAndFeel

[Pankaj Bansal]

On Thu, 19 Aug 2021 12:11:23 GMT, Prasanta Sadhukhan  
wrote:

> > The "InternalFrame.useTaskBar" is set true in case of GTKL only,
> 
> What if we set this property to false and only set under some condition for 
> GTK L, what sort of problem we can expect? Does any jtreg/jck test gets 
> affected if we set it to false?

I just ran a mach5 job with the "InternalFrame.useTaskBar" set to true with 
GTKL Link in JBS. I do not see any issue due to this. The failures are not 
related to this change.

My point is that, as discussed in the meeting, this is not related to GTKL 
Anyone can make a custom container and add some default components and this 
test will fail for that container. So rather than setting 
"InternalFrame.useTaskBar" to TRUE for GTL L just to solve this issue quickly 
but wrong way, we should make changes to the spec and state that this is 
allowed. Similar things could have been done in other components for other 
L, which may have not yet been reported.

-

PR: https://git.openjdk.java.net/jdk/pull/5121

Re: RFR: 8272148: JDesktopPane:getComponentCount() returns one extra than expected with GTKLookAndFeel

[Pankaj Bansal]

On Mon, 16 Aug 2021 19:11:43 GMT, Sergey Bylokhov  wrote:

> Can you please clarify why the GTK L is affected only?

Synth L is adding a Taskbar in SynthDesktopPaneUI class if the 
"InternalFrame.useTaskBar" is set true. The "InternalFrame.useTaskBar" is set 
true in case of GTKL only, so this issue is happening. I think L are 
allowed to customize these things.
I think this happening in GTK L is not really much to do with GTK L This 
can happen for any default/custom container for any L which adds some default 
components as children. The spec does not stop anyone from doing so. So the 
spec should be modified to clarify the expected behaviour.

https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthDesktopPaneUI.java#L109
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java#L660

-

PR: https://git.openjdk.java.net/jdk/pull/5121

Re: RFR: 8272491: Problem list javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java on macos

[Pankaj Bansal]

On Sun, 15 Aug 2021 16:23:52 GMT, Phil Race  wrote:

> This will fail regularly so problem list it.

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5119

Re: RFR: 4819544: SwingSet2 JTable Demo throws NullPointerException

[Pankaj Bansal]

On Tue, 3 Aug 2021 08:23:19 GMT, Prasanta Sadhukhan  
wrote:

> In the JTable demo, if we double click on the first cell in the Favorite 
> Number column, delete the value and click on some
> other cell, a java.lang.NullPointerException is getting thrown.
> The flaw is in the TableDemo's TableModel getColumnClass() method which 
> queries the value of cell 0 in the target column, and returns its Class. This 
> logic seems to be flawed - an NPE will be thrown when the value in cell 0 is 
> null.
> Fix by checking for null.

Verified that the NPE is not happening after the fix.

-

Marked as reviewed by pbansal (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4969

Re: RFR: 8270058: Use Objects.check{Index, FromIndexSize} for java.desktop [v3]

[Pankaj Bansal]

On Thu, 22 Jul 2021 06:29:13 GMT, Yi Yang  wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of 
>> checkIndex by 
>> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in 
>> the whole JDK codebase.
>> 
>> As Mandy suggested, I create this PR for changes involving client code:
>> 
>> src/java.desktop/share/classes/com/sun/media/sound/AudioFloatInputStream.java
>> src/java.desktop/share/classes/javax/swing/JTabbedPane.java
>> test/jdk/java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
>> test/jdk/javax/imageio/AppletResourceTest.java
>> test/jdk/javax/imageio/ImageReaderReadAll.java
>> test/jdk/javax/imageio/metadata/IIOMetadataFormat/UserPluginMetadataFormatTest.java
>
> Yi Yang has updated the pull request incrementally with one additional commit 
> since the last revision:
> 
>   typo

Looks ok to me

-

Marked as reviewed by pbansal (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4718

Re: RFR: 8270058: Use Objects.check{Index, FromIndexSize} for java.desktop [v3]

[Pankaj Bansal]

On Fri, 30 Jul 2021 08:17:29 GMT, Jayathirth D V  wrote:

>> Yi Yang has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   typo
>
> src/java.desktop/share/classes/javax/swing/JTabbedPane.java line 1793:
> 
>> 1791: 
>> 1792: private void checkIndex(int index) {
>> 1793: Objects.checkIndex(index, pages.size());
> 
> I think we should not replace IOOBE checks with messages. Its better to keep 
> it old way.

Objects.checkIndex itself throws exceptions for wrong values. So this should be 
ok. No?

-

PR: https://git.openjdk.java.net/jdk/pull/4718

Re: RFR: 8266510: Nimbus JTree default tree cell renderer does not use selected text color

[Pankaj Bansal]

On Mon, 26 Jul 2021 05:46:44 GMT, Tejpal Rebari  wrote:

> Please review the following fix for JDK-18.
> This is revert of the fix for  nimbus jtree renderer properties persist 
> across L(https://bugs.openjdk.java.net/browse/JDK-8249674), This fixed 
> caused nimbus jtree default tree cell renderer to not use the selected text 
> color, which was white originally and changed to black after the fix. 
> Reverted the change to match original behaviour.
> 
> Tested on MacOS , Windows and Linux.

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/4903

Re: [jdk17] RFR: 8269529: javax/swing/reliability/HangDuringStaticInitialization.java fails in Windows debug build [v3]

[Pankaj Bansal]

On Tue, 29 Jun 2021 08:29:29 GMT, Christoph Langer  wrote:

>> Exclude test on Windows if VM is from a debug build.
>
> Christoph Langer has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Update Copyright year

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/160

Re: RFR: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS [v4]

[Pankaj Bansal]

On Sat, 8 May 2021 16:01:28 GMT, Alexander Zuev  wrote:

>> Fixed popup position taking into account its offset
>> Added a lot of screenshots taking to better understand failures should they 
>> happen down the line
>
> Alexander Zuev has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Small fixes

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3844

Integrated: 8265291: Error in Javadoc for doAccessibleAction API in AccessibleJSlider class

[Pankaj Bansal]

On Sun, 2 May 2021 06:09:23 GMT, Pankaj Bansal  wrote:

> There is a small error in javadoc for doAccessibleAction function added in 
> AccessibleJSlider class under JDK-8262981. The documentation says that the 
> API returns true always, whereas it can return both true or false depending 
> upon the parameter value, same as is the case with same API in 
> AccessibleJSpinner. This error happened do to an oversight and current fix 
> corrects the error.

This pull request has now been integrated.

Changeset: 3af4efdf
Author:Pankaj Bansal 
URL:   
https://git.openjdk.java.net/jdk/commit/3af4efdfcfbbb52d38415374083c66c9e7b22604
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod

8265291: Error in Javadoc for doAccessibleAction API in AccessibleJSlider class

Reviewed-by: azvegint, jdv

-

PR: https://git.openjdk.java.net/jdk/pull/3832

Re: RFR: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS

[Pankaj Bansal]

On Mon, 3 May 2021 19:30:07 GMT, Alexander Zuev  wrote:

> Fixed popup position taking into account its offset
> Added a lot of screenshots taking to better understand failures should they 
> happen down the line

As this is an intermittent failure (failed once in 40 iterations as mentioned 
in JBS), can you please run multiple iterations of the test in CI system 
without JTREG_RETRY_COUNT option to confirm there is no failure now?

-

PR: https://git.openjdk.java.net/jdk/pull/3844

Re: RFR: 8264950: Set opaque for JTooltip in config file of NimbusLookAndFeel

[Pankaj Bansal]

On Mon, 3 May 2021 08:54:19 GMT, Tejpal Rebari  wrote:

> Set the opaque property for JToolTip in config file (skin.laf) of 
> NimbusLookAndFeel instead of setting up in the SynthToolTipUI.
> This is related to the discussion on PR  
> https://github.com/openjdk/jdk/pull/3167.

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3837

Re: RFR: 8265291: Error in Javadoc for doAccessibleAction API in AccessibleJSlider class

[Pankaj Bansal]

On Mon, 3 May 2021 16:55:07 GMT, Alexander Zvegintsev  
wrote:

> Looks like it requires CSR.

I think CSR is not required in this case. CSR would have been required if 
return type was being changed. Here the change only says that the function can 
return both true or false instead of just true, but the return type is not 
being changed. I will try to get clarity on this and proceed accordingly.

-

PR: https://git.openjdk.java.net/jdk/pull/3832

RFR: 8265291: Error in Javadoc for doAccessibleAction API in AccessibleJSlider class

[Pankaj Bansal]

There is a small error in javadoc for doAccessibleAction function added in 
AccessibleJSlider class under JDK-8262981. The documentation says that the API 
returns true always, whereas it can return both true or false depending upon 
the parameter value, same as is the case with same API in AccessibleJSpinner. 
This error happened do to an oversight and current fix corrects the error.

-

Commit messages:
 - 8265291: Error in Javadoc for doAccessibleAction API in AccessibleJSlider 
class

Changes: https://git.openjdk.java.net/jdk/pull/3832/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3832=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265291
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3832.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3832/head:pull/3832

PR: https://git.openjdk.java.net/jdk/pull/3832

Integrated: 8163367: Test javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java javax/swing/JComboBox/8033069/bug8033069ScrollBar.java fails intermittently

[Pankaj Bansal]

On Sun, 25 Apr 2021 16:27:46 GMT, Pankaj Bansal  wrote:

> The tests a javax/swing/JComboBox/8033069/bug8033069ScrollBar.java and 
> javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java fails 
> intermittently. The tests have a few problems which could cause this 
> behaviour and the are being fixed here.
> 
> 1. Test access the Swing components without EDT thread at couple of places.
> 2. Test is not calling waitForIdle or delay after Robot.mouseMove operations.
> 
> There is some additional cleanup done in the fix and moved the frame in 
> centre. The tests pass with multiple iterations on CI. Link in the JBS.

This pull request has now been integrated.

Changeset: 9481fad4
Author:Pankaj Bansal 
URL:   https://git.openjdk.java.net/jdk/commit/9481fad4
Stats: 34 lines in 2 files changed: 16 ins; 9 del; 9 mod

8163367: Test javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java 
javax/swing/JComboBox/8033069/bug8033069ScrollBar.java fails intermittently

Reviewed-by: aivanov

-

PR: https://git.openjdk.java.net/jdk/pull/3678

Re: RFR: 8163367: Test javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java javax/swing/JComboBox/8033069/bug8033069ScrollBar.java fails intermittently [v3]

[Pankaj Bansal]

> The tests a javax/swing/JComboBox/8033069/bug8033069ScrollBar.java and 
> javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java fails 
> intermittently. The tests have a few problems which could cause this 
> behaviour and the are being fixed here.
> 
> 1. Test access the Swing components without EDT thread at couple of places.
> 2. Test is not calling waitForIdle or delay after Robot.mouseMove operations.
> 
> There is some additional cleanup done in the fix and moved the frame in 
> centre. The tests pass with multiple iterations on CI. Link in the JBS.

Pankaj Bansal has updated the pull request incrementally with one additional 
commit since the last revision:

  Update test/jdk/javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java
  
  Review comments
  
  Co-authored-by: Alexey Ivanov <70774172+aivanov-...@users.noreply.github.com>

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3678/files
  - new: https://git.openjdk.java.net/jdk/pull/3678/files/5cb06612..0fb35893

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3678=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3678=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3678.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3678/head:pull/3678

PR: https://git.openjdk.java.net/jdk/pull/3678

Re: RFR: 8163367: Test javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java javax/swing/JComboBox/8033069/bug8033069ScrollBar.java fails intermittently [v2]

[Pankaj Bansal]

> The tests a javax/swing/JComboBox/8033069/bug8033069ScrollBar.java and 
> javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java fails 
> intermittently. The tests have a few problems which could cause this 
> behaviour and the are being fixed here.
> 
> 1. Test access the Swing components without EDT thread at couple of places.
> 2. Test is not calling waitForIdle or delay after Robot.mouseMove operations.
> 
> There is some additional cleanup done in the fix and moved the frame in 
> centre. The tests pass with multiple iterations on CI. Link in the JBS.

Pankaj Bansal has updated the pull request incrementally with one additional 
commit since the last revision:

  Incorporate review comments

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3678/files
  - new: https://git.openjdk.java.net/jdk/pull/3678/files/b726d76a..5cb06612

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3678=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3678=00-01

  Stats: 17 lines in 1 file changed: 6 ins; 8 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3678.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3678/head:pull/3678

PR: https://git.openjdk.java.net/jdk/pull/3678

Integrated: 8265278: doc build fails after JDK-8262981

[Pankaj Bansal]

On Thu, 15 Apr 2021 13:51:57 GMT, Pankaj Bansal  wrote:

> The doc build fails after the JDK-8262981. The JDK-8262981 adds a new 
> function, but by mistake the param name used in function is different from 
> the param name mentioned in @param tag. This breaks the doc build.
> 
> This change corrects the param name. I have verified that the doc build runs 
> successfully after the changes by running following command. It fails before 
> the current change and passes with the change.
> 
> "make jdk-image docs-jdk"

This pull request has now been integrated.

Changeset: 6b907155
Author:Pankaj Bansal 
URL:   https://git.openjdk.java.net/jdk/commit/6b907155
Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8265278: doc build fails after JDK-8262981

Reviewed-by: jdv, trebari

-

PR: https://git.openjdk.java.net/jdk/pull/3518

RFR: 8265278: doc build fails after JDK-8262981

[Pankaj Bansal]

The doc build fails after the JDK-8262981. The JDK-8262981 adds a new function, 
but by mistake the param name used in function is different from the param name 
mentioned in @param tag. This breaks the doc build.

This change corrects the param name. I have verified that the doc build runs 
successfully after the changes by running following command. It fails before 
the current change and passes with the change.

"make jdk-image docs-jdk"

-

Commit messages:
 - Fix the param name

Changes: https://git.openjdk.java.net/jdk/pull/3518/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3518=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265278
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3518.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3518/head:pull/3518

PR: https://git.openjdk.java.net/jdk/pull/3518

Integrated: 8262981: Create implementation for NSAccessibilitySlider protocol

[Pankaj Bansal]

On Mon, 8 Mar 2021 12:51:56 GMT, Pankaj Bansal  wrote:

> Create implementation of NSAccessibilitySlider protocol 
> https://developer.apple.com/documentation/appkit/nsaccessibilityslider
> 
> The implementation has the function performIncrement and performDecrement to 
> increase/decrease the value of slider using the VoiceOver. To implement this 
> functionality, I could think of  following two ways. I have chosen the first 
> one here though it is more intrusive.
> 1. Make the AccessibleJSlider class implement the AccessibleAction interface. 
> This makes AccessibleJSlider consistent with the AccessibleJSpinner class. It 
> is more clear and the logic to increase/decrease Slider value can be changed 
> easily. But this changes AccessibleJSlider class and will need a CSR.
> 2. Get the current Accessible Value from the component and  just 
> increment/decrement it in SliderAccessibility.m  class itself and then set 
> the current accessible value fro there only. This will not need any changes 
> in AccessibleJSlider class, but this does not look correct way and I have not 
> used this.
> 
> The changes can be easily tested by using a JSlider example, like the 
> following example. VO should announce the correct the slider values. To 
> change the slider values, use ctrl+opt+shift+down key to start interacting 
> with the slider, then use ctrl+opt+up/down arrow keys to increment/decrement 
> slider values.
> 
>   import javax.swing.JFrame;
>   import javax.swing.JSlider;
>   
>   public class JSliderDemo{
>   public static void main(String[] args) throws Exception {
>   JFrame jframe = new JFrame("JSlider Demo");
>   jframe.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>   jframe.add(new JSlider());
>   
>   jframe.setLocationRelativeTo(null);
>   jframe.pack();
>   jframe.setVisible(true);
>   }
>   }

This pull request has now been integrated.

Changeset: 9d669c91
Author:Pankaj Bansal 
URL:   https://git.openjdk.java.net/jdk/commit/9d669c91
Stats: 75 lines in 4 files changed: 68 ins; 1 del; 6 mod

8262981: Create implementation for NSAccessibilitySlider protocol

Reviewed-by: kizune

-

PR: https://git.openjdk.java.net/jdk/pull/2874

Re: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol

[Pankaj Bansal]

On Wed, 31 Mar 2021 19:56:24 GMT, Sergey Bylokhov  wrote:

>>> > It looks like the Dialog must have handled the keys as there are no 
>>> > special keys mentioned for JAWS to interact with the component like the VO
>>> 
>>> Did you check this list of hotkeys?
>>> https://www.freedomscientific.com/training/jaws/hotkeys
>>> https://freedomscientific.github.io/VFO-standards-support/aria.html
>>> Something like:
>>> RIGHT ARROW and UP ARROW increase the value of the slider.
>>> LEFT ARROW and DOWN ARROW decrease the value of the slider.
>>> HOME and END move to the minimum and maximum values of the slider.
>>> PAGE UP and PAGE DOWN increment or decrement the slider by a given amount.
>>> 
>>> ===
>>> My main point is that if we will change some shared code we should care 
>>> about both supported platforms.
>> 
>> I tried the hot keys with the both native dialog ("Display Settings" with a 
>> "Brightness" Slider ) and java applications. 
>> Both Java and native dialog  are themselves handling the RIGHT ARROW, UP 
>> ARROW, LEFT ARROW, DOWN ARROW, HOME and END buttons for JSlider and user can 
>> change slider value using these keys without JAWS also. but they are not 
>> handling the PAGE UP and PAGE DOWN button.
>> PAGE UP and PAGE DOWN button don't work with JAWS either, meaning JAWS is 
>> not able to handle the keys and is not able to change component values for 
>> both native dialogs and Java application. Also, I am not able to find any 
>> component in Swing, where JAWS can change the component values using any hot 
>> key. Please correct me if I am wrong in this and JAWS can actually 
>> manipulate some component. Also, in the old implementation for MacOS , the 
>> VO can not change the Spinner/Slider values and we are adding this 
>> functionality now only. 
>> In addition to this, the functionality we are adding in slider can be used 
>> with JAWS also if we decide to provide the support for the same later. 
>> Currently, I do not see JAWS being able to change any component value in 
>> swing, so it will not be able to change Slider value too.
>
> Ok, please file a similar bug for the windows platform.

@mrserb @azuev-java Any other comments on this? Can you please look at the CSR 
also?

-

PR: https://git.openjdk.java.net/jdk/pull/2874

Re: RFR: 8264658: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on linux-x64 [v3]

[Pankaj Bansal]

On Fri, 2 Apr 2021 19:03:43 GMT, Daniel D. Daugherty  wrote:

>> A trivial fix to ProblemList 
>> javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on linux-x64
>
> Daniel D. Daugherty has updated the pull request with a new target base due 
> to a merge or a rebase. The incremental webrev excludes the unrelated changes 
> brought in by the merge/rebase. The pull request contains three additional 
> commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8264658
>  - 8264658: ProblemList 
> javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on linux-x64
>  - 8264657: ProblemList 
> java/awt/Focus/FrameMinimizeTest/FrameMinimizeTest.java on linux-x64

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3330

Re: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol

[Pankaj Bansal]

On Wed, 31 Mar 2021 19:56:24 GMT, Sergey Bylokhov  wrote:

> Ok, please file a similar bug for the windows platform.

I have created the bug for windows here 
https://bugs.openjdk.java.net/browse/JDK-8264598.
I have also created the CSR for the current issue.

-

PR: https://git.openjdk.java.net/jdk/pull/2874

Re: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol [v3]

[Pankaj Bansal]

> Create implementation of NSAccessibilitySlider protocol 
> https://developer.apple.com/documentation/appkit/nsaccessibilityslider
> 
> The implementation has the function performIncrement and performDecrement to 
> increase/decrease the value of slider using the VoiceOver. To implement this 
> functionality, I could think of  following two ways. I have chosen the first 
> one here though it is more intrusive.
> 1. Make the AccessibleJSlider class implement the AccessibleAction interface. 
> This makes AccessibleJSlider consistent with the AccessibleJSpinner class. It 
> is more clear and the logic to increase/decrease Slider value can be changed 
> easily. But this changes AccessibleJSlider class and will need a CSR.
> 2. Get the current Accessible Value from the component and  just 
> increment/decrement it in SliderAccessibility.m  class itself and then set 
> the current accessible value fro there only. This will not need any changes 
> in AccessibleJSlider class, but this does not look correct way and I have not 
> used this.
> 
> The changes can be easily tested by using a JSlider example, like the 
> following example. VO should announce the correct the slider values. To 
> change the slider values, use ctrl+opt+shift+down key to start interacting 
> with the slider, then use ctrl+opt+up/down arrow keys to increment/decrement 
> slider values.
> 
>   import javax.swing.JFrame;
>   import javax.swing.JSlider;
>   
>   public class JSliderDemo{
>   public static void main(String[] args) throws Exception {
>   JFrame jframe = new JFrame("JSlider Demo");
>   jframe.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>   jframe.add(new JSlider());
>   
>   jframe.setLocationRelativeTo(null);
>   jframe.pack();
>   jframe.setVisible(true);
>   }
>   }

Pankaj Bansal has updated the pull request with a new target base due to a 
merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' into JDK-8262981
 - increase initial capacity for rolesMap
 - Remove whitespaces
 - remove SpinboxAccessibility.m changes
 - Code cleanup
 - cleanup
 - 8262981: Create implementation for NSAccessibilitySlider protocol

-

Changes: https://git.openjdk.java.net/jdk/pull/2874/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2874=02
  Stats: 75 lines in 4 files changed: 68 ins; 1 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2874.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2874/head:pull/2874

PR: https://git.openjdk.java.net/jdk/pull/2874

Re: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol

[Pankaj Bansal]

On Wed, 17 Mar 2021 01:48:40 GMT, Sergey Bylokhov  wrote:

> > It looks like the Dialog must have handled the keys as there are no special 
> > keys mentioned for JAWS to interact with the component like the VO
> 
> Did you check this list of hotkeys?
> https://www.freedomscientific.com/training/jaws/hotkeys
> https://freedomscientific.github.io/VFO-standards-support/aria.html
> Something like:
> RIGHT ARROW and UP ARROW increase the value of the slider.
> LEFT ARROW and DOWN ARROW decrease the value of the slider.
> HOME and END move to the minimum and maximum values of the slider.
> PAGE UP and PAGE DOWN increment or decrement the slider by a given amount.
> 
> ===
> My main point is that if we will change some shared code we should care about 
> both supported platforms.

I tried the hot keys with the both native dialog ("Display Settings" with a 
"Brightness" Slider ) and java applications. 
Both Java and native dialog  are themselves handling the RIGHT ARROW, UP ARROW, 
LEFT ARROW, DOWN ARROW, HOME and END buttons for JSlider and user can change 
slider value using these keys without JAWS also. but they are not handling the 
PAGE UP and PAGE DOWN button.
PAGE UP and PAGE DOWN button don't work with JAWS either, meaning JAWS is not 
able to handle the keys and is not able to change component values for both 
native dialogs and Java application. Also, I am not able to find any component 
in Swing, where JAWS can change the component values using any hot key. Please 
correct me if I am wrong in this and JAWS can actually manipulate some 
component. Also, in the old implementation for MacOS , the VO can not change 
the Spinner/Slider values and we are adding this functionality now only. 
In addition to this, the functionality we are adding in slider can be used with 
JAWS also if we decide to provide the support for the same later. Currently, I 
do not see JAWS being able to change any component value in swing, so it will 
not be able to change Slider value too.

-

PR: https://git.openjdk.java.net/jdk/pull/2874

Re: RFR: 8264328: Broken license in javax/swing/JComboBox/8072767/bug8072767.java

[Pankaj Bansal]

On Sun, 28 Mar 2021 00:21:16 GMT, Sergey Bylokhov  wrote:

> This test has a broken license:
> /*
>  * To change this license header, choose License Headers in Project 
> Properties.
>  * To change this template file, choose Tools | Templates
>  /*
>  * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3230

Re: RFR: 8263766: Confusing specification of JEditorPaneAccessibleHypertextSupport constructor

[Pankaj Bansal]

On Tue, 23 Mar 2021 05:53:30 GMT, Prasanta Sadhukhan  
wrote:

> The constructor JEditorPaneAccessibleHypertextSupport  javadoc wording is 
> wrong. Rectified the anomaly.

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3145

Re: RFR: 8263454: com.apple.laf.AquaFileChooserUI ignores the result of String.trim()

[Pankaj Bansal]

On Mon, 22 Mar 2021 22:19:18 GMT, Alexander Zvegintsev  
wrote:

> Looks like the original idea was to set `fallbacktext` on strings containing 
> only spaces.
> 
> I decided to remove the `trim()` call to keep the same behavior and to allows 
> to set such meaningless space only titles/tooltips(same as on other 
> platforms, maybe someone want empty label for some reason).

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3136

Re: RFR: 8263977: GTK L: Cleanup duplicate checks in GTKStyle and GTKLookAndFeel [v2]

[Pankaj Bansal]

On Mon, 22 Mar 2021 18:25:57 GMT, Aleksey Shipilev  wrote:

>> SonarCloud reports a few minor problems in GTKStyle and GTKLookAndFeel: 
>> Correct one of the identical sub-expressions on both sides of operator "||".
>
> Aleksey Shipilev has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Update copyrights

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3121

Re: RFR: 8263977: GTK L: Cleanup duplicate checks in GTKStyle and GTKLookAndFeel

[Pankaj Bansal]

On Mon, 22 Mar 2021 15:40:41 GMT, Aleksey Shipilev  wrote:

> SonarCloud reports a few minor problems in GTKStyle and GTKLookAndFeel: 
> Correct one of the identical sub-expressions on both sides of operator "||".

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3121

Re: RFR: 8263136: C4530 was reported from VS 2019 at access bridge [v2]

[Pankaj Bansal]

On Sat, 13 Mar 2021 01:57:53 GMT, Sergey Bylokhov  wrote:

>> This change looks fine, I was able to see the proper logs in the 
>> java_access_bridge.log, but I cannot find the logs from the 
>> windows_access_bridge.log. It seems unrelated to this fix. @pankaj-bansal 
>> please take a look at why the windows log might be missed if 
>> "JAVA_ACCESSBRIDGE_LOGDIR" is set.
>
> For the record: the jaws J2021.2102.34.400 was used for testing.

@mrserb Did you close the JAWS after running the program. I have seen that the 
logs for windows_access_bridge are flushed only after the JAWS is closed.

-

PR: https://git.openjdk.java.net/jdk/pull/2859

Re: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol [v2]

[Pankaj Bansal]

On Wed, 10 Mar 2021 14:47:38 GMT, Pankaj Bansal  wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m
>>  line 59:
>> 
>>> 57: [rolesMap setObject:@"RadiobuttonAccessibility" 
>>> forKey:@"radiobutton"];
>>> 58: [rolesMap setObject:@"CheckboxAccessibility" forKey:@"checkbox"];
>>> 59: [rolesMap setObject:@"SliderAccessibility" forKey:@"slider"];
>> 
>> Shouldn't you also increase the rolesMap initial capacity?
>
>> Shouldn't you also increase the rolesMap initial capacity?
> 
> ok, I will do that in next commit.

Done

-

PR: https://git.openjdk.java.net/jdk/pull/2874

Re: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol [v2]

[Pankaj Bansal]

> Create implementation of NSAccessibilitySlider protocol 
> https://developer.apple.com/documentation/appkit/nsaccessibilityslider
> 
> The implementation has the function performIncrement and performDecrement to 
> increase/decrease the value of slider using the VoiceOver. To implement this 
> functionality, I could think of  following two ways. I have chosen the first 
> one here though it is more intrusive.
> 1. Make the AccessibleJSlider class implement the AccessibleAction interface. 
> This makes AccessibleJSlider consistent with the AccessibleJSpinner class. It 
> is more clear and the logic to increase/decrease Slider value can be changed 
> easily. But this changes AccessibleJSlider class and will need a CSR.
> 2. Get the current Accessible Value from the component and  just 
> increment/decrement it in SliderAccessibility.m  class itself and then set 
> the current accessible value fro there only. This will not need any changes 
> in AccessibleJSlider class, but this does not look correct way and I have not 
> used this.
> 
> The changes can be easily tested by using a JSlider example, like the 
> following example. VO should announce the correct the slider values. To 
> change the slider values, use ctrl+opt+shift+down key to start interacting 
> with the slider, then use ctrl+opt+up/down arrow keys to increment/decrement 
> slider values.
> 
>   import javax.swing.JFrame;
>   import javax.swing.JSlider;
>   
>   public class JSliderDemo{
>   public static void main(String[] args) throws Exception {
>   JFrame jframe = new JFrame("JSlider Demo");
>   jframe.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>   jframe.add(new JSlider());
>   
>   jframe.setLocationRelativeTo(null);
>   jframe.pack();
>   jframe.setVisible(true);
>   }
>   }

Pankaj Bansal has updated the pull request incrementally with one additional 
commit since the last revision:

  increase initial capacity for rolesMap

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2874/files
  - new: https://git.openjdk.java.net/jdk/pull/2874/files/dac91ff1..a1944fee

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=2874=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2874=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2874.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2874/head:pull/2874

PR: https://git.openjdk.java.net/jdk/pull/2874

Re: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol

[Pankaj Bansal]

On Fri, 12 Mar 2021 03:26:10 GMT, Sergey Bylokhov  wrote:

> > If you happen to have some idea about how can a user interact with Sliders 
> > or Spinners using JAWS, please let me know. I will definitely verify if the 
> > changes would be helpful for Windows.
> 
> How the native applications works under JAWS?

I tried running a Windows native settings app like "Display Settings" with 
JAWS. It has a Slider "Brightness". JAWS says same thing when the Slider was 
brought in focus like "To increase or decrease, use the arrow keys". When I 
press the arrow keys, the values change. But I don't know if the value changed 
because the Windows Native dialog handles the keys and changed the value, or 
JAWS consumed the event and then changed the value. It looks like the Dialog 
must have handled the keys as there are no special keys mentioned for JAWS to 
interact with the component like the VO.  I am not sure how I can verify this 
on Windows native apps. 
I did try to run the JSpinner with JAWS and I see that if Java does not handle 
the keys, the value in Spinner does not change. This means JAWS does not 
interact with the component and the accessibility functionality was added for 
MacOS only. Same thing is being done for JSlider.

-

PR: https://git.openjdk.java.net/jdk/pull/2874

Re: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol

[Pankaj Bansal]

On Wed, 10 Mar 2021 23:09:31 GMT, Sergey Bylokhov  wrote:

> If it does not work on Windows then I suggest checking that the new 
> functionality requested via CSR will help it as well.

I could not find any key shortcuts where JAWS will consume the key pressed and 
will be used to interact with the component like the VO is doing here. This 
similar functionality is present in JSpinner already and JAWS says similar 
thing when a Spinner is in focus "To set the value, press the arrow keys or 
type the value". When user presses the keys, it is consumed by Java and value 
is incremented/decremented as expected. But the value is not being set by JAWS 
like VO if used with VO keys. So I am not sure how to verify if the changes 
will be useful for windows as well. I think if there is a way user can interact 
with Spinner or Slider, then these changes should be useful and if it is not 
possible, it will not be useful in both. These changes does make the Slider 
more consistent with Spinner and easy to maintain and cleaner.
If you happen to have some idea about how can a user interact with Sliders or 
Spinners using JAWS, please let me know. I will definitely verify if the 
changes would be helpful for Windows.

-

PR: https://git.openjdk.java.net/jdk/pull/2874

Re: RFR: 8263410: ListModel javadoc refers to non-existent interface [v2]

[Pankaj Bansal]

On Thu, 11 Mar 2021 04:40:25 GMT, Prasanta Sadhukhan  
wrote:

>> ListModel class javadoc refers to ListDataModel interface but there is no 
>> ListDataModel interface. Rectified the anomaly.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Copyright change

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/2931

Re: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol

[Pankaj Bansal]

On Wed, 10 Mar 2021 13:32:01 GMT, Alexander Zuev  wrote:

> > If you need a new functionality and CSR I wonder how it currently works on 
> > Windows and macOS, or it does not work?
> 
> Haven't tested this functionality on Windows, on macOS with current JDK it 
> does not work at all. After entering the JSlider interaction mode VoiceOver 
> does not announce the a11y shortcuts and the attempt to invoke said shortcuts 
> do nothing.

Yes, as Alex pointed out, it does not work on MacOS. The VO only announces the 
value and user can not modify the slider values using VO shortcut keys.

I saw the windows code and I did not see anything where the current value of a 
component is being set. I tested this by running JAWS as well. When a JSlider 
is in focus, JAWS announces the slider values and then says "To increase or 
decrease, use the arrow keys". The keys are being handled by JAVA only and JAWS 
is not doing any part in it. To verify this, I commented the code to handle 
keys events in Java and slider value does not change. So looks like this does 
not work on Windows as well.

If these changes are too intrusive, I can go with the second approach of 
getting and setting the current values of slider in 
performincrement/performdecrement functions in SliderAccessibility.m. I am not 
sure if this will be correct approach, but it will be less intrusive and will 
not need a CSR.

-

PR: https://git.openjdk.java.net/jdk/pull/2874

Re: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol

[Pankaj Bansal]

On Tue, 9 Mar 2021 21:27:39 GMT, Alexander Zuev  wrote:

> Shouldn't you also increase the rolesMap initial capacity?

ok, I will do that in next commit.

-

PR: https://git.openjdk.java.net/jdk/pull/2874

Re: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol

[Pankaj Bansal]

On Wed, 10 Mar 2021 13:32:01 GMT, Alexander Zuev  wrote:

> If you need a new functionality and CSR I wonder how it currently works on 
> Windows and macOS, or it does not work?

-

PR: https://git.openjdk.java.net/jdk/pull/2874

RFR: 8262981: Create implementation for NSAccessibilitySlider protocol

[Pankaj Bansal]

Create implementation of NSAccessibilitySlider protocol 
https://developer.apple.com/documentation/appkit/nsaccessibilityslider

The implementation has the function performIncrement and performDecrement to 
increase/decrease the value of slider using the VoiceOver. To implement this 
functionality, I could think of  following two ways. I have chosen the first 
one here though it is more intrusive.
1. Make the AccessibleJSlider class implement the AccessibleAction interface. 
This makes AccessibleJSlider consistent with the AccessibleJSpinner class. It 
is more clear and the logic to increase/decrease Slider value can be changed 
easily. But this changes AccessibleJSlider class and will need a CSR.
2. Get the current Accessible Value from the component and  just 
increment/decrement it in SliderAccessibility.m  class itself and then set the 
current accessible value fro there only. This will not need any changes in 
AccessibleJSlider class, but this does not look correct way and I have not used 
this.

The changes can be easily tested by using a JSlider example, like the following 
example. VO should announce the correct the slider values. To change the slider 
values, use ctrl+opt+shift+down key to start interacting with the slider, then 
use ctrl+opt+up/down arrow keys to increment/decrement slider values.

  import javax.swing.JFrame;
  import javax.swing.JSlider;
  
  public class JSliderDemo{
  public static void main(String[] args) throws Exception {
  JFrame jframe = new JFrame("JSlider Demo");
  jframe.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
  jframe.add(new JSlider());
  
  jframe.setLocationRelativeTo(null);
  jframe.pack();
  jframe.setVisible(true);
  }
  }

-

Commit messages:
 - Remove whitespaces
 - remove SpinboxAccessibility.m changes
 - Code cleanup
 - cleanup
 - 8262981: Create implementation for NSAccessibilitySlider protocol

Changes: https://git.openjdk.java.net/jdk/pull/2874/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2874=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262981
  Stats: 74 lines in 4 files changed: 68 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2874.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2874/head:pull/2874

PR: https://git.openjdk.java.net/jdk/pull/2874

Re: RFR: 8263170: ComboBoxModel documentation refers to a nonexistant type

[Pankaj Bansal]

On Tue, 9 Mar 2021 04:10:38 GMT, Prasanta Sadhukhan  
wrote:

> javadoc of ComboBoxModel incorrectly specifies "extends ListDataModel" but 
> actually it extends ListModel and there is no such interface as 
> ListDataModel. Rectified the anomaly.

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/2886

Re: RFR: 4710675: JTextArea.setComponentOrientation does not work with correct timing [v3]

[Pankaj Bansal]

On Fri, 26 Feb 2021 05:32:06 GMT, Prasanta Sadhukhan  
wrote:

>> It is seen 
>> JTextArea.setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) 
>> orientation is not honoured if it is called after setText() and remain at 
>> LTR orientation. It changes the orientation only if some more text is typed 
>> additionally to existing text.
>> This behaviour is different from JTextField where the RTL orientation is 
>> honoured from start.
>> Proposed fix is to check for ComponentOrientation propertyChange event and 
>> set i18n property if it is not set, so that orientation is honoured as soon 
>> as setComponentOrientation() is called.
>> Checked for all L in all supported platforms.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Add comment

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/2673

Integrated: 8260291: The case instruction is not visible in dark mode

[Pankaj Bansal]

On Sun, 14 Feb 2021 07:49:39 GMT, Pankaj Bansal  wrote:

> Please review a trivial test only fix.
> 
> This is a GTKL specific manual test and create an instruction panel 
> containing JTextArea. The JTextArea background color is hardcoded as white 
> color, which is causing issues on dark mode in Ubuntu 20.04 and Ubuntu 20.10 
> as the text color is also white. The fix is to remove the hardcoded white 
> color as the JTextArea background color should be set by L and should not 
> be hardcoded in test.

This pull request has now been integrated.

Changeset: 849f4c0f
Author:Pankaj Bansal 
URL:   https://git.openjdk.java.net/jdk/commit/849f4c0f
Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod

8260291: The case instruction is not visible in dark mode

Reviewed-by: trebari, aivanov

-

PR: https://git.openjdk.java.net/jdk/pull/2564

Re: RFR: 8260291: The case instruction is not visible in dark mode [v2]

[Pankaj Bansal]

> Please review a trivial test only fix.
> 
> This is a GTKL specific manual test and create an instruction panel 
> containing JTextArea. The JTextArea background color is hardcoded as white 
> color, which is causing issues on dark mode in Ubuntu 20.04 and Ubuntu 20.10 
> as the text color is also white. The fix is to remove the hardcoded white 
> color as the JTextArea background color should be set by L and should not 
> be hardcoded in test.

Pankaj Bansal has updated the pull request incrementally with one additional 
commit since the last revision:

  Revert "Add bugID"
  
  This reverts commit a84b6098bee8122abd159209a1ff857db716f4b4.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2564/files
  - new: https://git.openjdk.java.net/jdk/pull/2564/files/a84b6098..8eec0dd4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=2564=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2564=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2564.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2564/head:pull/2564

PR: https://git.openjdk.java.net/jdk/pull/2564

Re: RFR: 8260291: The case instruction is not visible in dark mode [v2]

[Pankaj Bansal]

On Mon, 15 Feb 2021 06:07:37 GMT, Tejpal Rebari  wrote:

>> Pankaj Bansal has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Revert "Add bugID"
>>   
>>   This reverts commit a84b6098bee8122abd159209a1ff857db716f4b4.
>
> test/jdk/javax/swing/JSpinner/TestJSpinnerPressUnpress.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @bug 8234733 8260291
> 
> There is no need to add bug id 8260291 here.
> http://openjdk.java.net/jtreg/faq.html#when-should-i-update-the-bug-entry-in-a-test-description

ok, makes sense. I have removed the bugID.

-

PR: https://git.openjdk.java.net/jdk/pull/2564

RFR: 8260291: The case instruction is not visible in dark mode

[Pankaj Bansal]

Please review a trivial test only fix.

This is a manual test and create an instruction panel containing JTextArea. The 
JTextArea background color is hardcoded as white color, which is causing issues 
on dark mode in Ubuntu 20.04 and Ubuntu 20.10 as the text color is also white. 
The fix is to remove the hardcoded white color as the JTextArea background 
color should be set by L and should not be hardcoded in test.

-

Commit messages:
 - Add bugID
 - 8260291: The case instruction is not visible in dark mode

Changes: https://git.openjdk.java.net/jdk/pull/2564/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2564=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260291
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2564.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2564/head:pull/2564

PR: https://git.openjdk.java.net/jdk/pull/2564

Re: RFR: 8216358: [accessibility] [macos] The focus is invisible when tab to "Image Radio Buttons" and "Image CheckBoxes" [v4]

[Pankaj Bansal]

On Fri, 5 Feb 2021 05:12:00 GMT, Alexander Zuev  wrote:

>> 8216358: [accessibility] [macos] The focus is invisible when tab to "Image 
>> Radio Buttons" and "Image CheckBoxes"
>
> Alexander Zuev has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Remove leftovers from last experiments.

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/2384

Re: RFR: 8260343: Delete obsolete classes in the Windows L

[Pankaj Bansal]

On Mon, 25 Jan 2021 07:08:33 GMT, Sergey Bylokhov  wrote:

> Obsolete/unused classes are removed.

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/2216

Re: RFR: 8260343: Delete obsolete classes in the Windows L

[Pankaj Bansal]

On Mon, 25 Jan 2021 07:08:33 GMT, Sergey Bylokhov  wrote:

> Obsolete/unused classes are removed.

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsButtonListener.java
 line 41:

> 39: }
> 40: /*
> 41:  This class is currently not used, but exists in case customers

Should not removing this public class need a CSR?

-

PR: https://git.openjdk.java.net/jdk/pull/2216

[jdk16] Integrated: 8259237: Demo selection changes with left/right arrow key. No need to press space for selection.

[Pankaj Bansal]

On Sat, 9 Jan 2021 12:47:48 GMT, Pankaj Bansal  wrote:

> Please review a fix for jdk16
> 
> Issue: In SwingSet2, if the user navigates through the demos, the demo gets 
> selected/starts on pressing left/right key only. There is no need to press 
> the "space" key. Earlier, on pressing the left/right key, only demo icon used 
> to get focused and user needed to press the "space" to actually select a demo.
> 
> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each 
> JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, 
> when the user pressed Left/Right button, only the selected button used to 
> change. The Action set on JToggleButton used to perform only  on pressing the 
> "Space" button. Now, the Action is performed on navigating the JToggleButtons 
> using Left/Right keys without the need to press the "space" key.
> 
> This issue is a side effect of fix done for 
> https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in 
> JDK-8249548 were not present in JRadioButton as there was code available to 
> handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for 
> JDK-8249548 moved duplicate code from AquaButtonRadioUI and 
> BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available 
> for JToggleButton and JRadioButton for all L This was wrong as there is a 
> difference in behaviour for JRadioButtons added to ButtonGroup for AquaL 
> and other L In AquaL, the AbstractAction set on JRadioButton is not 
> performed on button selection and user has to press "space". In other L, 
> the AbstractAction is performed on selection of Button itself without the 
> need to press "space". 
> 
> Fix: The current change fixes the issue in present bug and keeps the fixes 
> done in JDK-8249548. Following is the behaviour of JToggleButton and 
> JRadioButton for different L before JDK-8249548 fix, after JDK-8249548 fix 
> and after current fix.
> 
> Before fix for JDK-8249548
> JToggleButton: 
> For all L, user can not navigate/select the buttons added to ButtonGroup 
> properly as mentioned in the JDK-8249548.
> JRadioButton: 
> For Synth L (Nimbus L), user can not navigate/select the buttons added to 
> ButtonGroup. 
> For AquaL, user can select the buttons added to ButtonGroup by pressing 
> left/right key and needs to press the "space" to perform the set Action.
> For Other L, user can select/navigate the buttons and the set Action is 
> also performed without pressing "space"
> 
> After fix for JDK-8249548
> JToggleButton:
> For all L, user can navigate/select the buttons added to ButtonGroups and 
> the AbstractAction set is performed without the need to press "space".
> JRadioButton:
> For all L, user can navigate/select the buttons added to ButtonGroups and 
> the AbstractAction set is performed without the need to press "space".
> 
> After current fix:
> JToggleButton:
> For all L, user can navigate/select the buttons added to ButtonGroups.  
> User needs to press "space" to perform the set AbstractAction.
> JRadioButton:
> For AquaL, the behaviour before JDK-8249548 is restored, so user needs to 
> press the "space" to perform the set Action.
> For all other L (including Synth L), the behaviour is same. User can 
> navigate/select the buttons added to ButtonGroups and set Action is performed 
> without pressing "space"
> 
> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. 
> The test TestButtonGroupFocusTraversal.java is modified such that it fails 
> without current fix and passes after the fix. The fix also should be verified 
> by running SwingSet2.

This pull request has now been integrated.

Changeset: 28ff2de1
Author:Pankaj Bansal 
URL:   https://git.openjdk.java.net/jdk16/commit/28ff2de1
Stats: 99 lines in 2 files changed: 92 ins; 1 del; 6 mod

8259237: Demo selection changes with left/right arrow key. No need to press 
space for selection.

Reviewed-by: psadhukhan, kizune, serb

-

PR: https://git.openjdk.java.net/jdk16/pull/99

Re: [jdk16] RFR: 8259237: Demo selection changes with left/right arrow key. No need to press space for selection. [v6]

[Pankaj Bansal]

> Please review a fix for jdk16
> 
> Issue: In SwingSet2, if the user navigates through the demos, the demo gets 
> selected/starts on pressing left/right key only. There is no need to press 
> the "space" key. Earlier, on pressing the left/right key, only demo icon used 
> to get focused and user needed to press the "space" to actually select a demo.
> 
> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each 
> JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, 
> when the user pressed Left/Right button, only the selected button used to 
> change. The Action set on JToggleButton used to perform only  on pressing the 
> "Space" button. Now, the Action is performed on navigating the JToggleButtons 
> using Left/Right keys without the need to press the "space" key.
> 
> This issue is a side effect of fix done for 
> https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in 
> JDK-8249548 were not present in JRadioButton as there was code available to 
> handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for 
> JDK-8249548 moved duplicate code from AquaButtonRadioUI and 
> BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available 
> for JToggleButton and JRadioButton for all L This was wrong as there is a 
> difference in behaviour for JRadioButtons added to ButtonGroup for AquaL 
> and other L In AquaL, the AbstractAction set on JRadioButton is not 
> performed on button selection and user has to press "space". In other L, 
> the AbstractAction is performed on selection of Button itself without the 
> need to press "space". 
> 
> Fix: The current change fixes the issue in present bug and keeps the fixes 
> done in JDK-8249548. Following is the behaviour of JToggleButton and 
> JRadioButton for different L before JDK-8249548 fix, after JDK-8249548 fix 
> and after current fix.
> 
> Before fix for JDK-8249548
> JToggleButton: 
> For all L, user can not navigate/select the buttons added to ButtonGroup 
> properly as mentioned in the JDK-8249548.
> JRadioButton: 
> For Synth L (Nimbus L), user can not navigate/select the buttons added to 
> ButtonGroup. 
> For AquaL, user can select the buttons added to ButtonGroup by pressing 
> left/right key and needs to press the "space" to perform the set Action.
> For Other L, user can select/navigate the buttons and the set Action is 
> also performed without pressing "space"
> 
> After fix for JDK-8249548
> JToggleButton:
> For all L, user can navigate/select the buttons added to ButtonGroups and 
> the AbstractAction set is performed without the need to press "space".
> JRadioButton:
> For all L, user can navigate/select the buttons added to ButtonGroups and 
> the AbstractAction set is performed without the need to press "space".
> 
> After current fix:
> JToggleButton:
> For all L, user can navigate/select the buttons added to ButtonGroups.  
> User needs to press "space" to perform the set AbstractAction.
> JRadioButton:
> For AquaL, the behaviour before JDK-8249548 is restored, so user needs to 
> press the "space" to perform the set Action.
> For all other L (including Synth L), the behaviour is same. User can 
> navigate/select the buttons added to ButtonGroups and set Action is performed 
> without pressing "space"
> 
> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. 
> The test TestButtonGroupFocusTraversal.java is modified such that it fails 
> without current fix and passes after the fix. The fix also should be verified 
> by running SwingSet2.

Pankaj Bansal has updated the pull request incrementally with one additional 
commit since the last revision:

  Add checkbox in test

-

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/99/files
  - new: https://git.openjdk.java.net/jdk16/pull/99/files/fca7f7a4..9962d615

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16=99=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16=99=04-05

  Stats: 57 lines in 1 file changed: 57 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/99.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/99/head:pull/99

PR: https://git.openjdk.java.net/jdk16/pull/99

Re: [jdk16] RFR: 8259237: Demo selection changes with left/right arrow key. No need to press space for selection. [v5]

[Pankaj Bansal]

> Please review a fix for jdk16
> 
> Issue: In SwingSet2, if the user navigates through the demos, the demo gets 
> selected/starts on pressing left/right key only. There is no need to press 
> the "space" key. Earlier, on pressing the left/right key, only demo icon used 
> to get focused and user needed to press the "space" to actually select a demo.
> 
> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each 
> JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, 
> when the user pressed Left/Right button, only the selected button used to 
> change. The Action set on JToggleButton used to perform only  on pressing the 
> "Space" button. Now, the Action is performed on navigating the JToggleButtons 
> using Left/Right keys without the need to press the "space" key.
> 
> This issue is a side effect of fix done for 
> https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in 
> JDK-8249548 were not present in JRadioButton as there was code available to 
> handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for 
> JDK-8249548 moved duplicate code from AquaButtonRadioUI and 
> BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available 
> for JToggleButton and JRadioButton for all L This was wrong as there is a 
> difference in behaviour for JRadioButtons added to ButtonGroup for AquaL 
> and other L In AquaL, the AbstractAction set on JRadioButton is not 
> performed on button selection and user has to press "space". In other L, 
> the AbstractAction is performed on selection of Button itself without the 
> need to press "space". 
> 
> Fix: The current change fixes the issue in present bug and keeps the fixes 
> done in JDK-8249548. Following is the behaviour of JToggleButton and 
> JRadioButton for different L before JDK-8249548 fix, after JDK-8249548 fix 
> and after current fix.
> 
> Before fix for JDK-8249548
> JToggleButton: 
> For all L, user can not navigate/select the buttons added to ButtonGroup 
> properly as mentioned in the JDK-8249548.
> JRadioButton: 
> For Synth L (Nimbus L), user can not navigate/select the buttons added to 
> ButtonGroup. 
> For AquaL, user can select the buttons added to ButtonGroup by pressing 
> left/right key and needs to press the "space" to perform the set Action.
> For Other L, user can select/navigate the buttons and the set Action is 
> also performed without pressing "space"
> 
> After fix for JDK-8249548
> JToggleButton:
> For all L, user can navigate/select the buttons added to ButtonGroups and 
> the AbstractAction set is performed without the need to press "space".
> JRadioButton:
> For all L, user can navigate/select the buttons added to ButtonGroups and 
> the AbstractAction set is performed without the need to press "space".
> 
> After current fix:
> JToggleButton:
> For all L, user can navigate/select the buttons added to ButtonGroups.  
> User needs to press "space" to perform the set AbstractAction.
> JRadioButton:
> For AquaL, the behaviour before JDK-8249548 is restored, so user needs to 
> press the "space" to perform the set Action.
> For all other L (including Synth L), the behaviour is same. User can 
> navigate/select the buttons added to ButtonGroups and set Action is performed 
> without pressing "space"
> 
> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. 
> The test TestButtonGroupFocusTraversal.java is modified such that it fails 
> without current fix and passes after the fix. The fix also should be verified 
> by running SwingSet2.

Pankaj Bansal has updated the pull request incrementally with one additional 
commit since the last revision:

  Update Spec

-

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/99/files
  - new: https://git.openjdk.java.net/jdk16/pull/99/files/6c745600..fca7f7a4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16=99=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16=99=03-04

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/99.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/99/head:pull/99

PR: https://git.openjdk.java.net/jdk16/pull/99

Re: [jdk16] RFR: 8259237: Demo selection changes with left/right arrow key. No need to press space for selection. [v4]

[Pankaj Bansal]

On Tue, 12 Jan 2021 05:07:10 GMT, Sergey Bylokhov  wrote:

> > I did not add radio button to spec as RadioButton are also ToggleButton 
> > only. But yes, I will highlight that. So I will update the spec as below. 
> > Hope that is ok.
> > 
> > * Find the new toggle/radio button that focus needs to be
> > * moved to in the group, select the button
> 
> Also please add a comment of why we need to use the setPressed/setArmed it 
> seems unrelated to the selection of the button, and is not described anywhere.

Done, please have a look.

-

PR: https://git.openjdk.java.net/jdk16/pull/99

Re: [jdk16] RFR: 8259237: Demo selection changes with left/right arrow key. No need to press space for selection. [v4]

[Pankaj Bansal]

On Tue, 12 Jan 2021 04:26:19 GMT, Sergey Bylokhov  wrote:

> The spec of the update method seems outdated:
> * Find the new toggle button that focus needs to be
> * moved to in the group, select the button
> 
> BTW I am not sure why the Aqua is so specific and requires an additional 
> press while the same radio buttons do not require that. Is it possible that 
> some fix was implemented in the shared code so now all L skip the "space"?

The AquaL also does not need the additional "space" press for JRadioButton. 
During the fix of JDK-8226892, code was added for other L, so that the 
additional "space" press is not needed. But same code was not added for 
AquaL So, the additional key press was needed. Now, the additional press 
should not be needed for AquaL also for JRadioButton. So now, for all L, 
the additional key press is needed for JToggleButton and is not needed for 
JRadioButton.

I did not add radio button to spec as RadioButton are also ToggleButton only. 
But yes, I will highlight that. So I will update the spec as below. Hope that 
is ok.
 * Find the new toggle/radio button that focus needs to be
 * moved to in the group, select the button

-

PR: https://git.openjdk.java.net/jdk16/pull/99

Re: [jdk16] RFR: 8259237: Demo selection changes with left/right arrow key. No need to press space for selection. [v3]

[Pankaj Bansal]

On Tue, 12 Jan 2021 03:58:44 GMT, Prasanta Sadhukhan  
wrote:

>> Pankaj Bansal has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Remove duplicate code for AquaL
>
> test/jdk/javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java line 32:
> 
>> 30:  * @run main TestButtonGroupFocusTraversal
>> 31:  */
>> 32: 
> 
> We need to append this bugid as product code is changed for which this 
> testcase is modified

Done, please have a look.

-

PR: https://git.openjdk.java.net/jdk16/pull/99

Re: [jdk16] RFR: 8259237: Demo selection changes with left/right arrow key. No need to press space for selection. [v4]

[Pankaj Bansal]

> Please review a fix for jdk16
> 
> Issue: In SwingSet2, if the user navigates through the demos, the demo gets 
> selected/starts on pressing left/right key only. There is no need to press 
> the "space" key. Earlier, on pressing the left/right key, only demo icon used 
> to get focused and user needed to press the "space" to actually select a demo.
> 
> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each 
> JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, 
> when the user pressed Left/Right button, only the selected button used to 
> change. The Action set on JToggleButton used to perform only  on pressing the 
> "Space" button. Now, the Action is performed on navigating the JToggleButtons 
> using Left/Right keys without the need to press the "space" key.
> 
> This issue is a side effect of fix done for 
> https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in 
> JDK-8249548 were not present in JRadioButton as there was code available to 
> handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for 
> JDK-8249548 moved duplicate code from AquaButtonRadioUI and 
> BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available 
> for JToggleButton and JRadioButton for all L This was wrong as there is a 
> difference in behaviour for JRadioButtons added to ButtonGroup for AquaL 
> and other L In AquaL, the AbstractAction set on JRadioButton is not 
> performed on button selection and user has to press "space". In other L, 
> the AbstractAction is performed on selection of Button itself without the 
> need to press "space". 
> 
> Fix: The current change fixes the issue in present bug and keeps the fixes 
> done in JDK-8249548. Following is the behaviour of JToggleButton and 
> JRadioButton for different L before JDK-8249548 fix, after JDK-8249548 fix 
> and after current fix.
> 
> Before fix for JDK-8249548
> JToggleButton: 
> For all L, user can not navigate/select the buttons added to ButtonGroup 
> properly as mentioned in the JDK-8249548.
> JRadioButton: 
> For Synth L (Nimbus L), user can not navigate/select the buttons added to 
> ButtonGroup. 
> For AquaL, user can select the buttons added to ButtonGroup by pressing 
> left/right key and needs to press the "space" to perform the set Action.
> For Other L, user can select/navigate the buttons and the set Action is 
> also performed without pressing "space"
> 
> After fix for JDK-8249548
> JToggleButton:
> For all L, user can navigate/select the buttons added to ButtonGroups and 
> the AbstractAction set is performed without the need to press "space".
> JRadioButton:
> For all L, user can navigate/select the buttons added to ButtonGroups and 
> the AbstractAction set is performed without the need to press "space".
> 
> After current fix:
> JToggleButton:
> For all L, user can navigate/select the buttons added to ButtonGroups.  
> User needs to press "space" to perform the set AbstractAction.
> JRadioButton:
> For AquaL, the behaviour before JDK-8249548 is restored, so user needs to 
> press the "space" to perform the set Action.
> For all other L (including Synth L), the behaviour is same. User can 
> navigate/select the buttons added to ButtonGroups and set Action is performed 
> without pressing "space"
> 
> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. 
> The test TestButtonGroupFocusTraversal.java is modified such that it fails 
> without current fix and passes after the fix. The fix also should be verified 
> by running SwingSet2.

Pankaj Bansal has updated the pull request incrementally with one additional 
commit since the last revision:

  Add current bugid

-

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/99/files
  - new: https://git.openjdk.java.net/jdk16/pull/99/files/de3db58a..6c745600

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16=99=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16=99=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/99.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/99/head:pull/99

PR: https://git.openjdk.java.net/jdk16/pull/99

Re: [jdk16] RFR: 8259237: Demo selection changes with left/right arrow key. No need to press space for selection. [v3]

[Pankaj Bansal]

On Mon, 11 Jan 2021 08:20:39 GMT, Prasanta Sadhukhan  
wrote:

> I guess you did not run jtreg job with latest problemlist as it did not run
> javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java
> javax/swing/JRadioButton/8075609/bug8075609.java
> javax/swing/JRadioButton/8033699/bug8033699.java
> Please see this test pass with your change as some of them used to fail after 
> JDK-8226892 which was reworked by fix of JDK-8249548

I have updated the PR with some commits and ran the full jtreg/jck tests 
including the tests you have mentioned. The fix is not breaking anything.

-

PR: https://git.openjdk.java.net/jdk16/pull/99

Re: [jdk16] RFR: 8259237: Demo selection changes with left/right arrow key. No need to press space for selection. [v3]

[Pankaj Bansal]

On Mon, 11 Jan 2021 11:57:49 GMT, Pankaj Bansal  wrote:

>> Quick question: why we special casing JRadioButton case? Is there any reason 
>> we should call the action on them?
>
>> Quick question: why we special casing JRadioButton case? Is there any reason 
>> we should call the action on them?
> 
> This was the behaviour which was there before JDK-8249548 for JRadioButton 
> and I am just reverting to it. As explained in the PR description, the 
> behaviour before JDK-8249548 was as below
> 
> Before fix for JDK-8249548
> JToggleButton:
> For all L, user can not navigate/select the buttons added to 
> ButtonGroup properly as mentioned in the JDK-8249548.
> JRadioButton:
> For Synth L (Nimbus L), user can not navigate/select the buttons 
> added to ButtonGroup.
> For AquaL, user can select the buttons added to ButtonGroup by pressing 
> left/right key and needs to press the "space" to perform the set Action.
> For Other L, user can select/navigate the buttons and the set Action 
> is also performed without pressing "space"

I have removed the duplicate code for AquaL I think during the fix made for 
JDK-8226892, it was a mistake to not change the AquaL code. So, the behaviour 
of JRadioButton should be similar across L and the duplicate code in AquaL 
is not needed. A mach5 job with all jtreg/jck tests is being run and I will 
will update when it finishes.

-

PR: https://git.openjdk.java.net/jdk16/pull/99

Re: [jdk16] RFR: 8259237: Demo selection changes with left/right arrow key. No need to press space for selection. [v3]

[Pankaj Bansal]

> Please review a fix for jdk16
> 
> Issue: In SwingSet2, if the user navigates through the demos, the demo gets 
> selected/starts on pressing left/right key only. There is no need to press 
> the "space" key. Earlier, on pressing the left/right key, only demo icon used 
> to get focused and user needed to press the "space" to actually select a demo.
> 
> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each 
> JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, 
> when the user pressed Left/Right button, only the selected button used to 
> change. The Action set on JToggleButton used to perform only  on pressing the 
> "Space" button. Now, the Action is performed on navigating the JToggleButtons 
> using Left/Right keys without the need to press the "space" key.
> 
> This issue is a side effect of fix done for 
> https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in 
> JDK-8249548 were not present in JRadioButton as there was code available to 
> handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for 
> JDK-8249548 moved duplicate code from AquaButtonRadioUI and 
> BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available 
> for JToggleButton and JRadioButton for all L This was wrong as there is a 
> difference in behaviour for JRadioButtons added to ButtonGroup for AquaL 
> and other L In AquaL, the AbstractAction set on JRadioButton is not 
> performed on button selection and user has to press "space". In other L, 
> the AbstractAction is performed on selection of Button itself without the 
> need to press "space". 
> 
> Fix: The current change fixes the issue in present bug and keeps the fixes 
> done in JDK-8249548. Following is the behaviour of JToggleButton and 
> JRadioButton for different L before JDK-8249548 fix, after JDK-8249548 fix 
> and after current fix.
> 
> Before fix for JDK-8249548
> JToggleButton: 
> For all L, user can not navigate/select the buttons added to ButtonGroup 
> properly as mentioned in the JDK-8249548.
> JRadioButton: 
> For Synth L (Nimbus L), user can not navigate/select the buttons added to 
> ButtonGroup. 
> For AquaL, user can select the buttons added to ButtonGroup by pressing 
> left/right key and needs to press the "space" to perform the set Action.
> For Other L, user can select/navigate the buttons and the set Action is 
> also performed without pressing "space"
> 
> After fix for JDK-8249548
> JToggleButton:
> For all L, user can navigate/select the buttons added to ButtonGroups and 
> the AbstractAction set is performed without the need to press "space".
> JRadioButton:
> For all L, user can navigate/select the buttons added to ButtonGroups and 
> the AbstractAction set is performed without the need to press "space".
> 
> After current fix:
> JToggleButton:
> For all L, user can navigate/select the buttons added to ButtonGroups.  
> User needs to press "space" to perform the set AbstractAction.
> JRadioButton:
> For AquaL, the behaviour before JDK-8249548 is restored, so user needs to 
> press the "space" to perform the set Action.
> For all other L (including Synth L), the behaviour is same. User can 
> navigate/select the buttons added to ButtonGroups and set Action is performed 
> without pressing "space"
> 
> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. 
> The test TestButtonGroupFocusTraversal.java is modified such that it fails 
> without current fix and passes after the fix. The fix also should be verified 
> by running SwingSet2.

Pankaj Bansal has updated the pull request incrementally with one additional 
commit since the last revision:

  Remove duplicate code for AquaL

-

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/99/files
  - new: https://git.openjdk.java.net/jdk16/pull/99/files/724f5999..de3db58a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16=99=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16=99=01-02

  Stats: 337 lines in 2 files changed: 19 ins; 317 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/99.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/99/head:pull/99

PR: https://git.openjdk.java.net/jdk16/pull/99

Re: [jdk16] RFR: 8259237: Demo selection changes with left/right arrow key. No need to press space for selection. [v2]

[Pankaj Bansal]

On Mon, 11 Jan 2021 11:16:02 GMT, Alexander Zuev  wrote:

> Quick question: why we special casing JRadioButton case? Is there any reason 
> we should call the action on them?

This was the behaviour which was there before JDK-8249548 for JRadioButton and 
I am just reverting to it. As explained in the PR description, the behaviour 
before JDK-8249548 was as below

Before fix for JDK-8249548
JToggleButton:
For all L, user can not navigate/select the buttons added to ButtonGroup 
properly as mentioned in the JDK-8249548.
JRadioButton:
For Synth L (Nimbus L), user can not navigate/select the buttons added 
to ButtonGroup.
For AquaL, user can select the buttons added to ButtonGroup by pressing 
left/right key and needs to press the "space" to perform the set Action.
For Other L, user can select/navigate the buttons and the set Action is 
also performed without pressing "space"

-

PR: https://git.openjdk.java.net/jdk16/pull/99

Re: [jdk16] RFR: 8259237: Demo selection changes with left/right arrow key. No need to press space for selection. [v2]

[Pankaj Bansal]

> Please review a fix for jdk16
> 
> Issue: In SwingSet2, if the user navigates through the demos, the demo gets 
> selected/starts on pressing left/right key only. There is no need to press 
> the "space" key. Earlier, on pressing the left/right key, only demo icon used 
> to get focused and user needed to press the "space" to actually select a demo.
> 
> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each 
> JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, 
> when the user pressed Left/Right button, only the selected button used to 
> change. The Action set on JToggleButton used to perform only  on pressing the 
> "Space" button. Now, the Action is performed on navigating the JToggleButtons 
> using Left/Right keys without the need to press the "space" key.
> 
> This issue is a side effect of fix done for 
> https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in 
> JDK-8249548 were not present in JRadioButton as there was code available to 
> handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for 
> JDK-8249548 moved duplicate code from AquaButtonRadioUI and 
> BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available 
> for JToggleButton and JRadioButton for all L This was wrong as there is a 
> difference in behaviour for JRadioButtons added to ButtonGroup for AquaL 
> and other L In AquaL, the AbstractAction set on JRadioButton is not 
> performed on button selection and user has to press "space". In other L, 
> the AbstractAction is performed on selection of Button itself without the 
> need to press "space". 
> 
> Fix: The current change fixes the issue in present bug and keeps the fixes 
> done in JDK-8249548. Following is the behaviour of JToggleButton and 
> JRadioButton for different L before JDK-8249548 fix, after JDK-8249548 fix 
> and after current fix.
> 
> Before fix for JDK-8249548
> JToggleButton: 
> For all L, user can not navigate/select the buttons added to ButtonGroup 
> properly as mentioned in the JDK-8249548.
> JRadioButton: 
> For Synth L (Nimbus L), user can not navigate/select the buttons added to 
> ButtonGroup. 
> For AquaL, user can select the buttons added to ButtonGroup by pressing 
> left/right key and needs to press the "space" to perform the set Action.
> For Other L, user can select/navigate the buttons and the set Action is 
> also performed without pressing "space"
> 
> After fix for JDK-8249548
> JToggleButton:
> For all L, user can navigate/select the buttons added to ButtonGroups and 
> the AbstractAction set is performed without the need to press "space".
> JRadioButton:
> For all L, user can navigate/select the buttons added to ButtonGroups and 
> the AbstractAction set is performed without the need to press "space".
> 
> After current fix:
> JToggleButton:
> For all L, user can navigate/select the buttons added to ButtonGroups.  
> User needs to press "space" to perform the set AbstractAction.
> JRadioButton:
> For AquaL, the behaviour before JDK-8249548 is restored, so user needs to 
> press the "space" to perform the set Action.
> For all other L (including Synth L), the behaviour is same. User can 
> navigate/select the buttons added to ButtonGroups and set Action is performed 
> without pressing "space"
> 
> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. 
> The test TestButtonGroupFocusTraversal.java is modified such that it fails 
> without current fix and passes after the fix. The fix also should be verified 
> by running SwingSet2.

Pankaj Bansal has updated the pull request incrementally with one additional 
commit since the last revision:

  Remove duplicate call to remove listener

-

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/99/files
  - new: https://git.openjdk.java.net/jdk16/pull/99/files/903ffcbd..724f5999

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16=99=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16=99=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/99.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/99/head:pull/99

PR: https://git.openjdk.java.net/jdk16/pull/99

Re: [jdk16] RFR: 8259237: Demo selection changes with left/right arrow key. No need to press space for selection.

[Pankaj Bansal]

On Mon, 11 Jan 2021 08:05:21 GMT, Prasanta Sadhukhan  
wrote:

>> Please review a fix for jdk16
>> 
>> Issue: In SwingSet2, if the user navigates through the demos, the demo gets 
>> selected/starts on pressing left/right key only. There is no need to press 
>> the "space" key. Earlier, on pressing the left/right key, only demo icon 
>> used to get focused and user needed to press the "space" to actually select 
>> a demo.
>> 
>> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each 
>> JToggleButton has an AbstractAction set on it, which loads the demo. 
>> Earlier, when the user pressed Left/Right button, only the selected button 
>> used to change. The Action set on JToggleButton used to perform only  on 
>> pressing the "Space" button. Now, the Action is performed on navigating the 
>> JToggleButtons using Left/Right keys without the need to press the "space" 
>> key.
>> 
>> This issue is a side effect of fix done for 
>> https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in 
>> JDK-8249548 were not present in JRadioButton as there was code available to 
>> handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for 
>> JDK-8249548 moved duplicate code from AquaButtonRadioUI and 
>> BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available 
>> for JToggleButton and JRadioButton for all L This was wrong as there is 
>> a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL 
>> and other L In AquaL, the AbstractAction set on JRadioButton is not 
>> performed on button selection and user has to press "space". In other L, 
>> the AbstractAction is performed on selection of Button itself without the 
>> need to press "space". 
>> 
>> Fix: The current change fixes the issue in present bug and keeps the fixes 
>> done in JDK-8249548. Following is the behaviour of JToggleButton and 
>> JRadioButton for different L before JDK-8249548 fix, after JDK-8249548 
>> fix and after current fix.
>> 
>> Before fix for JDK-8249548
>> JToggleButton: 
>> For all L, user can not navigate/select the buttons added to ButtonGroup 
>> properly as mentioned in the JDK-8249548.
>> JRadioButton: 
>> For Synth L (Nimbus L), user can not navigate/select the buttons added 
>> to ButtonGroup. 
>> For AquaL, user can select the buttons added to ButtonGroup by pressing 
>> left/right key and needs to press the "space" to perform the set Action.
>> For Other L, user can select/navigate the buttons and the set Action is 
>> also performed without pressing "space"
>> 
>> After fix for JDK-8249548
>> JToggleButton:
>> For all L, user can navigate/select the buttons added to ButtonGroups and 
>> the AbstractAction set is performed without the need to press "space".
>> JRadioButton:
>> For all L, user can navigate/select the buttons added to ButtonGroups and 
>> the AbstractAction set is performed without the need to press "space".
>> 
>> After current fix:
>> JToggleButton:
>> For all L, user can navigate/select the buttons added to ButtonGroups.  
>> User needs to press "space" to perform the set AbstractAction.
>> JRadioButton:
>> For AquaL, the behaviour before JDK-8249548 is restored, so user needs to 
>> press the "space" to perform the set Action.
>> For all other L (including Synth L), the behaviour is same. User can 
>> navigate/select the buttons added to ButtonGroups and set Action is 
>> performed without pressing "space"
>> 
>> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. 
>> The test TestButtonGroupFocusTraversal.java is modified such that it fails 
>> without current fix and passes after the fix. The fix also should be 
>> verified by running SwingSet2.
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 228:
> 
>> 226: if (listener != null) {
>> 227: b.removeMouseListener(listener);
>> 228: b.removeMouseListener(listener);
> 
> Why are we removing same listener twice?

I just rolled back the changes I did in this file in JDK-8249548. Looks like 
this was has been there for some time. See the file in commit made in this file 
before JDK-8249548 
https://github.com/openjdk/jdk/blob/c18080fef714949221c8ddabc4e23d409575c3d3/src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java.
 
But yes, it should not be done and I will remove it and update the PR.

-

PR: https://git.openjdk.java.net/jdk16/pull/99

Re: RFR: 8225045: javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails on linux-x64 [v2]

[Pankaj Bansal]

On Mon, 11 Jan 2021 04:50:09 GMT, Prasanta Sadhukhan  
wrote:

>> This test was failing on mach5 nightly on ubuntu systems long time back. 
>> Modified the test to add some delays and call robot.waitForIdle() to make it 
>> more stable and the resultant test passes on all mach5 systems including 
>> linux consisting of ubuntu 19.10, 18.04,20.10,20.04 so we can remove the 
>> test from problemlist.
>> mach5 job running for several iterations is posted in JBS.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Remove unneeded setAutoDelay

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/2003

[jdk16] RFR: 8259237: Demo selection changes with left/right arrow key. No need to press space for selection.

[Pankaj Bansal]

Please review a fix for jdk16

Issue: In SwingSet2, if the user navigates through the demos, the demo gets 
selected/starts on pressing left/right key only. There is no need to press the 
"space" key. Earlier, on pressing the left/right key, only demo icon used to 
get focused and user needed to press the "space" to actually select a demo.

Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each 
JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, 
when the user pressed Left/Right button, only the selected button used to 
change. The Action set on JToggleButton used to perform only  on pressing the 
"Space" button. Now, the Action is performed on navigating the JToggleButtons 
using Left/Right keys without the need to press the "space" key.

This issue is a side effect of fix done for 
https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in 
JDK-8249548 were not present in JRadioButton as there was code available to 
handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for 
JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI 
and moved it to BasicButtonUI, so this code is available for JToggleButton and 
JRadioButton for all L This was wrong as there is a difference in behaviour 
for JRadioButtons added to ButtonGroup for AquaL and other L In AquaL, 
the AbstractAction set on JRadioButton is not performed on button selection and 
user has to press "space". In other L, the AbstractAction is performed on 
selection of Button itself without the need to press "space". 

Fix: The current change fixes the issue in present bug and keeps the fixes done 
in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton 
for different L before JDK-8249548 fix, after JDK-8249548 fix and after 
current fix.

Before fix for JDK-8249548
JToggleButton: 
For all L, user can not navigate/select the buttons added to ButtonGroup 
properly as mentioned in the JDK-8249548.
JRadioButton: 
For Synth L (Nimbus L), user can not navigate/select the buttons added to 
ButtonGroup. 
For AquaL, user can select the buttons added to ButtonGroup by pressing 
left/right key and needs to press the "space" to perform the set Action.
For Other L, user can select/navigate the buttons and the set Action is also 
performed without pressing "space"

After fix for JDK-8249548
JToggleButton:
For all L, user can navigate/select the buttons added to ButtonGroups and 
the AbstractAction set is performed without the need to press "space".
JRadioButton:
For all L, user can navigate/select the buttons added to ButtonGroups and 
the AbstractAction set is performed without the need to press "space".

After current fix:
JToggleButton:
For all L, user can navigate/select the buttons added to ButtonGroups.  User 
needs to press "space" to perform the set AbstractAction.
JRadioButton:
For AquaL, the behaviour before JDK-8249548 is restored, so user needs to 
press the "space" to perform the set Action.
For all other L (including Synth L), the behaviour is same. User can 
navigate/select the buttons added to ButtonGroups and set Action is performed 
without pressing "space"

I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The 
test TestButtonGroupFocusTraversal.java is modified such that it fails without 
current fix and passes after the fix. The fix also should be verified by 
running SwingSet2.

-

Commit messages:
 - 8259237: Demo selection changes with left/right arrow key. No need to press 
space for selection.

Changes: https://git.openjdk.java.net/jdk16/pull/99/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16=99=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259237
  Stats: 375 lines in 4 files changed: 350 ins; 20 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/99.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/99/head:pull/99

PR: https://git.openjdk.java.net/jdk16/pull/99

Re: RFR: 8233555: [TESTBUG] JRadioButton tests failing on MacoS

[Pankaj Bansal]

On Wed, 6 Jan 2021 09:17:50 GMT, Prasanta Sadhukhan  
wrote:

>>> Not sure but the code added by JDK-8226892 is reworked by JDK-8249548 and 
>>> we dont see the issue now as can be seen by mach5 run.
>> 
>> So the tests will fail on the builds before jdk16  b14?
>
> Yes, maybe not all but bug8033699 fails before 16b14

The JDK-8249548 may be backed out soon as it has caused some other issue 
JDK-8259237. I am working on it.

-

PR: https://git.openjdk.java.net/jdk/pull/1957

Withdrawn: 8251177: [macosx] The text "big" is truncated

[Pankaj Bansal]

On Sun, 1 Nov 2020 17:21:58 GMT, Pankaj Bansal  wrote:

> The manual test creates a JTabbedPane and add tabs with text with different 
> html styles. For the tab with text "big", a bigger text size is used and it 
> is expected that this should result in making the tab height bigger.
> 
> For AquaLookAndFeel, inside class AquaJTabbedPaneUI and 
> AquaTabbedPaneCopyFromBasicUI, the tabs height is constraint and there is 
> upper/lower limit set for tab height. So the tab height is less than expected 
> and the text looks truncated. I do not see this issue in other L
> 
> It looks like this is done deliberately for AquaL and this is not a bug. 
> but the test instructions do not specify this and result in confusion. So 
> updating the test instructions to specify that the text "big" may be 
> truncated in MacOS.

This pull request has been closed without being integrated.

-

PR: https://git.openjdk.java.net/jdk/pull/984

Re: RFR: 8196092: javax/swing/JComboBox/8032878/bug8032878.java fails

[Pankaj Bansal]

On Mon, 14 Dec 2020 08:17:41 GMT, Prasanta Sadhukhan  
wrote:

> Test was failing if JComboBox tests was run in group in nightly mach5 testing.
> Modified test to remove dependancy from Util class, added delay before frame 
> show and move frame to centre of screen.
> Resultant modified test ran fine in JComboBox group and also in standalone, 
> several iterations of which are ran in mach5. Link in JBS.

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/1762

Re: RFR: 7124397: [macosx] JSpinner serialiazation - deserialization issue [v2]

[Pankaj Bansal]

On Mon, 2 Nov 2020 11:56:12 GMT, Sergey Bylokhov  wrote:

>> The serialization was broken because different listeners are leaked in the 
>> case of compound components. 
>> That listeners also caused memory leaks which were fixed by a few fixes here 
>> and there, and in jdk16 the serialization start to work fine. But I would 
>> like to contribute the test which will prove that serialization works fine.
>
> Sergey Bylokhov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   the summary is added to the test

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/989

Re: RFR: 6816284: Notepad class should be public

[Pankaj Bansal]

On Sun, 1 Nov 2020 01:30:46 GMT, Sergey Bylokhov  wrote:

> The main class in the Notepad demo made public

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/980

Re: RFR: 7124397: [macosx] JSpinner serialiazation - deserialization issue

[Pankaj Bansal]

On Sun, 1 Nov 2020 23:12:10 GMT, Sergey Bylokhov  wrote:

> The serialization was broken because different listeners are leaked in the 
> case of compound components. 
> That listeners also caused memory leaks which were fixed by a few fixes here 
> and there, and in jdk16 the serialization start to work fine. But I would 
> like to contribute the test which will prove that serialization works fine.

test/jdk/javax/swing/JSpinner/SerializationTest.java line 40:

> 38: /**
> 39:  * @test
> 40:  * @bug 7124397

Can we add a @summary tag here to give small summary about the purpose of test?

-

PR: https://git.openjdk.java.net/jdk/pull/989

Re: RFR: 8251177: [macosx] The text "big" is truncated

[Pankaj Bansal]

On Sun, 1 Nov 2020 23:58:04 GMT, Sergey Bylokhov  wrote:

> Probably it is better to limit the size of the font?

Ok, I have reduced the font size. Now the text size if such that it is bigger 
than other texts, but text would fit within the tab height and text is not 
truncated.

-

PR: https://git.openjdk.java.net/jdk/pull/984

Re: RFR: 8015602: [macosx] Test javax/swing/SpringLayout/4726194/bug4726194.java fails on MacOSX [v2]

[Pankaj Bansal]

On Tue, 27 Oct 2020 07:10:31 GMT, Sergey Bylokhov  wrote:

>> The test fails on macOS when Aqua L is enabled:
>>> Test4 works well for all our LaFs because they set symmetrical insets for 
>>> the JTextField, when Aqua sets 6 points for top/bottom and 7 for left/right 
>>> which breaks the testing routine with the hardcoded values. The empty 
>>> border should be set for the tested JTextField.
>> https://bugs.openjdk.java.net/browse/JDK-7124209?focusedCommentId=12231936=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-12231936
>> 
>> Mixed story of this bug.
>> 
>> 1. Initially it was found by https://bugs.openjdk.java.net/browse/JDK-7124209
>>but for some reason the change for that bug missed the actual fix and 
>> just moved the test to the open repo.
>> 
>> 2. But it did not appear as failed because it was problemlisted by the
>> https://bugs.openjdk.java.net/browse/JDK-8198399
>> 3. Recently it was de-problemlisted by the 
>>https://bugs.openjdk.java.net/browse/JDK-8254976
>> 4. But the check via mach5 missed this issue, becouse on the headless 
>> systems default L is Metal not Aqua.
>
> Sergey Bylokhov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Update bug4726194.java

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/872

Re: RFR: 7156347: javax/swing/JList/6462008/bug6462008.java fails

[Pankaj Bansal]

On Thu, 22 Oct 2020 03:58:45 GMT, Prasanta Sadhukhan  
wrote:

> Please review a test fix for an issue seen to be failing in mach5 testing 
> which JList selection was not correct which seems to stem from the fact that 
> the keypress event was initiated before the frame is made visible.
> Fix by adding a robot delay after setVisible and also moved the frame to 
> centre of screen to avoid problems with keypress on window at left edge of 
> monitor.
> Mach5 job was run for several iteration on all 3 platforms. Link in JBS.

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/793

Re: RFR: 8028707: javax/swing/JComboBox/6236162/bug6236162.java fails on azure

[Pankaj Bansal]

On Thu, 15 Oct 2020 16:18:14 GMT, Prasanta Sadhukhan  
wrote:

> Please review a test fix for a test issue seen in nightly testing where the 
> combobox selection was not happening
> properly.  It seems the issue seems to stem from the fact that the test was 
> not waiting for frame to be visible long
> enough before commencing robot actions. Added robot delay and remove the 
> dependancy on Util class.
> Mach5 job was run for several iteration on all 3 platforms. Link in JBS

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/686

Re: RFR: 8254112: javax/swing/plaf/basic/BasicComboPopup/JComboBoxPopupLocation/JComboBoxPopupLocation.java fails on windows [v2]

[Pankaj Bansal]

On Fri, 9 Oct 2020 07:43:57 GMT, Prasanta Sadhukhan  
wrote:

>> Hello Prasanta,
>> 
>> Should not we try to find what has changed that test was failing few days 
>> back and is passing now. Is it sure that it
>> will not fail again like mentioned in 
>> https://bugs.openjdk.java.net/browse/JDK-8238720, specially when nothing is
>> really being changed here. It can be an intermittent failure and may fail 
>> again even though passing in mach5 job you
>> have run.
>
> There might be some lab issue on that day which caused it to fail. There is 
> no mach5 job listed in JDK-8238720 for this
> test for me to investigate. So,whatever is in my hand I am trying. I have 
> tried to run several iterations and it passed
> in mach5. Needless to say it is not reproducible locally.

The bug description in JDK-8238720 says that tests are failing repeatedly on 
Windows hi-dpi. So if Phil has filled a
bug with these tests, they must have failed few times. So finding link to mach5 
job should be possible. Most of the
intermittent failures are not reproducible locally, so that should not really 
counts here. Anyway, if you think it is
all that can be done here, please go ahead with the exiting reviews or when 
someone else reviews.

Thanks,
Pankaj

-

PR: https://git.openjdk.java.net/jdk/pull/535

Re: RFR: 8254112: javax/swing/plaf/basic/BasicComboPopup/JComboBoxPopupLocation/JComboBoxPopupLocation.java fails on windows [v2]

[Pankaj Bansal]

On Fri, 9 Oct 2020 06:45:03 GMT, Tejpal Rebari  wrote:

>> Prasanta Sadhukhan has updated the pull request with a new target base due 
>> to a merge or a rebase. The pull request now
>> contains two commits:
>>  - Merge master
>>  - 8254112: 
>> javax/swing/plaf/basic/BasicComboPopup/JComboBoxPopupLocation/JComboBoxPopupLocation.java
>>  fails on windows
>
> Marked as reviewed by trebari (Author).

Hello Prasanta,

Should not we try to find what has changed that test was failing few days back 
and is passing now. Is it sure that it
will not fail again like mentioned in 
https://bugs.openjdk.java.net/browse/JDK-8238720, specially when nothing is
really being changed here. It can be an intermittent failure and may fail again 
even though passing in mach5 job you
have run.

-

PR: https://git.openjdk.java.net/jdk/pull/535

Re: RFR: 8253606: Need to add missed constructor to the SwingEventMonitor

[Pankaj Bansal]

On Thu, 24 Sep 2020 17:08:31 GMT, Sergey Bylokhov  wrote:

> The javadoc for the constructor in this class was added, but the constructor 
> itsef is missed..

Marked as reviewed by pbansal (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/340

Integrated: 8252194: Add automated test for fix done in JDK-8218469

[Pankaj Bansal]

On Sun, 27 Sep 2020 16:44:12 GMT, Pankaj Bansal  wrote:

> Under JDK-8218469, fix was made to correct the rendering of JSlider as the 
> Slider knob/head was not being rendered at
> all. The reason was that gtk3 changed the way styles are used. No automated 
> test was written to verify the results.
> Current bug is to write the automated tests for the same. I have verified 
> that the test fails without the fix done for
> DK-8218469 and passes with the fix.

This pull request has now been integrated.

Changeset: 1ae6b533
Author:Pankaj Bansal 
URL:   https://git.openjdk.java.net/jdk/commit/1ae6b533
Stats: 148 lines in 1 file changed: 148 ins; 0 del; 0 mod

8252194: Add automated test for fix done in JDK-8218469

Reviewed-by: serb, jdv, kizune

-

PR: https://git.openjdk.java.net/jdk/pull/374

Re: RFR: 6514600: AbstractAction can throw NullPointerException when clone()d

[Pankaj Bansal]

On Mon, 28 Sep 2020 07:52:20 GMT, Prasanta Sadhukhan  
wrote:

> Please review a fix for an issue whereby it is seen that AbstractAction which 
> has had its values clear()ed or nulled
> fails to clone and throws NPE. This is because AbstractAction contains an 
> inner class ArrayTable, whose 'table' field
> is lazily instantiated, and nulled on clear(), and thus can be null. The 
> clone() method assumes it is not null.
> Proposed fix is to add a check for null for "table" field in clone().

Looks good to me

-

Marked as reviewed by pbansal (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/377

Re: RFR: 8252194: Add automated test for fix done in JDK-8218469

[Pankaj Bansal]

Hi Alex,

Thanks for the review.

On 27/09/20 11:27 PM, Alexander Zuev wrote:

Hi Pankaj,

  in your test you have both
  * @requires (os.family == "linux")
and
  if (!System.getProperty("os.name").startsWith("Linux")) {
  System.out.println("This test is meant for Linux platform only");
  return;
  }
Isn't it a little bit overkill?

This has been discussed earlier for some other test. The logic is that, 
if the test is run under jtreg, the test would not be run/scheduled at 
all due to @requires tag on non-linux platforms. If the test is run as 
standalone test, the test will start but the "if" condition should stop 
the test.


Regards,
Pankaj


Otherwise looks good.

/Alex

On 9/27/2020 9:51 AM, Pankaj Bansal wrote:

Under JDK-8218469, fix was made to correct the rendering of JSlider as the 
Slider knob/head was not being rendered at
all. The reason was that gtk3 changed the way styles are used. No automated 
test was written to verify the results.
Current bug is to write the automated tests for the same. I have verified that 
the test fails without the fix done for
DK-8218469 and passes with the fix.

-

Commit messages:
  - Add automated test for fix done in JDK-8218469

Changes:https://git.openjdk.java.net/jdk/pull/374/files
  Webrev:https://webrevs.openjdk.java.net/?repo=jdk=374=00
   Issue:https://bugs.openjdk.java.net/browse/JDK-8252194
   Stats: 148 lines in 1 file changed: 148 ins; 0 del; 0 mod
   Patch:https://git.openjdk.java.net/jdk/pull/374.diff
   Fetch: git fetchhttps://git.openjdk.java.net/jdk  pull/374/head:pull/374

PR:https://git.openjdk.java.net/jdk/pull/374

RFR: 8252194: Add automated test for fix done in JDK-8218469

[Pankaj Bansal]

Under JDK-8218469, fix was made to correct the rendering of JSlider as the 
Slider knob/head was not being rendered at
all. The reason was that gtk3 changed the way styles are used. No automated 
test was written to verify the results.
Current bug is to write the automated tests for the same. I have verified that 
the test fails without the fix done for
DK-8218469 and passes with the fix.

-

Commit messages:
 - Add automated test for fix done in JDK-8218469

Changes: https://git.openjdk.java.net/jdk/pull/374/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=374=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252194
  Stats: 148 lines in 1 file changed: 148 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/374.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/374/head:pull/374

PR: https://git.openjdk.java.net/jdk/pull/374

Integrated: 8252825: Add automated test for fix done in JDK-8218479

[Pankaj Bansal]

On Sun, 6 Sep 2020 15:21:45 GMT, Pankaj Bansal  wrote:

> Under JDK-8218479, fix was made to correct the rendering of JTextPane as the 
> background color of JTextPane was similar
> to Panel color, so it looked like the JTextPane has transparent background. 
> No automated test was written to verify the
> results. Current bug is to write the automated tests for the same.  The test 
> fails without the fix done in JDK-8218479
> and pass with the fix. I have run the tests multiple times in mach5. Links in 
> JBS.

This pull request has now been integrated.

Changeset: 55c7e769
Author:Pankaj Bansal 
URL:   https://git.openjdk.java.net/jdk/commit/55c7e769
Stats: 140 lines in 1 file changed: 0 ins; 140 del; 0 mod

8252825: Add automated test for fix done in JDK-8218479

Reviewed-by: serb, prr

-

PR: https://git.openjdk.java.net/jdk/pull/30

RFR: 8252825: Add automated test for fix done in JDK-8218479

[Pankaj Bansal]

Under JDK-8218479, fix was made to correct the rendering of JTextPane as the 
background color of JTextPane was similar
to Panel color, so it looked like the JTextPane has transparent background. No 
automated test was written to verify the
results. Current bug is to write the automated tests for the same.

The test fails without the fix done in JDK-8218479 and pass with the fix. I 
have run the tests multiple times in mach5.
Links in JBS.

-

Commit messages:
 - 8252825: Add automated test for fix done in JDK-8218479

Changes: https://git.openjdk.java.net/jdk/pull/30/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=30=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252825
  Stats: 140 lines in 1 file changed: 140 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/30.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/30/head:pull/30

PR: https://git.openjdk.java.net/jdk/pull/30

Re: RFR: 8198334 java/awt/FileDialog/8003399/bug8003399.java fails in headless mode

[Pankaj Bansal]

+1. I assume you have run a mach5 job to confirm the tests are passing 
with the fix in JDK-8198335.


Regards,

Pankaj


On 31/08/20 9:46 AM, Sergey Bylokhov wrote:

Hello.
Please review the fix for jdk/client.

Bug: https://bugs.openjdk.java.net/browse/JDK-8198334
Fix: http://cr.openjdk.java.net/~serb/8198334/webrev.01

These tests were broken due to the product bug JDK-8198335 [1]
which was fixed in jdk11, so we can clean the problemList.

One tests required some additional clean up since it was mentioned
in another bug JDK-8213514 [2]

[1] https://bugs.openjdk.java.net/browse/JDK-8198335
[2] https://bugs.openjdk.java.net/browse/JDK-8213514

Re: RFR: 8249548: backward focus traversal gets stuck in button group

[Pankaj Bansal]

Hello Phil,

Thanks for looking at this.


On 29/08/20 12:07 AM, Philip Race wrote:

The protected method I see in BasicRadioButtonUI was added for
8033699: Incorrect radio button behavior
In JDK7u and had no CCC  / CSR that I can find and the change was made 
in an update release

So I don't think we need a CSR to remove it again.

I also saw that same method was added in AquaButtonRadioUI under 
JDK-8208640 in JDK11 and there is no CSR filled for that either. So I 
will be pushing this change without the CSR.


Regards,
Pankaj


-phil.

On 8/21/20, 8:03 PM, Sergey Bylokhov wrote:

Looks fine.

I am not sure, do we need to file CSR for removing protected methods 
in the subclass or not, please double-check.


On 26.07.2020 03:54, Pankaj Bansal wrote:

Hi All,

Please review the following fix for jdk16.

Bug : https://bugs.openjdk.java.net/browse/JDK-8249548
webrev: http://cr.openjdk.java.net/~pbansal/8249548/webrev00/ 
<http://cr.openjdk.java.net/%7Epbansal/8249548/webrev00/>


Issue: If few ToggleButtons are added to button group, the backward 
focus traversal can get stuck in few scenarios while using 
LayoutFocusTraversalPolicy. For exaple, if a TextField is added to a 
frame and a Button Group is added with two buttons and the second 
button in set selected, we can not move the focus from Button Group 
to Text Field using "Shift+Tab". More details in JBS.


Cause: The LayoutFocusTraversalPolicy uses 
SortingFocusTraversalPolicy always selects first button for focus 
traversal in button group for Toggle Button. This can be changed by 
Component if one of the button in the button group is set selected. 
This results in the selected Button being selected again and again 
for selection on pressing "Shift+Tab". This results in focus being 
stuck at same position. This is a generic issue and it is observed 
in all L for JToggleButton.


The JRadioButton does not have this issue as BasicRadioButtonUI and 
AquaRadioButtonUI have code to handle this issue but the Synth L 
has this issue for JRadioButton also. So, this issue can be observed 
in both ToggleButton and RadioButton in nimbus L


Fix: The fix is to add the code to handle this in BasicButtonUI 
class, so that it is available for all L without copying it in 
different L classes. The focus traversal works fine after this 
change for all L for both ToggleButton and RadioButton. Along with 
the current problem, this fix is also fixes issue like we cant 
change the selected button and focus in ToggleButton group like 
RadioButton group.


An automated test is added. I have ran the Mach5 with all tests and 
this is not causing any failures. Links in JBS.



Regards
Pankaj

RFR: 8251254: Add automated test for fix done in JDK-8218472

[Pankaj Bansal]

Hi All,

Please review this test only fix for jdk16

bug: https://bugs.openjdk.java.net/browse/JDK-8251254

webrev: http://cr.openjdk.java.net/~pbansal/8251254/webrev00/ 




UnderJDK-8218472 , fix 
was made to correct the highlight color for progress of JProgressBar as 
highlight/progress was not visible. No automated test was written to 
verify the results. Current bug is to write the automated tests for the 
same.
The test fails without the fix done in JDK-8218472 and pass with the 
fix. I have run the tests multiple times in mach5. Links in JBS.





Regards,

Pankaj

Re: RFR: 8022535 [TEST BUG] javax/swing/text/html/parser/Test8017492.java fails

[Pankaj Bansal]

looks good to me

-Pankaj


On 16/08/20 9:29 AM, Sergey Bylokhov wrote:

Hello.
Please review the fix for jdk/client.

Bug: https://bugs.openjdk.java.net/browse/JDK-8022535
Fix: http://cr.openjdk.java.net/~serb/8022535/webrev.00

The test manually uses AppContext on the custom thread and assume the
main thread has the "Main AppContext" by default, but it was removed a
long time ago,  NPE is a result of this.

The test should create it manually.

RFR: 8251252: Add automated testcase for fix done in JDK-8214253 for JToolTip

[Pankaj Bansal]

Hi All,

Please review this test only fix for jdk16

bug: https://bugs.openjdk.java.net/browse/JDK-8251252

webrev: http://cr.openjdk.java.net/~pbansal/8251252/webrev00/ 




UnderJDK-8214253 , fix 
was made to correct the background color of JTooltip as tooltip was 
looking transparent instead of having blackish background. No automated 
test was written to verify the results. Current bug is to write the 
automated test for the same.
The test fails without the fix done in JDK-8214253 and pass with the 
fix. I have run the tests multiple times in mach5. Links in JBS.





Regards,

Pankaj