From krishna.addepalli at oracle.com Fri Mar 1 06:40:40 2019 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Fri, 1 Mar 2019 12:10:40 +0530 Subject: [13] RFR: JDK-8218674 - HTML Tooltip with "img=src" on component doesn't show In-Reply-To: References: <8698613c-6ab5-46fa-fad0-0a9935ed588e@oracle.com> <1b94404f-60bb-4381-b422-ebacaf42c71c@default> <6024edb9-c245-dfb0-4009-767ce59f3262@oracle.com> Message-ID: <97E0E21C-4FA9-4837-8404-FBDCDBF13A5E@oracle.com> Thanks for the review Sergey. Can I have one more review? Prasanta maybe? Thanks, Krishna > On 01-Mar-2019, at 3:40 AM, Sergey Bylokhov wrote: > > Looks fine. > > On 21/02/2019 08:44, Sergey Bylokhov wrote: >> On 20/02/2019 22:21, Krishna Addepalli wrote: >>> Hi Sergey, >>> >>> I have fixed the issue. Could you check now? >> Yes, it works now, I look to the fix. >>> >>> Thanks, >>> Krishna >>> -----Original Message----- >>> From: Sergey Bylokhov >>> Sent: Thursday, February 21, 2019 3:54 AM >>> To: Krishna Addepalli ; swing-dev at openjdk.java.net >>> Subject: Re: [13] RFR: JDK-8218674 - HTML Tooltip with "img=src" on component doesn't show >>> >>> Hi, Krishna. >>> >>> Some links have wrong file permissions, "403 - Forbidden": >>> http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/raw_files/new/test/jdk/javax/swing/text/html/8218674/circle.png >>> http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/raw_files/new/test/jdk/javax/swing/text/html/8218674/TooltipImageTest.java >>> >>> On 20/02/2019 03:57, Krishna Addepalli wrote: >>>> Hi All, >>>> >>>> Please review a fix for the bug JDK-8218674: https://bugs.openjdk.java.net/browse/JDK-8218674 >>>> Webrev: http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/ >>>> >>>> This is a regression introduced due to fix for JDK-8208638. The default behaviour for ImageView is to load an image asynchronously. Hence, it uses the ImageHandler::imageUpdate to get the updates to the image being loaded. That will set the width and height of the image view. ImageView::updateImageSize does not alter the width and height in this case. When a JToolTip is created and html text set as tooltip, internally, the image is requested to be loaded synchronously, and in this case, ImageView::updateImageSize is the only way to calculate the image size. Since the width and height were not specified in the tooltip, the image was not being drawn. >>>> The fix is to check if the image is requested to be loaded synchronously, and if so, then do the same calculation as for the fix for JDK-8208638, which will provide valid image width and height, additionally also taking care of the scaling issues fixed for JDK-8208638. >>>> I have tested the fix on Windows, Linux(Ubuntu) and Mac, and found that it is working. I have also run all the jtreg tests under the test/jdk/javax/swing/text/html, and found no new failures. >>>> >>>> Thanks, >>>> Krishna >>> >>> > > > -- > Best regards, Sergey. From pankaj.b.bansal at oracle.com Fri Mar 1 07:55:22 2019 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Thu, 28 Feb 2019 23:55:22 -0800 (PST) Subject: [13] RFR JDK-8214253: Tooltip is transparent rather than having a black background Message-ID: Hi All, Please review the following fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8214253 webrev http://cr.openjdk.java.net/~pbansal/8214253/webrev00/ Issue: >From gtk 3.20, gtk has changed the way themes and styles work for many widgets. Due to which, jdk is not able to render some widgets properly including JTooltip. The tooltip background looks transparent, but tooltip background is of same color as background panel. gtk 3.20 release notes: https://developer.gnome.org/gtk3/stable/ch32s10.html Fix: This patch fixes rendering issues in JTooltip by using correct way to define styles. Testing: This fix can be verified by running SwingSet2 and using the tooltip. I have verified this on Ubuntu 16.04, 18.04, 18.10 and OEL 7.5. Regards, Pankaj Bansal -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Fri Mar 1 20:25:59 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 1 Mar 2019 20:25:59 +0000 Subject: [12] JDK-8182043: Access to Windows Large Icons In-Reply-To: <5a617257-eaba-4e30-a1e5-60e1f7a01b10@default> References: <261fe40d-a8ed-4b12-9017-81fd8e9efef2@default> <4cc06fa7-7406-ece0-0527-46d566d701a1@oracle.com> <934606c2-3a79-4ae5-b041-3fa1b6a9fd99@default> <378efc00-ae1a-4e9c-861e-e563657486ce@default> <02c13573-f2ef-4275-7468-c53b54310ef0@oracle.com> <23897cf4-5068-641b-3b38-4de185796341@oracle.com> <5a617257-eaba-4e30-a1e5-60e1f7a01b10@default> Message-ID: <797327a1-86c9-6726-3f08-83ed3900af11@oracle.com> Hi Shashi, Sorry for my belated review. On 22/01/2019 18:03, Shashidhara Veerabhadraiah wrote: > > Hi All, Please review the below new fix compared to earlier webrevs. > Now the new api to get the icons of different sizes is being made part > of a new class SystemIcon. Please consider this as a different > solution than the one that was under review for a long time till now. > > http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.05/ > This version looks cleaner. The new SystemIcon class contains only one method, getSystemIcon. Does it justify creating a new class for this? Can't we add this extended version into FileSystemView class? FileSystemView has method: public Icon getSystemIcon(File f) We're extending it with public Icon getSystemIcon(File f, int size) Are there any objections to this approach? The class name, if we're going this route, could be more specific: FileSystemIcon seems a better alternative. Javadoc for SystemIcon says, ?SystemIcon is JFileChooser's gateway to the file system icons.? Yet JFileChooser uses FileSystemView.getSystemIcon(File). So Javadoc is not accurate at the very least. There should also be @since tag for the class. As this is a new API, I think it makes sense to throw IllegalArgumentException for invalid parameters: file == null or size is out of supported range. You don't usually want to print exception stack trace or messages from a public API: 74???????????? System.err.println("FileSystemView.getShellFolder: f="+f); 75???????????? e.printStackTrace(); As Phil mentioned, you should clearly state when a null value can be returned. static public Icon getSystemIcon(File f, int size) should be public static Icon getSystemIcon(File f, int size) At this time, SystemIcon is an utility class which provides only static methods. Yet it can be instantiated which does not look good. The code indents by three spaces instead of four. Win32ShellFolder2.java 1111???? public Image getIcon(int size) { The method should have @Override annotation. It can also be added to 1040???? public Image getIcon(final boolean getLargeIcon) { Win32ShellFolderManager2.java 383????????????????????????? key.startsWith("shell32LargeIcon ")?LARGE_ICON_SIZE : SMALL_ICON_SIZE); There should be spaces around ???. > Part of the fix is being borrowed from Semyon?s fix and would like to > thank Semyon for that. > You can give Semyon attribution by including "Contributed-by" tag in your commit message and referencing Semyon and yourself there. Regards, Alexey > Thanks and regards, > > Shashi > > From philip.race at oracle.com Fri Mar 1 20:40:20 2019 From: philip.race at oracle.com (Phil Race) Date: Fri, 1 Mar 2019 12:40:20 -0800 Subject: [12] JDK-8182043: Access to Windows Large Icons In-Reply-To: <797327a1-86c9-6726-3f08-83ed3900af11@oracle.com> References: <261fe40d-a8ed-4b12-9017-81fd8e9efef2@default> <4cc06fa7-7406-ece0-0527-46d566d701a1@oracle.com> <934606c2-3a79-4ae5-b041-3fa1b6a9fd99@default> <378efc00-ae1a-4e9c-861e-e563657486ce@default> <02c13573-f2ef-4275-7468-c53b54310ef0@oracle.com> <23897cf4-5068-641b-3b38-4de185796341@oracle.com> <5a617257-eaba-4e30-a1e5-60e1f7a01b10@default> <797327a1-86c9-6726-3f08-83ed3900af11@oracle.com> Message-ID: <72fea0a5-51de-5670-1a86-831bf2f8a362@oracle.com> Alexey, We already nixed this approach See https://mail.openjdk.java.net/pipermail/awt-dev/2019-January/014972.html Shashi is re-thinking it to use MultiResolutionImage. -phil. On 3/1/19 12:25 PM, Alexey Ivanov wrote: > Hi Shashi, > > Sorry for my belated review. > > On 22/01/2019 18:03, Shashidhara Veerabhadraiah wrote: >> >> Hi All, Please review the below new fix compared to earlier webrevs. >> Now the new api to get the icons of different sizes is being made >> part of a new class SystemIcon. Please consider this as a different >> solution than the one that was under review for a long time till now. >> >> http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.05/ >> > > This version looks cleaner. > > The new SystemIcon class contains only one method, getSystemIcon. Does > it justify creating a new class for this? Can't we add this extended > version into FileSystemView class? > > FileSystemView has method: > public Icon getSystemIcon(File f) > > We're extending it with > public Icon getSystemIcon(File f, int size) > > Are there any objections to this approach? > > > The class name, if we're going this route, could be more specific: > FileSystemIcon seems a better alternative. > > > Javadoc for SystemIcon says, ?SystemIcon is JFileChooser's gateway to > the file system icons.? Yet JFileChooser uses > FileSystemView.getSystemIcon(File). So Javadoc is not accurate at the > very least. > > There should also be @since tag for the class. > > As this is a new API, I think it makes sense to throw > IllegalArgumentException for invalid parameters: file == null or size > is out of supported range. > > You don't usually want to print exception stack trace or messages from > a public API: > 74???????????? System.err.println("FileSystemView.getShellFolder: f="+f); > 75???????????? e.printStackTrace(); > > As Phil mentioned, you should clearly state when a null value can be > returned. > > > static public Icon getSystemIcon(File f, int size) > should be > public static Icon getSystemIcon(File f, int size) > > At this time, SystemIcon is an utility class which provides only > static methods. Yet it can be instantiated which does not look good. > The code indents by three spaces instead of four. > > Win32ShellFolder2.java > 1111???? public Image getIcon(int size) { > The method should have @Override annotation. > > It can also be added to > 1040???? public Image getIcon(final boolean getLargeIcon) { > > > Win32ShellFolderManager2.java > 383????????????????????????? key.startsWith("shell32LargeIcon > ")?LARGE_ICON_SIZE : SMALL_ICON_SIZE); > > There should be spaces around ???. > > >> Part of the fix is being borrowed from Semyon?s fix and would like to >> thank Semyon for that. >> > > You can give Semyon attribution by including "Contributed-by" tag in > your commit message and referencing Semyon and yourself there. > > > Regards, > Alexey > >> Thanks and regards, >> >> Shashi >> >> > From Sergey.Bylokhov at oracle.com Fri Mar 1 23:18:00 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 1 Mar 2019 15:18:00 -0800 Subject: [13] RFR JDK-8214253: Tooltip is transparent rather than having a black background In-Reply-To: References: Message-ID: <81ce4e27-26ab-6103-25fc-08828533889b@oracle.com> Looks fine. On 28/02/2019 23:55, Pankaj Bansal wrote: > Hi All, > > Please review the following fix. > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8214253 > > webrev > > http://cr.openjdk.java.net/~pbansal/8214253/webrev00/ > > Issue: > > From gtk 3.20, gtk has changed the way themes and styles work for many widgets. Due to which, jdk is not able to render some widgets properly including JTooltip. The tooltip background looks transparent, but tooltip background is of same color as background panel. > > gtk 3.20 release notes: https://developer.gnome.org/gtk3/stable/ch32s10.html > > Fix: > > This patch fixes rendering issues in JTooltip by using correct way to define styles. > > Testing: > > This fix can be verified by running SwingSet2 and using the tooltip. I have verified this on Ubuntu 16.04, 18.04, 18.10 and OEL 7.5. > > > Regards, > Pankaj Bansal > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Mon Mar 4 07:59:31 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 4 Mar 2019 13:29:31 +0530 Subject: [13] RFR: JDK-8218674 - HTML Tooltip with "img=src" on component doesn't show In-Reply-To: <97E0E21C-4FA9-4837-8404-FBDCDBF13A5E@oracle.com> References: <8698613c-6ab5-46fa-fad0-0a9935ed588e@oracle.com> <1b94404f-60bb-4381-b422-ebacaf42c71c@default> <6024edb9-c245-dfb0-4009-767ce59f3262@oracle.com> <97E0E21C-4FA9-4837-8404-FBDCDBF13A5E@oracle.com> Message-ID: <20bc0723-91fc-81b8-cdb2-7170d9433b5b@oracle.com> Hi Krishna, You can reuse existing method getLoadsSynchronously() instead of checking for (state & SYNC_LOAD_FLAG) != 0) BTW, do we not have to check if (newWidth > 0) & newHeight >0 before changing the newstate @l797? The copyright year in testcase should be changed to 2019. Regards Prasanta On 01-Mar-19 12:10 PM, Krishna Addepalli wrote: > Thanks for the review Sergey. > Can I have one more review? Prasanta maybe? > > Thanks, > Krishna > >> On 01-Mar-2019, at 3:40 AM, Sergey Bylokhov wrote: >> >> Looks fine. >> >> On 21/02/2019 08:44, Sergey Bylokhov wrote: >>> On 20/02/2019 22:21, Krishna Addepalli wrote: >>>> Hi Sergey, >>>> >>>> I have fixed the issue. Could you check now? >>> Yes, it works now, I look to the fix. >>>> Thanks, >>>> Krishna >>>> -----Original Message----- >>>> From: Sergey Bylokhov >>>> Sent: Thursday, February 21, 2019 3:54 AM >>>> To: Krishna Addepalli ; swing-dev at openjdk.java.net >>>> Subject: Re: [13] RFR: JDK-8218674 - HTML Tooltip with "img=src" on component doesn't show >>>> >>>> Hi, Krishna. >>>> >>>> Some links have wrong file permissions, "403 - Forbidden": >>>> http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/raw_files/new/test/jdk/javax/swing/text/html/8218674/circle.png >>>> http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/raw_files/new/test/jdk/javax/swing/text/html/8218674/TooltipImageTest.java >>>> >>>> On 20/02/2019 03:57, Krishna Addepalli wrote: >>>>> Hi All, >>>>> >>>>> Please review a fix for the bug JDK-8218674: https://bugs.openjdk.java.net/browse/JDK-8218674 >>>>> Webrev: http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/ >>>>> >>>>> This is a regression introduced due to fix for JDK-8208638. The default behaviour for ImageView is to load an image asynchronously. Hence, it uses the ImageHandler::imageUpdate to get the updates to the image being loaded. That will set the width and height of the image view. ImageView::updateImageSize does not alter the width and height in this case. When a JToolTip is created and html text set as tooltip, internally, the image is requested to be loaded synchronously, and in this case, ImageView::updateImageSize is the only way to calculate the image size. Since the width and height were not specified in the tooltip, the image was not being drawn. >>>>> The fix is to check if the image is requested to be loaded synchronously, and if so, then do the same calculation as for the fix for JDK-8208638, which will provide valid image width and height, additionally also taking care of the scaling issues fixed for JDK-8208638. >>>>> I have tested the fix on Windows, Linux(Ubuntu) and Mac, and found that it is working. I have also run all the jtreg tests under the test/jdk/javax/swing/text/html, and found no new failures. >>>>> >>>>> Thanks, >>>>> Krishna >>>> >> >> -- >> Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Mar 4 08:12:46 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 4 Mar 2019 13:42:46 +0530 Subject: [13] RFR JDK-8214112: The whole text in target JPasswordField image are not selected. In-Reply-To: References: Message-ID: <44fb149c-b829-d3fe-f5e8-00193568f20d@oracle.com> Hi Pankaj, Dont we have to take care of else part for if (gtk3_version_3_20)? Regards Prasanta On 26-Feb-19 4:03 PM, Pankaj Bansal wrote: > > Hi All, > > Please review the following fix. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214112 > > webrev: http://cr.openjdk.java.net/~pbansal/8214112/webrev00/ > > > Issue: > > The whole text in target JPasswordField image are not selected. > > Fix: > > This bug is similar to > https://bugs.openjdk.java.net/browse/JDK-8218473. Gtk3 does not set > the selected background color for some widgets like > SPINNER_TEXT_FIELD, FORMATTED_TEXT_FIELD, PASSWORD_FIELD and > TEXT_FIELD after gtk version 3.20. The TEXT_FIELD widget case was > corrected by https://bugs.openjdk.java.net/browse/JDK-8218473. This > fix corrects the other widgets. > > This can be verified by running any sample/demo of these widgets and > selecting the text in the widget. This issue is coming in Adwaita and > Yaru themes. So, this will be easily reproducible on OEL 7.5, 7.6 and > Ubuntu 18.10. To reproduce this on Ubuntu 18.04, switch the gtk3 theme > to Adwaita. I have tested this on Ubuntu 18.10, 18.04, 16.04 and OEL 7.5. > > > Regards, > Pankaj Bansal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pankaj.b.bansal at oracle.com Mon Mar 4 08:20:39 2019 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Mon, 4 Mar 2019 00:20:39 -0800 (PST) Subject: [13] RFR JDK-8214112: The whole text in target JPasswordField image are not selected. In-Reply-To: <44fb149c-b829-d3fe-f5e8-00193568f20d@oracle.com> References: <44fb149c-b829-d3fe-f5e8-00193568f20d@oracle.com> Message-ID: <64f64e81-fe42-4a38-bb8f-eb14095124a1@default> Hi Prasanta, << Dont we have to take care of else part for if (gtk3_version_3_20)? Actually this change has been done in gtk 3.20. So all works well before that and nothing needs to be done. -Pankaj From: Prasanta Sadhukhan Sent: Monday, March 4, 2019 1:43 PM To: Pankaj Bansal; swing-dev at openjdk.java.net Subject: Re: [13] RFR JDK-8214112: The whole text in target JPasswordField image are not selected. Hi Pankaj, Dont we have to take care of else part for if (gtk3_version_3_20)? Regards Prasanta On 26-Feb-19 4:03 PM, Pankaj Bansal wrote: Hi All, Please review the following fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8214112 webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epbansal/8214112/webrev00/"http://cr.openjdk.java.net/~pbansal/8214112/webrev00/ Issue: The whole text in target JPasswordField image are not selected. Fix: This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8218473. Gtk3 does not set the selected background color for some widgets like SPINNER_TEXT_FIELD, FORMATTED_TEXT_FIELD, PASSWORD_FIELD and TEXT_FIELD after gtk version 3.20. The TEXT_FIELD widget case was corrected by https://bugs.openjdk.java.net/browse/JDK-8218473. This fix corrects the other widgets. This can be verified by running any sample/demo of these widgets and selecting the text in the widget. This issue is coming in Adwaita and Yaru themes. So, this will be easily reproducible on OEL 7.5, 7.6 and Ubuntu 18.10. To reproduce this on Ubuntu 18.04, switch the gtk3 theme to Adwaita. I have tested this on Ubuntu 18.10, 18.04, 16.04 and OEL 7.5. Regards, Pankaj Bansal -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Mar 4 08:35:33 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 4 Mar 2019 14:05:33 +0530 Subject: [13] RFR JDK-8214112: The whole text in target JPasswordField image are not selected. In-Reply-To: <64f64e81-fe42-4a38-bb8f-eb14095124a1@default> References: <44fb149c-b829-d3fe-f5e8-00193568f20d@oracle.com> <64f64e81-fe42-4a38-bb8f-eb14095124a1@default> Message-ID: <3af83317-b1e5-6bcd-b773-775d8b118e27@oracle.com> ok. +1 Regards Prasanta On 04-Mar-19 1:50 PM, Pankaj Bansal wrote: > > Hi Prasanta, > > << Dont we have to take care of else part for if (gtk3_version_3_20)? > > Actually this change has been done in gtk 3.20. So all works well > before that and nothing needs to be done. > > -Pankaj > > *From:*Prasanta Sadhukhan > *Sent:* Monday, March 4, 2019 1:43 PM > *To:* Pankaj Bansal; swing-dev at openjdk.java.net > *Subject:* Re: [13] RFR JDK-8214112: The whole text in > target JPasswordField image are not selected. > > Hi Pankaj, > > Dont we have to take care of else part for if (gtk3_version_3_20)? > > Regards > Prasanta > > On 26-Feb-19 4:03 PM, Pankaj Bansal wrote: > > Hi All, > > Please review the following fix. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214112 > > webrev: http://cr.openjdk.java.net/~pbansal/8214112/webrev00/ > > > Issue: > > The whole text in target JPasswordField image are not selected. > > Fix: > > This bug is similar to > https://bugs.openjdk.java.net/browse/JDK-8218473. Gtk3 does not > set the selected background color for some widgets like > SPINNER_TEXT_FIELD, FORMATTED_TEXT_FIELD, PASSWORD_FIELD and > TEXT_FIELD after gtk version 3.20. The TEXT_FIELD widget case was > corrected by https://bugs.openjdk.java.net/browse/JDK-8218473. > This fix corrects the other widgets. > > This can be verified by running any sample/demo of these widgets > and selecting the text in the widget. This issue is coming in > Adwaita and Yaru themes. So, this will be easily reproducible on > OEL 7.5, 7.6 and Ubuntu 18.10. To reproduce this on Ubuntu 18.04, > switch the gtk3 theme to Adwaita. I have tested this on Ubuntu > 18.10, 18.04, 16.04 and OEL 7.5. > > > Regards, > Pankaj Bansal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shashidhara.veerabhadraiah at oracle.com Mon Mar 4 09:40:54 2019 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Mon, 4 Mar 2019 01:40:54 -0800 (PST) Subject: [12] JDK-8213516: jck test api/javax_accessibility/AccessibleState/fields.html fails intermittent In-Reply-To: <0ef54b83-956f-4c28-b3cc-039e625d6f99@default> References: <5905b959-3ade-4d99-931f-f88beada7a88@default> <6ac52c32-f03f-4825-f7be-d37ae41a3ec5@oracle.com> <03bd002b-8ac8-4988-922c-fae418d39541@default> <91109c82-fe7b-4abf-8ef9-08c955cf9388@default> <94ef9f6d-a96d-0a4b-7ce6-be34964e0fee@oracle.com> <001bf74e-3415-bd91-c354-4006ee3b0e2c@oracle.com> <41a2006c-78f1-1ddd-c796-b89e1b594184@oracle.com> <5C1C40BC.90106@oracle.com> <5C1C776D.2090709@oracle.com> <717ce4ea-8d1a-4fc8-8cca-6ce676cfda40@default> <9006ef65-0837-7b77-be83-79bbd475aa95@oracle.com> <5dab2a68-2773-4a61-bf86-88bcb322f273@default> <77206885-c49a-cb5a-3cb1-73049c85c2a1@oracle.com> <0ef54b83-956f-4c28-b3cc-039e625d6f99@default> Message-ID: <98b5e57e-9b2c-4ba5-9462-36325f3c9c9e@default> Hi Sergey\Phil, Here is a new Webrev containing the new test case along with the fix. With this change, the test fails before the fix and passes after the fix. http://cr.openjdk.java.net/~sveerabhadra/8213516/webrev.04/ Please review this change. Thanks and regards, Shashi -----Original Message----- From: Shashidhara Veerabhadraiah Sent: Friday, February 15, 2019 4:27 PM To: Sergey Bylokhov ; Philip Race Cc: swing-dev at openjdk.java.net; Dmitry Bessonov Subject: Re: [12] JDK-8213516: jck test api/javax_accessibility/AccessibleState/fields.html fails intermittent Hi Phil\Sergey, I have a question regarding the test. The test is supposed to fail before the fix and pass after the fix. But this bug fails because of earlier ran resource bundle test caching the file and which is getting used by the fields test causing failure. Now even if I write the test it will still pass before and after the fix, so was not sure how do I go about that!! Please clarify. Thanks and regards, Shashi -----Original Message----- From: Shashidhara Veerabhadraiah Sent: Friday, February 15, 2019 3:14 PM To: Sergey Bylokhov ; Philip Race Cc: swing-dev at openjdk.java.net; Dmitry Bessonov Subject: Re: [12] JDK-8213516: jck test api/javax_accessibility/AccessibleState/fields.html fails intermittent Hi Sergey\Phil, Here is the new webrev: http://cr.openjdk.java.net/~sveerabhadra/8213516/webrev.03/ I assumed the table.get() function calls the equals() method of the key class. But that was not the case. My mistake. Thanks and regards, Shashi -----Original Message----- From: Sergey Bylokhov Sent: Friday, February 15, 2019 4:23 AM To: Shashidhara Veerabhadraiah ; Philip Race Cc: swing-dev at openjdk.java.net; Dmitry Bessonov ; Krishna Addepalli Subject: Re: [12] JDK-8213516: jck test api/javax_accessibility/AccessibleState/fields.html fails intermittent Hi, Shashi. > HashTable class uses these methods for key types used in the hash table, hence they need to be implemented as part of the key types. The JCK test already tests this, so Sergey do you want me to write another open test for this problem? The rules above are applicable to the keys of the hashtable, but you did not use your new class as a key. The new test is needed because the old test will be excluded. Please take a look to this comment as well: https://mail.openjdk.java.net/pipermail/swing-dev/2019-January/009277.html -- Best regards, Sergey. From pankaj.b.bansal at oracle.com Mon Mar 4 09:47:39 2019 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Mon, 4 Mar 2019 01:47:39 -0800 (PST) Subject: [13] RFR JDK-8214112: The whole text in target JPasswordField image are not selected. In-Reply-To: <3af83317-b1e5-6bcd-b773-775d8b118e27@oracle.com> References: <44fb149c-b829-d3fe-f5e8-00193568f20d@oracle.com> <64f64e81-fe42-4a38-bb8f-eb14095124a1@default> <3af83317-b1e5-6bcd-b773-775d8b118e27@oracle.com> Message-ID: <08a71737-2fc4-4836-b866-c0d1a39ec0a3@default> Thanks Prasanta and Sergey for the review. Sergey, this is the new bug I have created for reading the values from the CSS. https://bugs.openjdk.java.net/browse/JDK-8220053 -Pankaj From: Prasanta Sadhukhan Sent: Monday, March 4, 2019 2:06 PM To: Pankaj Bansal; swing-dev at openjdk.java.net Subject: Re: [13] RFR JDK-8214112: The whole text in target JPasswordField image are not selected. ok. +1 Regards Prasanta On 04-Mar-19 1:50 PM, Pankaj Bansal wrote: Hi Prasanta, << Dont we have to take care of else part for if (gtk3_version_3_20)? Actually this change has been done in gtk 3.20. So all works well before that and nothing needs to be done. -Pankaj From: Prasanta Sadhukhan Sent: Monday, March 4, 2019 1:43 PM To: Pankaj Bansal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] RFR JDK-8214112: The whole text in target JPasswordField image are not selected. Hi Pankaj, Dont we have to take care of else part for if (gtk3_version_3_20)? Regards Prasanta On 26-Feb-19 4:03 PM, Pankaj Bansal wrote: Hi All, Please review the following fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8214112 webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epbansal/8214112/webrev00/"http://cr.openjdk.java.net/~pbansal/8214112/webrev00/ Issue: The whole text in target JPasswordField image are not selected. Fix: This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8218473. Gtk3 does not set the selected background color for some widgets like SPINNER_TEXT_FIELD, FORMATTED_TEXT_FIELD, PASSWORD_FIELD and TEXT_FIELD after gtk version 3.20. The TEXT_FIELD widget case was corrected by https://bugs.openjdk.java.net/browse/JDK-8218473. This fix corrects the other widgets. This can be verified by running any sample/demo of these widgets and selecting the text in the widget. This issue is coming in Adwaita and Yaru themes. So, this will be easily reproducible on OEL 7.5, 7.6 and Ubuntu 18.10. To reproduce this on Ubuntu 18.04, switch the gtk3 theme to Adwaita. I have tested this on Ubuntu 18.10, 18.04, 16.04 and OEL 7.5. Regards, Pankaj Bansal -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Mar 4 09:49:41 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 4 Mar 2019 01:49:41 -0800 Subject: [13] RFR JDK-8214112: The whole text in target JPasswordField image are not selected. In-Reply-To: <08a71737-2fc4-4836-b866-c0d1a39ec0a3@default> References: <44fb149c-b829-d3fe-f5e8-00193568f20d@oracle.com> <64f64e81-fe42-4a38-bb8f-eb14095124a1@default> <3af83317-b1e5-6bcd-b773-775d8b118e27@oracle.com> <08a71737-2fc4-4836-b866-c0d1a39ec0a3@default> Message-ID: <56f766d2-cab5-d73e-41e7-dd6d06910cf4@oracle.com> On 04/03/2019 01:47, Pankaj Bansal wrote: > Sergey, this is the new bug I have created for reading the values from the CSS. > https://bugs.openjdk.java.net/browse/JDK-8220053 Thank you, the fix looks fine. > > -Pankaj > > *From:*Prasanta Sadhukhan > *Sent:* Monday, March 4, 2019 2:06 PM > *To:* Pankaj Bansal; swing-dev at openjdk.java.net > *Subject:* Re: [13] RFR JDK-8214112: The whole text in target JPasswordField image are not selected. > > ok. +1 > > Regards > Prasanta > > On 04-Mar-19 1:50 PM, Pankaj Bansal wrote: > > Hi Prasanta, > > << Dont we have to take care of else part for if (gtk3_version_3_20)? > > Actually this change has been done in gtk 3.20. So all works well before that and nothing needs to be done. > > -Pankaj > > *From:*Prasanta Sadhukhan > *Sent:* Monday, March 4, 2019 1:43 PM > *To:* Pankaj Bansal; swing-dev at openjdk.java.net > *Subject:* Re: [13] RFR JDK-8214112: The whole text in target JPasswordField image are not selected. > > Hi Pankaj, > > Dont we have to take care of else part for if (gtk3_version_3_20)? > > Regards > Prasanta > > On 26-Feb-19 4:03 PM, Pankaj Bansal wrote: > > Hi All, > > Please review the following fix. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214112 > > webrev: http://cr.openjdk.java.net/~pbansal/8214112/webrev00/ > > Issue: > > The whole text in target JPasswordField image are not selected. > > Fix: > > This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8218473. Gtk3 does not set the selected background color for some widgets like SPINNER_TEXT_FIELD, FORMATTED_TEXT_FIELD, PASSWORD_FIELD and TEXT_FIELD after gtk version 3.20. The TEXT_FIELD widget case was corrected by https://bugs.openjdk.java.net/browse/JDK-8218473. This fix corrects the other widgets. > > This can be verified by running any sample/demo of these widgets and selecting the text in the widget. This issue is coming in Adwaita and Yaru themes. So, this will be easily reproducible on OEL 7.5, 7.6 and Ubuntu 18.10. To reproduce this on Ubuntu 18.04, switch the gtk3 theme to Adwaita. I have tested this on Ubuntu 18.10, 18.04, 16.04 and OEL 7.5. > > > Regards, > Pankaj Bansal > -- Best regards, Sergey. From shashidhara.veerabhadraiah at oracle.com Mon Mar 4 10:05:32 2019 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Mon, 4 Mar 2019 02:05:32 -0800 (PST) Subject: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash In-Reply-To: References: <86dc6276-6a1c-4d09-8155-705fea8fd95e@default> <465ad181-9c9c-4752-a3bc-595e82f08744@default> <9149f70d-5265-efb1-e496-48e159e61e92@oracle.com> <554176f6-b538-46b5-97bb-14e488f50656@default> <5C5DEB0E.5010405@oracle.com> <23625b97-76d0-4956-8d4b-bf1add82ceb1@default> <1d4ad24a-e6bf-8e71-c88c-020e1106f089@oracle.com> <8634f5a6-a0a6-5739-9fd6-9a304a4a97f3@oracle.com> <70c695de-a54e-4aad-ae7b-0e11a6b9054e@default> Message-ID: Hi Joe, Please find the updated Webrev fixing the typo: ? http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/ ? Thanks and regards, Shashi ? From: Shashidhara Veerabhadraiah Sent: Thursday, February 21, 2019 2:08 PM To: Philip Race ; Joe Darcy Cc: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi Joe, Please find the new Webrev fixing the specification as asked in the CSR bug: https://bugs.openjdk.java.net/browse/JDK-8218737 ? Webrev: http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.06/ ? Thanks and regards, Shashi ? From: Shashidhara Veerabhadraiah Sent: Monday, February 18, 2019 10:19 AM To: Philip Race Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Thank you Phil for that help on CSR. ? From: Phil Race Sent: Friday, February 15, 2019 9:41 PM To: Shashidhara Veerabhadraiah Cc: Sergey Bylokhov ; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? That text may actually be worse. Although I maybe didn't get your distinction of null vs the empty string here ? Oh, wait. Why is this doc clarification on the PRIVATE implementation method ? It needs to go on the public getDefaultToolkit() method to have any point whatsoever especially from a CSR perspective. Try this : -???? * toolkit is created. All errors are handled via an AWTError exception. +???? * toolkit is created. +???? * If the list of assistive technology providers is the empty string, or +???? * contains only white space characters then the method returns immediately. +???? * All other errors are handled via an AWTError exception. I think the CSR needs some work too. I've made some updates there. -phil. On 2/15/19 2:10 AM, Shashidhara Veerabhadraiah wrote: Hi Phil, I have updated the CSR and updated the information for the function and here is the new Webrev: ? http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.05/ Thanks and regards, Shashi ? From: Phil Race Sent: Friday, February 15, 2019 2:58 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? +???? * activate method.? If the list of assistive technology providers is empty string, ? is "the" empty string. ? ? The CSR needs to be updated to include this spec. What is there now in the specification section needs to be fixed It should not point to the webrev or review and right now doesn't contain the change to the javadoc in the body of the CSR ? I think I even have to question most of the rest of it. Any one reading it would think that we always used to throw an exception in such case and now want to stop doing so. Isn't the bug that we did NOT throw an exception and now we do ? You only hint at that when you say at the end of "Solution", "as was the case earlier" ? If I am right the only thing you need in the CSR is to say that you are reverting the implementation to previous behaviour and updating the specification to make it clear that this behaviour is allowed by the spec since this case was unclear. ? -phil. ? On 2/12/19 1:08 AM, Shashidhara Veerabhadraiah wrote: Hi Phil, Here is the new Webrev and CSR for the same: http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.04/ ? CSR: https://bugs.openjdk.java.net/browse/JDK-8218737 ? Thanks and regards, Shashi ? From: Philip Race Sent: Saturday, February 9, 2019 2:18 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? FWIW I think this could be closed out as "not a bug". An empty value string is an error and the spec. says AWTError is how errors are reported. In fact I'll argue that 8 was wrong not to have thrown an exception in such a case. It was an accident of the implementation that it did not. But if we want to be behaviourally compatible then ... Note that since you now document this you need an approved CSR BEFORE pushing it. And if you go the CSR route you may need to be more precise about what you mean by "empty". I think it needs to say "If the list of assistive technology providers is null, or contains only white space characters then the method returns immediately. All other errors are handled by throwing {@code AWTError}" @throws AWTError if there is any error in parsing or loading the ATs. -phil. On 1/21/19, 9:12 AM, Shashidhara Veerabhadraiah wrote: Hi Sergey, Here is the new Webrev for your comments: ? http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.02/ ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Saturday, January 19, 2019 3:47 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? On 16/01/2019 23:03, HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote: Another point is that the whitespace trimming should not trigger additional input processing? for the custom class that will be used for assistive technology. For eg., if custom class "FooProvider" is implemented and if we pass "? FooProvider? " by mistake, a bug may be created to trim the whitespace in this case as well!! ? Yes, my previous email suggested to always trim the content of the "input", it will cover all cases, the "atNames" is empty, the "atNames" contains only the whitespace, or the name of the class has some spaces at the start/end. ? ? Thanks and regards, ? Shashi ? ? On 17/01/19 10:28 AM, Shashidhara Veerabhadraiah wrote: We need one way to tell the system not to load any assistive technologies and which is being provided. If we add trailing white spaces removal then we may need to add another functionality to see if that class exists or not and based on that not to load anything(without throwing the error because we are parsing the input content). I think that would take a different direction. I feel it is fair enough to provide one way to tell not to load any assistive technologies and additional parsing would only lead to other ways/expectations. ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Thursday, January 17, 2019 1:33 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? I guess you meant whitespaces, then it is unclear why we should not consider "empty" parameter as a "mistake"? ? On 15/01/2019 20:37, Shashidhara Veerabhadraiah wrote: Hi Sergey, I felt that a string with an empty space is intentional and should be considering it as a 'mistake' if done by the developers. Hence I feel it is not required(as there is a way to tell nothing to load). Please let me know if you think otherwise. ? ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, January 15, 2019 7:32 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi, Shashi. ? Should we trim all whitespaces from the "atNames"? Otherwise the "atNames", which contains only one whitespace, will trigger the same error. ? On 09/01/2019 00:20, Shashidhara Veerabhadraiah wrote: Hi Sergey, Thanks for pointing that out. Here is the new Webrev: ? http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.01/ ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Friday, January 4, 2019 3:48 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi, Shashi. I think you can update an existing test: open/test/jdk/javax/accessibility/AccessibilityProvider/basic.sh ? On 03/01/2019 01:36, Shashidhara Veerabhadraiah wrote: Hi All, Please review a fix for the below bug. ? Bug: https://bugs.openjdk.java.net/browse/JDK-8216008 ? Webrev: http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.00/ ? Since the mentioned list of assistive technologies for the system property(javax.accessibility.assistive_technologies) is loaded by jvm am unable to write a test case for this bug. The test file attached with the bug can be used for testing this fix. ? This fix removes the error(class not found error) by passing an empty list to system variable javax.accessibility.assistive_technologies and does not load any assistive technologies(as the list is empty). Currently empty list produce a crash which is not required as there was no class name mentioned in the list. Please read the bug comments for more information. ? Thanks and regards, ? Shashi ? ? ? ? ? ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishna.addepalli at oracle.com Mon Mar 4 11:23:35 2019 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Mon, 4 Mar 2019 16:53:35 +0530 Subject: [13] RFR: JDK-8218674 - HTML Tooltip with "img=src" on component doesn't show In-Reply-To: <20bc0723-91fc-81b8-cdb2-7170d9433b5b@oracle.com> References: <8698613c-6ab5-46fa-fad0-0a9935ed588e@oracle.com> <1b94404f-60bb-4381-b422-ebacaf42c71c@default> <6024edb9-c245-dfb0-4009-767ce59f3262@oracle.com> <97E0E21C-4FA9-4837-8404-FBDCDBF13A5E@oracle.com> <20bc0723-91fc-81b8-cdb2-7170d9433b5b@oracle.com> Message-ID: Hi Prasanta, Thanks for the review. Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8218674/webrev01/ The check (newWidth>0) && (newHeight > 0) is done in adjustWidthHeight function. Thanks, Krishna > On 04-Mar-2019, at 1:29 PM, Prasanta Sadhukhan wrote: > > Hi Krishna, > You can reuse existing method getLoadsSynchronously() instead of checking for (state & SYNC_LOAD_FLAG) != 0) > > BTW, do we not have to check if (newWidth > 0) & newHeight >0 before changing the newstate @l797? > > The copyright year in testcase should be changed to 2019. > > Regards > Prasanta > On 01-Mar-19 12:10 PM, Krishna Addepalli wrote: >> Thanks for the review Sergey. >> Can I have one more review? Prasanta maybe? >> >> Thanks, >> Krishna >> >>> On 01-Mar-2019, at 3:40 AM, Sergey Bylokhov wrote: >>> >>> Looks fine. >>> >>> On 21/02/2019 08:44, Sergey Bylokhov wrote: >>>> On 20/02/2019 22:21, Krishna Addepalli wrote: >>>>> Hi Sergey, >>>>> >>>>> I have fixed the issue. Could you check now? >>>> Yes, it works now, I look to the fix. >>>>> Thanks, >>>>> Krishna >>>>> -----Original Message----- >>>>> From: Sergey Bylokhov >>>>> Sent: Thursday, February 21, 2019 3:54 AM >>>>> To: Krishna Addepalli ; swing-dev at openjdk.java.net >>>>> Subject: Re: [13] RFR: JDK-8218674 - HTML Tooltip with "img=src" on component doesn't show >>>>> >>>>> Hi, Krishna. >>>>> >>>>> Some links have wrong file permissions, "403 - Forbidden": >>>>> http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/raw_files/new/test/jdk/javax/swing/text/html/8218674/circle.png >>>>> http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/raw_files/new/test/jdk/javax/swing/text/html/8218674/TooltipImageTest.java >>>>> >>>>> On 20/02/2019 03:57, Krishna Addepalli wrote: >>>>>> Hi All, >>>>>> >>>>>> Please review a fix for the bug JDK-8218674: https://bugs.openjdk.java.net/browse/JDK-8218674 >>>>>> Webrev: http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/ >>>>>> >>>>>> This is a regression introduced due to fix for JDK-8208638. The default behaviour for ImageView is to load an image asynchronously. Hence, it uses the ImageHandler::imageUpdate to get the updates to the image being loaded. That will set the width and height of the image view. ImageView::updateImageSize does not alter the width and height in this case. When a JToolTip is created and html text set as tooltip, internally, the image is requested to be loaded synchronously, and in this case, ImageView::updateImageSize is the only way to calculate the image size. Since the width and height were not specified in the tooltip, the image was not being drawn. >>>>>> The fix is to check if the image is requested to be loaded synchronously, and if so, then do the same calculation as for the fix for JDK-8208638, which will provide valid image width and height, additionally also taking care of the scaling issues fixed for JDK-8208638. >>>>>> I have tested the fix on Windows, Linux(Ubuntu) and Mac, and found that it is working. I have also run all the jtreg tests under the test/jdk/javax/swing/text/html, and found no new failures. >>>>>> >>>>>> Thanks, >>>>>> Krishna >>>>> >>> >>> -- >>> Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Mar 4 11:42:27 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 4 Mar 2019 17:12:27 +0530 Subject: [13] RFR: JDK-8218674 - HTML Tooltip with "img=src" on component doesn't show In-Reply-To: References: <8698613c-6ab5-46fa-fad0-0a9935ed588e@oracle.com> <1b94404f-60bb-4381-b422-ebacaf42c71c@default> <6024edb9-c245-dfb0-4009-767ce59f3262@oracle.com> <97E0E21C-4FA9-4837-8404-FBDCDBF13A5E@oracle.com> <20bc0723-91fc-81b8-cdb2-7170d9433b5b@oracle.com> Message-ID: On 04-Mar-19 4:53 PM, Krishna Addepalli wrote: > Hi Prasanta, > > Thanks for the review. Here is the updated webrev: > http://cr.openjdk.java.net/~kaddepalli/8218674/webrev01/ > > > The check (newWidth>0) && (newHeight > 0) is done in adjustWidthHeight > function. > if (specifiedWidth != -1 && specifiedHeight != -1) {915 newWidth = specifiedWidth;916 newHeight = specifiedHeight;917 } ... 931 d.width = newWidth;932 d.height = newHeight;If specifiedWidth/Height is 0, then I do not see any check, it is just assigning to d.width/height, no? In that case, can we need to change the newstate without checking? Regards Prasanta > Thanks, > Krishna > >> On 04-Mar-2019, at 1:29 PM, Prasanta Sadhukhan >> > > wrote: >> >> Hi Krishna, >> >> You can reuse existing method getLoadsSynchronously() instead of >> checking for (state & SYNC_LOAD_FLAG) != 0) >> >> BTW, do we not have to check if (newWidth > 0) & newHeight >0 before >> changing the newstate @l797? The copyright year in testcase should be >> changed to 2019. Regards Prasanta >> On 01-Mar-19 12:10 PM, Krishna Addepalli wrote: >>> Thanks for the review Sergey. >>> Can I have one more review? Prasanta maybe? >>> >>> Thanks, >>> Krishna >>> >>>> On 01-Mar-2019, at 3:40 AM, Sergey Bylokhov wrote: >>>> >>>> Looks fine. >>>> >>>> On 21/02/2019 08:44, Sergey Bylokhov wrote: >>>>> On 20/02/2019 22:21, Krishna Addepalli wrote: >>>>>> Hi Sergey, >>>>>> >>>>>> I have fixed the issue. Could you check now? >>>>> Yes, it works now, I look to the fix. >>>>>> Thanks, >>>>>> Krishna >>>>>> -----Original Message----- >>>>>> From: Sergey Bylokhov >>>>>> Sent: Thursday, February 21, 2019 3:54 AM >>>>>> To: Krishna Addepalli;swing-dev at openjdk.java.net >>>>>> Subject: Re: [13] RFR: JDK-8218674 - HTML Tooltip with "img=src" on component doesn't show >>>>>> >>>>>> Hi, Krishna. >>>>>> >>>>>> Some links have wrong file permissions, "403 - Forbidden": >>>>>> http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/raw_files/new/test/jdk/javax/swing/text/html/8218674/circle.png >>>>>> http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/raw_files/new/test/jdk/javax/swing/text/html/8218674/TooltipImageTest.java >>>>>> >>>>>> On 20/02/2019 03:57, Krishna Addepalli wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> Please review a fix for the bug JDK-8218674:https://bugs.openjdk.java.net/browse/JDK-8218674 >>>>>>> Webrev:http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/ >>>>>>> >>>>>>> This is a regression introduced due to fix for JDK-8208638. The default behaviour for ImageView is to load an image asynchronously. Hence, it uses the ImageHandler::imageUpdate to get the updates to the image being loaded. That will set the width and height of the image view. ImageView::updateImageSize does not alter the width and height in this case. When a JToolTip is created and html text set as tooltip, internally, the image is requested to be loaded synchronously, and in this case, ImageView::updateImageSize is the only way to calculate the image size. Since the width and height were not specified in the tooltip, the image was not being drawn. >>>>>>> The fix is to check if the image is requested to be loaded synchronously, and if so, then do the same calculation as for the fix for JDK-8208638, which will provide valid image width and height, additionally also taking care of the scaling issues fixed for JDK-8208638. >>>>>>> I have tested the fix on Windows, Linux(Ubuntu) and Mac, and found that it is working. I have also run all the jtreg tests under the test/jdk/javax/swing/text/html, and found no new failures. >>>>>>> >>>>>>> Thanks, >>>>>>> Krishna >>>> -- >>>> Best regards, Sergey. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishna.addepalli at oracle.com Mon Mar 4 12:19:53 2019 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Mon, 4 Mar 2019 17:49:53 +0530 Subject: [13] RFR: JDK-8218674 - HTML Tooltip with "img=src" on component doesn't show In-Reply-To: References: <8698613c-6ab5-46fa-fad0-0a9935ed588e@oracle.com> <1b94404f-60bb-4381-b422-ebacaf42c71c@default> <6024edb9-c245-dfb0-4009-767ce59f3262@oracle.com> <97E0E21C-4FA9-4837-8404-FBDCDBF13A5E@oracle.com> <20bc0723-91fc-81b8-cdb2-7170d9433b5b@oracle.com> Message-ID: <517F3E4A-7F96-4357-86A2-6702A872F9EC@oracle.com> Hi Prasanta, Yes, you are right. But, does it make a difference if we still update the values even if they are same? Thanks, Krishna > On 04-Mar-2019, at 5:12 PM, Prasanta Sadhukhan wrote: > > > > On 04-Mar-19 4:53 PM, Krishna Addepalli wrote: >> Hi Prasanta, >> >> Thanks for the review. Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8218674/webrev01/ >> >> The check (newWidth>0) && (newHeight > 0) is done in adjustWidthHeight function. >> > if (specifiedWidth != -1 && specifiedHeight != -1) { > 915 newWidth = specifiedWidth; > 916 newHeight = specifiedHeight; > 917 } > ... > 931 d.width = newWidth; > 932 d.height = newHeight; > > If specifiedWidth/Height is 0, then I do not see any check, it is just assigning to d.width/height, no? In that case, can we need to change the newstate without checking? > > Regards > Prasanta >> Thanks, >> Krishna >> >>> On 04-Mar-2019, at 1:29 PM, Prasanta Sadhukhan > wrote: >>> >>> Hi Krishna, >>> You can reuse existing method getLoadsSynchronously() instead of checking for (state & SYNC_LOAD_FLAG) != 0) >>> >>> BTW, do we not have to check if (newWidth > 0) & newHeight >0 before changing the newstate @l797? >>> >>> The copyright year in testcase should be changed to 2019. >>> >>> Regards >>> Prasanta >>> On 01-Mar-19 12:10 PM, Krishna Addepalli wrote: >>>> Thanks for the review Sergey. >>>> Can I have one more review? Prasanta maybe? >>>> >>>> Thanks, >>>> Krishna >>>> >>>>> On 01-Mar-2019, at 3:40 AM, Sergey Bylokhov wrote: >>>>> >>>>> Looks fine. >>>>> >>>>> On 21/02/2019 08:44, Sergey Bylokhov wrote: >>>>>> On 20/02/2019 22:21, Krishna Addepalli wrote: >>>>>>> Hi Sergey, >>>>>>> >>>>>>> I have fixed the issue. Could you check now? >>>>>> Yes, it works now, I look to the fix. >>>>>>> Thanks, >>>>>>> Krishna >>>>>>> -----Original Message----- >>>>>>> From: Sergey Bylokhov >>>>>>> Sent: Thursday, February 21, 2019 3:54 AM >>>>>>> To: Krishna Addepalli ; swing-dev at openjdk.java.net >>>>>>> Subject: Re: [13] RFR: JDK-8218674 - HTML Tooltip with "img=src" on component doesn't show >>>>>>> >>>>>>> Hi, Krishna. >>>>>>> >>>>>>> Some links have wrong file permissions, "403 - Forbidden": >>>>>>> http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/raw_files/new/test/jdk/javax/swing/text/html/8218674/circle.png >>>>>>> http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/raw_files/new/test/jdk/javax/swing/text/html/8218674/TooltipImageTest.java >>>>>>> >>>>>>> On 20/02/2019 03:57, Krishna Addepalli wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Please review a fix for the bug JDK-8218674: https://bugs.openjdk.java.net/browse/JDK-8218674 >>>>>>>> Webrev: http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/ >>>>>>>> >>>>>>>> This is a regression introduced due to fix for JDK-8208638. The default behaviour for ImageView is to load an image asynchronously. Hence, it uses the ImageHandler::imageUpdate to get the updates to the image being loaded. That will set the width and height of the image view. ImageView::updateImageSize does not alter the width and height in this case. When a JToolTip is created and html text set as tooltip, internally, the image is requested to be loaded synchronously, and in this case, ImageView::updateImageSize is the only way to calculate the image size. Since the width and height were not specified in the tooltip, the image was not being drawn. >>>>>>>> The fix is to check if the image is requested to be loaded synchronously, and if so, then do the same calculation as for the fix for JDK-8208638, which will provide valid image width and height, additionally also taking care of the scaling issues fixed for JDK-8208638. >>>>>>>> I have tested the fix on Windows, Linux(Ubuntu) and Mac, and found that it is working. I have also run all the jtreg tests under the test/jdk/javax/swing/text/html, and found no new failures. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Krishna >>>>> -- >>>>> Best regards, Sergey. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Mar 5 00:47:10 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 4 Mar 2019 16:47:10 -0800 Subject: [13] Review Request: 8177960 Deprecate the Swing Motif Look and Feel and document it as unsupported on macOS Message-ID: <83592c70-6b39-d718-436d-65238c8a466c@oracle.com> Hello. Please review the fix for JDK 13. Bug: https://bugs.openjdk.java.net/browse/JDK-8177960 CSR: https://bugs.openjdk.java.net/browse/JDK-8218637 Fix: http://cr.openjdk.java.net/~serb/8177960/webrev.01 This is a request to deprecate the Swing Motif Look and Feel, and document it as unsupported on macOS platform in JDK 13. The Motif L&F has long been part of the Swing implementation shipped with the JDK, although unlike L&Fs such as Metal and Nimbus it is not exposed in Java APIs and not part of the Java SE specification. This look and feel was implemented as the System look and feel for the Solaris platform at time when the CDE/Motif environment was used the principal supported desktop environment. But it was placed in shared code and provided and supported on all platforms including Windows and later macOS. Since it is superseded as a system L&F by the GTK L&F and has limited use and additionally as a L&F is very dated visually, we would like to discourage further use. Note in some future release we may remove it completely, or we may remove it from the shared code to stop distributing it on Windows and macOS. These are mentioned here to give the most possible notice of such possible additional changes. -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Tue Mar 5 03:24:08 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 5 Mar 2019 08:54:08 +0530 Subject: [13] RFR: JDK-8218674 - HTML Tooltip with "img=src" on component doesn't show In-Reply-To: <517F3E4A-7F96-4357-86A2-6702A872F9EC@oracle.com> References: <8698613c-6ab5-46fa-fad0-0a9935ed588e@oracle.com> <1b94404f-60bb-4381-b422-ebacaf42c71c@default> <6024edb9-c245-dfb0-4009-767ce59f3262@oracle.com> <97E0E21C-4FA9-4837-8404-FBDCDBF13A5E@oracle.com> <20bc0723-91fc-81b8-cdb2-7170d9433b5b@oracle.com> <517F3E4A-7F96-4357-86A2-6702A872F9EC@oracle.com> Message-ID: <24dd1ffe-ffab-abaa-43d8-ad7c92fe09e9@oracle.com> Hi Krishna, On 04-Mar-19 5:49 PM, Krishna Addepalli wrote: > Hi Prasanta, > > Yes, you are right. But, does it make a difference if we still update > the values even if they are same? I am not pointing to d.width = newWidth; My concern is newState |= (WIDTH_FLAG | HEIGHT_FLAG);where you update the state even if width/height can be 0. I am not sure about possible repurcussions? I do not see any test with image of width/height=0 so thought that you probably do not check that path. Regards Prasanta > > Thanks, > Krishna > >> On 04-Mar-2019, at 5:12 PM, Prasanta Sadhukhan >> > > wrote: >> >> >> >> On 04-Mar-19 4:53 PM, Krishna Addepalli wrote: >>> Hi Prasanta, >>> >>> Thanks for the review. Here is the updated webrev: >>> http://cr.openjdk.java.net/~kaddepalli/8218674/webrev01/ >>> >>> >>> The check (newWidth>0) && (newHeight > 0) is done in >>> adjustWidthHeight function. >>> >> if (specifiedWidth != -1 && specifiedHeight != -1) {915 newWidth = >> specifiedWidth;916 newHeight = specifiedHeight;917 } ... 931 d.width >> = newWidth;932 d.height = newHeight;If specifiedWidth/Height is 0, >> then I do not see any check, it is just assigning to d.width/height, >> no? In that case, can we need to change the newstate without >> checking? Regards Prasanta >>> Thanks, >>> Krishna >>> >>>> On 04-Mar-2019, at 1:29 PM, Prasanta Sadhukhan >>>> >>> > wrote: >>>> >>>> Hi Krishna, >>>> >>>> You can reuse existing method getLoadsSynchronously() instead of >>>> checking for (state & SYNC_LOAD_FLAG) != 0) >>>> >>>> BTW, do we not have to check if (newWidth > 0) & newHeight >0 >>>> before changing the newstate @l797? The copyright year in testcase >>>> should be changed to 2019. Regards Prasanta >>>> On 01-Mar-19 12:10 PM, Krishna Addepalli wrote: >>>>> Thanks for the review Sergey. >>>>> Can I have one more review? Prasanta maybe? >>>>> >>>>> Thanks, >>>>> Krishna >>>>> >>>>>> On 01-Mar-2019, at 3:40 AM, Sergey Bylokhov wrote: >>>>>> >>>>>> Looks fine. >>>>>> >>>>>> On 21/02/2019 08:44, Sergey Bylokhov wrote: >>>>>>> On 20/02/2019 22:21, Krishna Addepalli wrote: >>>>>>>> Hi Sergey, >>>>>>>> >>>>>>>> I have fixed the issue. Could you check now? >>>>>>> Yes, it works now, I look to the fix. >>>>>>>> Thanks, >>>>>>>> Krishna >>>>>>>> -----Original Message----- >>>>>>>> From: Sergey Bylokhov >>>>>>>> Sent: Thursday, February 21, 2019 3:54 AM >>>>>>>> To: Krishna Addepalli;swing-dev at openjdk.java.net >>>>>>>> Subject: Re: [13] RFR: JDK-8218674 - HTML Tooltip with "img=src" on component doesn't show >>>>>>>> >>>>>>>> Hi, Krishna. >>>>>>>> >>>>>>>> Some links have wrong file permissions, "403 - Forbidden": >>>>>>>> http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/raw_files/new/test/jdk/javax/swing/text/html/8218674/circle.png >>>>>>>> http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/raw_files/new/test/jdk/javax/swing/text/html/8218674/TooltipImageTest.java >>>>>>>> >>>>>>>> On 20/02/2019 03:57, Krishna Addepalli wrote: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> Please review a fix for the bug JDK-8218674:https://bugs.openjdk.java.net/browse/JDK-8218674 >>>>>>>>> Webrev:http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/ >>>>>>>>> >>>>>>>>> This is a regression introduced due to fix for JDK-8208638. The default behaviour for ImageView is to load an image asynchronously. Hence, it uses the ImageHandler::imageUpdate to get the updates to the image being loaded. That will set the width and height of the image view. ImageView::updateImageSize does not alter the width and height in this case. When a JToolTip is created and html text set as tooltip, internally, the image is requested to be loaded synchronously, and in this case, ImageView::updateImageSize is the only way to calculate the image size. Since the width and height were not specified in the tooltip, the image was not being drawn. >>>>>>>>> The fix is to check if the image is requested to be loaded synchronously, and if so, then do the same calculation as for the fix for JDK-8208638, which will provide valid image width and height, additionally also taking care of the scaling issues fixed for JDK-8208638. >>>>>>>>> I have tested the fix on Windows, Linux(Ubuntu) and Mac, and found that it is working. I have also run all the jtreg tests under the test/jdk/javax/swing/text/html, and found no new failures. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Krishna >>>>>> -- >>>>>> Best regards, Sergey. >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Mar 5 03:33:35 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 5 Mar 2019 09:03:35 +0530 Subject: [13] RFR JDK-8214253: Tooltip is transparent rather than having a black background In-Reply-To: References: Message-ID: <1d56e1d5-3460-faaf-7ce0-d811c19ba1be@oracle.com> Hi Pankaj, One question, dont we need to do 1782 fp_gtk_style_context_add_class(context, "background");after 2366 context = get_style(widget_type, "tooltip"); Also,please put noreg-demo in JBS since you are not providing any testcase. Applicable for all gtk3 bugs, I presume. Regards Prasanta On 01-Mar-19 1:25 PM, Pankaj Bansal wrote: > > Hi All, > > Please review the following fix. > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8214253 > > webrev > > http://cr.openjdk.java.net/~pbansal/8214253/webrev00/ > > > Issue: > > From gtk 3.20, gtk has changed the way themes and styles work for many > widgets. Due to which, jdk is not able to render some widgets properly > including JTooltip. The tooltip background looks transparent, but > tooltip background is of same color as background panel. > > gtk 3.20 release notes: > https://developer.gnome.org/gtk3/stable/ch32s10.html > > Fix: > > This patch fixes rendering issues in JTooltip by using correct way to > define styles. > > Testing: > > This fix can be verified by running SwingSet2 and using the tooltip. I > have verified this on Ubuntu 16.04, 18.04, 18.10 and OEL 7.5. > > > Regards, > Pankaj Bansal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Mar 5 04:25:43 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 5 Mar 2019 09:55:43 +0530 Subject: [13] Review Request: 8177960 Deprecate the Swing Motif Look and Feel and document it as unsupported on macOS In-Reply-To: <83592c70-6b39-d718-436d-65238c8a466c@oracle.com> References: <83592c70-6b39-d718-436d-65238c8a466c@oracle.com> Message-ID: Looks good to me. Regards Prasanta On 05-Mar-19 6:17 AM, Sergey Bylokhov wrote: > Hello. > Please review the fix for JDK 13. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8177960 > CSR: https://bugs.openjdk.java.net/browse/JDK-8218637 > Fix: http://cr.openjdk.java.net/~serb/8177960/webrev.01 > > This is a request to deprecate the Swing Motif Look and Feel, > and document it as unsupported on macOS platform in JDK 13. > > The Motif L&F has long been part of the Swing implementation > shipped with the JDK, although unlike L&Fs such as Metal and > Nimbus it is not exposed in Java APIs and not part of the Java SE > specification. > > This look and feel was implemented as the System look and feel for the > Solaris platform at time when the CDE/Motif environment was used the > principal supported desktop environment. But it was placed in shared code > and provided and supported on all platforms including Windows and > later macOS. > > Since it is superseded as a system L&F by the GTK L&F and has limited > use and > additionally as a L&F is very dated visually, we would like to > discourage further use. > > Note in some future release we may remove it completely, or we may remove > it from the shared code to stop distributing it on Windows and macOS. > These are mentioned here to give the most possible notice of such > possible additional changes. > From pankaj.b.bansal at oracle.com Tue Mar 5 07:02:35 2019 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Mon, 4 Mar 2019 23:02:35 -0800 (PST) Subject: [13] RFR JDK-8214253: Tooltip is transparent rather than having a black background In-Reply-To: <1d56e1d5-3460-faaf-7ce0-d811c19ba1be@oracle.com> References: <1d56e1d5-3460-faaf-7ce0-d811c19ba1be@oracle.com> Message-ID: Hi Prasanta, < [13] RFR JDK-8214253: Tooltip is transparent rather than having a black background Hi Pankaj, One question, dont we need to do 1782 fp_gtk_style_context_add_class(context, "background"); after 2366 context = get_style(widget_type, "tooltip"); Also,please put noreg-demo in JBS since you are not providing any testcase. Applicable for all gtk3 bugs, I presume. Regards Prasanta On 01-Mar-19 1:25 PM, Pankaj Bansal wrote: Hi All, Please review the following fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8214253 webrev HYPERLINK "http://cr.openjdk.java.net/%7Epbansal/8214253/webrev00/"http://cr.openjdk.java.net/~pbansal/8214253/webrev00/ Issue: >From gtk 3.20, gtk has changed the way themes and styles work for many widgets. Due to which, jdk is not able to render some widgets properly including JTooltip. The tooltip background looks transparent, but tooltip background is of same color as background panel. gtk 3.20 release notes: https://developer.gnome.org/gtk3/stable/ch32s10.html Fix: This patch fixes rendering issues in JTooltip by using correct way to define styles. Testing: This fix can be verified by running SwingSet2 and using the tooltip. I have verified this on Ubuntu 16.04, 18.04, 18.10 and OEL 7.5. Regards, Pankaj Bansal -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Mar 5 07:18:27 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 5 Mar 2019 12:48:27 +0530 Subject: [13] RFR JDK-8214253: Tooltip is transparent rather than having a black background In-Reply-To: References: <1d56e1d5-3460-faaf-7ce0-d811c19ba1be@oracle.com> Message-ID: ok. +1 Regards Prasanta On 05-Mar-19 12:32 PM, Pankaj Bansal wrote: > > Hi Prasanta, > > < <<1782 fp_gtk_style_context_add_class(context, "background"); > > < > <<2366 context = get_style(widget_type, "tooltip"); > > The tooltip is drawn in two parts, tooltip background and tooltip > text. Tooltip background is drawn using gtk3_paint_flat_box. The text > color is found by gtk3_get_color_for_state. In the css file [1], for > drawing the toolkit background, background class is added to the > tooltip style, so this is done in gtk3_paint_flat_box. But to find the > text color, this is not needed. So this is not done in > gtk3_get_color_for_state. > > << Also,please put noreg-demo in JBS since you are not providing any > testcase. Applicable for all gtk3 bugs, I presume. > > Done. I will add this to other bugs too. > > [1] > https://github.com/GNOME/gtk/blob/gtk-3-22/gtk/theme/Adwaita/gtk-contained.css > > -Pankaj > > *From:*Prasanta Sadhukhan > *Sent:* Tuesday, March 5, 2019 9:04 AM > *To:* Pankaj Bansal; swing-dev at openjdk.java.net > *Subject:* Re: [13] RFR JDK-8214253: Tooltip is > transparent rather than having a black background > > Hi Pankaj, > > One question, dont we need to do > 1782 fp_gtk_style_context_add_class(context, "background"); > > after > > 2366 context = get_style(widget_type, "tooltip"); > > > Also,please put noreg-demo in JBS since you are not providing any > testcase. Applicable for all gtk3 bugs, I presume. > > Regards > Prasanta > > On 01-Mar-19 1:25 PM, Pankaj Bansal wrote: > > Hi All, > > Please review the following fix. > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8214253 > > webrev > > http://cr.openjdk.java.net/~pbansal/8214253/webrev00/ > > > Issue: > > From gtk 3.20, gtk has changed the way themes and styles work for > many widgets. Due to which, jdk is not able to render some widgets > properly including JTooltip. The tooltip background looks > transparent, but tooltip background is of same color as background > panel. > > gtk 3.20 release notes: > https://developer.gnome.org/gtk3/stable/ch32s10.html > > Fix: > > This patch fixes rendering issues in JTooltip by using correct way > to define styles. > > Testing: > > This fix can be verified by running SwingSet2 and using the > tooltip. I have verified this on Ubuntu 16.04, 18.04, 18.10 and > OEL 7.5. > > > Regards, > Pankaj Bansal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vikrant.v.agarwal at oracle.com Tue Mar 5 10:18:02 2019 From: vikrant.v.agarwal at oracle.com (Vikrant Agarwal) Date: Tue, 5 Mar 2019 02:18:02 -0800 (PST) Subject: [13] RFR JDK-8219552:bump jtreg requiredVersion to b14 in test/jdk/sanity/client/ In-Reply-To: <405D75EB-0AFE-48B2-BB51-46D4FF08F726@oracle.com> References: <405D75EB-0AFE-48B2-BB51-46D4FF08F726@oracle.com> Message-ID: <8640c2b4-d863-4d6f-ae8b-3703613ca1b4@default> Hi Igor, Here is the updated webrev: http://cr.openjdk.java.net/~vagarwal/8219552/webrev.3/ Summary of changes made: Removed requiredVersion from TEST.properties and README Removed 'test/jdk/sanity/client/TEST.ROOT.template' as it is not being used. It is not necessary for all keywords to be under TEST.ROOT file. Right now test ButtonDemoScreenshotTest.java runs without any errors and if we remove 'screenshots' keyword from TEST.properties file it throws "Error. Parse Exception: Invalid key: screenshots" exception. So keeping the TEST.properties file. Added "sanity/client" under exclusiveAccess.dirs to test/jdk/TEST.ROOT and removed exclusiveAccess.dirs from 'test/jdk/sanity/client/TEST.properties' Removed "intermittent" keyword from ButtonDemoScreenshotTest, because intermittent issue is resolved by JDK-8157338 Added "screenshots" keyword to EditorPaneDemoTest as this test also has screenshot tests. Added GPL legal notice in TEST.properties file Best Regards, Vikrant From: Igor Ignatyev Sent: Friday, February 22, 2019 11:35 PM To: Vikrant Agarwal Cc: swing-dev at openjdk.java.net; Aleksandre Iline ; Muneer Kolarkunnu Subject: Re: [13] RFR JDK-8219552:bump jtreg requiredVersion to b14 in test/jdk/sanity/client/ Hi Vikrant. could you please explain how 'test/jdk/sanity/client/TEST.ROOT.template' is used? if it's not used at all, I'd prefer to delete this file for good. I also have kinda same question to 'TEST.properties' file. AFAIR jtreg doesn't extending 'keys' in 'TEST.properties' files, which means all keywords must be listed in 'TEST.ROOT' file, and using of any other unregistered keywords leads to 'Error. Parse Exception: Invalid key: ...'. 'screenshots' isn't registered in test/jdk/TEST.ROOT, having it in 'test/jdk/sanity/client/TEST.properties' has no effect, so 'test/jdk/sanity/client/SwingSet/src/ButtonDemoScreenshotTest.java' (the only test w/ screenshots) can't be executed and will always fail w/ error status. so I'm wondering if you doing something w/ test/jdk/sanity/client/ before running these tests. Thanks, -- Igor On Feb 21, 2019, at 9:56 PM, Vikrant Agarwal wrote: Hi All, Please review this small fix for HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8219552"JDK-8219552: Bug: https://bugs.openjdk.java.net/browse/JDK-8219552 Webrev: http://cr.openjdk.java.net/~vagarwal/8219552/webrev.0/ Summary: Removed jtreg requiredVersion field from files in test/jdk/sanity/client/ as it is redundant because jtreg requiredVersion is specified in test/jdk/TEST.ROOT which is being updated by HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8219417"JDK-8219417 Best Regards, Vikrant -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishna.addepalli at oracle.com Tue Mar 5 11:22:29 2019 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Tue, 5 Mar 2019 16:52:29 +0530 Subject: [13] Review request for JDK-8216971: [macosx swing] For JCheckBoxMenuItem actionPerformed() is called twice, when apple.laf.useScreenMenuBar=true and modifier is InputEvent.META_DOWN_MASK In-Reply-To: <52287ED0-64B7-4586-9D2F-F3912EE4057A@oracle.com> References: <52287ED0-64B7-4586-9D2F-F3912EE4057A@oracle.com> Message-ID: Hi Manajit, Per our discussion, The cause of the problem is : 1), Key Event being sent from the OS to the application - which the Java layer processes it correctly 2) The Mac OS calling the handleAction function directly on the NSMenutItem - although as per your description, there is no code which maps the hot key to this widget in the native layer. Ideally, since the OS is recognising the key combination, that key event should not be delivered again to the application. Or, it should be that the key event is not recognised and hence delivered to the application. Can you check why in this case, we are getting the key event as well as the handleAction from the OS? Thanks, Krishna > On 23-Feb-2019, at 9:14 PM, Manajit Halder wrote: > > Hi All, > > Please review the fix for JDK13. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8216971 > > Webrev: > http://cr.openjdk.java.net/~mhalder/8216971/webrev.00/ > > Fix: > actionPerformed() was called twice due to wrong handling of key down event in method handleAction, which is corrected with this fix. > This change was added during fix of issue JDK-8152492. Apart from the changes required to fix the problem, code related to finding out > eventKey is removed as eventKey is no more used now. > > Note: > This issue is regression of bug 8152492, which was introduced in JDK release 9b120. > > Regards, > Manajit -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Tue Mar 5 17:04:28 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 5 Mar 2019 09:04:28 -0800 Subject: [13] RFR JDK-8219552:bump jtreg requiredVersion to b14 in test/jdk/sanity/client/ In-Reply-To: <8640c2b4-d863-4d6f-ae8b-3703613ca1b4@default> References: <405D75EB-0AFE-48B2-BB51-46D4FF08F726@oracle.com> <8640c2b4-d863-4d6f-ae8b-3703613ca1b4@default> Message-ID: Hi Vikrant, although I still don't understand why we are moving exclusiveAccess.dirs to test/jdk/TEST.ROOT, I'm fine w/ the patch. Cheers, -- Igor > On Mar 5, 2019, at 2:18 AM, Vikrant Agarwal wrote: > > Hi Igor, > > Here is the updated webrev: http://cr.openjdk.java.net/~vagarwal/8219552/webrev.3/ > > Summary of changes made: > Removed requiredVersion from TEST.properties and README > Removed 'test/jdk/sanity/client/TEST.ROOT.template' as it is not being used. > It is not necessary for all keywords to be under TEST.ROOT file. Right now test ButtonDemoScreenshotTest.java runs without any errors and if we remove 'screenshots' keyword from TEST.properties file it throws ?Error. Parse Exception: Invalid key: screenshots?exception. So keeping the TEST.properties file. > Added "sanity/client" under exclusiveAccess.dirs to test/jdk/TEST.ROOT and removed exclusiveAccess.dirs from ?test/jdk/sanity/client/TEST.properties? > Removed "intermittent" keyword from ButtonDemoScreenshotTest, because intermittent issue is resolved by JDK-8157338 > Added "screenshots" keyword to EditorPaneDemoTest as this test also has screenshot tests. > Added GPL legal notice in TEST.properties file > > Best Regards, > Vikrant > > From: Igor Ignatyev > Sent: Friday, February 22, 2019 11:35 PM > To: Vikrant Agarwal > Cc: swing-dev at openjdk.java.net; Aleksandre Iline ; Muneer Kolarkunnu > Subject: Re: [13] RFR JDK-8219552:bump jtreg requiredVersion to b14 in test/jdk/sanity/client/ > > Hi Vikrant. > > could you please explain how 'test/jdk/sanity/client/TEST.ROOT.template' is used? if it's not used at all, I'd prefer to delete this file for good. > > I also have kinda same question to 'TEST.properties' file. AFAIR jtreg doesn't extending 'keys' in 'TEST.properties' files, which means all keywords must be listed in 'TEST.ROOT' file, and using of any other unregistered keywords leads to 'Error. Parse Exception: Invalid key: ...'. 'screenshots' isn't registered in test/jdk/TEST.ROOT, having it in 'test/jdk/sanity/client/TEST.properties' has no effect, so 'test/jdk/sanity/client/SwingSet/src/ButtonDemoScreenshotTest.java' (the only test w/ screenshots) can't be executed and will always fail w/ error status. so I'm wondering if you doing something w/ test/jdk/sanity/client/ before running these tests. > > Thanks, > -- Igor > > > On Feb 21, 2019, at 9:56 PM, Vikrant Agarwal > wrote: > > Hi All, > Please review this small fix for JDK-8219552 : > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219552 > Webrev: http://cr.openjdk.java.net/~vagarwal/8219552/webrev.0/ > Summary: Removed jtreg requiredVersion field from files in test/jdk/sanity/client/ as it is redundant because jtreg requiredVersion is specified in test/jdk/TEST.ROOT which is being updated by JDK-8219417 > Best Regards, > Vikrant -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Mar 5 23:41:21 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 5 Mar 2019 15:41:21 -0800 Subject: [13] Review Request: 7106851 Test should not use System.exit Message-ID: Hello. Please review the small fix for JDK 13. Bug: https://bugs.openjdk.java.net/browse/JDK-7106851 Fix: http://cr.openjdk.java.net/~serb/7106851/webrev.00 The System.exit() was replaced by the exception. The test is moved to the open repo. I have checked that the new version still fail before JDK-6192422. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Mar 5 23:48:56 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 5 Mar 2019 15:48:56 -0800 Subject: [12] JDK-8213516: jck test api/javax_accessibility/AccessibleState/fields.html fails intermittent In-Reply-To: <98b5e57e-9b2c-4ba5-9462-36325f3c9c9e@default> References: <5905b959-3ade-4d99-931f-f88beada7a88@default> <94ef9f6d-a96d-0a4b-7ce6-be34964e0fee@oracle.com> <001bf74e-3415-bd91-c354-4006ee3b0e2c@oracle.com> <41a2006c-78f1-1ddd-c796-b89e1b594184@oracle.com> <5C1C40BC.90106@oracle.com> <5C1C776D.2090709@oracle.com> <717ce4ea-8d1a-4fc8-8cca-6ce676cfda40@default> <9006ef65-0837-7b77-be83-79bbd475aa95@oracle.com> <5dab2a68-2773-4a61-bf86-88bcb322f273@default> <77206885-c49a-cb5a-3cb1-73049c85c2a1@oracle.com> <0ef54b83-956f-4c28-b3cc-039e625d6f99@default> <98b5e57e-9b2c-4ba5-9462-36325f3c9c9e@default> Message-ID: Hi, Shashi. On 04/03/2019 01:40, Shashidhara Veerabhadraiah wrote: > Hi Sergey\Phil, Here is a new Webrev containing the new test case along with the fix. With this change, the test fails before the fix and passes after the fix. > > http://cr.openjdk.java.net/~sveerabhadra/8213516/webrev.04/ > > Please review this change. The hashcode() does not guarantee that it will produce different numbers for different inputs. You need a compound key like in previous fix(but not in the public APi), or you need a compound map like this: Hashtable>> table = new Hashtable<>(); -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Mar 6 01:05:15 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 5 Mar 2019 17:05:15 -0800 Subject: [13] RFR JDK-8215396: JTabbedPane preferred size calculation is wrong for SCROLL_TAB_LAYOUT In-Reply-To: <62f1a4ad-ec66-361b-b16e-30577173d78f@oracle.com> References: <62f1a4ad-ec66-361b-b16e-30577173d78f@oracle.com> Message-ID: Hi, Prasanta. The change looks fine, but I have two comments. - Please close the JDK-7151452 as a duplicate of JDK-8215396, since you sent JDK-8215396 to the review. - Looks like the test depends on the L&F, on my system it is passed on macOS on jdk11, probably it should checks all installe L&Fs? On 27/02/2019 02:25, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue where it is seen that for SCROLL_TAB_LAYOUT the border of the content of JTabbedPane is not fully shown, whereas for WRAP_TAB_LAYOUT policy, the content is fully shown. > > It seems BasicTabbedPaneUI.TabbedPaneScrollLayout inner class (used for SCROLL_TAB_LAYOUT) has preferredTabAreaHeight() and preferredTabAreaWidth() which are overridden from > its superclass, BasicTabbedPaneUI.TabbedPaneLayout (used for WRAP_TAB_LAYOUT). In superclass, these methods take into account the tab area insets, but the overridden methods in TabbedPaneScrollLayout? don't. > > Proposed fix is to use existing methods [calculateTabAreaHeight,calculateTabAreaWidth] for calculating the size as was done for WRAP_TAB_LAYOUT. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215396 > webrev: http://cr.openjdk.java.net/~psadhukhan/8215396/webrev.0/ > > Regards > Prasanta -- Best regards, Sergey. From krishna.addepalli at oracle.com Wed Mar 6 03:40:09 2019 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Wed, 6 Mar 2019 09:10:09 +0530 Subject: [13] Review Request: 7106851 Test should not use System.exit In-Reply-To: References: Message-ID: +1 ?Krishna > On 06-Mar-2019, at 5:11 AM, Sergey Bylokhov wrote: > > Hello. > Please review the small fix for JDK 13. > > Bug: https://bugs.openjdk.java.net/browse/JDK-7106851 > Fix: http://cr.openjdk.java.net/~serb/7106851/webrev.00 > > The System.exit() was replaced by the exception. > The test is moved to the open repo. > I have checked that the new version still fail before JDK-6192422. > > -- > Best regards, Sergey. From vikrant.v.agarwal at oracle.com Wed Mar 6 04:15:25 2019 From: vikrant.v.agarwal at oracle.com (Vikrant Agarwal) Date: Tue, 5 Mar 2019 20:15:25 -0800 (PST) Subject: [13] RFR JDK-8219552:bump jtreg requiredVersion to b14 in test/jdk/sanity/client/ In-Reply-To: References: <405D75EB-0AFE-48B2-BB51-46D4FF08F726@oracle.com> <8640c2b4-d863-4d6f-ae8b-3703613ca1b4@default> Message-ID: Hi Igor, ? We are moving exclusiveAccess.dirs to test/jdk/TEST.ROOT to minimize our dependency on ?test/jdk/sanity/client/TEST.properties?, so that we can remove it in the future if screenshots keyword is no longer required. ? Best Regards, Vikrant ? From: Igor Ignatyev Sent: Tuesday, March 05, 2019 10:34 PM To: Vikrant Agarwal Cc: swing-dev at openjdk.java.net; Aleksandre Iline ; Muneer Kolarkunnu ; Sergey Bylokhov Subject: Re: [13] RFR JDK-8219552:bump jtreg requiredVersion to b14 in test/jdk/sanity/client/ ? Hi Vikrant, ? although I still don't understand why we are moving exclusiveAccess.dirs to test/jdk/TEST.ROOT, I'm fine w/ the patch. ? Cheers, -- Igor On Mar 5, 2019, at 2:18 AM, Vikrant Agarwal wrote: ? Hi Igor, ? Here is the updated webrev:?http://cr.openjdk.java.net/~vagarwal/8219552/webrev.3/ ? Summary of changes made: Removed requiredVersion from TEST.properties and README Removed 'test/jdk/sanity/client/TEST.ROOT.template' as it is not being used. It is not necessary for all keywords to be? under TEST.ROOT file. Right now test ButtonDemoScreenshotTest.java runs without any errors and if we remove 'screenshots' keyword from TEST.properties file it throws??Error. Parse Exception: Invalid key: screenshots?exception. So keeping the TEST.properties file. Added "sanity/client" under exclusiveAccess.dirs to test/jdk/TEST.ROOT and removed exclusiveAccess.dirs ?from ?test/jdk/sanity/client/TEST.properties? Removed "intermittent" keyword from ButtonDemoScreenshotTest, because intermittent issue is resolved by JDK-8157338 Added "screenshots" keyword to EditorPaneDemoTest as this test also has screenshot tests. Added GPL legal notice in TEST.properties file ? Best Regards, Vikrant ? From:?Igor Ignatyev? Sent:?Friday, February 22, 2019 11:35 PM To:?Vikrant Agarwal Cc:?HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Aleksandre Iline ; Muneer Kolarkunnu Subject:?Re: [13] RFR JDK-8219552:bump jtreg requiredVersion to b14 in test/jdk/sanity/client/ ? Hi?Vikrant. ? could you please explain how 'test/jdk/sanity/client/TEST.ROOT.template' is used? if it's not used at all, I'd prefer to delete this file for good.? ? I also have kinda same question to 'TEST.properties' file. AFAIR jtreg doesn't extending 'keys' in 'TEST.properties' files, which means all keywords must be listed in 'TEST.ROOT' file, and using of any other unregistered keywords leads to 'Error. Parse Exception: Invalid key: ...'. ?'screenshots' isn't registered in test/jdk/TEST.ROOT, having it in 'test/jdk/sanity/client/TEST.properties' has no effect, so 'test/jdk/sanity/client/SwingSet/src/ButtonDemoScreenshotTest.java' (the only test w/ screenshots) can't be executed and will always fail w/ error status. so I'm wondering if you doing something w/ test/jdk/sanity/client/ before running these tests. ? Thanks, -- Igor On Feb 21, 2019, at 9:56 PM, Vikrant Agarwal wrote: ? Hi All, Please review this small fix for?HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8219552"JDK-8219552: ? Bug:?https://bugs.openjdk.java.net/browse/JDK-8219552 Webrev:?http://cr.openjdk.java.net/~vagarwal/8219552/webrev.0/ Summary: Removed jtreg requiredVersion field from files in test/jdk/sanity/client/ as it is redundant because jtreg requiredVersion is specified in test/jdk/TEST.ROOT which is being updated by?HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8219417"JDK-8219417 Best Regards, Vikrant ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Mar 6 05:03:05 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 6 Mar 2019 10:33:05 +0530 Subject: [13] RFR JDK-8215396: JTabbedPane preferred size calculation is wrong for SCROLL_TAB_LAYOUT In-Reply-To: References: <62f1a4ad-ec66-361b-b16e-30577173d78f@oracle.com> Message-ID: Hi Sergey, Modified test in webrev to iterate through installed L&Fs http://cr.openjdk.java.net/~psadhukhan/8215396/webrev.1/ Regards Prasanta On 06-Mar-19 6:35 AM, Sergey Bylokhov wrote: > Hi, Prasanta. > The change looks fine, but I have two comments. > ?- Please close the JDK-7151452 as a duplicate of JDK-8215396, since > you sent JDK-8215396 to the review. > ?- Looks like the test depends on the L&F, on my system it is passed > on macOS on jdk11, probably it should checks all installe L&Fs? > > On 27/02/2019 02:25, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for an issue where it is seen that for >> SCROLL_TAB_LAYOUT the border of the content of JTabbedPane is not >> fully shown, whereas for WRAP_TAB_LAYOUT policy, the content is fully >> shown. >> >> It seems BasicTabbedPaneUI.TabbedPaneScrollLayout inner class (used >> for SCROLL_TAB_LAYOUT) has preferredTabAreaHeight() and >> preferredTabAreaWidth() which are overridden from >> its superclass, BasicTabbedPaneUI.TabbedPaneLayout (used for >> WRAP_TAB_LAYOUT). In superclass, these methods take into account the >> tab area insets, but the overridden methods in >> TabbedPaneScrollLayout? don't. >> >> Proposed fix is to use existing methods >> [calculateTabAreaHeight,calculateTabAreaWidth] for calculating the >> size as was done for WRAP_TAB_LAYOUT. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215396 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8215396/webrev.0/ >> >> Regards >> Prasanta > > From prasanta.sadhukhan at oracle.com Wed Mar 6 05:17:30 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 6 Mar 2019 10:47:30 +0530 Subject: [13] Review Request: 7106851 Test should not use System.exit In-Reply-To: References: Message-ID: <5b82a57b-100e-db62-b62f-4c6f49546c0d@oracle.com> +1 Regards Prasanta On 06-Mar-19 5:11 AM, Sergey Bylokhov wrote: > Hello. > Please review the small fix for JDK 13. > > Bug: https://bugs.openjdk.java.net/browse/JDK-7106851 > Fix: http://cr.openjdk.java.net/~serb/7106851/webrev.00 > > The System.exit() was replaced by the exception. > The test is moved to the open repo. > I have checked that the new version still fail before JDK-6192422. > From shashidhara.veerabhadraiah at oracle.com Wed Mar 6 06:15:36 2019 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Tue, 5 Mar 2019 22:15:36 -0800 (PST) Subject: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash In-Reply-To: References: <86dc6276-6a1c-4d09-8155-705fea8fd95e@default> <465ad181-9c9c-4752-a3bc-595e82f08744@default> <9149f70d-5265-efb1-e496-48e159e61e92@oracle.com> <554176f6-b538-46b5-97bb-14e488f50656@default> <5C5DEB0E.5010405@oracle.com> <23625b97-76d0-4956-8d4b-bf1add82ceb1@default> <1d4ad24a-e6bf-8e71-c88c-020e1106f089@oracle.com> <8634f5a6-a0a6-5739-9fd6-9a304a4a97f3@oracle.com> <70c695de-a54e-4aad-ae7b-0e11a6b9054e@default> Message-ID: Hi Phil\Sergey, Please review the CSR along with the bug fix. ? Webrev: http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/ ? CSR: https://bugs.openjdk.java.net/browse/JDK-8218737 ? Bug: https://bugs.openjdk.java.net/browse/JDK-8216008 ? Thanks and regards, Shashi ? From: Shashidhara Veerabhadraiah Sent: Monday, March 4, 2019 3:36 PM To: Philip Race ; Joe Darcy Cc: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi Joe, Please find the updated Webrev fixing the typo: ? http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/ ? Thanks and regards, Shashi ? From: Shashidhara Veerabhadraiah Sent: Thursday, February 21, 2019 2:08 PM To: Philip Race ; Joe Darcy Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi Joe, Please find the new Webrev fixing the specification as asked in the CSR bug: https://bugs.openjdk.java.net/browse/JDK-8218737 ? Webrev: http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.06/ ? Thanks and regards, Shashi ? From: Shashidhara Veerabhadraiah Sent: Monday, February 18, 2019 10:19 AM To: Philip Race Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Thank you Phil for that help on CSR. ? From: Phil Race Sent: Friday, February 15, 2019 9:41 PM To: Shashidhara Veerabhadraiah Cc: Sergey Bylokhov ; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? That text may actually be worse. Although I maybe didn't get your distinction of null vs the empty string here ? Oh, wait. Why is this doc clarification on the PRIVATE implementation method ? It needs to go on the public getDefaultToolkit() method to have any point whatsoever especially from a CSR perspective. Try this : -???? * toolkit is created. All errors are handled via an AWTError exception. +???? * toolkit is created. +???? * If the list of assistive technology providers is the empty string, or +???? * contains only white space characters then the method returns immediately. +???? * All other errors are handled via an AWTError exception. I think the CSR needs some work too. I've made some updates there. -phil. On 2/15/19 2:10 AM, Shashidhara Veerabhadraiah wrote: Hi Phil, I have updated the CSR and updated the information for the function and here is the new Webrev: ? http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.05/ Thanks and regards, Shashi ? From: Phil Race Sent: Friday, February 15, 2019 2:58 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? +???? * activate method.? If the list of assistive technology providers is empty string, ? is "the" empty string. ? ? The CSR needs to be updated to include this spec. What is there now in the specification section needs to be fixed It should not point to the webrev or review and right now doesn't contain the change to the javadoc in the body of the CSR ? I think I even have to question most of the rest of it. Any one reading it would think that we always used to throw an exception in such case and now want to stop doing so. Isn't the bug that we did NOT throw an exception and now we do ? You only hint at that when you say at the end of "Solution", "as was the case earlier" ? If I am right the only thing you need in the CSR is to say that you are reverting the implementation to previous behaviour and updating the specification to make it clear that this behaviour is allowed by the spec since this case was unclear. ? -phil. ? On 2/12/19 1:08 AM, Shashidhara Veerabhadraiah wrote: Hi Phil, Here is the new Webrev and CSR for the same: http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.04/ ? CSR: https://bugs.openjdk.java.net/browse/JDK-8218737 ? Thanks and regards, Shashi ? From: Philip Race Sent: Saturday, February 9, 2019 2:18 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? FWIW I think this could be closed out as "not a bug". An empty value string is an error and the spec. says AWTError is how errors are reported. In fact I'll argue that 8 was wrong not to have thrown an exception in such a case. It was an accident of the implementation that it did not. But if we want to be behaviourally compatible then ... Note that since you now document this you need an approved CSR BEFORE pushing it. And if you go the CSR route you may need to be more precise about what you mean by "empty". I think it needs to say "If the list of assistive technology providers is null, or contains only white space characters then the method returns immediately. All other errors are handled by throwing {@code AWTError}" @throws AWTError if there is any error in parsing or loading the ATs. -phil. On 1/21/19, 9:12 AM, Shashidhara Veerabhadraiah wrote: Hi Sergey, Here is the new Webrev for your comments: ? http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.02/ ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Saturday, January 19, 2019 3:47 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? On 16/01/2019 23:03, HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote: Another point is that the whitespace trimming should not trigger additional input processing? for the custom class that will be used for assistive technology. For eg., if custom class "FooProvider" is implemented and if we pass "? FooProvider? " by mistake, a bug may be created to trim the whitespace in this case as well!! ? Yes, my previous email suggested to always trim the content of the "input", it will cover all cases, the "atNames" is empty, the "atNames" contains only the whitespace, or the name of the class has some spaces at the start/end. ? ? Thanks and regards, ? Shashi ? ? On 17/01/19 10:28 AM, Shashidhara Veerabhadraiah wrote: We need one way to tell the system not to load any assistive technologies and which is being provided. If we add trailing white spaces removal then we may need to add another functionality to see if that class exists or not and based on that not to load anything(without throwing the error because we are parsing the input content). I think that would take a different direction. I feel it is fair enough to provide one way to tell not to load any assistive technologies and additional parsing would only lead to other ways/expectations. ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Thursday, January 17, 2019 1:33 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? I guess you meant whitespaces, then it is unclear why we should not consider "empty" parameter as a "mistake"? ? On 15/01/2019 20:37, Shashidhara Veerabhadraiah wrote: Hi Sergey, I felt that a string with an empty space is intentional and should be considering it as a 'mistake' if done by the developers. Hence I feel it is not required(as there is a way to tell nothing to load). Please let me know if you think otherwise. ? ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, January 15, 2019 7:32 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi, Shashi. ? Should we trim all whitespaces from the "atNames"? Otherwise the "atNames", which contains only one whitespace, will trigger the same error. ? On 09/01/2019 00:20, Shashidhara Veerabhadraiah wrote: Hi Sergey, Thanks for pointing that out. Here is the new Webrev: ? http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.01/ ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Friday, January 4, 2019 3:48 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi, Shashi. I think you can update an existing test: open/test/jdk/javax/accessibility/AccessibilityProvider/basic.sh ? On 03/01/2019 01:36, Shashidhara Veerabhadraiah wrote: Hi All, Please review a fix for the below bug. ? Bug: https://bugs.openjdk.java.net/browse/JDK-8216008 ? Webrev: http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.00/ ? Since the mentioned list of assistive technologies for the system property(javax.accessibility.assistive_technologies) is loaded by jvm am unable to write a test case for this bug. The test file attached with the bug can be used for testing this fix. ? This fix removes the error(class not found error) by passing an empty list to system variable javax.accessibility.assistive_technologies and does not load any assistive technologies(as the list is empty). Currently empty list produce a crash which is not required as there was no class name mentioned in the list. Please read the bug comments for more information. ? Thanks and regards, ? Shashi ? ? ? ? ? ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishna.addepalli at oracle.com Wed Mar 6 09:55:48 2019 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Wed, 6 Mar 2019 15:25:48 +0530 Subject: [13] RFR: JDK-8218674 - HTML Tooltip with "img=src" on component doesn't show In-Reply-To: <24dd1ffe-ffab-abaa-43d8-ad7c92fe09e9@oracle.com> References: <8698613c-6ab5-46fa-fad0-0a9935ed588e@oracle.com> <1b94404f-60bb-4381-b422-ebacaf42c71c@default> <6024edb9-c245-dfb0-4009-767ce59f3262@oracle.com> <97E0E21C-4FA9-4837-8404-FBDCDBF13A5E@oracle.com> <20bc0723-91fc-81b8-cdb2-7170d9433b5b@oracle.com> <517F3E4A-7F96-4357-86A2-6702A872F9EC@oracle.com> <24dd1ffe-ffab-abaa-43d8-ad7c92fe09e9@oracle.com> Message-ID: Hi Prasanta, Handling 0-sized images was not done in the earlier fix as well. And this fix simply makes sure that the earlier fix works exactly the same when the image is loaded synchronously/asynchronously. At least from the looks of it, I do not see any harm in updating the image size, since it will only load the appropriate image, and update the ImageView object state. Thanks, Krishna > On 05-Mar-2019, at 8:54 AM, Prasanta Sadhukhan wrote: > > Hi Krishna, > > On 04-Mar-19 5:49 PM, Krishna Addepalli wrote: >> Hi Prasanta, >> >> Yes, you are right. But, does it make a difference if we still update the values even if they are same? > I am not pointing to > d.width = newWidth; > > My concern is newState |= (WIDTH_FLAG | HEIGHT_FLAG); > where you update the state even if width/height can be 0. I am not sure about possible repurcussions? I do not see any test with image of width/height=0 so thought that you probably do not check that path. > > Regards > Prasanta >> >> Thanks, >> Krishna >> >>> On 04-Mar-2019, at 5:12 PM, Prasanta Sadhukhan > wrote: >>> >>> >>> >>> On 04-Mar-19 4:53 PM, Krishna Addepalli wrote: >>>> Hi Prasanta, >>>> >>>> Thanks for the review. Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8218674/webrev01/ >>>> >>>> The check (newWidth>0) && (newHeight > 0) is done in adjustWidthHeight function. >>>> >>> if (specifiedWidth != -1 && specifiedHeight != -1) { >>> 915 newWidth = specifiedWidth; >>> 916 newHeight = specifiedHeight; >>> 917 } >>> ... >>> 931 d.width = newWidth; >>> 932 d.height = newHeight; >>> >>> If specifiedWidth/Height is 0, then I do not see any check, it is just assigning to d.width/height, no? In that case, can we need to change the newstate without checking? >>> >>> Regards >>> Prasanta >>>> Thanks, >>>> Krishna >>>> >>>>> On 04-Mar-2019, at 1:29 PM, Prasanta Sadhukhan > wrote: >>>>> >>>>> Hi Krishna, >>>>> You can reuse existing method getLoadsSynchronously() instead of checking for (state & SYNC_LOAD_FLAG) != 0) >>>>> >>>>> BTW, do we not have to check if (newWidth > 0) & newHeight >0 before changing the newstate @l797? >>>>> >>>>> The copyright year in testcase should be changed to 2019. >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 01-Mar-19 12:10 PM, Krishna Addepalli wrote: >>>>>> Thanks for the review Sergey. >>>>>> Can I have one more review? Prasanta maybe? >>>>>> >>>>>> Thanks, >>>>>> Krishna >>>>>> >>>>>>> On 01-Mar-2019, at 3:40 AM, Sergey Bylokhov wrote: >>>>>>> >>>>>>> Looks fine. >>>>>>> >>>>>>> On 21/02/2019 08:44, Sergey Bylokhov wrote: >>>>>>>> On 20/02/2019 22:21, Krishna Addepalli wrote: >>>>>>>>> Hi Sergey, >>>>>>>>> >>>>>>>>> I have fixed the issue. Could you check now? >>>>>>>> Yes, it works now, I look to the fix. >>>>>>>>> Thanks, >>>>>>>>> Krishna >>>>>>>>> -----Original Message----- >>>>>>>>> From: Sergey Bylokhov >>>>>>>>> Sent: Thursday, February 21, 2019 3:54 AM >>>>>>>>> To: Krishna Addepalli ; swing-dev at openjdk.java.net >>>>>>>>> Subject: Re: [13] RFR: JDK-8218674 - HTML Tooltip with "img=src" on component doesn't show >>>>>>>>> >>>>>>>>> Hi, Krishna. >>>>>>>>> >>>>>>>>> Some links have wrong file permissions, "403 - Forbidden": >>>>>>>>> http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/raw_files/new/test/jdk/javax/swing/text/html/8218674/circle.png >>>>>>>>> http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/raw_files/new/test/jdk/javax/swing/text/html/8218674/TooltipImageTest.java >>>>>>>>> >>>>>>>>> On 20/02/2019 03:57, Krishna Addepalli wrote: >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> Please review a fix for the bug JDK-8218674: https://bugs.openjdk.java.net/browse/JDK-8218674 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/ >>>>>>>>>> >>>>>>>>>> This is a regression introduced due to fix for JDK-8208638. The default behaviour for ImageView is to load an image asynchronously. Hence, it uses the ImageHandler::imageUpdate to get the updates to the image being loaded. That will set the width and height of the image view. ImageView::updateImageSize does not alter the width and height in this case. When a JToolTip is created and html text set as tooltip, internally, the image is requested to be loaded synchronously, and in this case, ImageView::updateImageSize is the only way to calculate the image size. Since the width and height were not specified in the tooltip, the image was not being drawn. >>>>>>>>>> The fix is to check if the image is requested to be loaded synchronously, and if so, then do the same calculation as for the fix for JDK-8208638, which will provide valid image width and height, additionally also taking care of the scaling issues fixed for JDK-8208638. >>>>>>>>>> I have tested the fix on Windows, Linux(Ubuntu) and Mac, and found that it is working. I have also run all the jtreg tests under the test/jdk/javax/swing/text/html, and found no new failures. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Krishna >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Mar 6 10:31:07 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 6 Mar 2019 16:01:07 +0530 Subject: [13] RFR: JDK-8218674 - HTML Tooltip with "img=src" on component doesn't show In-Reply-To: References: <8698613c-6ab5-46fa-fad0-0a9935ed588e@oracle.com> <1b94404f-60bb-4381-b422-ebacaf42c71c@default> <6024edb9-c245-dfb0-4009-767ce59f3262@oracle.com> <97E0E21C-4FA9-4837-8404-FBDCDBF13A5E@oracle.com> <20bc0723-91fc-81b8-cdb2-7170d9433b5b@oracle.com> <517F3E4A-7F96-4357-86A2-6702A872F9EC@oracle.com> <24dd1ffe-ffab-abaa-43d8-ad7c92fe09e9@oracle.com> Message-ID: <0af3dc2c-643f-f80a-1565-3b6e0ac7efc9@oracle.com> Hi Krishna, But in other area of the code, like 778 if (newWidth > 0) { 779 newState |= WIDTH_FLAG; 780 } we do check for width/height > 0 before updating the state, so I would expect to maintain consistency, we should do the same for 797 newState |= (WIDTH_FLAG | HEIGHT_FLAG);Regards Prasanta On 06-Mar-19 3:25 PM, Krishna Addepalli wrote: > Hi Prasanta, > > Handling 0-sized images was not done in the earlier fix as well. And > this fix simply makes sure that the earlier fix works exactly the same > when the image is loaded synchronously/asynchronously. > At least from the looks of it, I do not see any harm in updating the > image size, since it will only load the appropriate image, and update > the ImageView object state. > > Thanks, > Krishna > >> On 05-Mar-2019, at 8:54 AM, Prasanta Sadhukhan >> > > wrote: >> >> Hi Krishna, >> >> >> On 04-Mar-19 5:49 PM, Krishna Addepalli wrote: >>> Hi Prasanta, >>> >>> Yes, you are right. But, does it make a difference if we still >>> update the values even if they are same? >> I am not pointing to >> d.width = newWidth; My concern is newState |= (WIDTH_FLAG | >> HEIGHT_FLAG);where you update the state even if width/height can be >> 0. I am not sure about possible repurcussions? I do not see any test >> with image of width/height=0 so thought that you probably do not >> check that path. Regards Prasanta >>> >>> Thanks, >>> Krishna >>> >>>> On 04-Mar-2019, at 5:12 PM, Prasanta Sadhukhan >>>> >>> > wrote: >>>> >>>> >>>> >>>> On 04-Mar-19 4:53 PM, Krishna Addepalli wrote: >>>>> Hi Prasanta, >>>>> >>>>> Thanks for the review. Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~kaddepalli/8218674/webrev01/ >>>>> >>>>> >>>>> The check (newWidth>0) && (newHeight > 0) is done in >>>>> adjustWidthHeight function. >>>>> >>>> if (specifiedWidth != -1 && specifiedHeight != -1) {915 newWidth = >>>> specifiedWidth;916 newHeight = specifiedHeight;917 } ... 931 >>>> d.width = newWidth;932 d.height = newHeight;If >>>> specifiedWidth/Height is 0, then I do not see any check, it is just >>>> assigning to d.width/height, no? In that case, can we need to >>>> change the newstate without checking? Regards Prasanta >>>>> Thanks, >>>>> Krishna >>>>> >>>>>> On 04-Mar-2019, at 1:29 PM, Prasanta Sadhukhan >>>>>> >>>>> > wrote: >>>>>> >>>>>> Hi Krishna, >>>>>> >>>>>> You can reuse existing method getLoadsSynchronously() instead of >>>>>> checking for (state & SYNC_LOAD_FLAG) != 0) >>>>>> >>>>>> BTW, do we not have to check if (newWidth > 0) & newHeight >0 >>>>>> before changing the newstate @l797? The copyright year in >>>>>> testcase should be changed to 2019. Regards Prasanta >>>>>> On 01-Mar-19 12:10 PM, Krishna Addepalli wrote: >>>>>>> Thanks for the review Sergey. >>>>>>> Can I have one more review? Prasanta maybe? >>>>>>> >>>>>>> Thanks, >>>>>>> Krishna >>>>>>> >>>>>>>> On 01-Mar-2019, at 3:40 AM, Sergey Bylokhov wrote: >>>>>>>> >>>>>>>> Looks fine. >>>>>>>> >>>>>>>> On 21/02/2019 08:44, Sergey Bylokhov wrote: >>>>>>>>> On 20/02/2019 22:21, Krishna Addepalli wrote: >>>>>>>>>> Hi Sergey, >>>>>>>>>> >>>>>>>>>> I have fixed the issue. Could you check now? >>>>>>>>> Yes, it works now, I look to the fix. >>>>>>>>>> Thanks, >>>>>>>>>> Krishna >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Sergey Bylokhov >>>>>>>>>> Sent: Thursday, February 21, 2019 3:54 AM >>>>>>>>>> To: Krishna Addepalli;swing-dev at openjdk.java.net >>>>>>>>>> Subject: Re: [13] RFR: JDK-8218674 - HTML Tooltip with "img=src" on component doesn't show >>>>>>>>>> >>>>>>>>>> Hi, Krishna. >>>>>>>>>> >>>>>>>>>> Some links have wrong file permissions, "403 - Forbidden": >>>>>>>>>> http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/raw_files/new/test/jdk/javax/swing/text/html/8218674/circle.png >>>>>>>>>> http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/raw_files/new/test/jdk/javax/swing/text/html/8218674/TooltipImageTest.java >>>>>>>>>> >>>>>>>>>> On 20/02/2019 03:57, Krishna Addepalli wrote: >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> Please review a fix for the bug JDK-8218674:https://bugs.openjdk.java.net/browse/JDK-8218674 >>>>>>>>>>> Webrev:http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/ >>>>>>>>>>> >>>>>>>>>>> This is a regression introduced due to fix for JDK-8208638. The default behaviour for ImageView is to load an image asynchronously. Hence, it uses the ImageHandler::imageUpdate to get the updates to the image being loaded. That will set the width and height of the image view. ImageView::updateImageSize does not alter the width and height in this case. When a JToolTip is created and html text set as tooltip, internally, the image is requested to be loaded synchronously, and in this case, ImageView::updateImageSize is the only way to calculate the image size. Since the width and height were not specified in the tooltip, the image was not being drawn. >>>>>>>>>>> The fix is to check if the image is requested to be loaded synchronously, and if so, then do the same calculation as for the fix for JDK-8208638, which will provide valid image width and height, additionally also taking care of the scaling issues fixed for JDK-8208638. >>>>>>>>>>> I have tested the fix on Windows, Linux(Ubuntu) and Mac, and found that it is working. I have also run all the jtreg tests under the test/jdk/javax/swing/text/html, and found no new failures. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Krishna >>>>>>>> -- >>>>>>>> Best regards, Sergey. >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishna.addepalli at oracle.com Wed Mar 6 11:38:48 2019 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Wed, 6 Mar 2019 03:38:48 -0800 (PST) Subject: [13] RFR: JDK-8218674 - HTML Tooltip with "img=src" on component doesn't show In-Reply-To: <0af3dc2c-643f-f80a-1565-3b6e0ac7efc9@oracle.com> References: <8698613c-6ab5-46fa-fad0-0a9935ed588e@oracle.com> <1b94404f-60bb-4381-b422-ebacaf42c71c@default> <6024edb9-c245-dfb0-4009-767ce59f3262@oracle.com> <97E0E21C-4FA9-4837-8404-FBDCDBF13A5E@oracle.com> <20bc0723-91fc-81b8-cdb2-7170d9433b5b@oracle.com> <517F3E4A-7F96-4357-86A2-6702A872F9EC@oracle.com> <24dd1ffe-ffab-abaa-43d8-ad7c92fe09e9@oracle.com> <0af3dc2c-643f-f80a-1565-3b6e0ac7efc9@oracle.com> Message-ID: <4b851e73-fe3c-46c0-a7c1-8cf55ed18fd3@default> Hi Prasanta, Ok, lets understand this in terms of the possible cases: When newWidth > 0 || newHeight > 0 - then we should update the state anyway. This covers 3 cases in which we need update the state. The only other case is when newWidth < 0 && newHeight < 0 - as in the dimensions are not specified in the html. In this case, we need to fallback to image dimensions, which again will warrant a state update. So, keeping this in view, I did not write another condition to check for the width /height change to update the state. Hope this clarifies the logic. Thanks, Krishna From: Prasanta Sadhukhan Sent: Wednesday, March 6, 2019 4:01 PM To: Krishna Addepalli Cc: Sergey Bylokhov ; swing-dev at openjdk.java.net Subject: Re: [13] RFR: JDK-8218674 - HTML Tooltip with "img=src" on component doesn't show Hi Krishna, But in other area of the code, like 778 if (newWidth > 0) { 779 newState |= WIDTH_FLAG; 780 } we do check for width/height > 0 before updating the state, so I would expect to maintain consistency, we should do the same for 797 newState |= (WIDTH_FLAG | HEIGHT_FLAG); Regards Prasanta On 06-Mar-19 3:25 PM, Krishna Addepalli wrote: Hi Prasanta, Handling 0-sized images was not done in the earlier fix as well. And this fix simply makes sure that the earlier fix works exactly the same when the image is loaded synchronously/asynchronously. At least from the looks of it, I do not see any harm in updating the image size, since it will only load the appropriate image, and update the ImageView object state. Thanks, Krishna On 05-Mar-2019, at 8:54 AM, Prasanta Sadhukhan wrote: Hi Krishna, On 04-Mar-19 5:49 PM, Krishna Addepalli wrote: Hi Prasanta, Yes, you are right. But, does it make a difference if we still update the values even if they are same? I am not pointing to d.width = newWidth; My concern is newState |= (WIDTH_FLAG | HEIGHT_FLAG); where you update the state even if width/height can be 0. I am not sure about possible repurcussions? I do not see any test with image of width/height=0 so thought that you probably do not check that path. Regards Prasanta Thanks, Krishna On 04-Mar-2019, at 5:12 PM, Prasanta Sadhukhan wrote: On 04-Mar-19 4:53 PM, Krishna Addepalli wrote: Hi Prasanta, Thanks for the review. Here is the updated webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8218674/webrev01/"http://cr.openjdk.java.net/~kaddepalli/8218674/webrev01/ The check (newWidth>0) && (newHeight > 0) is done in adjustWidthHeight function. if (specifiedWidth != -1 && specifiedHeight != -1) { 915 newWidth = specifiedWidth; 916 newHeight = specifiedHeight; 917 } ... 931 d.width = newWidth; 932 d.height = newHeight; If specifiedWidth/Height is 0, then I do not see any check, it is just assigning to d.width/height, no? In that case, can we need to change the newstate without checking? Regards Prasanta Thanks, Krishna On 04-Mar-2019, at 1:29 PM, Prasanta Sadhukhan wrote: Hi Krishna, You can reuse existing method getLoadsSynchronously() instead of checking for (state & SYNC_LOAD_FLAG) != 0) BTW, do we not have to check if (newWidth > 0) & newHeight >0 before changing the newstate @l797? The copyright year in testcase should be changed to 2019. Regards Prasanta On 01-Mar-19 12:10 PM, Krishna Addepalli wrote: Thanks for the review Sergey. Can I have one more review? Prasanta maybe? Thanks, Krishna On 01-Mar-2019, at 3:40 AM, Sergey Bylokhov HYPERLINK "mailto:Sergey.Bylokhov at oracle.com" wrote: Looks fine. On 21/02/2019 08:44, Sergey Bylokhov wrote: On 20/02/2019 22:21, Krishna Addepalli wrote: Hi Sergey, I have fixed the issue. Could you check now? Yes, it works now, I look to the fix. Thanks, Krishna -----Original Message----- From: Sergey Bylokhov Sent: Thursday, February 21, 2019 3:54 AM To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] RFR: JDK-8218674 - HTML Tooltip with "img=src" on component doesn't show Hi, Krishna. Some links have wrong file permissions, "403 - Forbidden": HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8218674/webrev00/raw_files/new/test/jdk/javax/swing/text/html/8218674/circle.png"http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/raw_files/new/test/jdk/javax/swing/text/html/8218674/circle.png HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8218674/webrev00/raw_files/new/test/jdk/javax/swing/text/html/8218674/TooltipImageTest.java"http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/raw_files/new/test/jdk/javax/swing/text/html/8218674/TooltipImageTest.java On 20/02/2019 03:57, Krishna Addepalli wrote: Hi All, Please review a fix for the bug JDK-8218674: https://bugs.openjdk.java.net/browse/JDK-8218674 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8218674/webrev00/"http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/ This is a regression introduced due to fix for JDK-8208638. The default behaviour for ImageView is to load an image asynchronously. Hence, it uses the ImageHandler::imageUpdate to get the updates to the image being loaded. That will set the width and height of the image view. ImageView::updateImageSize does not alter the width and height in this case. When a JToolTip is created and html text set as tooltip, internally, the image is requested to be loaded synchronously, and in this case, ImageView::updateImageSize is the only way to calculate the image size. Since the width and height were not specified in the tooltip, the image was not being drawn. The fix is to check if the image is requested to be loaded synchronously, and if so, then do the same calculation as for the fix for JDK-8208638, which will provide valid image width and height, additionally also taking care of the scaling issues fixed for JDK-8208638. I have tested the fix on Windows, Linux(Ubuntu) and Mac, and found that it is working. I have also run all the jtreg tests under the test/jdk/javax/swing/text/html, and found no new failures. Thanks, Krishna -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Mar 6 16:51:16 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 6 Mar 2019 22:21:16 +0530 Subject: [13] RFR: JDK-8218674 - HTML Tooltip with "img=src" on component doesn't show In-Reply-To: <4b851e73-fe3c-46c0-a7c1-8cf55ed18fd3@default> References: <8698613c-6ab5-46fa-fad0-0a9935ed588e@oracle.com> <1b94404f-60bb-4381-b422-ebacaf42c71c@default> <6024edb9-c245-dfb0-4009-767ce59f3262@oracle.com> <97E0E21C-4FA9-4837-8404-FBDCDBF13A5E@oracle.com> <20bc0723-91fc-81b8-cdb2-7170d9433b5b@oracle.com> <517F3E4A-7F96-4357-86A2-6702A872F9EC@oracle.com> <24dd1ffe-ffab-abaa-43d8-ad7c92fe09e9@oracle.com> <0af3dc2c-643f-f80a-1565-3b6e0ac7efc9@oracle.com> <4b851e73-fe3c-46c0-a7c1-8cf55ed18fd3@default> Message-ID: <5a53a525-12c9-6d73-ed79-908a69f1d803@oracle.com> ok. Thanks for the clarification. Regards Prasanta On 06-Mar-19 5:08 PM, Krishna Addepalli wrote: > > Hi Prasanta, > > Ok, lets understand this in terms of the possible cases: > > When newWidth > 0 || newHeight > 0 ? then we should update the state > anyway. This covers 3 cases in which we need update the state. > > The only other case is when newWidth < 0 && newHeight < 0 ? as in the > dimensions are not specified in the html. In this case, we need to > fallback to image dimensions, which again will warrant a state update. > > So, keeping this in view, I did not write another condition to check > for the width /height change to update the state. > > Hope this clarifies the logic. > > Thanks, > > Krishna > > *From:*Prasanta Sadhukhan > *Sent:* Wednesday, March 6, 2019 4:01 PM > *To:* Krishna Addepalli > *Cc:* Sergey Bylokhov ; > swing-dev at openjdk.java.net > *Subject:* Re: [13] RFR: JDK-8218674 - HTML Tooltip with > "img=src" on component doesn't show > > Hi Krishna, > > But in other area of the code, like > > 778 if (newWidth > 0) { > > 779??????????????? ?newState |= WIDTH_FLAG; > > 780???????????? } > > we do check for width/height > 0 before updating the state, so I would > expect to maintain consistency, we should do the same for > *797 newState |= (WIDTH_FLAG | HEIGHT_FLAG);* > > Regards > > Prasanta > > On 06-Mar-19 3:25 PM, Krishna Addepalli wrote: > > Hi Prasanta, > > Handling 0-sized images was not done in the earlier fix as well. > And this fix simply makes sure that the earlier fix works exactly > the same when the image is loaded synchronously/asynchronously. > > At least from the looks of it, I do not see any harm in updating > the image size, since it will only load the appropriate image, and > update the ImageView object state. > > Thanks, > > Krishna > > > > On 05-Mar-2019, at 8:54 AM, Prasanta Sadhukhan > > wrote: > > Hi Krishna, > > On 04-Mar-19 5:49 PM, Krishna Addepalli wrote: > > Hi Prasanta, > > Yes, you are right. But, does it make a difference if we > still update the values even if they are same? > > I am not pointing to > *d.width = newWidth;* > > ** > > *My concern is newState |= (WIDTH_FLAG | HEIGHT_FLAG);* > > where you update the state even if width/height can be 0. I am > not sure about possible repurcussions? I do not see any test > with image of width/height=0 so thought that you probably do > not check that path. > > Regards > > Prasanta > > Thanks, > > Krishna > > > > On 04-Mar-2019, at 5:12 PM, Prasanta Sadhukhan > > wrote: > > On 04-Mar-19 4:53 PM, Krishna Addepalli wrote: > > Hi Prasanta, > > Thanks for the review. Here is the updated webrev: > http://cr.openjdk.java.net/~kaddepalli/8218674/webrev01/ > > > The check (newWidth>0) && (newHeight > 0) is done > in adjustWidthHeight function. > > *if (specifiedWidth != -1 && specifiedHeight != -1) {* > > *915???????????? newWidth = specifiedWidth;* > > *916???????????? newHeight = specifiedHeight;* > > *917???????? }* > > *...* > > *931 d.width = newWidth;* > > *932 d.height = newHeight;* > > If specifiedWidth/Height is 0, then I do not see any > check, it is just assigning to d.width/height, no? In > that case, can we need to change the newstate without > checking? > > Regards > > Prasanta > > Thanks, > > Krishna > > > > On 04-Mar-2019, at 1:29 PM, Prasanta Sadhukhan > > wrote: > > Hi Krishna, > > You can reuse existing method > getLoadsSynchronously() instead of checking > for *(state & SYNC_LOAD_FLAG) != 0)* > > BTW, do we not have to check if (newWidth > 0) > & newHeight >0 before changing the newstate @l797? > > The copyright year in testcase should be > changed to 2019. > > Regards > > Prasanta > > On 01-Mar-19 12:10 PM, Krishna Addepalli wrote: > > Thanks for the review Sergey. > > Can I have one more review? Prasanta maybe? > > Thanks, > > Krishna > > On 01-Mar-2019, at 3:40 AM, Sergey Bylokhov > wrote: > > Looks fine. > > On 21/02/2019 08:44, Sergey Bylokhov wrote: > > On 20/02/2019 22:21, Krishna Addepalli wrote: > > Hi Sergey, > > I have fixed the issue. Could you check now? > > Yes, it works now, I look to the fix. > > Thanks, > > Krishna > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Thursday, February 21, 2019 3:54 AM > > To: Krishna Addepalli > ;swing-dev at openjdk.java.net > > > Subject: Re: [13] RFR: JDK-8218674 - HTML Tooltip with "img=src" on component doesn't show > > Hi, Krishna. > > Some links have wrong file permissions, "403 - Forbidden": > > http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/raw_files/new/test/jdk/javax/swing/text/html/8218674/circle.png > > > http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/raw_files/new/test/jdk/javax/swing/text/html/8218674/TooltipImageTest.java > > > On 20/02/2019 03:57, Krishna Addepalli wrote: > > Hi All, > > Please review a fix for the bug JDK-8218674:https://bugs.openjdk.java.net/browse/JDK-8218674 > > Webrev:http://cr.openjdk.java.net/~kaddepalli/8218674/webrev00/ > > > This is a regression introduced due to fix for JDK-8208638. The default behaviour for ImageView is to load an image asynchronously. Hence, it uses the ImageHandler::imageUpdate to get the updates to the image being loaded. That will set the width and height of the image view. ImageView::updateImageSize does not alter the width and height in this case. When a JToolTip is created and html text set as tooltip, internally, the image is requested to be loaded synchronously, and in this case, ImageView::updateImageSize is the only way to calculate the image size. Since the width and height were not specified in the tooltip, the image was not being drawn. > > The fix is to check if the image is requested to be loaded synchronously, and if so, then do the same calculation as for the fix for JDK-8208638, which will provide valid image width and height, additionally also taking care of the scaling issues fixed for JDK-8208638. > > I have tested the fix on Windows, Linux(Ubuntu) and Mac, and found that it is working. I have also run all the jtreg tests under the test/jdk/javax/swing/text/html, and found no new failures. > > Thanks, > > Krishna > > -- > > Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Mar 6 17:12:17 2019 From: philip.race at oracle.com (Philip Race) Date: Wed, 06 Mar 2019 22:42:17 +0530 Subject: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash In-Reply-To: References: <86dc6276-6a1c-4d09-8155-705fea8fd95e@default> <465ad181-9c9c-4752-a3bc-595e82f08744@default> <9149f70d-5265-efb1-e496-48e159e61e92@oracle.com> <554176f6-b538-46b5-97bb-14e488f50656@default> <5C5DEB0E.5010405@oracle.com> <23625b97-76d0-4956-8d4b-bf1add82ceb1@default> <1d4ad24a-e6bf-8e71-c88c-020e1106f089@oracle.com> <8634f5a6-a0a6-5739-9fd6-9a304a4a97f3@oracle.com> <70c695de-a54e-4aad-ae7b-0e11a6b9054e@default> Message-ID: <5C7FFF71.1020809@oracle.com> the webrev needs a couple of minor tweaks : contains empty string -> is the empty string and immeadiately -> immediately Go ahead and finalize the CSR which looks OK. -phil. On 3/6/19, 11:45 AM, Shashidhara Veerabhadraiah wrote: > > Hi Phil\Sergey, Please review the CSR along with the bug fix. > > Webrev: http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/ > > > CSR: https://bugs.openjdk.java.net/browse/JDK-8218737 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216008 > > Thanks and regards, > > Shashi > > *From:*Shashidhara Veerabhadraiah > *Sent:* Monday, March 4, 2019 3:36 PM > *To:* Philip Race ; Joe Darcy > > *Cc:* awt-dev at openjdk.java.net; swing-dev at openjdk.java.net > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty list leads to crash > > Hi Joe, Please find the updated Webrev fixing the typo: > > http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/ > > > Thanks and regards, > > Shashi > > *From:*Shashidhara Veerabhadraiah > *Sent:* Thursday, February 21, 2019 2:08 PM > *To:* Philip Race >; Joe Darcy > > *Cc:* awt-dev at openjdk.java.net ; > swing-dev at openjdk.java.net > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty list leads to crash > > Hi Joe, Please find the new Webrev fixing the specification as asked > in the CSR bug: https://bugs.openjdk.java.net/browse/JDK-8218737 > > Webrev: http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.06/ > > > Thanks and regards, > > Shashi > > *From:*Shashidhara Veerabhadraiah > *Sent:* Monday, February 18, 2019 10:19 AM > *To:* Philip Race > > *Cc:* awt-dev at openjdk.java.net ; > swing-dev at openjdk.java.net > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty list leads to crash > > Thank you Phil for that help on CSR. > > *From:*Phil Race > *Sent:* Friday, February 15, 2019 9:41 PM > *To:* Shashidhara Veerabhadraiah > > > *Cc:* Sergey Bylokhov >; awt-dev at openjdk.java.net > ; swing-dev at openjdk.java.net > > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty list leads to crash > > That text may actually be worse. > Although I maybe didn't get your distinction of null vs the empty > string here ? > > Oh, wait. Why is this doc clarification on the PRIVATE implementation > method ? > It needs to go on the public getDefaultToolkit() method to have any > point whatsoever > especially from a CSR perspective. > Try this : > - * toolkit is created. All errors are handled via an AWTError > exception. > + * toolkit is created. > + * If the list of assistive technology providers is the empty > string, or > + * contains only white space characters then the method returns > immediately. > + * All other errors are handled via an AWTError exception. > > > I think the CSR needs some work too. I've made some updates there. > > -phil. > > On 2/15/19 2:10 AM, Shashidhara Veerabhadraiah wrote: > > Hi Phil, I have updated the CSR and updated the information for > the function and here is the new Webrev: > > http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.05/ > > > Thanks and regards, > > Shashi > > *From:*Phil Race > *Sent:* Friday, February 15, 2019 2:58 AM > *To:* Shashidhara Veerabhadraiah > > > *Cc:* Sergey Bylokhov > ; awt-dev at openjdk.java.net > ; swing-dev at openjdk.java.net > > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty list leads to crash > > + * activate method. If the list of assistive technology providers is empty string, > > > > is "the" empty string. > > > > > > The CSR needs to be updated to include this spec. > > What is there now in the specification section needs to be fixed > > It should not point to the webrev or review and right now > > doesn't contain the change to the javadoc in the body of the CSR > > > > I think I even have to question most of the rest of it. > > Any one reading it would think that we always used to throw an exception in such > > case and now want to stop doing so. Isn't the bug that we did NOT throw an exception > > and now we do ? You only hint at that when you say at the end of "Solution", "as was the case earlier" > > > > If I am right the only thing you need in the CSR is to say that you > > are reverting the implementation to previous behaviour and updating the > > specification to make it clear that this behaviour is allowed by the spec > > since this case was unclear. > > > > -phil. > > On 2/12/19 1:08 AM, Shashidhara Veerabhadraiah wrote: > > Hi Phil, Here is the new Webrev and CSR for the same: > > http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.04/ > > > CSR: https://bugs.openjdk.java.net/browse/JDK-8218737 > > Thanks and regards, > > Shashi > > *From:*Philip Race > *Sent:* Saturday, February 9, 2019 2:18 AM > *To:* Shashidhara Veerabhadraiah > > > *Cc:* Sergey Bylokhov > ; awt-dev at openjdk.java.net > ; swing-dev at openjdk.java.net > > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty list leads > to crash > > FWIW I think this could be closed out as "not a bug". > An empty value string is an error and the spec. says AWTError is > how errors are reported. In fact I'll argue that 8 was wrong not > to have thrown an exception in such a case. > It was an accident of the implementation that it did not. > But if we want to be behaviourally compatible then ... > Note that since you now document this you need an approved CSR > BEFORE pushing it. > > And if you go the CSR route you may need to be more precise > about what > you mean by "empty". > > I think it needs to say > > "If the list of assistive technology providers is null, or > contains only white > space characters then the method returns immediately. > All other errors are handled by throwing {@code AWTError}" > > @throws AWTError if there is any error in parsing or loading > the ATs. > > -phil. > > On 1/21/19, 9:12 AM, Shashidhara Veerabhadraiah wrote: > > Hi Sergey, Here is the new Webrev for your comments: > > > > http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.02/ > > > > Thanks and regards, > > Shashi > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Saturday, January 19, 2019 3:47 AM > > To: Shashidhara Veerabhadraiah ;awt-dev at openjdk.java.net ;swing-dev at openjdk.java.net > > Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash > > > > On 16/01/2019 23:03,shashidhara.veerabhadraiah at oracle.com wrote: > > Another point is that the whitespace trimming should not trigger additional input processing for the custom class that will be used for assistive technology. For eg., if custom class "FooProvider" is implemented and if we pass " FooProvider " by mistake, a bug may be created to trim the whitespace in this case as well!! > > > > Yes, my previous email suggested to always trim the content of the "input", it will cover all cases, the "atNames" is empty, the "atNames" contains only the whitespace, or the name of the class has some spaces at the start/end. > > > > > > Thanks and regards, > > > > Shashi > > > > > > On 17/01/19 10:28 AM, Shashidhara Veerabhadraiah wrote: > > We need one way to tell the system not to load any assistive technologies and which is being provided. > > If we add trailing white spaces removal then we may need to add another functionality to see if that class exists or not and based on that not to load anything(without throwing the error because we are parsing the input content). I think that would take a different direction. I feel it is fair enough to provide one way to tell not to load any assistive technologies and additional parsing would only lead to other ways/expectations. > > > > Thanks and regards, > > Shashi > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Thursday, January 17, 2019 1:33 AM > > To: Shashidhara Veerabhadraiah ;awt-dev at openjdk.java.net ;swing-dev at openjdk.java.net > > Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash > > > > I guess you meant whitespaces, then it is unclear why we should not consider "empty" parameter as a "mistake"? > > > > On 15/01/2019 20:37, Shashidhara Veerabhadraiah wrote: > > Hi Sergey, I felt that a string with an empty space is intentional and should be considering it as a 'mistake' if done by the developers. Hence I feel it is not required(as there is a way to tell nothing to load). Please let me know if you think otherwise. > > > > > > Thanks and regards, > > Shashi > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Tuesday, January 15, 2019 7:32 AM > > To: Shashidhara Veerabhadraiah ;awt-dev at openjdk.java.net ;swing-dev at openjdk.java.net > > Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash > > > > Hi, Shashi. > > > > Should we trim all whitespaces from the "atNames"? > > Otherwise the "atNames", which contains only one whitespace, will trigger the same error. > > > > On 09/01/2019 00:20, Shashidhara Veerabhadraiah wrote: > > Hi Sergey, Thanks for pointing that out. Here is the new Webrev: > > > > http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.01/ > > > > Thanks and regards, > > Shashi > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Friday, January 4, 2019 3:48 AM > > To: Shashidhara Veerabhadraiah ;awt-dev at openjdk.java.net ;swing-dev at openjdk.java.net > > Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash > > > > Hi, Shashi. > > I think you can update an existing test: > > open/test/jdk/javax/accessibility/AccessibilityProvider/basic.sh > > > > On 03/01/2019 01:36, Shashidhara Veerabhadraiah wrote: > > Hi All, Please review a fix for the below bug. > > > > Bug:https://bugs.openjdk.java.net/browse/JDK-8216008 > > > > Webrev:http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.00/ > > > > Since the mentioned list of assistive technologies for the system property(javax.accessibility.assistive_technologies) is loaded by jvm am unable to write a test case for this bug. The test file attached with the bug can be used for testing this fix. > > > > This fix removes the error(class not found error) by passing an empty list to system variable javax.accessibility.assistive_technologies and does not load any assistive technologies(as the list is empty). Currently empty list produce a crash which is not required as there was no class name mentioned in the list. Please read the bug comments for more information. > > > > Thanks and regards, > > > > Shashi > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Mar 7 05:13:27 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 6 Mar 2019 21:13:27 -0800 Subject: [13] RFR JDK-8215396: JTabbedPane preferred size calculation is wrong for SCROLL_TAB_LAYOUT In-Reply-To: References: <62f1a4ad-ec66-361b-b16e-30577173d78f@oracle.com> Message-ID: <398a7b40-6965-1e24-5b00-890f32a71d4c@oracle.com> Looks fine. On 05/03/2019 21:03, Prasanta Sadhukhan wrote: > Hi Sergey, > > Modified test in webrev to iterate through installed L&Fs > http://cr.openjdk.java.net/~psadhukhan/8215396/webrev.1/ > > Regards > Prasanta > On 06-Mar-19 6:35 AM, Sergey Bylokhov wrote: >> Hi, Prasanta. >> The change looks fine, but I have two comments. >> ?- Please close the JDK-7151452 as a duplicate of JDK-8215396, since you sent JDK-8215396 to the review. >> ?- Looks like the test depends on the L&F, on my system it is passed on macOS on jdk11, probably it should checks all installe L&Fs? >> >> On 27/02/2019 02:25, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for an issue where it is seen that for SCROLL_TAB_LAYOUT the border of the content of JTabbedPane is not fully shown, whereas for WRAP_TAB_LAYOUT policy, the content is fully shown. >>> >>> It seems BasicTabbedPaneUI.TabbedPaneScrollLayout inner class (used for SCROLL_TAB_LAYOUT) has preferredTabAreaHeight() and preferredTabAreaWidth() which are overridden from >>> its superclass, BasicTabbedPaneUI.TabbedPaneLayout (used for WRAP_TAB_LAYOUT). In superclass, these methods take into account the tab area insets, but the overridden methods in TabbedPaneScrollLayout? don't. >>> >>> Proposed fix is to use existing methods [calculateTabAreaHeight,calculateTabAreaWidth] for calculating the size as was done for WRAP_TAB_LAYOUT. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215396 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8215396/webrev.0/ >>> >>> Regards >>> Prasanta >> >> > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Thu Mar 7 11:37:02 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 7 Mar 2019 17:07:02 +0530 Subject: [13] RFR JDK-8220250: fix headings in java.desktop Message-ID: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> Hi All, Bug: https://bugs.openjdk.java.net/browse/JDK-8220250 webrev: http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.0/ Please review a doc fix to fix heading style to improve the accessibility JDK API documentation of java.desktop module. Main approach taken for fixing heading style are: - headings in documentation comments for modules, packages and types should start at

- Headings should be hierarchical, and without ascending gaps, so

should be followed by

,

should be followed by

or another

Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Mar 7 22:07:50 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 7 Mar 2019 14:07:50 -0800 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> Message-ID: Looks fine. On 07/03/2019 03:37, Prasanta Sadhukhan wrote: > Hi All, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220250 > webrev: http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.0/ > > Please review a doc fix to fix heading style to improve the accessibility JDK API documentation of java.desktop module. > > Main approach taken for fixing heading style are: > - headings in documentation comments for modules, packages and types should start at

- Headings should be hierarchical, and without ascending gaps, so

should be followed by

,

should be followed by

or another

Regards Prasanta -- Best regards, Sergey. From philip.race at oracle.com Fri Mar 8 03:47:29 2019 From: philip.race at oracle.com (Philip Race) Date: Fri, 08 Mar 2019 09:17:29 +0530 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> Message-ID: <5C81E5D1.8040504@oracle.com> Apart from making sure all the files are fixed there are two things to look for : 1) If by moving a heading up from H3 to H2 you've now created a similar error because there is now no H3 before an H4. To be sure of this I think you'd need to run Jon's tool - how did you verify it ? 2) If in a case like UIManager where you've moved some subsequent headings up from H3 to H2 to match the new size at the reported error site , would it have been better visually to leave them as H3 ? ... probably not .. but if there were generated doc for us to look at posted that would be easier to tell. -phil. On 3/8/19, 3:37 AM, Sergey Bylokhov wrote: > Looks fine. > > On 07/03/2019 03:37, Prasanta Sadhukhan wrote: >> Hi All, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8220250 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.0/ >> >> Please review a doc fix to fix heading style to improve the >> accessibility JDK API documentation of java.desktop module. >> >> Main approach taken for fixing heading style are: >> - headings in documentation comments for modules, packages and types >> should start at

- Headings should be hierarchical, and without >> ascending gaps, so

should be followed by

,

should be >> followed by

or another

Regards Prasanta > > From shashidhara.veerabhadraiah at oracle.com Fri Mar 8 05:03:13 2019 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Thu, 7 Mar 2019 21:03:13 -0800 (PST) Subject: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash In-Reply-To: <5C7FFF71.1020809@oracle.com> References: <86dc6276-6a1c-4d09-8155-705fea8fd95e@default> <465ad181-9c9c-4752-a3bc-595e82f08744@default> <9149f70d-5265-efb1-e496-48e159e61e92@oracle.com> <554176f6-b538-46b5-97bb-14e488f50656@default> <5C5DEB0E.5010405@oracle.com> <23625b97-76d0-4956-8d4b-bf1add82ceb1@default> <1d4ad24a-e6bf-8e71-c88c-020e1106f089@oracle.com> <8634f5a6-a0a6-5739-9fd6-9a304a4a97f3@oracle.com> <70c695de-a54e-4aad-ae7b-0e11a6b9054e@default> <5C7FFF71.1020809@oracle.com> Message-ID: <88e0e602-7b4e-443d-95fe-a7fe288fa161@default> Thank you Phil for the review and here are the updates done: ? HYPERLINK "http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.08/"http://cr.openjdk.java.net/~sveerabhadra/8216008//webrev.08/ ? Thanks and regards, Shashi ? From: Philip Race Sent: Wednesday, March 6, 2019 10:42 PM To: Shashidhara Veerabhadraiah Cc: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net; Joe Darcy Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? the webrev needs a couple of minor tweaks : ? contains empty string -> is the empty string ? and ? immeadiately -> immediately Go ahead and finalize the CSR which looks OK. -phil. On 3/6/19, 11:45 AM, Shashidhara Veerabhadraiah wrote: Hi Phil\Sergey, Please review the CSR along with the bug fix. ? Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.07/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/ ? CSR: https://bugs.openjdk.java.net/browse/JDK-8218737 ? Bug: https://bugs.openjdk.java.net/browse/JDK-8216008 ? Thanks and regards, Shashi ? From: Shashidhara Veerabhadraiah Sent: Monday, March 4, 2019 3:36 PM To: Philip Race HYPERLINK "mailto:philip.race at oracle.com"; Joe Darcy HYPERLINK "mailto:joe.darcy at oracle.com" Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi Joe, Please find the updated Webrev fixing the typo: ? HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.07/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/ ? Thanks and regards, Shashi ? From: Shashidhara Veerabhadraiah Sent: Thursday, February 21, 2019 2:08 PM To: Philip Race ; Joe Darcy Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi Joe, Please find the new Webrev fixing the specification as asked in the CSR bug: https://bugs.openjdk.java.net/browse/JDK-8218737 ? Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.06/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.06/ ? Thanks and regards, Shashi ? From: Shashidhara Veerabhadraiah Sent: Monday, February 18, 2019 10:19 AM To: Philip Race Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Thank you Phil for that help on CSR. ? From: Phil Race Sent: Friday, February 15, 2019 9:41 PM To: Shashidhara Veerabhadraiah Cc: Sergey Bylokhov ; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? That text may actually be worse. Although I maybe didn't get your distinction of null vs the empty string here ? Oh, wait. Why is this doc clarification on the PRIVATE implementation method ? It needs to go on the public getDefaultToolkit() method to have any point whatsoever especially from a CSR perspective. Try this : -???? * toolkit is created. All errors are handled via an AWTError exception. +???? * toolkit is created. +???? * If the list of assistive technology providers is the empty string, or +???? * contains only white space characters then the method returns immediately. +???? * All other errors are handled via an AWTError exception. I think the CSR needs some work too. I've made some updates there. -phil. On 2/15/19 2:10 AM, Shashidhara Veerabhadraiah wrote: Hi Phil, I have updated the CSR and updated the information for the function and here is the new Webrev: ? HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.05/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.05/ Thanks and regards, Shashi ? From: Phil Race Sent: Friday, February 15, 2019 2:58 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? +???? * activate method.? If the list of assistive technology providers is empty string, ? is "the" empty string. ? ? The CSR needs to be updated to include this spec. What is there now in the specification section needs to be fixed It should not point to the webrev or review and right now doesn't contain the change to the javadoc in the body of the CSR ? I think I even have to question most of the rest of it. Any one reading it would think that we always used to throw an exception in such case and now want to stop doing so. Isn't the bug that we did NOT throw an exception and now we do ? You only hint at that when you say at the end of "Solution", "as was the case earlier" ? If I am right the only thing you need in the CSR is to say that you are reverting the implementation to previous behaviour and updating the specification to make it clear that this behaviour is allowed by the spec since this case was unclear. ? -phil. ? On 2/12/19 1:08 AM, Shashidhara Veerabhadraiah wrote: Hi Phil, Here is the new Webrev and CSR for the same: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.04/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.04/ ? CSR: https://bugs.openjdk.java.net/browse/JDK-8218737 ? Thanks and regards, Shashi ? From: Philip Race Sent: Saturday, February 9, 2019 2:18 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? FWIW I think this could be closed out as "not a bug". An empty value string is an error and the spec. says AWTError is how errors are reported. In fact I'll argue that 8 was wrong not to have thrown an exception in such a case. It was an accident of the implementation that it did not. But if we want to be behaviourally compatible then ... Note that since you now document this you need an approved CSR BEFORE pushing it. And if you go the CSR route you may need to be more precise about what you mean by "empty". I think it needs to say "If the list of assistive technology providers is null, or contains only white space characters then the method returns immediately. All other errors are handled by throwing {@code AWTError}" @throws AWTError if there is any error in parsing or loading the ATs. -phil. On 1/21/19, 9:12 AM, Shashidhara Veerabhadraiah wrote: Hi Sergey, Here is the new Webrev for your comments: ? HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.02/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.02/ ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Saturday, January 19, 2019 3:47 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? On 16/01/2019 23:03, HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote: Another point is that the whitespace trimming should not trigger additional input processing? for the custom class that will be used for assistive technology. For eg., if custom class "FooProvider" is implemented and if we pass "? FooProvider? " by mistake, a bug may be created to trim the whitespace in this case as well!! ? Yes, my previous email suggested to always trim the content of the "input", it will cover all cases, the "atNames" is empty, the "atNames" contains only the whitespace, or the name of the class has some spaces at the start/end. ? ? Thanks and regards, ? Shashi ? ? On 17/01/19 10:28 AM, Shashidhara Veerabhadraiah wrote: We need one way to tell the system not to load any assistive technologies and which is being provided. If we add trailing white spaces removal then we may need to add another functionality to see if that class exists or not and based on that not to load anything(without throwing the error because we are parsing the input content). I think that would take a different direction. I feel it is fair enough to provide one way to tell not to load any assistive technologies and additional parsing would only lead to other ways/expectations. ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Thursday, January 17, 2019 1:33 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? I guess you meant whitespaces, then it is unclear why we should not consider "empty" parameter as a "mistake"? ? On 15/01/2019 20:37, Shashidhara Veerabhadraiah wrote: Hi Sergey, I felt that a string with an empty space is intentional and should be considering it as a 'mistake' if done by the developers. Hence I feel it is not required(as there is a way to tell nothing to load). Please let me know if you think otherwise. ? ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, January 15, 2019 7:32 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi, Shashi. ? Should we trim all whitespaces from the "atNames"? Otherwise the "atNames", which contains only one whitespace, will trigger the same error. ? On 09/01/2019 00:20, Shashidhara Veerabhadraiah wrote: Hi Sergey, Thanks for pointing that out. Here is the new Webrev: ? HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.01/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.01/ ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Friday, January 4, 2019 3:48 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi, Shashi. I think you can update an existing test: open/test/jdk/javax/accessibility/AccessibilityProvider/basic.sh ? On 03/01/2019 01:36, Shashidhara Veerabhadraiah wrote: Hi All, Please review a fix for the below bug. ? Bug: https://bugs.openjdk.java.net/browse/JDK-8216008 ? Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.00/ ? Since the mentioned list of assistive technologies for the system property(javax.accessibility.assistive_technologies) is loaded by jvm am unable to write a test case for this bug. The test file attached with the bug can be used for testing this fix. ? This fix removes the error(class not found error) by passing an empty list to system variable javax.accessibility.assistive_technologies and does not load any assistive technologies(as the list is empty). Currently empty list produce a crash which is not required as there was no class name mentioned in the list. Please read the bug comments for more information. ? Thanks and regards, ? Shashi ? ? ? ? ? ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From shashidhara.veerabhadraiah at oracle.com Fri Mar 8 06:11:45 2019 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Thu, 7 Mar 2019 22:11:45 -0800 (PST) Subject: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash In-Reply-To: <88e0e602-7b4e-443d-95fe-a7fe288fa161@default> References: <86dc6276-6a1c-4d09-8155-705fea8fd95e@default> <465ad181-9c9c-4752-a3bc-595e82f08744@default> <9149f70d-5265-efb1-e496-48e159e61e92@oracle.com> <554176f6-b538-46b5-97bb-14e488f50656@default> <5C5DEB0E.5010405@oracle.com> <23625b97-76d0-4956-8d4b-bf1add82ceb1@default> <1d4ad24a-e6bf-8e71-c88c-020e1106f089@oracle.com> <8634f5a6-a0a6-5739-9fd6-9a304a4a97f3@oracle.com> <70c695de-a54e-4aad-ae7b-0e11a6b9054e@default> <5C7FFF71.1020809@oracle.com> <88e0e602-7b4e-443d-95fe-a7fe288fa161@default> Message-ID: Hi Phil, As discussed here are the updates for the Webrev. Hopefully this is correct. ? http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.09/ ? Thanks and regards, Shashi ? From: Shashidhara Veerabhadraiah Sent: Friday, March 8, 2019 10:33 AM To: Philip Race Cc: awt-dev at openjdk.java.net; Joe Darcy ; swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Thank you Phil for the review and here are the updates done: ? HYPERLINK "http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.08/"http://cr.openjdk.java.net/~sveerabhadra/8216008//webrev.08/ ? Thanks and regards, Shashi ? From: Philip Race Sent: Wednesday, March 6, 2019 10:42 PM To: Shashidhara Veerabhadraiah Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Joe Darcy Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? the webrev needs a couple of minor tweaks : ? contains empty string -> is the empty string ? and ? immeadiately -> immediately Go ahead and finalize the CSR which looks OK. -phil. On 3/6/19, 11:45 AM, Shashidhara Veerabhadraiah wrote: Hi Phil\Sergey, Please review the CSR along with the bug fix. ? Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.07/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/ ? CSR: https://bugs.openjdk.java.net/browse/JDK-8218737 ? Bug: https://bugs.openjdk.java.net/browse/JDK-8216008 ? Thanks and regards, Shashi ? From: Shashidhara Veerabhadraiah Sent: Monday, March 4, 2019 3:36 PM To: Philip Race HYPERLINK "mailto:philip.race at oracle.com"; Joe Darcy HYPERLINK "mailto:joe.darcy at oracle.com" Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi Joe, Please find the updated Webrev fixing the typo: ? HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.07/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/ ? Thanks and regards, Shashi ? From: Shashidhara Veerabhadraiah Sent: Thursday, February 21, 2019 2:08 PM To: Philip Race ; Joe Darcy Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi Joe, Please find the new Webrev fixing the specification as asked in the CSR bug: https://bugs.openjdk.java.net/browse/JDK-8218737 ? Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.06/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.06/ ? Thanks and regards, Shashi ? From: Shashidhara Veerabhadraiah Sent: Monday, February 18, 2019 10:19 AM To: Philip Race Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Thank you Phil for that help on CSR. ? From: Phil Race Sent: Friday, February 15, 2019 9:41 PM To: Shashidhara Veerabhadraiah Cc: Sergey Bylokhov ; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? That text may actually be worse. Although I maybe didn't get your distinction of null vs the empty string here ? Oh, wait. Why is this doc clarification on the PRIVATE implementation method ? It needs to go on the public getDefaultToolkit() method to have any point whatsoever especially from a CSR perspective. Try this : -???? * toolkit is created. All errors are handled via an AWTError exception. +???? * toolkit is created. +???? * If the list of assistive technology providers is the empty string, or +???? * contains only white space characters then the method returns immediately. +???? * All other errors are handled via an AWTError exception. I think the CSR needs some work too. I've made some updates there. -phil. On 2/15/19 2:10 AM, Shashidhara Veerabhadraiah wrote: Hi Phil, I have updated the CSR and updated the information for the function and here is the new Webrev: ? HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.05/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.05/ Thanks and regards, Shashi ? From: Phil Race Sent: Friday, February 15, 2019 2:58 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? +???? * activate method.? If the list of assistive technology providers is empty string, ? is "the" empty string. ? ? The CSR needs to be updated to include this spec. What is there now in the specification section needs to be fixed It should not point to the webrev or review and right now doesn't contain the change to the javadoc in the body of the CSR ? I think I even have to question most of the rest of it. Any one reading it would think that we always used to throw an exception in such case and now want to stop doing so. Isn't the bug that we did NOT throw an exception and now we do ? You only hint at that when you say at the end of "Solution", "as was the case earlier" ? If I am right the only thing you need in the CSR is to say that you are reverting the implementation to previous behaviour and updating the specification to make it clear that this behaviour is allowed by the spec since this case was unclear. ? -phil. ? On 2/12/19 1:08 AM, Shashidhara Veerabhadraiah wrote: Hi Phil, Here is the new Webrev and CSR for the same: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.04/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.04/ ? CSR: https://bugs.openjdk.java.net/browse/JDK-8218737 ? Thanks and regards, Shashi ? From: Philip Race Sent: Saturday, February 9, 2019 2:18 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? FWIW I think this could be closed out as "not a bug". An empty value string is an error and the spec. says AWTError is how errors are reported. In fact I'll argue that 8 was wrong not to have thrown an exception in such a case. It was an accident of the implementation that it did not. But if we want to be behaviourally compatible then ... Note that since you now document this you need an approved CSR BEFORE pushing it. And if you go the CSR route you may need to be more precise about what you mean by "empty". I think it needs to say "If the list of assistive technology providers is null, or contains only white space characters then the method returns immediately. All other errors are handled by throwing {@code AWTError}" @throws AWTError if there is any error in parsing or loading the ATs. -phil. On 1/21/19, 9:12 AM, Shashidhara Veerabhadraiah wrote: Hi Sergey, Here is the new Webrev for your comments: ? HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.02/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.02/ ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Saturday, January 19, 2019 3:47 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? On 16/01/2019 23:03, HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote: Another point is that the whitespace trimming should not trigger additional input processing? for the custom class that will be used for assistive technology. For eg., if custom class "FooProvider" is implemented and if we pass "? FooProvider? " by mistake, a bug may be created to trim the whitespace in this case as well!! ? Yes, my previous email suggested to always trim the content of the "input", it will cover all cases, the "atNames" is empty, the "atNames" contains only the whitespace, or the name of the class has some spaces at the start/end. ? ? Thanks and regards, ? Shashi ? ? On 17/01/19 10:28 AM, Shashidhara Veerabhadraiah wrote: We need one way to tell the system not to load any assistive technologies and which is being provided. If we add trailing white spaces removal then we may need to add another functionality to see if that class exists or not and based on that not to load anything(without throwing the error because we are parsing the input content). I think that would take a different direction. I feel it is fair enough to provide one way to tell not to load any assistive technologies and additional parsing would only lead to other ways/expectations. ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Thursday, January 17, 2019 1:33 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? I guess you meant whitespaces, then it is unclear why we should not consider "empty" parameter as a "mistake"? ? On 15/01/2019 20:37, Shashidhara Veerabhadraiah wrote: Hi Sergey, I felt that a string with an empty space is intentional and should be considering it as a 'mistake' if done by the developers. Hence I feel it is not required(as there is a way to tell nothing to load). Please let me know if you think otherwise. ? ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, January 15, 2019 7:32 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi, Shashi. ? Should we trim all whitespaces from the "atNames"? Otherwise the "atNames", which contains only one whitespace, will trigger the same error. ? On 09/01/2019 00:20, Shashidhara Veerabhadraiah wrote: Hi Sergey, Thanks for pointing that out. Here is the new Webrev: ? HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.01/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.01/ ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Friday, January 4, 2019 3:48 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi, Shashi. I think you can update an existing test: open/test/jdk/javax/accessibility/AccessibilityProvider/basic.sh ? On 03/01/2019 01:36, Shashidhara Veerabhadraiah wrote: Hi All, Please review a fix for the below bug. ? Bug: https://bugs.openjdk.java.net/browse/JDK-8216008 ? Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.00/ ? Since the mentioned list of assistive technologies for the system property(javax.accessibility.assistive_technologies) is loaded by jvm am unable to write a test case for this bug. The test file attached with the bug can be used for testing this fix. ? This fix removes the error(class not found error) by passing an empty list to system variable javax.accessibility.assistive_technologies and does not load any assistive technologies(as the list is empty). Currently empty list produce a crash which is not required as there was no class name mentioned in the list. Please read the bug comments for more information. ? Thanks and regards, ? Shashi ? ? ? ? ? ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Mar 8 06:47:41 2019 From: philip.race at oracle.com (Philip Race) Date: Fri, 08 Mar 2019 12:17:41 +0530 Subject: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash In-Reply-To: References: <86dc6276-6a1c-4d09-8155-705fea8fd95e@default> <465ad181-9c9c-4752-a3bc-595e82f08744@default> <9149f70d-5265-efb1-e496-48e159e61e92@oracle.com> <554176f6-b538-46b5-97bb-14e488f50656@default> <5C5DEB0E.5010405@oracle.com> <23625b97-76d0-4956-8d4b-bf1add82ceb1@default> <1d4ad24a-e6bf-8e71-c88c-020e1106f089@oracle.com> <8634f5a6-a0a6-5739-9fd6-9a304a4a97f3@oracle.com> <70c695de-a54e-4aad-ae7b-0e11a6b9054e@default> <5C7FFF71.1020809@oracle.com> <88e0e602-7b4e-443d-95fe-a7fe288fa161@default> Message-ID: <5C82100D.8030106@oracle.com> Ok but you need to wait for the CSR to be approved before you can push. -phil. On 3/8/19, 11:41 AM, Shashidhara Veerabhadraiah wrote: > > Hi Phil, As discussed here are the updates for the Webrev. Hopefully > this is correct. > > http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.09/ > > > Thanks and regards, > > Shashi > > *From:*Shashidhara Veerabhadraiah > *Sent:* Friday, March 8, 2019 10:33 AM > *To:* Philip Race > *Cc:* awt-dev at openjdk.java.net; Joe Darcy ; > swing-dev at openjdk.java.net > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty list leads to crash > > Thank you Phil for the review and here are the updates done: > > http://cr.openjdk.java.net/~sveerabhadra/8216008//webrev.08/ > > > Thanks and regards, > > Shashi > > *From:*Philip Race > *Sent:* Wednesday, March 6, 2019 10:42 PM > *To:* Shashidhara Veerabhadraiah > > > *Cc:* awt-dev at openjdk.java.net ; > swing-dev at openjdk.java.net ; Joe > Darcy > > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty list leads to crash > > the webrev needs a couple of minor tweaks : > > contains empty string -> is the empty string > > and > > immeadiately -> immediately > > > Go ahead and finalize the CSR which looks OK. > > -phil. > > On 3/6/19, 11:45 AM, Shashidhara Veerabhadraiah wrote: > > Hi Phil\Sergey, Please review the CSR along with the bug fix. > > Webrev: > http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/ > > > CSR: https://bugs.openjdk.java.net/browse/JDK-8218737 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216008 > > Thanks and regards, > > Shashi > > *From:*Shashidhara Veerabhadraiah > *Sent:* Monday, March 4, 2019 3:36 PM > *To:* Philip Race > ; Joe Darcy > > *Cc:* awt-dev at openjdk.java.net ; > swing-dev at openjdk.java.net > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty list leads to crash > > Hi Joe, Please find the updated Webrev fixing the typo: > > http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/ > > > Thanks and regards, > > Shashi > > *From:*Shashidhara Veerabhadraiah > *Sent:* Thursday, February 21, 2019 2:08 PM > *To:* Philip Race >; Joe Darcy > > *Cc:* awt-dev at openjdk.java.net ; > swing-dev at openjdk.java.net > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty list leads to crash > > Hi Joe, Please find the new Webrev fixing the specification as > asked in the CSR bug: https://bugs.openjdk.java.net/browse/JDK-8218737 > > Webrev: > http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.06/ > > > Thanks and regards, > > Shashi > > *From:*Shashidhara Veerabhadraiah > *Sent:* Monday, February 18, 2019 10:19 AM > *To:* Philip Race > > *Cc:* awt-dev at openjdk.java.net ; > swing-dev at openjdk.java.net > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty list leads to crash > > Thank you Phil for that help on CSR. > > *From:*Phil Race > *Sent:* Friday, February 15, 2019 9:41 PM > *To:* Shashidhara Veerabhadraiah > > > *Cc:* Sergey Bylokhov >; awt-dev at openjdk.java.net > ; swing-dev at openjdk.java.net > > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty list leads to crash > > That text may actually be worse. > Although I maybe didn't get your distinction of null vs the empty > string here ? > > Oh, wait. Why is this doc clarification on the PRIVATE > implementation method ? > It needs to go on the public getDefaultToolkit() method to have > any point whatsoever > especially from a CSR perspective. > Try this : > - * toolkit is created. All errors are handled via an AWTError > exception. > + * toolkit is created. > + * If the list of assistive technology providers is the empty > string, or > + * contains only white space characters then the method > returns immediately. > + * All other errors are handled via an AWTError exception. > > > I think the CSR needs some work too. I've made some updates there. > > -phil. > > On 2/15/19 2:10 AM, Shashidhara Veerabhadraiah wrote: > > Hi Phil, I have updated the CSR and updated the information > for the function and here is the new Webrev: > > http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.05/ > > > Thanks and regards, > > Shashi > > *From:*Phil Race > *Sent:* Friday, February 15, 2019 2:58 AM > *To:* Shashidhara Veerabhadraiah > > > *Cc:* Sergey Bylokhov > ; awt-dev at openjdk.java.net > ; swing-dev at openjdk.java.net > > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty list leads > to crash > > + * activate method. If the list of assistive technology providers is empty string, > > > > is "the" empty string. > > > > > > The CSR needs to be updated to include this spec. > > What is there now in the specification section needs to be fixed > > It should not point to the webrev or review and right now > > doesn't contain the change to the javadoc in the body of the CSR > > > > I think I even have to question most of the rest of it. > > Any one reading it would think that we always used to throw an exception in such > > case and now want to stop doing so. Isn't the bug that we did NOT throw an exception > > and now we do ? You only hint at that when you say at the end of "Solution", "as was the case earlier" > > > > If I am right the only thing you need in the CSR is to say that you > > are reverting the implementation to previous behaviour and updating the > > specification to make it clear that this behaviour is allowed by the spec > > since this case was unclear. > > > > -phil. > > On 2/12/19 1:08 AM, Shashidhara Veerabhadraiah wrote: > > Hi Phil, Here is the new Webrev and CSR for the same: > > http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.04/ > > CSR: https://bugs.openjdk.java.net/browse/JDK-8218737 > > Thanks and regards, > > Shashi > > *From:*Philip Race > *Sent:* Saturday, February 9, 2019 2:18 AM > *To:* Shashidhara Veerabhadraiah > > > *Cc:* Sergey Bylokhov > ; > awt-dev at openjdk.java.net > ; > swing-dev at openjdk.java.net > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty list > leads to crash > > FWIW I think this could be closed out as "not a bug". > An empty value string is an error and the spec. says > AWTError is > how errors are reported. In fact I'll argue that 8 was > wrong not > to have thrown an exception in such a case. > It was an accident of the implementation that it did not. > But if we want to be behaviourally compatible then ... > Note that since you now document this you need an approved > CSR BEFORE pushing it. > > And if you go the CSR route you may need to be more > precise about what > you mean by "empty". > > I think it needs to say > > "If the list of assistive technology providers is null, or > contains only white > space characters then the method returns immediately. > All other errors are handled by throwing {@code AWTError}" > > @throws AWTError if there is any error in parsing or > loading the ATs. > > -phil. > > On 1/21/19, 9:12 AM, Shashidhara Veerabhadraiah wrote: > > Hi Sergey, Here is the new Webrev for your comments: > > > > http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.02/ > > > > Thanks and regards, > > Shashi > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Saturday, January 19, 2019 3:47 AM > > To: Shashidhara Veerabhadraiah ;awt-dev at openjdk.java.net ;swing-dev at openjdk.java.net > > Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash > > > > On 16/01/2019 23:03,shashidhara.veerabhadraiah at oracle.com wrote: > > Another point is that the whitespace trimming should not trigger additional input processing for the custom class that will be used for assistive technology. For eg., if custom class "FooProvider" is implemented and if we pass " FooProvider " by mistake, a bug may be created to trim the whitespace in this case as well!! > > > > Yes, my previous email suggested to always trim the content of the "input", it will cover all cases, the "atNames" is empty, the "atNames" contains only the whitespace, or the name of the class has some spaces at the start/end. > > > > > > Thanks and regards, > > > > Shashi > > > > > > On 17/01/19 10:28 AM, Shashidhara Veerabhadraiah wrote: > > We need one way to tell the system not to load any assistive technologies and which is being provided. > > If we add trailing white spaces removal then we may need to add another functionality to see if that class exists or not and based on that not to load anything(without throwing the error because we are parsing the input content). I think that would take a different direction. I feel it is fair enough to provide one way to tell not to load any assistive technologies and additional parsing would only lead to other ways/expectations. > > > > Thanks and regards, > > Shashi > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Thursday, January 17, 2019 1:33 AM > > To: Shashidhara Veerabhadraiah ;awt-dev at openjdk.java.net ;swing-dev at openjdk.java.net > > Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash > > > > I guess you meant whitespaces, then it is unclear why we should not consider "empty" parameter as a "mistake"? > > > > On 15/01/2019 20:37, Shashidhara Veerabhadraiah wrote: > > Hi Sergey, I felt that a string with an empty space is intentional and should be considering it as a 'mistake' if done by the developers. Hence I feel it is not required(as there is a way to tell nothing to load). Please let me know if you think otherwise. > > > > > > Thanks and regards, > > Shashi > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Tuesday, January 15, 2019 7:32 AM > > To: Shashidhara Veerabhadraiah ;awt-dev at openjdk.java.net ;swing-dev at openjdk.java.net > > Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash > > > > Hi, Shashi. > > > > Should we trim all whitespaces from the "atNames"? > > Otherwise the "atNames", which contains only one whitespace, will trigger the same error. > > > > On 09/01/2019 00:20, Shashidhara Veerabhadraiah wrote: > > Hi Sergey, Thanks for pointing that out. Here is the new Webrev: > > > > http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.01/ > > > > Thanks and regards, > > Shashi > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Friday, January 4, 2019 3:48 AM > > To: Shashidhara Veerabhadraiah ;awt-dev at openjdk.java.net ;swing-dev at openjdk.java.net > > Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash > > > > Hi, Shashi. > > I think you can update an existing test: > > open/test/jdk/javax/accessibility/AccessibilityProvider/basic.sh > > > > On 03/01/2019 01:36, Shashidhara Veerabhadraiah wrote: > > Hi All, Please review a fix for the below bug. > > > > Bug:https://bugs.openjdk.java.net/browse/JDK-8216008 > > > > Webrev:http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.00/ > > > > Since the mentioned list of assistive technologies for the system property(javax.accessibility.assistive_technologies) is loaded by jvm am unable to write a test case for this bug. The test file attached with the bug can be used for testing this fix. > > > > This fix removes the error(class not found error) by passing an empty list to system variable javax.accessibility.assistive_technologies and does not load any assistive technologies(as the list is empty). Currently empty list produce a crash which is not required as there was no class name mentioned in the list. Please read the bug comments for more information. > > > > Thanks and regards, > > > > Shashi > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shashidhara.veerabhadraiah at oracle.com Fri Mar 8 06:56:33 2019 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Thu, 7 Mar 2019 22:56:33 -0800 (PST) Subject: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash In-Reply-To: <5C82100D.8030106@oracle.com> References: <86dc6276-6a1c-4d09-8155-705fea8fd95e@default> <465ad181-9c9c-4752-a3bc-595e82f08744@default> <9149f70d-5265-efb1-e496-48e159e61e92@oracle.com> <554176f6-b538-46b5-97bb-14e488f50656@default> <5C5DEB0E.5010405@oracle.com> <23625b97-76d0-4956-8d4b-bf1add82ceb1@default> <1d4ad24a-e6bf-8e71-c88c-020e1106f089@oracle.com> <8634f5a6-a0a6-5739-9fd6-9a304a4a97f3@oracle.com> <70c695de-a54e-4aad-ae7b-0e11a6b9054e@default> <5C7FFF71.1020809@oracle.com> <88e0e602-7b4e-443d-95fe-a7fe288fa161@default> <5C82100D.8030106@oracle.com> Message-ID: Thank you Phil. Sure will wait till CSR is approved. ? Thanks and regards, shashi ? From: Philip Race Sent: Friday, March 8, 2019 12:18 PM To: Shashidhara Veerabhadraiah Cc: awt-dev at openjdk.java.net; Joe Darcy ; swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Ok but you need to wait for the CSR to be approved before you can push. -phil. On 3/8/19, 11:41 AM, Shashidhara Veerabhadraiah wrote: Hi Phil, As discussed here are the updates for the Webrev. Hopefully this is correct. ? HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.09/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.09/ ? Thanks and regards, Shashi ? From: Shashidhara Veerabhadraiah Sent: Friday, March 8, 2019 10:33 AM To: Philip Race HYPERLINK "mailto:philip.race at oracle.com" Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Joe Darcy HYPERLINK "mailto:joe.darcy at oracle.com"; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Thank you Phil for the review and here are the updates done: ? HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.08/"http://cr.openjdk.java.net/~sveerabhadra/8216008//webrev.08/ ? Thanks and regards, Shashi ? From: Philip Race Sent: Wednesday, March 6, 2019 10:42 PM To: Shashidhara Veerabhadraiah Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Joe Darcy Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? the webrev needs a couple of minor tweaks : ? contains empty string -> is the empty string ? and ? immeadiately -> immediately Go ahead and finalize the CSR which looks OK. -phil. On 3/6/19, 11:45 AM, Shashidhara Veerabhadraiah wrote: Hi Phil\Sergey, Please review the CSR along with the bug fix. ? Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.07/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/ ? CSR: https://bugs.openjdk.java.net/browse/JDK-8218737 ? Bug: https://bugs.openjdk.java.net/browse/JDK-8216008 ? Thanks and regards, Shashi ? From: Shashidhara Veerabhadraiah Sent: Monday, March 4, 2019 3:36 PM To: Philip Race HYPERLINK "mailto:philip.race at oracle.com"; Joe Darcy HYPERLINK "mailto:joe.darcy at oracle.com" Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi Joe, Please find the updated Webrev fixing the typo: ? HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.07/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/ ? Thanks and regards, Shashi ? From: Shashidhara Veerabhadraiah Sent: Thursday, February 21, 2019 2:08 PM To: Philip Race ; Joe Darcy Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi Joe, Please find the new Webrev fixing the specification as asked in the CSR bug: https://bugs.openjdk.java.net/browse/JDK-8218737 ? Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.06/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.06/ ? Thanks and regards, Shashi ? From: Shashidhara Veerabhadraiah Sent: Monday, February 18, 2019 10:19 AM To: Philip Race Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Thank you Phil for that help on CSR. ? From: Phil Race Sent: Friday, February 15, 2019 9:41 PM To: Shashidhara Veerabhadraiah Cc: Sergey Bylokhov ; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? That text may actually be worse. Although I maybe didn't get your distinction of null vs the empty string here ? Oh, wait. Why is this doc clarification on the PRIVATE implementation method ? It needs to go on the public getDefaultToolkit() method to have any point whatsoever especially from a CSR perspective. Try this : -???? * toolkit is created. All errors are handled via an AWTError exception. +???? * toolkit is created. +???? * If the list of assistive technology providers is the empty string, or +???? * contains only white space characters then the method returns immediately. +???? * All other errors are handled via an AWTError exception. I think the CSR needs some work too. I've made some updates there. -phil. On 2/15/19 2:10 AM, Shashidhara Veerabhadraiah wrote: Hi Phil, I have updated the CSR and updated the information for the function and here is the new Webrev: ? HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.05/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.05/ Thanks and regards, Shashi ? From: Phil Race Sent: Friday, February 15, 2019 2:58 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? +???? * activate method.? If the list of assistive technology providers is empty string, ? is "the" empty string. ? ? The CSR needs to be updated to include this spec. What is there now in the specification section needs to be fixed It should not point to the webrev or review and right now doesn't contain the change to the javadoc in the body of the CSR ? I think I even have to question most of the rest of it. Any one reading it would think that we always used to throw an exception in such case and now want to stop doing so. Isn't the bug that we did NOT throw an exception and now we do ? You only hint at that when you say at the end of "Solution", "as was the case earlier" ? If I am right the only thing you need in the CSR is to say that you are reverting the implementation to previous behaviour and updating the specification to make it clear that this behaviour is allowed by the spec since this case was unclear. ? -phil. ? On 2/12/19 1:08 AM, Shashidhara Veerabhadraiah wrote: Hi Phil, Here is the new Webrev and CSR for the same: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.04/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.04/ ? CSR: https://bugs.openjdk.java.net/browse/JDK-8218737 ? Thanks and regards, Shashi ? From: Philip Race Sent: Saturday, February 9, 2019 2:18 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? FWIW I think this could be closed out as "not a bug". An empty value string is an error and the spec. says AWTError is how errors are reported. In fact I'll argue that 8 was wrong not to have thrown an exception in such a case. It was an accident of the implementation that it did not. But if we want to be behaviourally compatible then ... Note that since you now document this you need an approved CSR BEFORE pushing it. And if you go the CSR route you may need to be more precise about what you mean by "empty". I think it needs to say "If the list of assistive technology providers is null, or contains only white space characters then the method returns immediately. All other errors are handled by throwing {@code AWTError}" @throws AWTError if there is any error in parsing or loading the ATs. -phil. On 1/21/19, 9:12 AM, Shashidhara Veerabhadraiah wrote: Hi Sergey, Here is the new Webrev for your comments: ? HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.02/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.02/ ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Saturday, January 19, 2019 3:47 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? On 16/01/2019 23:03, HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote: Another point is that the whitespace trimming should not trigger additional input processing? for the custom class that will be used for assistive technology. For eg., if custom class "FooProvider" is implemented and if we pass "? FooProvider? " by mistake, a bug may be created to trim the whitespace in this case as well!! ? Yes, my previous email suggested to always trim the content of the "input", it will cover all cases, the "atNames" is empty, the "atNames" contains only the whitespace, or the name of the class has some spaces at the start/end. ? ? Thanks and regards, ? Shashi ? ? On 17/01/19 10:28 AM, Shashidhara Veerabhadraiah wrote: We need one way to tell the system not to load any assistive technologies and which is being provided. If we add trailing white spaces removal then we may need to add another functionality to see if that class exists or not and based on that not to load anything(without throwing the error because we are parsing the input content). I think that would take a different direction. I feel it is fair enough to provide one way to tell not to load any assistive technologies and additional parsing would only lead to other ways/expectations. ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Thursday, January 17, 2019 1:33 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? I guess you meant whitespaces, then it is unclear why we should not consider "empty" parameter as a "mistake"? ? On 15/01/2019 20:37, Shashidhara Veerabhadraiah wrote: Hi Sergey, I felt that a string with an empty space is intentional and should be considering it as a 'mistake' if done by the developers. Hence I feel it is not required(as there is a way to tell nothing to load). Please let me know if you think otherwise. ? ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, January 15, 2019 7:32 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi, Shashi. ? Should we trim all whitespaces from the "atNames"? Otherwise the "atNames", which contains only one whitespace, will trigger the same error. ? On 09/01/2019 00:20, Shashidhara Veerabhadraiah wrote: Hi Sergey, Thanks for pointing that out. Here is the new Webrev: ? HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.01/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.01/ ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Friday, January 4, 2019 3:48 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi, Shashi. I think you can update an existing test: open/test/jdk/javax/accessibility/AccessibilityProvider/basic.sh ? On 03/01/2019 01:36, Shashidhara Veerabhadraiah wrote: Hi All, Please review a fix for the below bug. ? Bug: https://bugs.openjdk.java.net/browse/JDK-8216008 ? Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.00/ ? Since the mentioned list of assistive technologies for the system property(javax.accessibility.assistive_technologies) is loaded by jvm am unable to write a test case for this bug. The test file attached with the bug can be used for testing this fix. ? This fix removes the error(class not found error) by passing an empty list to system variable javax.accessibility.assistive_technologies and does not load any assistive technologies(as the list is empty). Currently empty list produce a crash which is not required as there was no class name mentioned in the list. Please read the bug comments for more information. ? Thanks and regards, ? Shashi ? ? ? ? ? ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Fri Mar 8 09:12:26 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 8 Mar 2019 01:12:26 -0800 Subject: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash In-Reply-To: References: <86dc6276-6a1c-4d09-8155-705fea8fd95e@default> <9149f70d-5265-efb1-e496-48e159e61e92@oracle.com> <554176f6-b538-46b5-97bb-14e488f50656@default> <5C5DEB0E.5010405@oracle.com> <23625b97-76d0-4956-8d4b-bf1add82ceb1@default> <1d4ad24a-e6bf-8e71-c88c-020e1106f089@oracle.com> <8634f5a6-a0a6-5739-9fd6-9a304a4a97f3@oracle.com> <70c695de-a54e-4aad-ae7b-0e11a6b9054e@default> <5C7FFF71.1020809@oracle.com> <88e0e602-7b4e-443d-95fe-a7fe288fa161@default> <5C82100D.8030106@oracle.com> Message-ID: <606ce427-71da-8bdb-7726-5334ab3d3399@oracle.com> Hello, I strongly recommend using ??? String.strip rather than ??? String.trim as Strim.trim uses a idosyncratic definition of whitespace whereas the new-in-11 String.strip uses a conventional definition of white space. Likewise, I recommend linking "white space" to the definition of white space used by Character.isWhitespace. Thanks, -Joe On 3/7/2019 10:56 PM, Shashidhara Veerabhadraiah wrote: > > Thank you Phil. Sure will wait till CSR is approved. > > Thanks and regards, > > shashi > > *From:*Philip Race > *Sent:* Friday, March 8, 2019 12:18 PM > *To:* Shashidhara Veerabhadraiah > *Cc:* awt-dev at openjdk.java.net; Joe Darcy ; > swing-dev at openjdk.java.net > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty list leads to crash > > Ok but you need to wait for the CSR to be approved before you can push. > > -phil. > > On 3/8/19, 11:41 AM, Shashidhara Veerabhadraiah wrote: > > Hi Phil, As discussed here are the updates for the Webrev. > Hopefully this is correct. > > http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.09/ > > > Thanks and regards, > > Shashi > > *From:*Shashidhara Veerabhadraiah > *Sent:* Friday, March 8, 2019 10:33 AM > *To:* Philip Race > > *Cc:* awt-dev at openjdk.java.net ; > Joe Darcy ; > swing-dev at openjdk.java.net > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty list leads to crash > > Thank you Phil for the review and here are the updates done: > > http://cr.openjdk.java.net/~sveerabhadra/8216008//webrev.08/ > > > Thanks and regards, > > Shashi > > *From:*Philip Race > *Sent:* Wednesday, March 6, 2019 10:42 PM > *To:* Shashidhara Veerabhadraiah > > > *Cc:* awt-dev at openjdk.java.net ; > swing-dev at openjdk.java.net ; > Joe Darcy > > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty list leads to crash > > the webrev needs a couple of minor tweaks : > > contains empty string -> is the empty string > > > > and > > > > immeadiately -> immediately > > > Go ahead and finalize the CSR which looks OK. > > -phil. > > On 3/6/19, 11:45 AM, Shashidhara Veerabhadraiah wrote: > > Hi Phil\Sergey, Please review the CSR along with the bug fix. > > Webrev: > http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/ > > > CSR: https://bugs.openjdk.java.net/browse/JDK-8218737 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216008 > > Thanks and regards, > > Shashi > > *From:*Shashidhara Veerabhadraiah > *Sent:* Monday, March 4, 2019 3:36 PM > *To:* Philip Race > ; Joe Darcy > > *Cc:* awt-dev at openjdk.java.net > ; swing-dev at openjdk.java.net > > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty list leads > to crash > > Hi Joe, Please find the updated Webrev fixing the typo: > > http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/ > > > Thanks and regards, > > Shashi > > *From:*Shashidhara Veerabhadraiah > *Sent:* Thursday, February 21, 2019 2:08 PM > *To:* Philip Race >; Joe Darcy > > > *Cc:* awt-dev at openjdk.java.net > ; swing-dev at openjdk.java.net > > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty list leads > to crash > > Hi Joe, Please find the new Webrev fixing the specification as > asked in the CSR bug: > https://bugs.openjdk.java.net/browse/JDK-8218737 > > Webrev: > http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.06/ > > > Thanks and regards, > > Shashi > > *From:*Shashidhara Veerabhadraiah > *Sent:* Monday, February 18, 2019 10:19 AM > *To:* Philip Race > > *Cc:* awt-dev at openjdk.java.net > ; swing-dev at openjdk.java.net > > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty list leads > to crash > > Thank you Phil for that help on CSR. > > *From:*Phil Race > *Sent:* Friday, February 15, 2019 9:41 PM > *To:* Shashidhara Veerabhadraiah > > > *Cc:* Sergey Bylokhov >; awt-dev at openjdk.java.net > ; swing-dev at openjdk.java.net > > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty list leads > to crash > > That text may actually be worse. > Although I maybe didn't get your distinction of null vs the > empty string here ? > > Oh, wait. Why is this doc clarification on the PRIVATE > implementation method ? > It needs to go on the public getDefaultToolkit() method to > have any point whatsoever > especially from a CSR perspective. > Try this : > -???? * toolkit is created. All errors are handled via an > AWTError exception. > +???? * toolkit is created. > +???? * If the list of assistive technology providers is the > empty string, or > +???? * contains only white space characters then the method > returns immediately. > +???? * All other errors are handled via an AWTError exception. > > > I think the CSR needs some work too. I've made some updates there. > > -phil. > > On 2/15/19 2:10 AM, Shashidhara Veerabhadraiah wrote: > > Hi Phil, I have updated the CSR and updated the > information for the function and here is the new Webrev: > > http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.05/ > > > Thanks and regards, > > Shashi > > *From:*Phil Race > *Sent:* Friday, February 15, 2019 2:58 AM > *To:* Shashidhara Veerabhadraiah > > > *Cc:* Sergey Bylokhov > ; > awt-dev at openjdk.java.net > ; > swing-dev at openjdk.java.net > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty list > leads to crash > > +???? * activate method.? If the list of assistive > technology providers is empty string, > > is "the" empty string. > > The CSR needs to be updated to include this spec. > > What is there now in the specification section needs to be > fixed > > It should not point to the webrev or review and right now > > doesn't contain the change to the javadoc in the body of > the CSR > > I think I even have to question most of the rest of it. > > Any one reading it would think that we always used to > throw an exception in such > > case and now want to stop doing so. Isn't the bug that we > did NOT throw an exception > > and now we do ? You only hint at that when you say at the > end of "Solution", "as was the case earlier" > > If I am right the only thing you need in the CSR is to say > that you > > are reverting the implementation to previous behaviour and > updating the > > specification to make it clear that this behaviour is > allowed by the spec > > since this case was unclear. > > -phil. > > On 2/12/19 1:08 AM, Shashidhara Veerabhadraiah wrote: > > Hi Phil, Here is the new Webrev and CSR for the same: > > http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.04/ > > > CSR: https://bugs.openjdk.java.net/browse/JDK-8218737 > > Thanks and regards, > > Shashi > > *From:*Philip Race > *Sent:* Saturday, February 9, 2019 2:18 AM > *To:* Shashidhara Veerabhadraiah > > > *Cc:* Sergey Bylokhov > ; > awt-dev at openjdk.java.net > ; > swing-dev at openjdk.java.net > > *Subject:* Re: [13] JDK-8216008: > -Djavax.accessibility.assistive_technologies empty > list leads to crash > > FWIW I think this could be closed out as "not a bug". > An empty value string is an error and the spec. says > AWTError is > how errors are reported. In fact I'll argue that 8 was > wrong not > to have thrown an exception in such a case. > It was an accident of the implementation that it did not. > But if we want to be behaviourally compatible then ... > Note that since you now document this you need an > approved CSR BEFORE pushing it. > > And if you go the CSR route you may need to be more > precise about what > you mean by "empty". > > I think it needs to say > > "If the list of assistive technology providers is > null, or contains only white > space characters then the method returns immediately. > All other errors are handled by throwing {@code AWTError}" > > @throws AWTError if there is any error in parsing or > loading the ATs. > > -phil. > > On 1/21/19, 9:12 AM, Shashidhara Veerabhadraiah wrote: > > Hi Sergey, Here is the new Webrev for your comments: > > > > http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.02/ > > > > Thanks and regards, > > Shashi > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Saturday, January 19, 2019 3:47 AM > > To: Shashidhara Veerabhadraiah ;awt-dev at openjdk.java.net ;swing-dev at openjdk.java.net > > Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash > > > > On 16/01/2019 23:03,shashidhara.veerabhadraiah at oracle.com wrote: > > Another point is that the whitespace trimming should not trigger additional input processing? for the custom class that will be used for assistive technology. For eg., if custom class "FooProvider" is implemented and if we pass "? FooProvider? " by mistake, a bug may be created to trim the whitespace in this case as well!! > > > > Yes, my previous email suggested to always trim the content of the "input", it will cover all cases, the "atNames" is empty, the "atNames" contains only the whitespace, or the name of the class has some spaces at the start/end. > > > > > > Thanks and regards, > > > > Shashi > > > > > > On 17/01/19 10:28 AM, Shashidhara Veerabhadraiah wrote: > > We need one way to tell the system not to load any assistive technologies and which is being provided. > > If we add trailing white spaces removal then we may need to add another functionality to see if that class exists or not and based on that not to load anything(without throwing the error because we are parsing the input content). I think that would take a different direction. I feel it is fair enough to provide one way to tell not to load any assistive technologies and additional parsing would only lead to other ways/expectations. > > > > Thanks and regards, > > Shashi > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Thursday, January 17, 2019 1:33 AM > > To: Shashidhara Veerabhadraiah ;awt-dev at openjdk.java.net ;swing-dev at openjdk.java.net > > Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash > > > > I guess you meant whitespaces, then it is unclear why we should not consider "empty" parameter as a "mistake"? > > > > On 15/01/2019 20:37, Shashidhara Veerabhadraiah wrote: > > Hi Sergey, I felt that a string with an empty space is intentional and should be considering it as a 'mistake' if done by the developers. Hence I feel it is not required(as there is a way to tell nothing to load). Please let me know if you think otherwise. > > > > > > Thanks and regards, > > Shashi > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Tuesday, January 15, 2019 7:32 AM > > To: Shashidhara Veerabhadraiah ;awt-dev at openjdk.java.net ;swing-dev at openjdk.java.net > > Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash > > > > Hi, Shashi. > > > > Should we trim all whitespaces from the "atNames"? > > Otherwise the "atNames", which contains only one whitespace, will trigger the same error. > > > > On 09/01/2019 00:20, Shashidhara Veerabhadraiah wrote: > > Hi Sergey, Thanks for pointing that out. Here is the new Webrev: > > > > http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.01/ > > > > Thanks and regards, > > Shashi > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Friday, January 4, 2019 3:48 AM > > To: Shashidhara Veerabhadraiah ;awt-dev at openjdk.java.net ;swing-dev at openjdk.java.net > > Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash > > > > Hi, Shashi. > > I think you can update an existing test: > > open/test/jdk/javax/accessibility/AccessibilityProvider/basic.sh > > > > On 03/01/2019 01:36, Shashidhara Veerabhadraiah wrote: > > Hi All, Please review a fix for the below bug. > > > > Bug:https://bugs.openjdk.java.net/browse/JDK-8216008 > > > > Webrev:http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.00/ > > > > Since the mentioned list of assistive technologies for the system property(javax.accessibility.assistive_technologies) is loaded by jvm am unable to write a test case for this bug. The test file attached with the bug can be used for testing this fix. > > > > This fix removes the error(class not found error) by passing an empty list to system variable javax.accessibility.assistive_technologies and does not load any assistive technologies(as the list is empty). Currently empty list produce a crash which is not required as there was no class name mentioned in the list. Please read the bug comments for more information. > > > > Thanks and regards, > > > > Shashi > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pankaj.b.bansal at oracle.com Fri Mar 8 13:50:36 2019 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Fri, 8 Mar 2019 05:50:36 -0800 (PST) Subject: [13] RFR JDK-8220349: The fix done for JDK-8214253 have caused issues in JTree behaviour Message-ID: Hi All, Please review the following fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8220349 webrev http://cr.openjdk.java.net/~pbansal/8220349/webrev00/ Issue: The fix done for JDK-8214253 have caused issues in JTree behaviour. If the JTree node is selected, its background and text color become white and nothing is readable. The changes done in gtk3_paint_flat_box for JDK-8214253 have caused this issue as the changes were made for all the widgets. JDK-8214253 is specific to TOOL_TIP. So JDK-8214253 can be fixed by making changes only for TOOL_TIP like done in gtk3_get_color_for_state. The gtk3_paint_flat_box is also called by other widegts like JTree cell rendering and they have been handled well in transform_detail_string. So we don't want to copy the same code in get_style. Fix: This patch fixes the issue by making the changes done in gtk3_paint_flat_box specific to TOOL_TIP like were done in gtk3_get_color_for_state Testing: This fix can be verified by running SwingSet2 and using JTree. I have verified this on Ubuntu 16.04, 18.04, 18.10 and OEL 7.5. Regards, Pankaj Bansal -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Mar 8 15:09:19 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 8 Mar 2019 20:39:19 +0530 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: <5C81E5D1.8040504@oracle.com> References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> <5C81E5D1.8040504@oracle.com> Message-ID: <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> Hi Phil, On 08-Mar-19 9:17 AM, Philip Race wrote: > Apart from making sure all the files are fixed there are two things to > look for : > > 1) If by moving a heading up from H3 to H2 you've now created a > similar error > because there is now no H3 before an H4. To be sure of this I think you'd > need to run Jon's tool - how did you verify it ? > I missed one case in TextAttribute which I rectified http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.1/ ?It will be good to have Jon's tool so cc-ed him... > 2) If in a case like UIManager where you've moved some subsequent > headings > up from H3 to H2 to match the new size at the reported error site , > would it > have been better visually to leave them as H3 ? ... probably not .. > but if there > were generated doc for us to look at posted that would be easier to tell. I am using make docs to verify and the docs output can be found at http://cr.openjdk.java.net/~psadhukhan/8220250/docs/api/java.desktop/module-summary.html Regards Prasanta > > -phil. > > On 3/8/19, 3:37 AM, Sergey Bylokhov wrote: >> Looks fine. >> >> On 07/03/2019 03:37, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220250 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.0/ >>> >>> Please review a doc fix to fix heading style to improve the >>> accessibility JDK API documentation of java.desktop module. >>> >>> Main approach taken for fixing heading style are: >>> - headings in documentation comments for modules, packages and types >>> should start at

- Headings should be hierarchical, and without >>> ascending gaps, so

should be followed by

,

should be >>> followed by

or another

Regards Prasanta >> >> From jonathan.gibbons at oracle.com Fri Mar 8 20:50:19 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 8 Mar 2019 12:50:19 -0800 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> <5C81E5D1.8040504@oracle.com> <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> Message-ID: <681d69ba-da47-f0e5-d888-456f7c813116@oracle.com> Hi Prasanta, You mentioned the tool I was using to find the issues with headings... It's a bit of a hack -- it's an annotation processor that can be run by javac -- but while it is reasonably good at _detecting, it is not good at checking that you have fixed them _correctly_.? This is because it is just checking for some simple heuristics in the sequence of headings, without any concept of the semantic meaning of the headings. As an example, if you had a class comment containing (just) two

headings, the tool will report that an

is missing. If you fix the first

, so that the comment now has an

and an

, the tool will not find any sequencing issues, but that second

will now appear semantically as a subheading of the

, which was not the original intent of the comment.? (If we started using
as well as we would be able to do better, but that's a different story.) I don't have a good solution, except to say that if you update any heading in any individual comment, you should (probably) update them all. One script we could write as a verifier script would be to compare the number of headings in a modified source file (using `grep -c`) with the number of edits appearing in the output for `hg diff` for that file (again counted with `grep -c`).?? That would at least make sure you haven't missed any headings, but you'd still have to eyeball the edits to make sure they have been modified correctly. Finally, FWIW, I'm working on a fix for doclint, to improve its reporting of these issues.? The code is done, but I'm running tests, and will need a review, so this will likely be early next week. -- Jon On 3/8/19 7:09 AM, Prasanta Sadhukhan wrote: > Hi Phil, > > > On 08-Mar-19 9:17 AM, Philip Race wrote: >> Apart from making sure all the files are fixed there are two things >> to look for : >> >> 1) If by moving a heading up from H3 to H2 you've now created a >> similar error >> because there is now no H3 before an H4. To be sure of this I think >> you'd >> need to run Jon's tool - how did you verify it ? >> > I missed one case in TextAttribute which I rectified > http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.1/ > ?It will be good to have Jon's tool so cc-ed him... >> 2) If in a case like UIManager where you've moved some subsequent >> headings >> up from H3 to H2 to match the new size at the reported error site , >> would it >> have been better visually to leave them as H3 ? ... probably not .. >> but if there >> were generated doc for us to look at posted that would be easier to >> tell. > I am using make docs to verify and the docs output can be found at > http://cr.openjdk.java.net/~psadhukhan/8220250/docs/api/java.desktop/module-summary.html > > > Regards > Prasanta >> >> -phil. >> >> On 3/8/19, 3:37 AM, Sergey Bylokhov wrote: >>> Looks fine. >>> >>> On 07/03/2019 03:37, Prasanta Sadhukhan wrote: >>>> Hi All, >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220250 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.0/ >>>> >>>> Please review a doc fix to fix heading style to improve the >>>> accessibility JDK API documentation of java.desktop module. >>>> >>>> Main approach taken for fixing heading style are: >>>> - headings in documentation comments for modules, packages and >>>> types should start at

- Headings should be hierarchical, and >>>> without ascending gaps, so

should be followed by

,

>>>> should be followed by

or another

Regards Prasanta >>> >>> > From jonathan.gibbons at oracle.com Fri Mar 8 20:54:55 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 8 Mar 2019 12:54:55 -0800 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> <5C81E5D1.8040504@oracle.com> <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> Message-ID: Prasanta, You should double check this file: http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.1/src/java.desktop/share/classes/javax/print/attribute/package-info.java.udiff.html Previously, it was a mixture of

and

, suggesting that the

were subheadings of the enclosing logical

section.? Now, you have changed them all to

, meaning that now they are all equivalent headings. -- Jon On 3/8/19 7:09 AM, Prasanta Sadhukhan wrote: > Hi Phil, > > > On 08-Mar-19 9:17 AM, Philip Race wrote: >> Apart from making sure all the files are fixed there are two things >> to look for : >> >> 1) If by moving a heading up from H3 to H2 you've now created a >> similar error >> because there is now no H3 before an H4. To be sure of this I think >> you'd >> need to run Jon's tool - how did you verify it ? >> > I missed one case in TextAttribute which I rectified > http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.1/ > ?It will be good to have Jon's tool so cc-ed him... >> 2) If in a case like UIManager where you've moved some subsequent >> headings >> up from H3 to H2 to match the new size at the reported error site , >> would it >> have been better visually to leave them as H3 ? ... probably not .. >> but if there >> were generated doc for us to look at posted that would be easier to >> tell. > I am using make docs to verify and the docs output can be found at > http://cr.openjdk.java.net/~psadhukhan/8220250/docs/api/java.desktop/module-summary.html > > > Regards > Prasanta >> >> -phil. >> >> On 3/8/19, 3:37 AM, Sergey Bylokhov wrote: >>> Looks fine. >>> >>> On 07/03/2019 03:37, Prasanta Sadhukhan wrote: >>>> Hi All, >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220250 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.0/ >>>> >>>> Please review a doc fix to fix heading style to improve the >>>> accessibility JDK API documentation of java.desktop module. >>>> >>>> Main approach taken for fixing heading style are: >>>> - headings in documentation comments for modules, packages and >>>> types should start at

- Headings should be hierarchical, and >>>> without ascending gaps, so

should be followed by

,

>>>> should be followed by

or another

Regards Prasanta >>> >>> > From Sergey.Bylokhov at oracle.com Fri Mar 8 22:26:00 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 8 Mar 2019 14:26:00 -0800 Subject: [13] RFR JDK-8220349: The fix done for JDK-8214253 have caused issues in JTree behaviour In-Reply-To: References: Message-ID: Hi, Pankaj. Is it possible at runtime in the test check that the color of the selected node is the same as background? On 08/03/2019 05:50, Pankaj Bansal wrote: > Hi All, > > Please review the following fix. > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8220349 > > webrev > > http://cr.openjdk.java.net/~pbansal/8220349/webrev00/ > > Issue: > > The fix done for JDK-8214253 have caused issues in JTree behaviour. If the JTree node is selected, its background and text color become white and nothing is readable. > > The changes done in gtk3_paint_flat_box for JDK-8214253 have caused this issue as the changes were made for all the widgets. JDK-8214253 is specific to TOOL_TIP. So JDK-8214253 can be fixed by making changes only for TOOL_TIP like done in gtk3_get_color_for_state. The gtk3_paint_flat_box is also called by other widegts like JTree cell rendering and they have been handled well in transform_detail_string. So we don?t want to copy the same code in get_style. > > Fix: > > This patch fixes the issue by making the changes done in gtk3_paint_flat_box specific to TOOL_TIP like were done in gtk3_get_color_for_state > > Testing: > > This fix can be verified by running SwingSet2 and using JTree. I have verified this on Ubuntu 16.04, 18.04, 18.10 and OEL 7.5. > > > Regards, > Pankaj Bansal > -- Best regards, Sergey. From philip.race at oracle.com Sat Mar 9 04:00:01 2019 From: philip.race at oracle.com (Philip Race) Date: Sat, 09 Mar 2019 09:30:01 +0530 Subject: [13] RFR JDK-8220349: The fix done for JDK-8214253 have caused issues in JTree behaviour In-Reply-To: References: Message-ID: <5C833A41.70704@oracle.com> I am unable to test this since I don't have access to suitable systems, but it does look like it should be OK as it reverts the function's behaviour to what it was before 8214253 except for tooltips. -phil. On 3/8/19, 7:20 PM, Pankaj Bansal wrote: > > Hi All, > > Please review the following fix. > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8220349 > > webrev > > http://cr.openjdk.java.net/~pbansal/8220349/webrev00/ > > > Issue: > > The fix done for JDK-8214253 have caused issues in JTree behaviour. If > the JTree node is selected, its background and text color become white > and nothing is readable. > > The changes done in gtk3_paint_flat_box for JDK-8214253 have caused > this issue as the changes were made for all the widgets. JDK-8214253 > is specific to TOOL_TIP. So JDK-8214253 can be fixed by making changes > only for TOOL_TIP like done in gtk3_get_color_for_state. The > gtk3_paint_flat_box is also called by other widegts like JTree cell > rendering and they have been handled well in transform_detail_string. > So we don't want to copy the same code in get_style. > > Fix: > > This patch fixes the issue by making the changes done in > gtk3_paint_flat_box specific to TOOL_TIP like were done in > gtk3_get_color_for_state > > Testing: > > This fix can be verified by running SwingSet2 and using JTree. I have > verified this on Ubuntu 16.04, 18.04, 18.10 and OEL 7.5. > > > Regards, > Pankaj Bansal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Sat Mar 9 09:54:40 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Sat, 9 Mar 2019 15:24:40 +0530 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> <5C81E5D1.8040504@oracle.com> <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> Message-ID: <57966237-35cd-0cde-c195-ed4af73091ee@oracle.com> Thanks Jon for the pointer. I have modified that file http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.2/ Any more comments? Regards Prasanta On 09-Mar-19 2:24 AM, Jonathan Gibbons wrote: > Prasanta, > > You should double check this file: > > http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.1/src/java.desktop/share/classes/javax/print/attribute/package-info.java.udiff.html > > > Previously, it was a mixture of

and

, suggesting that the >

were subheadings of the enclosing logical

section.? Now, you > have changed them all to

, meaning that now they are all > equivalent headings. > > -- Jon > > On 3/8/19 7:09 AM, Prasanta Sadhukhan wrote: >> Hi Phil, >> >> >> On 08-Mar-19 9:17 AM, Philip Race wrote: >>> Apart from making sure all the files are fixed there are two things >>> to look for : >>> >>> 1) If by moving a heading up from H3 to H2 you've now created a >>> similar error >>> because there is now no H3 before an H4. To be sure of this I think >>> you'd >>> need to run Jon's tool - how did you verify it ? >>> >> I missed one case in TextAttribute which I rectified >> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.1/ >> ?It will be good to have Jon's tool so cc-ed him... >>> 2) If in a case like UIManager where you've moved some subsequent >>> headings >>> up from H3 to H2 to match the new size at the reported error site , >>> would it >>> have been better visually to leave them as H3 ? ... probably not .. >>> but if there >>> were generated doc for us to look at posted that would be easier to >>> tell. >> I am using make docs to verify and the docs output can be found at >> http://cr.openjdk.java.net/~psadhukhan/8220250/docs/api/java.desktop/module-summary.html >> >> >> Regards >> Prasanta >>> >>> -phil. >>> >>> On 3/8/19, 3:37 AM, Sergey Bylokhov wrote: >>>> Looks fine. >>>> >>>> On 07/03/2019 03:37, Prasanta Sadhukhan wrote: >>>>> Hi All, >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220250 >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.0/ >>>>> >>>>> Please review a doc fix to fix heading style to improve the >>>>> accessibility JDK API documentation of java.desktop module. >>>>> >>>>> Main approach taken for fixing heading style are: >>>>> - headings in documentation comments for modules, packages and >>>>> types should start at

- Headings should be hierarchical, and >>>>> without ascending gaps, so

should be followed by

,

>>>>> should be followed by

or another

Regards Prasanta >>>> >>>> >> From Sergey.Bylokhov at oracle.com Sun Mar 10 04:00:13 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 9 Mar 2019 20:00:13 -0800 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: <57966237-35cd-0cde-c195-ed4af73091ee@oracle.com> References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> <5C81E5D1.8040504@oracle.com> <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> <57966237-35cd-0cde-c195-ed4af73091ee@oracle.com> Message-ID: When I check the first version, I thought it was intentional change. https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/javax/print/attribute/package-summary.html All of them looks similar headers described something about attributes: 1.

Attribute Roles

2.

Attribute Sets

Why the first uses

and the second uses

? On 09/03/2019 01:54, Prasanta Sadhukhan wrote: > Thanks Jon for the pointer. I have modified that file > > http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.2/ > > Any more comments? > > Regards > Prasanta > On 09-Mar-19 2:24 AM, Jonathan Gibbons wrote: >> Prasanta, >> >> You should double check this file: >> >> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.1/src/java.desktop/share/classes/javax/print/attribute/package-info.java.udiff.html >> >> Previously, it was a mixture of

and

, suggesting that the

were subheadings of the enclosing logical

section.? Now, you have changed them all to

, meaning that now they are all equivalent headings. >> >> -- Jon >> >> On 3/8/19 7:09 AM, Prasanta Sadhukhan wrote: >>> Hi Phil, >>> >>> >>> On 08-Mar-19 9:17 AM, Philip Race wrote: >>>> Apart from making sure all the files are fixed there are two things to look for : >>>> >>>> 1) If by moving a heading up from H3 to H2 you've now created a similar error >>>> because there is now no H3 before an H4. To be sure of this I think you'd >>>> need to run Jon's tool - how did you verify it ? >>>> >>> I missed one case in TextAttribute which I rectified >>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.1/ >>> ?It will be good to have Jon's tool so cc-ed him... >>>> 2) If in a case like UIManager where you've moved some subsequent headings >>>> up from H3 to H2 to match the new size at the reported error site , would it >>>> have been better visually to leave them as H3 ? ... probably not .. but if there >>>> were generated doc for us to look at posted that would be easier to tell. >>> I am using make docs to verify and the docs output can be found at >>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs/api/java.desktop/module-summary.html >>> >>> Regards >>> Prasanta >>>> >>>> -phil. >>>> >>>> On 3/8/19, 3:37 AM, Sergey Bylokhov wrote: >>>>> Looks fine. >>>>> >>>>> On 07/03/2019 03:37, Prasanta Sadhukhan wrote: >>>>>> Hi All, >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220250 >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.0/ >>>>>> >>>>>> Please review a doc fix to fix heading style to improve the accessibility JDK API documentation of java.desktop module. >>>>>> >>>>>> Main approach taken for fixing heading style are: >>>>>> - headings in documentation comments for modules, packages and types should start at

- Headings should be hierarchical, and without ascending gaps, so

should be followed by

,

should be followed by

or another

Regards Prasanta >>>>> >>>>> >>> > -- Best regards, Sergey. From philip.race at oracle.com Sun Mar 10 06:59:26 2019 From: philip.race at oracle.com (Philip Race) Date: Sun, 10 Mar 2019 12:29:26 +0530 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> <5C81E5D1.8040504@oracle.com> <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> <57966237-35cd-0cde-c195-ed4af73091ee@oracle.com> Message-ID: <5C84B5CE.30904@oracle.com> It might have been intentional but I think it is wrong. It is useful to look at the old : https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/module-summary.html and the new : http://cr.openjdk.java.net/~psadhukhan/8220250/docs/api/java.desktop/module-summary.html to compare. What was H3 is in italics and what follows in regular style is intended to be a sub-section. -phil. On 3/10/19, 9:30 AM, Sergey Bylokhov wrote: > When I check the first version, I thought it was intentional change. > > https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/javax/print/attribute/package-summary.html > > > All of them looks similar headers described something about attributes: > 1.

Attribute Roles

> 2.

Attribute Sets

> > Why the first uses

and the second uses

? > > On 09/03/2019 01:54, Prasanta Sadhukhan wrote: >> Thanks Jon for the pointer. I have modified that file >> >> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.2/ >> >> Any more comments? >> >> Regards >> Prasanta >> On 09-Mar-19 2:24 AM, Jonathan Gibbons wrote: >>> Prasanta, >>> >>> You should double check this file: >>> >>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.1/src/java.desktop/share/classes/javax/print/attribute/package-info.java.udiff.html >>> >>> >>> Previously, it was a mixture of

and

, suggesting that the >>>

were subheadings of the enclosing logical

section. Now, >>> you have changed them all to

, meaning that now they are all >>> equivalent headings. >>> >>> -- Jon >>> >>> On 3/8/19 7:09 AM, Prasanta Sadhukhan wrote: >>>> Hi Phil, >>>> >>>> >>>> On 08-Mar-19 9:17 AM, Philip Race wrote: >>>>> Apart from making sure all the files are fixed there are two >>>>> things to look for : >>>>> >>>>> 1) If by moving a heading up from H3 to H2 you've now created a >>>>> similar error >>>>> because there is now no H3 before an H4. To be sure of this I >>>>> think you'd >>>>> need to run Jon's tool - how did you verify it ? >>>>> >>>> I missed one case in TextAttribute which I rectified >>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.1/ >>>> It will be good to have Jon's tool so cc-ed him... >>>>> 2) If in a case like UIManager where you've moved some subsequent >>>>> headings >>>>> up from H3 to H2 to match the new size at the reported error site >>>>> , would it >>>>> have been better visually to leave them as H3 ? ... probably not >>>>> .. but if there >>>>> were generated doc for us to look at posted that would be easier >>>>> to tell. >>>> I am using make docs to verify and the docs output can be found at >>>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs/api/java.desktop/module-summary.html >>>> >>>> >>>> Regards >>>> Prasanta >>>>> >>>>> -phil. >>>>> >>>>> On 3/8/19, 3:37 AM, Sergey Bylokhov wrote: >>>>>> Looks fine. >>>>>> >>>>>> On 07/03/2019 03:37, Prasanta Sadhukhan wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220250 >>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.0/ >>>>>>> >>>>>>> Please review a doc fix to fix heading style to improve the >>>>>>> accessibility JDK API documentation of java.desktop module. >>>>>>> >>>>>>> Main approach taken for fixing heading style are: >>>>>>> - headings in documentation comments for modules, packages and >>>>>>> types should start at

- Headings should be hierarchical, >>>>>>> and without ascending gaps, so

should be followed by

, >>>>>>>

should be followed by

or another

Regards Prasanta >>>>>> >>>>>> >>>> >> > > From jonathan.gibbons at oracle.com Sun Mar 10 15:47:38 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sun, 10 Mar 2019 08:47:38 -0700 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: <5C84B5CE.30904@oracle.com> References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> <5C81E5D1.8040504@oracle.com> <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> <57966237-35cd-0cde-c195-ed4af73091ee@oracle.com> <5C84B5CE.30904@oracle.com> Message-ID: If it helps, I have a utility to extract headers from an API bundle, that can generate a new bundle showing just the headers for each page, and their metadata. I'll run that on the two bundles you list below, and post the new URLs here. -- Jon On 3/9/19 10:59 PM, Philip Race wrote: > It might have been intentional but I think it is wrong. > > It is useful to look at the old : > https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/module-summary.html > > and the new : > http://cr.openjdk.java.net/~psadhukhan/8220250/docs/api/java.desktop/module-summary.html > > > to compare. > > > What was H3 is in italics and what follows in regular style is intended > to be a sub-section. > > -phil. > > On 3/10/19, 9:30 AM, Sergey Bylokhov wrote: >> When I check the first version, I thought it was intentional change. >> >> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/javax/print/attribute/package-summary.html >> >> >> All of them looks similar headers described something about attributes: >> ? 1.

Attribute Roles

>> ? 2.

Attribute Sets

>> >> Why the first uses

and the second uses

? >> >> On 09/03/2019 01:54, Prasanta Sadhukhan wrote: >>> Thanks Jon for the pointer. I have modified that file >>> >>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.2/ >>> >>> Any more comments? >>> >>> Regards >>> Prasanta >>> On 09-Mar-19 2:24 AM, Jonathan Gibbons wrote: >>>> Prasanta, >>>> >>>> You should double check this file: >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.1/src/java.desktop/share/classes/javax/print/attribute/package-info.java.udiff.html >>>> >>>> >>>> Previously, it was a mixture of

and

, suggesting that the >>>>

were subheadings of the enclosing logical

section.? Now, >>>> you have changed them all to

, meaning that now they are all >>>> equivalent headings. >>>> >>>> -- Jon >>>> >>>> On 3/8/19 7:09 AM, Prasanta Sadhukhan wrote: >>>>> Hi Phil, >>>>> >>>>> >>>>> On 08-Mar-19 9:17 AM, Philip Race wrote: >>>>>> Apart from making sure all the files are fixed there are two >>>>>> things to look for : >>>>>> >>>>>> 1) If by moving a heading up from H3 to H2 you've now created a >>>>>> similar error >>>>>> because there is now no H3 before an H4. To be sure of this I >>>>>> think you'd >>>>>> need to run Jon's tool - how did you verify it ? >>>>>> >>>>> I missed one case in TextAttribute which I rectified >>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.1/ >>>>> ?It will be good to have Jon's tool so cc-ed him... >>>>>> 2) If in a case like UIManager where you've moved some subsequent >>>>>> headings >>>>>> up from H3 to H2 to match the new size at the reported error site >>>>>> , would it >>>>>> have been better visually to leave them as H3 ? ... probably not >>>>>> .. but if there >>>>>> were generated doc for us to look at posted that would be easier >>>>>> to tell. >>>>> I am using make docs to verify and the docs output can be found at >>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs/api/java.desktop/module-summary.html >>>>> >>>>> >>>>> Regards >>>>> Prasanta >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 3/8/19, 3:37 AM, Sergey Bylokhov wrote: >>>>>>> Looks fine. >>>>>>> >>>>>>> On 07/03/2019 03:37, Prasanta Sadhukhan wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220250 >>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.0/ >>>>>>>> >>>>>>>> Please review a doc fix to fix heading style to improve the >>>>>>>> accessibility JDK API documentation of java.desktop module. >>>>>>>> >>>>>>>> Main approach taken for fixing heading style are: >>>>>>>> - headings in documentation comments for modules, packages and >>>>>>>> types should start at

- Headings should be hierarchical, >>>>>>>> and without ascending gaps, so

should be followed by

, >>>>>>>>

should be followed by

or another

Regards Prasanta >>>>>>> >>>>>>> >>>>> >>> >> >> From vikrant.v.agarwal at oracle.com Mon Mar 11 05:31:11 2019 From: vikrant.v.agarwal at oracle.com (Vikrant Agarwal) Date: Sun, 10 Mar 2019 22:31:11 -0700 (PDT) Subject: [13] RFR JDK-8219552:bump jtreg requiredVersion to b14 in test/jdk/sanity/client/ In-Reply-To: References: <405D75EB-0AFE-48B2-BB51-46D4FF08F726@oracle.com> <8640c2b4-d863-4d6f-ae8b-3703613ca1b4@default> Message-ID: <68ed91fb-c326-47ed-a1ed-d59eea34f387@default> Gentle Reminder. ? Best Regards, Vikrant ? From: Vikrant Agarwal Sent: Wednesday, March 06, 2019 9:45 AM To: Igor Ignatyev Cc: Aleksandre Iline ; swing-dev at openjdk.java.net Subject: Re: [13] RFR JDK-8219552:bump jtreg requiredVersion to b14 in test/jdk/sanity/client/ ? Hi Igor, ? We are moving exclusiveAccess.dirs to test/jdk/TEST.ROOT to minimize our dependency on ?test/jdk/sanity/client/TEST.properties?, so that we can remove it in the future if screenshots keyword is no longer required. ? Best Regards, Vikrant ? From: Igor Ignatyev Sent: Tuesday, March 05, 2019 10:34 PM To: Vikrant Agarwal Cc: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Aleksandre Iline ; Muneer Kolarkunnu ; Sergey Bylokhov Subject: Re: [13] RFR JDK-8219552:bump jtreg requiredVersion to b14 in test/jdk/sanity/client/ ? Hi Vikrant, ? although I still don't understand why we are moving exclusiveAccess.dirs to test/jdk/TEST.ROOT, I'm fine w/ the patch. ? Cheers, -- Igor ? On Mar 5, 2019, at 2:18 AM, Vikrant Agarwal wrote: ? Hi Igor, ? Here is the updated webrev:?http://cr.openjdk.java.net/~vagarwal/8219552/webrev.3/ ? Summary of changes made: Removed requiredVersion from TEST.properties and README Removed 'test/jdk/sanity/client/TEST.ROOT.template' as it is not being used. It is not necessary for all keywords to be? under TEST.ROOT file. Right now test ButtonDemoScreenshotTest.java runs without any errors and if we remove 'screenshots' keyword from TEST.properties file it throws??Error. Parse Exception: Invalid key: screenshots?exception. So keeping the TEST.properties file. Added "sanity/client" under exclusiveAccess.dirs to test/jdk/TEST.ROOT and removed exclusiveAccess.dirs ?from ?test/jdk/sanity/client/TEST.properties? Removed "intermittent" keyword from ButtonDemoScreenshotTest, because intermittent issue is resolved by JDK-8157338 Added "screenshots" keyword to EditorPaneDemoTest as this test also has screenshot tests. Added GPL legal notice in TEST.properties file ? Best Regards, Vikrant ? From:?Igor Ignatyev? Sent:?Friday, February 22, 2019 11:35 PM To:?Vikrant Agarwal Cc:?HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Aleksandre Iline ; Muneer Kolarkunnu Subject:?Re: [13] RFR JDK-8219552:bump jtreg requiredVersion to b14 in test/jdk/sanity/client/ ? Hi?Vikrant. ? could you please explain how 'test/jdk/sanity/client/TEST.ROOT.template' is used? if it's not used at all, I'd prefer to delete this file for good.? ? I also have kinda same question to 'TEST.properties' file. AFAIR jtreg doesn't extending 'keys' in 'TEST.properties' files, which means all keywords must be listed in 'TEST.ROOT' file, and using of any other unregistered keywords leads to 'Error. Parse Exception: Invalid key: ...'. ?'screenshots' isn't registered in test/jdk/TEST.ROOT, having it in 'test/jdk/sanity/client/TEST.properties' has no effect, so 'test/jdk/sanity/client/SwingSet/src/ButtonDemoScreenshotTest.java' (the only test w/ screenshots) can't be executed and will always fail w/ error status. so I'm wondering if you doing something w/ test/jdk/sanity/client/ before running these tests. ? Thanks, -- Igor On Feb 21, 2019, at 9:56 PM, Vikrant Agarwal wrote: ? Hi All, Please review this small fix for?HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8219552"JDK-8219552: ? Bug:?https://bugs.openjdk.java.net/browse/JDK-8219552 Webrev:?http://cr.openjdk.java.net/~vagarwal/8219552/webrev.0/ Summary: Removed jtreg requiredVersion field from files in test/jdk/sanity/client/ as it is redundant because jtreg requiredVersion is specified in test/jdk/TEST.ROOT which is being updated by?HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8219417"JDK-8219417 Best Regards, Vikrant ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Mar 11 06:44:03 2019 From: philip.race at oracle.com (Philip Race) Date: Mon, 11 Mar 2019 12:14:03 +0530 Subject: [13] RFR JDK-8219552:bump jtreg requiredVersion to b14 in test/jdk/sanity/client/ In-Reply-To: <68ed91fb-c326-47ed-a1ed-d59eea34f387@default> References: <405D75EB-0AFE-48B2-BB51-46D4FF08F726@oracle.com> <8640c2b4-d863-4d6f-ae8b-3703613ca1b4@default> <68ed91fb-c326-47ed-a1ed-d59eea34f387@default> Message-ID: <5C8603B3.9000907@oracle.com> This all looks OK to me. -phil. On 3/11/19, 11:01 AM, Vikrant Agarwal wrote: > > Gentle Reminder. > > Best Regards, > > Vikrant > > *From:* Vikrant Agarwal > *Sent:* Wednesday, March 06, 2019 9:45 AM > *To:* Igor Ignatyev > *Cc:* Aleksandre Iline ; > swing-dev at openjdk.java.net > *Subject:* Re: [13] RFR JDK-8219552:bump jtreg > requiredVersion to b14 in test/jdk/sanity/client/ > > Hi Igor, > > We are moving exclusiveAccess.dirs to test/jdk/TEST.ROOT to minimize > our dependency on ?test/jdk/sanity/client/TEST.properties?, so that we > can remove it in the future if screenshots keyword is no longer required. > > Best Regards, > > Vikrant > > *From:* Igor Ignatyev > *Sent:* Tuesday, March 05, 2019 10:34 PM > *To:* Vikrant Agarwal > > *Cc:* swing-dev at openjdk.java.net ; > Aleksandre Iline >; Muneer Kolarkunnu > >; > Sergey Bylokhov > > *Subject:* Re: [13] RFR JDK-8219552:bump jtreg > requiredVersion to b14 in test/jdk/sanity/client/ > > Hi Vikrant, > > although I still don't understand why we are moving > exclusiveAccess.dirs to test/jdk/TEST.ROOT, I'm fine w/ the patch. > > Cheers, > > -- Igor > > On Mar 5, 2019, at 2:18 AM, Vikrant Agarwal > > wrote: > > Hi Igor, > > Here is the updated > webrev:http://cr.openjdk.java.net/~vagarwal/8219552/webrev.3/ > > > Summary of changes made: > > 1. Removed requiredVersion from TEST.properties and README > 2. Removed 'test/jdk/sanity/client/TEST.ROOT.template' as it is > not being used. > 3. It is not necessary for all keywords to be under TEST.ROOT > file. Right now test ButtonDemoScreenshotTest.java runs > without any errors and if we remove 'screenshots' keyword from > TEST.properties file it throws/?Error. Parse Exception: > Invalid key: screenshots?/exception. So keeping the > TEST.properties file. > 4. Added "sanity/client" under exclusiveAccess.dirs to > test/jdk/TEST.ROOT and removed exclusiveAccess.dirs from > ?test/jdk/sanity/client/TEST.properties? > 5. Removed "intermittent" keyword from ButtonDemoScreenshotTest, > because intermittent issue is resolved by JDK-8157338 > 6. Added "screenshots" keyword to EditorPaneDemoTest as this test > also has screenshot tests. > 7. Added GPL legal notice in TEST.properties file > > Best Regards, > > Vikrant > > *From:*Igor Ignatyev > *Sent:*Friday, February 22, 2019 11:35 PM > *To:*Vikrant Agarwal > > *Cc:*swing-dev at openjdk.java.net > ; Aleksandre Iline > >; > Muneer Kolarkunnu > > *Subject:*Re: [13] RFR JDK-8219552:bump jtreg > requiredVersion to b14 in test/jdk/sanity/client/ > > Hi Vikrant. > > could you please explain how > 'test/jdk/sanity/client/TEST.ROOT.template' is used? if it's not > used at all, I'd prefer to delete this file for good. > > I also have kinda same question to 'TEST.properties' file. AFAIR > jtreg doesn't extending 'keys' in 'TEST.properties' files, which > means all keywords must be listed in 'TEST.ROOT' file, and using > of any other unregistered keywords leads to 'Error. Parse > Exception: Invalid key: ...'. 'screenshots' isn't registered in > test/jdk/TEST.ROOT, having it in > 'test/jdk/sanity/client/TEST.properties' has no effect, so > 'test/jdk/sanity/client/SwingSet/src/ButtonDemoScreenshotTest.java' (the > only test w/ screenshots) can't be executed and will always fail > w/ error status. so I'm wondering if you doing something w/ > test/jdk/sanity/client/ before running these tests. > > Thanks, > > -- Igor > > > > On Feb 21, 2019, at 9:56 PM, Vikrant Agarwal > > wrote: > > Hi All, > > Please review this small fix forJDK-8219552 > : > > Bug:https://bugs.openjdk.java.net/browse/JDK-8219552 > > Webrev:http://cr.openjdk.java.net/~vagarwal/8219552/webrev.0/ > > > Summary: Removed jtreg requiredVersion field from files in > test/jdk/sanity/client/ as it is redundant because jtreg > requiredVersion is specified in test/jdk/TEST.ROOT which is > being updated byJDK-8219417 > > > Best Regards, > > Vikrant > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Mar 11 08:46:09 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 11 Mar 2019 14:16:09 +0530 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> <5C81E5D1.8040504@oracle.com> <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> <57966237-35cd-0cde-c195-ed4af73091ee@oracle.com> <5C84B5CE.30904@oracle.com> Message-ID: The 2nd URL is based on webrev.1. I have placed new docs for webrev.2 here http://cr.openjdk.java.net/~psadhukhan/8220250/docs.webrev2/docs/api/java.desktop/module-summary.html Regards Prasanta On 10-Mar-19 9:17 PM, Jonathan Gibbons wrote: > If it helps, I have a utility to extract headers from an API bundle, > that can generate a new bundle showing just the headers for each page, > and their metadata. I'll run that on the two bundles you list below, > and post the new URLs here. > > -- Jon > > On 3/9/19 10:59 PM, Philip Race wrote: >> It might have been intentional but I think it is wrong. >> >> It is useful to look at the old : >> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/module-summary.html >> >> and the new : >> http://cr.openjdk.java.net/~psadhukhan/8220250/docs/api/java.desktop/module-summary.html >> >> >> to compare. >> >> >> What was H3 is in italics and what follows in regular style is intended >> to be a sub-section. >> >> -phil. >> >> On 3/10/19, 9:30 AM, Sergey Bylokhov wrote: >>> When I check the first version, I thought it was intentional change. >>> >>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/javax/print/attribute/package-summary.html >>> >>> >>> All of them looks similar headers described something about attributes: >>> ? 1.

Attribute Roles

>>> ? 2.

Attribute Sets

>>> >>> Why the first uses

and the second uses

? >>> >>> On 09/03/2019 01:54, Prasanta Sadhukhan wrote: >>>> Thanks Jon for the pointer. I have modified that file >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.2/ >>>> >>>> Any more comments? >>>> >>>> Regards >>>> Prasanta >>>> On 09-Mar-19 2:24 AM, Jonathan Gibbons wrote: >>>>> Prasanta, >>>>> >>>>> You should double check this file: >>>>> >>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.1/src/java.desktop/share/classes/javax/print/attribute/package-info.java.udiff.html >>>>> >>>>> >>>>> Previously, it was a mixture of

and

, suggesting that the >>>>>

were subheadings of the enclosing logical

section.? Now, >>>>> you have changed them all to

, meaning that now they are all >>>>> equivalent headings. >>>>> >>>>> -- Jon >>>>> >>>>> On 3/8/19 7:09 AM, Prasanta Sadhukhan wrote: >>>>>> Hi Phil, >>>>>> >>>>>> >>>>>> On 08-Mar-19 9:17 AM, Philip Race wrote: >>>>>>> Apart from making sure all the files are fixed there are two >>>>>>> things to look for : >>>>>>> >>>>>>> 1) If by moving a heading up from H3 to H2 you've now created a >>>>>>> similar error >>>>>>> because there is now no H3 before an H4. To be sure of this I >>>>>>> think you'd >>>>>>> need to run Jon's tool - how did you verify it ? >>>>>>> >>>>>> I missed one case in TextAttribute which I rectified >>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.1/ >>>>>> ?It will be good to have Jon's tool so cc-ed him... >>>>>>> 2) If in a case like UIManager where you've moved some >>>>>>> subsequent headings >>>>>>> up from H3 to H2 to match the new size at the reported error >>>>>>> site , would it >>>>>>> have been better visually to leave them as H3 ? ... probably not >>>>>>> .. but if there >>>>>>> were generated doc for us to look at posted that would be easier >>>>>>> to tell. >>>>>> I am using make docs to verify and the docs output can be found at >>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs/api/java.desktop/module-summary.html >>>>>> >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 3/8/19, 3:37 AM, Sergey Bylokhov wrote: >>>>>>>> Looks fine. >>>>>>>> >>>>>>>> On 07/03/2019 03:37, Prasanta Sadhukhan wrote: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220250 >>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.0/ >>>>>>>>> >>>>>>>>> Please review a doc fix to fix heading style to improve the >>>>>>>>> accessibility JDK API documentation of java.desktop module. >>>>>>>>> >>>>>>>>> Main approach taken for fixing heading style are: >>>>>>>>> - headings in documentation comments for modules, packages and >>>>>>>>> types should start at

- Headings should be hierarchical, >>>>>>>>> and without ascending gaps, so

should be followed by >>>>>>>>>

,

should be followed by

or another

Regards >>>>>>>>> Prasanta >>>>>>>> >>>>>>>> >>>>>> >>>> >>> >>> From manajit.halder at oracle.com Mon Mar 11 08:55:10 2019 From: manajit.halder at oracle.com (Manajit Halder) Date: Mon, 11 Mar 2019 14:25:10 +0530 Subject: [13] Review request for JDK-8216971: [macosx swing] For JCheckBoxMenuItem actionPerformed() is called twice, when apple.laf.useScreenMenuBar=true and modifier is InputEvent.META_DOWN_MASK In-Reply-To: References: <52287ED0-64B7-4586-9D2F-F3912EE4057A@oracle.com> Message-ID: <72180FB8-168D-419D-A357-C75D7BF4E3D4@oracle.com> Hi Krishna, Thanks for the review comment. The key mapping is done by method setKeyEquivalent on fMenuItem (object of the NSMenuItem) in the same file. As discussed with you, the second key event is the problem here, and is caused only when System property ?apple.laf.useScreenMenuBar? is set to true. The extra event is generated in the handleAction method and my proposed fix is solving this issue. The difference with other look and feel setting or when ?apple.laf.useScreenMenuBar? is set to ?false? is that handleAction method is not called. I have verified and found that the META_MASK and CTRL_MASK are only set when ?apple.laf.useScreenMenuBar? is set to true and not in case of it is false. Also verified with ?metal? look and feel and found the MASKS are not set and handleAction method is not called and hence the extra key event is not generated. Please let me know if you have any other query. Regards, Manajit > On 05-Mar-2019, at 4:52 PM, Krishna Addepalli wrote: > > Hi Manajit, > > Per our discussion, The cause of the problem is : 1), Key Event being sent from the OS to the application - which the Java layer processes it correctly > 2) The Mac OS calling the handleAction function directly on the NSMenutItem - although as per your description, there is no code which maps the hot key to this widget in the native layer. > Ideally, since the OS is recognising the key combination, that key event should not be delivered again to the application. Or, it should be that the key event is not recognised and hence delivered to the application. > > Can you check why in this case, we are getting the key event as well as the handleAction from the OS? > > Thanks, > Krishna > >> On 23-Feb-2019, at 9:14 PM, Manajit Halder > wrote: >> >> Hi All, >> >> Please review the fix for JDK13. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8216971 >> >> Webrev: >> http://cr.openjdk.java.net/~mhalder/8216971/webrev.00/ >> >> Fix: >> actionPerformed() was called twice due to wrong handling of key down event in method handleAction, which is corrected with this fix. >> This change was added during fix of issue JDK-8152492. Apart from the changes required to fix the problem, code related to finding out >> eventKey is removed as eventKey is no more used now. >> >> Note: >> This issue is regression of bug 8152492, which was introduced in JDK release 9b120. >> >> Regards, >> Manajit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pankaj.b.bansal at oracle.com Mon Mar 11 12:25:50 2019 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Mon, 11 Mar 2019 05:25:50 -0700 (PDT) Subject: [13] RFR JDK-8220349: The fix done for JDK-8214253 have caused issues in JTree behaviour In-Reply-To: References: Message-ID: Thanks for review Sergey and Phil. << Is it possible at runtime in the test check that the color of the selected node is the same as background? I am not able to find a way to write an automated test case for this. I can write a Manual test but don't know how much that will help as SwingSet2 can also be used to verify this. Please let me know your thoughts on this. -Pankaj -----Original Message----- From: Sergey Bylokhov Sent: Saturday, March 9, 2019 3:56 AM To: Pankaj Bansal; swing-dev at openjdk.java.net Subject: Re: [13] RFR JDK-8220349: The fix done for JDK-8214253 have caused issues in JTree behaviour Hi, Pankaj. Is it possible at runtime in the test check that the color of the selected node is the same as background? On 08/03/2019 05:50, Pankaj Bansal wrote: > Hi All, > > Please review the following fix. > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8220349 > > webrev > > http://cr.openjdk.java.net/~pbansal/8220349/webrev00/ > > Issue: > > The fix done for JDK-8214253 have caused issues in JTree behaviour. If the JTree node is selected, its background and text color become white and nothing is readable. > > The changes done in gtk3_paint_flat_box for JDK-8214253 have caused this issue as the changes were made for all the widgets. JDK-8214253 is specific to TOOL_TIP. So JDK-8214253 can be fixed by making changes only for TOOL_TIP like done in gtk3_get_color_for_state. The gtk3_paint_flat_box is also called by other widegts like JTree cell rendering and they have been handled well in transform_detail_string. So we don't want to copy the same code in get_style. > > Fix: > > This patch fixes the issue by making the changes done in gtk3_paint_flat_box specific to TOOL_TIP like were done in gtk3_get_color_for_state > > Testing: > > This fix can be verified by running SwingSet2 and using JTree. I have verified this on Ubuntu 16.04, 18.04, 18.10 and OEL 7.5. > > > Regards, > Pankaj Bansal > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Mar 12 00:16:06 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 11 Mar 2019 17:16:06 -0700 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: <5C84B5CE.30904@oracle.com> References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> <5C81E5D1.8040504@oracle.com> <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> <57966237-35cd-0cde-c195-ed4af73091ee@oracle.com> <5C84B5CE.30904@oracle.com> Message-ID: <133236ed-1cf6-3677-c563-b6f447484669@oracle.com> On 09/03/2019 22:59, Philip Race wrote: > > What was H3 is in italics and what follows in regular style is intended > to be a sub-section. It is unclear why "Attribute Categories and Values" and "Attribute Roles" is a sub-section of "What is an Attribute?", while all other stuff is not. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Mar 12 00:18:23 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 11 Mar 2019 17:18:23 -0700 Subject: [13] RFR JDK-8220349: The fix done for JDK-8214253 have caused issues in JTree behaviour In-Reply-To: References: Message-ID: <310c124a-02b6-7c33-eec0-95424cebe200@oracle.com> Hi, Pankaj. I guess this color is depend on L&F, so it should be stored somewhere in the UIDefaults. On 11/03/2019 05:25, Pankaj Bansal wrote: > Thanks for review Sergey and Phil. > > << Is it possible at runtime in the test check that the color of the selected node is the same as background? > I am not able to find a way to write an automated test case for this. I can write a Manual test but don't know how much that will help as SwingSet2 can also be used to verify this. Please let me know your thoughts on this. > > -Pankaj > > > -----Original Message----- > From: Sergey Bylokhov > Sent: Saturday, March 9, 2019 3:56 AM > To: Pankaj Bansal; swing-dev at openjdk.java.net > Subject: Re: [13] RFR JDK-8220349: The fix done for JDK-8214253 have caused issues in JTree behaviour > > Hi, Pankaj. > > Is it possible at runtime in the test check that the color of the selected node is the same as background? > > On 08/03/2019 05:50, Pankaj Bansal wrote: >> Hi All, >> >> Please review the following fix. >> >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8220349 >> >> webrev >> >> http://cr.openjdk.java.net/~pbansal/8220349/webrev00/ >> >> Issue: >> >> The fix done for JDK-8214253 have caused issues in JTree behaviour. If the JTree node is selected, its background and text color become white and nothing is readable. >> >> The changes done in gtk3_paint_flat_box for JDK-8214253 have caused this issue as the changes were made for all the widgets. JDK-8214253 is specific to TOOL_TIP. So JDK-8214253 can be fixed by making changes only for TOOL_TIP like done in gtk3_get_color_for_state. The gtk3_paint_flat_box is also called by other widegts like JTree cell rendering and they have been handled well in transform_detail_string. So we don't want to copy the same code in get_style. >> >> Fix: >> >> This patch fixes the issue by making the changes done in gtk3_paint_flat_box specific to TOOL_TIP like were done in gtk3_get_color_for_state >> >> Testing: >> >> This fix can be verified by running SwingSet2 and using JTree. I have verified this on Ubuntu 16.04, 18.04, 18.10 and OEL 7.5. >> >> >> Regards, >> Pankaj Bansal >> > > -- Best regards, Sergey. From philip.race at oracle.com Tue Mar 12 00:42:33 2019 From: philip.race at oracle.com (Philip Race) Date: Tue, 12 Mar 2019 06:12:33 +0530 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: <133236ed-1cf6-3677-c563-b6f447484669@oracle.com> References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> <5C81E5D1.8040504@oracle.com> <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> <57966237-35cd-0cde-c195-ed4af73091ee@oracle.com> <5C84B5CE.30904@oracle.com> <133236ed-1cf6-3677-c563-b6f447484669@oracle.com> Message-ID: <5C870079.5030701@oracle.com> What can I say ? It is clear enough to me .. "What is an Attribute" is the intro/preamble/overview and the two subsections get into the specifics of how an attribute is used by the API. After that we move on to the next topic of Attribute Sets .. -phil. On 3/12/19, 5:46 AM, Sergey Bylokhov wrote: > On 09/03/2019 22:59, Philip Race wrote: >> >> What was H3 is in italics and what follows in regular style is intended >> to be a sub-section. > > It is unclear why "Attribute Categories and Values" and "Attribute > Roles" is a sub-section of "What is an Attribute?", while all other > stuff is not. > From Sergey.Bylokhov at oracle.com Tue Mar 12 01:39:11 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 11 Mar 2019 18:39:11 -0700 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: <5C870079.5030701@oracle.com> References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> <5C81E5D1.8040504@oracle.com> <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> <57966237-35cd-0cde-c195-ed4af73091ee@oracle.com> <5C84B5CE.30904@oracle.com> <133236ed-1cf6-3677-c563-b6f447484669@oracle.com> <5C870079.5030701@oracle.com> Message-ID: <7a137828-5941-e8b6-57ae-6506fed87c95@oracle.com> On 11/03/2019 17:42, Philip Race wrote: > What can I say ? It is clear enough to me .. > "What is an Attribute" is the intro/preamble/overview? and the two subsections > get into the specifics of how an attribute is used by the API. > > After that we move on to the next topic of Attribute Sets .. And "Attribute Class Design" is also separate topic and not a "specifics of how an attribute is used by the API"? Not an expert here, but it looks like "What is an Attribute" is the intro/preamble/overview of the whole page, and other topics describes some specific aspects of the attrubutes, like roles, categories, values, sets, vendors, examples, But it is up to you on how it should look. > > -phil. > > On 3/12/19, 5:46 AM, Sergey Bylokhov wrote: >> On 09/03/2019 22:59, Philip Race wrote: >>> >>> What was H3 is in italics and what follows in regular style is intended >>> to be a sub-section. >> >> It is unclear why "Attribute Categories and Values" and "Attribute Roles" is a sub-section of "What is an Attribute?", while all other stuff is not. >> -- Best regards, Sergey. From vikrant.v.agarwal at oracle.com Tue Mar 12 06:08:39 2019 From: vikrant.v.agarwal at oracle.com (Vikrant Agarwal) Date: Tue, 12 Mar 2019 06:08:39 +0000 (UTC) Subject: [13] RFR JDK-8216353:Use utility APIs introduced in org/netbeans/jemmy/util/LookAndFeel class in client sanity test cases Message-ID: Hi All, Please review this fix for HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8216353"JDK-8216353: Bug: https://bugs.openjdk.java.net/browse/JDK-8216353 Webrev: http://cr.openjdk.java.net/~vagarwal/8216353/webrev.1/ Summary: The new Jemmy utility class (LookAndFeel.java) and other jemmy changes have already been committed to Jemmy Codetools repo and have been added here as is. Sanity tests have been updated to use this new utility class. Best Regards, Vikrant -------------- next part -------------- An HTML attachment was scrubbed... URL: From shashidhara.veerabhadraiah at oracle.com Tue Mar 12 08:36:55 2019 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Tue, 12 Mar 2019 01:36:55 -0700 (PDT) Subject: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash In-Reply-To: <606ce427-71da-8bdb-7726-5334ab3d3399@oracle.com> References: <86dc6276-6a1c-4d09-8155-705fea8fd95e@default> <9149f70d-5265-efb1-e496-48e159e61e92@oracle.com> <554176f6-b538-46b5-97bb-14e488f50656@default> <5C5DEB0E.5010405@oracle.com> <23625b97-76d0-4956-8d4b-bf1add82ceb1@default> <1d4ad24a-e6bf-8e71-c88c-020e1106f089@oracle.com> <8634f5a6-a0a6-5739-9fd6-9a304a4a97f3@oracle.com> <70c695de-a54e-4aad-ae7b-0e11a6b9054e@default> <5C7FFF71.1020809@oracle.com> <88e0e602-7b4e-443d-95fe-a7fe288fa161@default> <5C82100D.8030106@oracle.com> <606ce427-71da-8bdb-7726-5334ab3d3399@oracle.com> Message-ID: <36db56a3-b0c1-4509-a65d-f6d198e34e73@default> Hi Joe, Thank you for that good suggestion. I have incorporated the same and here is the new Webrev: ? http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.10/ ? Thanks and regards, Shashi ? From: Joe Darcy Sent: Friday, March 8, 2019 2:42 PM To: Shashidhara Veerabhadraiah ; Philip Race Cc: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hello, I strongly recommend using ??? String.strip rather than ??? String.trim as Strim.trim uses a idosyncratic definition of whitespace whereas the new-in-11 String.strip uses a conventional definition of white space. Likewise, I recommend linking "white space" to the definition of white space used by Character.isWhitespace. Thanks, -Joe On 3/7/2019 10:56 PM, Shashidhara Veerabhadraiah wrote: Thank you Phil. Sure will wait till CSR is approved. ? Thanks and regards, shashi ? From: Philip Race Sent: Friday, March 8, 2019 12:18 PM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Joe Darcy HYPERLINK "mailto:joe.darcy at oracle.com"; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Ok but you need to wait for the CSR to be approved before you can push. -phil. On 3/8/19, 11:41 AM, Shashidhara Veerabhadraiah wrote: Hi Phil, As discussed here are the updates for the Webrev. Hopefully this is correct. ? HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.09/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.09/ ? Thanks and regards, Shashi ? From: Shashidhara Veerabhadraiah Sent: Friday, March 8, 2019 10:33 AM To: Philip Race HYPERLINK "mailto:philip.race at oracle.com" Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Joe Darcy HYPERLINK "mailto:joe.darcy at oracle.com"; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Thank you Phil for the review and here are the updates done: ? HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.08/"http://cr.openjdk.java.net/~sveerabhadra/8216008//webrev.08/ ? Thanks and regards, Shashi ? From: Philip Race Sent: Wednesday, March 6, 2019 10:42 PM To: Shashidhara Veerabhadraiah Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Joe Darcy Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? the webrev needs a couple of minor tweaks : ? contains empty string -> is the empty string ? and ? immeadiately -> immediately Go ahead and finalize the CSR which looks OK. -phil. On 3/6/19, 11:45 AM, Shashidhara Veerabhadraiah wrote: Hi Phil\Sergey, Please review the CSR along with the bug fix. ? Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.07/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/ ? CSR: https://bugs.openjdk.java.net/browse/JDK-8218737 ? Bug: https://bugs.openjdk.java.net/browse/JDK-8216008 ? Thanks and regards, Shashi ? From: Shashidhara Veerabhadraiah Sent: Monday, March 4, 2019 3:36 PM To: Philip Race HYPERLINK "mailto:philip.race at oracle.com"; Joe Darcy HYPERLINK "mailto:joe.darcy at oracle.com" Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi Joe, Please find the updated Webrev fixing the typo: ? HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.07/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.07/ ? Thanks and regards, Shashi ? From: Shashidhara Veerabhadraiah Sent: Thursday, February 21, 2019 2:08 PM To: Philip Race ; Joe Darcy Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi Joe, Please find the new Webrev fixing the specification as asked in the CSR bug: https://bugs.openjdk.java.net/browse/JDK-8218737 ? Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.06/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.06/ ? Thanks and regards, Shashi ? From: Shashidhara Veerabhadraiah Sent: Monday, February 18, 2019 10:19 AM To: Philip Race Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Thank you Phil for that help on CSR. ? From: Phil Race Sent: Friday, February 15, 2019 9:41 PM To: Shashidhara Veerabhadraiah Cc: Sergey Bylokhov ; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? That text may actually be worse. Although I maybe didn't get your distinction of null vs the empty string here ? Oh, wait. Why is this doc clarification on the PRIVATE implementation method ? It needs to go on the public getDefaultToolkit() method to have any point whatsoever especially from a CSR perspective. Try this : -???? * toolkit is created. All errors are handled via an AWTError exception. +???? * toolkit is created. +???? * If the list of assistive technology providers is the empty string, or +???? * contains only white space characters then the method returns immediately. +???? * All other errors are handled via an AWTError exception. I think the CSR needs some work too. I've made some updates there. -phil. On 2/15/19 2:10 AM, Shashidhara Veerabhadraiah wrote: Hi Phil, I have updated the CSR and updated the information for the function and here is the new Webrev: ? HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.05/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.05/ Thanks and regards, Shashi ? From: Phil Race Sent: Friday, February 15, 2019 2:58 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? +???? * activate method.? If the list of assistive technology providers is empty string, ? is "the" empty string. ? ? The CSR needs to be updated to include this spec. What is there now in the specification section needs to be fixed It should not point to the webrev or review and right now doesn't contain the change to the javadoc in the body of the CSR ? I think I even have to question most of the rest of it. Any one reading it would think that we always used to throw an exception in such case and now want to stop doing so. Isn't the bug that we did NOT throw an exception and now we do ? You only hint at that when you say at the end of "Solution", "as was the case earlier" ? If I am right the only thing you need in the CSR is to say that you are reverting the implementation to previous behaviour and updating the specification to make it clear that this behaviour is allowed by the spec since this case was unclear. ? -phil. ? On 2/12/19 1:08 AM, Shashidhara Veerabhadraiah wrote: Hi Phil, Here is the new Webrev and CSR for the same: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.04/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.04/ ? CSR: https://bugs.openjdk.java.net/browse/JDK-8218737 ? Thanks and regards, Shashi ? From: Philip Race Sent: Saturday, February 9, 2019 2:18 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" Cc: Sergey Bylokhov HYPERLINK "mailto:sergey.bylokhov at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? FWIW I think this could be closed out as "not a bug". An empty value string is an error and the spec. says AWTError is how errors are reported. In fact I'll argue that 8 was wrong not to have thrown an exception in such a case. It was an accident of the implementation that it did not. But if we want to be behaviourally compatible then ... Note that since you now document this you need an approved CSR BEFORE pushing it. And if you go the CSR route you may need to be more precise about what you mean by "empty". I think it needs to say "If the list of assistive technology providers is null, or contains only white space characters then the method returns immediately. All other errors are handled by throwing {@code AWTError}" @throws AWTError if there is any error in parsing or loading the ATs. -phil. On 1/21/19, 9:12 AM, Shashidhara Veerabhadraiah wrote: Hi Sergey, Here is the new Webrev for your comments: ? HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.02/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.02/ ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Saturday, January 19, 2019 3:47 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? On 16/01/2019 23:03, HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote: Another point is that the whitespace trimming should not trigger additional input processing? for the custom class that will be used for assistive technology. For eg., if custom class "FooProvider" is implemented and if we pass "? FooProvider? " by mistake, a bug may be created to trim the whitespace in this case as well!! ? Yes, my previous email suggested to always trim the content of the "input", it will cover all cases, the "atNames" is empty, the "atNames" contains only the whitespace, or the name of the class has some spaces at the start/end. ? ? Thanks and regards, ? Shashi ? ? On 17/01/19 10:28 AM, Shashidhara Veerabhadraiah wrote: We need one way to tell the system not to load any assistive technologies and which is being provided. If we add trailing white spaces removal then we may need to add another functionality to see if that class exists or not and based on that not to load anything(without throwing the error because we are parsing the input content). I think that would take a different direction. I feel it is fair enough to provide one way to tell not to load any assistive technologies and additional parsing would only lead to other ways/expectations. ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Thursday, January 17, 2019 1:33 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? I guess you meant whitespaces, then it is unclear why we should not consider "empty" parameter as a "mistake"? ? On 15/01/2019 20:37, Shashidhara Veerabhadraiah wrote: Hi Sergey, I felt that a string with an empty space is intentional and should be considering it as a 'mistake' if done by the developers. Hence I feel it is not required(as there is a way to tell nothing to load). Please let me know if you think otherwise. ? ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, January 15, 2019 7:32 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi, Shashi. ? Should we trim all whitespaces from the "atNames"? Otherwise the "atNames", which contains only one whitespace, will trigger the same error. ? On 09/01/2019 00:20, Shashidhara Veerabhadraiah wrote: Hi Sergey, Thanks for pointing that out. Here is the new Webrev: ? HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.01/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.01/ ? Thanks and regards, Shashi ? -----Original Message----- From: Sergey Bylokhov Sent: Friday, January 4, 2019 3:48 AM To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash ? Hi, Shashi. I think you can update an existing test: open/test/jdk/javax/accessibility/AccessibilityProvider/basic.sh ? On 03/01/2019 01:36, Shashidhara Veerabhadraiah wrote: Hi All, Please review a fix for the below bug. ? Bug: https://bugs.openjdk.java.net/browse/JDK-8216008 ? Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8216008/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8216008/webrev.00/ ? Since the mentioned list of assistive technologies for the system property(javax.accessibility.assistive_technologies) is loaded by jvm am unable to write a test case for this bug. The test file attached with the bug can be used for testing this fix. ? This fix removes the error(class not found error) by passing an empty list to system variable javax.accessibility.assistive_technologies and does not load any assistive technologies(as the list is empty). Currently empty list produce a crash which is not required as there was no class name mentioned in the list. Please read the bug comments for more information. ? Thanks and regards, ? Shashi ? ? ? ? ? ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishna.addepalli at oracle.com Tue Mar 12 09:46:32 2019 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Tue, 12 Mar 2019 15:16:32 +0530 Subject: [13] Review request for JDK-8216971: [macosx swing] For JCheckBoxMenuItem actionPerformed() is called twice, when apple.laf.useScreenMenuBar=true and modifier is InputEvent.META_DOWN_MASK In-Reply-To: <72180FB8-168D-419D-A357-C75D7BF4E3D4@oracle.com> References: <52287ED0-64B7-4586-9D2F-F3912EE4057A@oracle.com> <72180FB8-168D-419D-A357-C75D7BF4E3D4@oracle.com> Message-ID: <29C7954A-4551-461E-825D-A87074612761@oracle.com> Hi Manajit, Thanks for the clarification. I think you should add some more comments around the statement at line86, to explain in more detail, about why to ignore this call. Thanks, Krishna > On 11-Mar-2019, at 2:25 PM, Manajit Halder wrote: > > Hi Krishna, > > Thanks for the review comment. > > The key mapping is done by method setKeyEquivalent on fMenuItem (object of the NSMenuItem) in the same file. > > As discussed with you, the second key event is the problem here, and is caused only when System property ?apple.laf.useScreenMenuBar? is set to true. The extra event is generated in the handleAction method and my proposed fix is solving this issue. The difference with other look and feel setting or when ?apple.laf.useScreenMenuBar? is set to ?false? is that handleAction method is not called. I have verified and found that the META_MASK and CTRL_MASK are only set when ?apple.laf.useScreenMenuBar? is set to true and not in case of it is false. Also verified with ?metal? look and feel and found the MASKS are not set and handleAction method is not called and hence the extra key event is not generated. > > Please let me know if you have any other query. > > Regards, > Manajit > > > >> On 05-Mar-2019, at 4:52 PM, Krishna Addepalli > wrote: >> >> Hi Manajit, >> >> Per our discussion, The cause of the problem is : 1), Key Event being sent from the OS to the application - which the Java layer processes it correctly >> 2) The Mac OS calling the handleAction function directly on the NSMenutItem - although as per your description, there is no code which maps the hot key to this widget in the native layer. >> Ideally, since the OS is recognising the key combination, that key event should not be delivered again to the application. Or, it should be that the key event is not recognised and hence delivered to the application. >> >> Can you check why in this case, we are getting the key event as well as the handleAction from the OS? >> >> Thanks, >> Krishna >> >>> On 23-Feb-2019, at 9:14 PM, Manajit Halder > wrote: >>> >>> Hi All, >>> >>> Please review the fix for JDK13. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8216971 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mhalder/8216971/webrev.00/ >>> >>> Fix: >>> actionPerformed() was called twice due to wrong handling of key down event in method handleAction, which is corrected with this fix. >>> This change was added during fix of issue JDK-8152492. Apart from the changes required to fix the problem, code related to finding out >>> eventKey is removed as eventKey is no more used now. >>> >>> Note: >>> This issue is regression of bug 8152492, which was introduced in JDK release 9b120. >>> >>> Regards, >>> Manajit >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From manajit.halder at oracle.com Tue Mar 12 10:06:49 2019 From: manajit.halder at oracle.com (Manajit Halder) Date: Tue, 12 Mar 2019 15:36:49 +0530 Subject: [13] Review request for JDK-8216971: [macosx swing] For JCheckBoxMenuItem actionPerformed() is called twice, when apple.laf.useScreenMenuBar=true and modifier is InputEvent.META_DOWN_MASK In-Reply-To: <29C7954A-4551-461E-825D-A87074612761@oracle.com> References: <52287ED0-64B7-4586-9D2F-F3912EE4057A@oracle.com> <72180FB8-168D-419D-A357-C75D7BF4E3D4@oracle.com> <29C7954A-4551-461E-825D-A87074612761@oracle.com> Message-ID: <4C9C2E09-ACFE-46AF-85AA-2FED1BF4EEFA@oracle.com> Lines 74 to 82 explains why we need to ignore this call. This method should be ignored if it is called as a result of user pressing a shortcut and the window containing the menu is not minimized. Regards, Manajit > On 12-Mar-2019, at 3:16 PM, Krishna Addepalli wrote: > > Hi Manajit, > > Thanks for the clarification. I think you should add some more comments around the statement at line86, to explain in more detail, about why to ignore this call. > > Thanks, > Krishna > >> On 11-Mar-2019, at 2:25 PM, Manajit Halder > wrote: >> >> Hi Krishna, >> >> Thanks for the review comment. >> >> The key mapping is done by method setKeyEquivalent on fMenuItem (object of the NSMenuItem) in the same file. >> >> As discussed with you, the second key event is the problem here, and is caused only when System property ?apple.laf.useScreenMenuBar? is set to true. The extra event is generated in the handleAction method and my proposed fix is solving this issue. The difference with other look and feel setting or when ?apple.laf.useScreenMenuBar? is set to ?false? is that handleAction method is not called. I have verified and found that the META_MASK and CTRL_MASK are only set when ?apple.laf.useScreenMenuBar? is set to true and not in case of it is false. Also verified with ?metal? look and feel and found the MASKS are not set and handleAction method is not called and hence the extra key event is not generated. >> >> Please let me know if you have any other query. >> >> Regards, >> Manajit >> >> >> >>> On 05-Mar-2019, at 4:52 PM, Krishna Addepalli > wrote: >>> >>> Hi Manajit, >>> >>> Per our discussion, The cause of the problem is : 1), Key Event being sent from the OS to the application - which the Java layer processes it correctly >>> 2) The Mac OS calling the handleAction function directly on the NSMenutItem - although as per your description, there is no code which maps the hot key to this widget in the native layer. >>> Ideally, since the OS is recognising the key combination, that key event should not be delivered again to the application. Or, it should be that the key event is not recognised and hence delivered to the application. >>> >>> Can you check why in this case, we are getting the key event as well as the handleAction from the OS? >>> >>> Thanks, >>> Krishna >>> >>>> On 23-Feb-2019, at 9:14 PM, Manajit Halder > wrote: >>>> >>>> Hi All, >>>> >>>> Please review the fix for JDK13. >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8216971 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mhalder/8216971/webrev.00/ >>>> >>>> Fix: >>>> actionPerformed() was called twice due to wrong handling of key down event in method handleAction, which is corrected with this fix. >>>> This change was added during fix of issue JDK-8152492. Apart from the changes required to fix the problem, code related to finding out >>>> eventKey is removed as eventKey is no more used now. >>>> >>>> Note: >>>> This issue is regression of bug 8152492, which was introduced in JDK release 9b120. >>>> >>>> Regards, >>>> Manajit >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Mar 12 10:09:31 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 12 Mar 2019 03:09:31 -0700 Subject: [13] RFR JDK-8216353:Use utility APIs introduced in org/netbeans/jemmy/util/LookAndFeel class in client sanity test cases In-Reply-To: References: Message-ID: Looks fine. On 11/03/2019 23:08, Vikrant Agarwal wrote: > Hi All, > > Please review this fix forJDK-8216353 : > > Bug:https://bugs.openjdk.java.net/browse/JDK-8216353 > > Webrev: http://cr.openjdk.java.net/~vagarwal/8216353/webrev.1/ > > Summary: > > 1. The new Jemmy utility class (LookAndFeel.java) and other jemmy changes have already been committed to Jemmy Codetools repo and have been added here as is. > 2. Sanity tests have been updated to use this new utility class. > > Best Regards, > > Vikrant > -- Best regards, Sergey. From shashidhara.veerabhadraiah at oracle.com Tue Mar 12 10:52:52 2019 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Tue, 12 Mar 2019 03:52:52 -0700 (PDT) Subject: [12] JDK-8213516: jck test api/javax_accessibility/AccessibleState/fields.html fails intermittent In-Reply-To: References: <5905b959-3ade-4d99-931f-f88beada7a88@default> <94ef9f6d-a96d-0a4b-7ce6-be34964e0fee@oracle.com> <001bf74e-3415-bd91-c354-4006ee3b0e2c@oracle.com> <41a2006c-78f1-1ddd-c796-b89e1b594184@oracle.com> <5C1C40BC.90106@oracle.com> <5C1C776D.2090709@oracle.com> <717ce4ea-8d1a-4fc8-8cca-6ce676cfda40@default> <9006ef65-0837-7b77-be83-79bbd475aa95@oracle.com> <5dab2a68-2773-4a61-bf86-88bcb322f273@default> <77206885-c49a-cb5a-3cb1-73049c85c2a1@oracle.com> <0ef54b83-956f-4c28-b3cc-039e625d6f99@default> <98b5e57e-9b2c-4ba5-9462-36325f3c9c9e@default> Message-ID: <0f55ff64-dac2-4b61-b509-fba7c4f1b9ca@default> Hi Sergey, Please find the updated Webrev with fixes for the below comments: http://cr.openjdk.java.net/~sveerabhadra/8213516/webrev.06/ Thanks and regards, Shashi -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, March 6, 2019 5:19 AM To: Shashidhara Veerabhadraiah ; Philip Race Cc: swing-dev at openjdk.java.net; Dmitry Bessonov Subject: Re: [12] JDK-8213516: jck test api/javax_accessibility/AccessibleState/fields.html fails intermittent Hi, Shashi. On 04/03/2019 01:40, Shashidhara Veerabhadraiah wrote: > Hi Sergey\Phil, Here is a new Webrev containing the new test case along with the fix. With this change, the test fails before the fix and passes after the fix. > > http://cr.openjdk.java.net/~sveerabhadra/8213516/webrev.04/ > > Please review this change. The hashcode() does not guarantee that it will produce different numbers for different inputs. You need a compound key like in previous fix(but not in the public APi), or you need a compound map like this: Hashtable>> table = new Hashtable<>(); -- Best regards, Sergey. From krishna.addepalli at oracle.com Tue Mar 12 13:16:29 2019 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Tue, 12 Mar 2019 18:46:29 +0530 Subject: [13] Review request for JDK-8216971: [macosx swing] For JCheckBoxMenuItem actionPerformed() is called twice, when apple.laf.useScreenMenuBar=true and modifier is InputEvent.META_DOWN_MASK In-Reply-To: <4C9C2E09-ACFE-46AF-85AA-2FED1BF4EEFA@oracle.com> References: <52287ED0-64B7-4586-9D2F-F3912EE4057A@oracle.com> <72180FB8-168D-419D-A357-C75D7BF4E3D4@oracle.com> <29C7954A-4551-461E-825D-A87074612761@oracle.com> <4C9C2E09-ACFE-46AF-85AA-2FED1BF4EEFA@oracle.com> Message-ID: <740B7C3D-A720-4F1D-B59E-03F85C183543@oracle.com> Hi Manajit, Thanks for the clarification. The fix looks ok to me. Thanks, Krishna > On 12-Mar-2019, at 3:36 PM, Manajit Halder wrote: > > Lines 74 to 82 explains why we need to ignore this call. This method should be ignored if it is called as a result of user pressing a shortcut and the window containing the menu is not minimized. > > Regards, > Manajit > > >> On 12-Mar-2019, at 3:16 PM, Krishna Addepalli > wrote: >> >> Hi Manajit, >> >> Thanks for the clarification. I think you should add some more comments around the statement at line86, to explain in more detail, about why to ignore this call. >> >> Thanks, >> Krishna >> >>> On 11-Mar-2019, at 2:25 PM, Manajit Halder > wrote: >>> >>> Hi Krishna, >>> >>> Thanks for the review comment. >>> >>> The key mapping is done by method setKeyEquivalent on fMenuItem (object of the NSMenuItem) in the same file. >>> >>> As discussed with you, the second key event is the problem here, and is caused only when System property ?apple.laf.useScreenMenuBar? is set to true. The extra event is generated in the handleAction method and my proposed fix is solving this issue. The difference with other look and feel setting or when ?apple.laf.useScreenMenuBar? is set to ?false? is that handleAction method is not called. I have verified and found that the META_MASK and CTRL_MASK are only set when ?apple.laf.useScreenMenuBar? is set to true and not in case of it is false. Also verified with ?metal? look and feel and found the MASKS are not set and handleAction method is not called and hence the extra key event is not generated. >>> >>> Please let me know if you have any other query. >>> >>> Regards, >>> Manajit >>> >>> >>> >>>> On 05-Mar-2019, at 4:52 PM, Krishna Addepalli > wrote: >>>> >>>> Hi Manajit, >>>> >>>> Per our discussion, The cause of the problem is : 1), Key Event being sent from the OS to the application - which the Java layer processes it correctly >>>> 2) The Mac OS calling the handleAction function directly on the NSMenutItem - although as per your description, there is no code which maps the hot key to this widget in the native layer. >>>> Ideally, since the OS is recognising the key combination, that key event should not be delivered again to the application. Or, it should be that the key event is not recognised and hence delivered to the application. >>>> >>>> Can you check why in this case, we are getting the key event as well as the handleAction from the OS? >>>> >>>> Thanks, >>>> Krishna >>>> >>>>> On 23-Feb-2019, at 9:14 PM, Manajit Halder > wrote: >>>>> >>>>> Hi All, >>>>> >>>>> Please review the fix for JDK13. >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8216971 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mhalder/8216971/webrev.00/ >>>>> >>>>> Fix: >>>>> actionPerformed() was called twice due to wrong handling of key down event in method handleAction, which is corrected with this fix. >>>>> This change was added during fix of issue JDK-8152492. Apart from the changes required to fix the problem, code related to finding out >>>>> eventKey is removed as eventKey is no more used now. >>>>> >>>>> Note: >>>>> This issue is regression of bug 8152492, which was introduced in JDK release 9b120. >>>>> >>>>> Regards, >>>>> Manajit >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Mar 13 06:10:42 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 13 Mar 2019 11:40:42 +0530 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> <5C81E5D1.8040504@oracle.com> <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> <57966237-35cd-0cde-c195-ed4af73091ee@oracle.com> <5C84B5CE.30904@oracle.com> Message-ID: <597c27ce-cc0f-11de-da41-7152cdf217be@oracle.com> Any more comments on this http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.2/ Regards Prasanta On 11-Mar-19 2:16 PM, Prasanta Sadhukhan wrote: > The 2nd URL is based on webrev.1. I have placed new docs for webrev.2 > here > http://cr.openjdk.java.net/~psadhukhan/8220250/docs.webrev2/docs/api/java.desktop/module-summary.html > > > Regards > Prasanta > On 10-Mar-19 9:17 PM, Jonathan Gibbons wrote: >> If it helps, I have a utility to extract headers from an API bundle, >> that can generate a new bundle showing just the headers for each >> page, and their metadata. I'll run that on the two bundles you list >> below, and post the new URLs here. >> >> -- Jon >> >> On 3/9/19 10:59 PM, Philip Race wrote: >>> It might have been intentional but I think it is wrong. >>> >>> It is useful to look at the old : >>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/module-summary.html >>> >>> and the new : >>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs/api/java.desktop/module-summary.html >>> >>> >>> to compare. >>> >>> >>> What was H3 is in italics and what follows in regular style is intended >>> to be a sub-section. >>> >>> -phil. >>> >>> On 3/10/19, 9:30 AM, Sergey Bylokhov wrote: >>>> When I check the first version, I thought it was intentional change. >>>> >>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/javax/print/attribute/package-summary.html >>>> >>>> >>>> All of them looks similar headers described something about >>>> attributes: >>>> ? 1.

Attribute Roles

>>>> ? 2.

Attribute Sets

>>>> >>>> Why the first uses

and the second uses

? >>>> >>>> On 09/03/2019 01:54, Prasanta Sadhukhan wrote: >>>>> Thanks Jon for the pointer. I have modified that file >>>>> >>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.2/ >>>>> >>>>> Any more comments? >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 09-Mar-19 2:24 AM, Jonathan Gibbons wrote: >>>>>> Prasanta, >>>>>> >>>>>> You should double check this file: >>>>>> >>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.1/src/java.desktop/share/classes/javax/print/attribute/package-info.java.udiff.html >>>>>> >>>>>> >>>>>> Previously, it was a mixture of

and

, suggesting that >>>>>> the

were subheadings of the enclosing logical

section.? >>>>>> Now, you have changed them all to

, meaning that now they are >>>>>> all equivalent headings. >>>>>> >>>>>> -- Jon >>>>>> >>>>>> On 3/8/19 7:09 AM, Prasanta Sadhukhan wrote: >>>>>>> Hi Phil, >>>>>>> >>>>>>> >>>>>>> On 08-Mar-19 9:17 AM, Philip Race wrote: >>>>>>>> Apart from making sure all the files are fixed there are two >>>>>>>> things to look for : >>>>>>>> >>>>>>>> 1) If by moving a heading up from H3 to H2 you've now created a >>>>>>>> similar error >>>>>>>> because there is now no H3 before an H4. To be sure of this I >>>>>>>> think you'd >>>>>>>> need to run Jon's tool - how did you verify it ? >>>>>>>> >>>>>>> I missed one case in TextAttribute which I rectified >>>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.1/ >>>>>>> ?It will be good to have Jon's tool so cc-ed him... >>>>>>>> 2) If in a case like UIManager where you've moved some >>>>>>>> subsequent headings >>>>>>>> up from H3 to H2 to match the new size at the reported error >>>>>>>> site , would it >>>>>>>> have been better visually to leave them as H3 ? ... probably >>>>>>>> not .. but if there >>>>>>>> were generated doc for us to look at posted that would be >>>>>>>> easier to tell. >>>>>>> I am using make docs to verify and the docs output can be found at >>>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs/api/java.desktop/module-summary.html >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 3/8/19, 3:37 AM, Sergey Bylokhov wrote: >>>>>>>>> Looks fine. >>>>>>>>> >>>>>>>>> On 07/03/2019 03:37, Prasanta Sadhukhan wrote: >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220250 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.0/ >>>>>>>>>> >>>>>>>>>> Please review a doc fix to fix heading style to improve the >>>>>>>>>> accessibility JDK API documentation of java.desktop module. >>>>>>>>>> >>>>>>>>>> Main approach taken for fixing heading style are: >>>>>>>>>> - headings in documentation comments for modules, packages >>>>>>>>>> and types should start at

- Headings should be >>>>>>>>>> hierarchical, and without ascending gaps, so

should be >>>>>>>>>> followed by

,

should be followed by

or another >>>>>>>>>>

Regards Prasanta >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >>>> > From alexey.ivanov at oracle.com Wed Mar 13 12:40:13 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 13 Mar 2019 12:40:13 +0000 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: <597c27ce-cc0f-11de-da41-7152cdf217be@oracle.com> References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> <5C81E5D1.8040504@oracle.com> <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> <57966237-35cd-0cde-c195-ed4af73091ee@oracle.com> <5C84B5CE.30904@oracle.com> <597c27ce-cc0f-11de-da41-7152cdf217be@oracle.com> Message-ID: Hi guys, This is more of a general comment rather than targeted at this particular change. Sorry if I missed any previous discussion on that matter. I think it's good to have consistent headings without skipping levels. Yet

in the Javadoc comments does not seem right. Let's take a look at JTable for example: http://cr.openjdk.java.net/~psadhukhan/8220250/docs.webrev2/docs/api/java.desktop/javax/swing/JTable.html The page starts with

JTable

. This is the highest heading level on the page, I haven't found any

. Later on,

Method Detail

. And a specific method:

doLayout

. Since the entire method description is under

heading, it should not use any headings above

. But now we have

and

which kind-of start new sections rather than being part of

which describes the method. Is such heading sequence intended? Regards, Alexey On 13/03/2019 06:10, Prasanta Sadhukhan wrote: > Any more comments on this > http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.2/ > > Regards > Prasanta > On 11-Mar-19 2:16 PM, Prasanta Sadhukhan wrote: >> The 2nd URL is based on webrev.1. I have placed new docs for webrev.2 >> here >> http://cr.openjdk.java.net/~psadhukhan/8220250/docs.webrev2/docs/api/java.desktop/module-summary.html >> >> >> Regards >> Prasanta >> On 10-Mar-19 9:17 PM, Jonathan Gibbons wrote: >>> If it helps, I have a utility to extract headers from an API bundle, >>> that can generate a new bundle showing just the headers for each >>> page, and their metadata. I'll run that on the two bundles you list >>> below, and post the new URLs here. >>> >>> -- Jon >>> >>> On 3/9/19 10:59 PM, Philip Race wrote: >>>> It might have been intentional but I think it is wrong. >>>> >>>> It is useful to look at the old : >>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/module-summary.html >>>> >>>> and the new : >>>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs/api/java.desktop/module-summary.html >>>> >>>> >>>> to compare. >>>> >>>> >>>> What was H3 is in italics and what follows in regular style is >>>> intended >>>> to be a sub-section. >>>> >>>> -phil. >>>> >>>> On 3/10/19, 9:30 AM, Sergey Bylokhov wrote: >>>>> When I check the first version, I thought it was intentional change. >>>>> >>>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/javax/print/attribute/package-summary.html >>>>> >>>>> >>>>> All of them looks similar headers described something about >>>>> attributes: >>>>> ? 1.

Attribute Roles

>>>>> ? 2.

Attribute Sets

>>>>> >>>>> Why the first uses

and the second uses

? >>>>> >>>>> On 09/03/2019 01:54, Prasanta Sadhukhan wrote: >>>>>> Thanks Jon for the pointer. I have modified that file >>>>>> >>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.2/ >>>>>> >>>>>> Any more comments? >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 09-Mar-19 2:24 AM, Jonathan Gibbons wrote: >>>>>>> Prasanta, >>>>>>> >>>>>>> You should double check this file: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.1/src/java.desktop/share/classes/javax/print/attribute/package-info.java.udiff.html >>>>>>> >>>>>>> >>>>>>> Previously, it was a mixture of

and

, suggesting that >>>>>>> the

were subheadings of the enclosing logical

>>>>>>> section.? Now, you have changed them all to

, meaning that >>>>>>> now they are all equivalent headings. >>>>>>> >>>>>>> -- Jon >>>>>>> >>>>>>> On 3/8/19 7:09 AM, Prasanta Sadhukhan wrote: >>>>>>>> Hi Phil, >>>>>>>> >>>>>>>> >>>>>>>> On 08-Mar-19 9:17 AM, Philip Race wrote: >>>>>>>>> Apart from making sure all the files are fixed there are two >>>>>>>>> things to look for : >>>>>>>>> >>>>>>>>> 1) If by moving a heading up from H3 to H2 you've now created >>>>>>>>> a similar error >>>>>>>>> because there is now no H3 before an H4. To be sure of this I >>>>>>>>> think you'd >>>>>>>>> need to run Jon's tool - how did you verify it ? >>>>>>>>> >>>>>>>> I missed one case in TextAttribute which I rectified >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.1/ >>>>>>>> ?It will be good to have Jon's tool so cc-ed him... >>>>>>>>> 2) If in a case like UIManager where you've moved some >>>>>>>>> subsequent headings >>>>>>>>> up from H3 to H2 to match the new size at the reported error >>>>>>>>> site , would it >>>>>>>>> have been better visually to leave them as H3 ? ... probably >>>>>>>>> not .. but if there >>>>>>>>> were generated doc for us to look at posted that would be >>>>>>>>> easier to tell. >>>>>>>> I am using make docs to verify and the docs output can be found at >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs/api/java.desktop/module-summary.html >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 3/8/19, 3:37 AM, Sergey Bylokhov wrote: >>>>>>>>>> Looks fine. >>>>>>>>>> >>>>>>>>>> On 07/03/2019 03:37, Prasanta Sadhukhan wrote: >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220250 >>>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.0/ >>>>>>>>>>> >>>>>>>>>>> Please review a doc fix to fix heading style to improve the >>>>>>>>>>> accessibility JDK API documentation of java.desktop module. >>>>>>>>>>> >>>>>>>>>>> Main approach taken for fixing heading style are: >>>>>>>>>>> - headings in documentation comments for modules, packages >>>>>>>>>>> and types should start at

- Headings should be >>>>>>>>>>> hierarchical, and without ascending gaps, so

should be >>>>>>>>>>> followed by

,

should be followed by

or another >>>>>>>>>>>

Regards Prasanta >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>>> >> > From prasanta.sadhukhan at oracle.com Fri Mar 15 05:15:52 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 15 Mar 2019 10:45:52 +0530 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> <5C81E5D1.8040504@oracle.com> <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> <57966237-35cd-0cde-c195-ed4af73091ee@oracle.com> <5C84B5CE.30904@oracle.com> <597c27ce-cc0f-11de-da41-7152cdf217be@oracle.com> Message-ID: <03eb91ca-0a9c-a434-2088-08be7cd19280@oracle.com> Hi Alexey, On 13-Mar-19 6:10 PM, Alexey Ivanov wrote: > Hi guys, > > This is more of a general comment rather than targeted at this > particular change. Sorry if I missed any previous discussion on that > matter. > > I think it's good to have consistent headings without skipping levels. > > Yet

in the Javadoc comments does not seem right. Let's take a > look at JTable for example: > http://cr.openjdk.java.net/~psadhukhan/8220250/docs.webrev2/docs/api/java.desktop/javax/swing/JTable.html > > > The page starts with

JTable

. This is the highest heading > level on the page, I haven't found any

. As for this changeset, I am following the rules set in the https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002671.html - headings in documentation comments for modules, packages and types should start at

- > > Later on,

Method Detail

. And a specific method: >

doLayout

. Since the entire method description is under

> heading, it should not use any headings above

. But now we have >

and

which kind-of start new sections rather than being part > of

which describes the method. I have only changed to make sure there are no missing headings ie start with h2 (as stated above) and change previously used? h4 to h3(to make sure no missing heading), rest were as it was earlier. Regards Prasanta > > Is such heading sequence intended? > > Regards, > Alexey > > On 13/03/2019 06:10, Prasanta Sadhukhan wrote: >> Any more comments on this >> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.2/ >> >> Regards >> Prasanta >> On 11-Mar-19 2:16 PM, Prasanta Sadhukhan wrote: >>> The 2nd URL is based on webrev.1. I have placed new docs for >>> webrev.2 here >>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs.webrev2/docs/api/java.desktop/module-summary.html >>> >>> >>> Regards >>> Prasanta >>> On 10-Mar-19 9:17 PM, Jonathan Gibbons wrote: >>>> If it helps, I have a utility to extract headers from an API >>>> bundle, that can generate a new bundle showing just the headers for >>>> each page, and their metadata. I'll run that on the two bundles you >>>> list below, and post the new URLs here. >>>> >>>> -- Jon >>>> >>>> On 3/9/19 10:59 PM, Philip Race wrote: >>>>> It might have been intentional but I think it is wrong. >>>>> >>>>> It is useful to look at the old : >>>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/module-summary.html >>>>> >>>>> and the new : >>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs/api/java.desktop/module-summary.html >>>>> >>>>> >>>>> to compare. >>>>> >>>>> >>>>> What was H3 is in italics and what follows in regular style is >>>>> intended >>>>> to be a sub-section. >>>>> >>>>> -phil. >>>>> >>>>> On 3/10/19, 9:30 AM, Sergey Bylokhov wrote: >>>>>> When I check the first version, I thought it was intentional change. >>>>>> >>>>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/javax/print/attribute/package-summary.html >>>>>> >>>>>> >>>>>> All of them looks similar headers described something about >>>>>> attributes: >>>>>> ? 1.

Attribute Roles

>>>>>> ? 2.

Attribute Sets

>>>>>> >>>>>> Why the first uses

and the second uses

? >>>>>> >>>>>> On 09/03/2019 01:54, Prasanta Sadhukhan wrote: >>>>>>> Thanks Jon for the pointer. I have modified that file >>>>>>> >>>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.2/ >>>>>>> >>>>>>> Any more comments? >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 09-Mar-19 2:24 AM, Jonathan Gibbons wrote: >>>>>>>> Prasanta, >>>>>>>> >>>>>>>> You should double check this file: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.1/src/java.desktop/share/classes/javax/print/attribute/package-info.java.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> Previously, it was a mixture of

and

, suggesting that >>>>>>>> the

were subheadings of the enclosing logical

>>>>>>>> section.? Now, you have changed them all to

, meaning that >>>>>>>> now they are all equivalent headings. >>>>>>>> >>>>>>>> -- Jon >>>>>>>> >>>>>>>> On 3/8/19 7:09 AM, Prasanta Sadhukhan wrote: >>>>>>>>> Hi Phil, >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08-Mar-19 9:17 AM, Philip Race wrote: >>>>>>>>>> Apart from making sure all the files are fixed there are two >>>>>>>>>> things to look for : >>>>>>>>>> >>>>>>>>>> 1) If by moving a heading up from H3 to H2 you've now created >>>>>>>>>> a similar error >>>>>>>>>> because there is now no H3 before an H4. To be sure of this I >>>>>>>>>> think you'd >>>>>>>>>> need to run Jon's tool - how did you verify it ? >>>>>>>>>> >>>>>>>>> I missed one case in TextAttribute which I rectified >>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.1/ >>>>>>>>> ?It will be good to have Jon's tool so cc-ed him... >>>>>>>>>> 2) If in a case like UIManager where you've moved some >>>>>>>>>> subsequent headings >>>>>>>>>> up from H3 to H2 to match the new size at the reported error >>>>>>>>>> site , would it >>>>>>>>>> have been better visually to leave them as H3 ? ... probably >>>>>>>>>> not .. but if there >>>>>>>>>> were generated doc for us to look at posted that would be >>>>>>>>>> easier to tell. >>>>>>>>> I am using make docs to verify and the docs output can be >>>>>>>>> found at >>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs/api/java.desktop/module-summary.html >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> On 3/8/19, 3:37 AM, Sergey Bylokhov wrote: >>>>>>>>>>> Looks fine. >>>>>>>>>>> >>>>>>>>>>> On 07/03/2019 03:37, Prasanta Sadhukhan wrote: >>>>>>>>>>>> Hi All, >>>>>>>>>>>> >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220250 >>>>>>>>>>>> webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.0/ >>>>>>>>>>>> >>>>>>>>>>>> Please review a doc fix to fix heading style to improve the >>>>>>>>>>>> accessibility JDK API documentation of java.desktop module. >>>>>>>>>>>> >>>>>>>>>>>> Main approach taken for fixing heading style are: >>>>>>>>>>>> - headings in documentation comments for modules, packages >>>>>>>>>>>> and types should start at

- Headings should be >>>>>>>>>>>> hierarchical, and without ascending gaps, so

should be >>>>>>>>>>>> followed by

,

should be followed by

or >>>>>>>>>>>> another

Regards Prasanta >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Mar 15 06:02:28 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 15 Mar 2019 11:32:28 +0530 Subject: [13] Review request for JDK-8216971: [macosx swing] For JCheckBoxMenuItem actionPerformed() is called twice, when apple.laf.useScreenMenuBar=true and modifier is InputEvent.META_DOWN_MASK In-Reply-To: <740B7C3D-A720-4F1D-B59E-03F85C183543@oracle.com> References: <52287ED0-64B7-4586-9D2F-F3912EE4057A@oracle.com> <72180FB8-168D-419D-A357-C75D7BF4E3D4@oracle.com> <29C7954A-4551-461E-825D-A87074612761@oracle.com> <4C9C2E09-ACFE-46AF-85AA-2FED1BF4EEFA@oracle.com> <740B7C3D-A720-4F1D-B59E-03F85C183543@oracle.com> Message-ID: <4b333319-7402-85f0-04e9-a340a95fac03@oracle.com> fix looks fine to me but there are indentation issue both in fix and in testcase. Please rectify it. Regards Prasanta On 12-Mar-19 6:46 PM, Krishna Addepalli wrote: > Hi Manajit, > > Thanks for the clarification. The fix looks ok to me. > > Thanks, > Krishna > >> On 12-Mar-2019, at 3:36 PM, Manajit Halder > > wrote: >> >> Lines 74 to 82 explains why we need to ignore this call. This method >> should be ignored if it is called as a result of user pressing ?a >> shortcut and the window containing the menu is not minimized. >> >> Regards, >> Manajit >> >> >>> On 12-Mar-2019, at 3:16 PM, Krishna Addepalli >>> > >>> wrote: >>> >>> Hi Manajit, >>> >>> Thanks for the clarification. I think you should add some more >>> comments around the statement at line86, to explain in more detail, >>> about why to ignore this call. >>> >>> Thanks, >>> Krishna >>> >>>> On 11-Mar-2019, at 2:25 PM, Manajit Halder >>>> > wrote: >>>> >>>> Hi Krishna, >>>> >>>> Thanks for the review comment. >>>> >>>> The key mapping is done by method setKeyEquivalent on fMenuItem >>>> (object of the NSMenuItem) in the same file. >>>> >>>> As discussed with you, the second key event is the problem here, >>>> and is caused only when System property >>>> ?apple.laf.useScreenMenuBar? is set to true.?The extra event is >>>> generated in the handleAction method and my proposed fix is solving >>>> this issue. The difference with other look and feel setting or when >>>> ?apple.laf.useScreenMenuBar? is set to ?false? is that handleAction >>>> method is not called. I have verified and found that the?META_MASK >>>> and CTRL_MASK are only set when ?apple.laf.useScreenMenuBar? is set >>>> to true?and not in case of it is false. Also verified with ?metal? >>>> look and feel and found the MASKS are not set and handleAction >>>> method is not called and hence the extra key event is not generated. >>>> >>>> Please let me know if you have any other query. >>>> >>>> Regards, >>>> Manajit >>>> >>>> >>>> >>>>> On 05-Mar-2019, at 4:52 PM, Krishna Addepalli >>>>> >>>> > wrote: >>>>> >>>>> Hi Manajit, >>>>> >>>>> Per our discussion, The cause of the problem is : 1), Key Event >>>>> being sent from the OS to the application - which the Java layer >>>>> processes it correctly >>>>> 2) The Mac OS calling the handleAction function directly on the >>>>> NSMenutItem - although as per your description, there is no code >>>>> which maps the hot key to this widget in the native layer. >>>>> Ideally, since the OS is recognising the key combination, that key >>>>> event should not be delivered again to the application. Or, it >>>>> should be that the key event is not recognised and hence delivered >>>>> to the application. >>>>> >>>>> Can you check why in this case, we are getting the key event as >>>>> well as the handleAction from the OS? >>>>> >>>>> Thanks, >>>>> Krishna >>>>> >>>>>> On 23-Feb-2019, at 9:14 PM, Manajit Halder >>>>>> > wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> Please review the fix for JDK13. >>>>>> >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8216971 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~mhalder/8216971/webrev.00/ >>>>>> >>>>>> >>>>>> Fix: >>>>>> actionPerformed() was called twice due to wrong handling of key >>>>>> down event in method handleAction, which is corrected with this fix. >>>>>> This change was added during fix of issue JDK-8152492. Apart from >>>>>> the changes required to fix the problem, code related to finding out >>>>>> eventKey is removed as eventKey is no more used now. >>>>>> >>>>>> Note: >>>>>> This issue is regression of bug 8152492, which was introduced in >>>>>> JDK release 9b120. >>>>>> >>>>>> Regards, >>>>>> Manajit >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From manajit.halder at oracle.com Fri Mar 15 11:21:02 2019 From: manajit.halder at oracle.com (Manajit Halder) Date: Fri, 15 Mar 2019 16:51:02 +0530 Subject: [13] Review request for JDK-8216971: [macosx swing] For JCheckBoxMenuItem actionPerformed() is called twice, when apple.laf.useScreenMenuBar=true and modifier is InputEvent.META_DOWN_MASK In-Reply-To: <4b333319-7402-85f0-04e9-a340a95fac03@oracle.com> References: <52287ED0-64B7-4586-9D2F-F3912EE4057A@oracle.com> <72180FB8-168D-419D-A357-C75D7BF4E3D4@oracle.com> <29C7954A-4551-461E-825D-A87074612761@oracle.com> <4C9C2E09-ACFE-46AF-85AA-2FED1BF4EEFA@oracle.com> <740B7C3D-A720-4F1D-B59E-03F85C183543@oracle.com> <4b333319-7402-85f0-04e9-a340a95fac03@oracle.com> Message-ID: Thanks Prasanta, I have corrected the indentation issue in both files. Please review the modified webrev. http://cr.openjdk.java.net/~mhalder/8216971/webrev.01/ Regards, Manajit > On 15-Mar-2019, at 11:32 AM, Prasanta Sadhukhan wrote: > > fix looks fine to me but there are indentation issue both in fix and in testcase. Please rectify it. > Regards > Prasanta > On 12-Mar-19 6:46 PM, Krishna Addepalli wrote: >> Hi Manajit, >> >> Thanks for the clarification. The fix looks ok to me. >> >> Thanks, >> Krishna >> >>> On 12-Mar-2019, at 3:36 PM, Manajit Halder > wrote: >>> >>> Lines 74 to 82 explains why we need to ignore this call. This method should be ignored if it is called as a result of user pressing a shortcut and the window containing the menu is not minimized. >>> >>> Regards, >>> Manajit >>> >>> >>>> On 12-Mar-2019, at 3:16 PM, Krishna Addepalli > wrote: >>>> >>>> Hi Manajit, >>>> >>>> Thanks for the clarification. I think you should add some more comments around the statement at line86, to explain in more detail, about why to ignore this call. >>>> >>>> Thanks, >>>> Krishna >>>> >>>>> On 11-Mar-2019, at 2:25 PM, Manajit Halder > wrote: >>>>> >>>>> Hi Krishna, >>>>> >>>>> Thanks for the review comment. >>>>> >>>>> The key mapping is done by method setKeyEquivalent on fMenuItem (object of the NSMenuItem) in the same file. >>>>> >>>>> As discussed with you, the second key event is the problem here, and is caused only when System property ?apple.laf.useScreenMenuBar? is set to true. The extra event is generated in the handleAction method and my proposed fix is solving this issue. The difference with other look and feel setting or when ?apple.laf.useScreenMenuBar? is set to ?false? is that handleAction method is not called. I have verified and found that the META_MASK and CTRL_MASK are only set when ?apple.laf.useScreenMenuBar? is set to true and not in case of it is false. Also verified with ?metal? look and feel and found the MASKS are not set and handleAction method is not called and hence the extra key event is not generated. >>>>> >>>>> Please let me know if you have any other query. >>>>> >>>>> Regards, >>>>> Manajit >>>>> >>>>> >>>>> >>>>>> On 05-Mar-2019, at 4:52 PM, Krishna Addepalli > wrote: >>>>>> >>>>>> Hi Manajit, >>>>>> >>>>>> Per our discussion, The cause of the problem is : 1), Key Event being sent from the OS to the application - which the Java layer processes it correctly >>>>>> 2) The Mac OS calling the handleAction function directly on the NSMenutItem - although as per your description, there is no code which maps the hot key to this widget in the native layer. >>>>>> Ideally, since the OS is recognising the key combination, that key event should not be delivered again to the application. Or, it should be that the key event is not recognised and hence delivered to the application. >>>>>> >>>>>> Can you check why in this case, we are getting the key event as well as the handleAction from the OS? >>>>>> >>>>>> Thanks, >>>>>> Krishna >>>>>> >>>>>>> On 23-Feb-2019, at 9:14 PM, Manajit Halder > wrote: >>>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> Please review the fix for JDK13. >>>>>>> >>>>>>> Bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8216971 >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~mhalder/8216971/webrev.00/ >>>>>>> >>>>>>> Fix: >>>>>>> actionPerformed() was called twice due to wrong handling of key down event in method handleAction, which is corrected with this fix. >>>>>>> This change was added during fix of issue JDK-8152492. Apart from the changes required to fix the problem, code related to finding out >>>>>>> eventKey is removed as eventKey is no more used now. >>>>>>> >>>>>>> Note: >>>>>>> This issue is regression of bug 8152492, which was introduced in JDK release 9b120. >>>>>>> >>>>>>> Regards, >>>>>>> Manajit >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Fri Mar 15 16:58:46 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 15 Mar 2019 16:58:46 +0000 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: <03eb91ca-0a9c-a434-2088-08be7cd19280@oracle.com> References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> <5C81E5D1.8040504@oracle.com> <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> <57966237-35cd-0cde-c195-ed4af73091ee@oracle.com> <5C84B5CE.30904@oracle.com> <597c27ce-cc0f-11de-da41-7152cdf217be@oracle.com> <03eb91ca-0a9c-a434-2088-08be7cd19280@oracle.com> Message-ID: Hi Prasanta, On 15/03/2019 05:15, Prasanta Sadhukhan wrote: > > Hi Alexey, > > > On 13-Mar-19 6:10 PM, Alexey Ivanov wrote: >> Hi guys, >> >> This is more of a general comment rather than targeted at this >> particular change. Sorry if I missed any previous discussion on that >> matter. >> >> I think it's good to have consistent headings without skipping levels. >> >> Yet

in the Javadoc comments does not seem right. Let's take a >> look at JTable for example: >> http://cr.openjdk.java.net/~psadhukhan/8220250/docs.webrev2/docs/api/java.desktop/javax/swing/JTable.html >> >> >> The page starts with

JTable

. This is the highest heading >> level on the page, I haven't found any

. > As for this changeset, I am following the rules set in the > https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002671.html > - headings in documentation comments for modules, packages and types > should start at

- Thank you for clarification. I've seen a few fixes in this area but I missed this discussion. So the main type heading will be

, i.e. it will

JTable

. Therefore starting at

in types makes sense. >> Later on,

Method Detail

. And a specific method: >>

doLayout

. Since the entire method description is under

>> heading, it should not use any headings above

. But now we have >>

and

which kind-of start new sections rather than being part >> of

which describes the method. > I have only changed to make sure there are no missing headings ie > start with h2 (as stated above) and change previously used? h4 to > h3(to make sure no missing heading), rest were as it was earlier. According to the message you linked to, the documentation comments for methods should start at

. Here's the relevant quote: ?Headings in documentation comments for modules, packages and types should start at

; Headings in documentation comments for members of a type (field, constructor, method, etc) should start at

. (I've changed formatting to separate these two cases.) Thus in *JTable.java* you should rather decrease heading level as the headings are used in /method/ as opposed to /type/ in the majority of other cases: -3053????? *

Distributing the delta

+3053????? *

Distributing the delta

-3055????? *

Overview

+3055????? *
Overview
And the remaining

become

: 3064????? *

Definition

3096????? *

Details

3107????? *

When the MAX and MIN bounds are hit

As for the rest of the review: *Font.java* You changed the first

to

: -77? *

Characters and Glyphs

+77? *

Characters and Glyphs

But why not other headings? All of the headings were at the same level, but they're not. These should also go up to

: ?99? *

Physical and Logical Fonts

138? *

Font Faces and Names

172? *

Font and TextAttribute

*javax/print/attribute/package-info.java* 204? *

Attribute Class Design

298? *

Attribute Vendors

324? *

Using Attributes

These should also go one level up to

as other headings. These used to be separate sections but now they're subsections of 131? *

Attribute Sets

which does not seem correct. Regards, Alexey > > Regards > Prasanta >> >> Is such heading sequence intended? >> >> Regards, >> Alexey >> >> On 13/03/2019 06:10, Prasanta Sadhukhan wrote: >>> Any more comments on this >>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.2/ >>> >>> Regards >>> Prasanta >>> On 11-Mar-19 2:16 PM, Prasanta Sadhukhan wrote: >>>> The 2nd URL is based on webrev.1. I have placed new docs for >>>> webrev.2 here >>>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs.webrev2/docs/api/java.desktop/module-summary.html >>>> >>>> >>>> Regards >>>> Prasanta >>>> From prasanta.sadhukhan at oracle.com Mon Mar 18 05:51:00 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 18 Mar 2019 11:21:00 +0530 Subject: [13] Review request for JDK-8216971: [macosx swing] For JCheckBoxMenuItem actionPerformed() is called twice, when apple.laf.useScreenMenuBar=true and modifier is InputEvent.META_DOWN_MASK In-Reply-To: References: <52287ED0-64B7-4586-9D2F-F3912EE4057A@oracle.com> <72180FB8-168D-419D-A357-C75D7BF4E3D4@oracle.com> <29C7954A-4551-461E-825D-A87074612761@oracle.com> <4C9C2E09-ACFE-46AF-85AA-2FED1BF4EEFA@oracle.com> <740B7C3D-A720-4F1D-B59E-03F85C183543@oracle.com> <4b333319-7402-85f0-04e9-a340a95fac03@oracle.com> Message-ID: I guess l94-111 indentation in CMenuItem.m and l69 Robot robot = new Robot(); in testcase is still not fixed. Regards Prasanta On 15-Mar-19 4:51 PM, Manajit Halder wrote: > Thanks Prasanta, > > I have corrected the indentation issue in both files. Please review > the modified webrev. > http://cr.openjdk.java.net/~mhalder/8216971/webrev.01/ > > > Regards, > Manajit > > >> On 15-Mar-2019, at 11:32 AM, Prasanta Sadhukhan >> > > wrote: >> >> fix looks fine to me but there are indentation issue both in fix and >> in testcase. Please rectify it. >> >> Regards >> Prasanta >> On 12-Mar-19 6:46 PM, Krishna Addepalli wrote: >>> Hi Manajit, >>> >>> Thanks for the clarification. The fix looks ok to me. >>> >>> Thanks, >>> Krishna >>> >>>> On 12-Mar-2019, at 3:36 PM, Manajit Halder >>>> > wrote: >>>> >>>> Lines 74 to 82 explains why we need to ignore this call. This >>>> method should be ignored if it is called as a result of user >>>> pressing ?a shortcut and the window containing the menu is not >>>> minimized. >>>> >>>> Regards, >>>> Manajit >>>> >>>> >>>>> On 12-Mar-2019, at 3:16 PM, Krishna Addepalli >>>>> >>>> > wrote: >>>>> >>>>> Hi Manajit, >>>>> >>>>> Thanks for the clarification. I think you should add some more >>>>> comments around the statement at line86, to explain in more >>>>> detail, about why to ignore this call. >>>>> >>>>> Thanks, >>>>> Krishna >>>>> >>>>>> On 11-Mar-2019, at 2:25 PM, Manajit Halder >>>>>> > wrote: >>>>>> >>>>>> Hi Krishna, >>>>>> >>>>>> Thanks for the review comment. >>>>>> >>>>>> The key mapping is done by method setKeyEquivalent on fMenuItem >>>>>> (object of the NSMenuItem) in the same file. >>>>>> >>>>>> As discussed with you, the second key event is the problem here, >>>>>> and is caused only when System property >>>>>> ?apple.laf.useScreenMenuBar? is set to true.?The extra event is >>>>>> generated in the handleAction method and my proposed fix is >>>>>> solving this issue. The difference with other look and feel >>>>>> setting or when ?apple.laf.useScreenMenuBar? is set to ?false? is >>>>>> that handleAction method is not called. I have verified and found >>>>>> that the?META_MASK and CTRL_MASK are only set when >>>>>> ?apple.laf.useScreenMenuBar? is set to true?and not in case of it >>>>>> is false. Also verified with ?metal? look and feel and found the >>>>>> MASKS are not set and handleAction method is not called and hence >>>>>> the extra key event is not generated. >>>>>> >>>>>> Please let me know if you have any other query. >>>>>> >>>>>> Regards, >>>>>> Manajit >>>>>> >>>>>> >>>>>> >>>>>>> On 05-Mar-2019, at 4:52 PM, Krishna Addepalli >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Hi Manajit, >>>>>>> >>>>>>> Per our discussion, The cause of the problem is : 1), Key Event >>>>>>> being sent from the OS to the application - which the Java layer >>>>>>> processes it correctly >>>>>>> 2) The Mac OS calling the handleAction function directly on the >>>>>>> NSMenutItem - although as per your description, there is no code >>>>>>> which maps the hot key to this widget in the native layer. >>>>>>> Ideally, since the OS is recognising the key combination, that >>>>>>> key event should not be delivered again to the application. Or, >>>>>>> it should be that the key event is not recognised and hence >>>>>>> delivered to the application. >>>>>>> >>>>>>> Can you check why in this case, we are getting the key event as >>>>>>> well as the handleAction from the OS? >>>>>>> >>>>>>> Thanks, >>>>>>> Krishna >>>>>>> >>>>>>>> On 23-Feb-2019, at 9:14 PM, Manajit Halder >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Please review the fix for JDK13. >>>>>>>> >>>>>>>> Bug: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8216971 >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~mhalder/8216971/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> Fix: >>>>>>>> actionPerformed() was called twice due to wrong handling of key >>>>>>>> down event in method handleAction, which is corrected with this >>>>>>>> fix. >>>>>>>> This change was added during fix of issue JDK-8152492. Apart >>>>>>>> from the changes required to fix the problem, code related to >>>>>>>> finding out >>>>>>>> eventKey is removed as eventKey is no more used now. >>>>>>>> >>>>>>>> Note: >>>>>>>> This issue is regression of bug 8152492, which was introduced >>>>>>>> in JDK release 9b120. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Manajit >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From manajit.halder at oracle.com Mon Mar 18 10:42:33 2019 From: manajit.halder at oracle.com (Manajit Halder) Date: Mon, 18 Mar 2019 16:12:33 +0530 Subject: [13] Review request for JDK-8216971: [macosx swing] For JCheckBoxMenuItem actionPerformed() is called twice, when apple.laf.useScreenMenuBar=true and modifier is InputEvent.META_DOWN_MASK In-Reply-To: References: <52287ED0-64B7-4586-9D2F-F3912EE4057A@oracle.com> <72180FB8-168D-419D-A357-C75D7BF4E3D4@oracle.com> <29C7954A-4551-461E-825D-A87074612761@oracle.com> <4C9C2E09-ACFE-46AF-85AA-2FED1BF4EEFA@oracle.com> <740B7C3D-A720-4F1D-B59E-03F85C183543@oracle.com> <4b333319-7402-85f0-04e9-a340a95fac03@oracle.com> Message-ID: <7B778B0E-8394-4BDB-92B2-9AD329C020CD@oracle.com> Thanks Prasanta for the review. I have corrected the indentation problem. Please review the updated webrev. http://cr.openjdk.java.net/~mhalder/8216971/webrev.02/ Regards, Manajit > On 18-Mar-2019, at 11:21 AM, Prasanta Sadhukhan wrote: > > I guess l94-111 indentation in CMenuItem.m and l69 Robot robot = new Robot(); in testcase > is still not fixed. > Regards > Prasanta > On 15-Mar-19 4:51 PM, Manajit Halder wrote: >> Thanks Prasanta, >> >> I have corrected the indentation issue in both files. Please review the modified webrev. >> http://cr.openjdk.java.net/~mhalder/8216971/webrev.01/ >> >> Regards, >> Manajit >> >> >>> On 15-Mar-2019, at 11:32 AM, Prasanta Sadhukhan > wrote: >>> >>> fix looks fine to me but there are indentation issue both in fix and in testcase. Please rectify it. >>> Regards >>> Prasanta >>> On 12-Mar-19 6:46 PM, Krishna Addepalli wrote: >>>> Hi Manajit, >>>> >>>> Thanks for the clarification. The fix looks ok to me. >>>> >>>> Thanks, >>>> Krishna >>>> >>>>> On 12-Mar-2019, at 3:36 PM, Manajit Halder > wrote: >>>>> >>>>> Lines 74 to 82 explains why we need to ignore this call. This method should be ignored if it is called as a result of user pressing a shortcut and the window containing the menu is not minimized. >>>>> >>>>> Regards, >>>>> Manajit >>>>> >>>>> >>>>>> On 12-Mar-2019, at 3:16 PM, Krishna Addepalli > wrote: >>>>>> >>>>>> Hi Manajit, >>>>>> >>>>>> Thanks for the clarification. I think you should add some more comments around the statement at line86, to explain in more detail, about why to ignore this call. >>>>>> >>>>>> Thanks, >>>>>> Krishna >>>>>> >>>>>>> On 11-Mar-2019, at 2:25 PM, Manajit Halder > wrote: >>>>>>> >>>>>>> Hi Krishna, >>>>>>> >>>>>>> Thanks for the review comment. >>>>>>> >>>>>>> The key mapping is done by method setKeyEquivalent on fMenuItem (object of the NSMenuItem) in the same file. >>>>>>> >>>>>>> As discussed with you, the second key event is the problem here, and is caused only when System property ?apple.laf.useScreenMenuBar? is set to true. The extra event is generated in the handleAction method and my proposed fix is solving this issue. The difference with other look and feel setting or when ?apple.laf.useScreenMenuBar? is set to ?false? is that handleAction method is not called. I have verified and found that the META_MASK and CTRL_MASK are only set when ?apple.laf.useScreenMenuBar? is set to true and not in case of it is false. Also verified with ?metal? look and feel and found the MASKS are not set and handleAction method is not called and hence the extra key event is not generated. >>>>>>> >>>>>>> Please let me know if you have any other query. >>>>>>> >>>>>>> Regards, >>>>>>> Manajit >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 05-Mar-2019, at 4:52 PM, Krishna Addepalli > wrote: >>>>>>>> >>>>>>>> Hi Manajit, >>>>>>>> >>>>>>>> Per our discussion, The cause of the problem is : 1), Key Event being sent from the OS to the application - which the Java layer processes it correctly >>>>>>>> 2) The Mac OS calling the handleAction function directly on the NSMenutItem - although as per your description, there is no code which maps the hot key to this widget in the native layer. >>>>>>>> Ideally, since the OS is recognising the key combination, that key event should not be delivered again to the application. Or, it should be that the key event is not recognised and hence delivered to the application. >>>>>>>> >>>>>>>> Can you check why in this case, we are getting the key event as well as the handleAction from the OS? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Krishna >>>>>>>> >>>>>>>>> On 23-Feb-2019, at 9:14 PM, Manajit Halder > wrote: >>>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> Please review the fix for JDK13. >>>>>>>>> >>>>>>>>> Bug: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8216971 >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~mhalder/8216971/webrev.00/ >>>>>>>>> >>>>>>>>> Fix: >>>>>>>>> actionPerformed() was called twice due to wrong handling of key down event in method handleAction, which is corrected with this fix. >>>>>>>>> This change was added during fix of issue JDK-8152492. Apart from the changes required to fix the problem, code related to finding out >>>>>>>>> eventKey is removed as eventKey is no more used now. >>>>>>>>> >>>>>>>>> Note: >>>>>>>>> This issue is regression of bug 8152492, which was introduced in JDK release 9b120. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Manajit >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Mar 18 10:55:42 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 18 Mar 2019 16:25:42 +0530 Subject: [13] Review request for JDK-8216971: [macosx swing] For JCheckBoxMenuItem actionPerformed() is called twice, when apple.laf.useScreenMenuBar=true and modifier is InputEvent.META_DOWN_MASK In-Reply-To: <7B778B0E-8394-4BDB-92B2-9AD329C020CD@oracle.com> References: <52287ED0-64B7-4586-9D2F-F3912EE4057A@oracle.com> <72180FB8-168D-419D-A357-C75D7BF4E3D4@oracle.com> <29C7954A-4551-461E-825D-A87074612761@oracle.com> <4C9C2E09-ACFE-46AF-85AA-2FED1BF4EEFA@oracle.com> <740B7C3D-A720-4F1D-B59E-03F85C183543@oracle.com> <4b333319-7402-85f0-04e9-a340a95fac03@oracle.com> <7B778B0E-8394-4BDB-92B2-9AD329C020CD@oracle.com> Message-ID: Still 74 } finally { in testcase not fixed. Please fix it before pushing...No need to send webrev. Regards Prasanta On 18-Mar-19 4:12 PM, Manajit Halder wrote: > Thanks Prasanta for the review. I have corrected the indentation > problem. Please review the updated webrev. > http://cr.openjdk.java.net/~mhalder/8216971/webrev.02/ > > > Regards, > Manajit > >> On 18-Mar-2019, at 11:21 AM, Prasanta Sadhukhan >> > > wrote: >> >> I guess l94-111 indentation in CMenuItem.m and l69 Robot robot = new >> Robot(); in testcase >> >> is still not fixed. >> >> Regards >> Prasanta >> On 15-Mar-19 4:51 PM, Manajit Halder wrote: >>> Thanks Prasanta, >>> >>> I have corrected the indentation issue in both files. Please review >>> the modified webrev. >>> http://cr.openjdk.java.net/~mhalder/8216971/webrev.01/ >>> >>> >>> Regards, >>> Manajit >>> >>> >>>> On 15-Mar-2019, at 11:32 AM, Prasanta Sadhukhan >>>> >>> > wrote: >>>> >>>> fix looks fine to me but there are indentation issue both in fix >>>> and in testcase. Please rectify it. >>>> >>>> Regards >>>> Prasanta >>>> On 12-Mar-19 6:46 PM, Krishna Addepalli wrote: >>>>> Hi Manajit, >>>>> >>>>> Thanks for the clarification. The fix looks ok to me. >>>>> >>>>> Thanks, >>>>> Krishna >>>>> >>>>>> On 12-Mar-2019, at 3:36 PM, Manajit Halder >>>>>> > wrote: >>>>>> >>>>>> Lines 74 to 82 explains why we need to ignore this call. This >>>>>> method should be ignored if it is called as a result of user >>>>>> pressing ?a shortcut and the window containing the menu is not >>>>>> minimized. >>>>>> >>>>>> Regards, >>>>>> Manajit >>>>>> >>>>>> >>>>>>> On 12-Mar-2019, at 3:16 PM, Krishna Addepalli >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Hi Manajit, >>>>>>> >>>>>>> Thanks for the clarification. I think you should add some more >>>>>>> comments around the statement at line86, to explain in more >>>>>>> detail, about why to ignore this call. >>>>>>> >>>>>>> Thanks, >>>>>>> Krishna >>>>>>> >>>>>>>> On 11-Mar-2019, at 2:25 PM, Manajit Halder >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Krishna, >>>>>>>> >>>>>>>> Thanks for the review comment. >>>>>>>> >>>>>>>> The key mapping is done by method setKeyEquivalent on fMenuItem >>>>>>>> (object of the NSMenuItem) in the same file. >>>>>>>> >>>>>>>> As discussed with you, the second key event is the problem >>>>>>>> here, and is caused only when System property >>>>>>>> ?apple.laf.useScreenMenuBar? is set to true.?The extra event is >>>>>>>> generated in the handleAction method and my proposed fix is >>>>>>>> solving this issue. The difference with other look and feel >>>>>>>> setting or when ?apple.laf.useScreenMenuBar? is set to ?false? >>>>>>>> is that handleAction method is not called. I have verified and >>>>>>>> found that the?META_MASK and CTRL_MASK are only set when >>>>>>>> ?apple.laf.useScreenMenuBar? is set to true?and not in case of >>>>>>>> it is false. Also verified with ?metal? look and feel and found >>>>>>>> the MASKS are not set and handleAction method is not called and >>>>>>>> hence the extra key event is not generated. >>>>>>>> >>>>>>>> Please let me know if you have any other query. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Manajit >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 05-Mar-2019, at 4:52 PM, Krishna Addepalli >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> Hi Manajit, >>>>>>>>> >>>>>>>>> Per our discussion, The cause of the problem is : 1), Key >>>>>>>>> Event being sent from the OS to the application - which the >>>>>>>>> Java layer processes it correctly >>>>>>>>> 2) The Mac OS calling the handleAction function directly on >>>>>>>>> the NSMenutItem - although as per your description, there is >>>>>>>>> no code which maps the hot key to this widget in the native layer. >>>>>>>>> Ideally, since the OS is recognising the key combination, that >>>>>>>>> key event should not be delivered again to the application. >>>>>>>>> Or, it should be that the key event is not recognised and >>>>>>>>> hence delivered to the application. >>>>>>>>> >>>>>>>>> Can you check why in this case, we are getting the key event >>>>>>>>> as well as the handleAction from the OS? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Krishna >>>>>>>>> >>>>>>>>>> On 23-Feb-2019, at 9:14 PM, Manajit Halder >>>>>>>>>> >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> Please review the fix for JDK13. >>>>>>>>>> >>>>>>>>>> Bug: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8216971 >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~mhalder/8216971/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Fix: >>>>>>>>>> actionPerformed() was called twice due to wrong handling of >>>>>>>>>> key down event in method handleAction, which is corrected >>>>>>>>>> with this fix. >>>>>>>>>> This change was added during fix of issue JDK-8152492. Apart >>>>>>>>>> from the changes required to fix the problem, code related to >>>>>>>>>> finding out >>>>>>>>>> eventKey is removed as eventKey is no more used now. >>>>>>>>>> >>>>>>>>>> Note: >>>>>>>>>> This issue is regression of bug 8152492, which was introduced >>>>>>>>>> in JDK release 9b120. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Manajit >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From manajit.halder at oracle.com Mon Mar 18 12:40:57 2019 From: manajit.halder at oracle.com (Manajit Halder) Date: Mon, 18 Mar 2019 18:10:57 +0530 Subject: [13] Review request for JDK-8216971: [macosx swing] For JCheckBoxMenuItem actionPerformed() is called twice, when apple.laf.useScreenMenuBar=true and modifier is InputEvent.META_DOWN_MASK In-Reply-To: References: <52287ED0-64B7-4586-9D2F-F3912EE4057A@oracle.com> <72180FB8-168D-419D-A357-C75D7BF4E3D4@oracle.com> <29C7954A-4551-461E-825D-A87074612761@oracle.com> <4C9C2E09-ACFE-46AF-85AA-2FED1BF4EEFA@oracle.com> <740B7C3D-A720-4F1D-B59E-03F85C183543@oracle.com> <4b333319-7402-85f0-04e9-a340a95fac03@oracle.com> <7B778B0E-8394-4BDB-92B2-9AD329C020CD@oracle.com> Message-ID: <3A037F41-3F3C-471A-A1F0-79E6BE04925D@oracle.com> Thanks Prasanta, I have corrected the indentation issue. Also removed use of @build jdk.test.lib.Platform and replaced Platform.isOSX() with System.getProperty. Please review the updated webrev. http://cr.openjdk.java.net/~mhalder/8216971/webrev.03/ Regards, Manajit > On 18-Mar-2019, at 4:25 PM, Prasanta Sadhukhan wrote: > > Still > 74 } finally { > in testcase not fixed. Please fix it before pushing...No need to send webrev. > > Regards > Prasanta > On 18-Mar-19 4:12 PM, Manajit Halder wrote: >> Thanks Prasanta for the review. I have corrected the indentation problem. Please review the updated webrev. >> http://cr.openjdk.java.net/~mhalder/8216971/webrev.02/ >> >> Regards, >> Manajit >> >>> On 18-Mar-2019, at 11:21 AM, Prasanta Sadhukhan > wrote: >>> >>> I guess l94-111 indentation in CMenuItem.m and l69 Robot robot = new Robot(); in testcase >>> is still not fixed. >>> Regards >>> Prasanta >>> On 15-Mar-19 4:51 PM, Manajit Halder wrote: >>>> Thanks Prasanta, >>>> >>>> I have corrected the indentation issue in both files. Please review the modified webrev. >>>> http://cr.openjdk.java.net/~mhalder/8216971/webrev.01/ >>>> >>>> Regards, >>>> Manajit >>>> >>>> >>>>> On 15-Mar-2019, at 11:32 AM, Prasanta Sadhukhan > wrote: >>>>> >>>>> fix looks fine to me but there are indentation issue both in fix and in testcase. Please rectify it. >>>>> Regards >>>>> Prasanta >>>>> On 12-Mar-19 6:46 PM, Krishna Addepalli wrote: >>>>>> Hi Manajit, >>>>>> >>>>>> Thanks for the clarification. The fix looks ok to me. >>>>>> >>>>>> Thanks, >>>>>> Krishna >>>>>> >>>>>>> On 12-Mar-2019, at 3:36 PM, Manajit Halder > wrote: >>>>>>> >>>>>>> Lines 74 to 82 explains why we need to ignore this call. This method should be ignored if it is called as a result of user pressing a shortcut and the window containing the menu is not minimized. >>>>>>> >>>>>>> Regards, >>>>>>> Manajit >>>>>>> >>>>>>> >>>>>>>> On 12-Mar-2019, at 3:16 PM, Krishna Addepalli > wrote: >>>>>>>> >>>>>>>> Hi Manajit, >>>>>>>> >>>>>>>> Thanks for the clarification. I think you should add some more comments around the statement at line86, to explain in more detail, about why to ignore this call. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Krishna >>>>>>>> >>>>>>>>> On 11-Mar-2019, at 2:25 PM, Manajit Halder > wrote: >>>>>>>>> >>>>>>>>> Hi Krishna, >>>>>>>>> >>>>>>>>> Thanks for the review comment. >>>>>>>>> >>>>>>>>> The key mapping is done by method setKeyEquivalent on fMenuItem (object of the NSMenuItem) in the same file. >>>>>>>>> >>>>>>>>> As discussed with you, the second key event is the problem here, and is caused only when System property ?apple.laf.useScreenMenuBar? is set to true. The extra event is generated in the handleAction method and my proposed fix is solving this issue. The difference with other look and feel setting or when ?apple.laf.useScreenMenuBar? is set to ?false? is that handleAction method is not called. I have verified and found that the META_MASK and CTRL_MASK are only set when ?apple.laf.useScreenMenuBar? is set to true and not in case of it is false. Also verified with ?metal? look and feel and found the MASKS are not set and handleAction method is not called and hence the extra key event is not generated. >>>>>>>>> >>>>>>>>> Please let me know if you have any other query. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Manajit >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 05-Mar-2019, at 4:52 PM, Krishna Addepalli > wrote: >>>>>>>>>> >>>>>>>>>> Hi Manajit, >>>>>>>>>> >>>>>>>>>> Per our discussion, The cause of the problem is : 1), Key Event being sent from the OS to the application - which the Java layer processes it correctly >>>>>>>>>> 2) The Mac OS calling the handleAction function directly on the NSMenutItem - although as per your description, there is no code which maps the hot key to this widget in the native layer. >>>>>>>>>> Ideally, since the OS is recognising the key combination, that key event should not be delivered again to the application. Or, it should be that the key event is not recognised and hence delivered to the application. >>>>>>>>>> >>>>>>>>>> Can you check why in this case, we are getting the key event as well as the handleAction from the OS? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Krishna >>>>>>>>>> >>>>>>>>>>> On 23-Feb-2019, at 9:14 PM, Manajit Halder > wrote: >>>>>>>>>>> >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> Please review the fix for JDK13. >>>>>>>>>>> >>>>>>>>>>> Bug: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8216971 >>>>>>>>>>> >>>>>>>>>>> Webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~mhalder/8216971/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Fix: >>>>>>>>>>> actionPerformed() was called twice due to wrong handling of key down event in method handleAction, which is corrected with this fix. >>>>>>>>>>> This change was added during fix of issue JDK-8152492. Apart from the changes required to fix the problem, code related to finding out >>>>>>>>>>> eventKey is removed as eventKey is no more used now. >>>>>>>>>>> >>>>>>>>>>> Note: >>>>>>>>>>> This issue is regression of bug 8152492, which was introduced in JDK release 9b120. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Manajit >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Mar 19 05:27:07 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 19 Mar 2019 10:57:07 +0530 Subject: [13] Review request for JDK-8216971: [macosx swing] For JCheckBoxMenuItem actionPerformed() is called twice, when apple.laf.useScreenMenuBar=true and modifier is InputEvent.META_DOWN_MASK In-Reply-To: <3A037F41-3F3C-471A-A1F0-79E6BE04925D@oracle.com> References: <52287ED0-64B7-4586-9D2F-F3912EE4057A@oracle.com> <72180FB8-168D-419D-A357-C75D7BF4E3D4@oracle.com> <29C7954A-4551-461E-825D-A87074612761@oracle.com> <4C9C2E09-ACFE-46AF-85AA-2FED1BF4EEFA@oracle.com> <740B7C3D-A720-4F1D-B59E-03F85C183543@oracle.com> <4b333319-7402-85f0-04e9-a340a95fac03@oracle.com> <7B778B0E-8394-4BDB-92B2-9AD329C020CD@oracle.com> <3A037F41-3F3C-471A-A1F0-79E6BE04925D@oracle.com> Message-ID: Thanks for making the test really standalone as discussed but you can also remove 30 * @library /test/lib and 46 import jdk.test.lib.Platform; since you do not need them now. Rest looks ok. Regards Prasanta On 18-Mar-19 6:10 PM, Manajit Halder wrote: > Thanks Prasanta, I have corrected the indentation issue. Also removed > use of @build jdk.test.lib.Platform?and replaced Platform.isOSX() with > System.getProperty. > Please review the updated webrev. > http://cr.openjdk.java.net/~mhalder/8216971/webrev.03/ > > > Regards, > Manajit > >> On 18-Mar-2019, at 4:25 PM, Prasanta Sadhukhan >> > > wrote: >> >> Still >> >> 74 } finally { >> in testcase not fixed. Please fix it before pushing...No need to send >> webrev. >> >> Regards >> Prasanta >> On 18-Mar-19 4:12 PM, Manajit Halder wrote: >>> Thanks Prasanta for the review. I have corrected the indentation >>> problem. Please review the updated webrev. >>> http://cr.openjdk.java.net/~mhalder/8216971/webrev.02/ >>> >>> >>> Regards, >>> Manajit >>> >>>> On 18-Mar-2019, at 11:21 AM, Prasanta Sadhukhan >>>> >>> > wrote: >>>> >>>> I guess l94-111 indentation in CMenuItem.m and l69 Robot robot = >>>> new Robot(); in testcase >>>> >>>> is still not fixed. >>>> >>>> Regards >>>> Prasanta >>>> On 15-Mar-19 4:51 PM, Manajit Halder wrote: >>>>> Thanks Prasanta, >>>>> >>>>> I have corrected the indentation issue in both files. Please >>>>> review the modified webrev. >>>>> http://cr.openjdk.java.net/~mhalder/8216971/webrev.01/ >>>>> >>>>> >>>>> Regards, >>>>> Manajit >>>>> >>>>> >>>>>> On 15-Mar-2019, at 11:32 AM, Prasanta Sadhukhan >>>>>> >>>>> > wrote: >>>>>> >>>>>> fix looks fine to me but there are indentation issue both in fix >>>>>> and in testcase. Please rectify it. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 12-Mar-19 6:46 PM, Krishna Addepalli wrote: >>>>>>> Hi Manajit, >>>>>>> >>>>>>> Thanks for the clarification. The fix looks ok to me. >>>>>>> >>>>>>> Thanks, >>>>>>> Krishna >>>>>>> >>>>>>>> On 12-Mar-2019, at 3:36 PM, Manajit Halder >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> Lines 74 to 82 explains why we need to ignore this call. This >>>>>>>> method should be ignored if it is called as a result of user >>>>>>>> pressing ?a shortcut and the window containing the menu is not >>>>>>>> minimized. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Manajit >>>>>>>> >>>>>>>> >>>>>>>>> On 12-Mar-2019, at 3:16 PM, Krishna Addepalli >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> Hi Manajit, >>>>>>>>> >>>>>>>>> Thanks for the clarification. I think you should add some more >>>>>>>>> comments around the statement at line86, to explain in more >>>>>>>>> detail, about why to ignore this call. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Krishna >>>>>>>>> >>>>>>>>>> On 11-Mar-2019, at 2:25 PM, Manajit Halder >>>>>>>>>> >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> Hi Krishna, >>>>>>>>>> >>>>>>>>>> Thanks for the review comment. >>>>>>>>>> >>>>>>>>>> The key mapping is done by method setKeyEquivalent on >>>>>>>>>> fMenuItem (object of the NSMenuItem) in the same file. >>>>>>>>>> >>>>>>>>>> As discussed with you, the second key event is the problem >>>>>>>>>> here, and is caused only when System property >>>>>>>>>> ?apple.laf.useScreenMenuBar? is set to true.?The extra event >>>>>>>>>> is generated in the handleAction method and my proposed fix >>>>>>>>>> is solving this issue. The difference with other look and >>>>>>>>>> feel setting or when ?apple.laf.useScreenMenuBar? is set to >>>>>>>>>> ?false? is that handleAction method is not called. I have >>>>>>>>>> verified and found that the?META_MASK and CTRL_MASK are only >>>>>>>>>> set when ?apple.laf.useScreenMenuBar? is set to true?and not >>>>>>>>>> in case of it is false. Also verified with ?metal? look and >>>>>>>>>> feel and found the MASKS are not set and handleAction method >>>>>>>>>> is not called and hence the extra key event is not generated. >>>>>>>>>> >>>>>>>>>> Please let me know if you have any other query. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Manajit >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 05-Mar-2019, at 4:52 PM, Krishna Addepalli >>>>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Manajit, >>>>>>>>>>> >>>>>>>>>>> Per our discussion, The cause of the problem is : 1), Key >>>>>>>>>>> Event being sent from the OS to the application - which the >>>>>>>>>>> Java layer processes it correctly >>>>>>>>>>> 2) The Mac OS calling the handleAction function directly on >>>>>>>>>>> the NSMenutItem - although as per your description, there is >>>>>>>>>>> no code which maps the hot key to this widget in the native >>>>>>>>>>> layer. >>>>>>>>>>> Ideally, since the OS is recognising the key combination, >>>>>>>>>>> that key event should not be delivered again to the >>>>>>>>>>> application. Or, it should be that the key event is not >>>>>>>>>>> recognised and hence delivered to the application. >>>>>>>>>>> >>>>>>>>>>> Can you check why in this case, we are getting the key event >>>>>>>>>>> as well as the handleAction from the OS? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Krishna >>>>>>>>>>> >>>>>>>>>>>> On 23-Feb-2019, at 9:14 PM, Manajit Halder >>>>>>>>>>>> >>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi All, >>>>>>>>>>>> >>>>>>>>>>>> Please review the fix for JDK13. >>>>>>>>>>>> >>>>>>>>>>>> Bug: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8216971 >>>>>>>>>>>> >>>>>>>>>>>> Webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~mhalder/8216971/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Fix: >>>>>>>>>>>> actionPerformed() was called twice due to wrong handling of >>>>>>>>>>>> key down event in method handleAction, which is corrected >>>>>>>>>>>> with this fix. >>>>>>>>>>>> This change was added during fix of issue JDK-8152492. >>>>>>>>>>>> Apart from the changes required to fix the problem, code >>>>>>>>>>>> related to finding out >>>>>>>>>>>> eventKey is removed as eventKey is no more used now. >>>>>>>>>>>> >>>>>>>>>>>> Note: >>>>>>>>>>>> This issue is regression of bug 8152492, which was >>>>>>>>>>>> introduced in JDK release 9b120. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Manajit >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Mar 19 07:03:12 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 19 Mar 2019 12:33:12 +0530 Subject: [13] RFR JDK-8212904:JTextArea line wrapping incorrect when using UI scale Message-ID: <5e3cb36e-fdad-b2ce-4774-f516fd37b420@oracle.com> Hi All, Please review a fix for an issue where it is seen that line wrapping of JTextArea doen't work correctly if you set wrapStyleWord = true and you use a UI scale (either by setting "sun.java2d.uiScale" or by setting display scale of Windows) It is a regression of JDK-8132119: Provide public API for text related methods in SwingUtilities2 where many public text related API was added catering to floating point hidpi scale. This issue happened because of that as the public Utilities.getBreakLocation() API, used to determine where to break the given text, is using non-floating point methods. Proposed fix is to make sure correct getBreakLocation() method is called and not the deprecated(integer based) one and also the floating point based getBreakLocation() API uses floating point API based calculations. Bug: https://bugs.openjdk.java.net/browse/JDK-8212904 webrev: http://cr.openjdk.java.net/~psadhukhan/8212904/webrev.0/ Regards Prasanta From prasanta.sadhukhan at oracle.com Tue Mar 19 10:41:03 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 19 Mar 2019 16:11:03 +0530 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> <5C81E5D1.8040504@oracle.com> <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> <57966237-35cd-0cde-c195-ed4af73091ee@oracle.com> <5C84B5CE.30904@oracle.com> <597c27ce-cc0f-11de-da41-7152cdf217be@oracle.com> <03eb91ca-0a9c-a434-2088-08be7cd19280@oracle.com> Message-ID: <9d697892-f42a-081c-9d0c-1add2b6ea4f6@oracle.com> Hi Alexey, Your points are valid so I modified those in this webrev, please have a look http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.3/ Regards Prasanta On 15-Mar-19 10:28 PM, Alexey Ivanov wrote: > Hi Prasanta, > > On 15/03/2019 05:15, Prasanta Sadhukhan wrote: >> >> Hi Alexey, >> >> >> On 13-Mar-19 6:10 PM, Alexey Ivanov wrote: >>> Hi guys, >>> >>> This is more of a general comment rather than targeted at this >>> particular change. Sorry if I missed any previous discussion on that >>> matter. >>> >>> I think it's good to have consistent headings without skipping levels. >>> >>> Yet

in the Javadoc comments does not seem right. Let's take a >>> look at JTable for example: >>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs.webrev2/docs/api/java.desktop/javax/swing/JTable.html >>> >>> >>> The page starts with

JTable

. This is the highest heading >>> level on the page, I haven't found any

. >> As for this changeset, I am following the rules set in the >> https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002671.html >> - headings in documentation comments for modules, packages and types >> should start at

- > > Thank you for clarification. I've seen a few fixes in this area but I > missed this discussion. > > So the main type heading will be

, i.e. it will

JTable

. > Therefore starting at

in types makes sense. > >>> Later on,

Method Detail

. And a specific method: >>>

doLayout

. Since the entire method description is under

>>> heading, it should not use any headings above

. But now we have >>>

and

which kind-of start new sections rather than being >>> part of

which describes the method. >> I have only changed to make sure there are no missing headings ie >> start with h2 (as stated above) and change previously used h4 to >> h3(to make sure no missing heading), rest were as it was earlier. > > According to the message you linked to, the documentation comments for > methods should start at

. > > Here's the relevant quote: > ?Headings in documentation comments for modules, packages and types > should start at

; > Headings in documentation comments for members of a type (field, > constructor, method, etc) should start at

. > > (I've changed formatting to separate these two cases.) > > > Thus in *JTable.java* you should rather decrease heading level as the > headings are used in /method/ as opposed to /type/ in the majority of > other cases: > -3053????? *

Distributing the delta

> +3053????? *

Distributing the delta

> > -3055????? *

Overview

> +3055????? *
Overview
> > And the remaining

become

: > 3064????? *

Definition

> 3096????? *

Details

> 3107????? *

When the MAX and MIN bounds are hit

> > > As for the rest of the review: > > *Font.java* > > You changed the first

to

: > -77? *

Characters and Glyphs

> +77? *

Characters and Glyphs

> > But why not other headings? All of the headings were at the same > level, but they're not. > > These should also go up to

: > ?99? *

Physical and Logical Fonts

> 138? *

Font Faces and Names

> 172? *

Font and TextAttribute

> > > *javax/print/attribute/package-info.java* > > 204? *

Attribute Class Design

> 298? *

Attribute Vendors

> 324? *

Using Attributes

> > These should also go one level up to

as other headings. > These used to be separate sections but now they're subsections of > 131? *

Attribute Sets

> which does not seem correct. > > > Regards, > Alexey > >> >> Regards >> Prasanta >>> >>> Is such heading sequence intended? >>> >>> Regards, >>> Alexey >>> >>> On 13/03/2019 06:10, Prasanta Sadhukhan wrote: >>>> Any more comments on this >>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.2/ >>>> >>>> Regards >>>> Prasanta >>>> On 11-Mar-19 2:16 PM, Prasanta Sadhukhan wrote: >>>>> The 2nd URL is based on webrev.1. I have placed new docs for >>>>> webrev.2 here >>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs.webrev2/docs/api/java.desktop/module-summary.html >>>>> >>>>> >>>>> Regards >>>>> Prasanta >>>>> > From jonathan.gibbons at oracle.com Tue Mar 19 17:28:34 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 19 Mar 2019 10:28:34 -0700 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: <9d697892-f42a-081c-9d0c-1add2b6ea4f6@oracle.com> References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> <5C81E5D1.8040504@oracle.com> <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> <57966237-35cd-0cde-c195-ed4af73091ee@oracle.com> <5C84B5CE.30904@oracle.com> <597c27ce-cc0f-11de-da41-7152cdf217be@oracle.com> <03eb91ca-0a9c-a434-2088-08be7cd19280@oracle.com> <9d697892-f42a-081c-9d0c-1add2b6ea4f6@oracle.com> Message-ID: Prasanta, Note that if you believe you have fixed all the heading issues in the java.desktop module, you can re-enable the doclint checks for the module by removing "-accessibility" from the java.desktop line in make/CompileJavaModules.gmk make/CompileJavaModules.gmk:java.desktop_ADD_JAVAC_FLAGS += -Xdoclint:all/protected,-reference,-accessibility \ If you do remove the option, make sure to run a build to verify that doclint does not find any unfixed errors, which will prevent the build from completing successfully. -- Jon On 3/19/19 3:41 AM, Prasanta Sadhukhan wrote: > Hi Alexey, > > Your points are valid so I modified those in this webrev, please have > a look > http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.3/ > > Regards > Prasanta > On 15-Mar-19 10:28 PM, Alexey Ivanov wrote: >> Hi Prasanta, >> >> On 15/03/2019 05:15, Prasanta Sadhukhan wrote: >>> >>> Hi Alexey, >>> >>> >>> On 13-Mar-19 6:10 PM, Alexey Ivanov wrote: >>>> Hi guys, >>>> >>>> This is more of a general comment rather than targeted at this >>>> particular change. Sorry if I missed any previous discussion on >>>> that matter. >>>> >>>> I think it's good to have consistent headings without skipping levels. >>>> >>>> Yet

in the Javadoc comments does not seem right. Let's take a >>>> look at JTable for example: >>>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs.webrev2/docs/api/java.desktop/javax/swing/JTable.html >>>> >>>> >>>> The page starts with

JTable

. This is the highest heading >>>> level on the page, I haven't found any

. >>> As for this changeset, I am following the rules set in the >>> https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002671.html >>> - headings in documentation comments for modules, packages and types >>> should start at

- >> >> Thank you for clarification. I've seen a few fixes in this area but I >> missed this discussion. >> >> So the main type heading will be

, i.e. it will

JTable

. >> Therefore starting at

in types makes sense. >> >>>> Later on,

Method Detail

. And a specific method: >>>>

doLayout

. Since the entire method description is under >>>>

heading, it should not use any headings above

. But now we >>>> have

and

which kind-of start new sections rather than >>>> being part of

which describes the method. >>> I have only changed to make sure there are no missing headings ie >>> start with h2 (as stated above) and change previously used h4 to >>> h3(to make sure no missing heading), rest were as it was earlier. >> >> According to the message you linked to, the documentation comments >> for methods should start at

. >> >> Here's the relevant quote: >> ?Headings in documentation comments for modules, packages and types >> should start at

; >> Headings in documentation comments for members of a type (field, >> constructor, method, etc) should start at

. >> >> (I've changed formatting to separate these two cases.) >> >> >> Thus in *JTable.java* you should rather decrease heading level as the >> headings are used in /method/ as opposed to /type/ in the majority of >> other cases: >> -3053????? *

Distributing the delta

>> +3053????? *

Distributing the delta

>> >> -3055????? *

Overview

>> +3055????? *
Overview
>> >> And the remaining

become

: >> 3064????? *

Definition

>> 3096????? *

Details

>> 3107????? *

When the MAX and MIN bounds are hit

>> >> >> As for the rest of the review: >> >> *Font.java* >> >> You changed the first

to

: >> -77? *

Characters and Glyphs

>> +77? *

Characters and Glyphs

>> >> But why not other headings? All of the headings were at the same >> level, but they're not. >> >> These should also go up to

: >> ?99? *

Physical and Logical Fonts

>> 138? *

Font Faces and Names

>> 172? *

Font and TextAttribute

>> >> >> *javax/print/attribute/package-info.java* >> >> 204? *

Attribute Class Design

>> 298? *

Attribute Vendors

>> 324? *

Using Attributes

>> >> These should also go one level up to

as other headings. >> These used to be separate sections but now they're subsections of >> 131? *

Attribute Sets

>> which does not seem correct. >> >> >> Regards, >> Alexey >> >>> >>> Regards >>> Prasanta >>>> >>>> Is such heading sequence intended? >>>> >>>> Regards, >>>> Alexey >>>> >>>> On 13/03/2019 06:10, Prasanta Sadhukhan wrote: >>>>> Any more comments on this >>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.2/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 11-Mar-19 2:16 PM, Prasanta Sadhukhan wrote: >>>>>> The 2nd URL is based on webrev.1. I have placed new docs for >>>>>> webrev.2 here >>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs.webrev2/docs/api/java.desktop/module-summary.html >>>>>> >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> >> > From alexey.ivanov at oracle.com Wed Mar 20 12:28:04 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 20 Mar 2019 12:28:04 +0000 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: <9d697892-f42a-081c-9d0c-1add2b6ea4f6@oracle.com> References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> <5C81E5D1.8040504@oracle.com> <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> <57966237-35cd-0cde-c195-ed4af73091ee@oracle.com> <5C84B5CE.30904@oracle.com> <597c27ce-cc0f-11de-da41-7152cdf217be@oracle.com> <03eb91ca-0a9c-a434-2088-08be7cd19280@oracle.com> <9d697892-f42a-081c-9d0c-1add2b6ea4f6@oracle.com> Message-ID: <4d99fdf9-b5f9-b670-35e1-e8199778636b@oracle.com> Hi Prasanta, Looks fine. Regards, Alexey On 19/03/2019 10:41, Prasanta Sadhukhan wrote: > Hi Alexey, > > Your points are valid so I modified those in this webrev, please have > a look > http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.3/ > > Regards > Prasanta > On 15-Mar-19 10:28 PM, Alexey Ivanov wrote: >> Hi Prasanta, >> >> On 15/03/2019 05:15, Prasanta Sadhukhan wrote: >>> >>> Hi Alexey, >>> >>> >>> On 13-Mar-19 6:10 PM, Alexey Ivanov wrote: >>>> Hi guys, >>>> >>>> This is more of a general comment rather than targeted at this >>>> particular change. Sorry if I missed any previous discussion on >>>> that matter. >>>> >>>> I think it's good to have consistent headings without skipping levels. >>>> >>>> Yet

in the Javadoc comments does not seem right. Let's take a >>>> look at JTable for example: >>>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs.webrev2/docs/api/java.desktop/javax/swing/JTable.html >>>> >>>> >>>> The page starts with

JTable

. This is the highest heading >>>> level on the page, I haven't found any

. >>> As for this changeset, I am following the rules set in the >>> https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002671.html >>> - headings in documentation comments for modules, packages and types >>> should start at

- >> >> Thank you for clarification. I've seen a few fixes in this area but I >> missed this discussion. >> >> So the main type heading will be

, i.e. it will

JTable

. >> Therefore starting at

in types makes sense. >> >>>> Later on,

Method Detail

. And a specific method: >>>>

doLayout

. Since the entire method description is under >>>>

heading, it should not use any headings above

. But now we >>>> have

and

which kind-of start new sections rather than >>>> being part of

which describes the method. >>> I have only changed to make sure there are no missing headings ie >>> start with h2 (as stated above) and change previously used h4 to >>> h3(to make sure no missing heading), rest were as it was earlier. >> >> According to the message you linked to, the documentation comments >> for methods should start at

. >> >> Here's the relevant quote: >> ?Headings in documentation comments for modules, packages and types >> should start at

; >> Headings in documentation comments for members of a type (field, >> constructor, method, etc) should start at

. >> >> (I've changed formatting to separate these two cases.) >> >> >> Thus in *JTable.java* you should rather decrease heading level as the >> headings are used in /method/ as opposed to /type/ in the majority of >> other cases: >> -3053????? *

Distributing the delta

>> +3053????? *

Distributing the delta

>> >> -3055????? *

Overview

>> +3055????? *
Overview
>> >> And the remaining

become

: >> 3064????? *

Definition

>> 3096????? *

Details

>> 3107????? *

When the MAX and MIN bounds are hit

>> >> >> As for the rest of the review: >> >> *Font.java* >> >> You changed the first

to

: >> -77? *

Characters and Glyphs

>> +77? *

Characters and Glyphs

>> >> But why not other headings? All of the headings were at the same >> level, but they're not. >> >> These should also go up to

: >> ?99? *

Physical and Logical Fonts

>> 138? *

Font Faces and Names

>> 172? *

Font and TextAttribute

>> >> >> *javax/print/attribute/package-info.java* >> >> 204? *

Attribute Class Design

>> 298? *

Attribute Vendors

>> 324? *

Using Attributes

>> >> These should also go one level up to

as other headings. >> These used to be separate sections but now they're subsections of >> 131? *

Attribute Sets

>> which does not seem correct. >> >> >> Regards, >> Alexey >> >>> >>> Regards >>> Prasanta >>>> >>>> Is such heading sequence intended? >>>> >>>> Regards, >>>> Alexey >>>> >>>> On 13/03/2019 06:10, Prasanta Sadhukhan wrote: >>>>> Any more comments on this >>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.2/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 11-Mar-19 2:16 PM, Prasanta Sadhukhan wrote: >>>>>> The 2nd URL is based on webrev.1. I have placed new docs for >>>>>> webrev.2 here >>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs.webrev2/docs/api/java.desktop/module-summary.html >>>>>> >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> >> > From Sergey.Bylokhov at oracle.com Wed Mar 20 22:54:47 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 20 Mar 2019 15:54:47 -0700 Subject: [13] RFR JDK-8212904:JTextArea line wrapping incorrect when using UI scale In-Reply-To: <5e3cb36e-fdad-b2ce-4774-f516fd37b420@oracle.com> References: <5e3cb36e-fdad-b2ce-4774-f516fd37b420@oracle.com> Message-ID: <1d54eee0-63bc-ed48-fa06-aa250510b12f@oracle.com> Hi, Prasanta. The change looks fine, but probably the test can be automated? I guess when "wrap" works properly you should get more lines in the text area, than in case of broken "wrap"? On 19/03/2019 00:03, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue where it is seen that > line wrapping of JTextArea doen't work correctly if you set wrapStyleWord = true and you use a UI scale (either by setting "sun.java2d.uiScale" or by setting display scale of Windows) > > It is a regression of JDK-8132119: Provide public API for text related methods in SwingUtilities2 > where many public text related API was added catering to floating point hidpi scale. > This issue happened because of that as the public Utilities.getBreakLocation() API, used to determine where to break the given text, is using non-floating point methods. > > Proposed fix is to make sure correct getBreakLocation() method is called and not the deprecated(integer based) one > and also the floating point based getBreakLocation() API uses floating point API based calculations. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212904 > webrev: http://cr.openjdk.java.net/~psadhukhan/8212904/webrev.0/ > > Regards > Prasanta -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Thu Mar 21 10:23:44 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 21 Mar 2019 15:53:44 +0530 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> <5C81E5D1.8040504@oracle.com> <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> <57966237-35cd-0cde-c195-ed4af73091ee@oracle.com> <5C84B5CE.30904@oracle.com> <597c27ce-cc0f-11de-da41-7152cdf217be@oracle.com> <03eb91ca-0a9c-a434-2088-08be7cd19280@oracle.com> <9d697892-f42a-081c-9d0c-1add2b6ea4f6@oracle.com> Message-ID: FYI...it does build fine with this build change. Regards Prasanta On 19-Mar-19 10:58 PM, Jonathan Gibbons wrote: > Prasanta, > > Note that if you believe you have fixed all the heading issues in the > java.desktop module, > you can re-enable the doclint checks for the module by removing > "-accessibility" from > the java.desktop line in make/CompileJavaModules.gmk > > make/CompileJavaModules.gmk:java.desktop_ADD_JAVAC_FLAGS += > -Xdoclint:all/protected,-reference,-accessibility \ > > If you do remove the option, make sure to run a build to verify that > doclint does not > find any unfixed errors, which will prevent the build from completing > successfully. > > -- Jon > > On 3/19/19 3:41 AM, Prasanta Sadhukhan wrote: >> Hi Alexey, >> >> Your points are valid so I modified those in this webrev, please have >> a look >> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.3/ >> >> Regards >> Prasanta >> On 15-Mar-19 10:28 PM, Alexey Ivanov wrote: >>> Hi Prasanta, >>> >>> On 15/03/2019 05:15, Prasanta Sadhukhan wrote: >>>> >>>> Hi Alexey, >>>> >>>> >>>> On 13-Mar-19 6:10 PM, Alexey Ivanov wrote: >>>>> Hi guys, >>>>> >>>>> This is more of a general comment rather than targeted at this >>>>> particular change. Sorry if I missed any previous discussion on >>>>> that matter. >>>>> >>>>> I think it's good to have consistent headings without skipping >>>>> levels. >>>>> >>>>> Yet

in the Javadoc comments does not seem right. Let's take a >>>>> look at JTable for example: >>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs.webrev2/docs/api/java.desktop/javax/swing/JTable.html >>>>> >>>>> >>>>> The page starts with

JTable

. This is the highest heading >>>>> level on the page, I haven't found any

. >>>> As for this changeset, I am following the rules set in the >>>> https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002671.html >>>> - headings in documentation comments for modules, packages and >>>> types should start at

- >>> >>> Thank you for clarification. I've seen a few fixes in this area but >>> I missed this discussion. >>> >>> So the main type heading will be

, i.e. it will

JTable

. >>> Therefore starting at

in types makes sense. >>> >>>>> Later on,

Method Detail

. And a specific method: >>>>>

doLayout

. Since the entire method description is under >>>>>

heading, it should not use any headings above

. But now >>>>> we have

and

which kind-of start new sections rather than >>>>> being part of

which describes the method. >>>> I have only changed to make sure there are no missing headings ie >>>> start with h2 (as stated above) and change previously used h4 to >>>> h3(to make sure no missing heading), rest were as it was earlier. >>> >>> According to the message you linked to, the documentation comments >>> for methods should start at

. >>> >>> Here's the relevant quote: >>> ?Headings in documentation comments for modules, packages and types >>> should start at

; >>> Headings in documentation comments for members of a type (field, >>> constructor, method, etc) should start at

. >>> >>> (I've changed formatting to separate these two cases.) >>> >>> >>> Thus in *JTable.java* you should rather decrease heading level as >>> the headings are used in /method/ as opposed to /type/ in the >>> majority of other cases: >>> -3053????? *

Distributing the delta

>>> +3053????? *

Distributing the delta

>>> >>> -3055????? *

Overview

>>> +3055????? *
Overview
>>> >>> And the remaining

become

: >>> 3064????? *

Definition

>>> 3096????? *

Details

>>> 3107????? *

When the MAX and MIN bounds are hit

>>> >>> >>> As for the rest of the review: >>> >>> *Font.java* >>> >>> You changed the first

to

: >>> -77? *

Characters and Glyphs

>>> +77? *

Characters and Glyphs

>>> >>> But why not other headings? All of the headings were at the same >>> level, but they're not. >>> >>> These should also go up to

: >>> ?99? *

Physical and Logical Fonts

>>> 138? *

Font Faces and Names

>>> 172? *

Font and TextAttribute

>>> >>> >>> *javax/print/attribute/package-info.java* >>> >>> 204? *

Attribute Class Design

>>> 298? *

Attribute Vendors

>>> 324? *

Using Attributes

>>> >>> These should also go one level up to

as other headings. >>> These used to be separate sections but now they're subsections of >>> 131? *

Attribute Sets

>>> which does not seem correct. >>> >>> >>> Regards, >>> Alexey >>> >>>> >>>> Regards >>>> Prasanta >>>>> >>>>> Is such heading sequence intended? >>>>> >>>>> Regards, >>>>> Alexey >>>>> >>>>> On 13/03/2019 06:10, Prasanta Sadhukhan wrote: >>>>>> Any more comments on this >>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.2/ >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 11-Mar-19 2:16 PM, Prasanta Sadhukhan wrote: >>>>>>> The 2nd URL is based on webrev.1. I have placed new docs for >>>>>>> webrev.2 here >>>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs.webrev2/docs/api/java.desktop/module-summary.html >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> >>> >> From jonathan.gibbons at oracle.com Thu Mar 21 15:03:13 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 21 Mar 2019 08:03:13 -0700 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> <5C81E5D1.8040504@oracle.com> <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> <57966237-35cd-0cde-c195-ed4af73091ee@oracle.com> <5C84B5CE.30904@oracle.com> <597c27ce-cc0f-11de-da41-7152cdf217be@oracle.com> <03eb91ca-0a9c-a434-2088-08be7cd19280@oracle.com> <9d697892-f42a-081c-9d0c-1add2b6ea4f6@oracle.com> Message-ID: Sounds good; note you should cc: build-dev at ojn for changes to build files. -- Jon On 3/21/19 3:23 AM, Prasanta Sadhukhan wrote: > FYI...it does build fine with this build change. > > Regards > Prasanta > On 19-Mar-19 10:58 PM, Jonathan Gibbons wrote: >> Prasanta, >> >> Note that if you believe you have fixed all the heading issues in the >> java.desktop module, >> you can re-enable the doclint checks for the module by removing >> "-accessibility" from >> the java.desktop line in make/CompileJavaModules.gmk >> >> make/CompileJavaModules.gmk:java.desktop_ADD_JAVAC_FLAGS += >> -Xdoclint:all/protected,-reference,-accessibility \ >> >> If you do remove the option, make sure to run a build to verify that >> doclint does not >> find any unfixed errors, which will prevent the build from completing >> successfully. >> >> -- Jon >> >> On 3/19/19 3:41 AM, Prasanta Sadhukhan wrote: >>> Hi Alexey, >>> >>> Your points are valid so I modified those in this webrev, please >>> have a look >>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.3/ >>> >>> Regards >>> Prasanta >>> On 15-Mar-19 10:28 PM, Alexey Ivanov wrote: >>>> Hi Prasanta, >>>> >>>> On 15/03/2019 05:15, Prasanta Sadhukhan wrote: >>>>> >>>>> Hi Alexey, >>>>> >>>>> >>>>> On 13-Mar-19 6:10 PM, Alexey Ivanov wrote: >>>>>> Hi guys, >>>>>> >>>>>> This is more of a general comment rather than targeted at this >>>>>> particular change. Sorry if I missed any previous discussion on >>>>>> that matter. >>>>>> >>>>>> I think it's good to have consistent headings without skipping >>>>>> levels. >>>>>> >>>>>> Yet

in the Javadoc comments does not seem right. Let's take >>>>>> a look at JTable for example: >>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs.webrev2/docs/api/java.desktop/javax/swing/JTable.html >>>>>> >>>>>> >>>>>> The page starts with

JTable

. This is the highest heading >>>>>> level on the page, I haven't found any

. >>>>> As for this changeset, I am following the rules set in the >>>>> https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002671.html >>>>> >>>>> - headings in documentation comments for modules, packages and >>>>> types should start at

- >>>> >>>> Thank you for clarification. I've seen a few fixes in this area but >>>> I missed this discussion. >>>> >>>> So the main type heading will be

, i.e. it will >>>>

JTable

. Therefore starting at

in types makes sense. >>>> >>>>>> Later on,

Method Detail

. And a specific method: >>>>>>

doLayout

. Since the entire method description is under >>>>>>

heading, it should not use any headings above

. But now >>>>>> we have

and

which kind-of start new sections rather >>>>>> than being part of

which describes the method. >>>>> I have only changed to make sure there are no missing headings ie >>>>> start with h2 (as stated above) and change previously used h4 to >>>>> h3(to make sure no missing heading), rest were as it was earlier. >>>> >>>> According to the message you linked to, the documentation comments >>>> for methods should start at

. >>>> >>>> Here's the relevant quote: >>>> ?Headings in documentation comments for modules, packages and types >>>> should start at

; >>>> Headings in documentation comments for members of a type (field, >>>> constructor, method, etc) should start at

. >>>> >>>> (I've changed formatting to separate these two cases.) >>>> >>>> >>>> Thus in *JTable.java* you should rather decrease heading level as >>>> the headings are used in /method/ as opposed to /type/ in the >>>> majority of other cases: >>>> -3053????? *

Distributing the delta

>>>> +3053????? *

Distributing the delta

>>>> >>>> -3055????? *

Overview

>>>> +3055????? *
Overview
>>>> >>>> And the remaining

become

: >>>> 3064????? *

Definition

>>>> 3096????? *

Details

>>>> 3107????? *

When the MAX and MIN bounds are hit

>>>> >>>> >>>> As for the rest of the review: >>>> >>>> *Font.java* >>>> >>>> You changed the first

to

: >>>> -77? *

Characters and Glyphs

>>>> +77? *

Characters and Glyphs

>>>> >>>> But why not other headings? All of the headings were at the same >>>> level, but they're not. >>>> >>>> These should also go up to

: >>>> ?99? *

Physical and Logical Fonts

>>>> 138? *

Font Faces and Names

>>>> 172? *

Font and TextAttribute

>>>> >>>> >>>> *javax/print/attribute/package-info.java* >>>> >>>> 204? *

Attribute Class Design

>>>> 298? *

Attribute Vendors

>>>> 324? *

Using Attributes

>>>> >>>> These should also go one level up to

as other headings. >>>> These used to be separate sections but now they're subsections of >>>> 131? *

Attribute Sets

>>>> which does not seem correct. >>>> >>>> >>>> Regards, >>>> Alexey >>>> >>>>> >>>>> Regards >>>>> Prasanta >>>>>> >>>>>> Is such heading sequence intended? >>>>>> >>>>>> Regards, >>>>>> Alexey >>>>>> >>>>>> On 13/03/2019 06:10, Prasanta Sadhukhan wrote: >>>>>>> Any more comments on this >>>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.2/ >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 11-Mar-19 2:16 PM, Prasanta Sadhukhan wrote: >>>>>>>> The 2nd URL is based on webrev.1. I have placed new docs for >>>>>>>> webrev.2 here >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs.webrev2/docs/api/java.desktop/module-summary.html >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> >>>> >>> > From philip.race at oracle.com Thu Mar 21 20:57:08 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 21 Mar 2019 13:57:08 -0700 Subject: [13] Review Request: 8177960 Deprecate the Swing Motif Look and Feel and document it as unsupported on macOS In-Reply-To: References: <83592c70-6b39-d718-436d-65238c8a466c@oracle.com> Message-ID: <5C93FAA4.9040402@oracle.com> Yes, please push this - the CSR is approved -phil On 3/4/19, 8:25 PM, Prasanta Sadhukhan wrote: > Looks good to me. > > Regards > Prasanta > On 05-Mar-19 6:17 AM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for JDK 13. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8177960 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8218637 >> Fix: http://cr.openjdk.java.net/~serb/8177960/webrev.01 >> >> This is a request to deprecate the Swing Motif Look and Feel, >> and document it as unsupported on macOS platform in JDK 13. >> >> The Motif L&F has long been part of the Swing implementation >> shipped with the JDK, although unlike L&Fs such as Metal and >> Nimbus it is not exposed in Java APIs and not part of the Java SE >> specification. >> >> This look and feel was implemented as the System look and feel for the >> Solaris platform at time when the CDE/Motif environment was used the >> principal supported desktop environment. But it was placed in shared >> code >> and provided and supported on all platforms including Windows and >> later macOS. >> >> Since it is superseded as a system L&F by the GTK L&F and has limited >> use and >> additionally as a L&F is very dated visually, we would like to >> discourage further use. >> >> Note in some future release we may remove it completely, or we may >> remove >> it from the shared code to stop distributing it on Windows and macOS. >> These are mentioned here to give the most possible notice of such >> possible additional changes. >> > From prasanta.sadhukhan at oracle.com Fri Mar 22 04:28:19 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 22 Mar 2019 09:58:19 +0530 Subject: [13] RFR JDK-8220250: fix headings in java.desktop In-Reply-To: References: <7bd326ca-93f7-7de9-de50-84fcf0f286b6@oracle.com> <5C81E5D1.8040504@oracle.com> <3c68fe28-bf6e-8311-5818-a1ea30d6328e@oracle.com> <57966237-35cd-0cde-c195-ed4af73091ee@oracle.com> <5C84B5CE.30904@oracle.com> <597c27ce-cc0f-11de-da41-7152cdf217be@oracle.com> <03eb91ca-0a9c-a434-2088-08be7cd19280@oracle.com> <9d697892-f42a-081c-9d0c-1add2b6ea4f6@oracle.com> Message-ID: <2a597f85-2d80-851c-fc78-1471f5fda422@oracle.com> I have not changed any build files. I only modified CompileJavaModules to see if it builds fine as was asked for. Regards Prasanta On 21-Mar-19 8:33 PM, Jonathan Gibbons wrote: > Sounds good; note you should cc: build-dev at ojn for changes to build > files. > > -- Jon > > On 3/21/19 3:23 AM, Prasanta Sadhukhan wrote: >> FYI...it does build fine with this build change. >> >> Regards >> Prasanta >> On 19-Mar-19 10:58 PM, Jonathan Gibbons wrote: >>> Prasanta, >>> >>> Note that if you believe you have fixed all the heading issues in >>> the java.desktop module, >>> you can re-enable the doclint checks for the module by removing >>> "-accessibility" from >>> the java.desktop line in make/CompileJavaModules.gmk >>> >>> make/CompileJavaModules.gmk:java.desktop_ADD_JAVAC_FLAGS += >>> -Xdoclint:all/protected,-reference,-accessibility \ >>> >>> If you do remove the option, make sure to run a build to verify that >>> doclint does not >>> find any unfixed errors, which will prevent the build from >>> completing successfully. >>> >>> -- Jon >>> >>> On 3/19/19 3:41 AM, Prasanta Sadhukhan wrote: >>>> Hi Alexey, >>>> >>>> Your points are valid so I modified those in this webrev, please >>>> have a look >>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.3/ >>>> >>>> Regards >>>> Prasanta >>>> On 15-Mar-19 10:28 PM, Alexey Ivanov wrote: >>>>> Hi Prasanta, >>>>> >>>>> On 15/03/2019 05:15, Prasanta Sadhukhan wrote: >>>>>> >>>>>> Hi Alexey, >>>>>> >>>>>> >>>>>> On 13-Mar-19 6:10 PM, Alexey Ivanov wrote: >>>>>>> Hi guys, >>>>>>> >>>>>>> This is more of a general comment rather than targeted at this >>>>>>> particular change. Sorry if I missed any previous discussion on >>>>>>> that matter. >>>>>>> >>>>>>> I think it's good to have consistent headings without skipping >>>>>>> levels. >>>>>>> >>>>>>> Yet

in the Javadoc comments does not seem right. Let's take >>>>>>> a look at JTable for example: >>>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs.webrev2/docs/api/java.desktop/javax/swing/JTable.html >>>>>>> >>>>>>> >>>>>>> The page starts with

JTable

. This is the highest >>>>>>> heading level on the page, I haven't found any

. >>>>>> As for this changeset, I am following the rules set in the >>>>>> https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002671.html >>>>>> >>>>>> - headings in documentation comments for modules, packages and >>>>>> types should start at

- >>>>> >>>>> Thank you for clarification. I've seen a few fixes in this area >>>>> but I missed this discussion. >>>>> >>>>> So the main type heading will be

, i.e. it will >>>>>

JTable

. Therefore starting at

in types makes sense. >>>>> >>>>>>> Later on,

Method Detail

. And a specific method: >>>>>>>

doLayout

. Since the entire method description is under >>>>>>>

heading, it should not use any headings above

. But now >>>>>>> we have

and

which kind-of start new sections rather >>>>>>> than being part of

which describes the method. >>>>>> I have only changed to make sure there are no missing headings ie >>>>>> start with h2 (as stated above) and change previously used h4 to >>>>>> h3(to make sure no missing heading), rest were as it was earlier. >>>>> >>>>> According to the message you linked to, the documentation comments >>>>> for methods should start at

. >>>>> >>>>> Here's the relevant quote: >>>>> ?Headings in documentation comments for modules, packages and >>>>> types should start at

; >>>>> Headings in documentation comments for members of a type (field, >>>>> constructor, method, etc) should start at

. >>>>> >>>>> (I've changed formatting to separate these two cases.) >>>>> >>>>> >>>>> Thus in *JTable.java* you should rather decrease heading level as >>>>> the headings are used in /method/ as opposed to /type/ in the >>>>> majority of other cases: >>>>> -3053????? *

Distributing the delta

>>>>> +3053????? *

Distributing the delta

>>>>> >>>>> -3055????? *

Overview

>>>>> +3055????? *
Overview
>>>>> >>>>> And the remaining

become

: >>>>> 3064????? *

Definition

>>>>> 3096????? *

Details

>>>>> 3107????? *

When the MAX and MIN bounds are hit

>>>>> >>>>> >>>>> As for the rest of the review: >>>>> >>>>> *Font.java* >>>>> >>>>> You changed the first

to

: >>>>> -77? *

Characters and Glyphs

>>>>> +77? *

Characters and Glyphs

>>>>> >>>>> But why not other headings? All of the headings were at the same >>>>> level, but they're not. >>>>> >>>>> These should also go up to

: >>>>> ?99? *

Physical and Logical Fonts

>>>>> 138? *

Font Faces and Names

>>>>> 172? *

Font and TextAttribute

>>>>> >>>>> >>>>> *javax/print/attribute/package-info.java* >>>>> >>>>> 204? *

Attribute Class Design

>>>>> 298? *

Attribute Vendors

>>>>> 324? *

Using Attributes

>>>>> >>>>> These should also go one level up to

as other headings. >>>>> These used to be separate sections but now they're subsections of >>>>> 131? *

Attribute Sets

>>>>> which does not seem correct. >>>>> >>>>> >>>>> Regards, >>>>> Alexey >>>>> >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>>> >>>>>>> Is such heading sequence intended? >>>>>>> >>>>>>> Regards, >>>>>>> Alexey >>>>>>> >>>>>>> On 13/03/2019 06:10, Prasanta Sadhukhan wrote: >>>>>>>> Any more comments on this >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/webrev.2/ >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> On 11-Mar-19 2:16 PM, Prasanta Sadhukhan wrote: >>>>>>>>> The 2nd URL is based on webrev.1. I have placed new docs for >>>>>>>>> webrev.2 here >>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8220250/docs.webrev2/docs/api/java.desktop/module-summary.html >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>> >>>>> >>>> >> From prasanta.sadhukhan at oracle.com Fri Mar 22 05:34:27 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 22 Mar 2019 11:04:27 +0530 Subject: [13] RFR JDK-8212904:JTextArea line wrapping incorrect when using UI scale In-Reply-To: <1d54eee0-63bc-ed48-fa06-aa250510b12f@oracle.com> References: <5e3cb36e-fdad-b2ce-4774-f516fd37b420@oracle.com> <1d54eee0-63bc-ed48-fa06-aa250510b12f@oracle.com> Message-ID: <6f337ddd-79d9-484c-f92a-e5a264442276@oracle.com> Hi Sergey, Thanks for your review. textarea.getLineCount() returns same number for both correct and broken wrap so it cannot be used for test automation... Regards Prasanta On 21-Mar-19 4:24 AM, Sergey Bylokhov wrote: > Hi, Prasanta. > > The change looks fine, but probably the test can be automated? I guess > when "wrap" works properly you should get more lines in the text area, > than in case of broken "wrap"? > > On 19/03/2019 00:03, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for an issue where it is seen that >> line wrapping of JTextArea doen't work correctly if you set >> wrapStyleWord = true and you use a UI scale (either by setting >> "sun.java2d.uiScale" or by setting display scale of Windows) >> >> It is a regression of JDK-8132119: Provide public API for text >> related methods in SwingUtilities2 >> where many public text related API was added catering to floating >> point hidpi scale. >> This issue happened because of that as the public >> Utilities.getBreakLocation() API, used to determine where to break >> the given text, is using non-floating point methods. >> >> Proposed fix is to make sure correct getBreakLocation() method is >> called and not the deprecated(integer based) one >> and also the floating point based getBreakLocation() API uses >> floating point API based calculations. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212904 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8212904/webrev.0/ >> >> Regards >> Prasanta > > From fujie at loongson.cn Fri Mar 22 09:31:39 2019 From: fujie at loongson.cn (Jie Fu) Date: Fri, 22 Mar 2019 17:31:39 +0800 Subject: RFR(trivial): 8221319: Update test/jdk/ProblemList.txt due to JDK-8221312 and JDK-8211703 Message-ID: <0fd804dc-5c2f-c593-6361-9442daeef03d@loongson.cn> Hi all, Bug: https://bugs.openjdk.java.net/browse/JDK-8221319 There are JDK-8221312 and JDK-8211703 failures on Ubuntu 18.04. May I update the test/jdk/ProblemList.txt like this? -------------------------------------------------------------------- diff -r 96c45aa61056 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt? Fri Mar 22 13:42:45 2019 +0530 +++ b/test/jdk/ProblemList.txt? Fri Mar 22 17:29:06 2019 +0800 @@ -809,7 +809,8 @@ ?javax/swing/JTable/6263446/bug6263446.java 8169959 macosx-all ?javax/swing/JTree/6263446/bug6263446.java 8213125 macosx-all ?javax/swing/JTree/8003400/Test8003400.java 8197560 macosx-all,linux-all - +sanity/client/SwingSet/src/InternalFrameDemoTest.java 8211703 linux-all +sanity/client/SwingSet/src/ColorChooserDemoTest.java 8221312 linux-all ?############################################################################ ?# jdk_text -------------------------------------------------------------------- The change has been tested on Linux/x86-64 (Ubuntu 18.04). Could you please review it? Thanks a lot. Best regards, Jie From Sergey.Bylokhov at oracle.com Fri Mar 22 23:32:32 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 22 Mar 2019 16:32:32 -0700 Subject: [13] RFR JDK-8212904:JTextArea line wrapping incorrect when using UI scale In-Reply-To: <6f337ddd-79d9-484c-f92a-e5a264442276@oracle.com> References: <5e3cb36e-fdad-b2ce-4774-f516fd37b420@oracle.com> <1d54eee0-63bc-ed48-fa06-aa250510b12f@oracle.com> <6f337ddd-79d9-484c-f92a-e5a264442276@oracle.com> Message-ID: <8a989061-2fd4-7f8e-6493-dd6f2d7dda15@oracle.com> On 21/03/2019 22:34, Prasanta Sadhukhan wrote: > Thanks for your review. textarea.getLineCount() returns same number for both correct and broken wrap so it cannot be used for test automation... Then probably it can be checked by the visibility of the horizontal scroll bar? If you set the scrollbar policy as HORIZONTAL_SCROLLBAR_AS_NEEDED then you can check is it visible(wrap-off) or is it invisible(wrap-on). Or you can check the height of the text area, which is different when wrap on/off. > Regards > Prasanta > On 21-Mar-19 4:24 AM, Sergey Bylokhov wrote: >> Hi, Prasanta. >> >> The change looks fine, but probably the test can be automated? I guess when "wrap" works properly you should get more lines in the text area, than in case of broken "wrap"? >> >> On 19/03/2019 00:03, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for an issue where it is seen that >>> line wrapping of JTextArea doen't work correctly if you set wrapStyleWord = true and you use a UI scale (either by setting "sun.java2d.uiScale" or by setting display scale of Windows) >>> >>> It is a regression of JDK-8132119: Provide public API for text related methods in SwingUtilities2 >>> where many public text related API was added catering to floating point hidpi scale. >>> This issue happened because of that as the public Utilities.getBreakLocation() API, used to determine where to break the given text, is using non-floating point methods. >>> >>> Proposed fix is to make sure correct getBreakLocation() method is called and not the deprecated(integer based) one >>> and also the floating point based getBreakLocation() API uses floating point API based calculations. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212904 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8212904/webrev.0/ >>> >>> Regards >>> Prasanta >> >> > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Mon Mar 25 09:05:40 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 25 Mar 2019 14:35:40 +0530 Subject: [13] RFR JDK-8212904:JTextArea line wrapping incorrect when using UI scale In-Reply-To: <8a989061-2fd4-7f8e-6493-dd6f2d7dda15@oracle.com> References: <5e3cb36e-fdad-b2ce-4774-f516fd37b420@oracle.com> <1d54eee0-63bc-ed48-fa06-aa250510b12f@oracle.com> <6f337ddd-79d9-484c-f92a-e5a264442276@oracle.com> <8a989061-2fd4-7f8e-6493-dd6f2d7dda15@oracle.com> Message-ID: On 23-Mar-19 5:02 AM, Sergey Bylokhov wrote: > On 21/03/2019 22:34, Prasanta Sadhukhan wrote: >> Thanks for your review. textarea.getLineCount() returns same number >> for both correct and broken wrap so it cannot be used for test >> automation... > > Then probably it can be checked by the visibility of the horizontal > scroll bar? > If you set the scrollbar policy as HORIZONTAL_SCROLLBAR_AS_NEEDED then > you can check is it visible(wrap-off) or is it invisible(wrap-on). > Or you can check the height of the text area, which is different when > wrap on/off. > Thanks Sergey for the pointer. But horizontal scrollbar is not visible for both correct and broken wrap if scrollbar policy is set to HORIZONTAL_SCROLLBAR_AS_NEEDED. Also, the textArea.getHeight() is same for both textArea.setWrapStyleWord( true ) and not. Attached is the automated testcase I tried. Regards Prasanta >> Regards >> Prasanta >> On 21-Mar-19 4:24 AM, Sergey Bylokhov wrote: >>> Hi, Prasanta. >>> >>> The change looks fine, but probably the test can be automated? I >>> guess when "wrap" works properly you should get more lines in the >>> text area, than in case of broken "wrap"? >>> >>> On 19/03/2019 00:03, Prasanta Sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a fix for an issue where it is seen that >>>> line wrapping of JTextArea doen't work correctly if you set >>>> wrapStyleWord = true and you use a UI scale (either by setting >>>> "sun.java2d.uiScale" or by setting display scale of Windows) >>>> >>>> It is a regression of JDK-8132119: Provide public API for text >>>> related methods in SwingUtilities2 >>>> where many public text related API was added catering to floating >>>> point hidpi scale. >>>> This issue happened because of that as the public >>>> Utilities.getBreakLocation() API, used to determine where to break >>>> the given text, is using non-floating point methods. >>>> >>>> Proposed fix is to make sure correct getBreakLocation() method is >>>> called and not the deprecated(integer based) one >>>> and also the floating point based getBreakLocation() API uses >>>> floating point API based calculations. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212904 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8212904/webrev.0/ >>>> >>>> Regards >>>> Prasanta >>> >>> >> > > -------------- next part -------------- import java.awt.BorderLayout; import java.awt.event.WindowAdapter; import java.awt.event.WindowEvent; import java.io.IOException; import java.net.URISyntaxException; import javax.swing.JFrame; import javax.swing.JScrollPane; import javax.swing.JTextArea; import javax.swing.ScrollPaneConstants; import javax.swing.SwingUtilities; public class JTextAreaTest { static JFrame frame; static JFrame frame1; static int wraponHeight; static int wrapoffHeight; public static void doWrapOnTest() { frame = new JFrame(); frame.setSize( 720, 300 ); frame.setLayout( new BorderLayout() ); JTextArea textArea = new JTextArea(); textArea.setLineWrap( true ); textArea.setWrapStyleWord( true ); StringBuffer sb = new StringBuffer(); for (int i = 0; i < 100; i++) { sb.append( "zz zzz zzzz zz zz zz zzz xzzzz zzzzzzzzzzzzzzzzx yyyyyyy tttttttttt sssss hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh\n" ); } textArea.setText( sb.toString() ); JScrollPane pane = new JScrollPane( textArea, ScrollPaneConstants.VERTICAL_SCROLLBAR_ALWAYS, ScrollPaneConstants.HORIZONTAL_SCROLLBAR_AS_NEEDED ); frame.add( pane, BorderLayout.CENTER ); frame.setVisible( true ); wraponHeight = textArea.getHeight(); System.out.println("wraponheight " + wraponHeight); } public static void doWrapOffTest() { frame1 = new JFrame(); frame1.setSize( 720, 300 ); frame1.setLayout( new BorderLayout() ); JTextArea textArea1 = new JTextArea(); textArea1.setLineWrap( true ); StringBuffer sb1 = new StringBuffer(); for (int i = 0; i < 100; i++) { sb1.append( "zz zzz zzzz zz zz zz zzz xzzzz zzzzzzzzzzzzzzzzx yyyyyyy tttttttttt sssss hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh\n" ); } textArea1.setText( sb1.toString() ); JScrollPane pane1 = new JScrollPane( textArea1, ScrollPaneConstants.VERTICAL_SCROLLBAR_ALWAYS, ScrollPaneConstants.HORIZONTAL_SCROLLBAR_AS_NEEDED ); frame1.add( pane1, BorderLayout.CENTER ); frame1.setLocationRelativeTo(null); frame1.setVisible( true ); wrapoffHeight = textArea1.getHeight(); System.out.println("wrapoffheight " + wrapoffHeight); } public static void main( String[] args ) throws Exception { System.setProperty( "sun.java2d.uiScale", "1.25" ); try { SwingUtilities.invokeAndWait(() -> doWrapOnTest()); Thread.sleep(2000); SwingUtilities.invokeAndWait(() -> doWrapOffTest()); Thread.sleep(2000); if (wraponHeight == wrapoffHeight) { throw new RuntimeException("JTextArea line wrapping incorrect when using UI scale"); } } finally { SwingUtilities.invokeAndWait(() -> frame.dispose()); SwingUtilities.invokeAndWait(() -> frame1.dispose()); } } } From Sergey.Bylokhov at oracle.com Mon Mar 25 18:32:22 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 25 Mar 2019 11:32:22 -0700 Subject: [13] RFR JDK-8212904:JTextArea line wrapping incorrect when using UI scale In-Reply-To: References: <5e3cb36e-fdad-b2ce-4774-f516fd37b420@oracle.com> <1d54eee0-63bc-ed48-fa06-aa250510b12f@oracle.com> <6f337ddd-79d9-484c-f92a-e5a264442276@oracle.com> <8a989061-2fd4-7f8e-6493-dd6f2d7dda15@oracle.com> Message-ID: On 25/03/2019 02:05, Prasanta Sadhukhan wrote: > Thanks Sergey for the pointer. But horizontal scrollbar is not visible for both correct and broken wrap if scrollbar policy is set to HORIZONTAL_SCROLLBAR_AS_NEEDED. > Also, the textArea.getHeight() is same for both textArea.setWrapStyleWord( true ) and not. Attached is the automated testcase I tried. In the test above the case for doWrapOffTest() still uses setLineWrap(true) which disable scroll bar, if you drop it the scrollbar will be visible. As of the height, you need to read the value a little bit later, not immediately after "frame.setVisible", for example if you read these values at lines 75,76 you will get something like that: textArea.getHeight() = 3216 textArea1.getHeight() = 1616 -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Tue Mar 26 05:01:18 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 26 Mar 2019 10:31:18 +0530 Subject: [13] RFR JDK-8212904:JTextArea line wrapping incorrect when using UI scale In-Reply-To: References: <5e3cb36e-fdad-b2ce-4774-f516fd37b420@oracle.com> <1d54eee0-63bc-ed48-fa06-aa250510b12f@oracle.com> <6f337ddd-79d9-484c-f92a-e5a264442276@oracle.com> <8a989061-2fd4-7f8e-6493-dd6f2d7dda15@oracle.com> Message-ID: <78e8ad46-f58e-d168-32a4-09d42b903b53@oracle.com> Thanks Sergey for the pointer. Modified test to be automated in the webrev http://cr.openjdk.java.net/~psadhukhan/8212904/webrev.1/ Regards Prasanta On 26-Mar-19 12:02 AM, Sergey Bylokhov wrote: > On 25/03/2019 02:05, Prasanta Sadhukhan wrote: >> Thanks Sergey for the pointer. But horizontal scrollbar is not >> visible for both correct and broken wrap if scrollbar policy is set >> to HORIZONTAL_SCROLLBAR_AS_NEEDED. >> Also, the textArea.getHeight() is same for both >> textArea.setWrapStyleWord( true ) and not. Attached is the automated >> testcase I tried. > > In the test above the case for doWrapOffTest() still uses > setLineWrap(true) which disable scroll bar, if you drop it the > scrollbar will be visible. > > As of the height, you need to read the value a little bit later, not > immediately after "frame.setVisible", for example if you read these > values at lines 75,76 you will get something like that: > textArea.getHeight() = 3216 > textArea1.getHeight() = 1616 > > From krishna.addepalli at oracle.com Tue Mar 26 09:45:21 2019 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Tue, 26 Mar 2019 02:45:21 -0700 (PDT) Subject: [13] RFR: JDK-8219914: Change the environment variable for Java Access Bridge logging to have a directory. Message-ID: <85eceba2-46e0-4462-9276-bfa79d9e0dd2@default> Hi Phil, Per our discussion, I have changed the JAVA_ACCESSBRIDGE_LOGFILE to JAVA_ACCESSBRIDGE_LOGDIRECTORY to reflect that it accepts only a directory value in the variable. I have also changed the code in AccessBridgeDebug.cpp appropriately. So, currently, the code will look for the environment variable, which should contain path to the directory, and two log files namely "java_access_bridge.log" and "windows_access_bridge.log" will be created. Link to the JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8219914 Here is the webrev: http://cr.openjdk.java.net/~kaddepalli/8219914/webrev00/ Thanks, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Mar 26 17:12:25 2019 From: philip.race at oracle.com (Phil Race) Date: Tue, 26 Mar 2019 10:12:25 -0700 Subject: [13] RFR: JDK-8219914: Change the environment variable for Java Access Bridge logging to have a directory. In-Reply-To: <85eceba2-46e0-4462-9276-bfa79d9e0dd2@default> References: <85eceba2-46e0-4462-9276-bfa79d9e0dd2@default> Message-ID: <5e06ce11-7f36-cb59-9c34-d830cc44df44@oracle.com> Can we just call it JAVA_ACCESSBRIDGE_LOGDIR ? ?filePath[envFilePathLength] = '/'; Is this right ? Does fopen on Windows expect this unix style separator ? 53 memcpy(filePath, envfilePath, envFilePathLength*sizeof(char)); 56 memcpy(filePath + envFilePathLength + 1 + fileNameLength, ".log", 4*sizeof(char)); Interesting that you feel it necessary to use sizeof(char) when clearly the whole logic, eg see : 50 auto filePathSize = envFilePathLength + 1 + fileNameLength + 5; //1 for "/", 5 for ".log" and 0; assumes it is 1 ... ?PrintDebugString("couldnot open file %s", filePath); couldnot -> could not -phil. On 3/26/19 2:45 AM, Krishna Addepalli wrote: > > Hi Phil, > > Per our discussion, I have changed the JAVA_ACCESSBRIDGE_LOGFILE to > JAVA_ACCESSBRIDGE_LOGDIRECTORY to reflect that it accepts only a > directory value in the variable. > > I have also changed the code in AccessBridgeDebug.cpp appropriately. > > So, currently, the code will look for the environment variable, which > should contain path to the directory, and two log files namely > ?java_access_bridge.log? and ?windows_access_bridge.log? will be created. > > Link to the JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8219914 > > Here is the webrev: > http://cr.openjdk.java.net/~kaddepalli/8219914/webrev00/ > > Thanks, > > Krishna > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Mar 26 20:55:49 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 26 Mar 2019 13:55:49 -0700 Subject: [13] RFR JDK-8212904:JTextArea line wrapping incorrect when using UI scale In-Reply-To: <78e8ad46-f58e-d168-32a4-09d42b903b53@oracle.com> References: <5e3cb36e-fdad-b2ce-4774-f516fd37b420@oracle.com> <1d54eee0-63bc-ed48-fa06-aa250510b12f@oracle.com> <6f337ddd-79d9-484c-f92a-e5a264442276@oracle.com> <8a989061-2fd4-7f8e-6493-dd6f2d7dda15@oracle.com> <78e8ad46-f58e-d168-32a4-09d42b903b53@oracle.com> Message-ID: <23c338b5-2564-ebea-6da0-d2d5ed07952f@oracle.com> Hi, Prasanta. The "textArea.getHeight()" should be called on EDT, since this is a swing component. On 25/03/2019 22:01, Prasanta Sadhukhan wrote: > Thanks Sergey for the pointer. Modified test to be automated in the webrev > > http://cr.openjdk.java.net/~psadhukhan/8212904/webrev.1/ > > Regards > Prasanta > On 26-Mar-19 12:02 AM, Sergey Bylokhov wrote: >> On 25/03/2019 02:05, Prasanta Sadhukhan wrote: >>> Thanks Sergey for the pointer. But horizontal scrollbar is not visible for both correct and broken wrap if scrollbar policy is set to HORIZONTAL_SCROLLBAR_AS_NEEDED. >>> Also, the textArea.getHeight() is same for both textArea.setWrapStyleWord( true ) and not. Attached is the automated testcase I tried. >> >> In the test above the case for doWrapOffTest() still uses setLineWrap(true) which disable scroll bar, if you drop it the scrollbar will be visible. >> >> As of the height, you need to read the value a little bit later, not immediately after "frame.setVisible", for example if you read these values at lines 75,76 you will get something like that: >> textArea.getHeight() = 3216 >> textArea1.getHeight() = 1616 >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Mar 26 21:18:11 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 26 Mar 2019 14:18:11 -0700 Subject: [12] JDK-8213516: jck test api/javax_accessibility/AccessibleState/fields.html fails intermittent In-Reply-To: <0f55ff64-dac2-4b61-b509-fba7c4f1b9ca@default> References: <5905b959-3ade-4d99-931f-f88beada7a88@default> <001bf74e-3415-bd91-c354-4006ee3b0e2c@oracle.com> <41a2006c-78f1-1ddd-c796-b89e1b594184@oracle.com> <5C1C40BC.90106@oracle.com> <5C1C776D.2090709@oracle.com> <717ce4ea-8d1a-4fc8-8cca-6ce676cfda40@default> <9006ef65-0837-7b77-be83-79bbd475aa95@oracle.com> <5dab2a68-2773-4a61-bf86-88bcb322f273@default> <77206885-c49a-cb5a-3cb1-73049c85c2a1@oracle.com> <0ef54b83-956f-4c28-b3cc-039e625d6f99@default> <98b5e57e-9b2c-4ba5-9462-36325f3c9c9e@default> <0f55ff64-dac2-4b61-b509-fba7c4f1b9ca@default> Message-ID: <3786a857-ce53-b580-13d2-4100c79b397c@oracle.com> Hi, Shashi, Krishna. > Hi Sergey, Please find the updated Webrev with fixes for the below comments> http://cr.openjdk.java.net/~sveerabhadra/8213516/webrev.06/ Is it possible that concatenation of different resourceBundleName and locale.toLanguageTag() will produce the same resulted string? like aaa+bbb and aaab+bb. > The hashcode() does not guarantee that it will produce different numbers for different inputs. > You need a compound key like in previous fix(but not in the public APi), or you need a compound map like this: > Hashtable>> table = new Hashtable<>(); > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Wed Mar 27 05:25:09 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 27 Mar 2019 10:55:09 +0530 Subject: [13] RFR JDK-8212904:JTextArea line wrapping incorrect when using UI scale In-Reply-To: <23c338b5-2564-ebea-6da0-d2d5ed07952f@oracle.com> References: <5e3cb36e-fdad-b2ce-4774-f516fd37b420@oracle.com> <1d54eee0-63bc-ed48-fa06-aa250510b12f@oracle.com> <6f337ddd-79d9-484c-f92a-e5a264442276@oracle.com> <8a989061-2fd4-7f8e-6493-dd6f2d7dda15@oracle.com> <78e8ad46-f58e-d168-32a4-09d42b903b53@oracle.com> <23c338b5-2564-ebea-6da0-d2d5ed07952f@oracle.com> Message-ID: OK. Modified webrev http://cr.openjdk.java.net/~psadhukhan/8212904/webrev.2/ Regards Prasanta On 27-Mar-19 2:25 AM, Sergey Bylokhov wrote: > Hi, Prasanta. > > The "textArea.getHeight()" should be called on EDT, since this is a > swing component. > > On 25/03/2019 22:01, Prasanta Sadhukhan wrote: >> Thanks Sergey for the pointer. Modified test to be automated in the >> webrev >> >> http://cr.openjdk.java.net/~psadhukhan/8212904/webrev.1/ >> >> Regards >> Prasanta >> On 26-Mar-19 12:02 AM, Sergey Bylokhov wrote: >>> On 25/03/2019 02:05, Prasanta Sadhukhan wrote: >>>> Thanks Sergey for the pointer. But horizontal scrollbar is not >>>> visible for both correct and broken wrap if scrollbar policy is set >>>> to HORIZONTAL_SCROLLBAR_AS_NEEDED. >>>> Also, the textArea.getHeight() is same for both >>>> textArea.setWrapStyleWord( true ) and not. Attached is the >>>> automated testcase I tried. >>> >>> In the test above the case for doWrapOffTest() still uses >>> setLineWrap(true) which disable scroll bar, if you drop it the >>> scrollbar will be visible. >>> >>> As of the height, you need to read the value a little bit later, not >>> immediately after "frame.setVisible", for example if you read these >>> values at lines 75,76 you will get something like that: >>> textArea.getHeight() = 3216 >>> textArea1.getHeight() = 1616 >>> >>> >> > > From krishna.addepalli at oracle.com Wed Mar 27 08:41:51 2019 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Wed, 27 Mar 2019 01:41:51 -0700 (PDT) Subject: [13] RFR: JDK-8219914: Change the environment variable for Java Access Bridge logging to have a directory. In-Reply-To: <5e06ce11-7f36-cb59-9c34-d830cc44df44@oracle.com> References: <85eceba2-46e0-4462-9276-bfa79d9e0dd2@default> <5e06ce11-7f36-cb59-9c34-d830cc44df44@oracle.com> Message-ID: Hi Phil, Thanks for the review. I have changed the variable to "JAVA_ACCESSBRIDGE_LOGDIR". Yes, '/' file separator character works on windows. I have used it in the past and have also currently tested it on my machine and it works. I have added the multiplier "sizeof(char)" for all memcpy and memset lines in the code, to keep it consistent. Thanks for pointing that out. Here is the link to the webrev: http://cr.openjdk.java.net/~kaddepalli/8219914/webrev01/ Thanks, Krishna From: Phil Race Sent: Tuesday, March 26, 2019 10:42 PM To: Krishna Addepalli ; swing-dev at openjdk.java.net Subject: Re: [13] RFR: JDK-8219914: Change the environment variable for Java Access Bridge logging to have a directory. Can we just call it JAVA_ACCESSBRIDGE_LOGDIR ? filePath[envFilePathLength] = '/'; Is this right ? Does fopen on Windows expect this unix style separator ? 53 memcpy(filePath, envfilePath, envFilePathLength*sizeof(char)); 56 memcpy(filePath + envFilePathLength + 1 + fileNameLength, ".log", 4*sizeof(char)); Interesting that you feel it necessary to use sizeof(char) when clearly the whole logic, eg see : 50 auto filePathSize = envFilePathLength + 1 + fileNameLength + 5; //1 for "/", 5 for ".log" and 0; assumes it is 1 ... PrintDebugString("couldnot open file %s", filePath); couldnot -> could not -phil. On 3/26/19 2:45 AM, Krishna Addepalli wrote: Hi Phil, Per our discussion, I have changed the JAVA_ACCESSBRIDGE_LOGFILE to JAVA_ACCESSBRIDGE_LOGDIRECTORY to reflect that it accepts only a directory value in the variable. I have also changed the code in AccessBridgeDebug.cpp appropriately. So, currently, the code will look for the environment variable, which should contain path to the directory, and two log files namely "java_access_bridge.log" and "windows_access_bridge.log" will be created. Link to the JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8219914 Here is the webrev: http://cr.openjdk.java.net/~kaddepalli/8219914/webrev00/ Thanks, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From Keith.Pullen at ultra-css.com Wed Mar 27 14:18:08 2019 From: Keith.Pullen at ultra-css.com (Keith Pullen) Date: Wed, 27 Mar 2019 14:18:08 +0000 Subject: OpenJDK 11 and Swing Message-ID: <7dbbf5af45804646a4e96c8869447818@cssweyex01.ueccs.co.uk> Hi, I hope this makes some sense. The company that I work for has developed an application with a large, monolithic, GUI, build using swing components. We currently run java 8. Or assumption is that we will need to move to use OpenJDK 11 in the future, and I am wondering what support for Swing will be available moving on into the future, Keith Keith Pullen Senior Software Engineer Ultra Electronics COMMAND & SONAR SYSTEMS Waverley House, Hampshire Rd, Weymouth Dorset, DT4 9XD, U.K. keith.pullen at ultra-css.com Tel: +44 (0)1305 762172 -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Mar 27 15:56:58 2019 From: philip.race at oracle.com (Phil Race) Date: Wed, 27 Mar 2019 08:56:58 -0700 Subject: OpenJDK 11 and Swing In-Reply-To: <7dbbf5af45804646a4e96c8869447818@cssweyex01.ueccs.co.uk> References: <7dbbf5af45804646a4e96c8869447818@cssweyex01.ueccs.co.uk> Message-ID: <2933ca07-89b5-fb64-3dda-431c6a338d1f@oracle.com> Swing is there in OpenJDK 11 which is an LTS and JDK 11 will be supported for 8 years by Oracle : https://www.oracle.com/technetwork/java/java-se-support-roadmap.html and perhaps also by other vendors. It is still being maintained and updated in current JDK development releases (JDK 13 at the moment). If you want something more than that you'll need to go ask on some kind of customer support list for one of the OpenJDK vendors, not here. And I'd say the same about any OpenJDK feature, not just Swing. -phil. On 3/27/19 7:18 AM, Keith Pullen wrote: > > Hi, > > I hope this makes some sense. The company that I work for has > developed an application with a large, monolithic, GUI, build using > swing components. We currently run java 8. Or assumption is that we > will need to move to use OpenJDK 11 in the future, and I am wondering > what support for Swing will be available moving on into the future, > > Keith > > *Keith Pullen* > > Senior Software Engineer > > Ultra Electronics > > COMMAND & SONAR SYSTEMS > > Waverley House, Hampshire Rd, Weymouth > > Dorset, DT4 9XD, U.K. > > keith.pullen at ultra-css.com > > Tel: +44 (0)1305 762172 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Mar 27 16:03:08 2019 From: philip.race at oracle.com (Phil Race) Date: Wed, 27 Mar 2019 09:03:08 -0700 Subject: [13] RFR JDK-8212904:JTextArea line wrapping incorrect when using UI scale In-Reply-To: References: <5e3cb36e-fdad-b2ce-4774-f516fd37b420@oracle.com> <1d54eee0-63bc-ed48-fa06-aa250510b12f@oracle.com> <6f337ddd-79d9-484c-f92a-e5a264442276@oracle.com> <8a989061-2fd4-7f8e-6493-dd6f2d7dda15@oracle.com> <78e8ad46-f58e-d168-32a4-09d42b903b53@oracle.com> <23c338b5-2564-ebea-6da0-d2d5ed07952f@oracle.com> Message-ID: <1b3ab7f2-1a39-4a04-4fed-d1c23b86775f@oracle.com> The product code change looks fine. I didn't examine the test super-closely but I am curious why you used System.setProperty("sun.java2d.uiScale", "1.25" ) instead of setting it on the command line ? -phil. On 3/26/19 10:25 PM, Prasanta Sadhukhan wrote: > OK. Modified webrev > > http://cr.openjdk.java.net/~psadhukhan/8212904/webrev.2/ > > Regards > Prasanta > On 27-Mar-19 2:25 AM, Sergey Bylokhov wrote: >> Hi, Prasanta. >> >> The "textArea.getHeight()" should be called on EDT, since this is a >> swing component. >> >> On 25/03/2019 22:01, Prasanta Sadhukhan wrote: >>> Thanks Sergey for the pointer. Modified test to be automated in the >>> webrev >>> >>> http://cr.openjdk.java.net/~psadhukhan/8212904/webrev.1/ >>> >>> Regards >>> Prasanta >>> On 26-Mar-19 12:02 AM, Sergey Bylokhov wrote: >>>> On 25/03/2019 02:05, Prasanta Sadhukhan wrote: >>>>> Thanks Sergey for the pointer. But horizontal scrollbar is not >>>>> visible for both correct and broken wrap if scrollbar policy is >>>>> set to HORIZONTAL_SCROLLBAR_AS_NEEDED. >>>>> Also, the textArea.getHeight() is same for both >>>>> textArea.setWrapStyleWord( true ) and not. Attached is the >>>>> automated testcase I tried. >>>> >>>> In the test above the case for doWrapOffTest() still uses >>>> setLineWrap(true) which disable scroll bar, if you drop it the >>>> scrollbar will be visible. >>>> >>>> As of the height, you need to read the value a little bit later, >>>> not immediately after "frame.setVisible", for example if you read >>>> these values at lines 75,76 you will get something like that: >>>> textArea.getHeight() = 3216 >>>> textArea1.getHeight() = 1616 >>>> >>>> >>> >> >> > From philip.race at oracle.com Wed Mar 27 21:41:25 2019 From: philip.race at oracle.com (Phil Race) Date: Wed, 27 Mar 2019 14:41:25 -0700 Subject: [13] RFR: JDK-8219914: Change the environment variable for Java Access Bridge logging to have a directory. In-Reply-To: References: <85eceba2-46e0-4462-9276-bfa79d9e0dd2@default> <5e06ce11-7f36-cb59-9c34-d830cc44df44@oracle.com> Message-ID: <52d8785c-0f32-0779-60a2-b2d86f977b0b@oracle.com> Hi, It is still inconsistent. the "+1" and "+5" logic relies on the answer to sizeof(char) being 1. So either get rid of all those calls or use sizeof('/') and sizeof(".logX"); instead of 1 and 5. I'd get rid of them .... -phil On 3/27/19 1:41 AM, Krishna Addepalli wrote: > > Hi Phil, > > Thanks for the review. > > I have changed the variable to ?JAVA_ACCESSBRIDGE_LOGDIR?. > > Yes, ?/? file separator character works on windows. I have used it in > the past and have also currently tested it on my machine and it works. > > I have added the multiplier ?sizeof(char)? for all memcpy and memset > lines in the code, to keep it consistent. Thanks for pointing that out. > > Here is the link to the webrev: > http://cr.openjdk.java.net/~kaddepalli/8219914/webrev01/ > > Thanks, > > Krishna > > *From:*Phil Race > *Sent:* Tuesday, March 26, 2019 10:42 PM > *To:* Krishna Addepalli ; > swing-dev at openjdk.java.net > *Subject:* Re: [13] RFR: JDK-8219914: Change the > environment variable for Java Access Bridge logging to have a directory. > > Can we just call it? JAVA_ACCESSBRIDGE_LOGDIR ? > ?filePath[envFilePathLength] = '/'; > Is this right ? Does fopen on Windows expect this unix style separator ? > 53???????? memcpy(filePath, envfilePath, envFilePathLength*sizeof(char)); > 56???????? memcpy(filePath + envFilePathLength + 1 + fileNameLength, > ".log", 4*sizeof(char)); > Interesting that you feel it necessary to use sizeof(char) when > clearly the whole logic, eg see : > 50???????? auto filePathSize = envFilePathLength + 1 + fileNameLength > + 5; //1 for "/", 5 for ".log" and 0; > assumes it is 1 ... > ?PrintDebugString("couldnot open file %s", filePath); > > couldnot -> could not > > -phil. > > > On 3/26/19 2:45 AM, Krishna Addepalli wrote: > > Hi Phil, > > Per our discussion, I have changed the JAVA_ACCESSBRIDGE_LOGFILE > to JAVA_ACCESSBRIDGE_LOGDIRECTORY to reflect that it accepts only > a directory value in the variable. > > I have also changed the code in AccessBridgeDebug.cpp appropriately. > > So, currently, the code will look for the environment variable, > which should contain path to the directory, and two log files > namely ?java_access_bridge.log? and ?windows_access_bridge.log? > will be created. > > Link to the JDK Issue: > https://bugs.openjdk.java.net/browse/JDK-8219914 > > Here is the webrev: > http://cr.openjdk.java.net/~kaddepalli/8219914/webrev00/ > > Thanks, > > Krishna > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Mar 28 00:06:13 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 27 Mar 2019 17:06:13 -0700 Subject: [13] RFR JDK-8212904:JTextArea line wrapping incorrect when using UI scale In-Reply-To: References: <5e3cb36e-fdad-b2ce-4774-f516fd37b420@oracle.com> <1d54eee0-63bc-ed48-fa06-aa250510b12f@oracle.com> <6f337ddd-79d9-484c-f92a-e5a264442276@oracle.com> <8a989061-2fd4-7f8e-6493-dd6f2d7dda15@oracle.com> <78e8ad46-f58e-d168-32a4-09d42b903b53@oracle.com> <23c338b5-2564-ebea-6da0-d2d5ed07952f@oracle.com> Message-ID: <2eb8b6c6-7d94-6f9d-9891-f56a3b9cc3bf@oracle.com> Looks fine. On 26/03/2019 22:25, Prasanta Sadhukhan wrote: > OK. Modified webrev > > http://cr.openjdk.java.net/~psadhukhan/8212904/webrev.2/ > > Regards > Prasanta > On 27-Mar-19 2:25 AM, Sergey Bylokhov wrote: >> Hi, Prasanta. >> >> The "textArea.getHeight()" should be called on EDT, since this is a swing component. >> >> On 25/03/2019 22:01, Prasanta Sadhukhan wrote: >>> Thanks Sergey for the pointer. Modified test to be automated in the webrev >>> >>> http://cr.openjdk.java.net/~psadhukhan/8212904/webrev.1/ >>> >>> Regards >>> Prasanta >>> On 26-Mar-19 12:02 AM, Sergey Bylokhov wrote: >>>> On 25/03/2019 02:05, Prasanta Sadhukhan wrote: >>>>> Thanks Sergey for the pointer. But horizontal scrollbar is not visible for both correct and broken wrap if scrollbar policy is set to HORIZONTAL_SCROLLBAR_AS_NEEDED. >>>>> Also, the textArea.getHeight() is same for both textArea.setWrapStyleWord( true ) and not. Attached is the automated testcase I tried. >>>> >>>> In the test above the case for doWrapOffTest() still uses setLineWrap(true) which disable scroll bar, if you drop it the scrollbar will be visible. >>>> >>>> As of the height, you need to read the value a little bit later, not immediately after "frame.setVisible", for example if you read these values at lines 75,76 you will get something like that: >>>> textArea.getHeight() = 3216 >>>> textArea1.getHeight() = 1616 >>>> >>>> >>> >> >> > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Thu Mar 28 05:01:12 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 28 Mar 2019 10:31:12 +0530 Subject: [13] RFR JDK-8212904:JTextArea line wrapping incorrect when using UI scale In-Reply-To: <1b3ab7f2-1a39-4a04-4fed-d1c23b86775f@oracle.com> References: <5e3cb36e-fdad-b2ce-4774-f516fd37b420@oracle.com> <1d54eee0-63bc-ed48-fa06-aa250510b12f@oracle.com> <6f337ddd-79d9-484c-f92a-e5a264442276@oracle.com> <8a989061-2fd4-7f8e-6493-dd6f2d7dda15@oracle.com> <78e8ad46-f58e-d168-32a4-09d42b903b53@oracle.com> <23c338b5-2564-ebea-6da0-d2d5ed07952f@oracle.com> <1b3ab7f2-1a39-4a04-4fed-d1c23b86775f@oracle.com> Message-ID: Nothing specific. It was there in reproducer test in JBS and also to make sure the test can be run in standalone mode and not only via jtreg. Regards Prasanta On 27-Mar-19 9:33 PM, Phil Race wrote: > The product code change looks fine. I didn't examine the test > super-closely but > I am curious why you used System.setProperty("sun.java2d.uiScale", > "1.25" ) > instead of setting it on the command line ? > > -phil. > > On 3/26/19 10:25 PM, Prasanta Sadhukhan wrote: >> OK. Modified webrev >> >> http://cr.openjdk.java.net/~psadhukhan/8212904/webrev.2/ >> >> Regards >> Prasanta >> On 27-Mar-19 2:25 AM, Sergey Bylokhov wrote: >>> Hi, Prasanta. >>> >>> The "textArea.getHeight()" should be called on EDT, since this is a >>> swing component. >>> >>> On 25/03/2019 22:01, Prasanta Sadhukhan wrote: >>>> Thanks Sergey for the pointer. Modified test to be automated in the >>>> webrev >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/8212904/webrev.1/ >>>> >>>> Regards >>>> Prasanta >>>> On 26-Mar-19 12:02 AM, Sergey Bylokhov wrote: >>>>> On 25/03/2019 02:05, Prasanta Sadhukhan wrote: >>>>>> Thanks Sergey for the pointer. But horizontal scrollbar is not >>>>>> visible for both correct and broken wrap if scrollbar policy is >>>>>> set to HORIZONTAL_SCROLLBAR_AS_NEEDED. >>>>>> Also, the textArea.getHeight() is same for both >>>>>> textArea.setWrapStyleWord( true ) and not. Attached is the >>>>>> automated testcase I tried. >>>>> >>>>> In the test above the case for doWrapOffTest() still uses >>>>> setLineWrap(true) which disable scroll bar, if you drop it the >>>>> scrollbar will be visible. >>>>> >>>>> As of the height, you need to read the value a little bit later, >>>>> not immediately after "frame.setVisible", for example if you read >>>>> these values at lines 75,76 you will get something like that: >>>>> textArea.getHeight() = 3216 >>>>> textArea1.getHeight() = 1616 >>>>> >>>>> >>>> >>> >>> >> > From krishna.addepalli at oracle.com Thu Mar 28 06:21:13 2019 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Wed, 27 Mar 2019 23:21:13 -0700 (PDT) Subject: [13] RFR: JDK-8219914: Change the environment variable for Java Access Bridge logging to have a directory. In-Reply-To: <52d8785c-0f32-0779-60a2-b2d86f977b0b@oracle.com> References: <85eceba2-46e0-4462-9276-bfa79d9e0dd2@default> <5e06ce11-7f36-cb59-9c34-d830cc44df44@oracle.com> <52d8785c-0f32-0779-60a2-b2d86f977b0b@oracle.com> Message-ID: No it is not. When I'm adding "+1" and "+5", it simply adds that many number of characters to the size. The sizeof(char) can be more than 1, and this statement at line 51 (filePath = new char[filePathSize]), takes care of allocating sufficient number of bytes, which accommodate "filePathSize" number of characters. The problem is with memcpy and memset functions, which expect the size of the buffer to be provided in terms of bytes, which is why, we need the multiplier only in those functions. Even I'm in favor of getting rid of them, but unfortunately I cannot std::string in this case, which would have vastly simplified the code, and avoided this manual calculation of sizes, but that results in compiler errors. Thanks, Krishna From: Phil Race Sent: Thursday, March 28, 2019 3:11 AM To: Krishna Addepalli ; swing-dev at openjdk.java.net Subject: Re: [13] RFR: JDK-8219914: Change the environment variable for Java Access Bridge logging to have a directory. Hi, It is still inconsistent. the "+1" and "+5" logic relies on the answer to sizeof(char) being 1. So either get rid of all those calls or use sizeof('/') and sizeof(".logX"); instead of 1 and 5. I'd get rid of them .... -phil On 3/27/19 1:41 AM, Krishna Addepalli wrote: Hi Phil, Thanks for the review. I have changed the variable to "JAVA_ACCESSBRIDGE_LOGDIR". Yes, '/' file separator character works on windows. I have used it in the past and have also currently tested it on my machine and it works. I have added the multiplier "sizeof(char)" for all memcpy and memset lines in the code, to keep it consistent. Thanks for pointing that out. Here is the link to the webrev: http://cr.openjdk.java.net/~kaddepalli/8219914/webrev01/ Thanks, Krishna From: Phil Race Sent: Tuesday, March 26, 2019 10:42 PM To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [13] RFR: JDK-8219914: Change the environment variable for Java Access Bridge logging to have a directory. Can we just call it JAVA_ACCESSBRIDGE_LOGDIR ? filePath[envFilePathLength] = '/'; Is this right ? Does fopen on Windows expect this unix style separator ? 53 memcpy(filePath, envfilePath, envFilePathLength*sizeof(char)); 56 memcpy(filePath + envFilePathLength + 1 + fileNameLength, ".log", 4*sizeof(char)); Interesting that you feel it necessary to use sizeof(char) when clearly the whole logic, eg see : 50 auto filePathSize = envFilePathLength + 1 + fileNameLength + 5; //1 for "/", 5 for ".log" and 0; assumes it is 1 ... PrintDebugString("couldnot open file %s", filePath); couldnot -> could not -phil. On 3/26/19 2:45 AM, Krishna Addepalli wrote: Hi Phil, Per our discussion, I have changed the JAVA_ACCESSBRIDGE_LOGFILE to JAVA_ACCESSBRIDGE_LOGDIRECTORY to reflect that it accepts only a directory value in the variable. I have also changed the code in AccessBridgeDebug.cpp appropriately. So, currently, the code will look for the environment variable, which should contain path to the directory, and two log files namely "java_access_bridge.log" and "windows_access_bridge.log" will be created. Link to the JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8219914 Here is the webrev: http://cr.openjdk.java.net/~kaddepalli/8219914/webrev00/ Thanks, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Mar 28 20:57:23 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 28 Mar 2019 13:57:23 -0700 Subject: [13] RFR: JDK-8219914: Change the environment variable for Java Access Bridge logging to have a directory. In-Reply-To: References: <85eceba2-46e0-4462-9276-bfa79d9e0dd2@default> <5e06ce11-7f36-cb59-9c34-d830cc44df44@oracle.com> <52d8785c-0f32-0779-60a2-b2d86f977b0b@oracle.com> Message-ID: <5C9D3533.3080408@oracle.com> Ok, fair enough +1 -phil. On 3/27/19, 11:21 PM, Krishna Addepalli wrote: > > No it is not. When I'm adding "+1" and "+5", it simply adds that many > number of characters to the size. > > The sizeof(char) can be more than 1, and this statement at line 51 > (filePath = new char[filePathSize]), takes care of allocating > sufficient number of bytes, which accommodate "filePathSize" number of > characters. > > The problem is with memcpy and memset functions, which expect the size > of the buffer to be provided in terms of bytes, which is why, we need > the multiplier only in those functions. > > Even I'm in favor of getting rid of them, but unfortunately I cannot > std::string in this case, which would have vastly simplified the code, > and avoided this manual calculation of sizes, but that results in > compiler errors. > > Thanks, > > Krishna > > *From:*Phil Race > *Sent:* Thursday, March 28, 2019 3:11 AM > *To:* Krishna Addepalli ; > swing-dev at openjdk.java.net > *Subject:* Re: [13] RFR: JDK-8219914: Change the > environment variable for Java Access Bridge logging to have a directory. > > Hi, > > It is still inconsistent. the "+1" and "+5" logic relies on the answer > to sizeof(char) being 1. > So either get rid of all those calls or use sizeof('/') and > sizeof(".logX"); instead of 1 and 5. > > I'd get rid of them .... > > -phil > > On 3/27/19 1:41 AM, Krishna Addepalli wrote: > > Hi Phil, > > Thanks for the review. > > I have changed the variable to "JAVA_ACCESSBRIDGE_LOGDIR". > > Yes, '/' file separator character works on windows. I have used it > in the past and have also currently tested it on my machine and it > works. > > I have added the multiplier "sizeof(char)" for all memcpy and > memset lines in the code, to keep it consistent. Thanks for > pointing that out. > > Here is the link to the webrev: > http://cr.openjdk.java.net/~kaddepalli/8219914/webrev01/ > > > Thanks, > > Krishna > > *From:*Phil Race > *Sent:* Tuesday, March 26, 2019 10:42 PM > *To:* Krishna Addepalli > ; swing-dev at openjdk.java.net > > *Subject:* Re: [13] RFR: JDK-8219914: Change the > environment variable for Java Access Bridge logging to have a > directory. > > Can we just call it JAVA_ACCESSBRIDGE_LOGDIR ? > > > > > > filePath[envFilePathLength] = '/'; > > > > Is this right ? Does fopen on Windows expect this unix style separator ? > > > > > > 53 memcpy(filePath, envfilePath, envFilePathLength*sizeof(char)); > > > > 56 memcpy(filePath + envFilePathLength + 1 + fileNameLength, ".log", 4*sizeof(char)); > > > > Interesting that you feel it necessary to use sizeof(char) when clearly the whole logic, eg see : > > > > > > 50 auto filePathSize = envFilePathLength + 1 + fileNameLength + 5; //1 for "/", 5 for ".log" and 0; > > > > assumes it is 1 ... > > > > PrintDebugString("couldnot open file %s", filePath); > > couldnot -> could not > > -phil. > > > On 3/26/19 2:45 AM, Krishna Addepalli wrote: > > Hi Phil, > > Per our discussion, I have changed the > JAVA_ACCESSBRIDGE_LOGFILE to JAVA_ACCESSBRIDGE_LOGDIRECTORY to > reflect that it accepts only a directory value in the variable. > > I have also changed the code in AccessBridgeDebug.cpp > appropriately. > > So, currently, the code will look for the environment > variable, which should contain path to the directory, and two > log files namely "java_access_bridge.log" and > "windows_access_bridge.log" will be created. > > Link to the JDK Issue: > https://bugs.openjdk.java.net/browse/JDK-8219914 > > Here is the webrev: > http://cr.openjdk.java.net/~kaddepalli/8219914/webrev00/ > > > Thanks, > > Krishna > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Mar 28 20:58:33 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 28 Mar 2019 13:58:33 -0700 Subject: [13] RFR JDK-8212904:JTextArea line wrapping incorrect when using UI scale In-Reply-To: References: <5e3cb36e-fdad-b2ce-4774-f516fd37b420@oracle.com> <1d54eee0-63bc-ed48-fa06-aa250510b12f@oracle.com> <6f337ddd-79d9-484c-f92a-e5a264442276@oracle.com> <8a989061-2fd4-7f8e-6493-dd6f2d7dda15@oracle.com> <78e8ad46-f58e-d168-32a4-09d42b903b53@oracle.com> <23c338b5-2564-ebea-6da0-d2d5ed07952f@oracle.com> <1b3ab7f2-1a39-4a04-4fed-d1c23b86775f@oracle.com> Message-ID: <5C9D3579.2090604@oracle.com> Ok. +1 -phil. On 3/27/19, 10:01 PM, Prasanta Sadhukhan wrote: > Nothing specific. It was there in reproducer test in JBS and also to > make sure the test can be run in standalone mode and not only via jtreg. > > Regards > Prasanta > On 27-Mar-19 9:33 PM, Phil Race wrote: >> The product code change looks fine. I didn't examine the test >> super-closely but >> I am curious why you used System.setProperty("sun.java2d.uiScale", >> "1.25" ) >> instead of setting it on the command line ? >> >> -phil. >> >> On 3/26/19 10:25 PM, Prasanta Sadhukhan wrote: >>> OK. Modified webrev >>> >>> http://cr.openjdk.java.net/~psadhukhan/8212904/webrev.2/ >>> >>> Regards >>> Prasanta >>> On 27-Mar-19 2:25 AM, Sergey Bylokhov wrote: >>>> Hi, Prasanta. >>>> >>>> The "textArea.getHeight()" should be called on EDT, since this is a >>>> swing component. >>>> >>>> On 25/03/2019 22:01, Prasanta Sadhukhan wrote: >>>>> Thanks Sergey for the pointer. Modified test to be automated in >>>>> the webrev >>>>> >>>>> http://cr.openjdk.java.net/~psadhukhan/8212904/webrev.1/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 26-Mar-19 12:02 AM, Sergey Bylokhov wrote: >>>>>> On 25/03/2019 02:05, Prasanta Sadhukhan wrote: >>>>>>> Thanks Sergey for the pointer. But horizontal scrollbar is not >>>>>>> visible for both correct and broken wrap if scrollbar policy is >>>>>>> set to HORIZONTAL_SCROLLBAR_AS_NEEDED. >>>>>>> Also, the textArea.getHeight() is same for both >>>>>>> textArea.setWrapStyleWord( true ) and not. Attached is the >>>>>>> automated testcase I tried. >>>>>> >>>>>> In the test above the case for doWrapOffTest() still uses >>>>>> setLineWrap(true) which disable scroll bar, if you drop it the >>>>>> scrollbar will be visible. >>>>>> >>>>>> As of the height, you need to read the value a little bit later, >>>>>> not immediately after "frame.setVisible", for example if you read >>>>>> these values at lines 75,76 you will get something like that: >>>>>> textArea.getHeight() = 3216 >>>>>> textArea1.getHeight() = 1616 >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > From philip.race at oracle.com Thu Mar 28 21:02:38 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 28 Mar 2019 14:02:38 -0700 Subject: [12] RFR JDK-8210807:Printing a JTable with a JScrollPane prints table without rows populated In-Reply-To: <6bcd7158-dd21-d708-dfae-c04ea1b6f40c@oracle.com> References: <6bcd7158-dd21-d708-dfae-c04ea1b6f40c@oracle.com> Message-ID: <5C9D366E.1080108@oracle.com> That part now looks fine but Sergey's question SFAICT is still outstanding :- https://mail.openjdk.java.net/pipermail/swing-dev/2018-November/009147.html -phil. On 2/18/19, 10:46 PM, Prasanta Sadhukhan wrote: > > > > On 31-Jan-19 4:17 AM, Phil Race wrote: >> 755 if (g instanceof Graphics2D&& >> 756 !((g instanceof sun.print.PeekGraphics) || >> 757 (g instanceof sun.print.PathGraphics))) { >> >> You should test for the public interfaces .. I am not sure what you >> are doing here >> is going to do when we end up in banded printing which uses neither >> of these >> >> sun/swing/SwingUtilities2.java has this : >> /* >> * returns true if the Graphics is print Graphics >> * false otherwise >> */ >> static boolean isPrinting(Graphics g) { >> return (g instanceof PrinterGraphics || g instanceof >> PrintGraphics); >> } >> >> you could perhaps make it public and call that. >> > Thanks for the pointer. I have made the suggested change and here's > the modified webrev > http://cr.openjdk.java.net/~psadhukhan/8210807/webrev.1/ > > Regards > Prasanta >> -phil >> >> On 11/12/18 3:36 AM, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for an issue where it is seen that a simple >>> JTable doesn't print correctly if the table is contained in a >>> JScrollPane. >>> This is a regression of the fixJDK-8164032: >>> JViewport backing >>> store image is not scaled on HiDPI display >>> where JViewport's backing store image is scaled in the fix. >>> It seems this scaling of backing store image is not needed for >>> printing as the original backing store image or base image was >>> printed correctly before this fix. >>> Proposed fix is to check if the graphics object is been used for >>> printing ie PeekGraphics/pathGraphics then skip this backing store >>> image scaling. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210807 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8210807/webrev.0/ >>> >>> 8164032's manual regression testcase behaves in the same way before >>> and after this fix. >>> >>> Regards >>> Prasanta >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Mar 29 09:37:50 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 29 Mar 2019 15:07:50 +0530 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated Message-ID: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> Hi All, Please review a fix for an issue where it is seen that HTML tooltips aren't big enough to contain their contents on Windows HiDPI displays, there by the last word of the tooltip text are missing. It is an aftereffect of JDK-8178025 where we update glyph fontMetrics if current metrics is different from Container's fontmetrics. Even if the affinetransform or uiScale is modified, metrics is updated as FontMetrics would have changed because of the transform. This caused the tooltip rectangle to be not able to contain the text which is drawn with modified metrics. Proposed fix is to check if graphics transform has been modified because of hidpi scale, in which case, scale the tooltip rectangle accordingly. Bug: https://bugs.openjdk.java.net/browse/JDK-8213535 webrev: http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.0/ I was not able to fashion an automated test for this, so created a manual test. Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: