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 >

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

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 ex

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

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 >>

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

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

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:

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 >> >>

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

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 o

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

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 is a "compound" element and it contains a text field and button, > what does the "getComponentCount" return in that case, wIll we hide internal >

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 only, > > What if we set this property to false and only set under some condition for > GTK L, what sort of problem we can expect? Does any jtreg/jck test gets >

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 is affected only? Synth L is adding a Taskbar in SynthDesktopPaneUI class if the "InternalFrame.useTaskBar" is set true. The "InternalFrame.useTaskBar" is set true in case of GTKL only, so this

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

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

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

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(https://bugs.openjdk.java.net/browse/JDK-8249674), This fixed > caused nimbus jtree default tree cell

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

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

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 dependin

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

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

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,

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

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 t

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

e 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 J

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

e 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 J

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. > &

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

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 > in

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? >>>

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

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:

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

gt; 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

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? >

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

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

Re: RFR: 8263977: GTK L: 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 >

Re: RFR: 8263977: GTK L: 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:

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 >> p

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:@&

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

gt; jframe.add(new JSlider()); > > jframe.setLocationRelativeTo(null); > jframe.pack(); > jframe.setVisible(true); > } > } Pankaj Bansal has updated the pull request incrementally with one addi

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

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

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

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

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

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).

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

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 specific manual test and create an instruction panel > containing JTextArea. The JTextArea background color is hardcoded as white > color, which is causing issu

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

as the text color is also white. The fix is to remove the hardcoded white > color as the JTextArea background color should be set by L and should not > be hardcoded in test. Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revisi

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 a84b6098bee8122abd15

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

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: > >

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

On Mon, 25 Jan 2021 07:08:33 GMT, Sergey Bylokhov wrote: > Obsolete/unused classes are removed. Marked as reviewed by pbansal (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2216

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

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

[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. Earl

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

, the behaviour before JDK-8249548 is restored, so user needs to > press the "space" to perform the set Action. > For all other L (including Synth L), the behaviour is same. User can > navigate/select the buttons added to ButtonGroups and set Action is performed > without pr

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

, the behaviour before JDK-8249548 is restored, so user needs to > press the "space" to perform the set Action. > For all other L (including Synth L), the behaviour is same. User can > navigate/select the buttons added to ButtonGroups and set Action is performed > without pr

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

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

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 > > test/jdk/javax/swing/ButtonGroup/TestButto

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

, the behaviour before JDK-8249548 is restored, so user needs to > press the "space" to perform the set Action. > For all other L (including Synth L), the behaviour is same. User can > navigate/select the buttons added to ButtonGroups and set Action is performed > without pr

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 >

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 sho

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

, the behaviour before JDK-8249548 is restored, so user needs to > press the "space" to perform the set Action. > For all other L (including Synth L), the behaviour is same. User can > navigate/select the buttons added to ButtonGroups and set Action is performed > without pr

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

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

, the behaviour before JDK-8249548 is restored, so user needs to > press the "space" to perform the set Action. > For all other L (including Synth L), the behaviour is same. User can > navigate/select the buttons added to ButtonGroups and set Action is performed > without pr

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

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

[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

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

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 th

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

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

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

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. -

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 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

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

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

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 >>

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: >>

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 writt

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

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

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 t

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

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

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

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

+1. I assume you have run a mach5 job to confirm the tests are passing with the fix in JDK-8198335. Regards, Pankaj On 31/08/20 9:46 AM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk/client. Bug: https://bugs.openjdk.java.net/browse/JDK-8198334 Fix:

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

fine. I am not sure, do we need to file CSR for removing protected methods in the subclass or not, please double-check. On 26.07.2020 03:54, Pankaj Bansal wrote: Hi All, Please review the following fix for jdk16. Bug : https://bugs.openjdk.java.net/browse/JDK-8249548 webrev: http

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

Hi All, Please review this test only fix for jdk16 bug: https://bugs.openjdk.java.net/browse/JDK-8251254 webrev: http://cr.openjdk.java.net/~pbansal/8251254/webrev00/ UnderJDK-8218472

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

looks good to me -Pankaj On 16/08/20 9:29 AM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk/client. Bug: https://bugs.openjdk.java.net/browse/JDK-8022535 Fix: http://cr.openjdk.java.net/~serb/8022535/webrev.00 The test manually uses AppContext on the custom thread and assume

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

Hi All, Please review this test only fix for jdk16 bug: https://bugs.openjdk.java.net/browse/JDK-8251252 webrev: http://cr.openjdk.java.net/~pbansal/8251252/webrev00/ UnderJDK-8214253

  1   2   3   >