Re: RFR: JDK-8273312 : [TESTBUG] sanity/client/SwingSet/src/ButtonDemoScreenshotTest.java fails intermittently on Windows OS.
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&F and the test passes on other L&Fs. I mean should not a bug be filled to investigate the reason for the same instead of excluding the Windows L&F from the tested L&Fs. - PR: https://git.openjdk.java.net/jdk/pull/5380
Re: RFR: 8272148: JDesktopPane:getComponentCount() returns one extra than expected with GTKLookAndFeel [v2]
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&F also, as some L&F may add some default components to a >> container, but other L&F 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]
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&F 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&Fs 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&Fs. 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.
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&F currently being used. That is what the current change is doing. If some L&F 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]
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&F. 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.
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.
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&pr=5263&range=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]
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&F 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]
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]
> 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&F also, as some L&F may add some default components to a > container, but other L&F 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&pr=5121&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5121&range=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
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&F also, as some L&F may add some default components to a > container, but other L&F 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
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&F 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&Fs 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&Fs. 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
On Thu, 19 Aug 2021 12:11:23 GMT, Prasanta Sadhukhan wrote: > > The "InternalFrame.useTaskBar" is set true in case of GTKL&F only, > > What if we set this property to false and only set under some condition for > GTK L&F, 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&F. 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&F. 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&F 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&Fs, 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
On Mon, 16 Aug 2021 19:11:43 GMT, Sergey Bylokhov wrote: > Can you please clarify why the GTK L&F is affected only? Synth L&F is adding a Taskbar in SynthDesktopPaneUI class if the "InternalFrame.useTaskBar" is set true. The "InternalFrame.useTaskBar" is set true in case of GTKL&F only, so this issue is happening. I think L&Fs are allowed to customize these things. I think this happening in GTK L&F is not really much to do with GTK L&F. This can happen for any default/custom container for any L&F 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
RFR: 8272148: JDesktopPane:getComponentCount() returns one extra than expected with GTKLookAndFeel
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&F also, as some L&F may add some default components to a container, but other L&F 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. - Commit messages: - 8272148: JDesktopPane:getComponentCount() returns one extra than expected with GTKLookAndFeel Changes: https://git.openjdk.java.net/jdk/pull/5121/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5121&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272148 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 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: 8272491: Problem list javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java on macos
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
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]
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]
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
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&F(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]
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]
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
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
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
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
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
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&pr=3832&range=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
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]
> 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&pr=3678&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3678&range=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]
> 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&pr=3678&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3678&range=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
RFR: 8163367: Test javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java javax/swing/JComboBox/8033069/bug8033069ScrollBar.java fails intermittently
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. - Commit messages: - Move frame to centre - 8163367: Test javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java javax/swing/JComboBox/8033069/bug8033069ScrollBar.java fails intermittently Changes: https://git.openjdk.java.net/jdk/pull/3678/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3678&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8163367 Stats: 32 lines in 2 files changed: 16 ins; 7 del; 9 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
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
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&pr=3518&range=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
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
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]
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
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]
> 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&pr=2874&range=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
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
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
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()
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&F: Cleanup duplicate checks in GTKStyle and GTKLookAndFeel [v2]
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&F: Cleanup duplicate checks in GTKStyle and GTKLookAndFeel
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]
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]
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]
> 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&pr=2874&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2874&range=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
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
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]
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
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
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
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
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&pr=2874&range=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
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]
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&Fs 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
On Sun, 14 Feb 2021 07:49:39 GMT, Pankaj Bansal wrote: > Please review a trivial test only fix. > > This is a GTKL&F 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&F 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]
> Please review a trivial test only fix. > > This is a GTKL&F 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&F 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&pr=2564&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2564&range=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]
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
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&F 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&pr=2564&range=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]
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:
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:
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.
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&Fs. This was wrong as there is a > difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F > and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not > performed on button selection and user has to press "space". In other L&Fs, > 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&Fs before JDK-8249548 fix, after JDK-8249548 fix > and after current fix. > > Before fix for JDK-8249548 > JToggleButton: > For all L&Fs, user can not navigate/select the buttons added to ButtonGroup > properly as mentioned in the JDK-8249548. > JRadioButton: > For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to > ButtonGroup. > For AquaL&F, 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&Fs, 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&Fs, 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&Fs, 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&Fs, user can navigate/select the buttons added to ButtonGroups. > User needs to press "space" to perform the set AbstractAction. > JRadioButton: > For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to > press the "space" to perform the set Action. > For all other L&Fs (including Synth L&F), 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]
> 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&Fs. This was wrong as there is a > difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F > and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not > performed on button selection and user has to press "space". In other L&Fs, > 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&Fs before JDK-8249548 fix, after JDK-8249548 fix > and after current fix. > > Before fix for JDK-8249548 > JToggleButton: > For all L&Fs, user can not navigate/select the buttons added to ButtonGroup > properly as mentioned in the JDK-8249548. > JRadioButton: > For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to > ButtonGroup. > For AquaL&F, 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&Fs, 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&Fs, 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&Fs, 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&Fs, user can navigate/select the buttons added to ButtonGroups. > User needs to press "space" to perform the set AbstractAction. > JRadioButton: > For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to > press the "space" to perform the set Action. > For all other L&Fs (including Synth L&F), 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&pr=99&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=99&range=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]
> 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&Fs. This was wrong as there is a > difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F > and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not > performed on button selection and user has to press "space". In other L&Fs, > 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&Fs before JDK-8249548 fix, after JDK-8249548 fix > and after current fix. > > Before fix for JDK-8249548 > JToggleButton: > For all L&Fs, user can not navigate/select the buttons added to ButtonGroup > properly as mentioned in the JDK-8249548. > JRadioButton: > For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to > ButtonGroup. > For AquaL&F, 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&Fs, 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&Fs, 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&Fs, 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&Fs, user can navigate/select the buttons added to ButtonGroups. > User needs to press "space" to perform the set AbstractAction. > JRadioButton: > For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to > press the "space" to perform the set Action. > For all other L&Fs (including Synth L&F), 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&pr=99&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=99&range=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]
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]
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&F skip the "space"? The AquaL&F also does not need the additional "space" press for JRadioButton. During the fix of JDK-8226892, code was added for other L&F, so that the additional "space" press is not needed. But same code was not added for AquaL&F. So, the additional key press was needed. Now, the additional press should not be needed for AquaL&F also for JRadioButton. So now, for all L&Fs, 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]
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&F > > 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]
> 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&Fs. This was wrong as there is a > difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F > and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not > performed on button selection and user has to press "space". In other L&Fs, > 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&Fs before JDK-8249548 fix, after JDK-8249548 fix > and after current fix. > > Before fix for JDK-8249548 > JToggleButton: > For all L&Fs, user can not navigate/select the buttons added to ButtonGroup > properly as mentioned in the JDK-8249548. > JRadioButton: > For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to > ButtonGroup. > For AquaL&F, 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&Fs, 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&Fs, 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&Fs, 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&Fs, user can navigate/select the buttons added to ButtonGroups. > User needs to press "space" to perform the set AbstractAction. > JRadioButton: > For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to > press the "space" to perform the set Action. > For all other L&Fs (including Synth L&F), 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&pr=99&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=99&range=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]
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]
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&Fs, user can not navigate/select the buttons added to > ButtonGroup properly as mentioned in the JDK-8249548. > JRadioButton: > For Synth L&F (Nimbus L&F), user can not navigate/select the buttons > added to ButtonGroup. > For AquaL&F, 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&Fs, user can select/navigate the buttons and the set Action > is also performed without pressing "space" I have removed the duplicate code for AquaL&F. I think during the fix made for JDK-8226892, it was a mistake to not change the AquaL&F code. So, the behaviour of JRadioButton should be similar across L&Fs and the duplicate code in AquaL&F 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]
> 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&Fs. This was wrong as there is a > difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F > and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not > performed on button selection and user has to press "space". In other L&Fs, > 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&Fs before JDK-8249548 fix, after JDK-8249548 fix > and after current fix. > > Before fix for JDK-8249548 > JToggleButton: > For all L&Fs, user can not navigate/select the buttons added to ButtonGroup > properly as mentioned in the JDK-8249548. > JRadioButton: > For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to > ButtonGroup. > For AquaL&F, 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&Fs, 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&Fs, 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&Fs, 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&Fs, user can navigate/select the buttons added to ButtonGroups. > User needs to press "space" to perform the set AbstractAction. > JRadioButton: > For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to > press the "space" to perform the set Action. > For all other L&Fs (including Synth L&F), 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&F - 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&pr=99&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=99&range=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]
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&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548. JRadioButton: For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. For AquaL&F, 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&Fs, 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]
> 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&Fs. This was wrong as there is a > difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F > and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not > performed on button selection and user has to press "space". In other L&Fs, > 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&Fs before JDK-8249548 fix, after JDK-8249548 fix > and after current fix. > > Before fix for JDK-8249548 > JToggleButton: > For all L&Fs, user can not navigate/select the buttons added to ButtonGroup > properly as mentioned in the JDK-8249548. > JRadioButton: > For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to > ButtonGroup. > For AquaL&F, 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&Fs, 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&Fs, 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&Fs, 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&Fs, user can navigate/select the buttons added to ButtonGroups. > User needs to press "space" to perform the set AbstractAction. > JRadioButton: > For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to > press the "space" to perform the set Action. > For all other L&Fs (including Synth L&F), 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&pr=99&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=99&range=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.
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&Fs. This was wrong as there is >> a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F >> and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not >> performed on button selection and user has to press "space". In other L&Fs, >> 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&Fs before JDK-8249548 fix, after JDK-8249548 >> fix and after current fix. >> >> Before fix for JDK-8249548 >> JToggleButton: >> For all L&Fs, user can not navigate/select the buttons added to ButtonGroup >> properly as mentioned in the JDK-8249548. >> JRadioButton: >> For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added >> to ButtonGroup. >> For AquaL&F, 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&Fs, 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&Fs, 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&Fs, 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&Fs, user can navigate/select the buttons added to ButtonGroups. >> User needs to press "space" to perform the set AbstractAction. >> JRadioButton: >> For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to >> press the "space" to perform the set Action. >> For all other L&Fs (including Synth L&F), 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]
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.
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&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, 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&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix. Before fix for JDK-8249548 JToggleButton: For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548. JRadioButton: For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. For AquaL&F, 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&Fs, 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&Fs, 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&Fs, 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&Fs, user can navigate/select the buttons added to ButtonGroups. User needs to press "space" to perform the set AbstractAction. JRadioButton: For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action. For all other L&Fs (including Synth L&F), 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&pr=99&range=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
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
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&Fs. > > It looks like this is done deliberately for AquaL&F 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
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: 8251177: [macosx] The text "big" is truncated
On Mon, 2 Nov 2020 11:16:32 GMT, Sergey Bylokhov wrote: > I meant to limit the font size in the tab-pane. ok, just for clarification, you mean this should be fixed as product bug not test issue? We should limit the font size in AquaJTabbedPaneUI, so that the text is not truncated? - PR: https://git.openjdk.java.net/jdk/pull/984
Re: RFR: 7124397: [macosx] JSpinner serialiazation - deserialization issue [v2]
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
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
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
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: 8251177: [macosx] The text "big" is truncated [v2]
> 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&Fs. > > It looks like this is done deliberately for AquaL&F 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. Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision: Fixing review comments - Changes: - all: https://git.openjdk.java.net/jdk/pull/984/files - new: https://git.openjdk.java.net/jdk/pull/984/files/e6e441e3..206a5db0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=984&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=984&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/984.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/984/head:pull/984 PR: https://git.openjdk.java.net/jdk/pull/984
RFR: 8251177: [macosx] The text "big" is truncated
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&Fs. It looks like this is done deliberately for AquaL&F 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. - Commit messages: - Remove test from ProblemList - 8251177: [macosx] The text big is truncated Changes: https://git.openjdk.java.net/jdk/pull/984/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=984&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251177 Stats: 4 lines in 2 files changed: 2 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/984.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/984/head:pull/984 PR: https://git.openjdk.java.net/jdk/pull/984
Re: RFR: 8015602: [macosx] Test javax/swing/SpringLayout/4726194/bug4726194.java fails on MacOSX [v2]
On Tue, 27 Oct 2020 07:10:31 GMT, Sergey Bylokhov wrote: >> The test fails on macOS when Aqua L&F 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&page=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&F 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
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
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]
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]
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
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
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
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
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&pr=374&range=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
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&pr=374&range=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
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
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&pr=30&range=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