From tejpal.rebari at oracle.com Thu Jul 2 05:21:59 2020 From: tejpal.rebari at oracle.com (Tejpal Rebari) Date: Thu, 2 Jul 2020 10:51:59 +0530 Subject: RFR: 8041705 Bugs in DefaultTreeCellRenderer.updateUI() In-Reply-To: References: Message-ID: Hi Prasanta, Thanks for the review. > On 29-Jun-2020, at 9:06 AM, Prasanta Sadhukhan wrote: > > Fix looks ok but I think the test should actually set "Tree.rendererMargins" value for NimbusL&F and check insets for other L&F is not same as nimbus when "Tree.rendererMargins" is reset to null. > I have modified the test to set ?Tree.rendererMargins? property for nimbus and check insets is not same as other L&F after ?Tree.rendererMargins? Is reset to null . I have verified that the test passes with the fix and fails without the fix. Mach5 link is in JBS. Update webrev : http://cr.openjdk.java.net/~trebari/swing/8041705/webrev01/ Regards Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From pankaj.b.bansal at oracle.com Thu Jul 2 08:35:16 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Thu, 2 Jul 2020 14:05:16 +0530 Subject: RFR: 8041705 Bugs in DefaultTreeCellRenderer.updateUI() In-Reply-To: References: Message-ID: Hello Tejpal, Few comments about the test 1. Remove all wild imports 2. Why do you need to create "lf" variable? Just call setLookAndFeel with L&F name 3. Dispose the frame in EDT thread in finally block 4. I am not able to understand the use of Robot in your program. Regards, Pankaj On 02/07/20 10:51 AM, Tejpal Rebari wrote: > Hi Prasanta, > > Thanks for the review. > >> On 29-Jun-2020, at 9:06 AM, Prasanta Sadhukhan >> > > wrote: >> >> Fix looks ok but I think the test should actually set >> "Tree.rendererMargins" value for NimbusL&F and check insets for other >> L&F is not same as nimbus when "Tree.rendererMargins" is reset to null. >> > I have modified the test to set ?Tree.rendererMargins? property for > nimbus and check > ?insets is not same as other L&F after ?Tree.rendererMargins? Is reset > to null > . > I have verified that the test passes with the fix and fails without > the fix. > Mach5 link is in JBS. > > Update webrev : > http://cr.openjdk.java.net/~trebari/swing/8041705/webrev01/ > > > Regards > Tejpal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tejpal.rebari at oracle.com Thu Jul 2 09:14:03 2020 From: tejpal.rebari at oracle.com (Tejpal Rebari) Date: Thu, 2 Jul 2020 14:44:03 +0530 Subject: RFR: 8041705 Bugs in DefaultTreeCellRenderer.updateUI() In-Reply-To: References: Message-ID: Hi Pankaj, Thanks for the review. > On 02-Jul-2020, at 2:05 PM, Pankaj Bansal wrote: > > Hello Tejpal, > > Few comments about the test > > 1. Remove all wild imports > > 2. Why do you need to create "lf" variable? Just call setLookAndFeel with L&F name > 3. Dispose the frame in EDT thread in finally block > Will update the test. > 4. I am not able to understand the use of Robot in your program. > I have added robot for the test stability in mach5. > Regards, > > Pankaj > Regards Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From tejpal.rebari at oracle.com Thu Jul 2 15:55:17 2020 From: tejpal.rebari at oracle.com (Tejpal Rebari) Date: Thu, 2 Jul 2020 21:25:17 +0530 Subject: RFR: 8041705 Bugs in DefaultTreeCellRenderer.updateUI() In-Reply-To: <164602176.7253.1593178364863.JavaMail.www@wwinf1p16> References: <164602176.7253.1593178364863.JavaMail.www@wwinf1p16> Message-ID: <9F2DA7FD-0962-4D5F-A13C-62435742BE0E@oracle.com> Hi gouessej, > On 26-Jun-2020, at 7:02 PM, gouessej at orange.fr wrote: > > Will this bug fix be backported into jdk11? > About the backport you should ask on jdk-updates-dev at openjdk.java.net once this bug is fixed in latest jdk. Regards Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From tejpal.rebari at oracle.com Tue Jul 7 05:23:16 2020 From: tejpal.rebari at oracle.com (Tejpal Rebari) Date: Tue, 7 Jul 2020 10:53:16 +0530 Subject: RFR: 8041705 Bugs in DefaultTreeCellRenderer.updateUI() In-Reply-To: References: Message-ID: <8F9950CF-451E-4484-BB35-4464FF8CEEE1@oracle.com> > On 02-Jul-2020, at 2:44 PM, Tejpal Rebari wrote: > > Hi Pankaj, > > Thanks for the review. > >> On 02-Jul-2020, at 2:05 PM, Pankaj Bansal > wrote: >> >> Hello Tejpal, >> >> Few comments about the test >> >> 1. Remove all wild imports >> >> 2. Why do you need to create "lf" variable? Just call setLookAndFeel with L&F name >> 3. Dispose the frame in EDT thread in finally block >> > Will update the test. Updated webrev : http://cr.openjdk.java.net/~trebari/swing/8041705/webrev02/ Regards Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From fctorial at gmail.com Wed Jul 8 04:31:33 2020 From: fctorial at gmail.com (Sagar Tiwari) Date: Wed, 8 Jul 2020 10:01:33 +0530 Subject: State of swing ecosystem Message-ID: Hi, I've been looking into swing gui programming and noticed that the projects depending on swing haven't been updated in many years (miglayout release 4.2 is from 2011), and many of the tutorials are from 5 years ago. Is it because the project has been "completed"? Are there any new software projects (applications, libraries) that build on top of swing/awt? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pankaj.b.bansal at oracle.com Wed Jul 8 07:00:44 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Wed, 8 Jul 2020 12:30:44 +0530 Subject: RFR: 8041705 Bugs in DefaultTreeCellRenderer.updateUI() In-Reply-To: <8F9950CF-451E-4484-BB35-4464FF8CEEE1@oracle.com> References: <8F9950CF-451E-4484-BB35-4464FF8CEEE1@oracle.com> Message-ID: Looks good to me -Pankaj On 07/07/20 10:53 AM, Tejpal Rebari wrote: > > >> On 02-Jul-2020, at 2:44 PM, Tejpal Rebari > > wrote: >> >> Hi Pankaj, >> >> Thanks for the review. >> >>> On 02-Jul-2020, at 2:05 PM, Pankaj Bansal >>> > wrote: >>> >>> Hello Tejpal, >>> >>> Few comments about the test >>> >>> 1. Remove all wild imports >>> >>> 2. Why do you need to create "lf" variable? Just call setLookAndFeel >>> with L&F name >>> >>> 3. Dispose the frame in EDT thread in finally block >>> >> Will update the test. > > Updated webrev : > http://cr.openjdk.java.net/~trebari/swing/8041705/webrev02/ > > > Regards > Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Jul 9 05:28:52 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 9 Jul 2020 10:58:52 +0530 Subject: RFR: 8041705 Bugs in DefaultTreeCellRenderer.updateUI() In-Reply-To: <8F9950CF-451E-4484-BB35-4464FF8CEEE1@oracle.com> References: <8F9950CF-451E-4484-BB35-4464FF8CEEE1@oracle.com> Message-ID: +1 Regards Prasanta On 07-Jul-20 10:53 AM, Tejpal Rebari wrote: > > >> On 02-Jul-2020, at 2:44 PM, Tejpal Rebari > > wrote: >> >> Hi Pankaj, >> >> Thanks for the review. >> >>> On 02-Jul-2020, at 2:05 PM, Pankaj Bansal >>> > wrote: >>> >>> Hello Tejpal, >>> >>> Few comments about the test >>> >>> 1. Remove all wild imports >>> >>> 2. Why do you need to create "lf" variable? Just call setLookAndFeel >>> with L&F name >>> >>> 3. Dispose the frame in EDT thread in finally block >>> >> Will update the test. > > Updated webrev : > http://cr.openjdk.java.net/~trebari/swing/8041705/webrev02/ > > Regards > Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Jul 9 08:14:37 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 9 Jul 2020 13:44:37 +0530 Subject: RFR JDK-8245785: javax.swing.JTabbedPane cannot be deserialized Message-ID: <3b13c335-a51e-7e77-04ea-f5a7dd97d933@oracle.com> Hi All, Please review a fix for an issue where deserializing a serialized JTabbedPane-object results in NullPointerException. The NPE is result of tabbed "pages" object not being instantiated when deserialized. Proposed fix is to add a null check for "pages" object. Bug: https://bugs.openjdk.java.net/browse/JDK-8245785 webrev: http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.0/ Regards Prasanta From prasanta.sadhukhan at oracle.com Thu Jul 9 08:36:26 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 9 Jul 2020 14:06:26 +0530 Subject: RFR JDK-8239907: Vertical White Line appears with JOptionPane.showMessageDialog using a JTextPane/JEditorPane Message-ID: Hi All, Please review a fix for an issue where a white line artifact is appearing in JOptionPane.showMessageDialog, This issue is a regression of JDK-8098835 where the caretMargin is added to TextPane width in getMaximumSize/getMinimumSize/getVisibleEditorRect The present issue stems from the fact that the visibleEditorRect() actually subtracts the caret margin instead of adding to the text pane width. Proposed fix is to add the caret margin width rather than subtracting, to the actual width. Bug: https://bugs.openjdk.java.net/browse/JDK-8239907 webrev: http://cr.openjdk.java.net/~psadhukhan/8239907/webrev.0/ Regards Prasanta From Sergey.Bylokhov at oracle.com Thu Jul 9 09:58:05 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 9 Jul 2020 02:58:05 -0700 Subject: RFR JDK-8245785: javax.swing.JTabbedPane cannot be deserialized In-Reply-To: <3b13c335-a51e-7e77-04ea-f5a7dd97d933@oracle.com> References: <3b13c335-a51e-7e77-04ea-f5a7dd97d933@oracle.com> Message-ID: <2755c43b-0693-94f3-095d-eb4465cfe275@oracle.com> Hi, Prasanta. Why the "pages" object is not instantiated when deserialized? What will happen if the JTabbedPane will have a few(more than zero) pages before deserialization, will all pages be serialized/deserialized in this case? On 09.07.2020 01:14, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue where deserializing a serialized JTabbedPane-object results in NullPointerException. > > The NPE is result of tabbed "pages" object not being instantiated when deserialized. > > Proposed fix is to add a null check for "pages" object. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8245785 > > webrev: http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.0/ > > Regards > Prasanta -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu Jul 9 10:13:17 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 9 Jul 2020 03:13:17 -0700 Subject: RFR JDK-8239907: Vertical White Line appears with JOptionPane.showMessageDialog using a JTextPane/JEditorPane In-Reply-To: References: Message-ID: Hi, Prasanta Looks like another sequence of regressions =((( Can you please check implementation of these fixes: 1) http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ffe817b77f6a 2) http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/66c4f0fdd33d 3) http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b8ad62596d8f All of them calculate the size of the component in this way: "width + i.left + i.right + caretMargin" or "d.width - i.left - i.right - caretMargin" And in the current fix you suggest to change this in one place to "width - i.left - i.right + caretMargin" Could you please provide more details why it is necessary to do in this place only? On 09.07.2020 01:36, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue where a white line artifact is appearing in JOptionPane.showMessageDialog, > > This issue is a regression of JDK-8098835 where the caretMargin is added to TextPane width in getMaximumSize/getMinimumSize/getVisibleEditorRect > > The present issue stems from the fact that the visibleEditorRect() actually subtracts the caret margin instead of adding to the text pane width. > > Proposed fix is to add the caret margin width rather than subtracting, to the actual width. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8239907 > > webrev: http://cr.openjdk.java.net/~psadhukhan/8239907/webrev.0/ > > Regards > Prasanta -- Best regards, Sergey. From tejpal.rebari at oracle.com Thu Jul 9 11:24:19 2020 From: tejpal.rebari at oracle.com (Tejpal Rebari) Date: Thu, 9 Jul 2020 16:54:19 +0530 Subject: RFR: 8041701 Nimbus JTree renderer properties persist across L&F changes Message-ID: Hi All, Please review the following fix for jdk16. Bug : https://bugs.openjdk.java.net/browse/JDK-8041701 Webrev : http://cr.openjdk.java.net/~trebari/swing/8041701/webrev00/ Issue : UI properties ?Tree.leafIcon?, ?Tree.closedIcon?, ?Tree.openIcon?, ?Tree.selectionForeground? ..etc are supposed to be instances of UIResource if they are defined by LAF. In Nimbus LAF all the above properties are defined , but none of them implement UIResource, this causes them to persists when LAF is changed. Fix : Fix is to make NimbusLookAndFeel classes instance of UIResource, which uses above mentioned UI Properties. Test : Added an automated test. Tested on all the three platforms. Mach5 link is in JBS. Regards Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Jul 9 13:26:06 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 9 Jul 2020 18:56:06 +0530 Subject: RFR JDK-8245785: javax.swing.JTabbedPane cannot be deserialized In-Reply-To: <2755c43b-0693-94f3-095d-eb4465cfe275@oracle.com> References: <3b13c335-a51e-7e77-04ea-f5a7dd97d933@oracle.com> <2755c43b-0693-94f3-095d-eb4465cfe275@oracle.com> Message-ID: <811a6058-edda-8cb3-47a0-fc91887644e7@oracle.com> Hi Sergey, It seems "pages" object is not instantiated as readObject() did not read the object. I have modified the code to read the "pages" object after deserialization and now if JTabbedPane has few tabs/pages, all are deserialized. This is also tested in the testcase. http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.1/ Regards Prasanta On 09-Jul-20 3:28 PM, Sergey Bylokhov wrote: > Hi, Prasanta. > > Why the "pages" object is not instantiated when deserialized? What > will happen if the JTabbedPane > will have a few(more than zero) pages before deserialization, will all > pages be serialized/deserialized in this case? > > On 09.07.2020 01:14, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for an issue where deserializing a serialized >> JTabbedPane-object results in NullPointerException. >> >> The NPE is result of tabbed "pages" object not being instantiated >> when deserialized. >> >> Proposed fix is to add a null check for "pages" object. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8245785 >> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.0/ >> >> Regards >> Prasanta > > From Sergey.Bylokhov at oracle.com Sat Jul 11 06:11:12 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 10 Jul 2020 23:11:12 -0700 Subject: RFR: 8041701 Nimbus JTree renderer properties persist across L&F changes In-Reply-To: References: Message-ID: <058b841b-11f4-2827-4049-1c9340d84aa2@oracle.com> Hi, Tejpal. The fix looks fine, could you please update the test to check that all installed L&F work the same way. On 09.07.2020 04:24, Tejpal Rebari wrote: > Hi All, > Please review the following fix for jdk16. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8041701 > Webrev : http://cr.openjdk.java.net/~trebari/swing/8041701/webrev00/ > > Issue : UI properties ?Tree.leafIcon?, ?Tree.closedIcon?, ?Tree.openIcon?, > ?Tree.selectionForeground??..etc are supposed to be instances of UIResource > if they are?defined by LAF. > > In Nimbus LAF all the above properties are defined , but none of them implement > UIResource, this causes them to?persists when LAF is changed. > > Fix : Fix is to make NimbusLookAndFeel classes instance of UIResource, > which?uses?above mentioned UI Properties. > > Test : Added an automated test. > Tested on all the three platforms. Mach5 link is in JBS. > > > Regards > Tejpal -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Sat Jul 11 06:15:44 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 10 Jul 2020 23:15:44 -0700 Subject: RFR JDK-8245785: javax.swing.JTabbedPane cannot be deserialized In-Reply-To: <811a6058-edda-8cb3-47a0-fc91887644e7@oracle.com> References: <3b13c335-a51e-7e77-04ea-f5a7dd97d933@oracle.com> <2755c43b-0693-94f3-095d-eb4465cfe275@oracle.com> <811a6058-edda-8cb3-47a0-fc91887644e7@oracle.com> Message-ID: On 09.07.2020 06:26, Prasanta Sadhukhan wrote: > Hi Sergey, > > It seems "pages" object is not instantiated as readObject() did not read the object. I have modified the code to read the "pages" object after deserialization and now Do not need to change the getTabCount() since the pages will be non-null? It looks like this is the regression of JDK-8038937, could you please check other fields as well, probably something is missing as well. > > if JTabbedPane has few tabs/pages, all are deserialized. This is also tested in the testcase. > > http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.1/ > > Regards > Prasanta > On 09-Jul-20 3:28 PM, Sergey Bylokhov wrote: >> Hi, Prasanta. >> >> Why the "pages" object is not instantiated when deserialized? What will happen if the JTabbedPane >> will have a few(more than zero) pages before deserialization, will all pages be serialized/deserialized in this case? >> >> On 09.07.2020 01:14, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for an issue where deserializing a serialized JTabbedPane-object results in NullPointerException. >>> >>> The NPE is result of tabbed "pages" object not being instantiated when deserialized. >>> >>> Proposed fix is to add a null check for "pages" object. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8245785 >>> >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.0/ >>> >>> Regards >>> Prasanta >> >> -- Best regards, Sergey. From tejpal.rebari at oracle.com Sat Jul 11 09:40:14 2020 From: tejpal.rebari at oracle.com (Tejpal Rebari) Date: Sat, 11 Jul 2020 15:10:14 +0530 Subject: RFR: 8041701 Nimbus JTree renderer properties persist across L&F changes In-Reply-To: <058b841b-11f4-2827-4049-1c9340d84aa2@oracle.com> References: <058b841b-11f4-2827-4049-1c9340d84aa2@oracle.com> Message-ID: Hi Sergey, Thanks for the review. > On 11-Jul-2020, at 11:41 AM, Sergey Bylokhov wrote: > > Hi, Tejpal. > > The fix looks fine, could you please update the test to check that all installed L&F work the same way. I have updated the test to check for all installed LAF. Updated webrev : http://cr.openjdk.java.net/~trebari/swing/8041701/webrev01/ Tested on all there platform. Mach5 link is in JBS. Regards Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Sun Jul 12 05:42:58 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 11 Jul 2020 22:42:58 -0700 Subject: RFR: 8041701 Nimbus JTree renderer properties persist across L&F changes In-Reply-To: References: <058b841b-11f4-2827-4049-1c9340d84aa2@oracle.com> Message-ID: <6f274b2c-d1e3-54f1-ab8c-a5c39b717d43@oracle.com> Looks fine. On 11.07.2020 02:40, Tejpal Rebari wrote: > Hi Sergey, > Thanks for the review. > >> On 11-Jul-2020, at 11:41 AM, Sergey Bylokhov > wrote: >> >> Hi, Tejpal. >> >> The fix looks fine, could you please update the test to check that all installed L&F work the same way. > I have updated the test to check for all installed LAF. > Updated webrev : http://cr.openjdk.java.net/~trebari/swing/8041701/webrev01/ > > Tested on all there platform. > Mach5 link is in JBS. > > Regards > Tejpal -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Sun Jul 12 06:05:46 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Sun, 12 Jul 2020 11:35:46 +0530 Subject: RFR JDK-8245785: javax.swing.JTabbedPane cannot be deserialized In-Reply-To: References: <3b13c335-a51e-7e77-04ea-f5a7dd97d933@oracle.com> <2755c43b-0693-94f3-095d-eb4465cfe275@oracle.com> <811a6058-edda-8cb3-47a0-fc91887644e7@oracle.com> Message-ID: <8a6c7395-d034-c120-8bff-816b875fa937@oracle.com> On 11-Jul-20 11:45 AM, Sergey Bylokhov wrote: > On 09.07.2020 06:26, Prasanta Sadhukhan wrote: >> Hi Sergey, >> >> It seems "pages" object is not instantiated as readObject() did not >> read the object. I have modified the code to read the "pages" object >> after deserialization and now > > Do not need to change the getTabCount() since the pages will be non-null? > It looks like this is the regression of JDK-8038937, could you please > check > other fields as well, probably something is missing as well. It's just a null check so I guess we can keep getTabCount() check in-place. Also, there are no other fields is missing which is required. Regards Prasanta > >> >> if JTabbedPane has few tabs/pages, all are deserialized. This is also >> tested in the testcase. >> >> http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.1/ >> >> Regards >> Prasanta >> On 09-Jul-20 3:28 PM, Sergey Bylokhov wrote: >>> Hi, Prasanta. >>> >>> Why the "pages" object is not instantiated when deserialized? What >>> will happen if the JTabbedPane >>> will have a few(more than zero) pages before deserialization, will >>> all pages be serialized/deserialized in this case? >>> >>> On 09.07.2020 01:14, Prasanta Sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a fix for an issue where deserializing a serialized >>>> JTabbedPane-object results in NullPointerException. >>>> >>>> The NPE is result of tabbed "pages" object not being instantiated >>>> when deserialized. >>>> >>>> Proposed fix is to add a null check for "pages" object. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8245785 >>>> >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.0/ >>>> >>>> Regards >>>> Prasanta >>> >>> > > From prasanta.sadhukhan at oracle.com Sun Jul 12 06:28:51 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Sun, 12 Jul 2020 11:58:51 +0530 Subject: RFR: 8041701 Nimbus JTree renderer properties persist across L&F changes In-Reply-To: References: <058b841b-11f4-2827-4049-1c9340d84aa2@oracle.com> Message-ID: <31ba4e4a-9d1f-83f1-b253-1457529243f1@oracle.com> +1 On 11-Jul-20 3:10 PM, Tejpal Rebari wrote: > Hi Sergey, > Thanks for the review. > >> On 11-Jul-2020, at 11:41 AM, Sergey Bylokhov >> > wrote: >> >> Hi, Tejpal. >> >> The fix looks fine, could you please update the test to check that >> all installed L&F work the same way. > I have updated the test to check for all installed LAF. > Updated webrev : > http://cr.openjdk.java.net/~trebari/swing/8041701/webrev01/ > > Tested on all there platform. > Mach5 link is in JBS. > > Regards > Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Jul 13 06:00:05 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 12 Jul 2020 23:00:05 -0700 Subject: RFR JDK-8245785: javax.swing.JTabbedPane cannot be deserialized In-Reply-To: <8a6c7395-d034-c120-8bff-816b875fa937@oracle.com> References: <3b13c335-a51e-7e77-04ea-f5a7dd97d933@oracle.com> <2755c43b-0693-94f3-095d-eb4465cfe275@oracle.com> <811a6058-edda-8cb3-47a0-fc91887644e7@oracle.com> <8a6c7395-d034-c120-8bff-816b875fa937@oracle.com> Message-ID: <9c4e88a5-56ca-439a-cd44-a7dccd4ea9d1@oracle.com> On 11.07.2020 23:05, Prasanta Sadhukhan wrote: > > It's just a null check so I guess we can keep getTabCount() check in-place. Also, there are no other fields is missing which is required. But as far as I understand this check is not needed, the field initialized to non-null value in the constructor. And should not be null after deserialization, otherwise, you will need to add the null checks in every place where the field is used. > > Regards > Prasanta >> >>> >>> if JTabbedPane has few tabs/pages, all are deserialized. This is also tested in the testcase. >>> >>> http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.1/ >>> >>> Regards >>> Prasanta >>> On 09-Jul-20 3:28 PM, Sergey Bylokhov wrote: >>>> Hi, Prasanta. >>>> >>>> Why the "pages" object is not instantiated when deserialized? What will happen if the JTabbedPane >>>> will have a few(more than zero) pages before deserialization, will all pages be serialized/deserialized in this case? >>>> >>>> On 09.07.2020 01:14, Prasanta Sadhukhan wrote: >>>>> Hi All, >>>>> >>>>> Please review a fix for an issue where deserializing a serialized JTabbedPane-object results in NullPointerException. >>>>> >>>>> The NPE is result of tabbed "pages" object not being instantiated when deserialized. >>>>> >>>>> Proposed fix is to add a null check for "pages" object. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8245785 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.0/ >>>>> >>>>> Regards >>>>> Prasanta >>>> >>>> >> >> -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Mon Jul 13 14:10:40 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 13 Jul 2020 19:40:40 +0530 Subject: RFR JDK-8245785: javax.swing.JTabbedPane cannot be deserialized In-Reply-To: <9c4e88a5-56ca-439a-cd44-a7dccd4ea9d1@oracle.com> References: <3b13c335-a51e-7e77-04ea-f5a7dd97d933@oracle.com> <2755c43b-0693-94f3-095d-eb4465cfe275@oracle.com> <811a6058-edda-8cb3-47a0-fc91887644e7@oracle.com> <8a6c7395-d034-c120-8bff-816b875fa937@oracle.com> <9c4e88a5-56ca-439a-cd44-a7dccd4ea9d1@oracle.com> Message-ID: <283a4a4d-eb39-ee3d-f9d7-f403e6ba5e64@oracle.com> On 13-Jul-20 11:30 AM, Sergey Bylokhov wrote: > On 11.07.2020 23:05, Prasanta Sadhukhan wrote: >> >> It's just a null check so I guess we can keep getTabCount() check >> in-place. Also, there are no other fields is missing which is required. > > But as far as I understand this check is not needed, the field > initialized to non-null > value in the constructor. And should not be null after > deserialization, otherwise, you > will need to add the null checks in every place where the field is used. > OK. Null check removed http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.2/ Regards Prasanta >> >> Regards >> Prasanta >>> >>>> >>>> if JTabbedPane has few tabs/pages, all are deserialized. This is >>>> also tested in the testcase. >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.1/ >>>> >>>> Regards >>>> Prasanta >>>> On 09-Jul-20 3:28 PM, Sergey Bylokhov wrote: >>>>> Hi, Prasanta. >>>>> >>>>> Why the "pages" object is not instantiated when deserialized? What >>>>> will happen if the JTabbedPane >>>>> will have a few(more than zero) pages before deserialization, will >>>>> all pages be serialized/deserialized in this case? >>>>> >>>>> On 09.07.2020 01:14, Prasanta Sadhukhan wrote: >>>>>> Hi All, >>>>>> >>>>>> Please review a fix for an issue where deserializing a serialized >>>>>> JTabbedPane-object results in NullPointerException. >>>>>> >>>>>> The NPE is result of tabbed "pages" object not being instantiated >>>>>> when deserialized. >>>>>> >>>>>> Proposed fix is to add a null check for "pages" object. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8245785 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.0/ >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>> >>>>> >>> >>> > > From philip.race at oracle.com Mon Jul 13 14:37:19 2020 From: philip.race at oracle.com (Philip Race) Date: Mon, 13 Jul 2020 07:37:19 -0700 Subject: RFR JDK-8245785: javax.swing.JTabbedPane cannot be deserialized In-Reply-To: <283a4a4d-eb39-ee3d-f9d7-f403e6ba5e64@oracle.com> References: <3b13c335-a51e-7e77-04ea-f5a7dd97d933@oracle.com> <2755c43b-0693-94f3-095d-eb4465cfe275@oracle.com> <811a6058-edda-8cb3-47a0-fc91887644e7@oracle.com> <8a6c7395-d034-c120-8bff-816b875fa937@oracle.com> <9c4e88a5-56ca-439a-cd44-a7dccd4ea9d1@oracle.com> <283a4a4d-eb39-ee3d-f9d7-f403e6ba5e64@oracle.com> Message-ID: <5F0C719F.3050403@oracle.com> The regression test needs some clean up. It seems to be a copy+paste of the submitter's test case including the comment in German which can be removed. Also IMO all the English comments are stating the obvious and don't need to be there. And use ByteArray based streams not File streams. There are fewer clean up issues if you do that. -phil. On 7/13/20, 7:10 AM, Prasanta Sadhukhan wrote: > > On 13-Jul-20 11:30 AM, Sergey Bylokhov wrote: >> On 11.07.2020 23:05, Prasanta Sadhukhan wrote: >>> >>> It's just a null check so I guess we can keep getTabCount() check >>> in-place. Also, there are no other fields is missing which is required. >> >> But as far as I understand this check is not needed, the field >> initialized to non-null >> value in the constructor. And should not be null after >> deserialization, otherwise, you >> will need to add the null checks in every place where the field is used. >> > OK. Null check removed > http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.2/ > > Regards > Prasanta >>> >>> Regards >>> Prasanta >>>> >>>>> >>>>> if JTabbedPane has few tabs/pages, all are deserialized. This is >>>>> also tested in the testcase. >>>>> >>>>> http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.1/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 09-Jul-20 3:28 PM, Sergey Bylokhov wrote: >>>>>> Hi, Prasanta. >>>>>> >>>>>> Why the "pages" object is not instantiated when deserialized? >>>>>> What will happen if the JTabbedPane >>>>>> will have a few(more than zero) pages before deserialization, >>>>>> will all pages be serialized/deserialized in this case? >>>>>> >>>>>> On 09.07.2020 01:14, Prasanta Sadhukhan wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> Please review a fix for an issue where deserializing a >>>>>>> serialized JTabbedPane-object results in NullPointerException. >>>>>>> >>>>>>> The NPE is result of tabbed "pages" object not being >>>>>>> instantiated when deserialized. >>>>>>> >>>>>>> Proposed fix is to add a null check for "pages" object. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8245785 >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.0/ >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>> >>>>>> >>>> >>>> >> >> From pankaj.b.bansal at oracle.com Mon Jul 13 18:30:28 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Tue, 14 Jul 2020 00:00:28 +0530 Subject: RFR: 8249251: [dark_mode ubuntu 20.04] The selected menu is not highlighted in GTKLookAndFeel Message-ID: <67f741bb-7371-0d84-2278-1d78cb081df2@oracle.com> Hi All, Please review the following fix for jdk15. Bug : https://bugs.openjdk.java.net/browse/JDK-8249251 webrev: http://cr.openjdk.java.net/~pbansal/8249251/webrev01/ Issue: In Ubuntu 20.04 in dark mode, the selected Menu is not being highlighted properly. so, there is no difference between selected and unselected Menu. The issue can be reproduced by running Swingset2 or using the test added in fix. Cause: In dark mode, the highlight color for Menu is not visible over the dark background color for the Menubar. So, the highlight is not visible properly and it looks like there is no highlight being drawn. Fix: The fix is to use some color for highlighting, which will be properly visible. We have taken the background color for selected text. This color is is visible over the dark Background easily. The fix is tested on Ubuntu 18.04, Ubuntu 20.04 and OL 8.2. Added an automated test to verify that the highlight color is same as background color for selected text. The test passes on mach5 with multiple iterations. Link added in JBS. Regards Pankaj From philip.race at oracle.com Mon Jul 13 20:58:52 2020 From: philip.race at oracle.com (Philip Race) Date: Mon, 13 Jul 2020 13:58:52 -0700 Subject: RFR: 8249251: [dark_mode ubuntu 20.04] The selected menu is not highlighted in GTKLookAndFeel In-Reply-To: <67f741bb-7371-0d84-2278-1d78cb081df2@oracle.com> References: <67f741bb-7371-0d84-2278-1d78cb081df2@oracle.com> Message-ID: <5F0CCB0C.40707@oracle.com> Looks OK although it is a workaround and we may some day find some case in which the result although legible might differ from the native colours. And I think we do have a bug already on the subject of re-doing this properly by reading the CSS ?? -phil. On 7/13/20, 11:30 AM, Pankaj Bansal wrote: > Hi All, > > Please review the following fix for jdk15. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8249251 > webrev: http://cr.openjdk.java.net/~pbansal/8249251/webrev01/ > > > Issue: In Ubuntu 20.04 in dark mode, the selected Menu is not being > highlighted properly. so, there is no difference between selected and > unselected Menu. The issue can be reproduced by running Swingset2 or > using the test added in fix. > > Cause: In dark mode, the highlight color for Menu is not visible over > the dark background color for the Menubar. So, the highlight is not > visible properly and it looks like there is no highlight being drawn. > > Fix: The fix is to use some color for highlighting, which will be > properly visible. We have taken the background color for selected > text. This color is is visible over the dark Background easily. The > fix is tested on Ubuntu 18.04, Ubuntu 20.04 and OL 8.2. > > Added an automated test to verify that the highlight color is same as > background color for selected text. The test passes on mach5 with > multiple iterations. Link added in JBS. > > > Regards > Pankaj > From pankaj.b.bansal at oracle.com Tue Jul 14 05:48:22 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Tue, 14 Jul 2020 11:18:22 +0530 Subject: RFR: 8249251: [dark_mode ubuntu 20.04] The selected menu is not highlighted in GTKLookAndFeel In-Reply-To: <5F0CCB0C.40707@oracle.com> References: <67f741bb-7371-0d84-2278-1d78cb081df2@oracle.com> <5F0CCB0C.40707@oracle.com> Message-ID: <59223511-cdef-9c76-bb23-7911c7b03b1f@oracle.com> Hello Phil, Thanks for the review. < Looks OK although it is a workaround and we may some day find some case > in which the result although legible might differ from the native > colours. > > And I think we do have a bug already on the subject of re-doing > this properly by reading the CSS ?? > > -phil. > > > On 7/13/20, 11:30 AM, Pankaj Bansal wrote: >> Hi All, >> >> Please review the following fix for jdk15. >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8249251 >> webrev: http://cr.openjdk.java.net/~pbansal/8249251/webrev01/ >> >> >> Issue: In Ubuntu 20.04 in dark mode, the selected Menu is not being >> highlighted properly. so, there is no difference between selected and >> unselected Menu. The issue can be reproduced by running Swingset2 or >> using the test added in fix. >> >> Cause: In dark mode, the highlight color for Menu is not visible over >> the dark background color for the Menubar. So, the highlight is not >> visible properly and it looks like there is no highlight being drawn. >> >> Fix: The fix is to use some color for highlighting, which will be >> properly visible. We have taken the background color for selected >> text. This color is is visible over the dark Background easily. The >> fix is tested on Ubuntu 18.04, Ubuntu 20.04 and OL 8.2. >> >> Added an automated test to verify that the highlight color is same as >> background color for selected text. The test passes on mach5 with >> multiple iterations. Link added in JBS. >> >> >> Regards >> Pankaj >> From Sergey.Bylokhov at oracle.com Tue Jul 14 07:13:57 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 14 Jul 2020 00:13:57 -0700 Subject: RFR: 8249251: [dark_mode ubuntu 20.04] The selected menu is not highlighted in GTKLookAndFeel In-Reply-To: <67f741bb-7371-0d84-2278-1d78cb081df2@oracle.com> References: <67f741bb-7371-0d84-2278-1d78cb081df2@oracle.com> Message-ID: Hi, Pankaj. A few notes about the fix and test: - The usage of textarea selection as a temporal solution is fine, but did you notice that mouse over effect over JButtons in the SwingSet use correct "light color"? Did you tried to check can we use it for menu as well? - The test should not check exact selection color and compare it to the textarea selection, it should check that the selection color is clearly visible on the background. I guess it should use the logic similar to the logic which was deleted by the fix. - The next code should be inverted, or additional waitForIdle should be added: frame.setVisible(true); ........ SwingUtilities.invokeAndWait(() -> { point = menu.getLocationOnScreen(); rect = menu.getBounds(); }); robot.waitForIdle(); robot.delay(500); You need to wait and then read the bounds, otherwise the test may fail(It sometimes fail on my local run for that reason) On 13.07.2020 11:30, Pankaj Bansal wrote: > Hi All, > > Please review the following fix for jdk15. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8249251 > webrev: http://cr.openjdk.java.net/~pbansal/8249251/webrev01/ > > Issue: In Ubuntu 20.04 in dark mode, the selected Menu is not being highlighted properly. so, there is no difference between selected and unselected Menu. The issue can be reproduced by running Swingset2 or using the test added in fix. > > Cause: In dark mode, the highlight color for Menu is not visible over the dark background color for the Menubar. So, the highlight is not visible properly and it looks like there is no highlight being drawn. > > Fix: The fix is to use some color for highlighting, which will be properly visible. We have taken the background color for selected text. This color is is visible over the dark Background easily. The fix is tested on Ubuntu 18.04, Ubuntu 20.04 and OL 8.2. > > Added an automated test to verify that the highlight color is same as background color for selected text. The test passes on mach5 with multiple iterations. Link added in JBS. > > > Regards > Pankaj > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Tue Jul 14 14:11:48 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 14 Jul 2020 19:41:48 +0530 Subject: RFR JDK-8245785: javax.swing.JTabbedPane cannot be deserialized In-Reply-To: <5F0C719F.3050403@oracle.com> References: <3b13c335-a51e-7e77-04ea-f5a7dd97d933@oracle.com> <2755c43b-0693-94f3-095d-eb4465cfe275@oracle.com> <811a6058-edda-8cb3-47a0-fc91887644e7@oracle.com> <8a6c7395-d034-c120-8bff-816b875fa937@oracle.com> <9c4e88a5-56ca-439a-cd44-a7dccd4ea9d1@oracle.com> <283a4a4d-eb39-ee3d-f9d7-f403e6ba5e64@oracle.com> <5F0C719F.3050403@oracle.com> Message-ID: On 13-Jul-20 8:07 PM, Philip Race wrote: > The regression test needs some clean up. > It seems to be a copy+paste of the submitter's test case > including the comment in German which can be removed. > Also IMO all the English comments are stating the obvious and don't > need to be there. > > And use ByteArray based streams not File streams. OK. Modified webrev http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.3/ Regards Prasanta > There are fewer clean up issues if you do that. > > -phil. > > > On 7/13/20, 7:10 AM, Prasanta Sadhukhan wrote: >> >> On 13-Jul-20 11:30 AM, Sergey Bylokhov wrote: >>> On 11.07.2020 23:05, Prasanta Sadhukhan wrote: >>>> >>>> It's just a null check so I guess we can keep getTabCount() check >>>> in-place. Also, there are no other fields is missing which is >>>> required. >>> >>> But as far as I understand this check is not needed, the field >>> initialized to non-null >>> value in the constructor. And should not be null after >>> deserialization, otherwise, you >>> will need to add the null checks in every place where the field is >>> used. >>> >> OK. Null check removed >> http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.2/ >> >> Regards >> Prasanta >>>> >>>> Regards >>>> Prasanta >>>>> >>>>>> >>>>>> if JTabbedPane has few tabs/pages, all are deserialized. This is >>>>>> also tested in the testcase. >>>>>> >>>>>> http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.1/ >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 09-Jul-20 3:28 PM, Sergey Bylokhov wrote: >>>>>>> Hi, Prasanta. >>>>>>> >>>>>>> Why the "pages" object is not instantiated when deserialized? >>>>>>> What will happen if the JTabbedPane >>>>>>> will have a few(more than zero) pages before deserialization, >>>>>>> will all pages be serialized/deserialized in this case? >>>>>>> >>>>>>> On 09.07.2020 01:14, Prasanta Sadhukhan wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Please review a fix for an issue where deserializing a >>>>>>>> serialized JTabbedPane-object results in NullPointerException. >>>>>>>> >>>>>>>> The NPE is result of tabbed "pages" object not being >>>>>>>> instantiated when deserialized. >>>>>>>> >>>>>>>> Proposed fix is to add a null check for "pages" object. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8245785 >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.0/ >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> From pankaj.b.bansal at oracle.com Tue Jul 14 19:06:42 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Wed, 15 Jul 2020 00:36:42 +0530 Subject: RFR: 8249251: [dark_mode ubuntu 20.04] The selected menu is not highlighted in GTKLookAndFeel In-Reply-To: References: <67f741bb-7371-0d84-2278-1d78cb081df2@oracle.com> Message-ID: <3f4abe12-dec2-a5b8-d7a3-9b0073e0e313@oracle.com> Hi Sergey, Thanks for the review. Please see my comments inline. Following the new webrev webrev: http://cr.openjdk.java.net/~pbansal/8249251/webrev02/ On 14/07/20 12:43 PM, Sergey Bylokhov wrote: > Hi, Pankaj. > > A few notes about the fix and test: > ?- The usage of textarea selection as a temporal solution is fine, but > did you notice that mouse over effect over JButtons > ?? in the SwingSet use correct "light color"? Did you tried to check > can we use it for menu as well? I tried this, but I think this is not very viable option. 1. The highlight is again not very much visible over the menu. It looks good in SwingSet2 as there are other menus to compare, but if we create one menu, the highlight is not visible properly. I saw that there is very less difference in the color values. 2. Doing this will make the Menu more consistent with Popup menu highlight in Ubuntu 20.04. But for Ubuntu 18.04 and OL 76, OL82, this will make it less consistent. In OL 76, OL 82, Ubuntu 18.04 the highlight in native popup is also of same color as selected Text color background (Blue and Orange). so using button highlight color will make the menu highlight less consistent with native terminal popup menu highlight. 3. This is also a workaround in the end and we will need to fix this also by reading the popup highlight color from Terminal. 4. If you would like to try out this out, here is a webrev http://cr.openjdk.java.net/~pbansal/8249251/webrev02_Button/ > ?- The test should not check exact selection color and compare it to > the textarea selection, it should check > ?? that the selection color is clearly visible on the background. I > guess it should use the logic similar to the > ?? logic which was deleted by the fix. > Done. > ?- The next code should be inverted, or additional waitForIdle should > be added: > ?????? frame.setVisible(true); > ?????? ........ > ?????? SwingUtilities.invokeAndWait(() -> { > ????????? point = menu.getLocationOnScreen(); > ????????? rect = menu.getBounds(); > ?????? }); > ?????? robot.waitForIdle(); > ?????? robot.delay(500); > ?? You need to wait and then read the bounds, otherwise the test may > fail(It sometimes fail on my local run for that reason) > Done. Regards, Pankaj > > On 13.07.2020 11:30, Pankaj Bansal wrote: >> Hi All, >> >> Please review the following fix for jdk15. >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8249251 >> webrev: http://cr.openjdk.java.net/~pbansal/8249251/webrev01/ >> >> >> Issue: In Ubuntu 20.04 in dark mode, the selected Menu is not being >> highlighted properly. so, there is no difference between selected and >> unselected Menu. The issue can be reproduced by running Swingset2 or >> using the test added in fix. >> >> Cause: In dark mode, the highlight color for Menu is not visible over >> the dark background color for the Menubar. So, the highlight is not >> visible properly and it looks like there is no highlight being drawn. >> >> Fix: The fix is to use some color for highlighting, which will be >> properly visible. We have taken the background color for selected >> text. This color is is visible over the dark Background easily. The >> fix is tested on Ubuntu 18.04, Ubuntu 20.04 and OL 8.2. >> >> Added an automated test to verify that the highlight color is same as >> background color for selected text. The test passes on mach5 with >> multiple iterations. Link added in JBS. >> >> >> Regards >> Pankaj >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Jul 14 20:30:22 2020 From: philip.race at oracle.com (Philip Race) Date: Tue, 14 Jul 2020 13:30:22 -0700 Subject: [15] RFR : 8249278 : Revert JDK-8226253 In-Reply-To: References: Message-ID: <5F0E15DE.1000203@oracle.com> adding swing-dev which is the correct list for this Swing change. It looks like a faithful backout of https://bugs.openjdk.java.net/browse/JDK-8226253 https://hg.openjdk.java.net/jdk/jdk/rev/3ea8a0c5c264 except that the (c) year is remaining 2020 .. which I think just indicates the silliness of all these (c) updates since the only changes to these files in 2020 were those which you have now backed out. So I think you should revert the (c) changes as well. If some one else comes along and updates all files in JDK with updates in 2020 and so re-adds it then that is their problem ... -phil. On 7/14/20, 5:37 AM, Ambarish Rapte wrote: > > Hi, > > Please review this fix: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8249278 > > Webrev: http://cr.openjdk.java.net/~arapte/a11y/8249278/webrev.0/ > > > This change reverts the fix for JDK-8226253. > > The fix of JDK-8226253 breaks the specification of > AccessibleState.SHOWING for JList and has caused a regression with JTree. > > There is no alternative to fix JDK-8226253 on JDK side and the issue > should be really fixed on Screen reader side. > > So in order to keep the correctness of spec and avoid any new > regression, the fix needs to be reverted. > > Regards, > > Ambarish > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Jul 15 00:46:19 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 14 Jul 2020 17:46:19 -0700 Subject: RFR: 8249251: [dark_mode ubuntu 20.04] The selected menu is not highlighted in GTKLookAndFeel In-Reply-To: <3f4abe12-dec2-a5b8-d7a3-9b0073e0e313@oracle.com> References: <67f741bb-7371-0d84-2278-1d78cb081df2@oracle.com> <3f4abe12-dec2-a5b8-d7a3-9b0073e0e313@oracle.com> Message-ID: <3a070e27-fd88-0478-b1c1-b5738a93debb@oracle.com> On 14.07.2020 12:06, Pankaj Bansal wrote: > Hi Sergey, > > Thanks for the review. Please see my comments inline. Following the new webrev > > webrev: http://cr.openjdk.java.net/~pbansal/8249251/webrev02/ Looks fine. > > On 14/07/20 12:43 PM, Sergey Bylokhov wrote: >> Hi, Pankaj. >> >> A few notes about the fix and test: >> ?- The usage of textarea selection as a temporal solution is fine, but did you notice that mouse over effect over JButtons >> ?? in the SwingSet use correct "light color"? Did you tried to check can we use it for menu as well? > I tried this, but I think this is not very viable option. > 1. The highlight is again not very much visible over the menu. It looks good in SwingSet2 as there are other menus to compare, but if we create one menu, the highlight is not visible properly. I saw that there is very less difference in the color values. > 2. Doing this will make the Menu more consistent with Popup menu highlight in Ubuntu 20.04. But for Ubuntu 18.04 and OL 76, OL82, this will make it less consistent. In OL 76, OL 82, Ubuntu 18.04 the highlight in native popup is also of same color as selected Text color background (Blue and Orange). so using button highlight color will make the menu highlight less consistent with native terminal popup menu highlight. > 3. This is also a workaround in the end and we will need to fix this also by reading the popup highlight color from Terminal. > 4. If you would like to try out this out, here is a webrev http://cr.openjdk.java.net/~pbansal/8249251/webrev02_Button/ >> ?- The test should not check exact selection color and compare it to the textarea selection, it should check >> ?? that the selection color is clearly visible on the background. I guess it should use the logic similar to the >> ?? logic which was deleted by the fix. >> > Done. >> ?- The next code should be inverted, or additional waitForIdle should be added: >> ?????? frame.setVisible(true); >> ?????? ........ >> ?????? SwingUtilities.invokeAndWait(() -> { >> ????????? point = menu.getLocationOnScreen(); >> ????????? rect = menu.getBounds(); >> ?????? }); >> ?????? robot.waitForIdle(); >> ?????? robot.delay(500); >> ?? You need to wait and then read the bounds, otherwise the test may fail(It sometimes fail on my local run for that reason) >> > Done. > > > Regards, > Pankaj >> >> On 13.07.2020 11:30, Pankaj Bansal wrote: >>> Hi All, >>> >>> Please review the following fix for jdk15. >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8249251 >>> webrev: http://cr.openjdk.java.net/~pbansal/8249251/webrev01/ >>> >>> Issue: In Ubuntu 20.04 in dark mode, the selected Menu is not being highlighted properly. so, there is no difference between selected and unselected Menu. The issue can be reproduced by running Swingset2 or using the test added in fix. >>> >>> Cause: In dark mode, the highlight color for Menu is not visible over the dark background color for the Menubar. So, the highlight is not visible properly and it looks like there is no highlight being drawn. >>> >>> Fix: The fix is to use some color for highlighting, which will be properly visible. We have taken the background color for selected text. This color is is visible over the dark Background easily. The fix is tested on Ubuntu 18.04, Ubuntu 20.04 and OL 8.2. >>> >>> Added an automated test to verify that the highlight color is same as background color for selected text. The test passes on mach5 with multiple iterations. Link added in JBS. >>> >>> >>> Regards >>> Pankaj >>> >> >> > -- Best regards, Sergey. From ambarish.rapte at oracle.com Wed Jul 15 02:44:11 2020 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Tue, 14 Jul 2020 19:44:11 -0700 (PDT) Subject: [15] RFR : 8249278 : Revert JDK-8226253 which breaks the spec of AccessibleState.SHOWING for JList Message-ID: Hello Phil, Thanks for the review and correcting the mail group, Please take a look at the updated webrev with C years also backed out: http://cr.openjdk.java.net/~arapte/a11y/8249278/webrev.1 Regards, Ambarish. From: Philip Race Sent: Wednesday, July 15, 2020 2:00 AM To: Ambarish Rapte ; swing-dev at openjdk.java.net Cc: awt-dev at openjdk.java.net Subject: Re: [15] RFR : 8249278 : Revert JDK-8226253 adding swing-dev which is the correct list for this Swing change. It looks like a faithful backout of https://bugs.openjdk.java.net/browse/JDK-8226253 https://hg.openjdk.java.net/jdk/jdk/rev/3ea8a0c5c264 except that the (c) year is remaining 2020 .. which I think just indicates the silliness of all these (c) updates since the only changes to these files in 2020 were those which you have now backed out. So I think you should revert the (c) changes as well. If some one else comes along and updates all files in JDK with updates in 2020 and so re-adds it then that is their problem ... -phil. On 7/14/20, 5:37 AM, Ambarish Rapte wrote: Hi, Please review this fix: JBS: https://bugs.openjdk.java.net/browse/JDK-8249278 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Earapte/a11y/8249278/webrev.0/"http://cr.openjdk.java.net/~arapte/a11y/8249278/webrev.0/ This change reverts the fix for JDK-8226253. The fix of JDK-8226253 breaks the specification of AccessibleState.SHOWING for JList and has caused a regression with JTree. There is no alternative to fix JDK-8226253 on JDK side and the issue should be really fixed on Screen reader side. So in order to keep the correctness of spec and avoid any new regression, the fix needs to be reverted. Regards, Ambarish -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Jul 15 08:24:49 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 15 Jul 2020 13:54:49 +0530 Subject: RFR JDK-8210850: There is a Java icon instead of a i icon on mac Message-ID: Hi All, Please review a fix for an issue where it is seen JOptionPane showInputDialog and showConfirmationDialog in SwingSet2 "OptionPane Demo" dialog is being shown as a "Java" icon instead of "i" icon for AquaLookAndFeel in mac. Other L&Fs show "i" icon. Issue is because in Aqua L&F, JOptionPane.informationIcon and JOptionPane.questionIcon uses "confirmIcon" which uses generic java icon as seen here http://hg.openjdk.java.net/jdk/client/file/9078079d153b/src/java.desktop/macosx/classes/com/apple/laf/AquaImageFactory.java#l53 Proposed fix is to use appropriate icon gif image that is being used for other L&Fs for showInputDialog and showConfirmationDialog. Other icons like errorIcon and warningIcon is not changed as it uses system icons via AquaIcon.SystemIcon icons but these system-icons are not present for the above 2 icons. Bug: https://bugs.openjdk.java.net/browse/JDK-8210850 webrev: http://cr.openjdk.java.net/~psadhukhan/8210850/webrev.0/ No regression test is provided as it can be verified through SwingSet2 OptionPane demo. Regards Prasanta From prasanta.sadhukhan at oracle.com Wed Jul 15 09:01:19 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 15 Jul 2020 14:31:19 +0530 Subject: RFR JDK-8042055: Nimbus DerivedColor incorrectly clamps hue Message-ID: Hi All, Please review a fix for a nimbus issue where it is seen that "hue" color in Nimbus.DerivedColor.rederiveColor is being incorrectly clamped. rederiveColor() calls Color.HSBtoRGB() to get the RGB color from Hue/Saturation/Brightness color and as per HSBtoRGB spec https://docs.oracle.com/en/java/javase/14/docs/api/java.desktop/java/awt/Color.html#HSBtoRGB(float,float,float) it is mentioned "The |hue| component can be any floating-point number. The floor of this number is subtracted from it to create a fraction between 0 and 1" whereas "The |saturation| and |brightness| components should be floating-point values between zero and one (numbers in the range 0.0-1.0)". So, although it is alright to clamp saturation and brightness value within 0.0-1.0 before calling Color.HSBtoRGB(), it is not supposed to be done for "hue" color as it is getting clamped inside HSBtoRGB() method. Proposed fix is to do away with this incorrect clamp. Bug: https://bugs.openjdk.java.net/browse/JDK-8042055 webrev: http://cr.openjdk.java.net/~psadhukhan/8042055/webrev.0/ Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From Koen.VanDenBorre at esko.com Wed Jul 15 09:18:25 2020 From: Koen.VanDenBorre at esko.com (Van Den Borre, Koen) Date: Wed, 15 Jul 2020 09:18:25 +0000 Subject: RFR JDK-8210850: There is a Java icon instead of a i icon on mac In-Reply-To: References: Message-ID: Hey, I believe that on mac, the question icon and inform icon are simply the application icon. This is the case for native alert dialogs, and this is also done in Java swing if your application is bundled correctly or when -Xdock:icon is specified via the command. I am not sure if there is something that needs fixing. The proposed fix seems like a step in the wrong direction Koen -----Original Message----- From: swing-dev On Behalf Of Prasanta Sadhukhan Sent: Wednesday, July 15, 2020 10:25 AM To: swing-dev at openjdk.java.net Subject: RFR JDK-8210850: There is a Java icon instead of a i icon on mac Hi All, Please review a fix for an issue where it is seen JOptionPane showInputDialog and showConfirmationDialog in SwingSet2 "OptionPane Demo" dialog is being shown as a "Java" icon instead of "i" icon for AquaLookAndFeel in mac. Other L&Fs show "i" icon. Issue is because in Aqua L&F, JOptionPane.informationIcon and JOptionPane.questionIcon uses "confirmIcon" which uses generic java icon as seen here https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_client_file_9078079d153b_src_java.desktop_macosx_classes_com_apple_laf_AquaImageFactory.java-23l53&d=DwICaQ&c=9mghv0deYPYDGP-W745IEdQLV1kHpn4XJRvR6xMRXtA&r=9d_eS2PJkOJltUfB0P4NB6MyXvE-X1oiMmv4r0btY2s&m=LSNvSA90f9CQ2ew0l5Nag5nXAoknapz0ote5Z8Tru58&s=giOu_dtf7JnXFrfZx5hNE1JqGQ2mwEaP4xZHWCcHG-o&e= Proposed fix is to use appropriate icon gif image that is being used for other L&Fs for showInputDialog and showConfirmationDialog. Other icons like errorIcon and warningIcon is not changed as it uses system icons via AquaIcon.SystemIcon icons but these system-icons are not present for the above 2 icons. Bug: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8210850&d=DwICaQ&c=9mghv0deYPYDGP-W745IEdQLV1kHpn4XJRvR6xMRXtA&r=9d_eS2PJkOJltUfB0P4NB6MyXvE-X1oiMmv4r0btY2s&m=LSNvSA90f9CQ2ew0l5Nag5nXAoknapz0ote5Z8Tru58&s=Dw7UmI849E2lHvyXrHYzIKVY9QE-djJ_pyCPdh4Wiz8&e= webrev: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Epsadhukhan_8210850_webrev.0_&d=DwICaQ&c=9mghv0deYPYDGP-W745IEdQLV1kHpn4XJRvR6xMRXtA&r=9d_eS2PJkOJltUfB0P4NB6MyXvE-X1oiMmv4r0btY2s&m=LSNvSA90f9CQ2ew0l5Nag5nXAoknapz0ote5Z8Tru58&s=6hel-l73633rQRiFvC0KMMyh9fw-zIVT3wqiUJ517Iw&e= No regression test is provided as it can be verified through SwingSet2 OptionPane demo. Regards Prasanta Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment. From prasanta.sadhukhan at oracle.com Wed Jul 15 13:26:52 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 15 Jul 2020 18:56:52 +0530 Subject: RFR JDK-8245785: javax.swing.JTabbedPane cannot be deserialized In-Reply-To: References: <3b13c335-a51e-7e77-04ea-f5a7dd97d933@oracle.com> <2755c43b-0693-94f3-095d-eb4465cfe275@oracle.com> <811a6058-edda-8cb3-47a0-fc91887644e7@oracle.com> <8a6c7395-d034-c120-8bff-816b875fa937@oracle.com> <9c4e88a5-56ca-439a-cd44-a7dccd4ea9d1@oracle.com> <283a4a4d-eb39-ee3d-f9d7-f403e6ba5e64@oracle.com> <5F0C719F.3050403@oracle.com> Message-ID: On 14-Jul-20 7:41 PM, Prasanta Sadhukhan wrote: > > On 13-Jul-20 8:07 PM, Philip Race wrote: >> The regression test needs some clean up. >> It seems to be a copy+paste of the submitter's test case >> including the comment in German which can be removed. >> Also IMO all the English comments are stating the obvious and don't >> need to be there. >> >> And use ByteArray based streams not File streams. > > OK. Modified webrev > > http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.3/ Any further comments on this? > > Regards > Prasanta >> There are fewer clean up issues if you do that. >> >> -phil. >> >> >> On 7/13/20, 7:10 AM, Prasanta Sadhukhan wrote: >>> >>> On 13-Jul-20 11:30 AM, Sergey Bylokhov wrote: >>>> On 11.07.2020 23:05, Prasanta Sadhukhan wrote: >>>>> >>>>> It's just a null check so I guess we can keep getTabCount() check >>>>> in-place. Also, there are no other fields is missing which is >>>>> required. >>>> >>>> But as far as I understand this check is not needed, the field >>>> initialized to non-null >>>> value in the constructor. And should not be null after >>>> deserialization, otherwise, you >>>> will need to add the null checks in every place where the field is >>>> used. >>>> >>> OK. Null check removed >>> http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.2/ >>> >>> Regards >>> Prasanta >>>>> >>>>> Regards >>>>> Prasanta >>>>>> >>>>>>> >>>>>>> if JTabbedPane has few tabs/pages, all are deserialized. This is >>>>>>> also tested in the testcase. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.1/ >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 09-Jul-20 3:28 PM, Sergey Bylokhov wrote: >>>>>>>> Hi, Prasanta. >>>>>>>> >>>>>>>> Why the "pages" object is not instantiated when deserialized? >>>>>>>> What will happen if the JTabbedPane >>>>>>>> will have a few(more than zero) pages before deserialization, >>>>>>>> will all pages be serialized/deserialized in this case? >>>>>>>> >>>>>>>> On 09.07.2020 01:14, Prasanta Sadhukhan wrote: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> Please review a fix for an issue where deserializing a >>>>>>>>> serialized JTabbedPane-object results in NullPointerException. >>>>>>>>> >>>>>>>>> The NPE is result of tabbed "pages" object not being >>>>>>>>> instantiated when deserialized. >>>>>>>>> >>>>>>>>> Proposed fix is to add a null check for "pages" object. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8245785 >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.0/ >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> From philip.race at oracle.com Wed Jul 15 15:43:55 2020 From: philip.race at oracle.com (Philip Race) Date: Wed, 15 Jul 2020 08:43:55 -0700 Subject: [15] RFR : 8249278 : Revert JDK-8226253 which breaks the spec of AccessibleState.SHOWING for JList In-Reply-To: References: Message-ID: <5F0F243B.6050607@oracle.com> +1 -phil On 7/14/20, 7:44 PM, Ambarish Rapte wrote: > > Hello Phil, > > Thanks for the review and correcting the mail group, > > Please take a look at the updated webrev with ? years also backed out: > > http://cr.openjdk.java.net/~arapte/a11y/8249278/webrev.1 > > > Regards, > > Ambarish. > > *From:*Philip Race > *Sent:* Wednesday, July 15, 2020 2:00 AM > *To:* Ambarish Rapte ; > swing-dev at openjdk.java.net > *Cc:* awt-dev at openjdk.java.net > *Subject:* Re: [15] RFR : 8249278 : Revert JDK-8226253 > > adding swing-dev which is the correct list for this Swing change. > > It looks like a faithful backout of > https://bugs.openjdk.java.net/browse/JDK-8226253 > https://hg.openjdk.java.net/jdk/jdk/rev/3ea8a0c5c264 > > except that the (c) year is remaining 2020 .. which I think just > indicates the silliness of all these (c) updates since the only > changes to these files in 2020 were those which you have now backed out. > > So I think you should revert the (c) changes as well. > > If some one else comes along and updates all files in JDK with updates > in 2020 > and so re-adds it then that is their problem ... > > -phil. > > On 7/14/20, 5:37 AM, Ambarish Rapte wrote: > > Hi, > > Please review this fix: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8249278 > > Webrev: http://cr.openjdk.java.net/~arapte/a11y/8249278/webrev.0/ > > > This change reverts the fix for JDK-8226253. > > The fix of JDK-8226253 breaks the specification of > AccessibleState.SHOWING for JList and has caused a regression with > JTree. > > There is no alternative to fix JDK-8226253 on JDK side and the > issue should be really fixed on Screen reader side. > > So in order to keep the correctness of spec and avoid any new > regression, the fix needs to be reverted. > > Regards, > > Ambarish > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.zuev at oracle.com Wed Jul 15 18:56:25 2020 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 15 Jul 2020 11:56:25 -0700 Subject: RFR JDK-8245785: javax.swing.JTabbedPane cannot be deserialized In-Reply-To: References: <3b13c335-a51e-7e77-04ea-f5a7dd97d933@oracle.com> <2755c43b-0693-94f3-095d-eb4465cfe275@oracle.com> <811a6058-edda-8cb3-47a0-fc91887644e7@oracle.com> <8a6c7395-d034-c120-8bff-816b875fa937@oracle.com> <9c4e88a5-56ca-439a-cd44-a7dccd4ea9d1@oracle.com> <283a4a4d-eb39-ee3d-f9d7-f403e6ba5e64@oracle.com> <5F0C719F.3050403@oracle.com> Message-ID: Looks good now. /Alex On 7/15/2020 6:26 AM, Prasanta Sadhukhan wrote: > > On 14-Jul-20 7:41 PM, Prasanta Sadhukhan wrote: >> >> On 13-Jul-20 8:07 PM, Philip Race wrote: >>> The regression test needs some clean up. >>> It seems to be a copy+paste of the submitter's test case >>> including the comment in German which can be removed. >>> Also IMO all the English comments are stating the obvious and don't >>> need to be there. >>> >>> And use ByteArray based streams not File streams. >> >> OK. Modified webrev >> >> http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.3/ > Any further comments on this? >> >> Regards >> Prasanta >>> There are fewer clean up issues if you do that. >>> >>> -phil. >>> >>> >>> On 7/13/20, 7:10 AM, Prasanta Sadhukhan wrote: >>>> >>>> On 13-Jul-20 11:30 AM, Sergey Bylokhov wrote: >>>>> On 11.07.2020 23:05, Prasanta Sadhukhan wrote: >>>>>> >>>>>> It's just a null check so I guess we can keep getTabCount() check >>>>>> in-place. Also, there are no other fields is missing which is >>>>>> required. >>>>> >>>>> But as far as I understand this check is not needed, the field >>>>> initialized to non-null >>>>> value in the constructor. And should not be null after >>>>> deserialization, otherwise, you >>>>> will need to add the null checks in every place where the field is >>>>> used. >>>>> >>>> OK. Null check removed >>>> http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.2/ >>>> >>>> Regards >>>> Prasanta >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>>> >>>>>>>> >>>>>>>> if JTabbedPane has few tabs/pages, all are deserialized. This >>>>>>>> is also tested in the testcase. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.1/ >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> On 09-Jul-20 3:28 PM, Sergey Bylokhov wrote: >>>>>>>>> Hi, Prasanta. >>>>>>>>> >>>>>>>>> Why the "pages" object is not instantiated when deserialized? >>>>>>>>> What will happen if the JTabbedPane >>>>>>>>> will have a few(more than zero) pages before deserialization, >>>>>>>>> will all pages be serialized/deserialized in this case? >>>>>>>>> >>>>>>>>> On 09.07.2020 01:14, Prasanta Sadhukhan wrote: >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> Please review a fix for an issue where deserializing a >>>>>>>>>> serialized JTabbedPane-object results in NullPointerException. >>>>>>>>>> >>>>>>>>>> The NPE is result of tabbed "pages" object not being >>>>>>>>>> instantiated when deserialized. >>>>>>>>>> >>>>>>>>>> Proposed fix is to add a null check for "pages" object. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8245785 >>>>>>>>>> >>>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.0/ >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> From philip.race at oracle.com Wed Jul 15 18:59:08 2020 From: philip.race at oracle.com (Philip Race) Date: Wed, 15 Jul 2020 11:59:08 -0700 Subject: RFR JDK-8245785: javax.swing.JTabbedPane cannot be deserialized In-Reply-To: References: <3b13c335-a51e-7e77-04ea-f5a7dd97d933@oracle.com> <2755c43b-0693-94f3-095d-eb4465cfe275@oracle.com> <811a6058-edda-8cb3-47a0-fc91887644e7@oracle.com> <8a6c7395-d034-c120-8bff-816b875fa937@oracle.com> <9c4e88a5-56ca-439a-cd44-a7dccd4ea9d1@oracle.com> <283a4a4d-eb39-ee3d-f9d7-f403e6ba5e64@oracle.com> <5F0C719F.3050403@oracle.com> Message-ID: <5F0F51FC.8010401@oracle.com> +1 -phil. On 7/15/20, 11:56 AM, Alexander Zuev wrote: > Looks good now. > > /Alex > > On 7/15/2020 6:26 AM, Prasanta Sadhukhan wrote: >> >> On 14-Jul-20 7:41 PM, Prasanta Sadhukhan wrote: >>> >>> On 13-Jul-20 8:07 PM, Philip Race wrote: >>>> The regression test needs some clean up. >>>> It seems to be a copy+paste of the submitter's test case >>>> including the comment in German which can be removed. >>>> Also IMO all the English comments are stating the obvious and don't >>>> need to be there. >>>> >>>> And use ByteArray based streams not File streams. >>> >>> OK. Modified webrev >>> >>> http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.3/ >> Any further comments on this? >>> >>> Regards >>> Prasanta >>>> There are fewer clean up issues if you do that. >>>> >>>> -phil. >>>> >>>> >>>> On 7/13/20, 7:10 AM, Prasanta Sadhukhan wrote: >>>>> >>>>> On 13-Jul-20 11:30 AM, Sergey Bylokhov wrote: >>>>>> On 11.07.2020 23:05, Prasanta Sadhukhan wrote: >>>>>>> >>>>>>> It's just a null check so I guess we can keep getTabCount() >>>>>>> check in-place. Also, there are no other fields is missing which >>>>>>> is required. >>>>>> >>>>>> But as far as I understand this check is not needed, the field >>>>>> initialized to non-null >>>>>> value in the constructor. And should not be null after >>>>>> deserialization, otherwise, you >>>>>> will need to add the null checks in every place where the field >>>>>> is used. >>>>>> >>>>> OK. Null check removed >>>>> http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.2/ >>>>> >>>>> Regards >>>>> Prasanta >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>>> >>>>>>>>> >>>>>>>>> if JTabbedPane has few tabs/pages, all are deserialized. This >>>>>>>>> is also tested in the testcase. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.1/ >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>> On 09-Jul-20 3:28 PM, Sergey Bylokhov wrote: >>>>>>>>>> Hi, Prasanta. >>>>>>>>>> >>>>>>>>>> Why the "pages" object is not instantiated when deserialized? >>>>>>>>>> What will happen if the JTabbedPane >>>>>>>>>> will have a few(more than zero) pages before deserialization, >>>>>>>>>> will all pages be serialized/deserialized in this case? >>>>>>>>>> >>>>>>>>>> On 09.07.2020 01:14, Prasanta Sadhukhan wrote: >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> Please review a fix for an issue where deserializing a >>>>>>>>>>> serialized JTabbedPane-object results in NullPointerException. >>>>>>>>>>> >>>>>>>>>>> The NPE is result of tabbed "pages" object not being >>>>>>>>>>> instantiated when deserialized. >>>>>>>>>>> >>>>>>>>>>> Proposed fix is to add a null check for "pages" object. >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8245785 >>>>>>>>>>> >>>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.0/ >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Prasanta >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> > From Sergey.Bylokhov at oracle.com Wed Jul 15 21:27:41 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 15 Jul 2020 14:27:41 -0700 Subject: [15] RFR : 8249278 : Revert JDK-8226253 which breaks the spec of AccessibleState.SHOWING for JList In-Reply-To: <5F0F243B.6050607@oracle.com> References: <5F0F243B.6050607@oracle.com> Message-ID: +1 On 15.07.2020 08:43, Philip Race wrote: > +1 > > -phil > > On 7/14/20, 7:44 PM, Ambarish Rapte wrote: >> >> Hello Phil, >> >> Thanks for the review and correcting the mail group, >> >> Please take a look at the updated webrev with ? years also backed out: >> >> http://cr.openjdk.java.net/~arapte/a11y/8249278/webrev.1 >> >> Regards, >> >> Ambarish. >> >> *From:*Philip Race >> *Sent:* Wednesday, July 15, 2020 2:00 AM >> *To:* Ambarish Rapte ; swing-dev at openjdk.java.net >> *Cc:* awt-dev at openjdk.java.net >> *Subject:* Re: [15] RFR : 8249278 : Revert JDK-8226253 >> >> adding swing-dev which is the correct list for this Swing change. >> >> It looks like a faithful backout of >> https://bugs.openjdk.java.net/browse/JDK-8226253 >> https://hg.openjdk.java.net/jdk/jdk/rev/3ea8a0c5c264 >> >> except that the (c) year is remaining 2020 .. which I think just >> indicates the silliness of all these (c) updates since the only >> changes to these files in 2020 were those which you have now backed out. >> >> So I think you should revert the (c) changes as well. >> >> If some one else comes along and updates all files in JDK with updates in 2020 >> and so re-adds it then that is their problem ... >> >> -phil. >> >> On 7/14/20, 5:37 AM, Ambarish Rapte wrote: >> >> Hi, >> >> Please review this fix: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8249278 >> >> Webrev: http://cr.openjdk.java.net/~arapte/a11y/8249278/webrev.0/ >> >> This change reverts the fix for JDK-8226253. >> >> The fix of JDK-8226253 breaks the specification of AccessibleState.SHOWING for JList and has caused a regression with JTree. >> >> There is no alternative to fix JDK-8226253 on JDK side and the issue should be really fixed on Screen reader side. >> >> So in order to keep the correctness of spec and avoid any new regression, the fix needs to be reverted. >> >> Regards, >> >> Ambarish >> -- Best regards, Sergey. From matthias.baesken at sap.com Thu Jul 16 08:02:27 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 16 Jul 2020 08:02:27 +0000 Subject: RFR: 8249588 : libwindowsaccessbridge issues on 64bit Windows Message-ID: Hello, looks like libwindowsaccessbridge has some issues in native coding on 64bit Windows , probably it was developed with 32bit in mind And still misses a few adjustments. WinAccessBridge .h/cpp contains BOOL CALLBACK AccessBridgeDialogProc(HWND hDlg, UINT message, UINT wParam, LONG lParam); and theDialogWindow = CreateDialog(windowsInstance, "ACCESSBRIDGESTATUSWINDOW", NULL, (DLGPROC) AccessBridgeDialogProc); But DLGPROC has parameters ( https://docs.microsoft.com/en-us/windows/win32/api/winuser/nc-winuser-dlgproc ) HWND Arg1, UINT Arg2, WPARAM Arg3, LPARAM Arg4 So probably the 3rd and 4th params should be ... WPARAM wParam, LPARAM lParam . One internal user claimed to have crashes because of this type mismatch . Additionally I found some unused declarations in WinAccessBridge.h probably we could delete them . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8249588 http://cr.openjdk.java.net/~mbaesken/webrevs/8249588.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Jul 16 17:26:34 2020 From: philip.race at oracle.com (Philip Race) Date: Thu, 16 Jul 2020 10:26:34 -0700 Subject: RFR: 8249588 : libwindowsaccessbridge issues on 64bit Windows In-Reply-To: References: Message-ID: <5F108DCA.8080209@oracle.com> This looks OK but I've asked folks with access to JAWS to apply and verify it. We'll wait for those results. And when we are done, please push to jdk/client. -phil. On 7/16/20, 1:02 AM, Baesken, Matthias wrote: > > Hello, looks like libwindowsaccessbridge has some issues in native > coding on 64bit Windows , probably it was developed with 32bit in mind > > And still misses a few adjustments. > > WinAccessBridge .h/cpp contains > > BOOL CALLBACK AccessBridgeDialogProc(HWND hDlg, UINT message, > > UINT wParam, LONG lParam); > > and > > theDialogWindow = CreateDialog(windowsInstance, > > "ACCESSBRIDGESTATUSWINDOW", NULL, > > (DLGPROC) AccessBridgeDialogProc); > > But DLGPROC has parameters ( > https://docs.microsoft.com/en-us/windows/win32/api/winuser/nc-winuser-dlgproc > ) > > HWND Arg1, > > UINT Arg2, > > WPARAM Arg3, > > LPARAM Arg4 > > So probably the 3^rd and 4^th params should be ... *WPARAM* wParam, > *LPARAM* lParam . > > One internal user claimed to have crashes because of this type > mismatch . > > Additionally I found some unused declarations in WinAccessBridge.h > probably we could delete them . > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8249588 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8249588.0/ > > > Thanks, Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Jul 16 21:34:33 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 16 Jul 2020 14:34:33 -0700 Subject: RFR JDK-8042055: Nimbus DerivedColor incorrectly clamps hue In-Reply-To: References: Message-ID: Looks fine. On 15.07.2020 02:01, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for a nimbus issue where it is seen that "hue" color in Nimbus.DerivedColor.rederiveColor is being incorrectly clamped. > > rederiveColor() calls Color.HSBtoRGB() to get the RGB color from Hue/Saturation/Brightness color and as per HSBtoRGB spec > > https://docs.oracle.com/en/java/javase/14/docs/api/java.desktop/java/awt/Color.html#HSBtoRGB(float,float,float) > > it is mentioned "The |hue| component can be any floating-point number. The floor of this number is subtracted from it to create a fraction between 0 and 1" > > whereas "The |saturation| and |brightness| components should be floating-point values between zero and one (numbers in the range 0.0-1.0)". > > So, although it is alright to clamp saturation and brightness value within 0.0-1.0 before calling Color.HSBtoRGB(), it is not supposed to be done for "hue" color as it is getting clamped inside HSBtoRGB() method. > > Proposed fix is to do away with this incorrect clamp. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8042055 > > webrev: http://cr.openjdk.java.net/~psadhukhan/8042055/webrev.0/ > > Regards > Prasanta -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu Jul 16 21:38:53 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 16 Jul 2020 14:38:53 -0700 Subject: RFR JDK-8245785: javax.swing.JTabbedPane cannot be deserialized In-Reply-To: References: <3b13c335-a51e-7e77-04ea-f5a7dd97d933@oracle.com> <2755c43b-0693-94f3-095d-eb4465cfe275@oracle.com> <811a6058-edda-8cb3-47a0-fc91887644e7@oracle.com> <8a6c7395-d034-c120-8bff-816b875fa937@oracle.com> <9c4e88a5-56ca-439a-cd44-a7dccd4ea9d1@oracle.com> <283a4a4d-eb39-ee3d-f9d7-f403e6ba5e64@oracle.com> <5F0C719F.3050403@oracle.com> Message-ID: <39709551-36de-f08b-2541-5808fda1af84@oracle.com> On 15.07.2020 06:26, Prasanta Sadhukhan wrote: >> OK. Modified webrev >> >> http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.3/ > Any further comments on this? +1 >> >> Regards >> Prasanta >>> There are fewer clean up issues if you do that. >>> >>> -phil. >>> >>> >>> On 7/13/20, 7:10 AM, Prasanta Sadhukhan wrote: >>>> >>>> On 13-Jul-20 11:30 AM, Sergey Bylokhov wrote: >>>>> On 11.07.2020 23:05, Prasanta Sadhukhan wrote: >>>>>> >>>>>> It's just a null check so I guess we can keep getTabCount() check in-place. Also, there are no other fields is missing which is required. >>>>> >>>>> But as far as I understand this check is not needed, the field initialized to non-null >>>>> value in the constructor. And should not be null after deserialization, otherwise, you >>>>> will need to add the null checks in every place where the field is used. >>>>> >>>> OK. Null check removed http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.2/ >>>> >>>> Regards >>>> Prasanta >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>>> >>>>>>>> >>>>>>>> if JTabbedPane has few tabs/pages, all are deserialized. This is also tested in the testcase. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.1/ >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> On 09-Jul-20 3:28 PM, Sergey Bylokhov wrote: >>>>>>>>> Hi, Prasanta. >>>>>>>>> >>>>>>>>> Why the "pages" object is not instantiated when deserialized? What will happen if the JTabbedPane >>>>>>>>> will have a few(more than zero) pages before deserialization, will all pages be serialized/deserialized in this case? >>>>>>>>> >>>>>>>>> On 09.07.2020 01:14, Prasanta Sadhukhan wrote: >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> Please review a fix for an issue where deserializing a serialized JTabbedPane-object results in NullPointerException. >>>>>>>>>> >>>>>>>>>> The NPE is result of tabbed "pages" object not being instantiated when deserialized. >>>>>>>>>> >>>>>>>>>> Proposed fix is to add a null check for "pages" object. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8245785 >>>>>>>>>> >>>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8245785/webrev.0/ >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> -- Best regards, Sergey. From matthias.baesken at sap.com Fri Jul 17 06:24:50 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 17 Jul 2020 06:24:50 +0000 Subject: RFR: 8249588 : libwindowsaccessbridge issues on 64bit Windows In-Reply-To: <5F108DCA.8080209@oracle.com> References: <5F108DCA.8080209@oracle.com> Message-ID: Hi Phil, thanks for asking your colleagues to verify it . Best regards, Matthias From: Philip Race Sent: Donnerstag, 16. Juli 2020 19:27 To: Baesken, Matthias Cc: swing-dev at openjdk.java.net Subject: Re: RFR: 8249588 : libwindowsaccessbridge issues on 64bit Windows This looks OK but I've asked folks with access to JAWS to apply and verify it. We'll wait for those results. And when we are done, please push to jdk/client. -phil. On 7/16/20, 1:02 AM, Baesken, Matthias wrote: Hello, looks like libwindowsaccessbridge has some issues in native coding on 64bit Windows , probably it was developed with 32bit in mind And still misses a few adjustments. WinAccessBridge .h/cpp contains BOOL CALLBACK AccessBridgeDialogProc(HWND hDlg, UINT message, UINT wParam, LONG lParam); and theDialogWindow = CreateDialog(windowsInstance, "ACCESSBRIDGESTATUSWINDOW", NULL, (DLGPROC) AccessBridgeDialogProc); But DLGPROC has parameters ( https://docs.microsoft.com/en-us/windows/win32/api/winuser/nc-winuser-dlgproc ) HWND Arg1, UINT Arg2, WPARAM Arg3, LPARAM Arg4 So probably the 3rd and 4th params should be ... WPARAM wParam, LPARAM lParam . One internal user claimed to have crashes because of this type mismatch . Additionally I found some unused declarations in WinAccessBridge.h probably we could delete them . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8249588 http://cr.openjdk.java.net/~mbaesken/webrevs/8249588.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From tejpal.rebari at oracle.com Fri Jul 17 13:16:40 2020 From: tejpal.rebari at oracle.com (Tejpal Rebari) Date: Fri, 17 Jul 2020 18:46:40 +0530 Subject: RFR: Nimbus L&F Fix for 8041701 is causing some Nimbus tests to fail Message-ID: <68282DCF-B2EE-4972-9F0A-EE2523A28CFA@oracle.com> Hi All, Please review the following fix for jdk16. Bug : https://bugs.openjdk.java.net/browse/JDK-8249619 Webrev : http://cr.openjdk.java.net/~trebari/swing/8249619/webrev00/ This change is revert of fix for JDK-8041701 . The fix for JDK-8041701 caused some internal NimbusLAF test to fail so need to reverted. JDK-8041701 will be reopened and re-worked for a proper fix. Thanks Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From pankaj.b.bansal at oracle.com Fri Jul 17 13:24:40 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Fri, 17 Jul 2020 18:54:40 +0530 Subject: RFR: Nimbus L&F Fix for 8041701 is causing some Nimbus tests to fail In-Reply-To: <68282DCF-B2EE-4972-9F0A-EE2523A28CFA@oracle.com> References: <68282DCF-B2EE-4972-9F0A-EE2523A28CFA@oracle.com> Message-ID: <4d25244b-7cf7-94d3-10a0-e1f4d53fe228@oracle.com> Looks ok to me -Pankaj On 17/07/20 6:46 PM, Tejpal Rebari wrote: > Hi All, > > Please review the following fix for jdk16. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8249619 > Webrev : http://cr.openjdk.java.net/~trebari/swing/8249619/webrev00/ > > > This change is revert of fix for JDK-8041701 > ?. > The fix for JDK-8041701 > ?caused some > internal NimbusLAF test to fail so need to reverted. > JDK-8041701 ?will be > reopened and re-worked for a proper fix. > > Thanks > Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jul 17 15:29:49 2020 From: philip.race at oracle.com (Philip Race) Date: Fri, 17 Jul 2020 08:29:49 -0700 Subject: RFR: Nimbus L&F Fix for 8041701 is causing some Nimbus tests to fail In-Reply-To: <68282DCF-B2EE-4972-9F0A-EE2523A28CFA@oracle.com> References: <68282DCF-B2EE-4972-9F0A-EE2523A28CFA@oracle.com> Message-ID: <5F11C3ED.7030700@oracle.com> Sound fine except do NOT re-open 8041701 - please file a new bug. -phil. On 7/17/20, 6:16 AM, Tejpal Rebari wrote: > Hi All, > > Please review the following fix for jdk16. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8249619 > Webrev : http://cr.openjdk.java.net/~trebari/swing/8249619/webrev00/ > > > This change is revert of fix for JDK-8041701 > . > The fix for JDK-8041701 > caused some > internal NimbusLAF test to fail so need to reverted. > JDK-8041701 will be > reopened and re-worked for a proper fix. > > Thanks > Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From tejpal.rebari at oracle.com Fri Jul 17 16:11:11 2020 From: tejpal.rebari at oracle.com (Tejpal Rebari) Date: Fri, 17 Jul 2020 21:41:11 +0530 Subject: RFR: Nimbus L&F Fix for 8041701 is causing some Nimbus tests to fail In-Reply-To: <5F11C3ED.7030700@oracle.com> References: <68282DCF-B2EE-4972-9F0A-EE2523A28CFA@oracle.com> <5F11C3ED.7030700@oracle.com> Message-ID: <05E7F85D-18EA-46AE-806B-843ACCEBEBF8@oracle.com> > On 17-Jul-2020, at 8:59 PM, Philip Race wrote: > > Sound fine except do NOT re-open 8041701 - please file a new bug. Ok, sure I will file a new bug. Can somebody please push this change, as I don?t have commit rights. Thanks Tejpal > > -phil. > > On 7/17/20, 6:16 AM, Tejpal Rebari wrote: >> >> Hi All, >> >> Please review the following fix for jdk16. >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8249619 >> Webrev : http://cr.openjdk.java.net/~trebari/swing/8249619/webrev00/ >> >> This change is revert of fix for JDK-8041701 . >> The fix for JDK-8041701 caused some internal NimbusLAF test to fail so need to reverted. >> JDK-8041701 will be reopened and re-worked for a proper fix. >> >> Thanks >> Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jul 17 16:36:55 2020 From: philip.race at oracle.com (Philip Race) Date: Fri, 17 Jul 2020 09:36:55 -0700 Subject: RFR: Nimbus L&F Fix for 8041701 is causing some Nimbus tests to fail In-Reply-To: <05E7F85D-18EA-46AE-806B-843ACCEBEBF8@oracle.com> References: <68282DCF-B2EE-4972-9F0A-EE2523A28CFA@oracle.com> <5F11C3ED.7030700@oracle.com> <05E7F85D-18EA-46AE-806B-843ACCEBEBF8@oracle.com> Message-ID: <5F11D3A7.9090100@oracle.com> Ok. I will push it. -phil. On 7/17/20, 9:11 AM, Tejpal Rebari wrote: > > >> On 17-Jul-2020, at 8:59 PM, Philip Race > > wrote: >> >> Sound fine except do NOT re-open 8041701 - please file a new bug. > > Ok, sure I will file a new bug. > Can somebody please push this change, as I don?t have commit rights. > > Thanks > Tejpal >> >> -phil. >> >> On 7/17/20, 6:16 AM, Tejpal Rebari wrote: >>> Hi All, >>> >>> Please review the following fix for jdk16. >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8249619 >>> Webrev : http://cr.openjdk.java.net/~trebari/swing/8249619/webrev00/ >>> >>> >>> This change is revert of fix for JDK-8041701 >>> . >>> The fix for JDK-8041701 >>> caused some >>> internal NimbusLAF test to fail so need to reverted. >>> JDK-8041701 will >>> be reopened and re-worked for a proper fix. >>> >>> Thanks >>> Tejpal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Sat Jul 18 12:44:01 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Sat, 18 Jul 2020 18:14:01 +0530 Subject: RFR JDK-8169959: javax/swing/JTable/6263446/bug6263446.java: Table should be editing Message-ID: <7A4887E2-1751-4DD4-BEA7-686A0564A73B@oracle.com> HI All, Please review a test fix for an issue where this test fails with message ""java.lang.RuntimeException: Table should be editing? in mach5 It seems it will fail with that message when the robot mouse event are executed without frame being visible on which the events are to be executed. So, the test is modified to add delay() and make frame on-top to allow frame to get visible. Also, the frame is moved to centre from default leftmost position to avoid mouse click on invalid position. Also, waitForIdle() is added at some place to make the test more stable. mach5 job results running for several iterations is added to JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8169959 webrev: http://cr.openjdk.java.net/~psadhukhan/8169959/webrev.0/ Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From ambarish.rapte at oracle.com Sat Jul 18 14:41:30 2020 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Sat, 18 Jul 2020 07:41:30 -0700 (PDT) Subject: RFR: 8249588 : libwindowsaccessbridge issues on 64bit Windows In-Reply-To: References: <5F108DCA.8080209@oracle.com> Message-ID: <4d676a67-d888-4d1b-9d6e-f63280f12902@default> Hi Phil and Matthias, I verified that JAWS starts normally with the updated libwindowsaccessbridge and reads the components as expected. Also, verified that the tools jaccessinspector and jaccesswalker start and behave same before and after this change. Regards, Ambarish From: Baesken, Matthias Sent: Friday, July 17, 2020 11:55 AM To: Philip Race Cc: swing-dev at openjdk.java.net Subject: Re: RFR: 8249588 : libwindowsaccessbridge issues on 64bit Windows Hi Phil, thanks for asking your colleagues to verify it . Best regards, Matthias From: Philip Race Sent: Donnerstag, 16. Juli 2020 19:27 To: Baesken, Matthias Cc: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: RFR: 8249588 : libwindowsaccessbridge issues on 64bit Windows This looks OK but I've asked folks with access to JAWS to apply and verify it. We'll wait for those results. And when we are done, please push to jdk/client. -phil. On 7/16/20, 1:02 AM, Baesken, Matthias wrote: Hello, looks like libwindowsaccessbridge has some issues in native coding on 64bit Windows , probably it was developed with 32bit in mind And still misses a few adjustments. WinAccessBridge .h/cpp contains BOOL CALLBACK AccessBridgeDialogProc(HWND hDlg, UINT message, UINT wParam, LONG lParam); and theDialogWindow = CreateDialog(windowsInstance, "ACCESSBRIDGESTATUSWINDOW", NULL, (DLGPROC) AccessBridgeDialogProc); But DLGPROC has parameters ( https://docs.microsoft.com/en-us/windows/win32/api/winuser/nc-winuser-dlgproc ) HWND Arg1, UINT Arg2, WPARAM Arg3, LPARAM Arg4 So probably the 3rd and 4th params should be . WPARAM wParam, LPARAM lParam . One internal user claimed to have crashes because of this type mismatch . Additionally I found some unused declarations in WinAccessBridge.h probably we could delete them . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8249588 HYPERLINK "http://cr.openjdk.java.net/%7Embaesken/webrevs/8249588.0/"http://cr.openjdk.java.net/~mbaesken/webrevs/8249588.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Sun Jul 19 12:13:39 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Sun, 19 Jul 2020 17:43:39 +0530 Subject: RFR JDK-8146451: javax/swing/JComponent/4337267/bug4337267.java failed on Windows Message-ID: Hi All, Please review a test-fix for an issue seen to be failing in windows in mach5 with mismatch in bufferedimage. It seems the test is run asynchronously in test.run() under SwingUtilities.invokeLater which is causing the test to be unstable in mach5. Also, the actual BufferedImage check inside test.run() is done again asynchronously under another invokeLater(). Although it's not invalid, it's causing some instability. Proposed fix is to run the test under invokeAndWait() synchronously. mach5 job run for several iterations has passed and link is present in JBS. Bug: https://bugs.openjdk.java.net/browse/JDK-8146451 webrev: http://cr.openjdk.java.net/~psadhukhan/8146451/webrev.0/ Regards Prasanta From pankaj.b.bansal at oracle.com Sun Jul 19 18:28:56 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Sun, 19 Jul 2020 23:58:56 +0530 Subject: RFR: 8239137: JAWS does not always announce the value of JSliders in JColorChooser Message-ID: <05eecb2c-b7ef-ce37-7fd3-f4b4b8fb999a@oracle.com> Hi All, Please review the following fix for jdk16. Bug : https://bugs.openjdk.java.net/browse/JDK-8239137 webrev: http://cr.openjdk.java.net/~pbansal/8239137/webrev02/ Issue: The JAWS does not announce the value of JSlider in JColorChooser Cause: The JSlider and JSpinner are kept in Sync in JColorChooser by changing the value of other component when one is used. eg, when we change color value using JSlider, the JSpinner value is also changed to keep the two in Sync. This results in two accessibility value change events being sent to JAWS (one for JSlider and JSpinner each) instead of just one for JSlider. The event in JSlider is being sent from setValue method, whereas in case of JSpinner, the event is being sent from a AccessibleJSpinner stateChanged method which is added as changeListener to JSpinner. This results in situation where the event for JSpinner is always being sent first whether we are using JSlider or JSpinner. It looks like JAWS is not able to process all the events being sent quickly. So, the JSlider event is not being processed properly by JAWS. Fix: The fix is to add the AccessibleJSlider as a ChangeListener on the JSlider and then sending the accesssiblity value change event from there instead of sending it from setValue method like being done in JSpinner. This results in the accessibility events being sent to JAWS in the order they are being changed. JAWS is able to announce the value properly for JSlider and JSpinner. This can be tested by running any JColorchooser sample program (One such sample program is attached in JBS). I have run full jtreg and jck tests on mach5. The change is not breaking any test. Links in JBS. Regards Pankaj From matthias.baesken at sap.com Mon Jul 20 06:32:27 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 20 Jul 2020 06:32:27 +0000 Subject: RFR: 8249588 : libwindowsaccessbridge issues on 64bit Windows In-Reply-To: <4d676a67-d888-4d1b-9d6e-f63280f12902@default> References: <5F108DCA.8080209@oracle.com> <4d676a67-d888-4d1b-9d6e-f63280f12902@default> Message-ID: Hi Ambarish, thanks for verifying . May I add you + Phil as reviewers ? Best regards, Matthias From: Ambarish Rapte Sent: Samstag, 18. Juli 2020 16:42 To: Baesken, Matthias ; Philip Race Cc: swing-dev at openjdk.java.net Subject: RE: RFR: 8249588 : libwindowsaccessbridge issues on 64bit Windows Hi Phil and Matthias, I verified that JAWS starts normally with the updated libwindowsaccessbridge and reads the components as expected. Also, verified that the tools jaccessinspector and jaccesswalker start and behave same before and after this change. Regards, Ambarish From: Baesken, Matthias > Sent: Friday, July 17, 2020 11:55 AM To: Philip Race > Cc: swing-dev at openjdk.java.net Subject: Re: RFR: 8249588 : libwindowsaccessbridge issues on 64bit Windows Hi Phil, thanks for asking your colleagues to verify it . Best regards, Matthias From: Philip Race > Sent: Donnerstag, 16. Juli 2020 19:27 To: Baesken, Matthias > Cc: swing-dev at openjdk.java.net Subject: Re: RFR: 8249588 : libwindowsaccessbridge issues on 64bit Windows This looks OK but I've asked folks with access to JAWS to apply and verify it. We'll wait for those results. And when we are done, please push to jdk/client. -phil. On 7/16/20, 1:02 AM, Baesken, Matthias wrote: Hello, looks like libwindowsaccessbridge has some issues in native coding on 64bit Windows , probably it was developed with 32bit in mind And still misses a few adjustments. WinAccessBridge .h/cpp contains BOOL CALLBACK AccessBridgeDialogProc(HWND hDlg, UINT message, UINT wParam, LONG lParam); and theDialogWindow = CreateDialog(windowsInstance, "ACCESSBRIDGESTATUSWINDOW", NULL, (DLGPROC) AccessBridgeDialogProc); But DLGPROC has parameters ( https://docs.microsoft.com/en-us/windows/win32/api/winuser/nc-winuser-dlgproc ) HWND Arg1, UINT Arg2, WPARAM Arg3, LPARAM Arg4 So probably the 3rd and 4th params should be ... WPARAM wParam, LPARAM lParam . One internal user claimed to have crashes because of this type mismatch . Additionally I found some unused declarations in WinAccessBridge.h probably we could delete them . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8249588 http://cr.openjdk.java.net/~mbaesken/webrevs/8249588.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Jul 22 07:44:22 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 22 Jul 2020 13:14:22 +0530 Subject: RFR JDK-8232927:ToolTipManager is unable to force heavy weight popups Message-ID: Hi All, Please review a fix for an issue whereby Java developer is not able to to force the tooltips to be displayed in a heavyweight popup. In ToolTipManager#showTipWindow() , even if we do "ToolTipManager.setLightWeightPopupEnabled(false)" we can only force a medium weight popup as can be seen here [http://hg.openjdk.java.net/jdk/client/file/f054a3a03050/src/java.desktop/share/classes/javax/swing/ToolTipManager.java#l338] In addition, there is also a field "heavyWeightPopupEnabled" inside the ToolTipManager which is not used.. There should be at least one way to force a heavy weight popup in the ToolTipManager. Proposed fix is to give an option to developer to force tooltip to be displayed in HW. CSR will be raised after technical review Bug: https://bugs.openjdk.java.net/browse/JDK-8232927 webrev: http://cr.openjdk.java.net/~psadhukhan/8232927/webrev.0 Regards Prasanta From Sergey.Bylokhov at oracle.com Wed Jul 22 20:52:39 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 22 Jul 2020 13:52:39 -0700 Subject: RFR JDK-8232927:ToolTipManager is unable to force heavy weight popups In-Reply-To: References: Message-ID: Hi, Prasanta. Isn't the current bug a duplicate of https://bugs.openjdk.java.net/browse/JDK-8147521 ? On 22.07.2020 00:44, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue whereby Java developer is not able to to force the tooltips to be displayed in a heavyweight popup. > > In ToolTipManager#showTipWindow() , even if we do "ToolTipManager.setLightWeightPopupEnabled(false)" we can only force a medium weight popup as can be seen here > > [http://hg.openjdk.java.net/jdk/client/file/f054a3a03050/src/java.desktop/share/classes/javax/swing/ToolTipManager.java#l338] > > In addition, there is also a field "heavyWeightPopupEnabled" inside the ToolTipManager which is not used.. > There should be at least one way to force a heavy weight popup in the ToolTipManager. > > Proposed fix is to give an option to developer to force tooltip to be displayed in HW. CSR will be raised after technical review > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232927 > > webrev: http://cr.openjdk.java.net/~psadhukhan/8232927/webrev.0 > > Regards > Prasanta > > -- Best regards, Sergey. From philip.race at oracle.com Wed Jul 22 21:05:49 2020 From: philip.race at oracle.com (Philip Race) Date: Wed, 22 Jul 2020 14:05:49 -0700 Subject: RFR JDK-8232927:ToolTipManager is unable to force heavy weight popups In-Reply-To: References: Message-ID: <5F18AA2D.9070805@oracle.com> Sure looks like it. Comments - the side effect of 164 lightWeightPopupEnabled = !aFlag; needs to be called out. Also I am not sure what to make of the fact that one may then call setHeavyWeightPopupEnabled(true); setLightWeightPopupEnabled(true); and break what was set by the first call. What is supposed to happen then ? I think you need to look at the whole picture here. Also (minor nit after the big issue) you always should have @since on new methods etc. -phil. On 7/22/20, 1:52 PM, Sergey Bylokhov wrote: > Hi, Prasanta. > > Isn't the current bug a duplicate of > https://bugs.openjdk.java.net/browse/JDK-8147521 > ? > > On 22.07.2020 00:44, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for an issue whereby Java developer is not able >> to to force the tooltips to be displayed in a heavyweight popup. >> >> In ToolTipManager#showTipWindow() , even if we do >> "ToolTipManager.setLightWeightPopupEnabled(false)" we can only force >> a medium weight popup as can be seen here >> >> [http://hg.openjdk.java.net/jdk/client/file/f054a3a03050/src/java.desktop/share/classes/javax/swing/ToolTipManager.java#l338] >> >> >> In addition, there is also a field "heavyWeightPopupEnabled" inside >> the ToolTipManager which is not used.. >> There should be at least one way to force a heavy weight popup in the >> ToolTipManager. >> >> Proposed fix is to give an option to developer to force tooltip to be >> displayed in HW. CSR will be raised after technical review >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8232927 >> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8232927/webrev.0 >> >> Regards >> Prasanta >> >> > > From prasanta.sadhukhan at oracle.com Thu Jul 23 05:46:15 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 23 Jul 2020 11:16:15 +0530 Subject: RFR JDK-8232927:ToolTipManager is unable to force heavy weight popups In-Reply-To: References: Message-ID: <12f25570-fda5-af67-261e-24cebafa0331@oracle.com> Hi Sergey, Not exactly, that is support of heavyweight popup in PopupFactory class. This is in Tooltipmanager which can utilise PopupFactory Heavyweight enhancement but there's no way to create HW popup through TooltipManager class which as shown in http://hg.openjdk.java.net/jdk/client/file/f054a3a03050/src/java.desktop/share/classes/javax/swing/ToolTipManager.java#l338] can create only LW and MW popup, not HW. Regards Prasanta On 23-Jul-20 2:22 AM, Sergey Bylokhov wrote: > Hi, Prasanta. > > Isn't the current bug a duplicate of > https://bugs.openjdk.java.net/browse/JDK-8147521 > ? > > On 22.07.2020 00:44, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for an issue whereby Java developer is not able >> to to force the tooltips to be displayed in a heavyweight popup. >> >> In ToolTipManager#showTipWindow() , even if we do >> "ToolTipManager.setLightWeightPopupEnabled(false)" we can only force >> a medium weight popup as can be seen here >> >> [http://hg.openjdk.java.net/jdk/client/file/f054a3a03050/src/java.desktop/share/classes/javax/swing/ToolTipManager.java#l338] >> >> >> In addition, there is also a field "heavyWeightPopupEnabled" inside >> the ToolTipManager which is not used.. >> There should be at least one way to force a heavy weight popup in the >> ToolTipManager. >> >> Proposed fix is to give an option to developer to force tooltip to be >> displayed in HW. CSR will be raised after technical review >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8232927 >> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8232927/webrev.0 >> >> Regards >> Prasanta >> >> > > From prasanta.sadhukhan at oracle.com Thu Jul 23 05:50:48 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 23 Jul 2020 11:20:48 +0530 Subject: RFR JDK-8232927:ToolTipManager is unable to force heavy weight popups In-Reply-To: <5F18AA2D.9070805@oracle.com> References: <5F18AA2D.9070805@oracle.com> Message-ID: <76fad6f5-bc41-47c2-40e4-6aa374b2c76f@oracle.com> On 23-Jul-20 2:35 AM, Philip Race wrote: > Sure looks like it. > > Comments > ?- the side effect of > > ?164???????? lightWeightPopupEnabled = !aFlag; > > needs to be called out. > That is to make sure if it is not HW, it should be LW. > Also I am not sure what to make of the fact that one may then call > > setHeavyWeightPopupEnabled(true); > setLightWeightPopupEnabled(true); > It should be LW as that is the last call. Also, in TooltipManager#showTipWindow() it first checks if it is LW, so that will held preference. Regards Prasanta > > and break what was set by the first call. > > What is supposed to happen then ? > > I think you need to look at the whole picture here. > > Also (minor nit after the big issue) you always should have @since > on new methods etc. > > -phil. > > On 7/22/20, 1:52 PM, Sergey Bylokhov wrote: >> Hi, Prasanta. >> >> Isn't the current bug a duplicate of >> https://bugs.openjdk.java.net/browse/JDK-8147521 >> ? >> >> On 22.07.2020 00:44, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for an issue whereby Java developer is not able >>> to to force the tooltips to be displayed in a heavyweight popup. >>> >>> In ToolTipManager#showTipWindow() , even if we do >>> "ToolTipManager.setLightWeightPopupEnabled(false)" we can only force >>> a medium weight popup as can be seen here >>> >>> [http://hg.openjdk.java.net/jdk/client/file/f054a3a03050/src/java.desktop/share/classes/javax/swing/ToolTipManager.java#l338] >>> >>> >>> In addition, there is also a field "heavyWeightPopupEnabled" inside >>> the ToolTipManager which is not used.. >>> There should be at least one way to force a heavy weight popup in >>> the ToolTipManager. >>> >>> Proposed fix is to give an option to developer to force tooltip to >>> be displayed in HW. CSR will be raised after technical review >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8232927 >>> >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8232927/webrev.0 >>> >>> Regards >>> Prasanta >>> >>> >> >> From Sergey.Bylokhov at oracle.com Thu Jul 23 06:25:00 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 22 Jul 2020 23:25:00 -0700 Subject: RFR JDK-8232927:ToolTipManager is unable to force heavy weight popups In-Reply-To: <12f25570-fda5-af67-261e-24cebafa0331@oracle.com> References: <12f25570-fda5-af67-261e-24cebafa0331@oracle.com> Message-ID: <2823454e-236f-ce05-5e78-355b1dd04c72@oracle.com> On 22.07.2020 22:46, Prasanta Sadhukhan wrote: > Hi Sergey, > > Not exactly, that is support of heavyweight popup in PopupFactory class. This is in Tooltipmanager which can utilise PopupFactory Heavyweight enhancement but there's no way to create HW popup through TooltipManager class which as shown in > > http://hg.openjdk.java.net/jdk/client/file/f054a3a03050/src/java.desktop/share/classes/javax/swing/ToolTipManager.java#l338] > > can create only LW and MW popup, not HW. The MEDIUM_WEIGHT_POPUP and the LIGHT_WEIGHT_POPUP passed to the setPopupType are just a hints for the popupFactory, both could be ignored. For example if tooltip will be shown outside of the owner then the HW popup will be used(even if LW or MW were requested). And to expose the PopupFactory.setPopupType() to the user the fix for JDK-8147521 was implemented, it looks the same thing as the current bug: https://bugs.openjdk.java.net/browse/CCC-8147521 > Regards > Prasanta > On 23-Jul-20 2:22 AM, Sergey Bylokhov wrote: >> Hi, Prasanta. >> >> Isn't the current bug a duplicate of >> https://bugs.openjdk.java.net/browse/JDK-8147521 >> ? >> >> On 22.07.2020 00:44, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for an issue whereby Java developer is not able to to force the tooltips to be displayed in a heavyweight popup. >>> >>> In ToolTipManager#showTipWindow() , even if we do "ToolTipManager.setLightWeightPopupEnabled(false)" we can only force a medium weight popup as can be seen here >>> >>> [http://hg.openjdk.java.net/jdk/client/file/f054a3a03050/src/java.desktop/share/classes/javax/swing/ToolTipManager.java#l338] >>> >>> In addition, there is also a field "heavyWeightPopupEnabled" inside the ToolTipManager which is not used.. >>> There should be at least one way to force a heavy weight popup in the ToolTipManager. >>> >>> Proposed fix is to give an option to developer to force tooltip to be displayed in HW. CSR will be raised after technical review >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8232927 >>> >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8232927/webrev.0 >>> >>> Regards >>> Prasanta >>> >>> >> >> -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Thu Jul 23 06:37:44 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 23 Jul 2020 12:07:44 +0530 Subject: RFR JDK-8232927:ToolTipManager is unable to force heavy weight popups In-Reply-To: <2823454e-236f-ce05-5e78-355b1dd04c72@oracle.com> References: <12f25570-fda5-af67-261e-24cebafa0331@oracle.com> <2823454e-236f-ce05-5e78-355b1dd04c72@oracle.com> Message-ID: On 23-Jul-20 11:55 AM, Sergey Bylokhov wrote: > On 22.07.2020 22:46, Prasanta Sadhukhan wrote: >> Hi Sergey, >> >> Not exactly, that is support of heavyweight popup in PopupFactory >> class. This is in Tooltipmanager which can utilise PopupFactory >> Heavyweight enhancement but there's no way to create HW popup through >> TooltipManager class which as shown in >> >> http://hg.openjdk.java.net/jdk/client/file/f054a3a03050/src/java.desktop/share/classes/javax/swing/ToolTipManager.java#l338] >> >> >> can create only LW and MW popup, not HW. > > The MEDIUM_WEIGHT_POPUP and the LIGHT_WEIGHT_POPUP passed to the > setPopupType are just a hints for the > popupFactory, both could be ignored. For example if tooltip will be shown > outside of the owner then the HW popup will be used(even if LW or MW > were requested). > And to expose the PopupFactory.setPopupType() to the user the fix for > JDK-8147521 was implemented, OK, but I dont think that's right as setPopupType() is not public and not available to the user. Maybe for this bug, we can just make that method public!!!! Regards Prasanta > it looks the same thing as the current bug: > https://bugs.openjdk.java.net/browse/CCC-8147521 > >> Regards >> Prasanta >> On 23-Jul-20 2:22 AM, Sergey Bylokhov wrote: >>> Hi, Prasanta. >>> >>> Isn't the current bug a duplicate of >>> https://bugs.openjdk.java.net/browse/JDK-8147521 >>> ? >>> >>> On 22.07.2020 00:44, Prasanta Sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a fix for an issue whereby Java developer is not able >>>> to to force the tooltips to be displayed in a heavyweight popup. >>>> >>>> In ToolTipManager#showTipWindow() , even if we do >>>> "ToolTipManager.setLightWeightPopupEnabled(false)" we can only >>>> force a medium weight popup as can be seen here >>>> >>>> [http://hg.openjdk.java.net/jdk/client/file/f054a3a03050/src/java.desktop/share/classes/javax/swing/ToolTipManager.java#l338] >>>> >>>> >>>> In addition, there is also a field "heavyWeightPopupEnabled" inside >>>> the ToolTipManager which is not used.. >>>> There should be at least one way to force a heavy weight popup in >>>> the ToolTipManager. >>>> >>>> Proposed fix is to give an option to developer to force tooltip to >>>> be displayed in HW. CSR will be raised after technical review >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8232927 >>>> >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8232927/webrev.0 >>>> >>>> Regards >>>> Prasanta >>>> >>>> >>> >>> > > From Sergey.Bylokhov at oracle.com Thu Jul 23 07:14:59 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 23 Jul 2020 00:14:59 -0700 Subject: RFR JDK-8232927:ToolTipManager is unable to force heavy weight popups In-Reply-To: References: <12f25570-fda5-af67-261e-24cebafa0331@oracle.com> <2823454e-236f-ce05-5e78-355b1dd04c72@oracle.com> Message-ID: <53ca1396-6aa7-0aea-6e8e-9f32ba364820@oracle.com> On 22.07.2020 23:37, Prasanta Sadhukhan wrote: > > On 23-Jul-20 11:55 AM, Sergey Bylokhov wrote: >> On 22.07.2020 22:46, Prasanta Sadhukhan wrote: >>> Hi Sergey, >>> >>> Not exactly, that is support of heavyweight popup in PopupFactory class. This is in Tooltipmanager which can utilise PopupFactory Heavyweight enhancement but there's no way to create HW popup through TooltipManager class which as shown in >>> >>> http://hg.openjdk.java.net/jdk/client/file/f054a3a03050/src/java.desktop/share/classes/javax/swing/ToolTipManager.java#l338] >>> >>> can create only LW and MW popup, not HW. >> >> The MEDIUM_WEIGHT_POPUP and the LIGHT_WEIGHT_POPUP passed to the setPopupType are just a hints for the >> popupFactory, both could be ignored. For example if tooltip will be shown >> outside of the owner then the HW popup will be used(even if LW or MW were requested). >> And to expose the PopupFactory.setPopupType() to the user the fix for JDK-8147521 was implemented, > > OK, but I dont think that's right as setPopupType() is not public and not available to the user. Maybe for this bug, we can just make that method public!!!! That was the exact purpose of the JDK-8147521, to make the functionality of the setPopupType() public, without making the method itself public. -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Thu Jul 23 09:28:54 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 23 Jul 2020 14:58:54 +0530 Subject: RFR JDK-7184956: [macosx] JPopupMenu.setDefaultLightPopupEnable(true) doesn't work correctly Message-ID: <56513ead-90cc-24ad-564d-86f99b2eb079@oracle.com> Hi All, Please review a fix for an issue in macos where regression test javax/swing/JPopupMenu/6800513/bug6800513.java fails with java.lang.Exception: popup class is: javax.swing.PopupFactory$HeavyWeightPopup, expected: javax.swing.PopupFactory$LightWeightPopup This is because com.apple.laf.ScreenPopupFactory#getPopup method always sets HEAVY_WEIGHT_POPUP when com.apple.laf.ScreenPopupFactory#fIsActive is true and fIsActive is always set to true in AquaLookAndFeel#initialize() Proposed fix is to use PopupFactory.getPopup() and let the PopupFactory decide which popup type to show. Bug: https://bugs.openjdk.java.net/browse/JDK-7184956 webrev: http://cr.openjdk.java.net/~psadhukhan/7184956/webrev.0/ Regards Prasanta From Sergey.Bylokhov at oracle.com Thu Jul 23 23:15:50 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 23 Jul 2020 16:15:50 -0700 Subject: RFR JDK-7184956: [macosx] JPopupMenu.setDefaultLightPopupEnable(true) doesn't work correctly In-Reply-To: <56513ead-90cc-24ad-564d-86f99b2eb079@oracle.com> References: <56513ead-90cc-24ad-564d-86f99b2eb079@oracle.com> Message-ID: <1d18833a-b696-dea7-35f6-1e65a5375143@oracle.com> Hi, Prasanta. > This is because com.apple.laf.ScreenPopupFactory#getPopup method always sets HEAVY_WEIGHT_POPUP when com.apple.laf.ScreenPopupFactory#fIsActive is true and fIsActive is always set to true in AquaLookAndFeel#initialize()>> Proposed fix is to use PopupFactory.getPopup() and let the PopupFactory decide which popup type to show. I would like to highlight that the ScreenPopupFactory itself is also a PopupFactory, and it intentionally overrides getPopup() method to always return HW popup, because other popup types are not implemented by the Aqua L&F, you can check that by the menubar/menuites in the SwingSet2, after the fix the popuop menu does not look like the native popup due to absent of shadows/transparency. -- Best regards, Sergey. From tejpal.rebari at oracle.com Fri Jul 24 09:06:15 2020 From: tejpal.rebari at oracle.com (Tejpal Rebari) Date: Fri, 24 Jul 2020 14:36:15 +0530 Subject: RFR: 8249674: Redo: Nimbus JTree renderer properties persist across L&F changes Message-ID: <3B18E219-4ED8-4F58-8D58-7F1D756FF9F5@oracle.com> Hi All, Please review the following fix for jdk16. Bug : https://bugs.openjdk.java.net/browse/JDK-8249674 Webrev : http://cr.openjdk.java.net/~trebari/swing/8249674/webrev00/ This is a modified fix for https://bugs.openjdk.java.net/browse/JDK-8041701 which caused some internal test to fail. Issue : UI properties ?Tree.leafIcon?, ?Tree.closedIcon?, ?Tree.openIcon?, ?Tree.selectionForeground? ..etc are supposed to be instances of UIResource if they are defined by LAF. In Nimbus LAF all the above properties are defined , but none of them implement UIResource, this causes them to persists when LAF is changed. This leaves artefacts when switching from nimbus to other LAFs. Fix : Fix is to make use of UIResource for the above mentioned uiProperties. Making NimbuIcon implements the UIResource was working fine earlier so keeping the change same. The second part of the earlier fix "class DerivedColor extends Color implements UIResource" caused the internal test failure, So changed this fix to keep the DerivedColor class same and for the uiProperties Tree.selectionForeground? ..etc use the UIResource class that is inside the DerivedColor. These changes were made in skin.laf file. Testing : Tested on all three platform, and all internal tests.Link is in JBS. In test also added the part which was the reason of revert of earlier fix. The test fails with the fix of 8041701 and passes with the current fix. Regards Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From pankaj.b.bansal at oracle.com Sun Jul 26 10:54:58 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Sun, 26 Jul 2020 16:24:58 +0530 Subject: RFR: 8249548: backward focus traversal gets stuck in button group Message-ID: <5df102aa-a5ae-afd9-95b7-d8b42fa9d735@oracle.com> Hi All, Please review the following fix for jdk16. Bug : https://bugs.openjdk.java.net/browse/JDK-8249548 webrev: http://cr.openjdk.java.net/~pbansal/8249548/webrev00/ Issue: If few ToggleButtons are added to button group, the backward focus traversal can get stuck in few scenarios while using LayoutFocusTraversalPolicy. For exaple, if a TextField is added to a frame and a Button Group is added with two buttons and the second button in set selected, we can not move the focus from Button Group to Text Field using "Shift+Tab". More details in JBS. Cause: The LayoutFocusTraversalPolicy uses SortingFocusTraversalPolicy always selects first button for focus traversal in button group for Toggle Button. This can be changed by Component if one of the button in the button group is set selected. This results in the selected Button being selected again and again for selection on pressing "Shift+Tab". This results in focus being stuck at same position. This is a generic issue and it is observed in all L&F for JToggleButton. The JRadioButton does not have this issue as BasicRadioButtonUI and AquaRadioButtonUI have code to handle this issue but the Synth L&F has this issue for JRadioButton also. So, this issue can be observed in both ToggleButton and RadioButton in nimbus L&F. Fix: The fix is to add the code to handle this in BasicButtonUI class, so that it is available for all L&F without copying it in different L&F classes. The focus traversal works fine after this change for all L&F for both ToggleButton and RadioButton. Along with the current problem, this fix is also fixes issue like we cant change the selected button and focus in ToggleButton group like RadioButton group. An automated test is added. I have ran the Mach5 with all tests and this is not causing any failures. Links in JBS. Regards Pankaj -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Jul 27 06:42:33 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 27 Jul 2020 12:12:33 +0530 Subject: RFR JDK-7184956: [macosx] JPopupMenu.setDefaultLightPopupEnable(true) doesn't work correctly In-Reply-To: <1d18833a-b696-dea7-35f6-1e65a5375143@oracle.com> References: <56513ead-90cc-24ad-564d-86f99b2eb079@oracle.com> <1d18833a-b696-dea7-35f6-1e65a5375143@oracle.com> Message-ID: <6b7f6166-3fa3-7059-6edc-b26d653db1ca@oracle.com> On 24-Jul-20 4:45 AM, Sergey Bylokhov wrote: > Hi, Prasanta. > >> This is because com.apple.laf.ScreenPopupFactory#getPopup method >> always sets HEAVY_WEIGHT_POPUP when >> com.apple.laf.ScreenPopupFactory#fIsActive is true and fIsActive is >> always set to true in AquaLookAndFeel#initialize()>> Proposed fix is >> to use PopupFactory.getPopup() and let the PopupFactory decide which >> popup type to show. > I would like to highlight that the ScreenPopupFactory itself is also a > PopupFactory, and > it intentionally overrides getPopup() method to always return HW > popup, because other > popup types are not implemented by the Aqua L&F, OK. I could not see any JBS issue asking for non-HW popup support in AquaL&F (even this issue is about regression testcase failing in mac) and we got mac build in jdk6 timeframe (so it's been a long way since),? so it seems to me non-HW popup support is not needed for AquaL&F. Can we put a check in the test to omit this from Aqua http://cr.openjdk.java.net/~psadhukhan/7184956/webrev.1/ and ask from community if non-HW popup is indeed needed for Aqua, in which case we can create an enhancement task in JBS? Regards Prasanta > you can check that by the menubar/menuites > in the SwingSet2, after the fix the popuop menu does not look like the > native popup due to > absent of shadows/transparency. > > From prasanta.sadhukhan at oracle.com Mon Jul 27 08:51:57 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 27 Jul 2020 14:21:57 +0530 Subject: RFR: 8249674: Redo: Nimbus JTree renderer properties persist across L&F changes In-Reply-To: <3B18E219-4ED8-4F58-8D58-7F1D756FF9F5@oracle.com> References: <3B18E219-4ED8-4F58-8D58-7F1D756FF9F5@oracle.com> Message-ID: Fix looks ok to me. But I think the test is more appropriate if it is placed in javax/swing/plaf/nimbus directory. Also, the test can be enhanced a bit to not fail at the first attempt as we are testing 8 different properties, so I think it will be good if you will store the results in a string for each property that fails, and finally at the end throw failure with stored string. Regards Prasanta On 24-Jul-20 2:36 PM, Tejpal Rebari wrote: > Hi All, > Please review the following fix for jdk16. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8249674 > Webrev : http://cr.openjdk.java.net/~trebari/swing/8249674/webrev00/ > > This is a modified fix for > https://bugs.openjdk.java.net/browse/JDK-8041701 > which caused some internal test to fail. > > Issue : UI properties ?Tree.leafIcon?, ?Tree.closedIcon?, ?Tree.openIcon?, > ?Tree.selectionForeground??..etc are supposed to be instances of > UIResource > if they are?defined by LAF. > > In Nimbus LAF all the above properties are defined , but none of them > implement > UIResource, this causes them to?persists when LAF is changed. > This leaves artefacts when switching from nimbus to other LAFs. > > Fix : ?Fix is to make use of UIResource for the > abovementioned?uiProperties. > Making NimbuIcon implements the UIResource was working fine earlier > so keeping the change same. > > The second part of the earlier fix "class DerivedColor extends Color > implements UIResource" > caused the internal test failure, > > So changed this fix to keep the DerivedColor class same and for the > uiProperties > Tree.selectionForeground??..etc ?use the UIResource > class that is inside the DerivedColor. These changes were made in > skin.laf file. > > Testing : Tested on all three platform, and all internal tests.Link is > in JBS. > In test?also added the part?which was the?reason of revert of earlier fix. > The test fails with the fix of 8041701 and passes with the current fix. > > > Regards > Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Jul 27 09:07:59 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 27 Jul 2020 14:37:59 +0530 Subject: RFR JDK-8169959: javax/swing/JTable/6263446/bug6263446.java: Table should be editing In-Reply-To: <7A4887E2-1751-4DD4-BEA7-686A0564A73B@oracle.com> References: <7A4887E2-1751-4DD4-BEA7-686A0564A73B@oracle.com> Message-ID: ping? any reviewers? On 18-Jul-20 6:14 PM, Prasanta Sadhukhan wrote: > HI All, > > Please review a test fix for an issue where this test fails with > message ""java.lang.RuntimeException: Table should be editing? in mach5 > ?It seems it will fail with that message when the robot mouse event > are executed without frame being visible on which the events are to be > executed. > > So, the test is modified to add delay() and make frame on-top to allow > frame to get visible. Also, the frame is moved to centre from default > leftmost position to avoid mouse click on invalid position. > Also, waitForIdle() is added at some place to make the test more stable. > > mach5 job results running for several iterations is added to JBS > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169959 > webrev: http://cr.openjdk.java.net/~psadhukhan/8169959/webrev.0/ > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Jul 27 09:08:25 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 27 Jul 2020 14:38:25 +0530 Subject: RFR JDK-8146451: javax/swing/JComponent/4337267/bug4337267.java failed on Windows In-Reply-To: References: Message-ID: <04e8731e-c5ac-2094-4cce-17637f0c4d60@oracle.com> ping? any reviewers? On 19-Jul-20 5:43 PM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a test-fix for an issue seen to be failing in windows in > mach5 with mismatch in bufferedimage. > > It seems the test is run asynchronously in test.run() under > SwingUtilities.invokeLater which is causing the test to be unstable in > mach5. > > Also, the actual BufferedImage check inside test.run() is done again > asynchronously under another invokeLater(). Although it's not invalid, > it's causing some instability. > > Proposed fix is to run the test under invokeAndWait() synchronously. > > mach5 job run for several iterations has passed and link is present in > JBS. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8146451 > > webrev: http://cr.openjdk.java.net/~psadhukhan/8146451/webrev.0/ > > Regards > Prasanta From Sergey.Bylokhov at oracle.com Mon Jul 27 22:17:20 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 27 Jul 2020 15:17:20 -0700 Subject: RFR JDK-7184956: [macosx] JPopupMenu.setDefaultLightPopupEnable(true) doesn't work correctly In-Reply-To: <6b7f6166-3fa3-7059-6edc-b26d653db1ca@oracle.com> References: <56513ead-90cc-24ad-564d-86f99b2eb079@oracle.com> <1d18833a-b696-dea7-35f6-1e65a5375143@oracle.com> <6b7f6166-3fa3-7059-6edc-b26d653db1ca@oracle.com> Message-ID: <5181e369-41b9-7f0e-f9cf-74956d258c7f@oracle.com> On 26.07.2020 23:42, Prasanta Sadhukhan wrote: > OK. I could not see any JBS issue asking for non-HW popup support in AquaL&F (even this issue is about regression testcase failing in mac) and we got mac build in jdk6 timeframe (so it's been a long way since), so it seems to me non-HW popup support is not needed for AquaL&F.> Can we put a check in the test to omit this from Aqua > > http://cr.openjdk.java.net/~psadhukhan/7184956/webrev.1/ > > and ask from community if non-HW popup is indeed needed for Aqua, in which case we can create an enhancement task in JBS? That's not enhanced, it is a bug that JPopupMenu.setDefaultLightPopupEnable does not work properly. And the JBS issue for "non-HW popup support in AquaL&F" is actually the current bug, which was found by the bug6800513 test(which was created for the similar bug in GTK l&f). -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Jul 28 00:38:40 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 27 Jul 2020 17:38:40 -0700 Subject: RFR: 8239137: JAWS does not always announce the value of JSliders in JColorChooser In-Reply-To: <05eecb2c-b7ef-ce37-7fd3-f4b4b8fb999a@oracle.com> References: <05eecb2c-b7ef-ce37-7fd3-f4b4b8fb999a@oracle.com> Message-ID: <8990e21f-93a3-7d8b-f3b4-f6541203fab2@oracle.com> Looks fine. Please note you will need a CSR for this change. On 19.07.2020 11:28, Pankaj Bansal wrote: > Hi All, > > Please review the following fix for jdk16. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8239137 > webrev: http://cr.openjdk.java.net/~pbansal/8239137/webrev02/ > > Issue: The JAWS does not announce the value of JSlider in JColorChooser > > Cause: The JSlider and JSpinner are kept in Sync in JColorChooser by changing the value of other component when one is used. eg, when we change color value using JSlider, the JSpinner value is also changed to keep the two in Sync. This results in two accessibility value change events being sent to JAWS (one for JSlider and JSpinner each) instead of just one for JSlider. > > The event in JSlider is being sent from setValue method, whereas in case of JSpinner, the event is being sent from a AccessibleJSpinner stateChanged method which is added as changeListener to JSpinner. This results in situation where the event for JSpinner is always being sent first whether we are using JSlider or JSpinner. It looks like JAWS is not able to process all the events being sent quickly. So, the JSlider event is not being processed properly by JAWS. > > > Fix: The fix is to add the AccessibleJSlider as a ChangeListener on the JSlider and then sending the accesssiblity value change event from there instead of sending it from setValue method like being done in JSpinner. This results in the accessibility events being sent to JAWS in the order they are being changed. JAWS is able to announce the value properly for JSlider and JSpinner. > > This can be tested by running any JColorchooser sample program (One such sample program is attached in JBS). I have run full jtreg and jck tests on mach5. The change is not breaking any test. Links in JBS. > > Regards > Pankaj > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Jul 28 04:50:16 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 27 Jul 2020 21:50:16 -0700 Subject: RFR JDK-8146451: javax/swing/JComponent/4337267/bug4337267.java failed on Windows In-Reply-To: References: Message-ID: <960a7656-d7dd-1fcf-f443-6fddab2a3c10@oracle.com> Hi, Prasanta. Since the test was updated and now uses invokeAndWait, then probably we can drop "doneTask()" and all related things used to wait while invokeLater is completed? On 19.07.2020 05:13, Prasanta Sadhukhan wrote: > Hi All, > > Please review a test-fix for an issue seen to be failing in windows in mach5 with mismatch in bufferedimage. > > It seems the test is run asynchronously in test.run() under SwingUtilities.invokeLater which is causing the test to be unstable in mach5. > > Also, the actual BufferedImage check inside test.run() is done again asynchronously under another invokeLater(). Although it's not invalid, it's causing some instability. > > Proposed fix is to run the test under invokeAndWait() synchronously. > > mach5 job run for several iterations has passed and link is present in JBS. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8146451 > > webrev: http://cr.openjdk.java.net/~psadhukhan/8146451/webrev.0/ > > Regards > Prasanta -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Jul 28 04:59:08 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 27 Jul 2020 21:59:08 -0700 Subject: RFR JDK-8169959: javax/swing/JTable/6263446/bug6263446.java: Table should be editing In-Reply-To: References: <7A4887E2-1751-4DD4-BEA7-686A0564A73B@oracle.com> Message-ID: <693c6c18-dd12-6de0-a502-8b4574332d9b@oracle.com> Looks fine. On 27.07.2020 02:07, Prasanta Sadhukhan wrote: > ping? any reviewers? > > On 18-Jul-20 6:14 PM, Prasanta Sadhukhan wrote: >> HI All, >> >> Please review a test fix for an issue where this test fails with message ""java.lang.RuntimeException: Table should be editing? in mach5 >> ?It seems it will fail with that message when the robot mouse event are executed without frame being visible on which the events are to be executed. >> >> So, the test is modified to add delay() and make frame on-top to allow frame to get visible. Also, the frame is moved to centre from default leftmost position to avoid mouse click on invalid position. >> Also, waitForIdle() is added at some place to make the test more stable. >> >> mach5 job results running for several iterations is added to JBS >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8169959 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8169959/webrev.0/ >> >> Regards >> Prasanta -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Tue Jul 28 08:16:17 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 28 Jul 2020 13:46:17 +0530 Subject: RFR JDK-8146451: javax/swing/JComponent/4337267/bug4337267.java failed on Windows In-Reply-To: <960a7656-d7dd-1fcf-f443-6fddab2a3c10@oracle.com> References: <960a7656-d7dd-1fcf-f443-6fddab2a3c10@oracle.com> Message-ID: <3d17d8c6-86f5-31eb-df6e-2dcb10b7ef28@oracle.com> OK. Removed doneTask() asynchronous method. Modified webrev: http://cr.openjdk.java.net/~psadhukhan/8146451/webrev.1/ mach5 job link in JBS Regards Prasanta On 28-Jul-20 10:20 AM, Sergey Bylokhov wrote: > Hi, Prasanta. > > Since the test was updated and now uses invokeAndWait, then probably > we can drop > "doneTask()" and all related things used to wait while invokeLater is > completed? > > On 19.07.2020 05:13, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a test-fix for an issue seen to be failing in windows >> in mach5 with mismatch in bufferedimage. >> >> It seems the test is run asynchronously in test.run() under >> SwingUtilities.invokeLater which is causing the test to be unstable >> in mach5. >> >> Also, the actual BufferedImage check inside test.run() is done again >> asynchronously under another invokeLater(). Although it's not >> invalid, it's causing some instability. >> >> Proposed fix is to run the test under invokeAndWait() synchronously. >> >> mach5 job run for several iterations has passed and link is present >> in JBS. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8146451 >> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8146451/webrev.0/ >> >> Regards >> Prasanta > > From Sergey.Bylokhov at oracle.com Tue Jul 28 22:40:58 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 28 Jul 2020 15:40:58 -0700 Subject: RFR JDK-8146451: javax/swing/JComponent/4337267/bug4337267.java failed on Windows In-Reply-To: <3d17d8c6-86f5-31eb-df6e-2dcb10b7ef28@oracle.com> References: <960a7656-d7dd-1fcf-f443-6fddab2a3c10@oracle.com> <3d17d8c6-86f5-31eb-df6e-2dcb10b7ef28@oracle.com> Message-ID: Looks fine. On 28.07.2020 01:16, Prasanta Sadhukhan wrote: > OK. Removed doneTask() asynchronous method. Modified webrev: > > http://cr.openjdk.java.net/~psadhukhan/8146451/webrev.1/ > > mach5 job link in JBS > > Regards > Prasanta > On 28-Jul-20 10:20 AM, Sergey Bylokhov wrote: >> Hi, Prasanta. >> >> Since the test was updated and now uses invokeAndWait, then probably we can drop >> "doneTask()" and all related things used to wait while invokeLater is completed? >> >> On 19.07.2020 05:13, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a test-fix for an issue seen to be failing in windows in mach5 with mismatch in bufferedimage. >>> >>> It seems the test is run asynchronously in test.run() under SwingUtilities.invokeLater which is causing the test to be unstable in mach5. >>> >>> Also, the actual BufferedImage check inside test.run() is done again asynchronously under another invokeLater(). Although it's not invalid, it's causing some instability. >>> >>> Proposed fix is to run the test under invokeAndWait() synchronously. >>> >>> mach5 job run for several iterations has passed and link is present in JBS. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146451 >>> >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8146451/webrev.0/ >>> >>> Regards >>> Prasanta >> >> -- Best regards, Sergey. From tejpal.rebari at oracle.com Wed Jul 29 07:55:56 2020 From: tejpal.rebari at oracle.com (Tejpal Rebari) Date: Wed, 29 Jul 2020 13:25:56 +0530 Subject: RFR: 8249674: Redo: Nimbus JTree renderer properties persist across L&F changes In-Reply-To: References: <3B18E219-4ED8-4F58-8D58-7F1D756FF9F5@oracle.com> Message-ID: <4A5F5B3C-E9A1-47EE-8C5B-92FC63D79313@oracle.com> Hi Prasanta, > On 27-Jul-2020, at 2:21 PM, Prasanta Sadhukhan wrote: > > Fix looks ok to me. But I think the test is more appropriate if it is placed in javax/swing/plaf/nimbus directory. Also, the test can be enhanced a bit to not fail at the first attempt as we are testing 8 different properties, so I think it will be good if you will store the results in a string for each property that fails, and finally at the end throw failure with stored string. > I was bit confused about where the test should be placed because it also checks for other LAFs. But for other LAF test was passing earlier also so keeping the test in javax/swing/plaf/nimbus. Made changes in the test to throw failure with stored string. Updated webrev : http://cr.openjdk.java.net/~trebari/swing/8249674/webrev01/ Thanks Tejpal > Regards > Prasanta > On 24-Jul-20 2:36 PM, Tejpal Rebari wrote: >> Hi All, >> Please review the following fix for jdk16. >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8249674 >> Webrev : http://cr.openjdk.java.net/~trebari/swing/8249674/webrev00/ >> >> This is a modified fix for https://bugs.openjdk.java.net/browse/JDK-8041701 >> which caused some internal test to fail. >> >> Issue : UI properties ?Tree.leafIcon?, ?Tree.closedIcon?, ?Tree.openIcon?, >> ?Tree.selectionForeground? ..etc are supposed to be instances of UIResource >> if they are defined by LAF. >> >> In Nimbus LAF all the above properties are defined , but none of them implement >> UIResource, this causes them to persists when LAF is changed. >> This leaves artefacts when switching from nimbus to other LAFs. >> >> Fix : Fix is to make use of UIResource for the above mentioned uiProperties. >> Making NimbuIcon implements the UIResource was working fine earlier >> so keeping the change same. >> >> The second part of the earlier fix "class DerivedColor extends Color implements UIResource" >> caused the internal test failure, >> >> So changed this fix to keep the DerivedColor class same and for the uiProperties >> Tree.selectionForeground? ..etc use the UIResource >> class that is inside the DerivedColor. These changes were made in skin.laf file. >> >> Testing : Tested on all three platform, and all internal tests.Link is in JBS. >> In test also added the part which was the reason of revert of earlier fix. >> The test fails with the fix of 8041701 and passes with the current fix. >> >> >> Regards >> Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Jul 29 11:53:59 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 29 Jul 2020 17:23:59 +0530 Subject: RFR: 8249674: Redo: Nimbus JTree renderer properties persist across L&F changes In-Reply-To: <4A5F5B3C-E9A1-47EE-8C5B-92FC63D79313@oracle.com> References: <3B18E219-4ED8-4F58-8D58-7F1D756FF9F5@oracle.com> <4A5F5B3C-E9A1-47EE-8C5B-92FC63D79313@oracle.com> Message-ID: <4941a9d7-80a5-0b32-3084-18e9d9a60850@oracle.com> On 29-Jul-20 1:25 PM, Tejpal Rebari wrote: > Hi Prasanta, > >> On 27-Jul-2020, at 2:21 PM, Prasanta Sadhukhan >> > > wrote: >> >> Fix looks ok to me. But I think the test is more appropriate if it is >> placed in javax/swing/plaf/nimbus directory. Also, the test can be >> enhanced a bit to not fail at the first attempt as we are testing 8 >> different properties, so I think it will be good if you will store >> the results in a string for each property that fails, and finally at >> the end throw failure with stored string. >> > I was bit confused about where the test should be placed because it > also checks for other LAFs. > But for other LAF test was passing earlier also so keeping the test in > javax/swing/plaf/nimbus. > We normally place the test in the area where the fix is being made. > Made changes in the test to throw failure with stored string. > > Updated webrev : > http://cr.openjdk.java.net/~trebari/swing/8249674/webrev01/ Looks ok but please use "," instead of "/t" and replace "/t" with ":" if "failedkeys" is null. No need of another webrev for me. Regards Prasanta > > Thanks > Tejpal > > >> Regards >> Prasanta >> On 24-Jul-20 2:36 PM, Tejpal Rebari wrote: >>> Hi All, >>> Please review the following fix for jdk16. >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8249674 >>> Webrev : http://cr.openjdk.java.net/~trebari/swing/8249674/webrev00/ >>> >>> This is a modified fix for >>> https://bugs.openjdk.java.net/browse/JDK-8041701 >>> which caused some internal test to fail. >>> >>> Issue : UI properties ?Tree.leafIcon?, ?Tree.closedIcon?, >>> ?Tree.openIcon?, >>> ?Tree.selectionForeground??..etc are supposed to be instances of >>> UIResource >>> if they are?defined by LAF. >>> >>> In Nimbus LAF all the above properties are defined , but none of >>> them implement >>> UIResource, this causes them to?persists when LAF is changed. >>> This leaves artefacts when switching from nimbus to other LAFs. >>> >>> Fix : ?Fix is to make use of UIResource for the >>> abovementioned?uiProperties. >>> Making NimbuIcon implements the UIResource was working fine earlier >>> so keeping the change same. >>> >>> The second part of the earlier fix "class DerivedColor extends Color >>> implements UIResource" >>> caused the internal test failure, >>> >>> So changed this fix to keep the DerivedColor class same and for the >>> uiProperties >>> Tree.selectionForeground??..etc ?use the UIResource >>> class that is inside the DerivedColor. These changes were made in >>> skin.laf file. >>> >>> Testing : Tested on all three platform, and all internal tests.Link >>> is in JBS. >>> In test?also added the part?which was the?reason of revert of >>> earlier fix. >>> The test fails with the fix of 8041701 and passes with the current fix. >>> >>> >>> Regards >>> Tejpal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kumar.z.abhishek at oracle.com Wed Jul 29 16:21:11 2020 From: kumar.z.abhishek at oracle.com (Kumar Abhishek) Date: Wed, 29 Jul 2020 09:21:11 -0700 (PDT) Subject: [16] RFR 8136363: Nimbus-LaF: background color cleared when setting component name of JToolBar Message-ID: <9f52660e-c17e-46bb-bafe-6a45f1172c66@default> Hello, Could you review a fix for jdk16, please? Webrev: http://cr.openjdk.java.net/~dmarkov/8136363/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8136363 Problem Description: Nimbus-LaF: background color cleared when setting component name of JToolbar Fix: The updatestyle method of the synthlook&feel is called to update style for the regions of every component. In this case ,style for the regions of JToolbar (Region.TOOL_BAR_CONTENT and Region.TOOL_BAR_DRAG_WINDOW) was getting cleared and so the background color was getting cleared. I have updated the correct style for the regions of JToolbar. Thanks, Abhishek -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Jul 30 06:18:52 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 30 Jul 2020 11:48:52 +0530 Subject: RFR JDK-6709913: BasicComboBoxUI.isPopupVisible returns NullPointerException Message-ID: <57201716-edea-d34b-c172-0e26a86bbdb2@oracle.com> Hi All, Please review a fix for an issue whereby javax.swing.plaf.basic.BasicComboBoxUI.isPopupVisible returns NullPointerException when called from a overridden method of getModel(). If a class extends JComboBox and overrides getModel() and then it calls isPopupVisible() from the overriden getModel() it gets NullPointerException the first time. Because the popup variable in javax.swing.plaf.basic.BasicComboBoxUI is not set yet. Proposed fix is to guard against it by doing a null check for the methods which can be overriden from JComboBox to access "popup" variable. Bug: https://bugs.openjdk.java.net/browse/JDK-6709913 webrev: http://cr.openjdk.java.net/~psadhukhan/6709913/webrev.0/ Regards Prasanta From prasanta.sadhukhan at oracle.com Thu Jul 30 08:24:19 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 30 Jul 2020 13:54:19 +0530 Subject: RFR JDK-8250639: Address reliance on default constructors in the javax.swing.plaf.multi module Message-ID: <418fca7d-5930-886f-a277-916768421ecd@oracle.com> Hi All, Please review a fix for issue where it was seen that several classes rely on default constructors as part of their public API. It's to be noted that "A no-arg public constructor is generated by the compiler for a class if it does not declare an explicit constructor. While convenient, this is inappropriate for many kinds of formal classes, both because the constructor will have no javadoc and because the constructor may be unintended." For the JDK, classes intended to be used outside of the JDK, public classes in exported packages, should not rely on default constructors. Proposed fix is to create no-arg default constructor for javax.swing.plaf.multi module (as one part of overalll java.desktop change) Bug: https://bugs.openjdk.java.net/browse/JDK-8250639 webrev: http://cr.openjdk.java.net/~psadhukhan/8250639/webrev.0/ CSR: https://bugs.openjdk.java.net/browse/JDK-8250812 Regards Prasanta From pankaj.b.bansal at oracle.com Thu Jul 30 10:04:27 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Thu, 30 Jul 2020 15:34:27 +0530 Subject: RFR: 8249548: backward focus traversal gets stuck in button group In-Reply-To: <5df102aa-a5ae-afd9-95b7-d8b42fa9d735@oracle.com> References: <5df102aa-a5ae-afd9-95b7-d8b42fa9d735@oracle.com> Message-ID: <11d9f535-d4db-4ac4-cc4a-0f82d2148c71@oracle.com> ping, any reviewers? Regards, Pankaj On 26/07/20 4:24 PM, Pankaj Bansal wrote: > > Hi All, > > Please review the following fix for jdk16. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8249548 > webrev: http://cr.openjdk.java.net/~pbansal/8249548/webrev00/ > > > Issue: If few ToggleButtons are added to button group, the backward > focus traversal can get stuck in few scenarios while using > LayoutFocusTraversalPolicy. For exaple, if a TextField is added to a > frame and a Button Group is added with two buttons and the second > button in set selected, we can not move the focus from Button Group to > Text Field using "Shift+Tab". More details in JBS. > > Cause: The LayoutFocusTraversalPolicy uses SortingFocusTraversalPolicy > always selects first button for focus traversal in button group for > Toggle Button. This can be changed by Component if one of the button > in the button group is set selected. This results in the selected > Button being selected again and again for selection on pressing > "Shift+Tab". This results in focus being stuck at same position. This > is a generic issue and it is observed in all L&F for JToggleButton. > > The JRadioButton does not have this issue as BasicRadioButtonUI and > AquaRadioButtonUI have code to handle this issue but the Synth L&F has > this issue for JRadioButton also. So, this issue can be observed in > both ToggleButton and RadioButton in nimbus L&F. > > Fix: The fix is to add the code to handle this in BasicButtonUI class, > so that it is available for all L&F without copying it in different > L&F classes. The focus traversal works fine after this change for all > L&F for both ToggleButton and RadioButton. Along with the current > problem, this fix is also fixes issue like we cant change the selected > button and focus in ToggleButton group like RadioButton group. > > An automated test is added. I have ran the Mach5 with all tests and > this is not causing any failures. Links in JBS. > > > Regards > Pankaj > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Jul 30 15:32:27 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 30 Jul 2020 08:32:27 -0700 Subject: RFR JDK-8250639: Address reliance on default constructors in the javax.swing.plaf.multi module In-Reply-To: <418fca7d-5930-886f-a277-916768421ecd@oracle.com> References: <418fca7d-5930-886f-a277-916768421ecd@oracle.com> Message-ID: <3157b24c-eed4-9119-a3f1-d0a24082dc81@oracle.com> On 30.07.2020 01:24, Prasanta Sadhukhan wrote: > Proposed fix is to create no-arg default constructor for javax.swing.plaf.multi module (as one part of overalll java.desktop change) This change is about "javax.swing.plaf.multi" package in the java.desktop module, but it refers to the JDK-8250639 which is about all module. But I suggest making all changes at once instead of split it to tenths different fixes, the changes are identical and easy for review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8250639 > > webrev: http://cr.openjdk.java.net/~psadhukhan/8250639/webrev.0/ > > CSR: https://bugs.openjdk.java.net/browse/JDK-8250812 > > Regards > Prasanta -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Thu Jul 30 15:34:36 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 30 Jul 2020 21:04:36 +0530 Subject: RFR JDK-8250639: Address reliance on default constructors in the javax.swing.plaf.multi module In-Reply-To: <3157b24c-eed4-9119-a3f1-d0a24082dc81@oracle.com> References: <418fca7d-5930-886f-a277-916768421ecd@oracle.com> <3157b24c-eed4-9119-a3f1-d0a24082dc81@oracle.com> Message-ID: <261e9f40-07b8-e3a1-4103-3a9e4c042dca@oracle.com> I had talked with Joe and it was decided to break up in parts as it will be easy for him. Regards PRasanta On 30-Jul-20 9:02 PM, Sergey Bylokhov wrote: > On 30.07.2020 01:24, Prasanta Sadhukhan wrote: >> Proposed fix is to create no-arg default constructor for >> javax.swing.plaf.multi module (as one part of overalll java.desktop >> change) > > This change is about "javax.swing.plaf.multi" package in the > java.desktop module, but it refers to the JDK-8250639 which is about > all module. > But I suggest making all changes at once instead of split it to tenths > different fixes, the changes are identical and easy for review. > >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8250639 >> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8250639/webrev.0/ >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8250812 >> >> Regards >> Prasanta > > From prasanta.sadhukhan at oracle.com Thu Jul 30 15:47:19 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 30 Jul 2020 21:17:19 +0530 Subject: RFR JDK-8250811: Address reliance on default constructors in the javax.swing.plaf.multi module In-Reply-To: <261e9f40-07b8-e3a1-4103-3a9e4c042dca@oracle.com> References: <418fca7d-5930-886f-a277-916768421ecd@oracle.com> <3157b24c-eed4-9119-a3f1-d0a24082dc81@oracle.com> <261e9f40-07b8-e3a1-4103-3a9e4c042dca@oracle.com> Message-ID: <48989b8c-99dc-a8f5-517a-27f77c0461e1@oracle.com> Ok. The bugid should read https://bugs.openjdk.java.net/browse/JDK-8250811 On 30-Jul-20 9:04 PM, Prasanta Sadhukhan wrote: > I had talked with Joe and it was decided to break up in parts as it > will be easy for him. > > Regards > > PRasanta > > On 30-Jul-20 9:02 PM, Sergey Bylokhov wrote: >> On 30.07.2020 01:24, Prasanta Sadhukhan wrote: >>> Proposed fix is to create no-arg default constructor for >>> javax.swing.plaf.multi module (as one part of overalll java.desktop >>> change) >> >> This change is about "javax.swing.plaf.multi" package in the >> java.desktop module, but it refers to the JDK-8250639 which is about >> all module. >> But I suggest making all changes at once instead of split it to >> tenths different fixes, the changes are identical and easy for review. >> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8250639 >>> >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8250639/webrev.0/ >>> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8250812 >>> >>> Regards >>> Prasanta >> >> From joe.darcy at oracle.com Thu Jul 30 15:56:51 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 30 Jul 2020 08:56:51 -0700 Subject: RFR JDK-8250639: Address reliance on default constructors in the javax.swing.plaf.multi module In-Reply-To: <261e9f40-07b8-e3a1-4103-3a9e4c042dca@oracle.com> References: <418fca7d-5930-886f-a277-916768421ecd@oracle.com> <3157b24c-eed4-9119-a3f1-d0a24082dc81@oracle.com> <261e9f40-07b8-e3a1-4103-3a9e4c042dca@oracle.com> Message-ID: If you want to make the changes all in one go, I can accommodate that too. Thanks, -Joe On 7/30/2020 8:34 AM, Prasanta Sadhukhan wrote: > I had talked with Joe and it was decided to break up in parts as it > will be easy for him. > > Regards > > PRasanta > > On 30-Jul-20 9:02 PM, Sergey Bylokhov wrote: >> On 30.07.2020 01:24, Prasanta Sadhukhan wrote: >>> Proposed fix is to create no-arg default constructor for >>> javax.swing.plaf.multi module (as one part of overalll java.desktop >>> change) >> >> This change is about "javax.swing.plaf.multi" package in the >> java.desktop module, but it refers to the JDK-8250639 which is about >> all module. >> But I suggest making all changes at once instead of split it to >> tenths different fixes, the changes are identical and easy for review. >> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8250639 >>> >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8250639/webrev.0/ >>> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8250812 >>> >>> Regards >>> Prasanta >> >> From prasanta.sadhukhan at oracle.com Thu Jul 30 15:57:35 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 30 Jul 2020 21:27:35 +0530 Subject: RFR JDK-8250639: Address reliance on default constructors in the javax.swing.plaf.multi module In-Reply-To: References: <418fca7d-5930-886f-a277-916768421ecd@oracle.com> <3157b24c-eed4-9119-a3f1-d0a24082dc81@oracle.com> <261e9f40-07b8-e3a1-4103-3a9e4c042dca@oracle.com> Message-ID: <18fe17ac-581b-d22b-da56-404d0aa33fbb@oracle.com> it will be easier for me to break up in parts if I have to do all of it. Regards Prasanta On 30-Jul-20 9:26 PM, Joe Darcy wrote: > If you want to make the changes all in one go, I can accommodate that > too. > > Thanks, > > -Joe > > On 7/30/2020 8:34 AM, Prasanta Sadhukhan wrote: >> I had talked with Joe and it was decided to break up in parts as it >> will be easy for him. >> >> Regards >> >> PRasanta >> >> On 30-Jul-20 9:02 PM, Sergey Bylokhov wrote: >>> On 30.07.2020 01:24, Prasanta Sadhukhan wrote: >>>> Proposed fix is to create no-arg default constructor for >>>> javax.swing.plaf.multi module (as one part of overalll java.desktop >>>> change) >>> >>> This change is about "javax.swing.plaf.multi" package in the >>> java.desktop module, but it refers to the JDK-8250639 which is about >>> all module. >>> But I suggest making all changes at once instead of split it to >>> tenths different fixes, the changes are identical and easy for review. >>> >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8250639 >>>> >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8250639/webrev.0/ >>>> >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8250812 >>>> >>>> Regards >>>> Prasanta >>> >>> From prasanta.sadhukhan at oracle.com Thu Jul 30 16:01:40 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 30 Jul 2020 21:31:40 +0530 Subject: RFR JDK-8250639: Address reliance on default constructors in the javax.swing.plaf.multi module In-Reply-To: <18fe17ac-581b-d22b-da56-404d0aa33fbb@oracle.com> References: <418fca7d-5930-886f-a277-916768421ecd@oracle.com> <3157b24c-eed4-9119-a3f1-d0a24082dc81@oracle.com> <261e9f40-07b8-e3a1-4103-3a9e4c042dca@oracle.com> <18fe17ac-581b-d22b-da56-404d0aa33fbb@oracle.com> Message-ID: <64b36536-0749-2eb0-79d6-68d75188e94d@oracle.com> Kevin mentioned even if fx they are breaking it up and tackling these issue. Regards Prasanta On 30-Jul-20 9:27 PM, Prasanta Sadhukhan wrote: > it will be easier for me to break up in parts if I have to do all of it. > > Regards > > Prasanta > > On 30-Jul-20 9:26 PM, Joe Darcy wrote: >> If you want to make the changes all in one go, I can accommodate that >> too. >> >> Thanks, >> >> -Joe >> >> On 7/30/2020 8:34 AM, Prasanta Sadhukhan wrote: >>> I had talked with Joe and it was decided to break up in parts as it >>> will be easy for him. >>> >>> Regards >>> >>> PRasanta >>> >>> On 30-Jul-20 9:02 PM, Sergey Bylokhov wrote: >>>> On 30.07.2020 01:24, Prasanta Sadhukhan wrote: >>>>> Proposed fix is to create no-arg default constructor for >>>>> javax.swing.plaf.multi module (as one part of overalll >>>>> java.desktop change) >>>> >>>> This change is about "javax.swing.plaf.multi" package in the >>>> java.desktop module, but it refers to the JDK-8250639 which is >>>> about all module. >>>> But I suggest making all changes at once instead of split it to >>>> tenths different fixes, the changes are identical and easy for review. >>>> >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8250639 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8250639/webrev.0/ >>>>> >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8250812 >>>>> >>>>> Regards >>>>> Prasanta >>>> >>>> From philip.race at oracle.com Thu Jul 30 16:35:17 2020 From: philip.race at oracle.com (Philip Race) Date: Thu, 30 Jul 2020 09:35:17 -0700 Subject: RFR JDK-8250639: Address reliance on default constructors in the javax.swing.plaf.multi module In-Reply-To: <64b36536-0749-2eb0-79d6-68d75188e94d@oracle.com> References: <418fca7d-5930-886f-a277-916768421ecd@oracle.com> <3157b24c-eed4-9119-a3f1-d0a24082dc81@oracle.com> <261e9f40-07b8-e3a1-4103-3a9e4c042dca@oracle.com> <18fe17ac-581b-d22b-da56-404d0aa33fbb@oracle.com> <64b36536-0749-2eb0-79d6-68d75188e94d@oracle.com> Message-ID: <5F22F6C5.8090304@oracle.com> Let's look at how to logically break it up. Sergey's first point was that you are here grabbing the bug that lists all issues and making it the fix for everything. I think you should withdraw this, turn it into an umbrella and file separate issues. But let's not make too many issues. It is fairly mechanical and I'd like to err on fewer rather than too many. There's overhead to many as well. -phil. On 7/30/20, 9:01 AM, Prasanta Sadhukhan wrote: > Kevin mentioned even if fx they are breaking it up and tackling these > issue. > > Regards > Prasanta > > On 30-Jul-20 9:27 PM, Prasanta Sadhukhan wrote: >> it will be easier for me to break up in parts if I have to do all of it. >> >> Regards >> >> Prasanta >> >> On 30-Jul-20 9:26 PM, Joe Darcy wrote: >>> If you want to make the changes all in one go, I can accommodate >>> that too. >>> >>> Thanks, >>> >>> -Joe >>> >>> On 7/30/2020 8:34 AM, Prasanta Sadhukhan wrote: >>>> I had talked with Joe and it was decided to break up in parts as it >>>> will be easy for him. >>>> >>>> Regards >>>> >>>> PRasanta >>>> >>>> On 30-Jul-20 9:02 PM, Sergey Bylokhov wrote: >>>>> On 30.07.2020 01:24, Prasanta Sadhukhan wrote: >>>>>> Proposed fix is to create no-arg default constructor for >>>>>> javax.swing.plaf.multi module (as one part of overalll >>>>>> java.desktop change) >>>>> >>>>> This change is about "javax.swing.plaf.multi" package in the >>>>> java.desktop module, but it refers to the JDK-8250639 which is >>>>> about all module. >>>>> But I suggest making all changes at once instead of split it to >>>>> tenths different fixes, the changes are identical and easy for >>>>> review. >>>>> >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8250639 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8250639/webrev.0/ >>>>>> >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8250812 >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>> >>>>> From prasanta.sadhukhan at oracle.com Thu Jul 30 16:38:59 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 30 Jul 2020 22:08:59 +0530 Subject: RFR JDK-8250639: Address reliance on default constructors in the javax.swing.plaf.multi module In-Reply-To: <5F22F6C5.8090304@oracle.com> References: <418fca7d-5930-886f-a277-916768421ecd@oracle.com> <3157b24c-eed4-9119-a3f1-d0a24082dc81@oracle.com> <261e9f40-07b8-e3a1-4103-3a9e4c042dca@oracle.com> <18fe17ac-581b-d22b-da56-404d0aa33fbb@oracle.com> <64b36536-0749-2eb0-79d6-68d75188e94d@oracle.com> <5F22F6C5.8090304@oracle.com> Message-ID: <90c2598e-e716-2ade-bb96-fa54ecf6e13a@oracle.com> Hi Phil, I actually erred on that. I should have used bughttps://bugs.openjdk.java.net/browse/JDK-8250811 which I created for this. I will like probably 3-5 issues out of umbrella task comprising each module.? I can see we have 100 issues for plaf.basic and 40 odd for plaf.metal so that will be covered in those module. SHould I sent this review mail again with the above bugid? Regards Prasanta On 30-Jul-20 10:05 PM, Philip Race wrote: > Let's look at how to logically break it up. > Sergey's first point was that you are here grabbing the bug that lists > all issues > and making it the fix for everything. > > I think you should withdraw this, turn it into an umbrella and file > separate issues. > But let's not make too many issues. It is fairly mechanical and I'd > like to err on > fewer rather than too many. There's overhead to many as well. > > -phil. > > On 7/30/20, 9:01 AM, Prasanta Sadhukhan wrote: >> Kevin mentioned even if fx they are breaking it up and tackling these >> issue. >> >> Regards >> Prasanta >> >> On 30-Jul-20 9:27 PM, Prasanta Sadhukhan wrote: >>> it will be easier for me to break up in parts if I have to do all of >>> it. >>> >>> Regards >>> >>> Prasanta >>> >>> On 30-Jul-20 9:26 PM, Joe Darcy wrote: >>>> If you want to make the changes all in one go, I can accommodate >>>> that too. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> On 7/30/2020 8:34 AM, Prasanta Sadhukhan wrote: >>>>> I had talked with Joe and it was decided to break up in parts as >>>>> it will be easy for him. >>>>> >>>>> Regards >>>>> >>>>> PRasanta >>>>> >>>>> On 30-Jul-20 9:02 PM, Sergey Bylokhov wrote: >>>>>> On 30.07.2020 01:24, Prasanta Sadhukhan wrote: >>>>>>> Proposed fix is to create no-arg default constructor for >>>>>>> javax.swing.plaf.multi module (as one part of overalll >>>>>>> java.desktop change) >>>>>> >>>>>> This change is about "javax.swing.plaf.multi" package in the >>>>>> java.desktop module, but it refers to the JDK-8250639 which is >>>>>> about all module. >>>>>> But I suggest making all changes at once instead of split it to >>>>>> tenths different fixes, the changes are identical and easy for >>>>>> review. >>>>>> >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8250639 >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8250639/webrev.0/ >>>>>>> >>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8250812 >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>> >>>>>> From philip.race at oracle.com Thu Jul 30 16:46:26 2020 From: philip.race at oracle.com (Philip Race) Date: Thu, 30 Jul 2020 09:46:26 -0700 Subject: RFR JDK-8250639: Address reliance on default constructors in the javax.swing.plaf.multi module In-Reply-To: <90c2598e-e716-2ade-bb96-fa54ecf6e13a@oracle.com> References: <418fca7d-5930-886f-a277-916768421ecd@oracle.com> <3157b24c-eed4-9119-a3f1-d0a24082dc81@oracle.com> <261e9f40-07b8-e3a1-4103-3a9e4c042dca@oracle.com> <18fe17ac-581b-d22b-da56-404d0aa33fbb@oracle.com> <64b36536-0749-2eb0-79d6-68d75188e94d@oracle.com> <5F22F6C5.8090304@oracle.com> <90c2598e-e716-2ade-bb96-fa54ecf6e13a@oracle.com> Message-ID: <5F22F962.1010408@oracle.com> Well let's not use 8250639 so yes a new review. But I think first step is to file all the sub-issues which I think should be by component area and we'll need to list like Joe did in the description and then we should be able to more easily track that the aggregate is the same .. Perhaps 8250811 should be for all of Swing unless there's a good reason to break up Swing. -phil. On 7/30/20, 9:38 AM, Prasanta Sadhukhan wrote: > Hi Phil, > > I actually erred on that. I should have used > bughttps://bugs.openjdk.java.net/browse/JDK-8250811 which I created > for this. > > I will like probably 3-5 issues out of umbrella task comprising each > module. I can see we have 100 issues for plaf.basic and 40 odd for > plaf.metal so that will be covered in those module. > > SHould I sent this review mail again with the above bugid? > > Regards > > Prasanta > > On 30-Jul-20 10:05 PM, Philip Race wrote: >> Let's look at how to logically break it up. >> Sergey's first point was that you are here grabbing the bug that >> lists all issues >> and making it the fix for everything. >> >> I think you should withdraw this, turn it into an umbrella and file >> separate issues. >> But let's not make too many issues. It is fairly mechanical and I'd >> like to err on >> fewer rather than too many. There's overhead to many as well. >> >> -phil. >> >> On 7/30/20, 9:01 AM, Prasanta Sadhukhan wrote: >>> Kevin mentioned even if fx they are breaking it up and tackling >>> these issue. >>> >>> Regards >>> Prasanta >>> >>> On 30-Jul-20 9:27 PM, Prasanta Sadhukhan wrote: >>>> it will be easier for me to break up in parts if I have to do all >>>> of it. >>>> >>>> Regards >>>> >>>> Prasanta >>>> >>>> On 30-Jul-20 9:26 PM, Joe Darcy wrote: >>>>> If you want to make the changes all in one go, I can accommodate >>>>> that too. >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> >>>>> On 7/30/2020 8:34 AM, Prasanta Sadhukhan wrote: >>>>>> I had talked with Joe and it was decided to break up in parts as >>>>>> it will be easy for him. >>>>>> >>>>>> Regards >>>>>> >>>>>> PRasanta >>>>>> >>>>>> On 30-Jul-20 9:02 PM, Sergey Bylokhov wrote: >>>>>>> On 30.07.2020 01:24, Prasanta Sadhukhan wrote: >>>>>>>> Proposed fix is to create no-arg default constructor for >>>>>>>> javax.swing.plaf.multi module (as one part of overalll >>>>>>>> java.desktop change) >>>>>>> >>>>>>> This change is about "javax.swing.plaf.multi" package in the >>>>>>> java.desktop module, but it refers to the JDK-8250639 which is >>>>>>> about all module. >>>>>>> But I suggest making all changes at once instead of split it to >>>>>>> tenths different fixes, the changes are identical and easy for >>>>>>> review. >>>>>>> >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8250639 >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8250639/webrev.0/ >>>>>>>> >>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8250812 >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>> >>>>>>> From Sergey.Bylokhov at oracle.com Thu Jul 30 21:41:19 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 30 Jul 2020 14:41:19 -0700 Subject: [16] RFR 8136363: Nimbus-LaF: background color cleared when setting component name of JToolBar In-Reply-To: <9f52660e-c17e-46bb-bafe-6a45f1172c66@default> References: <9f52660e-c17e-46bb-bafe-6a45f1172c66@default> Message-ID: <8e8b1943-9167-8b5a-4c6a-fdc4bface9dc@oracle.com> Hi, Kumar. I suggest improving the test a little bit. The test in the description of the bug checks all Swing components, it will be useful to do the same. Also, can you please iterate over all installed L&F and test each. On 29.07.2020 09:21, Kumar Abhishek wrote: > Hello, > > Could you review a fix for jdk16, please? > > Webrev: http://cr.openjdk.java.net/~dmarkov/8136363/webrev/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8136363 > > Problem Description: > > Nimbus-LaF: background color cleared when setting component name of JToolbar > > Fix: > > The updatestyle method of the synthlook&feel is called to update style for the regions of every component. > > In this case ,style for the regions of ?JToolbar (*Region.TOOL_BAR_CONTENT*and*Region.TOOL_BAR_DRAG_WINDOW*) was getting cleared and so the background color was getting cleared. > > I have updated the correct style for the regions of JToolbar. > > Thanks, > > Abhishek > -- Best regards, Sergey. From pankaj.b.bansal at oracle.com Fri Jul 31 06:07:24 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Fri, 31 Jul 2020 11:37:24 +0530 Subject: RFR: 8233635: [TESTBUG] ProgressMonitorEscapeKeyPress.java fails on macos In-Reply-To: References: <85e980a0-a4e5-38a5-80d1-885e26a43a25@oracle.com> Message-ID: <39e0fe5d-99f1-20cf-c414-e4bbf1b696f5@oracle.com> Hello Prasanta, I have ran this test on mach5 on MacOS 10.15. It is passing always. Link in the JBS. Please have a look. Regards, Pankaj On 21/05/20 1:01 PM, Prasanta Sadhukhan wrote: > Hi Pankaj, > > It seems this issue is observed in osx10.15 as was commented by one > tester. I do not see mach5 running this test on osx10.15. Did you > verify in osx10.15? > > Regards > Prasanta > On 21-May-20 10:08 AM, Pankaj Bansal wrote: >> Hi All, >> >> Please review the following test only fix for jdk15. >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8233635 >> >> Patch: >> >> diff -r dd652a1b2a39 test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt? Sat May 09 09:49:08 2020 +0530 >> +++ b/test/jdk/ProblemList.txt? Thu May 21 09:59:56 2020 +0530 >> @@ -854,7 +854,6 @@ >> ?javax/swing/text/StyledEditorKit/4506788/bug4506788.java 8233561 >> macosx-all >> ?javax/swing/text/JTextComponent/6361367/bug6361367.java 8233569 >> macosx-all >> ?javax/swing/text/html/HTMLEditorKit/5043626/bug5043626.java 233570 >> macosx-all >> -javax/swing/ProgressMonitor/ProgressMonitorEscapeKeyPress.java >> 8233635 macosx-all >> ?javax/swing/plaf/nimbus/TestNimbusOverride.java 8233559 macosx-all >> ?javax/swing/JTree/4927934/bug4927934.java 8233550 macosx-all >> ?javax/swing/JTree/4908142/bug4908142.java 8233550 macosx-all >> >> >> >> This test was added to the problemList as it was failing in nightly >> automated testing. >> Ran this test again several times and it is passing in mach5. Links >> are in JBS. So removing this from the problem list. >> >> Regards >> Pankaj From prasanta.sadhukhan at oracle.com Fri Jul 31 06:10:55 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 31 Jul 2020 11:40:55 +0530 Subject: RFR: 8233635: [TESTBUG] ProgressMonitorEscapeKeyPress.java fails on macos In-Reply-To: <39e0fe5d-99f1-20cf-c414-e4bbf1b696f5@oracle.com> References: <85e980a0-a4e5-38a5-80d1-885e26a43a25@oracle.com> <39e0fe5d-99f1-20cf-c414-e4bbf1b696f5@oracle.com> Message-ID: <7cd88637-7b90-de67-60e3-63a683ed4eb1@oracle.com> +1 Regards Prasanta On 31-Jul-20 11:37 AM, Pankaj Bansal wrote: > Hello Prasanta, > > I have ran this test on mach5 on MacOS 10.15. It is passing always. > Link in the JBS. Please have a look. > > Regards, > > Pankaj > > > On 21/05/20 1:01 PM, Prasanta Sadhukhan wrote: >> Hi Pankaj, >> >> It seems this issue is observed in osx10.15 as was commented by one >> tester. I do not see mach5 running this test on osx10.15. Did you >> verify in osx10.15? >> >> Regards >> Prasanta >> On 21-May-20 10:08 AM, Pankaj Bansal wrote: >>> Hi All, >>> >>> Please review the following test only fix for jdk15. >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8233635 >>> >>> Patch: >>> >>> diff -r dd652a1b2a39 test/jdk/ProblemList.txt >>> --- a/test/jdk/ProblemList.txt? Sat May 09 09:49:08 2020 +0530 >>> +++ b/test/jdk/ProblemList.txt? Thu May 21 09:59:56 2020 +0530 >>> @@ -854,7 +854,6 @@ >>> ?javax/swing/text/StyledEditorKit/4506788/bug4506788.java 8233561 >>> macosx-all >>> ?javax/swing/text/JTextComponent/6361367/bug6361367.java 8233569 >>> macosx-all >>> ?javax/swing/text/html/HTMLEditorKit/5043626/bug5043626.java 233570 >>> macosx-all >>> -javax/swing/ProgressMonitor/ProgressMonitorEscapeKeyPress.java >>> 8233635 macosx-all >>> ?javax/swing/plaf/nimbus/TestNimbusOverride.java 8233559 macosx-all >>> ?javax/swing/JTree/4927934/bug4927934.java 8233550 macosx-all >>> ?javax/swing/JTree/4908142/bug4908142.java 8233550 macosx-all >>> >>> >>> >>> This test was added to the problemList as it was failing in nightly >>> automated testing. >>> Ran this test again several times and it is passing in mach5. Links >>> are in JBS. So removing this from the problem list. >>> >>> Regards >>> Pankaj > From prasanta.sadhukhan at oracle.com Fri Jul 31 14:20:27 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 31 Jul 2020 19:50:27 +0530 Subject: RFR JDK-8250811: Address reliance on default constructors in the javax.swing.plaf.multi APIs Message-ID: <2b43da08-9f57-9fea-cea2-88eedcef0afc@oracle.com> Hi All, Please review a fix for issue where it was seen that several classes rely on default constructors as part of their public API. It's to be noted that "A no-arg public constructor is generated by the compiler for a class if it does not declare an explicit constructor. While convenient, this is inappropriate for many kinds of formal classes, both because the constructor will have no javadoc and because the constructor may be unintended." For the JDK, classes intended to be used outside of the JDK, public classes in exported packages, should not rely on default constructors. Proposed fix is to create no-arg default constructor for javax.swing.plaf.multi module (as one part of overalll java.desktop change) Bug: https://bugs.openjdk.java.net/browse/JDK-8250811 webrev: http://cr.openjdk.java.net/~psadhukhan/8250811/webrev.0/ CSR: https://bugs.openjdk.java.net/browse/JDK-8250812 Regards Prasanta From bheeren at copepod.de Wed Jul 15 15:12:03 2020 From: bheeren at copepod.de (Birke Heeren) Date: Wed, 15 Jul 2020 15:12:03 -0000 Subject: possible swing bug Message-ID: <179545049.538112.1594825912088@webmail.strato.com> Dear Madam or Sir, at https://stackoverflow.com/questions/62906739/java-swing-hebrew-font-scaling-problem-with-high-dpi-screen-scaling/62906773#62906773 I describe a possible bug with Java Swing. Do you have any idea what I could do about that problem? With kind regards, Birke Heeren Birke Heeren (Anwendungsprogrammiererin, FH Trier) Gustebiner Wende 4a, 17491 Greifswald bheeren at copepod.de mailto:bheeren at copepod.de Telefon: 03834 / 88 31 5 21 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 32371 bytes Desc: not available URL: From kumar.z.abhishek at oracle.com Tue Jul 28 10:52:54 2020 From: kumar.z.abhishek at oracle.com (Kumar Abhishek) Date: Tue, 28 Jul 2020 03:52:54 -0700 (PDT) Subject: [16] RFR 8136363: Nimbus-LaF: background color cleared when setting component name of JToolBar Message-ID: <2c8645b0-4642-4846-9740-3884a60a10f5@default> Hello, Could you review a fix for jdk16, please? Webrev: http://cr.openjdk.java.net/~dmarkov/8136363/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8136363 Problem Description: Nimbus-LaF: background color cleared when setting component name of JToolbar Fix: The updatestyle method of the synthlook&feel is called to update style for the regions of every component. In this case ,style for the regions of JToolbar (Region.TOOL_BAR_CONTENT and Region.TOOL_BAR_DRAG_WINDOW) was getting cleared and so the background color was getting cleared. I have updated the correct style for the regions of JToolbar. Thanks, Abhishek -------------- next part -------------- An HTML attachment was scrubbed... URL: