From serb at openjdk.java.net  Sun Nov  1 01:40:01 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 1 Nov 2020 01:40:01 GMT
Subject: <Swing Dev> RFR: 6816284: Notepad class should be public
Message-ID: <-sfkmJ1YkGLpYii3MGc7aRlWlMtFCYxWOxAlVU6ANBU=.a83b627b-03e2-49c7-a9a6-0db9850c2e77@github.com>

The main class in the Notepad demo made public

-------------

Commit messages:
 - Update Notepad.java

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

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

From serb at openjdk.java.net  Sun Nov  1 01:47:53 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 1 Nov 2020 01:47:53 GMT
Subject: <Swing Dev> RFR: 8233569: [TESTBUG] JTextComponent test
 bug6361367.java fails on macos
In-Reply-To: <IbuAR7Jn3RWTjKputAOJgm9JTxUtJnzbjb9PXhB-zGY=.4270a266-0240-4271-b91d-ad77777f186b@github.com>
References: <IbuAR7Jn3RWTjKputAOJgm9JTxUtJnzbjb9PXhB-zGY=.4270a266-0240-4271-b91d-ad77777f186b@github.com>
Message-ID: <zO6P6SdA9QikNm7SmwUp57RWyrK4lIYtYk5AhWr8pmg=.2d5515e4-ff69-4738-98d0-6a72da11cab4@github.com>

On Sat, 31 Oct 2020 14:53:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Please review deproblemlisting an issue which is not failing in latest build.  I have made the delay time consistent with other test.
> Resultant test is green on all platforms for mach5 test run.
> Mach5 job has been run for several iterations in all platforms. Link in JBS.

Marked as reviewed by serb (Reviewer).

-------------

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

From serb at openjdk.java.net  Sun Nov  1 02:22:59 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 1 Nov 2020 02:22:59 GMT
Subject: <Swing Dev> RFR: 8196302:
 javax/swing/JFileChooser/8041694/bug8041694.java
In-Reply-To: <NPv42bHaskeaveHilMT1uZ0rVvaRxXZ1ZFBV_UFeC1A=.dbd1ad17-8079-4886-887e-c40de422ea23@github.com>
References: <NPv42bHaskeaveHilMT1uZ0rVvaRxXZ1ZFBV_UFeC1A=.dbd1ad17-8079-4886-887e-c40de422ea23@github.com>
Message-ID: <FqmdhsdAdQnb5c0c1doHucHNy3ltWz1VzJHwFZBF9eA=.cc5dbf33-d165-4165-a467-8c47fe875589@github.com>

On Sat, 31 Oct 2020 10:55:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Another one of timing issue in mach5 windows solved by adjusted timing in setAutoDelay() and added waitForIdle().
> Mach5 job has been run for several iterations in all platforms. Link in JBS.

Marked as reviewed by serb (Reviewer).

-------------

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

From psadhukhan at openjdk.java.net  Sun Nov  1 15:49:55 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Sun, 1 Nov 2020 15:49:55 GMT
Subject: <Swing Dev> Integrated: 8196302:
 javax/swing/JFileChooser/8041694/bug8041694.java
In-Reply-To: <NPv42bHaskeaveHilMT1uZ0rVvaRxXZ1ZFBV_UFeC1A=.dbd1ad17-8079-4886-887e-c40de422ea23@github.com>
References: <NPv42bHaskeaveHilMT1uZ0rVvaRxXZ1ZFBV_UFeC1A=.dbd1ad17-8079-4886-887e-c40de422ea23@github.com>
Message-ID: <4zCHgLfM4k5rgAMjrYoBM_Hx-cLl3cx4Os4f3BQGeiM=.e978ab6a-e6d4-47ba-a9c7-102bd26067fb@github.com>

On Sat, 31 Oct 2020 10:55:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Another one of timing issue in mach5 windows solved by adjusted timing in setAutoDelay() and added waitForIdle().
> Mach5 job has been run for several iterations in all platforms. Link in JBS.

This pull request has now been integrated.

Changeset: 4c4b8f4d
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4c4b8f4d
Stats:     6 lines in 2 files changed: 4 ins; 2 del; 0 mod

8196302: javax/swing/JFileChooser/8041694/bug8041694.java

Reviewed-by: serb

-------------

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

From psadhukhan at openjdk.java.net  Sun Nov  1 15:54:54 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Sun, 1 Nov 2020 15:54:54 GMT
Subject: <Swing Dev> Integrated: 8233569: [TESTBUG] JTextComponent test
 bug6361367.java fails on macos
In-Reply-To: <IbuAR7Jn3RWTjKputAOJgm9JTxUtJnzbjb9PXhB-zGY=.4270a266-0240-4271-b91d-ad77777f186b@github.com>
References: <IbuAR7Jn3RWTjKputAOJgm9JTxUtJnzbjb9PXhB-zGY=.4270a266-0240-4271-b91d-ad77777f186b@github.com>
Message-ID: <_jbM73UZWvbuEY3xGPDKciQ0FqfQyv1VGHFhdT_jiOk=.7badbc05-7f85-4e8b-8385-c2f0e689f9ca@github.com>

On Sat, 31 Oct 2020 14:53:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Please review deproblemlisting an issue which is not failing in latest build.  I have made the delay time consistent with other test.
> Resultant test is green on all platforms for mach5 test run.
> Mach5 job has been run for several iterations in all platforms. Link in JBS.

This pull request has now been integrated.

Changeset: 518ff518
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/518ff518
Stats:     2 lines in 2 files changed: 0 ins; 1 del; 1 mod

8233569: [TESTBUG] JTextComponent test bug6361367.java fails on macos

Reviewed-by: serb

-------------

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

From psadhukhan at openjdk.java.net  Sun Nov  1 17:38:55 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Sun, 1 Nov 2020 17:38:55 GMT
Subject: <Swing Dev> Withdrawn: 8196465:
 javax/swing/JComboBox/8182031/ComboPopupTest.java fails on Linux
In-Reply-To: <0IUGO16kg8kZIXSq8lq4M1HPiK82nT78hnrooodrpJk=.fa0f4226-617f-4ce2-a3cd-07b2d1fd3fa5@github.com>
References: <0IUGO16kg8kZIXSq8lq4M1HPiK82nT78hnrooodrpJk=.fa0f4226-617f-4ce2-a3cd-07b2d1fd3fa5@github.com>
Message-ID: <PDZ9Ey_S1W_MLSZkCnuyQRFFx0BVKsZyqOCkNoUZSUE=.9908ff46-2ddd-47e5-836b-510f062c3812@github.com>

On Fri, 23 Oct 2020 09:50:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Please review a test fix for an issue seen to be failing in mach5 testing on linux whereby the combo popup is not opening.
> The issue is not reproducible locally in ubuntu18.04 but mach5 testing on ubuntu18.04 was able to see the issue. 
> Combo popup was opened by clicking at right edge of combo box, which sometimes is not set properly at mach5 system, so mouse click is clicked at wrong location of frame, thereby not opening the combo popup.
>  Modified the test to open the combo popup by clicking on middle of combobox which now works for all. Also, made robot autodelay consistent with other test to be 100ms. Also, changed deprecated constant to appropriate constants.
> Mach5 job was run for several iteration on all 3 platforms. Link in JBS

This pull request has been closed without being integrated.

-------------

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

From pbansal at openjdk.java.net  Sun Nov  1 17:50:00 2020
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Sun, 1 Nov 2020 17:50:00 GMT
Subject: <Swing Dev> RFR: 8251177: [macosx] The text "big" is truncated
Message-ID: <rNcxvoN2-u9cW0z10kB4B34p4JtOCNpVgoIcTJ15s5c=.9cb97ff7-30c4-4639-9c09-fc3d8b777628@github.com>

The manual test creates a JTabbedPane and add tabs with text with different html styles. For the tab with text "big", a bigger text size is used and it is expected that this should result in making the tab height bigger.

For AquaLookAndFeel, inside class AquaJTabbedPaneUI and AquaTabbedPaneCopyFromBasicUI, the tabs height is constraint and there is upper/lower limit set for tab height. So the tab height is less than expected and the text looks truncated. I do not see this issue in other L&Fs.

It looks like this is done deliberately for AquaL&F and this is not a bug. but the test instructions do not specify this and result in confusion. So updating the test instructions to specify that the text "big" may be truncated in MacOS.

-------------

Commit messages:
 - Remove test from ProblemList
 - 8251177: [macosx] The text big is truncated

Changes: https://git.openjdk.java.net/jdk/pull/984/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=984&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251177
  Stats: 4 lines in 2 files changed: 2 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/984.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/984/head:pull/984

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

From serb at openjdk.java.net  Sun Nov  1 23:20:04 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 1 Nov 2020 23:20:04 GMT
Subject: <Swing Dev> RFR: 7124397: [macosx] JSpinner serialiazation -
 deserialization issue
Message-ID: <bca3daI235KLExL5QHdhi08gpQ2OcDQ7a-uDBBOrs-0=.f0b09192-1ffe-44ca-ade7-d7efe59a6f7e@github.com>

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

-------------

Commit messages:
 - Create SerializationTest.java

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

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

From serb at openjdk.java.net  Mon Nov  2 00:00:53 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 2 Nov 2020 00:00:53 GMT
Subject: <Swing Dev> RFR: 8251177: [macosx] The text "big" is truncated
In-Reply-To: <rNcxvoN2-u9cW0z10kB4B34p4JtOCNpVgoIcTJ15s5c=.9cb97ff7-30c4-4639-9c09-fc3d8b777628@github.com>
References: <rNcxvoN2-u9cW0z10kB4B34p4JtOCNpVgoIcTJ15s5c=.9cb97ff7-30c4-4639-9c09-fc3d8b777628@github.com>
Message-ID: <txGuRtIYpXNUaUnXreWwb_PcA1Gi_AxdFTj5FCUzeYw=.d2f718c4-ef8e-4989-a969-4578e2b491c6@github.com>

On Sun, 1 Nov 2020 17:21:58 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

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

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

-------------

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

From jdv at openjdk.java.net  Mon Nov  2 03:41:59 2020
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 2 Nov 2020 03:41:59 GMT
Subject: <Swing Dev> RFR: 8233637: [TESTBUG] Swing
 ActionListenerCalledTwiceTest.java fails on macos
In-Reply-To: <nwi2B_F0BFE1_X_1d-yGXtBFhfnfVgQds9RY29MoInE=.a3afa0a4-dcd2-4040-b604-e3673b917ece@github.com>
References: <nvvY5qjdkE4eZtPjria9mD4WdmgQm2Jn_VnlqsohpBQ=.113622b1-717a-4e45-a7ea-d0cd36eb001e@github.com>
 <nwi2B_F0BFE1_X_1d-yGXtBFhfnfVgQds9RY29MoInE=.a3afa0a4-dcd2-4040-b604-e3673b917ece@github.com>
Message-ID: <mBwS72Waa_2DXZ48hnBeW6y-6WhYifPZOyGYIokZpNQ=.1e8b60fa-4605-46d9-b029-6feb31f149bc@github.com>

On Thu, 29 Oct 2020 23:26:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Please review a test fix for a test issue seen to be failing on mach5 macos systems due to timing issue.
>> Modified the test to added delay() after frame is made visible and moved the frame to centre of screen to be consistent with other tests.
>> Mach5 job has been run for several iterations in all platforms. Link in JBS.
>
> Please ask @jayathirthrao, who was able to reproduce this bug on the local system, about approval.

I tested with or without fix in my local system with all the settings that we do for jtreg tests but still it fails in my system.
Someone else with 10.15 please verify the behaviour or we can say that it passes in our CI system and there is some specific issue with my system.

-------------

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

From jdv at openjdk.java.net  Mon Nov  2 03:42:00 2020
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 2 Nov 2020 03:42:00 GMT
Subject: <Swing Dev> RFR: 8233641: [TESTBUG] JMenuItem test
 bug4171437.java fails on macos
In-Reply-To: <TYZLcN-sTCoa7nO04HbrmDP8SYqv7KRJPNNSUkwLLHg=.a33d5be2-da88-4e46-ba91-be33a65b96e1@github.com>
References: <x3nzJ3LWvArXe7yda-sKb9g2VWZenZZcQ3L3CBCAb_w=.27b15b3c-4e2a-4177-bd7d-b4b04c935198@github.com>
 <TYZLcN-sTCoa7nO04HbrmDP8SYqv7KRJPNNSUkwLLHg=.a33d5be2-da88-4e46-ba91-be33a65b96e1@github.com>
Message-ID: <_v3_R5wapLw6flxbFG0L1m-PWKgwy8WQntLr02Lspbo=.82613709-50bd-40db-bfef-321424063820@github.com>

On Thu, 29 Oct 2020 05:36:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Please review a test fix for a test issue seen to be failing on mach5 macos systems due to timing issue.
>> Modified the test to modify setAutoDelay() time, added delay() after frame is made visible and moved the frame to centre of screen.
>> Mach5 job has been run for several iterations in all platforms. Link in JBS.
>
> Please ask @jayathirthrao, who was able to reproduce this bug on the local system, about approval.

I tested with or without fix in my local system with all the settings that we do for jtreg tests but still it fails in my system.
Someone else with 10.15 please verify the behaviour or we can say that it passes in our CI system and there is some specific issue with my system.

-------------

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

From psadhukhan at openjdk.java.net  Mon Nov  2 08:28:01 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 2 Nov 2020 08:28:01 GMT
Subject: <Swing Dev> RFR: 8255215: Unsupported 'valign' attribute for 'tr'
 tag used in j.s.t.h.HTMLDocument
Message-ID: <0z1N6lTLhz_Jdd5tjzzGbnwSaTz2__iNF9_-G1bT2Rw=.90867000-46cb-44d9-a291-9d614f0e3e9b@github.com>

Since HTML4 support has been dropped from javadoc by JDK-8187793.
HTMLDocument.java containing the valign attribute in the table element, `valign="top"` 
needs to be replaced with `style="vertical-align:top"

-------------

Commit messages:
 - 8255215: Unsupported 'valign' attribute for 'tr' tag used in j.s.t.h.HTMLDocument

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

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

From serb at openjdk.java.net  Mon Nov  2 08:38:54 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 2 Nov 2020 08:38:54 GMT
Subject: <Swing Dev> RFR: 8255215: Unsupported 'valign' attribute for
 'tr' tag used in j.s.t.h.HTMLDocument
In-Reply-To: <0z1N6lTLhz_Jdd5tjzzGbnwSaTz2__iNF9_-G1bT2Rw=.90867000-46cb-44d9-a291-9d614f0e3e9b@github.com>
References: <0z1N6lTLhz_Jdd5tjzzGbnwSaTz2__iNF9_-G1bT2Rw=.90867000-46cb-44d9-a291-9d614f0e3e9b@github.com>
Message-ID: <K4AzPEoj0-BBviDB1zuEkj7Kd7lG4M4QElkQyedvf54=.aded5197-185c-44f1-b052-c46cfe757b76@github.com>

On Mon, 2 Nov 2020 08:18:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Since HTML4 support has been dropped from javadoc by JDK-8187793.
> HTMLDocument.java containing the valign attribute in the table element, `valign="top"` 
> needs to be replaced with `style="vertical-align:top"

Marked as reviewed by serb (Reviewer).

-------------

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

From jdv at openjdk.java.net  Mon Nov  2 10:35:55 2020
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 2 Nov 2020 10:35:55 GMT
Subject: <Swing Dev> RFR: 8233641: [TESTBUG] JMenuItem test
 bug4171437.java fails on macos
In-Reply-To: <x3nzJ3LWvArXe7yda-sKb9g2VWZenZZcQ3L3CBCAb_w=.27b15b3c-4e2a-4177-bd7d-b4b04c935198@github.com>
References: <x3nzJ3LWvArXe7yda-sKb9g2VWZenZZcQ3L3CBCAb_w=.27b15b3c-4e2a-4177-bd7d-b4b04c935198@github.com>
Message-ID: <q4iZKe62xqIgC1p_32XVO0Px0ngenWMQSTk68P1weqY=.18b1ee21-9399-40e1-af19-fb00d6f72a2a@github.com>

On Thu, 29 Oct 2020 05:09:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Please review a test fix for a test issue seen to be failing on mach5 macos systems due to timing issue.
> Modified the test to modify setAutoDelay() time, added delay() after frame is made visible and moved the frame to centre of screen.
> Mach5 job has been run for several iterations in all platforms. Link in JBS.

Marked as reviewed by jdv (Reviewer).

-------------

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

From jdv at openjdk.java.net  Mon Nov  2 10:35:56 2020
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 2 Nov 2020 10:35:56 GMT
Subject: <Swing Dev> RFR: 8233641: [TESTBUG] JMenuItem test
 bug4171437.java fails on macos
In-Reply-To: <_v3_R5wapLw6flxbFG0L1m-PWKgwy8WQntLr02Lspbo=.82613709-50bd-40db-bfef-321424063820@github.com>
References: <x3nzJ3LWvArXe7yda-sKb9g2VWZenZZcQ3L3CBCAb_w=.27b15b3c-4e2a-4177-bd7d-b4b04c935198@github.com>
 <TYZLcN-sTCoa7nO04HbrmDP8SYqv7KRJPNNSUkwLLHg=.a33d5be2-da88-4e46-ba91-be33a65b96e1@github.com>
 <_v3_R5wapLw6flxbFG0L1m-PWKgwy8WQntLr02Lspbo=.82613709-50bd-40db-bfef-321424063820@github.com>
Message-ID: <K6L8BJJCsODblwYxf70s1no7QY0Tcwgew3C7v0czf0I=.4793abad-62ca-4bc3-8bc8-3fc78f1f345a@github.com>

On Mon, 2 Nov 2020 03:39:18 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Please ask @jayathirthrao, who was able to reproduce this bug on the local system, about approval.
>
> I tested with or without fix in my local system with all the settings that we do for jtreg tests but still it fails in my system.
> Someone else with 10.15 please verify the behaviour or we can say that it passes in our CI system and there is some specific issue with my system.

If we dont give permission for "terminal" to control the computer in System Preferences -> Security & Privacy -> Privacy -> Accessibility i see that the test fails.

After enabling it i see that test passes without fix also. Looks like it was issue related to some settings.
Present change looks like some common test refactoring.

-------------

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

From jdv at openjdk.java.net  Mon Nov  2 10:37:03 2020
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 2 Nov 2020 10:37:03 GMT
Subject: <Swing Dev> RFR: 8233637: [TESTBUG] Swing
 ActionListenerCalledTwiceTest.java fails on macos
In-Reply-To: <mBwS72Waa_2DXZ48hnBeW6y-6WhYifPZOyGYIokZpNQ=.1e8b60fa-4605-46d9-b029-6feb31f149bc@github.com>
References: <nvvY5qjdkE4eZtPjria9mD4WdmgQm2Jn_VnlqsohpBQ=.113622b1-717a-4e45-a7ea-d0cd36eb001e@github.com>
 <nwi2B_F0BFE1_X_1d-yGXtBFhfnfVgQds9RY29MoInE=.a3afa0a4-dcd2-4040-b604-e3673b917ece@github.com>
 <mBwS72Waa_2DXZ48hnBeW6y-6WhYifPZOyGYIokZpNQ=.1e8b60fa-4605-46d9-b029-6feb31f149bc@github.com>
Message-ID: <2L86Qpl14smvViMCy0MGCVUpUzmJs8qIpwu004FPXjQ=.f0fae02f-d073-4a30-be8c-378da4ecda5e@github.com>

On Mon, 2 Nov 2020 03:39:31 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Please ask @jayathirthrao, who was able to reproduce this bug on the local system, about approval.
>
> I tested with or without fix in my local system with all the settings that we do for jtreg tests but still it fails in my system.
> Someone else with 10.15 please verify the behaviour or we can say that it passes in our CI system and there is some specific issue with my system.

If we dont give permission for "terminal" to control the computer in System Preferences -> Security & Privacy -> Privacy -> Accessibility i see that the test fails.

After enabling it i see that test passes without fix also. Looks like it was issue related to some settings.
Present change looks like some common test refactoring.

-------------

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

From jdv at openjdk.java.net  Mon Nov  2 10:37:01 2020
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 2 Nov 2020 10:37:01 GMT
Subject: <Swing Dev> RFR: 8233637: [TESTBUG] Swing
 ActionListenerCalledTwiceTest.java fails on macos
In-Reply-To: <nvvY5qjdkE4eZtPjria9mD4WdmgQm2Jn_VnlqsohpBQ=.113622b1-717a-4e45-a7ea-d0cd36eb001e@github.com>
References: <nvvY5qjdkE4eZtPjria9mD4WdmgQm2Jn_VnlqsohpBQ=.113622b1-717a-4e45-a7ea-d0cd36eb001e@github.com>
Message-ID: <9XytgKO4MkJ7QFUAVelz8bRLr5mD2oMnVIpSePiQLtE=.855c637d-6805-4e3a-938b-f728389ee392@github.com>

On Thu, 29 Oct 2020 09:21:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Please review a test fix for a test issue seen to be failing on mach5 macos systems due to timing issue.
> Modified the test to added delay() after frame is made visible and moved the frame to centre of screen to be consistent with other tests.
> Mach5 job has been run for several iterations in all platforms. Link in JBS.

Marked as reviewed by jdv (Reviewer).

-------------

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

From psadhukhan at openjdk.java.net  Mon Nov  2 10:44:04 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 2 Nov 2020 10:44:04 GMT
Subject: <Swing Dev> Integrated: 8233641: [TESTBUG] JMenuItem test
 bug4171437.java fails on macos
In-Reply-To: <x3nzJ3LWvArXe7yda-sKb9g2VWZenZZcQ3L3CBCAb_w=.27b15b3c-4e2a-4177-bd7d-b4b04c935198@github.com>
References: <x3nzJ3LWvArXe7yda-sKb9g2VWZenZZcQ3L3CBCAb_w=.27b15b3c-4e2a-4177-bd7d-b4b04c935198@github.com>
Message-ID: <fP09lNfcXqA8Mz24wkhOo35VJWFcIix-e6YfGAijzD8=.af38734c-734f-4d5b-b4fd-aa40fd64500c@github.com>

On Thu, 29 Oct 2020 05:09:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Please review a test fix for a test issue seen to be failing on mach5 macos systems due to timing issue.
> Modified the test to modify setAutoDelay() time, added delay() after frame is made visible and moved the frame to centre of screen.
> Mach5 job has been run for several iterations in all platforms. Link in JBS.

This pull request has now been integrated.

Changeset: e97809d3
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e97809d3
Stats:     8 lines in 2 files changed: 4 ins; 4 del; 0 mod

8233641: [TESTBUG] JMenuItem test bug4171437.java fails on macos

Reviewed-by: jdv

-------------

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

From psadhukhan at openjdk.java.net  Mon Nov  2 10:44:05 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 2 Nov 2020 10:44:05 GMT
Subject: <Swing Dev> Integrated: 8233637: [TESTBUG] Swing
 ActionListenerCalledTwiceTest.java fails on macos
In-Reply-To: <nvvY5qjdkE4eZtPjria9mD4WdmgQm2Jn_VnlqsohpBQ=.113622b1-717a-4e45-a7ea-d0cd36eb001e@github.com>
References: <nvvY5qjdkE4eZtPjria9mD4WdmgQm2Jn_VnlqsohpBQ=.113622b1-717a-4e45-a7ea-d0cd36eb001e@github.com>
Message-ID: <u3eurCK4WZtgfHuUX11F3p-8WcNI4nzsh2emj8fACns=.d45da149-6cc6-445b-9784-c2a04fd65810@github.com>

On Thu, 29 Oct 2020 09:21:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Please review a test fix for a test issue seen to be failing on mach5 macos systems due to timing issue.
> Modified the test to added delay() after frame is made visible and moved the frame to centre of screen to be consistent with other tests.
> Mach5 job has been run for several iterations in all platforms. Link in JBS.

This pull request has now been integrated.

Changeset: 98c91b64
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/98c91b64
Stats:     6 lines in 2 files changed: 3 ins; 1 del; 2 mod

8233637: [TESTBUG] Swing ActionListenerCalledTwiceTest.java fails on macos

Reviewed-by: jdv

-------------

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

From pbansal at openjdk.java.net  Mon Nov  2 10:46:08 2020
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 2 Nov 2020 10:46:08 GMT
Subject: <Swing Dev> RFR: 8251177: [macosx] The text "big" is truncated
 [v2]
In-Reply-To: <rNcxvoN2-u9cW0z10kB4B34p4JtOCNpVgoIcTJ15s5c=.9cb97ff7-30c4-4639-9c09-fc3d8b777628@github.com>
References: <rNcxvoN2-u9cW0z10kB4B34p4JtOCNpVgoIcTJ15s5c=.9cb97ff7-30c4-4639-9c09-fc3d8b777628@github.com>
Message-ID: <6ivHhPE02egllHHKmsv57OrC-W5h8AujU03sgrG5u5I=.3e858a0f-a451-4b90-a445-53b6b1d39b1b@github.com>

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

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

  Fixing review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/984/files
  - new: https://git.openjdk.java.net/jdk/pull/984/files/e6e441e3..206a5db0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=984&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=984&range=00-01

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

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

From pbansal at openjdk.java.net  Mon Nov  2 10:52:05 2020
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 2 Nov 2020 10:52:05 GMT
Subject: <Swing Dev> RFR: 8251177: [macosx] The text "big" is truncated
In-Reply-To: <txGuRtIYpXNUaUnXreWwb_PcA1Gi_AxdFTj5FCUzeYw=.d2f718c4-ef8e-4989-a969-4578e2b491c6@github.com>
References: <rNcxvoN2-u9cW0z10kB4B34p4JtOCNpVgoIcTJ15s5c=.9cb97ff7-30c4-4639-9c09-fc3d8b777628@github.com>
 <txGuRtIYpXNUaUnXreWwb_PcA1Gi_AxdFTj5FCUzeYw=.d2f718c4-ef8e-4989-a969-4578e2b491c6@github.com>
Message-ID: <isNErhKDLJBI-PWLJiflvotmP4i1aAim6Akcma5pxUM=.f192f9b3-c697-4190-ad30-39ff1318ba27@github.com>

On Sun, 1 Nov 2020 23:58:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

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

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

-------------

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

From pbansal at openjdk.java.net  Mon Nov  2 11:04:00 2020
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 2 Nov 2020 11:04:00 GMT
Subject: <Swing Dev> RFR: 7124397: [macosx] JSpinner serialiazation -
 deserialization issue
In-Reply-To: <bca3daI235KLExL5QHdhi08gpQ2OcDQ7a-uDBBOrs-0=.f0b09192-1ffe-44ca-ade7-d7efe59a6f7e@github.com>
References: <bca3daI235KLExL5QHdhi08gpQ2OcDQ7a-uDBBOrs-0=.f0b09192-1ffe-44ca-ade7-d7efe59a6f7e@github.com>
Message-ID: <ICPBJCFDJ9odNt1N708cN43_TCzFJ49QMHGep8kqNaw=.d1196168-29c0-47b9-a504-3842269850cc@github.com>

On Sun, 1 Nov 2020 23:12:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

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

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

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

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

-------------

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

From pbansal at openjdk.java.net  Mon Nov  2 11:07:04 2020
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 2 Nov 2020 11:07:04 GMT
Subject: <Swing Dev> RFR: 6816284: Notepad class should be public
In-Reply-To: <-sfkmJ1YkGLpYii3MGc7aRlWlMtFCYxWOxAlVU6ANBU=.a83b627b-03e2-49c7-a9a6-0db9850c2e77@github.com>
References: <-sfkmJ1YkGLpYii3MGc7aRlWlMtFCYxWOxAlVU6ANBU=.a83b627b-03e2-49c7-a9a6-0db9850c2e77@github.com>
Message-ID: <WgjPp472yYrvOgzdcSsMkDvh1yg4bYXdMhAsgTnnadU=.53f0364f-502a-4edd-b544-b22eab95c7b0@github.com>

On Sun, 1 Nov 2020 01:30:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The main class in the Notepad demo made public

Marked as reviewed by pbansal (Reviewer).

-------------

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

From serb at openjdk.java.net  Mon Nov  2 11:18:55 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 2 Nov 2020 11:18:55 GMT
Subject: <Swing Dev> RFR: 8251177: [macosx] The text "big" is truncated
In-Reply-To: <isNErhKDLJBI-PWLJiflvotmP4i1aAim6Akcma5pxUM=.f192f9b3-c697-4190-ad30-39ff1318ba27@github.com>
References: <rNcxvoN2-u9cW0z10kB4B34p4JtOCNpVgoIcTJ15s5c=.9cb97ff7-30c4-4639-9c09-fc3d8b777628@github.com>
 <txGuRtIYpXNUaUnXreWwb_PcA1Gi_AxdFTj5FCUzeYw=.d2f718c4-ef8e-4989-a969-4578e2b491c6@github.com>
 <isNErhKDLJBI-PWLJiflvotmP4i1aAim6Akcma5pxUM=.f192f9b3-c697-4190-ad30-39ff1318ba27@github.com>
Message-ID: <aC_pugW0FZ_jnGWVtAewJWXHB7BjZzXG1CgSNKYjwJY=.bd7c44d9-5a8f-48ab-87e2-424025ecfea1@github.com>

On Mon, 2 Nov 2020 10:49:00 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

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

I meant to limit the font size in the tab-pane.

-------------

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

From serb at openjdk.java.net  Mon Nov  2 11:56:13 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 2 Nov 2020 11:56:13 GMT
Subject: <Swing Dev> RFR: 7124397: [macosx] JSpinner serialiazation -
 deserialization issue [v2]
In-Reply-To: <ICPBJCFDJ9odNt1N708cN43_TCzFJ49QMHGep8kqNaw=.d1196168-29c0-47b9-a504-3842269850cc@github.com>
References: <bca3daI235KLExL5QHdhi08gpQ2OcDQ7a-uDBBOrs-0=.f0b09192-1ffe-44ca-ade7-d7efe59a6f7e@github.com>
 <ICPBJCFDJ9odNt1N708cN43_TCzFJ49QMHGep8kqNaw=.d1196168-29c0-47b9-a504-3842269850cc@github.com>
Message-ID: <p6r4qZ2r6cWH2qq8b3lVCfvlWpKAxz5BdbrHy7KDt0k=.2286d097-29ac-406c-bb9c-595c62172cca@github.com>

On Mon, 2 Nov 2020 11:00:48 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   the summary is added to the test
>
> test/jdk/javax/swing/JSpinner/SerializationTest.java line 40:
> 
>> 38: /**
>> 39:  * @test
>> 40:  * @bug 7124397
> 
> Can we add a @summary tag here to give small summary about the purpose of test?

fixed

-------------

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

From serb at openjdk.java.net  Mon Nov  2 11:56:12 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 2 Nov 2020 11:56:12 GMT
Subject: <Swing Dev> RFR: 7124397: [macosx] JSpinner serialiazation -
 deserialization issue [v2]
In-Reply-To: <bca3daI235KLExL5QHdhi08gpQ2OcDQ7a-uDBBOrs-0=.f0b09192-1ffe-44ca-ade7-d7efe59a6f7e@github.com>
References: <bca3daI235KLExL5QHdhi08gpQ2OcDQ7a-uDBBOrs-0=.f0b09192-1ffe-44ca-ade7-d7efe59a6f7e@github.com>
Message-ID: <JjnJG28gu_wbk1O8TZpOJppep41uM2aRjF-AOsKuzkM=.1fa41f9b-5b63-423e-b098-191a953f8493@github.com>

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

Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:

  the summary is added to the test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/989/files
  - new: https://git.openjdk.java.net/jdk/pull/989/files/061014c4..14615927

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=989&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=989&range=00-01

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

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

From pbansal at openjdk.java.net  Mon Nov  2 11:59:56 2020
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 2 Nov 2020 11:59:56 GMT
Subject: <Swing Dev> RFR: 7124397: [macosx] JSpinner serialiazation -
 deserialization issue [v2]
In-Reply-To: <JjnJG28gu_wbk1O8TZpOJppep41uM2aRjF-AOsKuzkM=.1fa41f9b-5b63-423e-b098-191a953f8493@github.com>
References: <bca3daI235KLExL5QHdhi08gpQ2OcDQ7a-uDBBOrs-0=.f0b09192-1ffe-44ca-ade7-d7efe59a6f7e@github.com>
 <JjnJG28gu_wbk1O8TZpOJppep41uM2aRjF-AOsKuzkM=.1fa41f9b-5b63-423e-b098-191a953f8493@github.com>
Message-ID: <PjzBzOln0wSuLi9tGivaVCzdhmA64sUZHNf9yJkchlE=.08e7e263-6a0a-412a-9fb5-504fc2d7b043@github.com>

On Mon, 2 Nov 2020 11:56:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

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

Marked as reviewed by pbansal (Reviewer).

-------------

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

From pbansal at openjdk.java.net  Mon Nov  2 12:13:53 2020
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 2 Nov 2020 12:13:53 GMT
Subject: <Swing Dev> RFR: 8251177: [macosx] The text "big" is truncated
In-Reply-To: <aC_pugW0FZ_jnGWVtAewJWXHB7BjZzXG1CgSNKYjwJY=.bd7c44d9-5a8f-48ab-87e2-424025ecfea1@github.com>
References: <rNcxvoN2-u9cW0z10kB4B34p4JtOCNpVgoIcTJ15s5c=.9cb97ff7-30c4-4639-9c09-fc3d8b777628@github.com>
 <txGuRtIYpXNUaUnXreWwb_PcA1Gi_AxdFTj5FCUzeYw=.d2f718c4-ef8e-4989-a969-4578e2b491c6@github.com>
 <isNErhKDLJBI-PWLJiflvotmP4i1aAim6Akcma5pxUM=.f192f9b3-c697-4190-ad30-39ff1318ba27@github.com>
 <aC_pugW0FZ_jnGWVtAewJWXHB7BjZzXG1CgSNKYjwJY=.bd7c44d9-5a8f-48ab-87e2-424025ecfea1@github.com>
Message-ID: <OUWXWrZ9y6qKGnC2IYfbWmJDTCOJqsM3DfOrLfxUNYU=.0541ed89-1e70-440f-93fd-1b1f0586b6fa@github.com>

On Mon, 2 Nov 2020 11:16:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I meant to limit the font size in the tab-pane.

ok, just for clarification, you mean this should be fixed as product bug not test issue? We should limit the font size in AquaJTabbedPaneUI, so that the text is not truncated?

-------------

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

From serb at openjdk.java.net  Mon Nov  2 12:19:55 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 2 Nov 2020 12:19:55 GMT
Subject: <Swing Dev> RFR: 8251177: [macosx] The text "big" is truncated
In-Reply-To: <OUWXWrZ9y6qKGnC2IYfbWmJDTCOJqsM3DfOrLfxUNYU=.0541ed89-1e70-440f-93fd-1b1f0586b6fa@github.com>
References: <rNcxvoN2-u9cW0z10kB4B34p4JtOCNpVgoIcTJ15s5c=.9cb97ff7-30c4-4639-9c09-fc3d8b777628@github.com>
 <txGuRtIYpXNUaUnXreWwb_PcA1Gi_AxdFTj5FCUzeYw=.d2f718c4-ef8e-4989-a969-4578e2b491c6@github.com>
 <isNErhKDLJBI-PWLJiflvotmP4i1aAim6Akcma5pxUM=.f192f9b3-c697-4190-ad30-39ff1318ba27@github.com>
 <aC_pugW0FZ_jnGWVtAewJWXHB7BjZzXG1CgSNKYjwJY=.bd7c44d9-5a8f-48ab-87e2-424025ecfea1@github.com>
 <OUWXWrZ9y6qKGnC2IYfbWmJDTCOJqsM3DfOrLfxUNYU=.0541ed89-1e70-440f-93fd-1b1f0586b6fa@github.com>
Message-ID: <3h0puHJzh5Vgc-9wmgtsBjlqoW3mjnBcZxb88rtavMk=.58b41239-b47a-4f69-8864-cec09a36263b@github.com>

On Mon, 2 Nov 2020 12:11:34 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> > I meant to limit the font size in the tab-pane.
> 
> ok, just for clarification, you mean this should be fixed as product bug not test issue? We should limit the font size in AquaJTabbedPaneUI, so that the text is not truncated?

Yes something like that in the JDK itself, I remember that menu items in the menubar on windows behave in a similar way, ignore the font size bigger some value.

-------------

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

From serb at openjdk.java.net  Mon Nov  2 12:21:58 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 2 Nov 2020 12:21:58 GMT
Subject: <Swing Dev> RFR: 7190978:
 javax/swing/JComponent/7154030/bug7154030.java fails on mac
In-Reply-To: <PnFXqzw83ENyBPH6nu57W5SPP0XPrXRsmJQhX4ovIeU=.1f13e52b-9cc6-4ff7-bb55-9898b1292190@github.com>
References: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
 <Az8BCBq_BJ6vjRTrOjtIPh2znxedQvxbasMvtZ79j8g=.c48c1c99-316a-400e-a05b-f8310e180b3d@github.com>
 <PnFXqzw83ENyBPH6nu57W5SPP0XPrXRsmJQhX4ovIeU=.1f13e52b-9cc6-4ff7-bb55-9898b1292190@github.com>
Message-ID: <Wf3yUJ0_l4myQu6LZ5gaI8O0KPMu8D57iu1Z3kS1JCM=.e18d8d73-35ce-43cb-b87b-9ac62c5fd9d8@github.com>

On Sat, 31 Oct 2020 11:06:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 55:
>> 
>>> 53:  * @build Util
>>> 54:  * @build ExtendedRobot
>>> 55:  * @run main/othervm -Dsun.java2d.uiScale=1 bug7154030
>> 
>> The "sun.java2d.uiScale" does not affect the sizes of the frame on macOS, Is it possible that it was reported on HiDPI screen macOS?
>
> It was reported in macmini (probably connect to hidpi screen) and iMac (I guess having hidpi screen).
> Also, I have seen mach5 job failing on windows too.
> I have posted failing mach5 jobs in JBS.

Then please double-check that the test will pass after the fix on HiDPI screen. Not sure that -Dsun.java2d.uiScale=1 affects such usecase.

-------------

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

From serb at openjdk.java.net  Mon Nov  2 12:30:10 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 2 Nov 2020 12:30:10 GMT
Subject: <Swing Dev> Integrated: 7124397: [macosx] JSpinner serialiazation -
 deserialization issue
In-Reply-To: <bca3daI235KLExL5QHdhi08gpQ2OcDQ7a-uDBBOrs-0=.f0b09192-1ffe-44ca-ade7-d7efe59a6f7e@github.com>
References: <bca3daI235KLExL5QHdhi08gpQ2OcDQ7a-uDBBOrs-0=.f0b09192-1ffe-44ca-ade7-d7efe59a6f7e@github.com>
Message-ID: <zmSEBJ9euYavchh97_nAhdzyAJKF4QhlVk6qnWrja_A=.28d911c0-5f84-4080-a603-b33383490cb2@github.com>

On Sun, 1 Nov 2020 23:12:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: eb66418b
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/eb66418b
Stats:     78 lines in 1 file changed: 78 ins; 0 del; 0 mod

7124397: [macosx] JSpinner serialiazation - deserialization issue

Reviewed-by: pbansal

-------------

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

From serb at openjdk.java.net  Mon Nov  2 12:33:59 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 2 Nov 2020 12:33:59 GMT
Subject: <Swing Dev> Integrated: 6816284: Notepad class should be public
In-Reply-To: <-sfkmJ1YkGLpYii3MGc7aRlWlMtFCYxWOxAlVU6ANBU=.a83b627b-03e2-49c7-a9a6-0db9850c2e77@github.com>
References: <-sfkmJ1YkGLpYii3MGc7aRlWlMtFCYxWOxAlVU6ANBU=.a83b627b-03e2-49c7-a9a6-0db9850c2e77@github.com>
Message-ID: <sDgyb4FTPMQbinxtIPeoZkamNjZ2uMiQDzid5CB6qcQ=.2d668af3-fe9e-4085-be48-dd6eb8c7aa63@github.com>

On Sun, 1 Nov 2020 01:30:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The main class in the Notepad demo made public

This pull request has now been integrated.

Changeset: ceab9f32
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ceab9f32
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

6816284: Notepad class should be public

Reviewed-by: pbansal

-------------

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

From psadhukhan at openjdk.java.net  Mon Nov  2 12:52:58 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 2 Nov 2020 12:52:58 GMT
Subject: <Swing Dev> RFR: 7190978:
 javax/swing/JComponent/7154030/bug7154030.java fails on mac
In-Reply-To: <Wf3yUJ0_l4myQu6LZ5gaI8O0KPMu8D57iu1Z3kS1JCM=.e18d8d73-35ce-43cb-b87b-9ac62c5fd9d8@github.com>
References: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
 <Az8BCBq_BJ6vjRTrOjtIPh2znxedQvxbasMvtZ79j8g=.c48c1c99-316a-400e-a05b-f8310e180b3d@github.com>
 <PnFXqzw83ENyBPH6nu57W5SPP0XPrXRsmJQhX4ovIeU=.1f13e52b-9cc6-4ff7-bb55-9898b1292190@github.com>
 <Wf3yUJ0_l4myQu6LZ5gaI8O0KPMu8D57iu1Z3kS1JCM=.e18d8d73-35ce-43cb-b87b-9ac62c5fd9d8@github.com>
Message-ID: <qe8GqluK5h14KUPp6RaWhWh8BXL3TKSiZCxDI1vdZR0=.789f7596-af95-4fcc-9e91-38c0740210ff@github.com>

On Mon, 2 Nov 2020 12:19:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> It was reported in macmini (probably connect to hidpi screen) and iMac (I guess having hidpi screen).
>> Also, I have seen mach5 job failing on windows too.
>> I have posted failing mach5 jobs in JBS.
>
> Then please double-check that the test will pass after the fix on HiDPI screen. Not sure that -Dsun.java2d.uiScale=1 affects such usecase.

Since mach5 systems are mostly macmini, where it initially failed, and the resultant test is passing on them, I would hope they will pass on hidpi screen they are connected to.

-------------

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

From psadhukhan at openjdk.java.net  Mon Nov  2 12:54:01 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 2 Nov 2020 12:54:01 GMT
Subject: <Swing Dev> RFR: 8196089:
 javax/swing/Action/8133039/bug8133039.java fails
In-Reply-To: <J1-C1TQD5l8FDz_bDmmwslLz5Tkni6Fxi25y3yoBY8Q=.0f8c722f-51bb-43fe-8283-42513a07d54c@github.com>
References: <EXtKsy-yNPIs_nPQoYpWTiDI9isXuyJWwdDUETAZqjE=.c189fcc6-8ece-4f47-8901-53f93370fad7@github.com>
 <mq8EsRQavNbVPXSJq4RjgSKt5TaeCJ816N7wl8sm9FY=.56202a81-efe7-48e6-a4d1-205c23f60cae@github.com>
 <J1-C1TQD5l8FDz_bDmmwslLz5Tkni6Fxi25y3yoBY8Q=.0f8c722f-51bb-43fe-8283-42513a07d54c@github.com>
Message-ID: <iflzMj42oipWbyFeHcQOw43kz23KXSXRb5Okn5W8TOM=.a81e018d-5f6a-4175-a918-0247c7c6d12f@github.com>

On Fri, 30 Oct 2020 10:41:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Deproblemlisted test
>
> any comment on this review?

ping?

-------------

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

From prr at openjdk.java.net  Mon Nov  2 15:35:54 2020
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 2 Nov 2020 15:35:54 GMT
Subject: <Swing Dev> RFR: 7190978:
 javax/swing/JComponent/7154030/bug7154030.java fails on mac
In-Reply-To: <qe8GqluK5h14KUPp6RaWhWh8BXL3TKSiZCxDI1vdZR0=.789f7596-af95-4fcc-9e91-38c0740210ff@github.com>
References: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
 <Az8BCBq_BJ6vjRTrOjtIPh2znxedQvxbasMvtZ79j8g=.c48c1c99-316a-400e-a05b-f8310e180b3d@github.com>
 <PnFXqzw83ENyBPH6nu57W5SPP0XPrXRsmJQhX4ovIeU=.1f13e52b-9cc6-4ff7-bb55-9898b1292190@github.com>
 <Wf3yUJ0_l4myQu6LZ5gaI8O0KPMu8D57iu1Z3kS1JCM=.e18d8d73-35ce-43cb-b87b-9ac62c5fd9d8@github.com>
 <qe8GqluK5h14KUPp6RaWhWh8BXL3TKSiZCxDI1vdZR0=.789f7596-af95-4fcc-9e91-38c0740210ff@github.com>
Message-ID: <TTZXZ83WrsMsTZbRGYysU_FYMtSuAc3C8pDknvj8-oQ=.6ab9ae7e-55a4-42ab-a665-6521d6d7f4e2@github.com>

On Mon, 2 Nov 2020 12:50:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Then please double-check that the test will pass after the fix on HiDPI screen. Not sure that -Dsun.java2d.uiScale=1 affects such usecase.
>
> Since mach5 systems are mostly macmini, where it initially failed, and the resultant test is passing on them, I would hope they will pass on hidpi screen they are connected to.

The mach5 macOS test systems currently have ZERO hidpi monitors. I think they are all 1920x1080 non-retina.
They only ever had at most one and that was because it was accidentally connected that way after a lab move.

-------------

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

From jdv at openjdk.java.net  Tue Nov  3 03:12:55 2020
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 3 Nov 2020 03:12:55 GMT
Subject: <Swing Dev> RFR: 8196089:
 javax/swing/Action/8133039/bug8133039.java fails
In-Reply-To: <EXtKsy-yNPIs_nPQoYpWTiDI9isXuyJWwdDUETAZqjE=.c189fcc6-8ece-4f47-8901-53f93370fad7@github.com>
References: <EXtKsy-yNPIs_nPQoYpWTiDI9isXuyJWwdDUETAZqjE=.c189fcc6-8ece-4f47-8901-53f93370fad7@github.com>
Message-ID: <lp1NwrCTtJM1RlPqdnBIQo1Nt8kxvY3MnWVvdBORev8=.50c82e62-7183-4bc9-8118-dd6ddad4118f@github.com>

On Thu, 29 Oct 2020 12:11:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Please review a test fix for an issue seen to be failing on mach5 systems due to timing issue.
> Adjusted the autoDelay time and moved the frame to center of screen.
> Mach5 job has been run for several iterations in all platforms. Link in JBS.

Marked as reviewed by jdv (Reviewer).

-------------

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

From jdv at openjdk.java.net  Tue Nov  3 03:12:56 2020
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 3 Nov 2020 03:12:56 GMT
Subject: <Swing Dev> RFR: 8196089:
 javax/swing/Action/8133039/bug8133039.java fails
In-Reply-To: <iflzMj42oipWbyFeHcQOw43kz23KXSXRb5Okn5W8TOM=.a81e018d-5f6a-4175-a918-0247c7c6d12f@github.com>
References: <EXtKsy-yNPIs_nPQoYpWTiDI9isXuyJWwdDUETAZqjE=.c189fcc6-8ece-4f47-8901-53f93370fad7@github.com>
 <mq8EsRQavNbVPXSJq4RjgSKt5TaeCJ816N7wl8sm9FY=.56202a81-efe7-48e6-a4d1-205c23f60cae@github.com>
 <J1-C1TQD5l8FDz_bDmmwslLz5Tkni6Fxi25y3yoBY8Q=.0f8c722f-51bb-43fe-8283-42513a07d54c@github.com>
 <iflzMj42oipWbyFeHcQOw43kz23KXSXRb5Okn5W8TOM=.a81e018d-5f6a-4175-a918-0247c7c6d12f@github.com>
Message-ID: <J6XJHHoTnhjvykssjyJ0zOlRnOOKU4ymf1TPL_9bu04=.4f6c1af9-b24e-4993-bb59-f4b8df49f574@github.com>

On Mon, 2 Nov 2020 12:50:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> any comment on this review?
>
> ping?

Looks like this is also related to giving permission to terminal in System Preferences -> Security & Privacy -> Privacy -> Accessibility. If we dont give permission the test fails.

-------------

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

From psadhukhan at openjdk.java.net  Tue Nov  3 03:20:55 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 3 Nov 2020 03:20:55 GMT
Subject: <Swing Dev> Integrated: 8196089:
 javax/swing/Action/8133039/bug8133039.java fails
In-Reply-To: <EXtKsy-yNPIs_nPQoYpWTiDI9isXuyJWwdDUETAZqjE=.c189fcc6-8ece-4f47-8901-53f93370fad7@github.com>
References: <EXtKsy-yNPIs_nPQoYpWTiDI9isXuyJWwdDUETAZqjE=.c189fcc6-8ece-4f47-8901-53f93370fad7@github.com>
Message-ID: <177vZA71kfX6F4HYBciANONnC7DV0wLrWwmM_w2wUuQ=.dcdb84c5-3dcd-44fb-a750-b58191769c09@github.com>

On Thu, 29 Oct 2020 12:11:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Please review a test fix for an issue seen to be failing on mach5 systems due to timing issue.
> Adjusted the autoDelay time and moved the frame to center of screen.
> Mach5 job has been run for several iterations in all platforms. Link in JBS.

This pull request has now been integrated.

Changeset: fe4e6b3e
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fe4e6b3e
Stats:     3 lines in 2 files changed: 1 ins; 1 del; 1 mod

8196089: javax/swing/Action/8133039/bug8133039.java fails

Reviewed-by: jdv

-------------

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

From jdv at openjdk.java.net  Tue Nov  3 05:57:04 2020
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 3 Nov 2020 05:57:04 GMT
Subject: <Swing Dev> RFR: 8233561: [TESTBUG] Swing text test bug8014863.java
 fails on macos
Message-ID: <VAVVKNWPHpg6wUhZI50Uq4T192G2tSUCtenwBQMd8hE=.bb5165a3-6ca7-4473-bc53-35c2ffc12b8c@github.com>

This issue is related to not giving permission for terminal to control things in System Preferences -> Security & privacy -> Privacy -> Accessibility.

I have verified the test in our CI and removed it from problemlist. There are small tweaks in test also.

-------------

Commit messages:
 - 8233561: [TESTBUG] Swing text test bug8014863.java fails on macos

Changes: https://git.openjdk.java.net/jdk/pull/1027/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1027&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8233561
  Stats: 4 lines in 2 files changed: 1 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1027.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1027/head:pull/1027

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

From jdv at openjdk.java.net  Tue Nov  3 06:19:00 2020
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 3 Nov 2020 06:19:00 GMT
Subject: <Swing Dev> RFR: 8233562: [TESTBUG] Swing StyledEditorKit test
 bug4506788.java fails on MacOS
Message-ID: <Meu4ZoX45FfXli-3NKEfbiSypv0m2MeLXFLRs6KEiUE=.3c114d97-e41d-46e5-9237-a3ec5b852e2c@github.com>

This issue is related to not giving permission for terminal to control things in System Preferences -> Security & privacy -> Privacy -> Accessibility.

I have verified the test in our CI and removed it from problemlist. There are small tweaks in test also.

-------------

Commit messages:
 - 8233562: [TESTBUG] Swing StyledEditorKit test bug4506788.java fails on MacOS

Changes: https://git.openjdk.java.net/jdk/pull/1028/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1028&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8233562
  Stats: 4 lines in 2 files changed: 1 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1028.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1028/head:pull/1028

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

From psadhukhan at openjdk.java.net  Tue Nov  3 06:37:59 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 3 Nov 2020 06:37:59 GMT
Subject: <Swing Dev> RFR: 8233561: [TESTBUG] Swing text test
 bug8014863.java fails on macos
In-Reply-To: <VAVVKNWPHpg6wUhZI50Uq4T192G2tSUCtenwBQMd8hE=.bb5165a3-6ca7-4473-bc53-35c2ffc12b8c@github.com>
References: <VAVVKNWPHpg6wUhZI50Uq4T192G2tSUCtenwBQMd8hE=.bb5165a3-6ca7-4473-bc53-35c2ffc12b8c@github.com>
Message-ID: <Ah-owvIYbiLrdbx5NcI4zDZ4Xpj60TEZZY69WIdBrSQ=.1922c5df-bde1-4725-a3f5-782df89627dc@github.com>

On Tue, 3 Nov 2020 05:48:13 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This issue is related to not giving permission for terminal to control things in System Preferences -> Security & privacy -> Privacy -> Accessibility.
> 
> I have verified the test in our CI and removed it from problemlist. There are small tweaks in test also.

Marked as reviewed by psadhukhan (Reviewer).

-------------

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

From psadhukhan at openjdk.java.net  Tue Nov  3 06:40:55 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 3 Nov 2020 06:40:55 GMT
Subject: <Swing Dev> RFR: 8233562: [TESTBUG] Swing StyledEditorKit test
 bug4506788.java fails on MacOS
In-Reply-To: <Meu4ZoX45FfXli-3NKEfbiSypv0m2MeLXFLRs6KEiUE=.3c114d97-e41d-46e5-9237-a3ec5b852e2c@github.com>
References: <Meu4ZoX45FfXli-3NKEfbiSypv0m2MeLXFLRs6KEiUE=.3c114d97-e41d-46e5-9237-a3ec5b852e2c@github.com>
Message-ID: <ODI_Md_O8Q6pdKw8hiPrPmQJ1gDp-t86RLf--VTDpsI=.abe63af3-6c0b-44ec-894f-3493c00da956@github.com>

On Tue, 3 Nov 2020 06:09:51 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This issue is related to not giving permission for terminal to control things in System Preferences -> Security & privacy -> Privacy -> Accessibility.
> 
> I have verified the test in our CI and removed it from problemlist. There are small tweaks in test also.

Marked as reviewed by psadhukhan (Reviewer).

-------------

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

From jdv at openjdk.java.net  Tue Nov  3 06:42:58 2020
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 3 Nov 2020 06:42:58 GMT
Subject: <Swing Dev> Integrated: 8233561: [TESTBUG] Swing text test
 bug8014863.java fails on macos
In-Reply-To: <VAVVKNWPHpg6wUhZI50Uq4T192G2tSUCtenwBQMd8hE=.bb5165a3-6ca7-4473-bc53-35c2ffc12b8c@github.com>
References: <VAVVKNWPHpg6wUhZI50Uq4T192G2tSUCtenwBQMd8hE=.bb5165a3-6ca7-4473-bc53-35c2ffc12b8c@github.com>
Message-ID: <FTnW1GkYO4MLeP4N_v4LGB5a7OLa5w42efvlXSrWx9o=.6a34b995-dc90-4362-90a2-7e15c1325240@github.com>

On Tue, 3 Nov 2020 05:48:13 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This issue is related to not giving permission for terminal to control things in System Preferences -> Security & privacy -> Privacy -> Accessibility.
> 
> I have verified the test in our CI and removed it from problemlist. There are small tweaks in test also.

This pull request has now been integrated.

Changeset: 9beb866b
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9beb866b
Stats:     4 lines in 2 files changed: 1 ins; 1 del; 2 mod

8233561: [TESTBUG] Swing text test bug8014863.java fails on macos

Reviewed-by: psadhukhan

-------------

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

From jdv at openjdk.java.net  Tue Nov  3 07:23:07 2020
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 3 Nov 2020 07:23:07 GMT
Subject: <Swing Dev> RFR: 8233562: [TESTBUG] Swing StyledEditorKit test
 bug4506788.java fails on MacOS [v2]
In-Reply-To: <Meu4ZoX45FfXli-3NKEfbiSypv0m2MeLXFLRs6KEiUE=.3c114d97-e41d-46e5-9237-a3ec5b852e2c@github.com>
References: <Meu4ZoX45FfXli-3NKEfbiSypv0m2MeLXFLRs6KEiUE=.3c114d97-e41d-46e5-9237-a3ec5b852e2c@github.com>
Message-ID: <w6QsFznEd4Urq3gdE4TvM-LI4JELhzD5gtDso7S7OEA=.c7e4f3ed-4a5c-43ed-bdf5-8db850cf80e4@github.com>

> This issue is related to not giving permission for terminal to control things in System Preferences -> Security & privacy -> Privacy -> Accessibility.
> 
> I have verified the test in our CI and removed it from problemlist. There are small tweaks in test also.

Jayathirth D V has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge master
 - 8233562: [TESTBUG] Swing StyledEditorKit test bug4506788.java fails on MacOS

-------------

Changes: https://git.openjdk.java.net/jdk/pull/1028/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1028&range=01
  Stats: 4 lines in 2 files changed: 1 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1028.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1028/head:pull/1028

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

From jdv at openjdk.java.net  Tue Nov  3 07:56:58 2020
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 3 Nov 2020 07:56:58 GMT
Subject: <Swing Dev> Integrated: 8233562: [TESTBUG] Swing StyledEditorKit
 test bug4506788.java fails on MacOS
In-Reply-To: <Meu4ZoX45FfXli-3NKEfbiSypv0m2MeLXFLRs6KEiUE=.3c114d97-e41d-46e5-9237-a3ec5b852e2c@github.com>
References: <Meu4ZoX45FfXli-3NKEfbiSypv0m2MeLXFLRs6KEiUE=.3c114d97-e41d-46e5-9237-a3ec5b852e2c@github.com>
Message-ID: <TRZtBKr1P77d_ImWUKygneeG_s7FzHIUh01-EOSQglI=.76604642-0453-4f0b-8454-a55d1795f914@github.com>

On Tue, 3 Nov 2020 06:09:51 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This issue is related to not giving permission for terminal to control things in System Preferences -> Security & privacy -> Privacy -> Accessibility.
> 
> I have verified the test in our CI and removed it from problemlist. There are small tweaks in test also.

This pull request has now been integrated.

Changeset: 4107670d
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4107670d
Stats:     4 lines in 2 files changed: 1 ins; 2 del; 1 mod

8233562: [TESTBUG] Swing StyledEditorKit test bug4506788.java fails on MacOS

Reviewed-by: psadhukhan

-------------

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

From kizune at openjdk.java.net  Tue Nov  3 10:43:11 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 3 Nov 2020 10:43:11 GMT
Subject: <Swing Dev> RFR: 4907798: MEMORY LEAK:
 javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper
Message-ID: <_EqDyPXhK4t_zt1Gcdx4dSGj0sKB7AdLC3T7F-Elhvg=.5470e2d2-dc1d-438d-8e0b-72f92ba0440d@github.com>

4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper

-------------

Commit messages:
 - 4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper
 - Merge pull request #1 from openjdk/master

Changes: https://git.openjdk.java.net/jdk/pull/1035/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1035&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-4907798
  Stats: 183 lines in 3 files changed: 181 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1035.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1035/head:pull/1035

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

From psadhukhan at openjdk.java.net  Tue Nov  3 16:32:07 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 3 Nov 2020 16:32:07 GMT
Subject: <Swing Dev> RFR: 7190978:
 javax/swing/JComponent/7154030/bug7154030.java fails on mac [v2]
In-Reply-To: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
References: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
Message-ID: <b2OxDrNcVjF_-tg7PDl7qbcJ6V-6F07TIk9qHxxRFac=.4c7f161c-b59a-440d-9f84-24ef5bac62ce@github.com>

> Please review a test fix for an issue seen where robot image capture is wrong if screen scale factor is more, which could result in button or frame to move out of captured dimension of 300,300.
> Fixed by setting uiScale=1 in the test which can still reproduce JDK-7154030.
> Mach5 job has been run for several iterations in all platforms. Link in JBS.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Remove uiScale

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/955/files
  - new: https://git.openjdk.java.net/jdk/pull/955/files/f3f9f9ff..b6a90f1d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=955&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=955&range=00-01

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

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

From psadhukhan at openjdk.java.net  Tue Nov  3 16:34:55 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 3 Nov 2020 16:34:55 GMT
Subject: <Swing Dev> RFR: 7190978:
 javax/swing/JComponent/7154030/bug7154030.java fails on mac
In-Reply-To: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
References: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
Message-ID: <85lu6YRxFTjWtBtqc4EFEhs9GkGkon24PhDv82n3uhQ=.f428e5e9-7568-4b07-b592-7ab9a6d7a49e@github.com>

On Fri, 30 Oct 2020 11:42:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Please review a test fix for an issue seen where robot image capture is wrong if screen scale factor is more, which could result in button or frame to move out of captured dimension of 300,300.
> Fixed by setting uiScale=1 in the test which can still reproduce JDK-7154030.
> Mach5 job has been run for several iterations in all platforms. Link in JBS.

Removed uiScale and move frame from (0,0) location to about mid-screen and made sure robot screenCapture also captures the frame from that location. mach5 iterations is green.

-------------

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

From psadhukhan at openjdk.java.net  Tue Nov  3 16:46:55 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 3 Nov 2020 16:46:55 GMT
Subject: <Swing Dev> RFR: 4907798: MEMORY LEAK:
 javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper
In-Reply-To: <_EqDyPXhK4t_zt1Gcdx4dSGj0sKB7AdLC3T7F-Elhvg=.5470e2d2-dc1d-438d-8e0b-72f92ba0440d@github.com>
References: <_EqDyPXhK4t_zt1Gcdx4dSGj0sKB7AdLC3T7F-Elhvg=.5470e2d2-dc1d-438d-8e0b-72f92ba0440d@github.com>
Message-ID: <UnpWHuKSD_uKz0K9SJoHgyr3fSN3IMC4EP7PejM8d2s=.8770179d-3edb-4178-9582-df7675e4a2d3@github.com>

On Tue, 3 Nov 2020 10:32:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper

I think even if the fix is in windows, there's no harm in making the test platform agnostic and let it run for all platforms.

-------------

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

From serb at openjdk.java.net  Tue Nov  3 17:44:59 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 3 Nov 2020 17:44:59 GMT
Subject: <Swing Dev> RFR: 8233562: [TESTBUG] Swing StyledEditorKit test
 bug4506788.java fails on MacOS [v2]
In-Reply-To: <ODI_Md_O8Q6pdKw8hiPrPmQJ1gDp-t86RLf--VTDpsI=.abe63af3-6c0b-44ec-894f-3493c00da956@github.com>
References: <Meu4ZoX45FfXli-3NKEfbiSypv0m2MeLXFLRs6KEiUE=.3c114d97-e41d-46e5-9237-a3ec5b852e2c@github.com>
 <ODI_Md_O8Q6pdKw8hiPrPmQJ1gDp-t86RLf--VTDpsI=.abe63af3-6c0b-44ec-894f-3493c00da956@github.com>
Message-ID: <1_Du3nFctK5JfOYRLF5YUPIT6fdL0BuqvPBw0zXbyHA=.25590e93-2430-4c30-9f29-19e3e3523f32@github.com>

On Tue, 3 Nov 2020 06:38:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge master
>>  - 8233562: [TESTBUG] Swing StyledEditorKit test bug4506788.java fails on MacOS
>
> Marked as reviewed by psadhukhan (Reviewer).

I suggest to check all bugs filed at the previouse sprint, caused by the system config and fix them at onece, like
https://github.com/openjdk/jdk/pull/895
https://github.com/openjdk/jdk/pull/733

-------------

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

From serb at openjdk.java.net  Tue Nov  3 18:41:06 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 3 Nov 2020 18:41:06 GMT
Subject: <Swing Dev> RFR: 7190978:
 javax/swing/JComponent/7154030/bug7154030.java fails on mac [v2]
In-Reply-To: <b2OxDrNcVjF_-tg7PDl7qbcJ6V-6F07TIk9qHxxRFac=.4c7f161c-b59a-440d-9f84-24ef5bac62ce@github.com>
References: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
 <b2OxDrNcVjF_-tg7PDl7qbcJ6V-6F07TIk9qHxxRFac=.4c7f161c-b59a-440d-9f84-24ef5bac62ce@github.com>
Message-ID: <aIDEYwLHUlh-7xomoaRPtvkSfWS5qfj7YI2xQ1g70Go=.f8bd0259-666b-47a2-94a7-f964596171cb@github.com>

On Tue, 3 Nov 2020 16:32:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Please review a test fix for an issue seen where robot image capture is wrong if screen scale factor is more, which could result in button or frame to move out of captured dimension of 300,300.
>> Fixed by setting uiScale=1 in the test which can still reproduce JDK-7154030.
>> Mach5 job has been run for several iterations in all platforms. Link in JBS.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove uiScale

test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 96:

> 94:                     locx = screenSize.width/2;
> 95:                     locy = screenSize.height/2;
> 96:                     frame.setLocation(locx, locy);

To move it to the center you can use, setLocationRelativeTo(null) and you will need to get the actual bounds of the window(locx and locy might be ignored/tweaked by the OS)

-------------

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

From serb at openjdk.java.net  Tue Nov  3 18:49:02 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 3 Nov 2020 18:49:02 GMT
Subject: <Swing Dev> RFR: 4907798: MEMORY LEAK:
 javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper
In-Reply-To: <_EqDyPXhK4t_zt1Gcdx4dSGj0sKB7AdLC3T7F-Elhvg=.5470e2d2-dc1d-438d-8e0b-72f92ba0440d@github.com>
References: <_EqDyPXhK4t_zt1Gcdx4dSGj0sKB7AdLC3T7F-Elhvg=.5470e2d2-dc1d-438d-8e0b-72f92ba0440d@github.com>
Message-ID: <vuzUv2nWtu_rhjnC4DMszCcaqYgg-CdzlG0jXdW4UsM=.c8f1d94e-76e2-493a-bed8-1f50fbd0cb57@github.com>

On Tue, 3 Nov 2020 10:32:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper

Changes requested by serb (Reviewer).

test/jdk/javax/swing/JMenu/PopupReferenceMemoryLeak.java line 100:

> 98:             }
> 99:             robot.waitForIdle();
> 100:             robot.keyPress(KeyEvent.VK_ALT);

Can we skip the robot interaction and instead show the popup menu ourselves? (not via menu items)

test/jdk/javax/swing/JMenu/PopupReferenceMemoryLeak.java line 57:

> 55:         try {
> 56:             // Set system look and feel
> 57:             UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

I suggest checking all installed L&Fs for example https://github.com/openjdk/jdk/pull/989/files

test/jdk/javax/swing/JMenu/PopupReferenceMemoryLeak.java line 89:

> 87:             for(int i=0; i<3; i++) {
> 88:                 try {
> 89:                     ArrayList gc = new ArrayList();

It will be useful to call System.gc() and limit the size of the heap via -mx

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java line 1229:

> 1227:                 // and uninstall menu keybindings
> 1228:                    removeItems();
> 1229:                    menuInputMap = null;

Just curious, will the uninstall(); at the start of the method will clear this flag as well?

-------------

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

From psadhukhan at openjdk.java.net  Wed Nov  4 02:44:58 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 4 Nov 2020 02:44:58 GMT
Subject: <Swing Dev> RFR: 7190978:
 javax/swing/JComponent/7154030/bug7154030.java fails on mac [v2]
In-Reply-To: <aIDEYwLHUlh-7xomoaRPtvkSfWS5qfj7YI2xQ1g70Go=.f8bd0259-666b-47a2-94a7-f964596171cb@github.com>
References: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
 <b2OxDrNcVjF_-tg7PDl7qbcJ6V-6F07TIk9qHxxRFac=.4c7f161c-b59a-440d-9f84-24ef5bac62ce@github.com>
 <aIDEYwLHUlh-7xomoaRPtvkSfWS5qfj7YI2xQ1g70Go=.f8bd0259-666b-47a2-94a7-f964596171cb@github.com>
Message-ID: <BAoIMC9xd8oYAUicjlm3TuXTogXiSxhTNRpMVAX2r7s=.0c1a24ac-bd1e-403c-9f84-c3cf3f79e171@github.com>

On Tue, 3 Nov 2020 18:38:15 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove uiScale
>
> test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 96:
> 
>> 94:                     locx = screenSize.width/2;
>> 95:                     locy = screenSize.height/2;
>> 96:                     frame.setLocation(locx, locy);
> 
> To move it to the center you can use, setLocationRelativeTo(null) and you will need to get the actual bounds of the window(locx and locy might be ignored/tweaked by the OS)

I know setLocationRelativeTo(null) will move to center of screen but I needed the coordinate for robot interaction.
The locx,locy calculation to move to center of screen is done intentionally as we need to use the same coordinate in robot to capture the screen

-------------

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

From serb at openjdk.java.net  Wed Nov  4 06:23:54 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 4 Nov 2020 06:23:54 GMT
Subject: <Swing Dev> RFR: 7190978:
 javax/swing/JComponent/7154030/bug7154030.java fails on mac [v2]
In-Reply-To: <BAoIMC9xd8oYAUicjlm3TuXTogXiSxhTNRpMVAX2r7s=.0c1a24ac-bd1e-403c-9f84-c3cf3f79e171@github.com>
References: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
 <b2OxDrNcVjF_-tg7PDl7qbcJ6V-6F07TIk9qHxxRFac=.4c7f161c-b59a-440d-9f84-24ef5bac62ce@github.com>
 <aIDEYwLHUlh-7xomoaRPtvkSfWS5qfj7YI2xQ1g70Go=.f8bd0259-666b-47a2-94a7-f964596171cb@github.com>
 <BAoIMC9xd8oYAUicjlm3TuXTogXiSxhTNRpMVAX2r7s=.0c1a24ac-bd1e-403c-9f84-c3cf3f79e171@github.com>
Message-ID: <MZuAHD9K7elHf-c0ejJnyVloMSaq44I8S9AFMkK7u6Q=.a7e503ac-3624-4723-8e4c-2f46483f68f3@github.com>

On Wed, 4 Nov 2020 02:42:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The locx,locy calculation to move to center of screen is done intentionally as we need to use the same coordinate in robot to capture the screen

You can use locx/loxy intentionally to move the window, but you can't use it in a robot because of:
> you will need to get the actual bounds of the window(locx and locy might be ignored/tweaked by the OS)

-------------

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

From psadhukhan at openjdk.java.net  Wed Nov  4 13:14:03 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 4 Nov 2020 13:14:03 GMT
Subject: <Swing Dev> Integrated: 8255215: Unsupported 'valign' attribute for
 'tr' tag used in j.s.t.h.HTMLDocument
In-Reply-To: <0z1N6lTLhz_Jdd5tjzzGbnwSaTz2__iNF9_-G1bT2Rw=.90867000-46cb-44d9-a291-9d614f0e3e9b@github.com>
References: <0z1N6lTLhz_Jdd5tjzzGbnwSaTz2__iNF9_-G1bT2Rw=.90867000-46cb-44d9-a291-9d614f0e3e9b@github.com>
Message-ID: <c_4p_3ApRIVmNcPWo3B2wzhs6c6zMqaHo8p3DQ0ldy0=.3006b660-f4c8-42f6-ab54-0e99309a888e@github.com>

On Mon, 2 Nov 2020 08:18:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Since HTML4 support has been dropped from javadoc by JDK-8187793.
> HTMLDocument.java containing the valign attribute in the table element, `valign="top"` 
> needs to be replaced with `style="vertical-align:top"

This pull request has now been integrated.

Changeset: 7f4d873d
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7f4d873d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8255215: Unsupported 'valign' attribute for 'tr' tag used in j.s.t.h.HTMLDocument

Reviewed-by: serb

-------------

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

From psadhukhan at openjdk.java.net  Wed Nov  4 14:38:06 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 4 Nov 2020 14:38:06 GMT
Subject: <Swing Dev> RFR: 7190978:
 javax/swing/JComponent/7154030/bug7154030.java fails on mac [v3]
In-Reply-To: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
References: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
Message-ID: <uW7MA4awjAXfpW6OdLXNksZoZdybc-rkeYFtm2baLIc=.abd919a4-e5f4-4eda-900b-ee29caf4e6da@github.com>

> Please review a test fix for an issue seen where robot image capture is wrong if screen scale factor is more, which could result in button or frame to move out of captured dimension of 300,300.
> Fixed by setting uiScale=1 in the test which can still reproduce JDK-7154030.
> Mach5 job has been run for several iterations in all platforms. Link in JBS.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  use getBounds()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/955/files
  - new: https://git.openjdk.java.net/jdk/pull/955/files/b6a90f1d..cf936ae0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=955&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=955&range=01-02

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

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

From psadhukhan at openjdk.java.net  Wed Nov  4 14:38:07 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 4 Nov 2020 14:38:07 GMT
Subject: <Swing Dev> RFR: 7190978:
 javax/swing/JComponent/7154030/bug7154030.java fails on mac [v2]
In-Reply-To: <MZuAHD9K7elHf-c0ejJnyVloMSaq44I8S9AFMkK7u6Q=.a7e503ac-3624-4723-8e4c-2f46483f68f3@github.com>
References: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
 <b2OxDrNcVjF_-tg7PDl7qbcJ6V-6F07TIk9qHxxRFac=.4c7f161c-b59a-440d-9f84-24ef5bac62ce@github.com>
 <aIDEYwLHUlh-7xomoaRPtvkSfWS5qfj7YI2xQ1g70Go=.f8bd0259-666b-47a2-94a7-f964596171cb@github.com>
 <BAoIMC9xd8oYAUicjlm3TuXTogXiSxhTNRpMVAX2r7s=.0c1a24ac-bd1e-403c-9f84-c3cf3f79e171@github.com>
 <MZuAHD9K7elHf-c0ejJnyVloMSaq44I8S9AFMkK7u6Q=.a7e503ac-3624-4723-8e4c-2f46483f68f3@github.com>
Message-ID: <6aMgUbkf3sKP69rM4mbfJBuMe845Et7jc_8pmRr-7gE=.88219b1a-ece0-4e04-886b-bacfdd4b119a@github.com>

On Wed, 4 Nov 2020 06:21:26 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I know setLocationRelativeTo(null) will move to center of screen but I needed the coordinate for robot interaction.
>> The locx,locy calculation to move to center of screen is done intentionally as we need to use the same coordinate in robot to capture the screen
>
>> The locx,locy calculation to move to center of screen is done intentionally as we need to use the same coordinate in robot to capture the screen
> 
> You can use locx/loxy intentionally to move the window, but you can't use it in a robot because of:
>> you will need to get the actual bounds of the window(locx and locy might be ignored/tweaked by the OS)

Modified to use bounds.

-------------

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

From psadhukhan at openjdk.java.net  Thu Nov  5 03:58:55 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 5 Nov 2020 03:58:55 GMT
Subject: <Swing Dev> RFR: 4916923: In MetalRootPaneUI,
 MetalRootLayout does not correctly calculate minimumsize
In-Reply-To: <wkpGK1yQmGzoYmfrD_bvTQvC7M1d_zUsDE7vbVs5USs=.86a6144e-5c76-4bcf-9831-a566b8b2f84b@github.com>
References: <x12pgHHvm8vRqf5U4RMWGVX7kO1pimiJmRHv2-XdEIg=.43e13b99-57f6-4125-9013-ec67456fce1e@github.com>
 <_nj2FwAXWLqsE2I79uXTwcrlGQ58fiVDRoieoLUmwEo=.6f136cb8-3059-4186-9494-3c0f1c4e8c45@github.com>
 <SEiU9GEFe4TzyGfMREWFG2k5lp5tvoRSdt2r7WM3LxE=.136d785e-b8cb-43d3-846c-b6d721587c81@github.com>
 <K9Ij6aBcHdtfQF4_mDkRAVSkxeqwDdn1pgSbCupFLQs=.89e39950-23e4-40c0-93b7-58164cfc86c5@github.com>
 <Xskfjlx6A7Js-xMLVQbA9We2bcDNvsHwhw0csE-SL_Y=.d1efd204-2e0f-4344-9890-b98e29c6e3c5@github.com>
 <hhJ2IEHtNE2hNT45_aARX5jn7-GRchRgUZZmsa7ph_w=.bb19d73f-a728-4134-8a77-92f278c9a15c@github.com>
 <TKWgfnQsQut_j9QFpwQq1-I5ShNh2TLA1m7BgBldsBg=.ae6c49f4-b370-41f3-b412-b56d711d6af7@github.com>
 <wkpGK1yQmGzoYmfrD_bvTQvC7M1d_zUsDE7vbVs5USs=.86a6144e-5c76-4bcf-9831-a566b8b2f84b@github.com>
Message-ID: <y7xcxjcS7FNUw-xCDVxaS-z3FmhD1FDueIHe1iZLE4w=.8b755358-0b67-4088-b844-20a6552c2e8f@github.com>

On Sat, 10 Oct 2020 11:33:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I tried following testcase snippet
>>                ```
>>  JRootPane r = new JRootPane();
>>                 JFrame f = new JFrame();
>>                 f.getRootPane().setUI(new MetalRootPaneUI());
>>                 f.getRootPane().setWindowDecorationStyle(JRootPane.FRAME);
>>                 f.getRootPane().getUI().installUI(r);
>>                 r.getContentPane().add(new JLabel("foo"));
>>                 System.out.println("Preferred Size: " + r.getPreferredSize());
>> but it uses JRootPane.RootLayout layout manager and not MetalRootLayout so it calls Rootlayout.preferredLayoutSize and not MetalRootLayout.preferredlayoutSize
>
> You need to set decorations for the root pane:
>         UIManager.setLookAndFeel(new MetalLookAndFeel());
>         JFrame frame = new JFrame();
>         frame.getRootPane().setWindowDecorationStyle(JRootPane.FRAME);
>         frame.pack();
>         System.out.println("Layout: " + frame.getRootPane().getLayout());
> ========
> Layout: javax.swing.plaf.metal.MetalRootPaneUI$MetalRootLayout at 69d9c55

I tried with 
 UIManager.setLookAndFeel(new MetalLookAndFeel());
JFrame frame = new JFrame();
                frame.setSize(new Dimension(500, 800));
                frame.getRootPane().setWindowDecorationStyle(JRootPane.FRAME);
                //frame.pack();
                frame.setVisible(true);
                System.out.println("Layout: " + frame.getRootPane().getLayout());
                System.out.println("PreferredSize " + frame.getRootPane().getPreferredSize());
but it seems tpWidth and tpHeight what is being changed is the width and height of MetalTitlePane which seems always comes as 23 for both no matter what frame size is set, so I guess using any variable will do but logically, it will be good to use "tpHeight" for height calculation.
If it is believed to continue with same logical but not technical error, I will close this PR without integrating.

-------------

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

From serb at openjdk.java.net  Thu Nov  5 04:09:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 5 Nov 2020 04:09:57 GMT
Subject: <Swing Dev> RFR: 4916923: In MetalRootPaneUI,
 MetalRootLayout does not correctly calculate minimumsize
In-Reply-To: <y7xcxjcS7FNUw-xCDVxaS-z3FmhD1FDueIHe1iZLE4w=.8b755358-0b67-4088-b844-20a6552c2e8f@github.com>
References: <x12pgHHvm8vRqf5U4RMWGVX7kO1pimiJmRHv2-XdEIg=.43e13b99-57f6-4125-9013-ec67456fce1e@github.com>
 <_nj2FwAXWLqsE2I79uXTwcrlGQ58fiVDRoieoLUmwEo=.6f136cb8-3059-4186-9494-3c0f1c4e8c45@github.com>
 <SEiU9GEFe4TzyGfMREWFG2k5lp5tvoRSdt2r7WM3LxE=.136d785e-b8cb-43d3-846c-b6d721587c81@github.com>
 <K9Ij6aBcHdtfQF4_mDkRAVSkxeqwDdn1pgSbCupFLQs=.89e39950-23e4-40c0-93b7-58164cfc86c5@github.com>
 <Xskfjlx6A7Js-xMLVQbA9We2bcDNvsHwhw0csE-SL_Y=.d1efd204-2e0f-4344-9890-b98e29c6e3c5@github.com>
 <hhJ2IEHtNE2hNT45_aARX5jn7-GRchRgUZZmsa7ph_w=.bb19d73f-a728-4134-8a77-92f278c9a15c@github.com>
 <TKWgfnQsQut_j9QFpwQq1-I5ShNh2TLA1m7BgBldsBg=.ae6c49f4-b370-41f3-b412-b56d711d6af7@github.com>
 <wkpGK1yQmGzoYmfrD_bvTQvC7M1d_zUsDE7vbVs5USs=.86a6144e-5c76-4bcf-9831-a566b8b2f84b@github.com>
 <y7xcxjcS7FNUw-xCDVxaS-z3FmhD1FDueIHe1iZLE4w=.8b755358-0b67-4088-b844-20a6552c2e8f@github.com>
Message-ID: <73XquI71hVHCLLk5yrgOwbkxCv6N-CUqSyDptAS8WVA=.6042f3b5-0a5a-44b3-b58b-33e8383654f6@github.com>

On Thu, 5 Nov 2020 03:55:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> You need to set decorations for the root pane:
>>         UIManager.setLookAndFeel(new MetalLookAndFeel());
>>         JFrame frame = new JFrame();
>>         frame.getRootPane().setWindowDecorationStyle(JRootPane.FRAME);
>>         frame.pack();
>>         System.out.println("Layout: " + frame.getRootPane().getLayout());
>> ========
>> Layout: javax.swing.plaf.metal.MetalRootPaneUI$MetalRootLayout at 69d9c55
>
> I tried with 
>  UIManager.setLookAndFeel(new MetalLookAndFeel());
> JFrame frame = new JFrame();
>                 frame.setSize(new Dimension(500, 800));
>                 frame.getRootPane().setWindowDecorationStyle(JRootPane.FRAME);
>                 //frame.pack();
>                 frame.setVisible(true);
>                 System.out.println("Layout: " + frame.getRootPane().getLayout());
>                 System.out.println("PreferredSize " + frame.getRootPane().getPreferredSize());
> but it seems tpWidth and tpHeight what is being changed is the width and height of MetalTitlePane which seems always comes as 23 for both no matter what frame size is set, so I guess using any variable will do but logically, it will be good to use "tpHeight" for height calculation.
> If it is believed to continue with same logical but not technical error, I will close this PR without integrating.

The bug submitter said that it is somehow affected his application. So I assume there is a way to trigger this bug in the MetalRootLayout.

-------------

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

From psadhukhan at openjdk.java.net  Thu Nov  5 04:09:57 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 5 Nov 2020 04:09:57 GMT
Subject: <Swing Dev> RFR: 4916923: In MetalRootPaneUI,
 MetalRootLayout does not correctly calculate minimumsize
In-Reply-To: <73XquI71hVHCLLk5yrgOwbkxCv6N-CUqSyDptAS8WVA=.6042f3b5-0a5a-44b3-b58b-33e8383654f6@github.com>
References: <x12pgHHvm8vRqf5U4RMWGVX7kO1pimiJmRHv2-XdEIg=.43e13b99-57f6-4125-9013-ec67456fce1e@github.com>
 <_nj2FwAXWLqsE2I79uXTwcrlGQ58fiVDRoieoLUmwEo=.6f136cb8-3059-4186-9494-3c0f1c4e8c45@github.com>
 <SEiU9GEFe4TzyGfMREWFG2k5lp5tvoRSdt2r7WM3LxE=.136d785e-b8cb-43d3-846c-b6d721587c81@github.com>
 <K9Ij6aBcHdtfQF4_mDkRAVSkxeqwDdn1pgSbCupFLQs=.89e39950-23e4-40c0-93b7-58164cfc86c5@github.com>
 <Xskfjlx6A7Js-xMLVQbA9We2bcDNvsHwhw0csE-SL_Y=.d1efd204-2e0f-4344-9890-b98e29c6e3c5@github.com>
 <hhJ2IEHtNE2hNT45_aARX5jn7-GRchRgUZZmsa7ph_w=.bb19d73f-a728-4134-8a77-92f278c9a15c@github.com>
 <TKWgfnQsQut_j9QFpwQq1-I5ShNh2TLA1m7BgBldsBg=.ae6c49f4-b370-41f3-b412-b56d711d6af7@github.com>
 <wkpGK1yQmGzoYmfrD_bvTQvC7M1d_zUsDE7vbVs5USs=.86a6144e-5c76-4bcf-9831-a566b8b2f84b@github.com>
 <y7xcxjcS7FNUw-xCDVxaS-z3FmhD1FDueIHe1iZLE4w=.8b755358-0b67-4088-b844-20a6552c2e8f@github.com>
 <73XquI71hVHCLLk5yrgOwbkxCv6N-CUqSyDptAS8WVA=.6042f3b5-0a5a-44b3-b58b-33e8383654f6@github.com>
Message-ID: <C7Wt4lOi9gTNObNGmnFW6vVIEfyGMC3UwyCZQ1J7ECg=.51a5f756-d2bb-4fd6-873d-1ce000550f65@github.com>

On Thu, 5 Nov 2020 04:04:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I tried with 
>>  UIManager.setLookAndFeel(new MetalLookAndFeel());
>> JFrame frame = new JFrame();
>>                 frame.setSize(new Dimension(500, 800));
>>                 frame.getRootPane().setWindowDecorationStyle(JRootPane.FRAME);
>>                 //frame.pack();
>>                 frame.setVisible(true);
>>                 System.out.println("Layout: " + frame.getRootPane().getLayout());
>>                 System.out.println("PreferredSize " + frame.getRootPane().getPreferredSize());
>> but it seems tpWidth and tpHeight what is being changed is the width and height of MetalTitlePane which seems always comes as 23 for both no matter what frame size is set, so I guess using any variable will do but logically, it will be good to use "tpHeight" for height calculation.
>> If it is believed to continue with same logical but not technical error, I will close this PR without integrating.
>
> The bug submitter said that it is somehow affected his application. So I assume there is a way to trigger this bug in the MetalRootLayout.

>From MetalTitlePane.java, the same "height" is being used for width and height so the value is same for both.
private class TitlePaneLayout implements LayoutManager {
        public void addLayoutComponent(String name, Component c) {}
        public void removeLayoutComponent(Component c) {}
        public Dimension preferredLayoutSize(Container c)  {
            int height = computeHeight();
            return new Dimension(height, height);
        }

-------------

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

From psadhukhan at openjdk.java.net  Thu Nov  5 04:12:55 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 5 Nov 2020 04:12:55 GMT
Subject: <Swing Dev> RFR: 4916923: In MetalRootPaneUI,
 MetalRootLayout does not correctly calculate minimumsize
In-Reply-To: <C7Wt4lOi9gTNObNGmnFW6vVIEfyGMC3UwyCZQ1J7ECg=.51a5f756-d2bb-4fd6-873d-1ce000550f65@github.com>
References: <x12pgHHvm8vRqf5U4RMWGVX7kO1pimiJmRHv2-XdEIg=.43e13b99-57f6-4125-9013-ec67456fce1e@github.com>
 <_nj2FwAXWLqsE2I79uXTwcrlGQ58fiVDRoieoLUmwEo=.6f136cb8-3059-4186-9494-3c0f1c4e8c45@github.com>
 <SEiU9GEFe4TzyGfMREWFG2k5lp5tvoRSdt2r7WM3LxE=.136d785e-b8cb-43d3-846c-b6d721587c81@github.com>
 <K9Ij6aBcHdtfQF4_mDkRAVSkxeqwDdn1pgSbCupFLQs=.89e39950-23e4-40c0-93b7-58164cfc86c5@github.com>
 <Xskfjlx6A7Js-xMLVQbA9We2bcDNvsHwhw0csE-SL_Y=.d1efd204-2e0f-4344-9890-b98e29c6e3c5@github.com>
 <hhJ2IEHtNE2hNT45_aARX5jn7-GRchRgUZZmsa7ph_w=.bb19d73f-a728-4134-8a77-92f278c9a15c@github.com>
 <TKWgfnQsQut_j9QFpwQq1-I5ShNh2TLA1m7BgBldsBg=.ae6c49f4-b370-41f3-b412-b56d711d6af7@github.com>
 <wkpGK1yQmGzoYmfrD_bvTQvC7M1d_zUsDE7vbVs5USs=.86a6144e-5c76-4bcf-9831-a566b8b2f84b@github.com>
 <y7xcxjcS7FNUw-xCDVxaS-z3FmhD1FDueIHe1iZLE4w=.8b755358-0b67-4088-b844-20a6552c2e8f@github.com>
 <73XquI71hVHCLLk5yrgOwbkxCv6N-CUqSyDptAS8WVA=.6042f3b5-0a5a-44b3-b58b-33e8383654f6@github.com>
 <C7Wt4lOi9gTNObNGmnFW6vVIEfyGMC3UwyC
 ZQ1J7ECg=.51a5f756-d2bb-4fd6-873d-1ce000550f65@github.com>
Message-ID: <jbpqFTbVLCBLGogcJp5S-TadqIDV5uzPJipiHm1Sd8g=.44beee76-67ee-423e-bb03-5b4661b9acd9@github.com>

On Thu, 5 Nov 2020 04:06:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The bug submitter said that it is somehow affected his application. So I assume there is a way to trigger this bug in the MetalRootLayout.
>
> From MetalTitlePane.java, the same "height" is being used for width and height so the value is same for both.
> private class TitlePaneLayout implements LayoutManager {
>         public void addLayoutComponent(String name, Component c) {}
>         public void removeLayoutComponent(Component c) {}
>         public Dimension preferredLayoutSize(Container c)  {
>             int height = computeHeight();
>             return new Dimension(height, height);
>         }

There is no reproducible testcase and the submitter id is not active anymore so cannot ask him and I am not sure of any other way, so if this is not accepted without a reproducing testcase, I will close this PR.

-------------

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

From serb at openjdk.java.net  Thu Nov  5 11:32:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 5 Nov 2020 11:32:57 GMT
Subject: <Swing Dev> RFR: 7190978:
 javax/swing/JComponent/7154030/bug7154030.java fails on mac [v2]
In-Reply-To: <6aMgUbkf3sKP69rM4mbfJBuMe845Et7jc_8pmRr-7gE=.88219b1a-ece0-4e04-886b-bacfdd4b119a@github.com>
References: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
 <b2OxDrNcVjF_-tg7PDl7qbcJ6V-6F07TIk9qHxxRFac=.4c7f161c-b59a-440d-9f84-24ef5bac62ce@github.com>
 <aIDEYwLHUlh-7xomoaRPtvkSfWS5qfj7YI2xQ1g70Go=.f8bd0259-666b-47a2-94a7-f964596171cb@github.com>
 <BAoIMC9xd8oYAUicjlm3TuXTogXiSxhTNRpMVAX2r7s=.0c1a24ac-bd1e-403c-9f84-c3cf3f79e171@github.com>
 <MZuAHD9K7elHf-c0ejJnyVloMSaq44I8S9AFMkK7u6Q=.a7e503ac-3624-4723-8e4c-2f46483f68f3@github.com>
 <6aMgUbkf3sKP69rM4mbfJBuMe845Et7jc_8pmRr-7gE=.88219b1a-ece0-4e04-886b-bacfdd4b119a@github.com>
Message-ID: <WxcqnFOMfiy-m1OgRCcyuMUAahoYC3ZMrZBbTr3NifE=.a026053b-f250-4346-8f2c-1b012a6876bc@github.com>

On Wed, 4 Nov 2020 14:35:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> The locx,locy calculation to move to center of screen is done intentionally as we need to use the same coordinate in robot to capture the screen
>> 
>> You can use locx/loxy intentionally to move the window, but you can't use it in a robot because of:
>>> you will need to get the actual bounds of the window(locx and locy might be ignored/tweaked by the OS)
>
> Modified to use bounds.

GC.getBounds() and Toolkit.getScreenSize() return the same bounds, but the bounds of the screen, not the window bounds.

-------------

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

From psadhukhan at openjdk.java.net  Thu Nov  5 11:37:56 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 5 Nov 2020 11:37:56 GMT
Subject: <Swing Dev> RFR: 7190978:
 javax/swing/JComponent/7154030/bug7154030.java fails on mac [v2]
In-Reply-To: <WxcqnFOMfiy-m1OgRCcyuMUAahoYC3ZMrZBbTr3NifE=.a026053b-f250-4346-8f2c-1b012a6876bc@github.com>
References: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
 <b2OxDrNcVjF_-tg7PDl7qbcJ6V-6F07TIk9qHxxRFac=.4c7f161c-b59a-440d-9f84-24ef5bac62ce@github.com>
 <aIDEYwLHUlh-7xomoaRPtvkSfWS5qfj7YI2xQ1g70Go=.f8bd0259-666b-47a2-94a7-f964596171cb@github.com>
 <BAoIMC9xd8oYAUicjlm3TuXTogXiSxhTNRpMVAX2r7s=.0c1a24ac-bd1e-403c-9f84-c3cf3f79e171@github.com>
 <MZuAHD9K7elHf-c0ejJnyVloMSaq44I8S9AFMkK7u6Q=.a7e503ac-3624-4723-8e4c-2f46483f68f3@github.com>
 <6aMgUbkf3sKP69rM4mbfJBuMe845Et7jc_8pmRr-7gE=.88219b1a-ece0-4e04-886b-bacfdd4b119a@github.com>
 <WxcqnFOMfiy-m1OgRCcyuMUAahoYC3ZMrZBbTr3NifE=.a026053b-f250-4346-8f2c-1b012a6876bc@github.com>
Message-ID: <vgTMOK9kVf5nP1F1S7Iu2_6Igq0F8Dt6ZUFUmg3rPOE=.f804df7f-e6be-460d-afa0-772fcfa446e3@github.com>

On Thu, 5 Nov 2020 11:30:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Modified to use bounds.
>
> GC.getBounds() and Toolkit.getScreenSize() return the same bounds, but the bounds of the screen, not the window bounds.

I guess we need the screen bounds only, no? I guess by window bounds, u mean frame bounds which is anyway set to 300,300 which I did not change.
If not, can you say which API to use?

-------------

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

From psadhukhan at openjdk.java.net  Fri Nov  6 03:43:11 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 6 Nov 2020 03:43:11 GMT
Subject: <Swing Dev> RFR: 7190978:
 javax/swing/JComponent/7154030/bug7154030.java fails on mac [v4]
In-Reply-To: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
References: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
Message-ID: <VTUPrptz-n3Ei6lle1sBy0FMutB0E-vWu5WM2mfUQjY=.1f2d1289-9364-44af-84e6-996b1b591488@github.com>

> Please review a test fix for an issue seen where robot image capture is wrong if screen scale factor is more, which could result in button or frame to move out of captured dimension of 300,300.
> Fixed by setting uiScale=1 in the test which can still reproduce JDK-7154030.
> Mach5 job has been run for several iterations in all platforms. Link in JBS.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Used window getbounds

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/955/files
  - new: https://git.openjdk.java.net/jdk/pull/955/files/cf936ae0..63209dd8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=955&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=955&range=02-03

  Stats: 12 lines in 1 file changed: 5 ins; 6 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/955.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/955/head:pull/955

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

From serb at openjdk.java.net  Fri Nov  6 09:02:09 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 6 Nov 2020 09:02:09 GMT
Subject: <Swing Dev> RFR: 6422025: ThemeReader.cpp can be updated for VC7
In-Reply-To: <oxZfajErufaOzwCiOiJpuyyrMfxOyeIelI7nDbpKDGo=.2f8045ce-c761-456f-8624-c541d4493a1e@github.com>
References: <oxZfajErufaOzwCiOiJpuyyrMfxOyeIelI7nDbpKDGo=.2f8045ce-c761-456f-8624-c541d4493a1e@github.com>
Message-ID: <FVgCy5-LPxdwQws3DoouDkR55jumA4jo9GMi5K5JbhU=.b946291c-c3ef-486d-9966-b29408d82c16@github.com>

On Fri, 6 Nov 2020 08:51:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Some of the type definitions have been imported from `UxTheme.h` to the `ThemeReader.cpp` because at that time we supported the windows OS below XP as well as VC6.
> 
> It is time to use `UxTheme.h ` directly, note I did not change how we load this library(JDK_LoadSystemLibrary(), as suggested in the comments of the bug it is not necessary that the application will use the win L&F and it is not necessary to link it directly.
> 
> mach5 is green

src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 38:

> 36: import java.util.concurrent.locks.ReentrantReadWriteLock;
> 37: 
> 38: /* !!!! WARNING !!!!

The comment is outdated we do not support win L&F on any Unix.

src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 302:

> 300:     }
> 301: 
> 302:     public static native boolean isGetThemeTransitionDurationDefined();

This method was added in Vista so we guarded it by the runtime check.

src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 177:

> 175:            && SetWindowThemeFunc
> 176:            && IsThemeBackgroundPartiallyTransparentFunc
> 177:            && GetThemeTransitionDurationFunc

Now we check `GetThemeTransitionDurationFunc` as well.

-------------

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

From serb at openjdk.java.net  Fri Nov  6 09:02:08 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 6 Nov 2020 09:02:08 GMT
Subject: <Swing Dev> RFR: 6422025: ThemeReader.cpp can be updated for VC7
Message-ID: <oxZfajErufaOzwCiOiJpuyyrMfxOyeIelI7nDbpKDGo=.2f8045ce-c761-456f-8624-c541d4493a1e@github.com>

Some of the type definitions have been imported from `UxTheme.h` to the `ThemeReader.cpp` because at that time we supported the windows OS below XP as well as VC6.

It is time to use `UxTheme.h ` directly, note I did not change how we load this library(JDK_LoadSystemLibrary(), as suggested in the comments of the bug it is not necessary that the application will use the win L&F and it is not necessary to link it directly.

mach5 is green

-------------

Commit messages:
 - 6422025: ThemeReader.cpp can be updated for VC7

Changes: https://git.openjdk.java.net/jdk/pull/1090/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1090&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-6422025
  Stats: 145 lines in 3 files changed: 2 ins; 63 del; 80 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1090.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1090/head:pull/1090

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

From psadhukhan at openjdk.java.net  Fri Nov  6 12:17:57 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 6 Nov 2020 12:17:57 GMT
Subject: <Swing Dev> Withdrawn: 4916923: In MetalRootPaneUI,
 MetalRootLayout does not correctly calculate minimumsize
In-Reply-To: <x12pgHHvm8vRqf5U4RMWGVX7kO1pimiJmRHv2-XdEIg=.43e13b99-57f6-4125-9013-ec67456fce1e@github.com>
References: <x12pgHHvm8vRqf5U4RMWGVX7kO1pimiJmRHv2-XdEIg=.43e13b99-57f6-4125-9013-ec67456fce1e@github.com>
Message-ID: <aAtzT716T6DPlMQDhuem8lzfY9u4rS2_Zr_SgSUvYmE=.d953a3b7-e10c-432c-9177-cbc0ee7726bd@github.com>

On Wed, 30 Sep 2020 12:11:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Please review a fix for an issue where minimumLayoutSize and preferredlayoutSize of MetalRootLayout class wrongly uses the width of the title pane in the height calculation:
> Proposed fix is to rectify the anomaly and use tpHeight for height calculation.
> 
> All closed, open jtreg and JCK tests and SwingSet2 Metal L&F are unaffected by this change.

This pull request has been closed without being integrated.

-------------

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

From psadhukhan at openjdk.java.net  Fri Nov  6 12:30:55 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 6 Nov 2020 12:30:55 GMT
Subject: <Swing Dev> RFR: 7190978:
 javax/swing/JComponent/7154030/bug7154030.java fails on mac [v2]
In-Reply-To: <vgTMOK9kVf5nP1F1S7Iu2_6Igq0F8Dt6ZUFUmg3rPOE=.f804df7f-e6be-460d-afa0-772fcfa446e3@github.com>
References: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
 <b2OxDrNcVjF_-tg7PDl7qbcJ6V-6F07TIk9qHxxRFac=.4c7f161c-b59a-440d-9f84-24ef5bac62ce@github.com>
 <aIDEYwLHUlh-7xomoaRPtvkSfWS5qfj7YI2xQ1g70Go=.f8bd0259-666b-47a2-94a7-f964596171cb@github.com>
 <BAoIMC9xd8oYAUicjlm3TuXTogXiSxhTNRpMVAX2r7s=.0c1a24ac-bd1e-403c-9f84-c3cf3f79e171@github.com>
 <MZuAHD9K7elHf-c0ejJnyVloMSaq44I8S9AFMkK7u6Q=.a7e503ac-3624-4723-8e4c-2f46483f68f3@github.com>
 <6aMgUbkf3sKP69rM4mbfJBuMe845Et7jc_8pmRr-7gE=.88219b1a-ece0-4e04-886b-bacfdd4b119a@github.com>
 <WxcqnFOMfiy-m1OgRCcyuMUAahoYC3ZMrZBbTr3NifE=.a026053b-f250-4346-8f2c-1b012a6876bc@github.com>
 <vgTMOK9kVf5nP1F1S7Iu2_6Igq0F8Dt6ZUFUmg3rPOE=.f804df7f-e6be-460d-afa0-772fcfa446e3@github.com>
Message-ID: <ytjUEyhi5DbaPilrH6GMM6ZLWGgLel0c1zN9yHBjNrw=.80a35585-3d17-4bad-b1cc-ec902f486cb7@github.com>

On Thu, 5 Nov 2020 11:35:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> GC.getBounds() and Toolkit.getScreenSize() return the same bounds, but the bounds of the screen, not the window bounds.
>
> I guess we need the screen bounds only, no? I guess by window bounds, u mean frame bounds which is anyway set to 300,300 which I did not change.
> If not, can you say which API to use?

Used window bounds...Please let me know if any other comments.

-------------

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

From aivanov at openjdk.java.net  Fri Nov  6 18:21:00 2020
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 6 Nov 2020 18:21:00 GMT
Subject: <Swing Dev> RFR: 6422025: ThemeReader.cpp can be updated for VC7
In-Reply-To: <oxZfajErufaOzwCiOiJpuyyrMfxOyeIelI7nDbpKDGo=.2f8045ce-c761-456f-8624-c541d4493a1e@github.com>
References: <oxZfajErufaOzwCiOiJpuyyrMfxOyeIelI7nDbpKDGo=.2f8045ce-c761-456f-8624-c541d4493a1e@github.com>
Message-ID: <VqGLFNav6xIYe9LsqpJhdop4zngd5Y-H4e5-lcxXA2A=.0ce782dd-f10e-4391-8fe7-beec2e4de0d8@github.com>

On Fri, 6 Nov 2020 08:51:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Some of the type definitions have been imported from `UxTheme.h` to the `ThemeReader.cpp` because at that time we supported the windows OS below XP as well as VC6.
> 
> It is time to use `UxTheme.h ` directly, note I did not change how we load this library(JDK_LoadSystemLibrary(), as suggested in the comments of the bug it is not necessary that the application will use the win L&F and it is not necessary to link it directly.
> 
> mach5 is green

Changes requested by aivanov (Reviewer).

src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 126:

> 124:         DTRACE_PRINTLN("Loaded UxTheme.dll\n");
> 125:         OpenThemeDataFunc = (PFNOPENTHEMEDATA)GetProcAddress(hModThemes,
> 126:                                                         "OpenThemeData");

Can't we use the functions directly? I mean we can link to `UxTheme.lib` and load the `UxTheme.dll` automatically.
Dynamic loading was necessary for Windows versions before Windows XP where `UxTheme.dll` doesn't exist.

-------------

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

From prappo at openjdk.java.net  Fri Nov  6 20:17:04 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 6 Nov 2020 20:17:04 GMT
Subject: <Swing Dev> RFR: 8255989: Remove explicitly unascribed authorship
 from Java source files
Message-ID: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>

This PR proposes to remove
1. JavaDoc `@author` tags with unclear semantics: `@author unascribed|unattributed|unknown`
2. A couple of astray Form Feed (a.k.a. FF, `\f`,  `0xC`, or `^L`) characters

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/1100/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1100&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255989
  Stats: 140 lines in 77 files changed: 0 ins; 80 del; 60 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1100.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1100/head:pull/1100

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

From redestad at openjdk.java.net  Fri Nov  6 20:28:57 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 6 Nov 2020 20:28:57 GMT
Subject: <Swing Dev> RFR: 8255989: Remove explicitly unascribed
 authorship from Java source files
In-Reply-To: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
References: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
Message-ID: <NXj1QERdKDWAI_eCPFIqxfcpSvgIsMaZj-D098av1Bs=.a8ad7c00-e037-449e-93c0-0ba7c3fb455b@github.com>

On Fri, 6 Nov 2020 20:11:24 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR proposes to remove
> 1. JavaDoc `@author` tags with unclear semantics: `@author unascribed|unattributed|unknown`
> 2. A couple of astray Form Feed (a.k.a. FF, `\f`,  `0xC`, or `^L`) characters

A removed @author tag is a good @author tag

-------------

Marked as reviewed by redestad (Reviewer).

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

From mr at openjdk.java.net  Fri Nov  6 21:17:59 2020
From: mr at openjdk.java.net (Mark Reinhold)
Date: Fri, 6 Nov 2020 21:17:59 GMT
Subject: <Swing Dev> RFR: 8255989: Remove explicitly unascribed
 authorship from Java source files
In-Reply-To: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
References: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
Message-ID: <BXofM2LBxP-1vS0_CarSp2TRDMe6_jUI56Dw8QuBsCw=.6dd59831-78f0-4730-8e9f-c97fa6ee03b2@github.com>

On Fri, 6 Nov 2020 20:11:24 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR proposes to remove
> 1. JavaDoc `@author` tags with unclear semantics: `@author unascribed|unattributed|unknown`
> 2. A couple of astray Form Feed (a.k.a. FF, `\f`,  `0xC`, or `^L`) characters

Marked as reviewed by mr (Lead).

-------------

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

From mchung at openjdk.java.net  Fri Nov  6 21:25:56 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 6 Nov 2020 21:25:56 GMT
Subject: <Swing Dev> RFR: 8255989: Remove explicitly unascribed
 authorship from Java source files
In-Reply-To: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
References: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
Message-ID: <4lqSkD7QVCiQkecfe_9HY1XLD7-l0OqNLmjTfJ9AgQw=.f11bfd8f-ff3e-454c-a560-6f34637eeb2c@github.com>

On Fri, 6 Nov 2020 20:11:24 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR proposes to remove
> 1. JavaDoc `@author` tags with unclear semantics: `@author unascribed|unattributed|unknown`
> 2. A couple of astray Form Feed (a.k.a. FF, `\f`,  `0xC`, or `^L`) characters

Marked as reviewed by mchung (Reviewer).

-------------

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

From iris at openjdk.java.net  Fri Nov  6 21:40:57 2020
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 6 Nov 2020 21:40:57 GMT
Subject: <Swing Dev> RFR: 8255989: Remove explicitly unascribed
 authorship from Java source files
In-Reply-To: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
References: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
Message-ID: <s-NIWpKZrEAHSFtUU4Ebb8O9-eplKij8yJJn5d6PPus=.c3adad62-7973-4f84-af13-eee58210d609@github.com>

On Fri, 6 Nov 2020 20:11:24 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR proposes to remove
> 1. JavaDoc `@author` tags with unclear semantics: `@author unascribed|unattributed|unknown`
> 2. A couple of astray Form Feed (a.k.a. FF, `\f`,  `0xC`, or `^L`) characters

Marked as reviewed by iris (Reviewer).

-------------

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

From serb at openjdk.java.net  Fri Nov  6 22:13:00 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 6 Nov 2020 22:13:00 GMT
Subject: <Swing Dev> RFR: 6422025: ThemeReader.cpp can be updated for VC7
In-Reply-To: <VqGLFNav6xIYe9LsqpJhdop4zngd5Y-H4e5-lcxXA2A=.0ce782dd-f10e-4391-8fe7-beec2e4de0d8@github.com>
References: <oxZfajErufaOzwCiOiJpuyyrMfxOyeIelI7nDbpKDGo=.2f8045ce-c761-456f-8624-c541d4493a1e@github.com>
 <VqGLFNav6xIYe9LsqpJhdop4zngd5Y-H4e5-lcxXA2A=.0ce782dd-f10e-4391-8fe7-beec2e4de0d8@github.com>
Message-ID: <Cc_GQmYiWFFcbRDnxtJiFm0Z2gCIIxrMJqKncx4MRHw=.7ce10673-c4d7-4b3a-9b2d-5f3eac2a0f18@github.com>

On Fri, 6 Nov 2020 18:17:30 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Some of the type definitions have been imported from `UxTheme.h` to the `ThemeReader.cpp` because at that time we supported the windows OS below XP as well as VC6.
>> 
>> It is time to use `UxTheme.h ` directly, note I did not change how we load this library(JDK_LoadSystemLibrary(), as suggested in the comments of the bug it is not necessary that the application will use the win L&F and it is not necessary to link it directly.
>> 
>> mach5 is green
>
> src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 126:
> 
>> 124:         DTRACE_PRINTLN("Loaded UxTheme.dll\n");
>> 125:         OpenThemeDataFunc = (PFNOPENTHEMEDATA)GetProcAddress(hModThemes,
>> 126:                                                         "OpenThemeData");
> 
> Can't we use the functions directly? I mean we can link to `UxTheme.lib` and load the `UxTheme.dll` automatically.
> Dynamic loading was necessary for Windows versions before Windows XP where `UxTheme.dll` doesn't exist.

That's was my comment in the description about:

>  It is time to use UxTheme.h directly, note I did not change how we load this library(JDK_LoadSystemLibrary(), as suggested in the comments of the bug it is not necessary that the application will use the win L&F and it is not necessary to link it directly,

 also, the native win L&F is an optional thing.

-------------

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

From aivanov at openjdk.java.net  Fri Nov  6 22:45:58 2020
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 6 Nov 2020 22:45:58 GMT
Subject: <Swing Dev> RFR: 6422025: ThemeReader.cpp can be updated for VC7
In-Reply-To: <Cc_GQmYiWFFcbRDnxtJiFm0Z2gCIIxrMJqKncx4MRHw=.7ce10673-c4d7-4b3a-9b2d-5f3eac2a0f18@github.com>
References: <oxZfajErufaOzwCiOiJpuyyrMfxOyeIelI7nDbpKDGo=.2f8045ce-c761-456f-8624-c541d4493a1e@github.com>
 <VqGLFNav6xIYe9LsqpJhdop4zngd5Y-H4e5-lcxXA2A=.0ce782dd-f10e-4391-8fe7-beec2e4de0d8@github.com>
 <Cc_GQmYiWFFcbRDnxtJiFm0Z2gCIIxrMJqKncx4MRHw=.7ce10673-c4d7-4b3a-9b2d-5f3eac2a0f18@github.com>
Message-ID: <Dd6IYKsl2aZ2jDTuFJbRz3S2xBi_-QBf0ji1FKgCgJM=.d45069f4-aea4-46a8-b7a9-7932df30c662@github.com>

On Fri, 6 Nov 2020 22:09:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 126:
>> 
>>> 124:         DTRACE_PRINTLN("Loaded UxTheme.dll\n");
>>> 125:         OpenThemeDataFunc = (PFNOPENTHEMEDATA)GetProcAddress(hModThemes,
>>> 126:                                                         "OpenThemeData");
>> 
>> Can't we use the functions directly? I mean we can link to `UxTheme.lib` and load the `UxTheme.dll` automatically.
>> Dynamic loading was necessary for Windows versions before Windows XP where `UxTheme.dll` doesn't exist.
>
> That's was my comment in the description about:
> 
>>  It is time to use UxTheme.h directly, note I did not change how we load this library(JDK_LoadSystemLibrary(), as suggested in the comments of the bug it is not necessary that the application will use the win L&F and it is not necessary to link it directly,
> 
>  also, the native win L&F is an optional thing.

Thank you for the clarification. I must have missed this note. Yes, I later realised that it could be the reason why you didn't update how the DLL is loaded.
Delay-load is another option, on the other hand there's already the code to load the library and get the function pointers.

-------------

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

From aivanov at openjdk.java.net  Fri Nov  6 22:45:57 2020
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 6 Nov 2020 22:45:57 GMT
Subject: <Swing Dev> RFR: 6422025: ThemeReader.cpp can be updated for VC7
In-Reply-To: <oxZfajErufaOzwCiOiJpuyyrMfxOyeIelI7nDbpKDGo=.2f8045ce-c761-456f-8624-c541d4493a1e@github.com>
References: <oxZfajErufaOzwCiOiJpuyyrMfxOyeIelI7nDbpKDGo=.2f8045ce-c761-456f-8624-c541d4493a1e@github.com>
Message-ID: <guA_eD8edIvIFnkJMpyA5ajngrEDQeqpovpgxJmXAxg=.4d6d0a93-2607-4ffa-86e3-40497bb06f61@github.com>

On Fri, 6 Nov 2020 08:51:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Some of the type definitions have been imported from `UxTheme.h` to the `ThemeReader.cpp` because at that time we supported the windows OS below XP as well as VC6.
> 
> It is time to use `UxTheme.h ` directly, note I did not change how we load this library(JDK_LoadSystemLibrary(), as suggested in the comments of the bug it is not necessary that the application will use the win L&F and it is not necessary to link it directly.
> 
> mach5 is green

Marked as reviewed by aivanov (Reviewer).

-------------

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

From serb at openjdk.java.net  Sat Nov  7 06:13:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 7 Nov 2020 06:13:57 GMT
Subject: <Swing Dev> Integrated: 6422025: ThemeReader.cpp can be updated for
 VC7
In-Reply-To: <oxZfajErufaOzwCiOiJpuyyrMfxOyeIelI7nDbpKDGo=.2f8045ce-c761-456f-8624-c541d4493a1e@github.com>
References: <oxZfajErufaOzwCiOiJpuyyrMfxOyeIelI7nDbpKDGo=.2f8045ce-c761-456f-8624-c541d4493a1e@github.com>
Message-ID: <penvlmKBvXq0noIPfljh6Sntm2b6qMjJ2hPfhVlV0r0=.674b9373-415e-47f6-a4a7-d5ff299b29d6@github.com>

On Fri, 6 Nov 2020 08:51:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Some of the type definitions have been imported from `UxTheme.h` to the `ThemeReader.cpp` because at that time we supported the windows OS below XP as well as VC6.
> 
> It is time to use `UxTheme.h ` directly, note I did not change how we load this library(JDK_LoadSystemLibrary(), as suggested in the comments of the bug it is not necessary that the application will use the win L&F and it is not necessary to link it directly.
> 
> mach5 is green

This pull request has now been integrated.

Changeset: 358f5d2b
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/358f5d2b
Stats:     145 lines in 3 files changed: 2 ins; 63 del; 80 mod

6422025: ThemeReader.cpp can be updated for VC7

Reviewed-by: aivanov

-------------

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

From serb at openjdk.java.net  Sat Nov  7 09:04:58 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 7 Nov 2020 09:04:58 GMT
Subject: <Swing Dev> RFR: 7190978:
 javax/swing/JComponent/7154030/bug7154030.java fails on mac [v3]
In-Reply-To: <uW7MA4awjAXfpW6OdLXNksZoZdybc-rkeYFtm2baLIc=.abd919a4-e5f4-4eda-900b-ee29caf4e6da@github.com>
References: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
 <uW7MA4awjAXfpW6OdLXNksZoZdybc-rkeYFtm2baLIc=.abd919a4-e5f4-4eda-900b-ee29caf4e6da@github.com>
Message-ID: <VFNbFmcHbDQU4j8GN8E_tpCrSTzjMBlUtdQ3RSKHKcQ=.910b25ad-6827-4742-bea2-6ab7c656c59e@github.com>

On Wed, 4 Nov 2020 14:38:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Please review a test fix for an issue seen where robot image capture is wrong if screen scale factor is more, which could result in button or frame to move out of captured dimension of 300,300.
>> Fixed by setting uiScale=1 in the test which can still reproduce JDK-7154030.
>> Mach5 job has been run for several iterations in all platforms. Link in JBS.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use getBounds()

test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 96:

> 94:                                       getDefaultScreenDevice().getDefaultConfiguration().
> 95:                                       getBounds();
> 96:                     locx = rect.width/2;

The usage of size 300x300 has the same issues as locx/locy before. It is part of the window bounds.

-------------

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

From serb at openjdk.java.net  Sat Nov  7 09:07:54 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 7 Nov 2020 09:07:54 GMT
Subject: <Swing Dev> RFR: 8255989: Remove explicitly unascribed
 authorship from Java source files
In-Reply-To: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
References: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
Message-ID: <g14KL4Fyv5qtYlqDWXMXBXs9N89kvx2cXl7cUKzwxrE=.0cb3a58a-6e38-4bff-814c-f9a9dbf0b0c5@github.com>

On Fri, 6 Nov 2020 20:11:24 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR proposes to remove
> 1. JavaDoc `@author` tags with unclear semantics: `@author unascribed|unattributed|unknown`
> 2. A couple of astray Form Feed (a.k.a. FF, `\f`,  `0xC`, or `^L`) characters

Marked as reviewed by serb (Reviewer).

-------------

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

From prappo at openjdk.java.net  Sat Nov  7 11:52:08 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Sat, 7 Nov 2020 11:52:08 GMT
Subject: <Swing Dev> RFR: 8255989: Remove explicitly unascribed
 authorship from Java source files [v2]
In-Reply-To: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
References: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
Message-ID: <TDJhHLH1pPKaWtmDP2vjWa5Fq7SiikXPslLW_F09-HM=.f706d3b9-4053-46d1-9d9f-d156cf2cceff@github.com>

> This PR proposes to remove
> 1. JavaDoc `@author` tags with unclear semantics: `@author unascribed|unattributed|unknown`
> 2. A couple of astray Form Feed (a.k.a. FF, `\f`,  `0xC`, or `^L`) characters

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into 8255989
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1100/files
  - new: https://git.openjdk.java.net/jdk/pull/1100/files/9f9b0a85..830ffafb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1100&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1100&range=00-01

  Stats: 192 lines in 9 files changed: 28 ins; 64 del; 100 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1100.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1100/head:pull/1100

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

From prappo at openjdk.java.net  Sat Nov  7 12:09:55 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Sat, 7 Nov 2020 12:09:55 GMT
Subject: <Swing Dev> RFR: 8255989: Remove explicitly unascribed
 authorship from Java source files [v2]
In-Reply-To: <g14KL4Fyv5qtYlqDWXMXBXs9N89kvx2cXl7cUKzwxrE=.0cb3a58a-6e38-4bff-814c-f9a9dbf0b0c5@github.com>
References: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
 <g14KL4Fyv5qtYlqDWXMXBXs9N89kvx2cXl7cUKzwxrE=.0cb3a58a-6e38-4bff-814c-f9a9dbf0b0c5@github.com>
Message-ID: <yIaBasqWPzIV7U0vBcoO6n0PXATYFnvHcSQaKn9PNTg=.af66d989-b606-4fbc-b298-e74867c518e0@github.com>

On Sat, 7 Nov 2020 09:05:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8255989
>>  - Initial commit
>
> Marked as reviewed by serb (Reviewer).

Thanks to all the reviewers, this may be now integrated.

For extra confidence, I went to https://openjdk.java.net/census and checked that there are no authors whose name is one of "unascribed", "unattributed", or "unknown". I did this because some words might not be what they seem: for example, see https://stackoverflow.com/questions/4456438/how-to-pass-null-a-real-surname-to-a-soap-web-service-in-actionscript-3

-------------

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

From prappo at openjdk.java.net  Sat Nov  7 12:14:56 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Sat, 7 Nov 2020 12:14:56 GMT
Subject: <Swing Dev> Integrated: 8255989: Remove explicitly unascribed
 authorship from Java source files
In-Reply-To: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
References: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
Message-ID: <kRuRluhvztusqU-jT53kBjdKy9hzaK4WAFrcaFjMak4=.d2d77e82-ada8-4c97-99d6-7987c7746d2b@github.com>

On Fri, 6 Nov 2020 20:11:24 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR proposes to remove
> 1. JavaDoc `@author` tags with unclear semantics: `@author unascribed|unattributed|unknown`
> 2. A couple of astray Form Feed (a.k.a. FF, `\f`,  `0xC`, or `^L`) characters

This pull request has now been integrated.

Changeset: c5462bb9
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c5462bb9
Stats:     140 lines in 77 files changed: 0 ins; 80 del; 60 mod

8255989: Remove explicitly unascribed authorship from Java source files

Reviewed-by: redestad, mr, mchung, iris, serb

-------------

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

From psadhukhan at openjdk.java.net  Sat Nov  7 14:36:57 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Sat, 7 Nov 2020 14:36:57 GMT
Subject: <Swing Dev> RFR: 7190978:
 javax/swing/JComponent/7154030/bug7154030.java fails on mac [v3]
In-Reply-To: <VFNbFmcHbDQU4j8GN8E_tpCrSTzjMBlUtdQ3RSKHKcQ=.910b25ad-6827-4742-bea2-6ab7c656c59e@github.com>
References: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
 <uW7MA4awjAXfpW6OdLXNksZoZdybc-rkeYFtm2baLIc=.abd919a4-e5f4-4eda-900b-ee29caf4e6da@github.com>
 <VFNbFmcHbDQU4j8GN8E_tpCrSTzjMBlUtdQ3RSKHKcQ=.910b25ad-6827-4742-bea2-6ab7c656c59e@github.com>
Message-ID: <hr_mjSgZWZ86cZBMaUmLoH4o6glJKI-7bQlZfE5MCyU=.f7d38f6d-509f-4b32-b568-825135c981e5@github.com>

On Sat, 7 Nov 2020 09:02:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use getBounds()
>
> test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 96:
> 
>> 94:                                       getDefaultScreenDevice().getDefaultConfiguration().
>> 95:                                       getBounds();
>> 96:                     locx = rect.width/2;
> 
> The usage of size 300x300 has the same issues as locx/locy before. It is part of the window bounds.

but 300x300 is set in frame setSize..if I use frame getBounds instead of already set 300x300, that will not be right, according to me...What if getBounds() has some bug (in some platform) and return some other width/height (say 1 pixel less, we might have similar bug in 8196465) that what is set in setSize, then the test might pass even though robot is capturing wrong bounds.

-------------

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

From serb at openjdk.java.net  Sat Nov  7 23:10:56 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 7 Nov 2020 23:10:56 GMT
Subject: <Swing Dev> RFR: 7190978:
 javax/swing/JComponent/7154030/bug7154030.java fails on mac [v3]
In-Reply-To: <hr_mjSgZWZ86cZBMaUmLoH4o6glJKI-7bQlZfE5MCyU=.f7d38f6d-509f-4b32-b568-825135c981e5@github.com>
References: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
 <uW7MA4awjAXfpW6OdLXNksZoZdybc-rkeYFtm2baLIc=.abd919a4-e5f4-4eda-900b-ee29caf4e6da@github.com>
 <VFNbFmcHbDQU4j8GN8E_tpCrSTzjMBlUtdQ3RSKHKcQ=.910b25ad-6827-4742-bea2-6ab7c656c59e@github.com>
 <hr_mjSgZWZ86cZBMaUmLoH4o6glJKI-7bQlZfE5MCyU=.f7d38f6d-509f-4b32-b568-825135c981e5@github.com>
Message-ID: <LGg-PSnxq0Nl2d7_qm-hGNK-3CkU9sQscngFio6rOZo=.6ece1731-0dde-4491-9bff-200364acb4c8@github.com>

On Sat, 7 Nov 2020 14:33:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> but 300x300 is set in frame setSize..if I use frame getBounds instead of already set 300x300, that will not be right, according to me...

The test should set the size 300,300 to the frame and then request and use the real bounds of the frame.

> What if getBounds() has some bug (in some platform) and return some other width/height (say 1 pixel less, we might have similar bug in 8196465) that what is set in setSize, then the test might pass even though robot is capturing wrong bounds.

The getBounds() simply returns the size which was set by the native system, so is it a bug in getBounds() or the real bounds of the frame "say 1 pixel less"?

-------------

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

From serb at openjdk.java.net  Mon Nov  9 00:42:00 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 9 Nov 2020 00:42:00 GMT
Subject: <Swing Dev> RFR: 8256014: Eliminate the warning about serialization
 in non-public API of Swing
Message-ID: <mI3RazbbTjb_JmSYtkl4fA_27pvLodApUI0ObtpoyGA=.2eed0e72-4c6e-40ed-942d-ab0a1d0e4be5@github.com>

As part of the serialization cleanup, I would like to remove the serialization warning below from the non-public API(mostly motif and windows L&Fs). Later I will remove it from the public API and move this warning to the "javax.swing" package spec.

 * <strong>Warning:</strong>
 * Serialized objects of this class will not be compatible with
 * future Swing releases. The current serialization support is appropriate
 * for short term storage or RMI between applications running the same
 * version of Swing. A future release of Swing will provide support for
 * long term persistence.

Note that this warning is useless because the UI delegates(parts of L&F) should never be serialized. Such classes were marked as "Serializable" by accident. If the component like JButton is serialized then parts related to the L&F are removed from the stream. This is because default L&F could be different before/after serialization.

-------------

Commit messages:
 - 8256014: Eliminate the warning about serialization in non-public API of Swing

Changes: https://git.openjdk.java.net/jdk/pull/1110/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1110&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256014
  Stats: 1405 lines in 67 files changed: 404 ins; 700 del; 301 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1110.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1110/head:pull/1110

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

From prr at openjdk.java.net  Mon Nov  9 01:23:58 2020
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 9 Nov 2020 01:23:58 GMT
Subject: <Swing Dev> RFR: 8256014: Eliminate the warning about
 serialization in non-public API of Swing
In-Reply-To: <mI3RazbbTjb_JmSYtkl4fA_27pvLodApUI0ObtpoyGA=.2eed0e72-4c6e-40ed-942d-ab0a1d0e4be5@github.com>
References: <mI3RazbbTjb_JmSYtkl4fA_27pvLodApUI0ObtpoyGA=.2eed0e72-4c6e-40ed-942d-ab0a1d0e4be5@github.com>
Message-ID: <dCOIO7AhyPYx5xLBaZEevgtazZTVsjewL7N9FhRNKEw=.7dca7c8f-a5a6-473b-ba00-edc1d4901f67@github.com>

On Sun, 8 Nov 2020 09:14:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As part of the serialization cleanup, I would like to remove the serialization warning below from the non-public API(mostly motif and windows L&Fs). Later I will remove it from the public API and move this warning to the "javax.swing" package spec.
> 
>  * <strong>Warning:</strong>
>  * Serialized objects of this class will not be compatible with
>  * future Swing releases. The current serialization support is appropriate
>  * for short term storage or RMI between applications running the same
>  * version of Swing. A future release of Swing will provide support for
>  * long term persistence.
> 
> Note that this warning is useless because the UI delegates(parts of L&F) should never be serialized. Such classes were marked as "Serializable" by accident. If the component like JButton is serialized then parts related to the L&F are removed from the stream. This is because default L&F could be different before/after serialization.

Marked as reviewed by prr (Reviewer).

-------------

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

From psadhukhan at openjdk.java.net  Mon Nov  9 04:04:09 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 9 Nov 2020 04:04:09 GMT
Subject: <Swing Dev> RFR: 7190978:
 javax/swing/JComponent/7154030/bug7154030.java fails on mac [v5]
In-Reply-To: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
References: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
Message-ID: <Z9Xf8y_iWvuzvKZBYZUWT7AzpnQ02WtbC_g-m5kD5rc=.366b5885-e905-4a99-8815-a96277a10f4a@github.com>

> Please review a test fix for an issue seen where robot image capture is wrong if screen scale factor is more, which could result in button or frame to move out of captured dimension of 300,300.
> Fixed by setting uiScale=1 in the test which can still reproduce JDK-7154030.
> Mach5 job has been run for several iterations in all platforms. Link in JBS.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Address review comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/955/files
  - new: https://git.openjdk.java.net/jdk/pull/955/files/63209dd8..f5fd7169

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=955&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=955&range=03-04

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

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

From psadhukhan at openjdk.java.net  Mon Nov  9 04:18:54 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 9 Nov 2020 04:18:54 GMT
Subject: <Swing Dev> RFR: 8256014: Eliminate the warning about
 serialization in non-public API of Swing
In-Reply-To: <mI3RazbbTjb_JmSYtkl4fA_27pvLodApUI0ObtpoyGA=.2eed0e72-4c6e-40ed-942d-ab0a1d0e4be5@github.com>
References: <mI3RazbbTjb_JmSYtkl4fA_27pvLodApUI0ObtpoyGA=.2eed0e72-4c6e-40ed-942d-ab0a1d0e4be5@github.com>
Message-ID: <UJBDkabu7SZ-iAd5AHkSJwCVYu7hPZD05TtXcNmYvkU=.9ee906d6-32f3-4a4a-aabd-75e377cbff30@github.com>

On Sun, 8 Nov 2020 09:14:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As part of the serialization cleanup, I would like to remove the serialization warning below from the non-public API(mostly motif and windows L&Fs). Later I will remove it from the public API and move this warning to the "javax.swing" package spec.
> 
>  * <strong>Warning:</strong>
>  * Serialized objects of this class will not be compatible with
>  * future Swing releases. The current serialization support is appropriate
>  * for short term storage or RMI between applications running the same
>  * version of Swing. A future release of Swing will provide support for
>  * long term persistence.
> 
> Note that this warning is useless because the UI delegates(parts of L&F) should never be serialized. Such classes were marked as "Serializable" by accident. If the component like JButton is serialized then parts related to the L&F are removed from the stream. This is because default L&F could be different before/after serialization.

Marked as reviewed by psadhukhan (Reviewer).

-------------

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

From serb at openjdk.java.net  Mon Nov  9 06:43:56 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 9 Nov 2020 06:43:56 GMT
Subject: <Swing Dev> Integrated: 8256014: Eliminate the warning about
 serialization in non-public API of Swing
In-Reply-To: <mI3RazbbTjb_JmSYtkl4fA_27pvLodApUI0ObtpoyGA=.2eed0e72-4c6e-40ed-942d-ab0a1d0e4be5@github.com>
References: <mI3RazbbTjb_JmSYtkl4fA_27pvLodApUI0ObtpoyGA=.2eed0e72-4c6e-40ed-942d-ab0a1d0e4be5@github.com>
Message-ID: <awmIsKfuI7bfWhFmyBPaJdeNePgcvTpyTb4v3Q3sJA0=.7f94c0df-b114-4ddc-8b32-b539bb0b03af@github.com>

On Sun, 8 Nov 2020 09:14:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As part of the serialization cleanup, I would like to remove the serialization warning below from the non-public API(mostly motif and windows L&Fs). Later I will remove it from the public API and move this warning to the "javax.swing" package spec.
> 
>  * <strong>Warning:</strong>
>  * Serialized objects of this class will not be compatible with
>  * future Swing releases. The current serialization support is appropriate
>  * for short term storage or RMI between applications running the same
>  * version of Swing. A future release of Swing will provide support for
>  * long term persistence.
> 
> Note that this warning is useless because the UI delegates(parts of L&F) should never be serialized. Such classes were marked as "Serializable" by accident. If the component like JButton is serialized then parts related to the L&F are removed from the stream. This is because default L&F could be different before/after serialization.

This pull request has now been integrated.

Changeset: c7551c37
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c7551c37
Stats:     1405 lines in 67 files changed: 404 ins; 700 del; 301 mod

8256014: Eliminate the warning about serialization in non-public API of Swing

Reviewed-by: prr, psadhukhan

-------------

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

From psadhukhan at openjdk.java.net  Mon Nov  9 08:39:01 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 9 Nov 2020 08:39:01 GMT
Subject: <Swing Dev> RFR: 8255916: [macos]
 javax/swing/JInternalFrame/6647340/bug6647340.java timed out
Message-ID: <6eov1ILcclPgMfsnI9-AuQrKZhJSSZvxNowYJhZHXwU=.9a602c3c-82a2-454d-beb5-2e26d81553a0@github.com>

This test has failed in one of jdk nightly testing although it always passed locally. Made the test use robot delays, waitForIdle() to make it more stable and appropriate to run in slower mach5 systems and also remove the dependancy on ExtendedRobot.
Mach5 job has been run for several iterations in all platforms. Link in JBS.

-------------

Commit messages:
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/1115/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1115&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255916
  Stats: 65 lines in 1 file changed: 12 ins; 23 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1115.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1115/head:pull/1115

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

From kizune at openjdk.java.net  Mon Nov  9 12:03:11 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 9 Nov 2020 12:03:11 GMT
Subject: <Swing Dev> RFR: 4907798: MEMORY LEAK:
 javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper [v2]
In-Reply-To: <_EqDyPXhK4t_zt1Gcdx4dSGj0sKB7AdLC3T7F-Elhvg=.5470e2d2-dc1d-438d-8e0b-72f92ba0440d@github.com>
References: <_EqDyPXhK4t_zt1Gcdx4dSGj0sKB7AdLC3T7F-Elhvg=.5470e2d2-dc1d-438d-8e0b-72f92ba0440d@github.com>
Message-ID: <vm20g66Ynt7C2MawTcCEaGMnBiUVBAKO1Pej_BWxIio=.187e215a-fa5b-40d1-b843-be2fe77a277d@github.com>

> 4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Test case made multiplatform and testing all the LaF's

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1035/files
  - new: https://git.openjdk.java.net/jdk/pull/1035/files/ff35c56a..31cfa27c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1035&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1035&range=00-01

  Stats: 151 lines in 1 file changed: 79 ins; 45 del; 27 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1035.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1035/head:pull/1035

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

From kizune at openjdk.java.net  Mon Nov  9 12:03:12 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 9 Nov 2020 12:03:12 GMT
Subject: <Swing Dev> RFR: 4907798: MEMORY LEAK:
 javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper [v2]
In-Reply-To: <UnpWHuKSD_uKz0K9SJoHgyr3fSN3IMC4EP7PejM8d2s=.8770179d-3edb-4178-9582-df7675e4a2d3@github.com>
References: <_EqDyPXhK4t_zt1Gcdx4dSGj0sKB7AdLC3T7F-Elhvg=.5470e2d2-dc1d-438d-8e0b-72f92ba0440d@github.com>
 <UnpWHuKSD_uKz0K9SJoHgyr3fSN3IMC4EP7PejM8d2s=.8770179d-3edb-4178-9582-df7675e4a2d3@github.com>
Message-ID: <ZOcvmhIcm0EBTxQeVHWK3nTpSveSwYwGJYLHpA9TDlQ=.6c0a8308-59fd-4941-b856-943ea0ae9687@github.com>

On Tue, 3 Nov 2020 16:44:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I think even if the fix is in windows, there's no harm in making the test platform agnostic and let it run for all platforms.

Done.

-------------

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

From kizune at openjdk.java.net  Mon Nov  9 12:03:14 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 9 Nov 2020 12:03:14 GMT
Subject: <Swing Dev> RFR: 4907798: MEMORY LEAK:
 javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper [v2]
In-Reply-To: <vuzUv2nWtu_rhjnC4DMszCcaqYgg-CdzlG0jXdW4UsM=.c8f1d94e-76e2-493a-bed8-1f50fbd0cb57@github.com>
References: <_EqDyPXhK4t_zt1Gcdx4dSGj0sKB7AdLC3T7F-Elhvg=.5470e2d2-dc1d-438d-8e0b-72f92ba0440d@github.com>
 <vuzUv2nWtu_rhjnC4DMszCcaqYgg-CdzlG0jXdW4UsM=.c8f1d94e-76e2-493a-bed8-1f50fbd0cb57@github.com>
Message-ID: <YUnpi97y6AFwktYgFwK8S0lDD3yihYxzJZAqN-NmviI=.25a2954d-bc6b-43af-87c1-b2fe22f6efd6@github.com>

On Tue, 3 Nov 2020 18:41:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test case made multiplatform and testing all the LaF's
>
> test/jdk/javax/swing/JMenu/PopupReferenceMemoryLeak.java line 57:
> 
>> 55:         try {
>> 56:             // Set system look and feel
>> 57:             UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
> 
> I suggest checking all installed L&Fs for example https://github.com/openjdk/jdk/pull/989/files

Fixed

> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java line 1229:
> 
>> 1227:                 // and uninstall menu keybindings
>> 1228:                    removeItems();
>> 1229:                    menuInputMap = null;
> 
> Just curious, will the uninstall(); at the start of the method will clear this flag as well?

We do call ninstall() at the beginning of the method but it does not resolve the issue.

> test/jdk/javax/swing/JMenu/PopupReferenceMemoryLeak.java line 89:
> 
>> 87:             for(int i=0; i<3; i++) {
>> 88:                 try {
>> 89:                     ArrayList gc = new ArrayList();
> 
> It will be useful to call System.gc() and limit the size of the heap via -mx

System.gc() does not affect test in any way so i just left it out.

> test/jdk/javax/swing/JMenu/PopupReferenceMemoryLeak.java line 100:
> 
>> 98:             }
>> 99:             robot.waitForIdle();
>> 100:             robot.keyPress(KeyEvent.VK_ALT);
> 
> Can we skip the robot interaction and instead show the popup menu ourselves? (not via menu items)

No, unfortunately one of the mechanics i'm testing only reproducible when popup is being opened from JMenuBar.

-------------

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

From kizune at openjdk.java.net  Mon Nov  9 12:03:14 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 9 Nov 2020 12:03:14 GMT
Subject: <Swing Dev> Withdrawn: 4907798: MEMORY LEAK:
 javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper
In-Reply-To: <_EqDyPXhK4t_zt1Gcdx4dSGj0sKB7AdLC3T7F-Elhvg=.5470e2d2-dc1d-438d-8e0b-72f92ba0440d@github.com>
References: <_EqDyPXhK4t_zt1Gcdx4dSGj0sKB7AdLC3T7F-Elhvg=.5470e2d2-dc1d-438d-8e0b-72f92ba0440d@github.com>
Message-ID: <QBq6CU_zEwqCieRxssMyR2IPV3eyCVm7MAI0onrL22I=.11fd0809-ac1d-4106-84b1-12658f46e84b@github.com>

On Tue, 3 Nov 2020 10:32:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper

This pull request has been closed without being integrated.

-------------

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

From serb at openjdk.java.net  Mon Nov  9 18:04:56 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 9 Nov 2020 18:04:56 GMT
Subject: <Swing Dev> RFR: 8255916: [macos]
 javax/swing/JInternalFrame/6647340/bug6647340.java timed out
In-Reply-To: <6eov1ILcclPgMfsnI9-AuQrKZhJSSZvxNowYJhZHXwU=.9a602c3c-82a2-454d-beb5-2e26d81553a0@github.com>
References: <6eov1ILcclPgMfsnI9-AuQrKZhJSSZvxNowYJhZHXwU=.9a602c3c-82a2-454d-beb5-2e26d81553a0@github.com>
Message-ID: <ea13Xt6CRDiN85mBeDektrfSxydpGxlN8hkhOXoJVB4=.c58345ce-1094-482a-b46f-7b1c41363a1b@github.com>

On Mon, 9 Nov 2020 08:34:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test has failed in one of jdk nightly testing although it always passed locally. Made the test use robot delays, waitForIdle() to make it more stable and appropriate to run in slower mach5 systems and also remove the dependancy on ExtendedRobot.
> Mach5 job has been run for several iterations in all platforms. Link in JBS.

test/jdk/javax/swing/JInternalFrame/6647340/bug6647340.java line 133:

> 131:             iconloc = jif.getDesktopIcon().getLocation();
> 132:         });
> 133:         if (iconloc.equals(location)) {

iconloc and iconloc are set on EDT and used on the main thread, it would be good to mark them volatile.

-------------

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

From serb at openjdk.java.net  Mon Nov  9 18:11:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 9 Nov 2020 18:11:57 GMT
Subject: <Swing Dev> RFR: 4907798: MEMORY LEAK:
 javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper [v2]
In-Reply-To: <YUnpi97y6AFwktYgFwK8S0lDD3yihYxzJZAqN-NmviI=.25a2954d-bc6b-43af-87c1-b2fe22f6efd6@github.com>
References: <_EqDyPXhK4t_zt1Gcdx4dSGj0sKB7AdLC3T7F-Elhvg=.5470e2d2-dc1d-438d-8e0b-72f92ba0440d@github.com>
 <vuzUv2nWtu_rhjnC4DMszCcaqYgg-CdzlG0jXdW4UsM=.c8f1d94e-76e2-493a-bed8-1f50fbd0cb57@github.com>
 <YUnpi97y6AFwktYgFwK8S0lDD3yihYxzJZAqN-NmviI=.25a2954d-bc6b-43af-87c1-b2fe22f6efd6@github.com>
Message-ID: <2kVgnn_UFxXNRs_LF49yBjzIC-XSdscyPd4cgwhHX6A=.66ef68f4-ec8c-4446-a578-d1b420522eda@github.com>

On Mon, 9 Nov 2020 11:57:40 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java line 1229:
>> 
>>> 1227:                 // and uninstall menu keybindings
>>> 1228:                    removeItems();
>>> 1229:                    menuInputMap = null;
>> 
>> Just curious, will the uninstall(); at the start of the method will clear this flag as well?
>
> We do call ninstall() at the beginning of the method but it does not resolve the issue.

I meant this code at the start of the method:
`            if (!(UIManager.getLookAndFeel() instanceof BasicLookAndFeel)) {
                uninstall();
                return;
            }`
If "uninstall" will not solve the problem and the code added in this fix will not be executed, then we will get the same leak?

-------------

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

From github.com+72060147+amresh-sahu at openjdk.java.net  Mon Nov  9 18:36:04 2020
From: github.com+72060147+amresh-sahu at openjdk.java.net (Amresh Sahu)
Date: Mon, 9 Nov 2020 18:36:04 GMT
Subject: <Swing Dev> RFR: 8253905: Update sanity test suite to not place
 windows at (0, 0)
Message-ID: <3N-nPvDM_3O1fd0gLG3J5dNA_5oVCzTGY6nNiWG0HwI=.44b59b3e-6b0e-4b53-82d1-309180edd8ed@github.com>

Four files has been modified:
        modified:   test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/dialog/DialogDemo.java
        modified:   test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/frame/FrameDemo.java
        modified:   test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/TableDemo.java
        modified:   test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/window/WindowDemo.java

Tested on Mach5 and all tests passes.

-------------

Commit messages:
 - Update TableDemo.java
 - Update DialogDemo.java
 - Update WindowDemo.java
 - Update DialogDemo.java
 - Update TableDemo.java
 - Update WindowDemo.java
 - Update WindowDemo.java
 - Checked-in changes for JDK-8253905

Changes: https://git.openjdk.java.net/jdk/pull/625/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=625&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253905
  Stats: 4 lines in 4 files changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/625.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/625/head:pull/625

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

From shurailine at openjdk.java.net  Mon Nov  9 18:36:04 2020
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Mon, 9 Nov 2020 18:36:04 GMT
Subject: <Swing Dev> RFR: 8253905: Update sanity test suite to not place
 windows at (0, 0)
In-Reply-To: <3N-nPvDM_3O1fd0gLG3J5dNA_5oVCzTGY6nNiWG0HwI=.44b59b3e-6b0e-4b53-82d1-309180edd8ed@github.com>
References: <3N-nPvDM_3O1fd0gLG3J5dNA_5oVCzTGY6nNiWG0HwI=.44b59b3e-6b0e-4b53-82d1-309180edd8ed@github.com>
Message-ID: <-lExk1C25UNtvSajcVa2JmV7puA5SQlfuMC2a9FpUiI=.34fe8c36-a87d-4f36-b884-7744357b3095@github.com>

On Tue, 13 Oct 2020 08:05:34 GMT, Amresh Sahu <github.com+72060147+amresh-sahu at openjdk.org> wrote:

> Four files has been modified:
>         modified:   test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/dialog/DialogDemo.java
>         modified:   test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/frame/FrameDemo.java
>         modified:   test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/TableDemo.java
>         modified:   test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/window/WindowDemo.java
> 
> Tested on Mach5 and all tests passes.

Marked as reviewed by shurailine (Committer).

-------------

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

From github.com+72060147+amresh-sahu at openjdk.java.net  Mon Nov  9 18:36:04 2020
From: github.com+72060147+amresh-sahu at openjdk.java.net (Amresh Sahu)
Date: Mon, 9 Nov 2020 18:36:04 GMT
Subject: <Swing Dev> RFR: 8253905: Update sanity test suite to not place
 windows at (0, 0)
In-Reply-To: <-lExk1C25UNtvSajcVa2JmV7puA5SQlfuMC2a9FpUiI=.34fe8c36-a87d-4f36-b884-7744357b3095@github.com>
References: <3N-nPvDM_3O1fd0gLG3J5dNA_5oVCzTGY6nNiWG0HwI=.44b59b3e-6b0e-4b53-82d1-309180edd8ed@github.com>
 <-lExk1C25UNtvSajcVa2JmV7puA5SQlfuMC2a9FpUiI=.34fe8c36-a87d-4f36-b884-7744357b3095@github.com>
Message-ID: <hYmFmqDssBdA_myFlm2e-3Tp0FwQAZ_LS2JwHeW2cp8=.b14a0f24-b092-453c-8a20-6cd62e0e2def@github.com>

On Tue, 13 Oct 2020 17:03:16 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

>> Four files has been modified:
>>         modified:   test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/dialog/DialogDemo.java
>>         modified:   test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/frame/FrameDemo.java
>>         modified:   test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/TableDemo.java
>>         modified:   test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/window/WindowDemo.java
>> 
>> Tested on Mach5 and all tests passes.
>
> Marked as reviewed by shurailine (Committer).

@mrserb @akolarkunnu 

Please review my code changes.

-------------

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

From robilad at openjdk.java.net  Mon Nov  9 18:36:04 2020
From: robilad at openjdk.java.net (Dalibor Topic)
Date: Mon, 9 Nov 2020 18:36:04 GMT
Subject: <Swing Dev> RFR: 8253905: Update sanity test suite to not place
 windows at (0, 0)
In-Reply-To: <hYmFmqDssBdA_myFlm2e-3Tp0FwQAZ_LS2JwHeW2cp8=.b14a0f24-b092-453c-8a20-6cd62e0e2def@github.com>
References: <3N-nPvDM_3O1fd0gLG3J5dNA_5oVCzTGY6nNiWG0HwI=.44b59b3e-6b0e-4b53-82d1-309180edd8ed@github.com>
 <-lExk1C25UNtvSajcVa2JmV7puA5SQlfuMC2a9FpUiI=.34fe8c36-a87d-4f36-b884-7744357b3095@github.com>
 <hYmFmqDssBdA_myFlm2e-3Tp0FwQAZ_LS2JwHeW2cp8=.b14a0f24-b092-453c-8a20-6cd62e0e2def@github.com>
Message-ID: <fUy0VxKTE89_8p6P575gQ0H38HwXB0UXV5wto6a-JVo=.ab61a951-54ef-424c-874e-79abddd49daf@github.com>

On Tue, 20 Oct 2020 03:43:49 GMT, Amresh Sahu <github.com+72060147+amresh-sahu at openjdk.org> wrote:

>> Marked as reviewed by shurailine (Committer).
>
> @mrserb @akolarkunnu 
> 
> Please review my code changes.

Hi, can you let me know under whose OCA your contributions would be covered via e-mail to dalibor.topic at oracle.com, please? Then I can verify your account. Thanks!

-------------

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

From serb at openjdk.java.net  Mon Nov  9 19:37:58 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 9 Nov 2020 19:37:58 GMT
Subject: <Swing Dev> RFR: 8253905: Update sanity test suite to not place
 windows at (0, 0)
In-Reply-To: <3N-nPvDM_3O1fd0gLG3J5dNA_5oVCzTGY6nNiWG0HwI=.44b59b3e-6b0e-4b53-82d1-309180edd8ed@github.com>
References: <3N-nPvDM_3O1fd0gLG3J5dNA_5oVCzTGY6nNiWG0HwI=.44b59b3e-6b0e-4b53-82d1-309180edd8ed@github.com>
Message-ID: <1aUqcTAFqztmuYKEpPdBJ66abbT3aVs-CXMZmXnmebc=.949587e7-59e8-45b6-a293-84bdb4c5f964@github.com>

On Tue, 13 Oct 2020 08:05:34 GMT, Amresh Sahu <github.com+72060147+amresh-sahu at openjdk.org> wrote:

> Four files has been modified:
>         modified:   test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/dialog/DialogDemo.java
>         modified:   test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/frame/FrameDemo.java
>         modified:   test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/TableDemo.java
>         modified:   test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/window/WindowDemo.java
> 
> Tested on Mach5 and all tests passes.

Marked as reviewed by serb (Reviewer).

-------------

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

From kizune at openjdk.java.net  Mon Nov  9 23:27:55 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 9 Nov 2020 23:27:55 GMT
Subject: <Swing Dev> RFR: 4907798: MEMORY LEAK:
 javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper [v2]
In-Reply-To: <2kVgnn_UFxXNRs_LF49yBjzIC-XSdscyPd4cgwhHX6A=.66ef68f4-ec8c-4446-a578-d1b420522eda@github.com>
References: <_EqDyPXhK4t_zt1Gcdx4dSGj0sKB7AdLC3T7F-Elhvg=.5470e2d2-dc1d-438d-8e0b-72f92ba0440d@github.com>
 <vuzUv2nWtu_rhjnC4DMszCcaqYgg-CdzlG0jXdW4UsM=.c8f1d94e-76e2-493a-bed8-1f50fbd0cb57@github.com>
 <YUnpi97y6AFwktYgFwK8S0lDD3yihYxzJZAqN-NmviI=.25a2954d-bc6b-43af-87c1-b2fe22f6efd6@github.com>
 <2kVgnn_UFxXNRs_LF49yBjzIC-XSdscyPd4cgwhHX6A=.66ef68f4-ec8c-4446-a578-d1b420522eda@github.com>
Message-ID: <6Yshz_j4vL9vPCT_fbWebxmv6IGKKug7ZolO2GDVw0Q=.2d582579-25e9-4008-b073-1d608378d42c@github.com>

On Mon, 9 Nov 2020 18:08:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> We do call ninstall() at the beginning of the method but it does not resolve the issue.
>
> I meant this code at the start of the method:
> `            if (!(UIManager.getLookAndFeel() instanceof BasicLookAndFeel)) {
>                 uninstall();
>                 return;
>             }`
> If "uninstall" will not solve the problem and the code added in this fix will not be executed, then we will get the same leak?

The code block here with uninstall is called if currently installed LAF is not derived from BasicLAF in which case we will not have this problem in the first place - the only place where we are setting menuInputMap variable is in this method down the line so it never gets initialized. And no, calling uninstall() unconditionally will not solve the problem because uninstall() does not change this value either.

-------------

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

From serb at openjdk.java.net  Tue Nov 10 02:50:54 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 10 Nov 2020 02:50:54 GMT
Subject: <Swing Dev> RFR: 4907798: MEMORY LEAK:
 javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper [v2]
In-Reply-To: <6Yshz_j4vL9vPCT_fbWebxmv6IGKKug7ZolO2GDVw0Q=.2d582579-25e9-4008-b073-1d608378d42c@github.com>
References: <_EqDyPXhK4t_zt1Gcdx4dSGj0sKB7AdLC3T7F-Elhvg=.5470e2d2-dc1d-438d-8e0b-72f92ba0440d@github.com>
 <vuzUv2nWtu_rhjnC4DMszCcaqYgg-CdzlG0jXdW4UsM=.c8f1d94e-76e2-493a-bed8-1f50fbd0cb57@github.com>
 <YUnpi97y6AFwktYgFwK8S0lDD3yihYxzJZAqN-NmviI=.25a2954d-bc6b-43af-87c1-b2fe22f6efd6@github.com>
 <2kVgnn_UFxXNRs_LF49yBjzIC-XSdscyPd4cgwhHX6A=.66ef68f4-ec8c-4446-a578-d1b420522eda@github.com>
 <6Yshz_j4vL9vPCT_fbWebxmv6IGKKug7ZolO2GDVw0Q=.2d582579-25e9-4008-b073-1d608378d42c@github.com>
Message-ID: <hpReHvloMeA2NsD30i7f2f8vnviYs_GfSDbYVl1HbaM=.3318d083-26e0-435a-99f3-39fef44287cf@github.com>

On Mon, 9 Nov 2020 23:25:13 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> I meant this code at the start of the method:
>> `            if (!(UIManager.getLookAndFeel() instanceof BasicLookAndFeel)) {
>>                 uninstall();
>>                 return;
>>             }`
>> If "uninstall" will not solve the problem and the code added in this fix will not be executed, then we will get the same leak?
>
> The code block here with uninstall is called if currently installed LAF is not derived from BasicLAF in which case we will not have this problem in the first place - the only place where we are setting menuInputMap variable is in this method down the line so it never gets initialized. And no, calling uninstall() unconditionally will not solve the problem because uninstall() does not change this value either.

I guess that the uninstall() above is called when the L&F was basic(since BasicPopupMenuUI is used) and then changed for some reason, so when the method in the BasicPopupMenuUI.java will be called we will find that the current L&F is different and call "uninstall()", so this is my question: will the leak will exist in that case? I mean the code changed by the current fix will not be executed since we will exit after "uninstall()".

-------------

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

From psadhukhan at openjdk.java.net  Tue Nov 10 03:41:02 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 10 Nov 2020 03:41:02 GMT
Subject: <Swing Dev> RFR: 7190978:
 javax/swing/JComponent/7154030/bug7154030.java fails on mac [v3]
In-Reply-To: <LGg-PSnxq0Nl2d7_qm-hGNK-3CkU9sQscngFio6rOZo=.6ece1731-0dde-4491-9bff-200364acb4c8@github.com>
References: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
 <uW7MA4awjAXfpW6OdLXNksZoZdybc-rkeYFtm2baLIc=.abd919a4-e5f4-4eda-900b-ee29caf4e6da@github.com>
 <VFNbFmcHbDQU4j8GN8E_tpCrSTzjMBlUtdQ3RSKHKcQ=.910b25ad-6827-4742-bea2-6ab7c656c59e@github.com>
 <hr_mjSgZWZ86cZBMaUmLoH4o6glJKI-7bQlZfE5MCyU=.f7d38f6d-509f-4b32-b568-825135c981e5@github.com>
 <LGg-PSnxq0Nl2d7_qm-hGNK-3CkU9sQscngFio6rOZo=.6ece1731-0dde-4491-9bff-200364acb4c8@github.com>
Message-ID: <GTLsziED6blYR2h42r55F2QcSN_tywiglcVQv388RQ8=.b9823e6b-d3ed-4d2a-9698-abcfa86662d0@github.com>

On Sat, 7 Nov 2020 23:08:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> but 300x300 is set in frame setSize..if I use frame getBounds instead of already set 300x300, that will not be right, according to me...What if getBounds() has some bug (in some platform) and return some other width/height (say 1 pixel less, we might have similar bug in 8196465) that what is set in setSize, then the test might pass even though robot is capturing wrong bounds.
>
>> but 300x300 is set in frame setSize..if I use frame getBounds instead of already set 300x300, that will not be right, according to me...
> 
> The test should set the size 300,300 to the frame and then request and use the real bounds of the frame.
> 
>> What if getBounds() has some bug (in some platform) and return some other width/height (say 1 pixel less, we might have similar bug in 8196465) that what is set in setSize, then the test might pass even though robot is capturing wrong bounds.
> 
> The getBounds() simply returns the size which was set by the native system, so is it a bug in getBounds() or the real bounds of the frame "say 1 pixel less"?

Any further feedback?

-------------

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

From psadhukhan at openjdk.java.net  Tue Nov 10 04:14:15 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 10 Nov 2020 04:14:15 GMT
Subject: <Swing Dev> RFR: 8255916: [macos]
 javax/swing/JInternalFrame/6647340/bug6647340.java timed out [v2]
In-Reply-To: <6eov1ILcclPgMfsnI9-AuQrKZhJSSZvxNowYJhZHXwU=.9a602c3c-82a2-454d-beb5-2e26d81553a0@github.com>
References: <6eov1ILcclPgMfsnI9-AuQrKZhJSSZvxNowYJhZHXwU=.9a602c3c-82a2-454d-beb5-2e26d81553a0@github.com>
Message-ID: <TC0CdiWFoRwRueGNc7dAnDLUKmlJ24eZrQxNR2SrG1g=.f8f82479-974f-4c50-bb5c-a4c15f11e5e5@github.com>

> This test has failed in one of jdk nightly testing although it always passed locally. Made the test use robot delays, waitForIdle() to make it more stable and appropriate to run in slower mach5 systems and also remove the dependancy on ExtendedRobot.
> Mach5 job has been run for several iterations in all platforms. Link in JBS.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Marked volatile

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1115/files
  - new: https://git.openjdk.java.net/jdk/pull/1115/files/9f53b404..a875bff4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1115&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1115&range=00-01

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

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

From github.com+72060147+amresh-sahu at openjdk.java.net  Tue Nov 10 05:29:59 2020
From: github.com+72060147+amresh-sahu at openjdk.java.net (Amresh Sahu)
Date: Tue, 10 Nov 2020 05:29:59 GMT
Subject: <Swing Dev> Integrated: 8253905: Update sanity test suite to not
 place windows at (0, 0)
In-Reply-To: <3N-nPvDM_3O1fd0gLG3J5dNA_5oVCzTGY6nNiWG0HwI=.44b59b3e-6b0e-4b53-82d1-309180edd8ed@github.com>
References: <3N-nPvDM_3O1fd0gLG3J5dNA_5oVCzTGY6nNiWG0HwI=.44b59b3e-6b0e-4b53-82d1-309180edd8ed@github.com>
Message-ID: <Y79XdFgNGPEaSl4R2paSAPYsbsUSt_TsNxMabQAsPkA=.fe7e59fb-58ff-40ec-bfd2-9c0906e8ad23@github.com>

On Tue, 13 Oct 2020 08:05:34 GMT, Amresh Sahu <github.com+72060147+amresh-sahu at openjdk.org> wrote:

> Four files has been modified:
>         modified:   test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/dialog/DialogDemo.java
>         modified:   test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/frame/FrameDemo.java
>         modified:   test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/TableDemo.java
>         modified:   test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/window/WindowDemo.java
> 
> Tested on Mach5 and all tests passes.

This pull request has now been integrated.

Changeset: 8066b33c
Author:    amresh-sahu <72060147+amresh-sahu at users.noreply.github.com>
Committer: Alexandre Iline <shurailine at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8066b33c
Stats:     4 lines in 4 files changed: 4 ins; 0 del; 0 mod

8253905: Update sanity test suite to not place windows at (0,0)

Reviewed-by: shurailine, serb

-------------

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

From kizune at openjdk.java.net  Tue Nov 10 09:19:59 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 10 Nov 2020 09:19:59 GMT
Subject: <Swing Dev> RFR: 8211999: Window positioning bugs due to
 overlapping GraphicsDevice bounds (Windows/HiDPI) [v4]
In-Reply-To: <GNK5tQ1JknvAOBjO-IA2tvR-u9hI8s1pjtoTAtWvj0I=.24099e9b-dc10-4fc9-b4d3-9b167f299721@github.com>
References: <kkB8arYa2TYXREelYcOweRcdmT1mgr2CWgD-piP-CbM=.1537b8e9-7fcd-4029-8c8a-488a9d25bd43@github.com>
 <GNK5tQ1JknvAOBjO-IA2tvR-u9hI8s1pjtoTAtWvj0I=.24099e9b-dc10-4fc9-b4d3-9b167f299721@github.com>
Message-ID: <h-K5JrIf9IRUTge0QEyI65ruTZAATMr0K-NmYrnoi2k=.84bda56a-5d89-43a1-a6d7-009033cf7873@github.com>

On Wed, 28 Oct 2020 23:46:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Hello.
>> Please review the fix for jdk.
>> 
>> Old review request:
>> https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015991.html
>> 
>> 
>> (Note: the fix use API available since Windows 8.1: WM_DPICHANGED, but it should be fine for
>> Windows 7, because it does not support different DPI for different monitors)
>> 
>> ========================================================
>> Short description:
>>      In the multi-screen configurations when each screen have different DPI
>>      we calculate the bounds of each monitor by these formulas:
>> 
>>          userSpaceBounds = deviceX / scaleX, deviceY / scaleY, deviceW / scaleX, deviceH / scaleY
>>          devSpaceBounds  = userX * scaleX, userY * scaleY, userW * scaleX, userH * scaleY
>> 
>>   This formula makes the next configuration completely broken:
>>     - The main screen on the left and 100% DPI
>>     - The second screen on the right and 200% DPI
>>   When we translate the bounds of the config from the device space to the user's space,
>>      the bounds of both screen overlap in the user's space, because we use bounds of
>>      the main screen as-is, and the X/Y of the second screen are divided by the scaleX/Y.
>> 
>>   Since the screens are overlapped we cannot be sure how to translate the user's space
>>    coordinates to device space in the overlapped zone.
>>   As a result => we use the wrong screen
>>                    => got wrong coordinates in the device space
>>                      => show top-level windows/popups/tooltips/menus/etc on the wrong screen
>> 
>>    The proposed solution for this bug is to change the formulas to these:
>> 
>>          userSpaceBounds = deviceX, deviceY, deviceW / scaleX, deviceH / scaleY
>>          devSpaceBounds  = userX, userY, userW * scaleX, userH * scaleY
>> 
>>    In other words, we should not transform the X and Y coordinates of the screen(the top/left corner). This will
>>    complicate the way of how we transform coordinates on the screen: user's <--> device spaces:
>> 
>>    Before the fix:
>> 
>>          userX = deviceX * scaleX;
>>          deviceX = userX / scaleX;
>> 
>>    After the fix(only the part appeared on this screen should be scaled)
>> 
>>          userX = screenX + (deviceX - screenX) * scaleX
>>          deviceX = screenX + (userX - screenX) / scaleX
>> 
>>    Note that these new formulas are applicable only for the coordinates on the screen such as X and Y.
>>    If we will need to calculate the "size" such as W and H then the old formula should be used.
>> 
>>    The main changes for the problem above are:
>>    - Skip transformation of X and Y of the screen bounds:
>>        http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsConfig.cpp.sdiff.html
>>    - A number of utility methods in java and native:
>> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp.sdiff.html
>> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java.sdiff.html
>>    
>> 
>> ========================================================
>> Long description:
>>      Unfortunately, the changes above are not enough to fix the problem when different monitors
>>      have different DPI, even if the bounds are *NOT* overlapped.
>> 
>>    - Currently, when we try to set the bounds of the window, we manually convert it in "java" to the
>>      expected device position based on the current GraphicsConfiguration of the peer, and then
>>      additionally, tweak it in native using the device scale stored in native code. Unfortunately
>>      this two scale might not be in sync:(after we use the GraphicsConfiguration scale in peer,
>>      the config might be changed and the tweak in native will use a different screen).
>> 
>>      As a fix I have moved all transformation from the peer to the native code, it will be executed
>>      on the toolkit thread:
>>      See the change in WWindowPeer.setBounds() and awt_Window.cpp AwtWindow::Reshape
>>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java.sdiff.html
>>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html
>>      I think at some point we should delete all transformation in java, and apply it in the native code only.
>>      
>> 
>>    - We had a special code that tracked the dragging of the window by the user from one screen to another,
>>      and change the size of the window only when the user stops the drag operation. I've proposed to use standard Windows
>>      machinery for that via WM_DPICHANGED: https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged
>>      As a result, Windows will provide the "best" windows bounds on the new screen. Note that the code has a
>>      workaround for https://bugs.openjdk.java.net/browse/JDK-8249164
>>   
>>    - I've also fix a variation of the bug previously fixed on macOS https://hg.openjdk.java.net/jdk/jdk/rev/b5cdba232fca
>>      If we try to change the position of the window, and Windows ignores this request then we need to call all "callbacks" manually, otherwise, the shared code will use the bounds ignored by the Windows.
>>      See the end of void AwtWindow::Reshape():
>>      http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html
>> 
>>   -  Currently the HW componets such as Canvas scales everything based on such code:
>> 
>>           770 int AwtComponent::ScaleUpX(int x) {
>>           4771     int screen = AwtWin32GraphicsDevice::DeviceIndexForWindow(GetHWnd());
>>           4772     Devices::InstanceAccess devices;
>>           4773     AwtWin32GraphicsDevice* device = devices->GetDevice(screen);
>>           4774     return device == NULL ? x : device->ScaleUpX(x);
>>           4775 }
>> 
>>   But it does not work well if the smaller part of the top-level window is located on one screen1(DPI=100) but
>>      the biggest part is located on the screen2(DPI=200). If the Canvas is located on the "smaller" part of the
>>      window, then the canvas will use DPI=100 for scale, but the whole window will use DPI=200
>> 
>>    As a fix, all HW components will try to use the scale factor of the top-level window, see AwtComponent::GetScreenImOn:
>> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp.sdiff.html
>> 
>>    - Our current implementation does not take care of the case when the HW component bounds are updated when the top-level
>>      the window is moved to another screen. For example, if the window does not use LayoutManager and the user sets some specific bounds for the Canvas. It is expected that the size of the Canvas will be updated when the window will be moved to another screen, but only HW top-level window and Swing components will update its size.
>> 
>>      As a fix I suggest to resync the bounds of the HW components if the GraphicsCOnfiguration is changed, see WComponentPeer.syncBounds():
>>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java.sdiff.html
>> 
>>    - Note that the current fix is for Windows only, but the bug exists on Linux as well, so I have to create a kind of "ifdef" in the
>>      Robot class, on windows we will use the new logic, on other platforms the old logic will be used.
>> 
>>    - The win32GraphicsDevice incorrectly sets the size of the full-screen window. It uses the display mode width/height(which are stored in pixels), but the bounds of the graphics config(which are stored in user's space) should be used.
>> 
>> ========================================================
>> Some other bugs which are not fixed.
>> 
>>     - We have a lot of places where we mix(unintentionally) the coordinate in user's space and device space.
>>       For example when we create the component we read x/y/width/height by the JNI(of course in a user's space)
>>       but pass this coordinates as-is to the ::CreateWindowEx() which is incorrect. It works currently
>>       because later we reshape the component to the correct bounds. Will fix it later.
>> 
>>     - When the frame is iconized and we try to save a new bounds for the future use, we store the
>>       coordinates in the user's space to the field which use device space:
>>       https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp#L664
>> 
>> Probably there are some other bugs and possibility to cleanups, but I would like to do that in separate issues.
>>      
>> 
>> ========================================================
>> The tests
>>     - I have updated a couple of the tests to check multiple screens if possible, it helps to found some bugs
>>       in my initial implementation
>>     - Four new tests were added: SetComponentsBounds, SlowMotion, WindowSizeDifferentScreens, FullscreenWindowProps
>>     - One test is moved from the closed repo(I made a small cleanup of it): ListMultipleSelectTest
>> 
>> ========================================================
>> I have run jck, regression tests in different configurations, when the main screen is on the left, up, down,
>> right, and have different DPI such as 100, 125, 150, and 200. No new issues were found so far.
>> 
>> The mach5 is also green.
>> 
>> PS: hope I did not forget some important information, will send it later if any.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Update WindowSizeDifferentScreens.java
>  - Update ListMultipleSelectTest.java
>  - syncBounds code reformat
>  - javadoc fix for SunGraphicsEnvironment#toDeviceSpace
>  - Merge branch 'master' into JDK-8211999
>  - Apply suggestions from code review
>    
>    Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Merge branch 'master' into JDK-8211999
>  - Update FullscreenWindowProps.java
>  - Merge branch 'master' into JDK-8211999
>  - Fix fullscreen in HiDPI mode
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/1a5e6c98...636b7cc4

Marked as reviewed by kizune (Reviewer).

-------------

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

From aivanov at openjdk.java.net  Tue Nov 10 09:54:59 2020
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 10 Nov 2020 09:54:59 GMT
Subject: <Swing Dev> RFR: 8211999: Window positioning bugs due to
 overlapping GraphicsDevice bounds (Windows/HiDPI) [v4]
In-Reply-To: <GNK5tQ1JknvAOBjO-IA2tvR-u9hI8s1pjtoTAtWvj0I=.24099e9b-dc10-4fc9-b4d3-9b167f299721@github.com>
References: <kkB8arYa2TYXREelYcOweRcdmT1mgr2CWgD-piP-CbM=.1537b8e9-7fcd-4029-8c8a-488a9d25bd43@github.com>
 <GNK5tQ1JknvAOBjO-IA2tvR-u9hI8s1pjtoTAtWvj0I=.24099e9b-dc10-4fc9-b4d3-9b167f299721@github.com>
Message-ID: <5LNG6nKhwE5XoKjIS9E8Sr5x0IxcFYUcszeGcEck87s=.5d5bb638-c044-4b75-899d-758ed21b872e@github.com>

On Wed, 28 Oct 2020 23:46:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Hello.
>> Please review the fix for jdk.
>> 
>> Old review request:
>> https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015991.html
>> 
>> 
>> (Note: the fix use API available since Windows 8.1: WM_DPICHANGED, but it should be fine for
>> Windows 7, because it does not support different DPI for different monitors)
>> 
>> ========================================================
>> Short description:
>>      In the multi-screen configurations when each screen have different DPI
>>      we calculate the bounds of each monitor by these formulas:
>> 
>>          userSpaceBounds = deviceX / scaleX, deviceY / scaleY, deviceW / scaleX, deviceH / scaleY
>>          devSpaceBounds  = userX * scaleX, userY * scaleY, userW * scaleX, userH * scaleY
>> 
>>   This formula makes the next configuration completely broken:
>>     - The main screen on the left and 100% DPI
>>     - The second screen on the right and 200% DPI
>>   When we translate the bounds of the config from the device space to the user's space,
>>      the bounds of both screen overlap in the user's space, because we use bounds of
>>      the main screen as-is, and the X/Y of the second screen are divided by the scaleX/Y.
>> 
>>   Since the screens are overlapped we cannot be sure how to translate the user's space
>>    coordinates to device space in the overlapped zone.
>>   As a result => we use the wrong screen
>>                    => got wrong coordinates in the device space
>>                      => show top-level windows/popups/tooltips/menus/etc on the wrong screen
>> 
>>    The proposed solution for this bug is to change the formulas to these:
>> 
>>          userSpaceBounds = deviceX, deviceY, deviceW / scaleX, deviceH / scaleY
>>          devSpaceBounds  = userX, userY, userW * scaleX, userH * scaleY
>> 
>>    In other words, we should not transform the X and Y coordinates of the screen(the top/left corner). This will
>>    complicate the way of how we transform coordinates on the screen: user's <--> device spaces:
>> 
>>    Before the fix:
>> 
>>          userX = deviceX * scaleX;
>>          deviceX = userX / scaleX;
>> 
>>    After the fix(only the part appeared on this screen should be scaled)
>> 
>>          userX = screenX + (deviceX - screenX) * scaleX
>>          deviceX = screenX + (userX - screenX) / scaleX
>> 
>>    Note that these new formulas are applicable only for the coordinates on the screen such as X and Y.
>>    If we will need to calculate the "size" such as W and H then the old formula should be used.
>> 
>>    The main changes for the problem above are:
>>    - Skip transformation of X and Y of the screen bounds:
>>        http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsConfig.cpp.sdiff.html
>>    - A number of utility methods in java and native:
>> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp.sdiff.html
>> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java.sdiff.html
>>    
>> 
>> ========================================================
>> Long description:
>>      Unfortunately, the changes above are not enough to fix the problem when different monitors
>>      have different DPI, even if the bounds are *NOT* overlapped.
>> 
>>    - Currently, when we try to set the bounds of the window, we manually convert it in "java" to the
>>      expected device position based on the current GraphicsConfiguration of the peer, and then
>>      additionally, tweak it in native using the device scale stored in native code. Unfortunately
>>      this two scale might not be in sync:(after we use the GraphicsConfiguration scale in peer,
>>      the config might be changed and the tweak in native will use a different screen).
>> 
>>      As a fix I have moved all transformation from the peer to the native code, it will be executed
>>      on the toolkit thread:
>>      See the change in WWindowPeer.setBounds() and awt_Window.cpp AwtWindow::Reshape
>>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java.sdiff.html
>>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html
>>      I think at some point we should delete all transformation in java, and apply it in the native code only.
>>      
>> 
>>    - We had a special code that tracked the dragging of the window by the user from one screen to another,
>>      and change the size of the window only when the user stops the drag operation. I've proposed to use standard Windows
>>      machinery for that via WM_DPICHANGED: https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged
>>      As a result, Windows will provide the "best" windows bounds on the new screen. Note that the code has a
>>      workaround for https://bugs.openjdk.java.net/browse/JDK-8249164
>>   
>>    - I've also fix a variation of the bug previously fixed on macOS https://hg.openjdk.java.net/jdk/jdk/rev/b5cdba232fca
>>      If we try to change the position of the window, and Windows ignores this request then we need to call all "callbacks" manually, otherwise, the shared code will use the bounds ignored by the Windows.
>>      See the end of void AwtWindow::Reshape():
>>      http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html
>> 
>>   -  Currently the HW componets such as Canvas scales everything based on such code:
>> 
>>           770 int AwtComponent::ScaleUpX(int x) {
>>           4771     int screen = AwtWin32GraphicsDevice::DeviceIndexForWindow(GetHWnd());
>>           4772     Devices::InstanceAccess devices;
>>           4773     AwtWin32GraphicsDevice* device = devices->GetDevice(screen);
>>           4774     return device == NULL ? x : device->ScaleUpX(x);
>>           4775 }
>> 
>>   But it does not work well if the smaller part of the top-level window is located on one screen1(DPI=100) but
>>      the biggest part is located on the screen2(DPI=200). If the Canvas is located on the "smaller" part of the
>>      window, then the canvas will use DPI=100 for scale, but the whole window will use DPI=200
>> 
>>    As a fix, all HW components will try to use the scale factor of the top-level window, see AwtComponent::GetScreenImOn:
>> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp.sdiff.html
>> 
>>    - Our current implementation does not take care of the case when the HW component bounds are updated when the top-level
>>      the window is moved to another screen. For example, if the window does not use LayoutManager and the user sets some specific bounds for the Canvas. It is expected that the size of the Canvas will be updated when the window will be moved to another screen, but only HW top-level window and Swing components will update its size.
>> 
>>      As a fix I suggest to resync the bounds of the HW components if the GraphicsCOnfiguration is changed, see WComponentPeer.syncBounds():
>>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java.sdiff.html
>> 
>>    - Note that the current fix is for Windows only, but the bug exists on Linux as well, so I have to create a kind of "ifdef" in the
>>      Robot class, on windows we will use the new logic, on other platforms the old logic will be used.
>> 
>>    - The win32GraphicsDevice incorrectly sets the size of the full-screen window. It uses the display mode width/height(which are stored in pixels), but the bounds of the graphics config(which are stored in user's space) should be used.
>> 
>> ========================================================
>> Some other bugs which are not fixed.
>> 
>>     - We have a lot of places where we mix(unintentionally) the coordinate in user's space and device space.
>>       For example when we create the component we read x/y/width/height by the JNI(of course in a user's space)
>>       but pass this coordinates as-is to the ::CreateWindowEx() which is incorrect. It works currently
>>       because later we reshape the component to the correct bounds. Will fix it later.
>> 
>>     - When the frame is iconized and we try to save a new bounds for the future use, we store the
>>       coordinates in the user's space to the field which use device space:
>>       https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp#L664
>> 
>> Probably there are some other bugs and possibility to cleanups, but I would like to do that in separate issues.
>>      
>> 
>> ========================================================
>> The tests
>>     - I have updated a couple of the tests to check multiple screens if possible, it helps to found some bugs
>>       in my initial implementation
>>     - Four new tests were added: SetComponentsBounds, SlowMotion, WindowSizeDifferentScreens, FullscreenWindowProps
>>     - One test is moved from the closed repo(I made a small cleanup of it): ListMultipleSelectTest
>> 
>> ========================================================
>> I have run jck, regression tests in different configurations, when the main screen is on the left, up, down,
>> right, and have different DPI such as 100, 125, 150, and 200. No new issues were found so far.
>> 
>> The mach5 is also green.
>> 
>> PS: hope I did not forget some important information, will send it later if any.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Update WindowSizeDifferentScreens.java
>  - Update ListMultipleSelectTest.java
>  - syncBounds code reformat
>  - javadoc fix for SunGraphicsEnvironment#toDeviceSpace
>  - Merge branch 'master' into JDK-8211999
>  - Apply suggestions from code review
>    
>    Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Merge branch 'master' into JDK-8211999
>  - Update FullscreenWindowProps.java
>  - Merge branch 'master' into JDK-8211999
>  - Fix fullscreen in HiDPI mode
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/1a5e6c98...636b7cc4

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java line 357:

> 355:      * @param  config the graphics configuration which bounds are requested
> 356:      * @return the bounds of the area covered by this
> 357:      *         {@code GraphicsConfiguration} in device space(pixels).

Suggestion:

     *         {@code GraphicsConfiguration} in device space (pixels).
If changed here, all other similar places should be updated too to keep doc comments consistent.

-------------

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

From serb at openjdk.java.net  Tue Nov 10 18:44:00 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 10 Nov 2020 18:44:00 GMT
Subject: <Swing Dev> RFR: 8211999: Window positioning bugs due to
 overlapping GraphicsDevice bounds (Windows/HiDPI) [v4]
In-Reply-To: <5LNG6nKhwE5XoKjIS9E8Sr5x0IxcFYUcszeGcEck87s=.5d5bb638-c044-4b75-899d-758ed21b872e@github.com>
References: <kkB8arYa2TYXREelYcOweRcdmT1mgr2CWgD-piP-CbM=.1537b8e9-7fcd-4029-8c8a-488a9d25bd43@github.com>
 <GNK5tQ1JknvAOBjO-IA2tvR-u9hI8s1pjtoTAtWvj0I=.24099e9b-dc10-4fc9-b4d3-9b167f299721@github.com>
 <5LNG6nKhwE5XoKjIS9E8Sr5x0IxcFYUcszeGcEck87s=.5d5bb638-c044-4b75-899d-758ed21b872e@github.com>
Message-ID: <QgMOABuFZJaZI2cFl_FpaSu26QY_hyWYq8wJQa7Wb1U=.7c630020-ca4f-4a20-8755-3fca5ef042c8@github.com>

On Tue, 10 Nov 2020 09:33:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Update WindowSizeDifferentScreens.java
>>  - Update ListMultipleSelectTest.java
>>  - syncBounds code reformat
>>  - javadoc fix for SunGraphicsEnvironment#toDeviceSpace
>>  - Merge branch 'master' into JDK-8211999
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Merge branch 'master' into JDK-8211999
>>  - Update FullscreenWindowProps.java
>>  - Merge branch 'master' into JDK-8211999
>>  - Fix fullscreen in HiDPI mode
>>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/1a5e6c98...636b7cc4
>
> src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java line 357:
> 
>> 355:      * @param  config the graphics configuration which bounds are requested
>> 356:      * @return the bounds of the area covered by this
>> 357:      *         {@code GraphicsConfiguration} in device space(pixels).
> 
> Suggestion:
> 
>      *         {@code GraphicsConfiguration} in device space (pixels).
> If changed here, all other similar places should be updated too to keep doc comments consistent.

I'll fix it and also merge the master, then update the PR.

-------------

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

From shurailine at openjdk.java.net  Tue Nov 10 18:48:03 2020
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Tue, 10 Nov 2020 18:48:03 GMT
Subject: <Swing Dev> RFR: 8253820: Save test images and dumps with
 timestamps from client sanity suite
Message-ID: <iTPtNAUW1EaTfOMBuX4AJk4f1Q69sN79e7wg2y1p88E=.61f96894-4fb7-4b6a-a511-0b80769709a8@github.com>

All screen images and xml dumps, if saved with help of the library methods, are saved by adding a timestamp and a LAF name. This is useful when there is some test re-execution, so all images are preserved and it is clear which image happened first.

-------------

Commit messages:
 - Merge branch 'master' of github.com:openjdk/jdk into JDK-8253820
 - Removed unused method.
 - JDK-8253820 Save test images and dumps with timestamps from client sanity suite

Changes: https://git.openjdk.java.net/jdk/pull/1146/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1146&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253820
  Stats: 135 lines in 3 files changed: 40 ins; 49 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1146.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1146/head:pull/1146

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

From shurailine at openjdk.java.net  Tue Nov 10 18:48:03 2020
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Tue, 10 Nov 2020 18:48:03 GMT
Subject: <Swing Dev> RFR: 8253820: Save test images and dumps with
 timestamps from client sanity suite
In-Reply-To: <iTPtNAUW1EaTfOMBuX4AJk4f1Q69sN79e7wg2y1p88E=.61f96894-4fb7-4b6a-a511-0b80769709a8@github.com>
References: <iTPtNAUW1EaTfOMBuX4AJk4f1Q69sN79e7wg2y1p88E=.61f96894-4fb7-4b6a-a511-0b80769709a8@github.com>
Message-ID: <GaJ73A66-Ds8qi2T4pMaBBbouJTjLYa1MzvkRaOnj9c=.a4e93bf2-d9e8-442b-8bf7-38bc82df802d@github.com>

On Tue, 10 Nov 2020 18:39:58 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> All screen images and xml dumps, if saved with help of the library methods, are saved by adding a timestamp and a LAF name. This is useful when there is some test re-execution, so all images are preserved and it is clear which image happened first.

@amresh-sahu , can you take a look?

-------------

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

From aivanov at openjdk.java.net  Tue Nov 10 19:38:58 2020
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 10 Nov 2020 19:38:58 GMT
Subject: <Swing Dev> RFR: 8211999: Window positioning bugs due to
 overlapping GraphicsDevice bounds (Windows/HiDPI) [v4]
In-Reply-To: <QgMOABuFZJaZI2cFl_FpaSu26QY_hyWYq8wJQa7Wb1U=.7c630020-ca4f-4a20-8755-3fca5ef042c8@github.com>
References: <kkB8arYa2TYXREelYcOweRcdmT1mgr2CWgD-piP-CbM=.1537b8e9-7fcd-4029-8c8a-488a9d25bd43@github.com>
 <GNK5tQ1JknvAOBjO-IA2tvR-u9hI8s1pjtoTAtWvj0I=.24099e9b-dc10-4fc9-b4d3-9b167f299721@github.com>
 <5LNG6nKhwE5XoKjIS9E8Sr5x0IxcFYUcszeGcEck87s=.5d5bb638-c044-4b75-899d-758ed21b872e@github.com>
 <QgMOABuFZJaZI2cFl_FpaSu26QY_hyWYq8wJQa7Wb1U=.7c630020-ca4f-4a20-8755-3fca5ef042c8@github.com>
Message-ID: <qdcQkl1PoiPVHcMc34ZuuhznQKyM3fnoK4bB0lJRwIw=.881b8fe9-7194-4a3c-9bf5-26874954dbec@github.com>

On Tue, 10 Nov 2020 18:40:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java line 357:
>> 
>>> 355:      * @param  config the graphics configuration which bounds are requested
>>> 356:      * @return the bounds of the area covered by this
>>> 357:      *         {@code GraphicsConfiguration} in device space(pixels).
>> 
>> Suggestion:
>> 
>>      *         {@code GraphicsConfiguration} in device space (pixels).
>> If changed here, all other similar places should be updated too to keep doc comments consistent.
>
> I'll fix it and also merge the master, then update the PR.

In this case, also consider adding a space between the word and the opening parenthesis in these  _coordinates (x, y)_ and _size (w, h)_ and, probably, a space after comma.

-------------

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

From serb at openjdk.java.net  Tue Nov 10 20:38:12 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 10 Nov 2020 20:38:12 GMT
Subject: <Swing Dev> RFR: 8211999: Window positioning bugs due to
 overlapping GraphicsDevice bounds (Windows/HiDPI) [v5]
In-Reply-To: <kkB8arYa2TYXREelYcOweRcdmT1mgr2CWgD-piP-CbM=.1537b8e9-7fcd-4029-8c8a-488a9d25bd43@github.com>
References: <kkB8arYa2TYXREelYcOweRcdmT1mgr2CWgD-piP-CbM=.1537b8e9-7fcd-4029-8c8a-488a9d25bd43@github.com>
Message-ID: <NinzK7ulPTguNc4frEeYSP8GtXcSOraq7g1zC5pZYLc=.0eaea1c0-2db9-4ea9-b5b8-134482be5085@github.com>

> Hello.
> Please review the fix for jdk.
> 
> Old review request:
> https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015991.html
> 
> 
> (Note: the fix use API available since Windows 8.1: WM_DPICHANGED, but it should be fine for
> Windows 7, because it does not support different DPI for different monitors)
> 
> ========================================================
> Short description:
>      In the multi-screen configurations when each screen have different DPI
>      we calculate the bounds of each monitor by these formulas:
> 
>          userSpaceBounds = deviceX / scaleX, deviceY / scaleY, deviceW / scaleX, deviceH / scaleY
>          devSpaceBounds  = userX * scaleX, userY * scaleY, userW * scaleX, userH * scaleY
> 
>   This formula makes the next configuration completely broken:
>     - The main screen on the left and 100% DPI
>     - The second screen on the right and 200% DPI
>   When we translate the bounds of the config from the device space to the user's space,
>      the bounds of both screen overlap in the user's space, because we use bounds of
>      the main screen as-is, and the X/Y of the second screen are divided by the scaleX/Y.
> 
>   Since the screens are overlapped we cannot be sure how to translate the user's space
>    coordinates to device space in the overlapped zone.
>   As a result => we use the wrong screen
>                    => got wrong coordinates in the device space
>                      => show top-level windows/popups/tooltips/menus/etc on the wrong screen
> 
>    The proposed solution for this bug is to change the formulas to these:
> 
>          userSpaceBounds = deviceX, deviceY, deviceW / scaleX, deviceH / scaleY
>          devSpaceBounds  = userX, userY, userW * scaleX, userH * scaleY
> 
>    In other words, we should not transform the X and Y coordinates of the screen(the top/left corner). This will
>    complicate the way of how we transform coordinates on the screen: user's <--> device spaces:
> 
>    Before the fix:
> 
>          userX = deviceX * scaleX;
>          deviceX = userX / scaleX;
> 
>    After the fix(only the part appeared on this screen should be scaled)
> 
>          userX = screenX + (deviceX - screenX) * scaleX
>          deviceX = screenX + (userX - screenX) / scaleX
> 
>    Note that these new formulas are applicable only for the coordinates on the screen such as X and Y.
>    If we will need to calculate the "size" such as W and H then the old formula should be used.
> 
>    The main changes for the problem above are:
>    - Skip transformation of X and Y of the screen bounds:
>        http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsConfig.cpp.sdiff.html
>    - A number of utility methods in java and native:
> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp.sdiff.html
> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java.sdiff.html
>    
> 
> ========================================================
> Long description:
>      Unfortunately, the changes above are not enough to fix the problem when different monitors
>      have different DPI, even if the bounds are *NOT* overlapped.
> 
>    - Currently, when we try to set the bounds of the window, we manually convert it in "java" to the
>      expected device position based on the current GraphicsConfiguration of the peer, and then
>      additionally, tweak it in native using the device scale stored in native code. Unfortunately
>      this two scale might not be in sync:(after we use the GraphicsConfiguration scale in peer,
>      the config might be changed and the tweak in native will use a different screen).
> 
>      As a fix I have moved all transformation from the peer to the native code, it will be executed
>      on the toolkit thread:
>      See the change in WWindowPeer.setBounds() and awt_Window.cpp AwtWindow::Reshape
>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java.sdiff.html
>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html
>      I think at some point we should delete all transformation in java, and apply it in the native code only.
>      
> 
>    - We had a special code that tracked the dragging of the window by the user from one screen to another,
>      and change the size of the window only when the user stops the drag operation. I've proposed to use standard Windows
>      machinery for that via WM_DPICHANGED: https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged
>      As a result, Windows will provide the "best" windows bounds on the new screen. Note that the code has a
>      workaround for https://bugs.openjdk.java.net/browse/JDK-8249164
>   
>    - I've also fix a variation of the bug previously fixed on macOS https://hg.openjdk.java.net/jdk/jdk/rev/b5cdba232fca
>      If we try to change the position of the window, and Windows ignores this request then we need to call all "callbacks" manually, otherwise, the shared code will use the bounds ignored by the Windows.
>      See the end of void AwtWindow::Reshape():
>      http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html
> 
>   -  Currently the HW componets such as Canvas scales everything based on such code:
> 
>           770 int AwtComponent::ScaleUpX(int x) {
>           4771     int screen = AwtWin32GraphicsDevice::DeviceIndexForWindow(GetHWnd());
>           4772     Devices::InstanceAccess devices;
>           4773     AwtWin32GraphicsDevice* device = devices->GetDevice(screen);
>           4774     return device == NULL ? x : device->ScaleUpX(x);
>           4775 }
> 
>   But it does not work well if the smaller part of the top-level window is located on one screen1(DPI=100) but
>      the biggest part is located on the screen2(DPI=200). If the Canvas is located on the "smaller" part of the
>      window, then the canvas will use DPI=100 for scale, but the whole window will use DPI=200
> 
>    As a fix, all HW components will try to use the scale factor of the top-level window, see AwtComponent::GetScreenImOn:
> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp.sdiff.html
> 
>    - Our current implementation does not take care of the case when the HW component bounds are updated when the top-level
>      the window is moved to another screen. For example, if the window does not use LayoutManager and the user sets some specific bounds for the Canvas. It is expected that the size of the Canvas will be updated when the window will be moved to another screen, but only HW top-level window and Swing components will update its size.
> 
>      As a fix I suggest to resync the bounds of the HW components if the GraphicsCOnfiguration is changed, see WComponentPeer.syncBounds():
>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java.sdiff.html
> 
>    - Note that the current fix is for Windows only, but the bug exists on Linux as well, so I have to create a kind of "ifdef" in the
>      Robot class, on windows we will use the new logic, on other platforms the old logic will be used.
> 
>    - The win32GraphicsDevice incorrectly sets the size of the full-screen window. It uses the display mode width/height(which are stored in pixels), but the bounds of the graphics config(which are stored in user's space) should be used.
> 
> ========================================================
> Some other bugs which are not fixed.
> 
>     - We have a lot of places where we mix(unintentionally) the coordinate in user's space and device space.
>       For example when we create the component we read x/y/width/height by the JNI(of course in a user's space)
>       but pass this coordinates as-is to the ::CreateWindowEx() which is incorrect. It works currently
>       because later we reshape the component to the correct bounds. Will fix it later.
> 
>     - When the frame is iconized and we try to save a new bounds for the future use, we store the
>       coordinates in the user's space to the field which use device space:
>       https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp#L664
> 
> Probably there are some other bugs and possibility to cleanups, but I would like to do that in separate issues.
>      
> 
> ========================================================
> The tests
>     - I have updated a couple of the tests to check multiple screens if possible, it helps to found some bugs
>       in my initial implementation
>     - Four new tests were added: SetComponentsBounds, SlowMotion, WindowSizeDifferentScreens, FullscreenWindowProps
>     - One test is moved from the closed repo(I made a small cleanup of it): ListMultipleSelectTest
> 
> ========================================================
> I have run jck, regression tests in different configurations, when the main screen is on the left, up, down,
> right, and have different DPI such as 100, 125, 150, and 200. No new issues were found so far.
> 
> The mach5 is also green.
> 
> PS: hope I did not forget some important information, will send it later if any.

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Update SunGraphicsEnvironment.java
 - Merge branch 'master' into JDK-8211999
 - Update WindowSizeDifferentScreens.java
 - Update ListMultipleSelectTest.java
 - syncBounds code reformat
 - javadoc fix for SunGraphicsEnvironment#toDeviceSpace
 - Merge branch 'master' into JDK-8211999
 - Apply suggestions from code review
   
   Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Merge branch 'master' into JDK-8211999
 - Update FullscreenWindowProps.java
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/a7f46919...fd238ef6

-------------

Changes: https://git.openjdk.java.net/jdk/pull/375/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=375&range=04
  Stats: 1393 lines in 35 files changed: 962 ins; 276 del; 155 mod
  Patch: https://git.openjdk.java.net/jdk/pull/375.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/375/head:pull/375

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

From serb at openjdk.java.net  Tue Nov 10 20:38:12 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 10 Nov 2020 20:38:12 GMT
Subject: <Swing Dev> RFR: 8211999: Window positioning bugs due to
 overlapping GraphicsDevice bounds (Windows/HiDPI) [v4]
In-Reply-To: <qdcQkl1PoiPVHcMc34ZuuhznQKyM3fnoK4bB0lJRwIw=.881b8fe9-7194-4a3c-9bf5-26874954dbec@github.com>
References: <kkB8arYa2TYXREelYcOweRcdmT1mgr2CWgD-piP-CbM=.1537b8e9-7fcd-4029-8c8a-488a9d25bd43@github.com>
 <GNK5tQ1JknvAOBjO-IA2tvR-u9hI8s1pjtoTAtWvj0I=.24099e9b-dc10-4fc9-b4d3-9b167f299721@github.com>
 <5LNG6nKhwE5XoKjIS9E8Sr5x0IxcFYUcszeGcEck87s=.5d5bb638-c044-4b75-899d-758ed21b872e@github.com>
 <QgMOABuFZJaZI2cFl_FpaSu26QY_hyWYq8wJQa7Wb1U=.7c630020-ca4f-4a20-8755-3fca5ef042c8@github.com>
 <qdcQkl1PoiPVHcMc34ZuuhznQKyM3fnoK4bB0lJRwIw=.881b8fe9-7194-4a3c-9bf5-26874954dbec@github.com>
Message-ID: <CfCuqLTeuQR_Y9bgRrr5zBGF9uL1KkcKhBdcY4uA3EI=.994881dc-5304-4aec-a68c-29ce7a07447b@github.com>

On Tue, 10 Nov 2020 19:35:58 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I'll fix it and also merge the master, then update the PR.
>
> In this case, also consider adding a space between the word and the opening parenthesis in these  _coordinates (x, y)_ and _size (w, h)_ and, probably, a space after comma.

Spaces are added.

-------------

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

From serb at openjdk.java.net  Wed Nov 11 01:34:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 11 Nov 2020 01:34:57 GMT
Subject: <Swing Dev> Integrated: 8211999: Window positioning bugs due to
 overlapping GraphicsDevice bounds (Windows/HiDPI)
In-Reply-To: <kkB8arYa2TYXREelYcOweRcdmT1mgr2CWgD-piP-CbM=.1537b8e9-7fcd-4029-8c8a-488a9d25bd43@github.com>
References: <kkB8arYa2TYXREelYcOweRcdmT1mgr2CWgD-piP-CbM=.1537b8e9-7fcd-4029-8c8a-488a9d25bd43@github.com>
Message-ID: <6xdyT0w04J4Q21Cy5LLc2gRnOjyjCHgvDzV6tn9g1KI=.c549d830-c144-4d8e-b4be-464ff836ced0@github.com>

On Sun, 27 Sep 2020 22:16:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Hello.
> Please review the fix for jdk.
> 
> Old review request:
> https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015991.html
> 
> 
> (Note: the fix use API available since Windows 8.1: WM_DPICHANGED, but it should be fine for
> Windows 7, because it does not support different DPI for different monitors)
> 
> ========================================================
> Short description:
>      In the multi-screen configurations when each screen have different DPI
>      we calculate the bounds of each monitor by these formulas:
> 
>          userSpaceBounds = deviceX / scaleX, deviceY / scaleY, deviceW / scaleX, deviceH / scaleY
>          devSpaceBounds  = userX * scaleX, userY * scaleY, userW * scaleX, userH * scaleY
> 
>   This formula makes the next configuration completely broken:
>     - The main screen on the left and 100% DPI
>     - The second screen on the right and 200% DPI
>   When we translate the bounds of the config from the device space to the user's space,
>      the bounds of both screen overlap in the user's space, because we use bounds of
>      the main screen as-is, and the X/Y of the second screen are divided by the scaleX/Y.
> 
>   Since the screens are overlapped we cannot be sure how to translate the user's space
>    coordinates to device space in the overlapped zone.
>   As a result => we use the wrong screen
>                    => got wrong coordinates in the device space
>                      => show top-level windows/popups/tooltips/menus/etc on the wrong screen
> 
>    The proposed solution for this bug is to change the formulas to these:
> 
>          userSpaceBounds = deviceX, deviceY, deviceW / scaleX, deviceH / scaleY
>          devSpaceBounds  = userX, userY, userW * scaleX, userH * scaleY
> 
>    In other words, we should not transform the X and Y coordinates of the screen(the top/left corner). This will
>    complicate the way of how we transform coordinates on the screen: user's <--> device spaces:
> 
>    Before the fix:
> 
>          userX = deviceX * scaleX;
>          deviceX = userX / scaleX;
> 
>    After the fix(only the part appeared on this screen should be scaled)
> 
>          userX = screenX + (deviceX - screenX) * scaleX
>          deviceX = screenX + (userX - screenX) / scaleX
> 
>    Note that these new formulas are applicable only for the coordinates on the screen such as X and Y.
>    If we will need to calculate the "size" such as W and H then the old formula should be used.
> 
>    The main changes for the problem above are:
>    - Skip transformation of X and Y of the screen bounds:
>        http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsConfig.cpp.sdiff.html
>    - A number of utility methods in java and native:
> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp.sdiff.html
> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java.sdiff.html
>    
> 
> ========================================================
> Long description:
>      Unfortunately, the changes above are not enough to fix the problem when different monitors
>      have different DPI, even if the bounds are *NOT* overlapped.
> 
>    - Currently, when we try to set the bounds of the window, we manually convert it in "java" to the
>      expected device position based on the current GraphicsConfiguration of the peer, and then
>      additionally, tweak it in native using the device scale stored in native code. Unfortunately
>      this two scale might not be in sync:(after we use the GraphicsConfiguration scale in peer,
>      the config might be changed and the tweak in native will use a different screen).
> 
>      As a fix I have moved all transformation from the peer to the native code, it will be executed
>      on the toolkit thread:
>      See the change in WWindowPeer.setBounds() and awt_Window.cpp AwtWindow::Reshape
>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java.sdiff.html
>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html
>      I think at some point we should delete all transformation in java, and apply it in the native code only.
>      
> 
>    - We had a special code that tracked the dragging of the window by the user from one screen to another,
>      and change the size of the window only when the user stops the drag operation. I've proposed to use standard Windows
>      machinery for that via WM_DPICHANGED: https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged
>      As a result, Windows will provide the "best" windows bounds on the new screen. Note that the code has a
>      workaround for https://bugs.openjdk.java.net/browse/JDK-8249164
>   
>    - I've also fix a variation of the bug previously fixed on macOS https://hg.openjdk.java.net/jdk/jdk/rev/b5cdba232fca
>      If we try to change the position of the window, and Windows ignores this request then we need to call all "callbacks" manually, otherwise, the shared code will use the bounds ignored by the Windows.
>      See the end of void AwtWindow::Reshape():
>      http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html
> 
>   -  Currently the HW componets such as Canvas scales everything based on such code:
> 
>           770 int AwtComponent::ScaleUpX(int x) {
>           4771     int screen = AwtWin32GraphicsDevice::DeviceIndexForWindow(GetHWnd());
>           4772     Devices::InstanceAccess devices;
>           4773     AwtWin32GraphicsDevice* device = devices->GetDevice(screen);
>           4774     return device == NULL ? x : device->ScaleUpX(x);
>           4775 }
> 
>   But it does not work well if the smaller part of the top-level window is located on one screen1(DPI=100) but
>      the biggest part is located on the screen2(DPI=200). If the Canvas is located on the "smaller" part of the
>      window, then the canvas will use DPI=100 for scale, but the whole window will use DPI=200
> 
>    As a fix, all HW components will try to use the scale factor of the top-level window, see AwtComponent::GetScreenImOn:
> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp.sdiff.html
> 
>    - Our current implementation does not take care of the case when the HW component bounds are updated when the top-level
>      the window is moved to another screen. For example, if the window does not use LayoutManager and the user sets some specific bounds for the Canvas. It is expected that the size of the Canvas will be updated when the window will be moved to another screen, but only HW top-level window and Swing components will update its size.
> 
>      As a fix I suggest to resync the bounds of the HW components if the GraphicsCOnfiguration is changed, see WComponentPeer.syncBounds():
>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java.sdiff.html
> 
>    - Note that the current fix is for Windows only, but the bug exists on Linux as well, so I have to create a kind of "ifdef" in the
>      Robot class, on windows we will use the new logic, on other platforms the old logic will be used.
> 
>    - The win32GraphicsDevice incorrectly sets the size of the full-screen window. It uses the display mode width/height(which are stored in pixels), but the bounds of the graphics config(which are stored in user's space) should be used.
> 
> ========================================================
> Some other bugs which are not fixed.
> 
>     - We have a lot of places where we mix(unintentionally) the coordinate in user's space and device space.
>       For example when we create the component we read x/y/width/height by the JNI(of course in a user's space)
>       but pass this coordinates as-is to the ::CreateWindowEx() which is incorrect. It works currently
>       because later we reshape the component to the correct bounds. Will fix it later.
> 
>     - When the frame is iconized and we try to save a new bounds for the future use, we store the
>       coordinates in the user's space to the field which use device space:
>       https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp#L664
> 
> Probably there are some other bugs and possibility to cleanups, but I would like to do that in separate issues.
>      
> 
> ========================================================
> The tests
>     - I have updated a couple of the tests to check multiple screens if possible, it helps to found some bugs
>       in my initial implementation
>     - Four new tests were added: SetComponentsBounds, SlowMotion, WindowSizeDifferentScreens, FullscreenWindowProps
>     - One test is moved from the closed repo(I made a small cleanup of it): ListMultipleSelectTest
> 
> ========================================================
> I have run jck, regression tests in different configurations, when the main screen is on the left, up, down,
> right, and have different DPI such as 100, 125, 150, and 200. No new issues were found so far.
> 
> The mach5 is also green.
> 
> PS: hope I did not forget some important information, will send it later if any.

This pull request has now been integrated.

Changeset: be635258
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/be635258
Stats:     1393 lines in 35 files changed: 962 ins; 276 del; 155 mod

8211999: Window positioning bugs due to overlapping GraphicsDevice bounds (Windows/HiDPI)

Reviewed-by: kizune, aivanov

-------------

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

From serb at openjdk.java.net  Wed Nov 11 01:42:02 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 11 Nov 2020 01:42:02 GMT
Subject: <Swing Dev> RFR: 7190978:
 javax/swing/JComponent/7154030/bug7154030.java fails on mac [v5]
In-Reply-To: <Z9Xf8y_iWvuzvKZBYZUWT7AzpnQ02WtbC_g-m5kD5rc=.366b5885-e905-4a99-8815-a96277a10f4a@github.com>
References: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
 <Z9Xf8y_iWvuzvKZBYZUWT7AzpnQ02WtbC_g-m5kD5rc=.366b5885-e905-4a99-8815-a96277a10f4a@github.com>
Message-ID: <dZG-5tfOFLYo5l2HMvhjZnOohqzEySLAbrJ3lCr9yiM=.50697e1e-ff57-47d2-ab68-1c720f9f914c@github.com>

On Mon, 9 Nov 2020 04:04:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Please review a test fix for an issue seen where robot image capture is wrong if screen scale factor is more, which could result in button or frame to move out of captured dimension of 300,300.
>> Fixed by setting uiScale=1 in the test which can still reproduce JDK-7154030.
>> Mach5 job has been run for several iterations in all platforms. Link in JBS.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment

Marked as reviewed by serb (Reviewer).

-------------

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

From serb at openjdk.java.net  Wed Nov 11 03:41:00 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 11 Nov 2020 03:41:00 GMT
Subject: <Swing Dev> RFR: 8255916: [macos]
 javax/swing/JInternalFrame/6647340/bug6647340.java timed out [v2]
In-Reply-To: <TC0CdiWFoRwRueGNc7dAnDLUKmlJ24eZrQxNR2SrG1g=.f8f82479-974f-4c50-bb5c-a4c15f11e5e5@github.com>
References: <6eov1ILcclPgMfsnI9-AuQrKZhJSSZvxNowYJhZHXwU=.9a602c3c-82a2-454d-beb5-2e26d81553a0@github.com>
 <TC0CdiWFoRwRueGNc7dAnDLUKmlJ24eZrQxNR2SrG1g=.f8f82479-974f-4c50-bb5c-a4c15f11e5e5@github.com>
Message-ID: <N3afNHTIQ_yAcpO8SCCNjNRAEMBuqvp-sYcNJTzKhKI=.544d8796-4060-44e9-8e08-1663cd71ad22@github.com>

On Tue, 10 Nov 2020 04:14:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> This test has failed in one of jdk nightly testing although it always passed locally. Made the test use robot delays, waitForIdle() to make it more stable and appropriate to run in slower mach5 systems and also remove the dependancy on ExtendedRobot.
>> Mach5 job has been run for several iterations in all platforms. Link in JBS.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Marked volatile

Marked as reviewed by serb (Reviewer).

-------------

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

From kizune at openjdk.java.net  Wed Nov 11 05:49:56 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 11 Nov 2020 05:49:56 GMT
Subject: <Swing Dev> RFR: 4907798: MEMORY LEAK:
 javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper [v2]
In-Reply-To: <hpReHvloMeA2NsD30i7f2f8vnviYs_GfSDbYVl1HbaM=.3318d083-26e0-435a-99f3-39fef44287cf@github.com>
References: <_EqDyPXhK4t_zt1Gcdx4dSGj0sKB7AdLC3T7F-Elhvg=.5470e2d2-dc1d-438d-8e0b-72f92ba0440d@github.com>
 <vuzUv2nWtu_rhjnC4DMszCcaqYgg-CdzlG0jXdW4UsM=.c8f1d94e-76e2-493a-bed8-1f50fbd0cb57@github.com>
 <YUnpi97y6AFwktYgFwK8S0lDD3yihYxzJZAqN-NmviI=.25a2954d-bc6b-43af-87c1-b2fe22f6efd6@github.com>
 <2kVgnn_UFxXNRs_LF49yBjzIC-XSdscyPd4cgwhHX6A=.66ef68f4-ec8c-4446-a578-d1b420522eda@github.com>
 <6Yshz_j4vL9vPCT_fbWebxmv6IGKKug7ZolO2GDVw0Q=.2d582579-25e9-4008-b073-1d608378d42c@github.com>
 <hpReHvloMeA2NsD30i7f2f8vnviYs_GfSDbYVl1HbaM=.3318d083-26e0-435a-99f3-39fef44287cf@github.com>
Message-ID: <unQvKBuDHnSWVQaHBoR4WkG8CuzWwd-fDo7bFL42L8U=.5fe5619b-e7a7-4704-a2a4-85515eadca52@github.com>

On Tue, 10 Nov 2020 02:48:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The code block here with uninstall is called if currently installed LAF is not derived from BasicLAF in which case we will not have this problem in the first place - the only place where we are setting menuInputMap variable is in this method down the line so it never gets initialized. And no, calling uninstall() unconditionally will not solve the problem because uninstall() does not change this value either.
>
> I guess that the uninstall() above is called when the L&F was basic(since BasicPopupMenuUI is used) and then changed for some reason, so when the method in the BasicPopupMenuUI.java will be called we will find that the current L&F is different and call "uninstall()", so this is my question: will the leak will exist in that case? I mean the code changed by the current fix will not be executed since we will exit after "uninstall()".

Well, yes it is called when it is changed from basic to some custom LaF not inherited by basic (i am not aware of any of such - but oh, well) and in this case once we remove MenuKeyboardHelper reference from the listener lists with uninstall() there will be no reference to this class from anywhere else - because it is referenced within the BasicPopupMenuUI and it is uninstalled. And if we have new LaF not inherited from basic LaF installed and instances of BasicPopupMenuUI are still referenced somewhere - well, yes, we will have a memory leak, but not because of this tiny variable - we will have much bigger problem on our hands.

-------------

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

From serb at openjdk.java.net  Wed Nov 11 06:02:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 11 Nov 2020 06:02:57 GMT
Subject: <Swing Dev> RFR: 4907798: MEMORY LEAK:
 javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper [v2]
In-Reply-To: <vm20g66Ynt7C2MawTcCEaGMnBiUVBAKO1Pej_BWxIio=.187e215a-fa5b-40d1-b843-be2fe77a277d@github.com>
References: <_EqDyPXhK4t_zt1Gcdx4dSGj0sKB7AdLC3T7F-Elhvg=.5470e2d2-dc1d-438d-8e0b-72f92ba0440d@github.com>
 <vm20g66Ynt7C2MawTcCEaGMnBiUVBAKO1Pej_BWxIio=.187e215a-fa5b-40d1-b843-be2fe77a277d@github.com>
Message-ID: <o4ZFQLiJcmvC3uQ3pRhw7DZwUgKQld0guCW8vy21Ihg=.4d676e5e-5daa-49f7-b8eb-a805e215f3a0@github.com>

On Mon, 9 Nov 2020 12:03:11 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> 4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test case made multiplatform and testing all the LaF's

Looks fine.

-------------

Marked as reviewed by serb (Reviewer).

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

From serb at openjdk.java.net  Wed Nov 11 06:22:05 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 11 Nov 2020 06:22:05 GMT
Subject: <Swing Dev> RFR: 4916923: In MetalRootPaneUI,
 MetalRootLayout does not correctly calculate minimumsize
Message-ID: <XfWa_6fqHjNYKcjjcPxOvXJe4YTTT52JS_agBhElZw4=.8b282884-1c8d-4ef3-b730-937709de8bbb@github.com>

The typo in the MetalRootLayout is fixed. The tpWidth was replaced by the tpHeight for height calculation.

-------------

Commit messages:
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/1155/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1155&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-4916923
  Stats: 126 lines in 2 files changed: 117 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1155.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1155/head:pull/1155

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

From psadhukhan at openjdk.java.net  Wed Nov 11 07:31:57 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 11 Nov 2020 07:31:57 GMT
Subject: <Swing Dev> RFR: 4907798: MEMORY LEAK:
 javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper [v2]
In-Reply-To: <vm20g66Ynt7C2MawTcCEaGMnBiUVBAKO1Pej_BWxIio=.187e215a-fa5b-40d1-b843-be2fe77a277d@github.com>
References: <_EqDyPXhK4t_zt1Gcdx4dSGj0sKB7AdLC3T7F-Elhvg=.5470e2d2-dc1d-438d-8e0b-72f92ba0440d@github.com>
 <vm20g66Ynt7C2MawTcCEaGMnBiUVBAKO1Pej_BWxIio=.187e215a-fa5b-40d1-b843-be2fe77a277d@github.com>
Message-ID: <DQ5hGdUoS3bAHC6IR36u4e8qVnSlr5Q0HmHJ0c2ZP8I=.88b9d116-a562-4a5d-834b-6e5421fb1924@github.com>

On Mon, 9 Nov 2020 12:03:11 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> 4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test case made multiplatform and testing all the LaF's

Looks ok. Just one minor comment in the test, since we are anyway using robot, it's better to use robot.delay() than Thread.sleep() unless if you have some compelling reason not to do that.

-------------

Marked as reviewed by psadhukhan (Reviewer).

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

From psadhukhan at openjdk.java.net  Wed Nov 11 08:06:09 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 11 Nov 2020 08:06:09 GMT
Subject: <Swing Dev> RFR: 8256019: JLabel HTML text does not support
 translucent text colors
Message-ID: <ZzkL8ZqJVoa-kuPtX_AY6LSHjHmSlaFCRubR4JcajVc=.6fbdb071-2141-4098-94c0-ba0fbf227668@github.com>

Issue is a JLabel with a translucent foreground color properly renders plain text, but with HTML text, the alpha component is discarded and the text is rendered using an opaque color.
As per https://www.w3schools.com/cssref/func_rgba.asp, CSS supports rgba() to support alpha and render translucent text color
but support for rgba() is not present in JDK html text rendering.

Added support for rgba() to render translucent text color.

-------------

Commit messages:
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/1158/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1158&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256019
  Stats: 251 lines in 5 files changed: 224 ins; 2 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1158.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1158/head:pull/1158

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

From psadhukhan at openjdk.java.net  Wed Nov 11 08:06:10 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 11 Nov 2020 08:06:10 GMT
Subject: <Swing Dev> RFR: 8256019: JLabel HTML text does not support
 translucent text colors
In-Reply-To: <ZzkL8ZqJVoa-kuPtX_AY6LSHjHmSlaFCRubR4JcajVc=.6fbdb071-2141-4098-94c0-ba0fbf227668@github.com>
References: <ZzkL8ZqJVoa-kuPtX_AY6LSHjHmSlaFCRubR4JcajVc=.6fbdb071-2141-4098-94c0-ba0fbf227668@github.com>
Message-ID: <2L1bXyzzioM0GGzPVTqfPGqi1G4NPlmgl9GtLz_rr58=.dace28e9-a6f0-4e9f-835b-9de7fc9f6902@github.com>

On Wed, 11 Nov 2020 08:00:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is a JLabel with a translucent foreground color properly renders plain text, but with HTML text, the alpha component is discarded and the text is rendered using an opaque color.
> As per https://www.w3schools.com/cssref/func_rgba.asp, CSS supports rgba() to support alpha and render translucent text color
> but support for rgba() is not present in JDK html text rendering.
> 
> Added support for rgba() to render translucent text color.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicHTML.java line 76:

> 74:             }
> 75:             col = new Color(Integer.parseInt(color[0]), Integer.parseInt(color[1]),
> 76:                             Integer.parseInt(color[2]), (int)(Float.parseFloat(color[3])*255));

It seems OceanTheme in Metal L&F supports only rgb

`ColorUIResource CONTROL_TEXT_COLOR =  new PrintColorUIResource(0x333333, Color.BLACK)`

so even when Color(r,g,b,a) is used, it creates rgb color and not rgba 
so alpha is obtained and passed separately.

-------------

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

From psadhukhan at openjdk.java.net  Wed Nov 11 08:09:59 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 11 Nov 2020 08:09:59 GMT
Subject: <Swing Dev> Integrated: 8255916: [macos]
 javax/swing/JInternalFrame/6647340/bug6647340.java timed out
In-Reply-To: <6eov1ILcclPgMfsnI9-AuQrKZhJSSZvxNowYJhZHXwU=.9a602c3c-82a2-454d-beb5-2e26d81553a0@github.com>
References: <6eov1ILcclPgMfsnI9-AuQrKZhJSSZvxNowYJhZHXwU=.9a602c3c-82a2-454d-beb5-2e26d81553a0@github.com>
Message-ID: <tpvl164Qo48P1jERM_juq-pNP2ZWrnvbgP7bWfEwFc0=.a74e1f44-5164-4919-996a-6849e6d0b16d@github.com>

On Mon, 9 Nov 2020 08:34:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test has failed in one of jdk nightly testing although it always passed locally. Made the test use robot delays, waitForIdle() to make it more stable and appropriate to run in slower mach5 systems and also remove the dependancy on ExtendedRobot.
> Mach5 job has been run for several iterations in all platforms. Link in JBS.

This pull request has now been integrated.

Changeset: 35284e46
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/35284e46
Stats:     66 lines in 1 file changed: 12 ins; 23 del; 31 mod

8255916: [macos] javax/swing/JInternalFrame/6647340/bug6647340.java timed out

Reviewed-by: serb

-------------

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

From psadhukhan at openjdk.java.net  Wed Nov 11 08:12:04 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 11 Nov 2020 08:12:04 GMT
Subject: <Swing Dev> Integrated: 7190978:
 javax/swing/JComponent/7154030/bug7154030.java fails on mac
In-Reply-To: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
References: <eu0LfkwrPv-VlTTPMDE_qMVd-eTt3EJQPWzVxSfP6aQ=.ac5a36ff-2561-4ad0-a0dc-252faed82888@github.com>
Message-ID: <_LncOQ9wRG-A55ugg4cRIhhdX-VG_spIuymS2HN_aZI=.f23fe1cb-0f93-4a75-b5ce-a1a62aba758d@github.com>

On Fri, 30 Oct 2020 11:42:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Please review a test fix for an issue seen where robot image capture is wrong if screen scale factor is more, which could result in button or frame to move out of captured dimension of 300,300.
> Fixed by setting uiScale=1 in the test which can still reproduce JDK-7154030.
> Mach5 job has been run for several iterations in all platforms. Link in JBS.

This pull request has now been integrated.

Changeset: 5181f9ce
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5181f9ce
Stats:     27 lines in 2 files changed: 18 ins; 1 del; 8 mod

7190978: javax/swing/JComponent/7154030/bug7154030.java fails on mac

Reviewed-by: serb

-------------

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

From kizune at openjdk.java.net  Wed Nov 11 11:47:01 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 11 Nov 2020 11:47:01 GMT
Subject: <Swing Dev> Integrated: 4907798: MEMORY LEAK:
 javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper
In-Reply-To: <_EqDyPXhK4t_zt1Gcdx4dSGj0sKB7AdLC3T7F-Elhvg=.5470e2d2-dc1d-438d-8e0b-72f92ba0440d@github.com>
References: <_EqDyPXhK4t_zt1Gcdx4dSGj0sKB7AdLC3T7F-Elhvg=.5470e2d2-dc1d-438d-8e0b-72f92ba0440d@github.com>
Message-ID: <hHoi3F_L4a9eGhkLWmZLqcCZXLukuuAHjL1ScHKRPKI=.e44b79fc-a4f2-445c-a0b4-ee8a42dd3292@github.com>

On Tue, 3 Nov 2020 10:32:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper

This pull request has now been integrated.

Changeset: ed615e3c
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ed615e3c
Stats:     216 lines in 3 files changed: 215 ins; 0 del; 1 mod

4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper

Reviewed-by: psadhukhan, serb

-------------

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

From psadhukhan at openjdk.java.net  Thu Nov 12 10:06:04 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 12 Nov 2020 10:06:04 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab text
 is barely legible
Message-ID: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>

On macOS 11 (bigsur) beta, using the Swing Aqua Look and Feel, the text of the selected JTabbedPane tab title text is just a light gray outline of white text on a white background. The macOS 11 design inverted from dark background / light text to light background / dark text, 
Proposed fix is to use dark color in light background so I used lightGray instead of "white" which is being used now, if we are on BigSur.

-------------

Commit messages:
 - 8251377: [macos11] JTabbedPane selected tab text is barely legible

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

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

From shurailine at openjdk.java.net  Thu Nov 12 18:01:59 2020
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Thu, 12 Nov 2020 18:01:59 GMT
Subject: <Swing Dev> RFR: 8253820: Save test images and dumps with
 timestamps from client sanity suite
In-Reply-To: <GaJ73A66-Ds8qi2T4pMaBBbouJTjLYa1MzvkRaOnj9c=.a4e93bf2-d9e8-442b-8bf7-38bc82df802d@github.com>
References: <iTPtNAUW1EaTfOMBuX4AJk4f1Q69sN79e7wg2y1p88E=.61f96894-4fb7-4b6a-a511-0b80769709a8@github.com>
 <GaJ73A66-Ds8qi2T4pMaBBbouJTjLYa1MzvkRaOnj9c=.a4e93bf2-d9e8-442b-8bf7-38bc82df802d@github.com>
Message-ID: <o3pJ599DrnTv24gVIWOn473k3S0aeC9yXQVjKjBvpI4=.42791b7b-12bc-446f-910f-3320192ec136@github.com>

On Tue, 10 Nov 2020 18:40:45 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

>> All screen images and xml dumps, if saved with help of the library methods, are saved by adding a timestamp and a LAF name. This is useful when there is some test re-execution, so all images are preserved and it is clear which image happened first.
>
> @amresh-sahu , can you take a look?

@mrserb Can you review?

-------------

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

From herrick at openjdk.java.net  Thu Nov 12 18:32:02 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 12 Nov 2020 18:32:02 GMT
Subject: <Swing Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <j3MK4sBx_azdu0U4AH9Ys6cO9i7225Sku6Qqzy5CiyU=.05465f80-fd5b-46fd-821f-e3d8f07b2527@github.com>

On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8189198: Add "forRemoval = true" to Applet APIs

preliminary changes for JDK-8189198 for evaluation

-------------

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

From herrick at openjdk.java.net  Thu Nov 12 18:32:02 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 12 Nov 2020 18:32:02 GMT
Subject: <Swing Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs
Message-ID: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>

JDK-8189198: Add "forRemoval = true" to Applet APIs

-------------

Commit messages:
 - Merge branch 'master' into JDK-8189198
 - JDK-8189198: Add "forRemoval = true" to Applet APIs
 - JDK-8189198: Add "forRemoval = true" to Applet APIs
 - JDK-8189198: Add "forRemoval = true" to Applet APIs

Changes: https://git.openjdk.java.net/jdk/pull/1127/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8189198
  Stats: 61 lines in 20 files changed: 10 ins; 0 del; 51 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1127/head:pull/1127

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

From kcr at openjdk.java.net  Thu Nov 12 19:22:01 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 12 Nov 2020 19:22:01 GMT
Subject: <Swing Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs
In-Reply-To: <j3MK4sBx_azdu0U4AH9Ys6cO9i7225Sku6Qqzy5CiyU=.05465f80-fd5b-46fd-821f-e3d8f07b2527@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <j3MK4sBx_azdu0U4AH9Ys6cO9i7225Sku6Qqzy5CiyU=.05465f80-fd5b-46fd-821f-e3d8f07b2527@github.com>
Message-ID: <GvP5LlxK0ocbdaxXbPDFAtX1v3sIZav1dHpSi54EEdg=.e2f907f8-d9e5-4910-be6a-6ec83f9d1ef9@github.com>

On Mon, 9 Nov 2020 13:57:32 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> preliminary changes for JDK-8189198 for evaluation

The following field, which is currently deprecated (not for removal) should probably also be marked as deprecated for removal::

javax.naming.Context:
    static final String APPLET

The CSR and JEP should be updated accordingly.

Also, what about the following?

javax.swing.text.html.parser.DTD
    Element applet

-------------

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

From iris at openjdk.java.net  Thu Nov 12 19:40:54 2020
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 12 Nov 2020 19:40:54 GMT
Subject: <Swing Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <1hu3mjRsBg1gnnWXUNl9TQ8PoPFjmGOaXkr6Vdd4mOo=.7ead6f18-6b34-42e4-adfb-756ada49eb61@github.com>

On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8189198: Add "forRemoval = true" to Applet APIs

Since all APIs in the java.applet package are deprecated "forRemoval = true", consider adding a brief deprecation note to java/applet/package-info.java too.

As an example, when all of the APIs in package java.rmi.activation were similarly deprecated in JDK 15, the following note was added: 

https://docs.oracle.com/en/java/javase/15/docs/api/java.rmi/java/rmi/activation/package-summary.html .

Thanks!
Iris

-------------

Marked as reviewed by iris (Reviewer).

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

From herrick at openjdk.java.net  Thu Nov 12 20:48:13 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 12 Nov 2020 20:48:13 GMT
Subject: <Swing Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v2]
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>

> JDK-8189198: Add "forRemoval = true" to Applet APIs

Andy Herrick has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - JDK-8189198: Add "forRemoval = true" to Applet APIs
 - Merge branch 'master' into JDK-8189198
 - Merge branch 'master' into JDK-8189198
 - JDK-8189198: Add "forRemoval = true" to Applet APIs
 - JDK-8189198: Add "forRemoval = true" to Applet APIs
 - JDK-8189198: Add "forRemoval = true" to Applet APIs

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1127/files
  - new: https://git.openjdk.java.net/jdk/pull/1127/files/a74deeee..d9850cd8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=00-01

  Stats: 7753 lines in 89 files changed: 4891 ins; 1603 del; 1259 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1127/head:pull/1127

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

From almatvee at openjdk.java.net  Thu Nov 12 23:52:56 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 12 Nov 2020 23:52:56 GMT
Subject: <Swing Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v2]
In-Reply-To: <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
Message-ID: <JVMXf2S7V5H6rariy6z8YkOGlh3YAtu2O6TWup0KeyY=.729335e8-4acc-4146-be1f-f5329cd98caf@github.com>

On Thu, 12 Nov 2020 20:48:13 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> Andy Herrick has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - Merge branch 'master' into JDK-8189198
>  - Merge branch 'master' into JDK-8189198
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs

Marked as reviewed by almatvee (Committer).

-------------

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

From serb at openjdk.java.net  Fri Nov 13 00:26:55 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 13 Nov 2020 00:26:55 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
Message-ID: <TkDAMSLggB3MeqJn59Lpxyq8jwMaN_IUsDicvjdVacE=.476a9201-3d74-4134-ae99-e05e43f188d9@github.com>

On Thu, 12 Nov 2020 09:58:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> On macOS 11 (bigsur) beta, using the Swing Aqua Look and Feel, the text of the selected JTabbedPane tab title text is just a light gray outline of white text on a white background. The macOS 11 design inverted from dark background / light text to light background / dark text, 
> Proposed fix is to use dark color in light background so I used lightGray instead of "white" which is being used now, if we are on BigSur.

src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java line 332:

> 330:         final ColorUIResource selectedTabTitleNormalColor =
> 331:                         System.getProperty("os.version").contains("10.16") ?
> 332:                                     new ColorUIResource(Color.lightGray) : white;

Can we read this information from the native? Probably it is already accessed by the SystemColor?

-------------

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

From kcr at openjdk.java.net  Fri Nov 13 00:27:58 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 13 Nov 2020 00:27:58 GMT
Subject: <Swing Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <Ycx4b7aaw5u8aiSS2NkJhWpuXdQjIRVbEn4DZautriM=.bbab7054-a46f-49c7-b8b7-ee0174aaa8b8@github.com>

On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8189198: Add "forRemoval = true" to Applet APIs

@andyherrick can you enter the `/csr needed` command? I would, but it needs to be done by either the author of the PR or a Reviewer.

-------------

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

From serb at openjdk.java.net  Fri Nov 13 02:05:53 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 13 Nov 2020 02:05:53 GMT
Subject: <Swing Dev> RFR: 8253820: Save test images and dumps with
 timestamps from client sanity suite
In-Reply-To: <iTPtNAUW1EaTfOMBuX4AJk4f1Q69sN79e7wg2y1p88E=.61f96894-4fb7-4b6a-a511-0b80769709a8@github.com>
References: <iTPtNAUW1EaTfOMBuX4AJk4f1Q69sN79e7wg2y1p88E=.61f96894-4fb7-4b6a-a511-0b80769709a8@github.com>
Message-ID: <ZXFmSKsIF_woMJ1hrhkZSMNFTzrpAA52YQfpS7o4_po=.76420135-4de4-4a39-97ca-e9a7d9ee6af5@github.com>

On Tue, 10 Nov 2020 18:39:58 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> All screen images and xml dumps, if saved with help of the library methods, are saved by adding a timestamp and a LAF name. This is useful when there is some test re-execution, so all images are preserved and it is clear which image happened first.

Marked as reviewed by serb (Reviewer).

-------------

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

From shurailine at openjdk.java.net  Fri Nov 13 02:30:55 2020
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Fri, 13 Nov 2020 02:30:55 GMT
Subject: <Swing Dev> Integrated: 8253820: Save test images and dumps with
 timestamps from client sanity suite
In-Reply-To: <iTPtNAUW1EaTfOMBuX4AJk4f1Q69sN79e7wg2y1p88E=.61f96894-4fb7-4b6a-a511-0b80769709a8@github.com>
References: <iTPtNAUW1EaTfOMBuX4AJk4f1Q69sN79e7wg2y1p88E=.61f96894-4fb7-4b6a-a511-0b80769709a8@github.com>
Message-ID: <3XR0xFVyzTtbH91e0NOx_ymlbaRSD_e71khoQqPslA8=.ac704145-5c5f-4bb8-8304-a2a915f84832@github.com>

On Tue, 10 Nov 2020 18:39:58 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> All screen images and xml dumps, if saved with help of the library methods, are saved by adding a timestamp and a LAF name. This is useful when there is some test re-execution, so all images are preserved and it is clear which image happened first.

This pull request has now been integrated.

Changeset: e32a4ea4
Author:    Alexandre Iline <shurailine at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e32a4ea4
Stats:     135 lines in 3 files changed: 40 ins; 49 del; 46 mod

8253820: Save test images and dumps with timestamps from client sanity suite

Reviewed-by: serb

-------------

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

From psadhukhan at openjdk.java.net  Fri Nov 13 02:41:59 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 13 Nov 2020 02:41:59 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <TkDAMSLggB3MeqJn59Lpxyq8jwMaN_IUsDicvjdVacE=.476a9201-3d74-4134-ae99-e05e43f188d9@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <TkDAMSLggB3MeqJn59Lpxyq8jwMaN_IUsDicvjdVacE=.476a9201-3d74-4134-ae99-e05e43f188d9@github.com>
Message-ID: <RpxiVJkGAb1PwHid0nv_AIVw6lC9LvvnSleOyLy_JHE=.d5181bdd-9ab5-47fc-a6a2-e6e32923f22d@github.com>

On Fri, 13 Nov 2020 00:24:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> On macOS 11 (bigsur) beta, using the Swing Aqua Look and Feel, the text of the selected JTabbedPane tab title text is just a light gray outline of white text on a white background. The macOS 11 design inverted from dark background / light text to light background / dark text, 
>> Proposed fix is to use dark color in light background so I used lightGray instead of "white" which is being used now, if we are on BigSur.
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java line 332:
> 
>> 330:         final ColorUIResource selectedTabTitleNormalColor =
>> 331:                         System.getProperty("os.version").contains("10.16") ?
>> 332:                                     new ColorUIResource(Color.lightGray) : white;
> 
> Can we read this information from the native? Probably it is already accessed by the SystemColor?

What "information" you want to be read from native?

-------------

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

From serb at openjdk.java.net  Fri Nov 13 07:21:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 13 Nov 2020 07:21:57 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <RpxiVJkGAb1PwHid0nv_AIVw6lC9LvvnSleOyLy_JHE=.d5181bdd-9ab5-47fc-a6a2-e6e32923f22d@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <TkDAMSLggB3MeqJn59Lpxyq8jwMaN_IUsDicvjdVacE=.476a9201-3d74-4134-ae99-e05e43f188d9@github.com>
 <RpxiVJkGAb1PwHid0nv_AIVw6lC9LvvnSleOyLy_JHE=.d5181bdd-9ab5-47fc-a6a2-e6e32923f22d@github.com>
Message-ID: <70CYeH1MC21ZFp74mRyEb7mdb6EPSzzR1SsTDsqHUmI=.ccf1128a-032e-4480-91fc-96b85dda2b43@github.com>

On Fri, 13 Nov 2020 02:39:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java line 332:
>> 
>>> 330:         final ColorUIResource selectedTabTitleNormalColor =
>>> 331:                         System.getProperty("os.version").contains("10.16") ?
>>> 332:                                     new ColorUIResource(Color.lightGray) : white;
>> 
>> Can we read this information from the native? Probably it is already accessed by the SystemColor?
>
> What "information" you want to be read from native?

The color instead of hardcoded "Color.lightGray"

-------------

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

From psadhukhan at openjdk.java.net  Fri Nov 13 09:31:56 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 13 Nov 2020 09:31:56 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <70CYeH1MC21ZFp74mRyEb7mdb6EPSzzR1SsTDsqHUmI=.ccf1128a-032e-4480-91fc-96b85dda2b43@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <TkDAMSLggB3MeqJn59Lpxyq8jwMaN_IUsDicvjdVacE=.476a9201-3d74-4134-ae99-e05e43f188d9@github.com>
 <RpxiVJkGAb1PwHid0nv_AIVw6lC9LvvnSleOyLy_JHE=.d5181bdd-9ab5-47fc-a6a2-e6e32923f22d@github.com>
 <70CYeH1MC21ZFp74mRyEb7mdb6EPSzzR1SsTDsqHUmI=.ccf1128a-032e-4480-91fc-96b85dda2b43@github.com>
Message-ID: <QU0SFKalgjYwGRfkgYSqgGuSwAtSHTokZ1sy8o7Sr5c=.428b7391-db0c-47ca-8039-191c636a190d@github.com>

On Fri, 13 Nov 2020 07:18:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> What "information" you want to be read from native?
>
> The color instead of hardcoded "Color.lightGray"

Well, even "white" was hardcoded till now...so I am not sure how can we read the color from native...do you have any idea?
Even CsystemColors.m has all the color hardcoded 
 sColors[java_awt_SystemColor_ACTIVE_CAPTION_TEXT] =        [NSColor blackColor];

-------------

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

From alanb at openjdk.java.net  Fri Nov 13 09:35:00 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 13 Nov 2020 09:35:00 GMT
Subject: <Swing Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v2]
In-Reply-To: <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
Message-ID: <3GqHzIv1CUYpxhZUBOoX5m2C2a-E9h_N77-MxvYKUQY=.3a9aa402-2e45-4d8c-a513-fb1e65157fbe@github.com>

On Thu, 12 Nov 2020 20:48:13 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> Andy Herrick has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - Merge branch 'master' into JDK-8189198
>  - Merge branch 'master' into JDK-8189198
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs

src/java.naming/share/classes/javax/naming/Context.java line 1087:

> 1085:     @Deprecated(since="16", forRemoval=true)
> 1086:     String APPLET = "java.naming.applet";
> 1087: };

Probably should be since="9" (the deprecation in JDK-8051422 pre-dates the enhanced deprecation work).

-------------

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

From psadhukhan at openjdk.java.net  Fri Nov 13 10:10:57 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 13 Nov 2020 10:10:57 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <QU0SFKalgjYwGRfkgYSqgGuSwAtSHTokZ1sy8o7Sr5c=.428b7391-db0c-47ca-8039-191c636a190d@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <TkDAMSLggB3MeqJn59Lpxyq8jwMaN_IUsDicvjdVacE=.476a9201-3d74-4134-ae99-e05e43f188d9@github.com>
 <RpxiVJkGAb1PwHid0nv_AIVw6lC9LvvnSleOyLy_JHE=.d5181bdd-9ab5-47fc-a6a2-e6e32923f22d@github.com>
 <70CYeH1MC21ZFp74mRyEb7mdb6EPSzzR1SsTDsqHUmI=.ccf1128a-032e-4480-91fc-96b85dda2b43@github.com>
 <QU0SFKalgjYwGRfkgYSqgGuSwAtSHTokZ1sy8o7Sr5c=.428b7391-db0c-47ca-8039-191c636a190d@github.com>
Message-ID: <HtwpZpn49M8DjWXvZEc1x1l8uzmGHXxmN0zmlusaCXQ=.7325eef1-d0fa-4789-af8e-9c439983a31d@github.com>

On Fri, 13 Nov 2020 09:29:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The color instead of hardcoded "Color.lightGray"
>
> Well, even "white" was hardcoded till now...so I am not sure how can we read the color from native...do you have any idea?
> Even CsystemColors.m has all the color hardcoded 
>  sColors[java_awt_SystemColor_ACTIVE_CAPTION_TEXT] =        [NSColor blackColor];

I dont think SystemColors are used in macos. I see in loadSystemColors() is commented in AquaLookAndFeel.java, therefore
loadNativeColors() defined in LWCToolkit.m is not used.

-------------

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

From herrick at openjdk.java.net  Fri Nov 13 15:05:15 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 13 Nov 2020 15:05:15 GMT
Subject: <Swing Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v3]
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <dLkIa4mWpx0hhXams7FvPoHbI5grhVHbsVnX6W_DphM=.9977bce3-93fe-459a-84de-feee4eccfb93@github.com>

> JDK-8189198: Add "forRemoval = true" to Applet APIs

Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8189198: Add "forRemoval = true" to Applet APIs

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1127/files
  - new: https://git.openjdk.java.net/jdk/pull/1127/files/d9850cd8..c6ea7714

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=01-02

  Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1127/head:pull/1127

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

From kcr at openjdk.java.net  Fri Nov 13 18:03:59 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 13 Nov 2020 18:03:59 GMT
Subject: <Swing Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v2]
In-Reply-To: <3GqHzIv1CUYpxhZUBOoX5m2C2a-E9h_N77-MxvYKUQY=.3a9aa402-2e45-4d8c-a513-fb1e65157fbe@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
 <3GqHzIv1CUYpxhZUBOoX5m2C2a-E9h_N77-MxvYKUQY=.3a9aa402-2e45-4d8c-a513-fb1e65157fbe@github.com>
Message-ID: <mot16WfbcRFgGyIX69OOOuf0ci4YY6zH1DcHnNVwM9g=.39da06f9-1bf8-47cf-9d99-a7b29b999ffa@github.com>

On Fri, 13 Nov 2020 09:31:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Andy Herrick has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>>  - Merge branch 'master' into JDK-8189198
>>  - Merge branch 'master' into JDK-8189198
>>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> src/java.naming/share/classes/javax/naming/Context.java line 1087:
> 
>> 1085:     @Deprecated(since="16", forRemoval=true)
>> 1086:     String APPLET = "java.naming.applet";
>> 1087: };
> 
> Probably should be since="9" (the deprecation in JDK-8051422 pre-dates the enhanced deprecation work).

Good point, since it was in fact deprecated in 9.

-------------

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

From kcr at openjdk.java.net  Fri Nov 13 18:23:02 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 13 Nov 2020 18:23:02 GMT
Subject: <Swing Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v3]
In-Reply-To: <dLkIa4mWpx0hhXams7FvPoHbI5grhVHbsVnX6W_DphM=.9977bce3-93fe-459a-84de-feee4eccfb93@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <dLkIa4mWpx0hhXams7FvPoHbI5grhVHbsVnX6W_DphM=.9977bce3-93fe-459a-84de-feee4eccfb93@github.com>
Message-ID: <2YW5WLSFQN87oSb4c-t2jsiflm8TmSyLH_ByIc9lq2U=.647a0363-4fea-4550-bb90-91603e5b842c@github.com>

On Fri, 13 Nov 2020 15:05:15 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8189198: Add "forRemoval = true" to Applet APIs

src/java.desktop/share/classes/java/applet/package-info.java line 40:

> 38:  * <p>
> 39:  * Deprecated.
> 40:  * This package has been deprecated and may be removed in a future version of the Java Platform.

That should be `@deprecated This package ...`. See [java/rmi/activation/package-info.java#L41](https://github.com/openjdk/jdk/blob/master/src/java.rmi/share/classes/java/rmi/activation/package-info.java#L41).

-------------

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

From herrick at openjdk.java.net  Fri Nov 13 18:22:59 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 13 Nov 2020 18:22:59 GMT
Subject: <Swing Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v2]
In-Reply-To: <mot16WfbcRFgGyIX69OOOuf0ci4YY6zH1DcHnNVwM9g=.39da06f9-1bf8-47cf-9d99-a7b29b999ffa@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
 <3GqHzIv1CUYpxhZUBOoX5m2C2a-E9h_N77-MxvYKUQY=.3a9aa402-2e45-4d8c-a513-fb1e65157fbe@github.com>
 <mot16WfbcRFgGyIX69OOOuf0ci4YY6zH1DcHnNVwM9g=.39da06f9-1bf8-47cf-9d99-a7b29b999ffa@github.com>
Message-ID: <gYa0bATGPUhfwxiRzpSFAjvkqohOGexGE2wtQOhzU2A=.0686d174-96f9-48c3-8bce-2222bdf38e3b@github.com>

On Fri, 13 Nov 2020 18:01:18 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> src/java.naming/share/classes/javax/naming/Context.java line 1087:
>> 
>>> 1085:     @Deprecated(since="16", forRemoval=true)
>>> 1086:     String APPLET = "java.naming.applet";
>>> 1087: };
>> 
>> Probably should be since="9" (the deprecation in JDK-8051422 pre-dates the enhanced deprecation work).
>
> Good point, since it was in fact deprecated in 9.

yes - changed to since="9" this morning

-------------

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

From serb at openjdk.java.net  Fri Nov 13 23:19:55 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 13 Nov 2020 23:19:55 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <HtwpZpn49M8DjWXvZEc1x1l8uzmGHXxmN0zmlusaCXQ=.7325eef1-d0fa-4789-af8e-9c439983a31d@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <TkDAMSLggB3MeqJn59Lpxyq8jwMaN_IUsDicvjdVacE=.476a9201-3d74-4134-ae99-e05e43f188d9@github.com>
 <RpxiVJkGAb1PwHid0nv_AIVw6lC9LvvnSleOyLy_JHE=.d5181bdd-9ab5-47fc-a6a2-e6e32923f22d@github.com>
 <70CYeH1MC21ZFp74mRyEb7mdb6EPSzzR1SsTDsqHUmI=.ccf1128a-032e-4480-91fc-96b85dda2b43@github.com>
 <QU0SFKalgjYwGRfkgYSqgGuSwAtSHTokZ1sy8o7Sr5c=.428b7391-db0c-47ca-8039-191c636a190d@github.com>
 <HtwpZpn49M8DjWXvZEc1x1l8uzmGHXxmN0zmlusaCXQ=.7325eef1-d0fa-4789-af8e-9c439983a31d@github.com>
Message-ID: <Ugh0XR0WSNuKblhm_mgwXCoe1GBO2cDSo1Vda1UdeXU=.42da1ed9-dfaa-475b-93ba-e60fba9e432e@github.com>

On Fri, 13 Nov 2020 10:07:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Well, even "white" was hardcoded till now...so I am not sure how can we read the color from native...do you have any idea?
>> Even CsystemColors.m has all the color hardcoded 
>>  sColors[java_awt_SystemColor_ACTIVE_CAPTION_TEXT] =        [NSColor blackColor];
>
> I dont think SystemColors are used in macos. I see in loadSystemColors() is commented in AquaLookAndFeel.java, therefore
> loadNativeColors() defined in LWCToolkit.m is not used.

> Well, even "white" was hardcoded till now...so I am not sure how can we read the color from native...do you have any idea?

The usage of the hardcoded white color was a bug, and it was found by the JDK-8251377. It would be good to investigate how to read the color of the text in the JTabbedPane(Or probably that color is used in some other components as well) from the native. 

> I dont think SystemColors are used in macos. I see in loadSystemColors() is commented in AquaLookAndFeel.java, therefore loadNativeColors() defined in LWCToolkit.m is not used.

SystemColors/LWCToolkit#loadNativeColors are for sure works on macOS it is responsible for the text selection color for example.

> Even CsystemColors.m has all the color hardcoded
> sColors[java_awt_SystemColor_ACTIVE_CAPTION_TEXT] = [NSColor blackColor];

All that hardcoded colors are bugs, but some of them use non-hardcoded values like: textColor/disabledControlTextColor/controlShadowColor/controlBackgroundColor/etc

-------------

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

From serb at openjdk.java.net  Fri Nov 13 23:29:59 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 13 Nov 2020 23:29:59 GMT
Subject: <Swing Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v3]
In-Reply-To: <2YW5WLSFQN87oSb4c-t2jsiflm8TmSyLH_ByIc9lq2U=.647a0363-4fea-4550-bb90-91603e5b842c@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <dLkIa4mWpx0hhXams7FvPoHbI5grhVHbsVnX6W_DphM=.9977bce3-93fe-459a-84de-feee4eccfb93@github.com>
 <2YW5WLSFQN87oSb4c-t2jsiflm8TmSyLH_ByIc9lq2U=.647a0363-4fea-4550-bb90-91603e5b842c@github.com>
Message-ID: <duVZxCWBKhVJrPXH4TcaSygW8i99rc9pLXcJe1bXC_s=.5bc72434-59bb-44d8-a957-9c391237397e@github.com>

On Fri, 13 Nov 2020 18:20:37 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> src/java.desktop/share/classes/java/applet/package-info.java line 40:
> 
>> 38:  * <p>
>> 39:  * Deprecated.
>> 40:  * This package has been deprecated and may be removed in a future version of the Java Platform.
> 
> That should be `@deprecated This package ...`. See [java/rmi/activation/package-info.java#L41](https://github.com/openjdk/jdk/blob/master/src/java.rmi/share/classes/java/rmi/activation/package-info.java#L41).

The deprecation description should point to the new API which might be used instead of the deprecated ones. So the text "deprecated without replacement" was intentionally added, it will be good to preserve it.

-------------

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

From herrick at openjdk.java.net  Sun Nov 15 19:09:07 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Sun, 15 Nov 2020 19:09:07 GMT
Subject: <Swing Dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v4]
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <n07B5X31Of1E-zQbdfwwtShOQ54zESY2s6oQQ8npBNU=.1beb38c9-1241-44cb-bf64-e64e0c9b3ea5@github.com>

> JDK-8189198: Add "forRemoval = true" to Applet APIs

Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8189198: Add "forRemoval = true" to Applet APIs

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1127/files
  - new: https://git.openjdk.java.net/jdk/pull/1127/files/c6ea7714..bc781bea

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=02-03

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

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

From serb at openjdk.java.net  Mon Nov 16 20:30:14 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 16 Nov 2020 20:30:14 GMT
Subject: <Swing Dev> RFR: 8256376: The
 javax/swing/JSpinner/SerializationTest.java fails on headful windows
In-Reply-To: <jNiaYQnte-DnWH82iiDZ7Y4tM8H0xZzEWG6fmTFGSag=.73011ef7-acfc-4eb3-b520-8573f9766686@github.com>
References: <jNiaYQnte-DnWH82iiDZ7Y4tM8H0xZzEWG6fmTFGSag=.73011ef7-acfc-4eb3-b520-8573f9766686@github.com>
Message-ID: <CmddBBlFevV-QO8XqiAMbHrMTzwcuGYR9x1iDFbTtIc=.08d39514-b0f7-43b1-a17c-12522e2dc48d@github.com>

On Mon, 16 Nov 2020 20:01:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The Windows L&F uses the windows specific class XPStyle as part of the border in the JSpinner. This class cannot be serialized and causes an exception during serialization. The root cause is that BasicSpinnerUI forgot to reset the border in uninstallUI() by the LookAndFeel.uninstallBorder(). I have found one more place where the LookAndFeel.installBorder() is not followed by the LookAndFeel.uninstallBorder() in the AquaSpinnerUI.

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

> 42:  * @summary Verifies that JSpinner can be serialized/deserialized correctly.
> 43:  * @run main/othervm SerializationTest
> 44:  * @run main/othervm -Djava.awt.headless=true SerializationTest

The test will cover the old use case(headless) and the headful as well.

-------------

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

From serb at openjdk.java.net  Mon Nov 16 20:30:13 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 16 Nov 2020 20:30:13 GMT
Subject: <Swing Dev> RFR: 8256376: The
 javax/swing/JSpinner/SerializationTest.java fails on headful windows
Message-ID: <jNiaYQnte-DnWH82iiDZ7Y4tM8H0xZzEWG6fmTFGSag=.73011ef7-acfc-4eb3-b520-8573f9766686@github.com>

The Windows L&F uses the windows specific class XPStyle as part of the border in the JSpinner. This class cannot be serialized and causes an exception during serialization. The root cause is that BasicSpinnerUI forgot to reset the border in uninstallUI() by the LookAndFeel.uninstallBorder(). I have found one more place where the LookAndFeel.installBorder() is not followed by the LookAndFeel.uninstallBorder() in the AquaSpinnerUI.

-------------

Commit messages:
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/1234/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1234&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256376
  Stats: 112 lines in 3 files changed: 88 ins; 4 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1234.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1234/head:pull/1234

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

From aivanov at openjdk.java.net  Mon Nov 16 23:09:04 2020
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 16 Nov 2020 23:09:04 GMT
Subject: <Swing Dev> RFR: 8256376: The
 javax/swing/JSpinner/SerializationTest.java fails on headful windows
In-Reply-To: <jNiaYQnte-DnWH82iiDZ7Y4tM8H0xZzEWG6fmTFGSag=.73011ef7-acfc-4eb3-b520-8573f9766686@github.com>
References: <jNiaYQnte-DnWH82iiDZ7Y4tM8H0xZzEWG6fmTFGSag=.73011ef7-acfc-4eb3-b520-8573f9766686@github.com>
Message-ID: <c6kCKkP3lKGliwQe15cHjGQ0KaLLw-4B1ufELlZUNS8=.7dab4b9e-2057-41ff-8d65-ae8963f1d632@github.com>

On Mon, 16 Nov 2020 20:01:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The Windows L&F uses the windows specific class XPStyle as part of the border in the JSpinner. This class cannot be serialized and causes an exception during serialization. The root cause is that BasicSpinnerUI forgot to reset the border in uninstallUI() by the LookAndFeel.uninstallBorder(). I have found one more place where the LookAndFeel.installBorder() is not followed by the LookAndFeel.uninstallBorder() in the AquaSpinnerUI.

Marked as reviewed by aivanov (Reviewer).

-------------

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

From serb at openjdk.java.net  Mon Nov 16 23:18:03 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 16 Nov 2020 23:18:03 GMT
Subject: <Swing Dev> Integrated: 8256376: The
 javax/swing/JSpinner/SerializationTest.java fails on headful windows
In-Reply-To: <jNiaYQnte-DnWH82iiDZ7Y4tM8H0xZzEWG6fmTFGSag=.73011ef7-acfc-4eb3-b520-8573f9766686@github.com>
References: <jNiaYQnte-DnWH82iiDZ7Y4tM8H0xZzEWG6fmTFGSag=.73011ef7-acfc-4eb3-b520-8573f9766686@github.com>
Message-ID: <5yLONZ4TmPD5paOlJA6R7tWNzRTHhQATxSsfbmcYI5g=.a5974d29-1b0d-4ed6-b5a0-592c0667a759@github.com>

On Mon, 16 Nov 2020 20:01:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The Windows L&F uses the windows specific class XPStyle as part of the border in the JSpinner. This class cannot be serialized and causes an exception during serialization. The root cause is that BasicSpinnerUI forgot to reset the border in uninstallUI() by the LookAndFeel.uninstallBorder(). I have found one more place where the LookAndFeel.installBorder() is not followed by the LookAndFeel.uninstallBorder() in the AquaSpinnerUI.

This pull request has now been integrated.

Changeset: 36dbe6f2
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/36dbe6f2
Stats:     112 lines in 3 files changed: 88 ins; 4 del; 20 mod

8256376: The javax/swing/JSpinner/SerializationTest.java fails on headful windows

Reviewed-by: aivanov

-------------

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

From psadhukhan at openjdk.java.net  Tue Nov 17 02:57:00 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 17 Nov 2020 02:57:00 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <Ugh0XR0WSNuKblhm_mgwXCoe1GBO2cDSo1Vda1UdeXU=.42da1ed9-dfaa-475b-93ba-e60fba9e432e@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <TkDAMSLggB3MeqJn59Lpxyq8jwMaN_IUsDicvjdVacE=.476a9201-3d74-4134-ae99-e05e43f188d9@github.com>
 <RpxiVJkGAb1PwHid0nv_AIVw6lC9LvvnSleOyLy_JHE=.d5181bdd-9ab5-47fc-a6a2-e6e32923f22d@github.com>
 <70CYeH1MC21ZFp74mRyEb7mdb6EPSzzR1SsTDsqHUmI=.ccf1128a-032e-4480-91fc-96b85dda2b43@github.com>
 <QU0SFKalgjYwGRfkgYSqgGuSwAtSHTokZ1sy8o7Sr5c=.428b7391-db0c-47ca-8039-191c636a190d@github.com>
 <HtwpZpn49M8DjWXvZEc1x1l8uzmGHXxmN0zmlusaCXQ=.7325eef1-d0fa-4789-af8e-9c439983a31d@github.com>
 <Ugh0XR0WSNuKblhm_mgwXCoe1GBO2cDSo1Vda1UdeXU=.42da1ed9-dfaa-475b-93ba-e60fba9e432e@github.com>
Message-ID: <5I_NTHoIDJ6ETqKyajgTPX5OLa-UZV1lQ1yb8qWd2H8=.0ba474a1-8aad-41d9-8fda-30bca1bb2deb@github.com>

On Fri, 13 Nov 2020 23:17:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> SystemColors/LWCToolkit#loadNativeColors are for sure works on macOS it is responsible for the text selection color for example.
I could not find how loadNativeColors() is used/works because only place I see it is called in macos is in loadSystemColors() which is commented out in AquaLookAndFeel.

-------------

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

From psadhukhan at openjdk.java.net  Tue Nov 17 10:00:20 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 17 Nov 2020 10:00:20 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible [v2]
In-Reply-To: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
Message-ID: <auz58G1Gwa422t7znOXoVb-LqscoopyoMZY3v4O7uRQ=.7e6df52c-5894-452e-9164-6d5486e71410@github.com>

> On macOS 11 (bigsur) beta, using the Swing Aqua Look and Feel, the text of the selected JTabbedPane tab title text is just a light gray outline of white text on a white background. The macOS 11 design inverted from dark background / light text to light background / dark text, 
> Proposed fix is to use dark color in light background so I used lightGray instead of "white" which is being used now, if we are on BigSur.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Use apple UI Element color

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1182/files
  - new: https://git.openjdk.java.net/jdk/pull/1182/files/c1cd3df5..f06c1d70

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1182&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1182&range=00-01

  Stats: 11 lines in 4 files changed: 7 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1182/head:pull/1182

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

From serb at openjdk.java.net  Tue Nov 17 20:30:03 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 17 Nov 2020 20:30:03 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible [v2]
In-Reply-To: <auz58G1Gwa422t7znOXoVb-LqscoopyoMZY3v4O7uRQ=.7e6df52c-5894-452e-9164-6d5486e71410@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <auz58G1Gwa422t7znOXoVb-LqscoopyoMZY3v4O7uRQ=.7e6df52c-5894-452e-9164-6d5486e71410@github.com>
Message-ID: <uAXB5KIZmfwdFyPBo9UZn2oa8g5YZujRGm1pBo07ViE=.775c1961-60fa-4edc-8dac-bbe887fa4c01@github.com>

On Tue, 17 Nov 2020 10:00:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> On macOS 11 (bigsur) beta, using the Swing Aqua Look and Feel, the text of the selected JTabbedPane tab title text is just a light gray outline of white text on a white background. The macOS 11 design inverted from dark background / light text to light background / dark text, 
>> Proposed fix is to use dark color in light background so I used lightGray instead of "white" which is being used now, if we are on BigSur.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use apple UI Element color

src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java line 216:

> 214:         0xFFC0C0C0, // secondarySelectedControlColor
> 215:         0xFF303030, // controlDarkShadowColor
> 216:         0xFFFFFFFF, // controlTextColor

As far as I understand the fix, It is a "alternateSelectedControlTextColor" not an "controlTextColor"

-------------

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

From serb at openjdk.java.net  Wed Nov 18 05:54:06 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 18 Nov 2020 05:54:06 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible [v2]
In-Reply-To: <uAXB5KIZmfwdFyPBo9UZn2oa8g5YZujRGm1pBo07ViE=.775c1961-60fa-4edc-8dac-bbe887fa4c01@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <auz58G1Gwa422t7znOXoVb-LqscoopyoMZY3v4O7uRQ=.7e6df52c-5894-452e-9164-6d5486e71410@github.com>
 <uAXB5KIZmfwdFyPBo9UZn2oa8g5YZujRGm1pBo07ViE=.775c1961-60fa-4edc-8dac-bbe887fa4c01@github.com>
Message-ID: <3FS6K7bsV6j0Q9OTslUtCCJhwZvtEhlzz-PNck0PMC8=.37cd05ad-7ba7-43ec-8820-cbd5371b9441@github.com>

On Tue, 17 Nov 2020 20:27:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use apple UI Element color
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java line 216:
> 
>> 214:         0xFFC0C0C0, // secondarySelectedControlColor
>> 215:         0xFF303030, // controlDarkShadowColor
>> 216:         0xFFFFFFFF, // controlTextColor
> 
> As far as I understand the fix, It is a "alternateSelectedControlTextColor" not an "controlTextColor"

BTW isn't it is the same color as java_awt_SystemColor_CONTROL_LT_HIGHLIGHT?

-------------

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

From psadhukhan at openjdk.java.net  Wed Nov 18 07:33:15 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 18 Nov 2020 07:33:15 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible [v3]
In-Reply-To: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
Message-ID: <W3LyrQpa1efeSII29gob4BNgsivsFGAFFr3Ph-tLyqc=.3c8d8c91-8006-4c3a-8073-c1df114d0ed9@github.com>

> On macOS 11 (bigsur) beta, using the Swing Aqua Look and Feel, the text of the selected JTabbedPane tab title text is just a light gray outline of white text on a white background. The macOS 11 design inverted from dark background / light text to light background / dark text, 
> Proposed fix is to use dark color in light background so I used lightGray instead of "white" which is being used now, if we are on BigSur.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Use proper apple UI Element color

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1182/files
  - new: https://git.openjdk.java.net/jdk/pull/1182/files/f06c1d70..ae1ba951

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1182&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1182&range=01-02

  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1182/head:pull/1182

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

From philip.race at oracle.com  Thu Nov 19 00:00:11 2020
From: philip.race at oracle.com (Philip Race)
Date: Wed, 18 Nov 2020 16:00:11 -0800
Subject: <Swing Dev> EA7 build of Project Lanai (Java 2D Metal rendering
 pipeline for macOS) is now posted
Message-ID: <5FB5B58B.4060000@oracle.com>

The EA 7 build of Project Lanai [1] was posted today at 
https://jdk.java.net/lanai/


    EA 7 Build 16-lanai+3-278 (2020/11/17)

Please do give it a try (-Dsun.java2d.metal=true) and let us know of issues.

EA 7 contains the following new bug fixes relative to EA 6

# 8256331: Lanai: DrawImage/IncorrectAlphaSurface2SW fails 
<https://bugs.openjdk.java.net/browse/JDK-8256331>
# 8252954: Lanai : 
java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java fails 
<https://bugs.openjdk.java.net/browse/JDK-8252954>
# 8252951: Lanai : java/awt/Robot/NonEmptyErrorStream.java fails 
<https://bugs.openjdk.java.net/browse/JDK-8252951>
# 8251033: Background texture is not visible when Alpha Composite is 
enabled <https://bugs.openjdk.java.net/browse/JDK-8251033>
# 8238533: [Lanai] Support texture paint where source is transparent 
<https://bugs.openjdk.java.net/browse/JDK-8238533>
# 8248129: Swingmark numbers are not good for Nimbus LAF 
<https://bugs.openjdk.java.net/browse/JDK-8248129>
# 8255212: J2DDemo : Rectangle in Texture paint disappears if we enable AA 
<https://bugs.openjdk.java.net/browse/JDK-8255212>
# 8255149: Lanai: DrawImage/IncorrectAlphaConversionBicubic.java failure 
<https://bugs.openjdk.java.net/browse/JDK-8255149>
# 8244718: J2DDemo - AlphaComposite tab - output colors are different with 
AA & non-AA <https://bugs.openjdk.java.net/browse/JDK-8244718>
# 8254881: Commit commandbuffer after draw happens through JNI 
<https://bugs.openjdk.java.net/browse/JDK-8254881>
# 8254879: Implement JNI path for Draw Poly 
<https://bugs.openjdk.java.net/browse/JDK-8254879>
# 8254869: Refactor check_previous_op usage in Mask Fill 
<https://bugs.openjdk.java.net/browse/JDK-8254869>
# 8244845: Lanai : J2DDemo - Clipping - Two parallel lines do not appear 
with AA Rendering <https://bugs.openjdk.java.net/browse/JDK-8244845>
# 8242924: Selection is not correct in Paint.TextureAnim 
<https://bugs.openjdk.java.net/browse/JDK-8242924>
# 8253994: J2DDemo: Buttcap, SquareCap color is different in 
AlphaComposite mode <https://bugs.openjdk.java.net/browse/JDK-8253994>
# 8252726: Lanai: IDEA Editor Rendering OGL vs Metal 1:2 
<https://bugs.openjdk.java.net/browse/JDK-8252726>
# 8254176: Lanai: MTLTexturePool optimize lookup of expired textures 
<https://bugs.openjdk.java.net/browse/JDK-8254176>

-phil.

[1] https://wiki.openjdk.java.net/display/lanai/Main
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/swing-dev/attachments/20201118/11de1f55/attachment.htm>

From serb at openjdk.java.net  Thu Nov 19 00:12:08 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 19 Nov 2020 00:12:08 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible [v3]
In-Reply-To: <W3LyrQpa1efeSII29gob4BNgsivsFGAFFr3Ph-tLyqc=.3c8d8c91-8006-4c3a-8073-c1df114d0ed9@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <W3LyrQpa1efeSII29gob4BNgsivsFGAFFr3Ph-tLyqc=.3c8d8c91-8006-4c3a-8073-c1df114d0ed9@github.com>
Message-ID: <z9lOVL2kpHiUxoSngW7uDl7ezh79X6kU9gmFUvFrz7M=.c7cbab02-2dcf-4114-97ba-05ae862de071@github.com>

On Wed, 18 Nov 2020 07:33:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> On macOS 11 (bigsur) beta, using the Swing Aqua Look and Feel, the text of the selected JTabbedPane tab title text is just a light gray outline of white text on a white background. The macOS 11 design inverted from dark background / light text to light background / dark text, 
>> Proposed fix is to use dark color in light background so I used lightGray instead of "white" which is being used now, if we are on BigSur.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use proper apple UI Element color

src/java.desktop/macosx/classes/com/apple/laf/AquaImageFactory.java line 500:

> 498:     }
> 499: 
> 500:     public static Color getControlTextColorUIResource() {

Should be "getSelectedControlColorUIResource"?

-------------

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

From psadhukhan at openjdk.java.net  Thu Nov 19 03:37:16 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 19 Nov 2020 03:37:16 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible [v4]
In-Reply-To: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
Message-ID: <uga0pLIn0PLnHu3mNMmVFk7Fkf8h1WY6lc0CNHMUlKY=.d6c779c5-8d0d-4263-a29b-f1232b780992@github.com>

> On macOS 11 (bigsur) beta, using the Swing Aqua Look and Feel, the text of the selected JTabbedPane tab title text is just a light gray outline of white text on a white background. The macOS 11 design inverted from dark background / light text to light background / dark text, 
> Proposed fix is to use dark color in light background so I used lightGray instead of "white" which is being used now, if we are on BigSur.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  name correction

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1182/files
  - new: https://git.openjdk.java.net/jdk/pull/1182/files/ae1ba951..0721a7af

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1182&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1182&range=02-03

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

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

From serb at openjdk.java.net  Thu Nov 19 08:32:04 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 19 Nov 2020 08:32:04 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
Message-ID: <1tz535gufWoNJ_jO-3KwmSsOfDHQN9Cqz-lvespNJpU=.bac9344b-310c-4af4-a623-0a29b2cc4eec@github.com>

On Thu, 12 Nov 2020 09:58:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> On macOS 11 (bigsur) beta, using the Swing Aqua Look and Feel, the text of the selected JTabbedPane tab title text is just a light gray outline of white text on a white background. The macOS 11 design inverted from dark background / light text to light background / dark text, 
> Proposed fix is to use dark color in light background so I used lightGray instead of "white" which is being used now, if we are on BigSur.

I have tried to test this change on macOS 10.15 and found some differences from the old behavior.
Before the fix:
 - The color was white for the selected tab while the window was focused, the same as in the native app(I have tested the tabs in the System preferences->Displays). So it worked fine.
 - The color was white for the selected tab while the window was unfocused(some other app is in focus). This is different from the native app, which uses black color. So this is a bug.

After the fix:
 - The color is "blurred white" or even "light blue" for the selected tab while the window is focused.
 - The color is "light blue" for the selected tab while the window is unfocused.

I think the new color used in the fix can be configured in the System Preferences -> General -> Highlight Color. If I select the green color then the tabs start to use green as a font color, which looks incorrect.

-------------

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

From psadhukhan at openjdk.java.net  Thu Nov 19 10:55:06 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 19 Nov 2020 10:55:06 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <1tz535gufWoNJ_jO-3KwmSsOfDHQN9Cqz-lvespNJpU=.bac9344b-310c-4af4-a623-0a29b2cc4eec@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <1tz535gufWoNJ_jO-3KwmSsOfDHQN9Cqz-lvespNJpU=.bac9344b-310c-4af4-a623-0a29b2cc4eec@github.com>
Message-ID: <5EU6riZkVpPCEF4g9XxJMtyfXiFEeV5A7Dd506uBn_w=.c3f68824-7756-4049-a3e2-52156bd8f014@github.com>

On Thu, 19 Nov 2020 08:29:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> On macOS 11 (bigsur) beta, using the Swing Aqua Look and Feel, the text of the selected JTabbedPane tab title text is just a light gray outline of white text on a white background. The macOS 11 design inverted from dark background / light text to light background / dark text, 
>> Proposed fix is to use dark color in light background so I used lightGray instead of "white" which is being used now, if we are on BigSur.
>
> I have tried to test this change on macOS 10.15 and found some differences from the old behavior.
> Before the fix:
>  - The color was white for the selected tab while the window was focused, the same as in the native app(I have tested the tabs in the System preferences->Displays). So it worked fine.
>  - The color was white for the selected tab while the window was unfocused(some other app is in focus). This is different from the native app, which uses black color. So this is a bug.
> 
> After the fix:
>  - The color is "blurred white" or even "light blue" for the selected tab while the window is focused.
>  - The color is "light blue" for the selected tab while the window is unfocused.
> 
> I think the new color used in the fix can be configured in the System Preferences -> General -> Highlight Color. If I select the green color then the tabs start to use green as a font color, which looks incorrect.

In Mohave, native System Preferences->Display tabs has 
white-text-on-blue-background when windows is focused
black-text-on-lightgray-background when window is unfocused

In macos11, it is always black-text-on-white-background whether focused/unfocused.

Current JDK tabpane always shows black background (when tab is selected) which is not configurable, at least I could not change it. Only thing i could change is the foreground text color. 
As was told to get color from native, I could see only "selectedTextBackground" and "selectedControlColor" works on both pre-macos11 and macos11 as it gives bluish text color which is legible on black (mohave) and white (macos11) background.

All other native-obtained-colors like selectedTextColor, selectedControlTextColor, controlTextColor, textBackgroundColor either gives black or white which is not legible on either pre-macos11 or macos11, so was not used.

-------------

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

From shade at openjdk.java.net  Thu Nov 19 14:37:08 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 19 Nov 2020 14:37:08 GMT
Subject: <Swing Dev> RFR: 4916923: In MetalRootPaneUI,
 MetalRootLayout does not correctly calculate minimumsize
In-Reply-To: <XfWa_6fqHjNYKcjjcPxOvXJe4YTTT52JS_agBhElZw4=.8b282884-1c8d-4ef3-b730-937709de8bbb@github.com>
References: <XfWa_6fqHjNYKcjjcPxOvXJe4YTTT52JS_agBhElZw4=.8b282884-1c8d-4ef3-b730-937709de8bbb@github.com>
Message-ID: <E8sEbqbILkRU-moI6W28qW5nlReuUzgerwjFSU56e14=.00804d96-cc78-4499-8842-5aa47e6937cb@github.com>

On Wed, 11 Nov 2020 06:12:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The typo in the MetalRootLayout is fixed. The tpWidth was replaced by the tpHeight for height calculation.

Seems like a simple bug. Looks good!

-------------

Marked as reviewed by shade (Reviewer).

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

From serb at openjdk.java.net  Thu Nov 19 18:59:06 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 19 Nov 2020 18:59:06 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <5EU6riZkVpPCEF4g9XxJMtyfXiFEeV5A7Dd506uBn_w=.c3f68824-7756-4049-a3e2-52156bd8f014@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <1tz535gufWoNJ_jO-3KwmSsOfDHQN9Cqz-lvespNJpU=.bac9344b-310c-4af4-a623-0a29b2cc4eec@github.com>
 <5EU6riZkVpPCEF4g9XxJMtyfXiFEeV5A7Dd506uBn_w=.c3f68824-7756-4049-a3e2-52156bd8f014@github.com>
Message-ID: <N7p7UzkSJr16E6KhZYLGLSlhVtXNNtBUkTz-USdjVzg=.825ed7ab-81e4-428e-b1ba-ec4646536393@github.com>

On Thu, 19 Nov 2020 10:51:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> I have tried to test this change on macOS 10.15 and found some differences from the old behavior.
>> Before the fix:
>>  - The color was white for the selected tab while the window was focused, the same as in the native app(I have tested the tabs in the System preferences->Displays). So it worked fine.
>>  - The color was white for the selected tab while the window was unfocused(some other app is in focus). This is different from the native app, which uses black color. So this is a bug.
>> 
>> After the fix:
>>  - The color is "blurred white" or even "light blue" for the selected tab while the window is focused.
>>  - The color is "light blue" for the selected tab while the window is unfocused.
>> 
>> I think the new color used in the fix can be configured in the System Preferences -> General -> Highlight Color. If I select the green color then the tabs start to use green as a font color, which looks incorrect.
>
> In Mohave, native System Preferences->Display tabs has 
> white-text-on-blue-background when windows is focused
> black-text-on-lightgray-background when window is unfocused
> 
> In macos11, it is always black-text-on-white-background whether focused/unfocused.
> 
> Current JDK tabpane always shows black background (when tab is selected) which is not configurable, at least I could not change it. Only thing i could change is the foreground text color. 
> As was told to get color from native, I could see only "selectedTextBackground" and "selectedControlColor" works on both pre-macos11 and macos11 as it gives bluish text color which is legible on black (mohave) and white (macos11) background.
> 
> All other native-obtained-colors like selectedTextColor, selectedControlTextColor, controlTextColor, textBackgroundColor either gives black or white which is not legible on either pre-macos11 or macos11, so was not used.

Then try to dig into it a little bit, probably a good reason to ask about the current font color in the tab at the Apple forum.

-------------

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

From serb at openjdk.java.net  Thu Nov 19 19:19:05 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 19 Nov 2020 19:19:05 GMT
Subject: <Swing Dev> RFR: 8256019: JLabel HTML text does not support
 translucent text colors
In-Reply-To: <ZzkL8ZqJVoa-kuPtX_AY6LSHjHmSlaFCRubR4JcajVc=.6fbdb071-2141-4098-94c0-ba0fbf227668@github.com>
References: <ZzkL8ZqJVoa-kuPtX_AY6LSHjHmSlaFCRubR4JcajVc=.6fbdb071-2141-4098-94c0-ba0fbf227668@github.com>
Message-ID: <wxFBtwc6OrSvzUzqvvsO0hoatY9j6ABGZ-5wGdQ3oY8=.f94b6769-25d0-416f-9159-a8e1c2a4bbc5@github.com>

On Wed, 11 Nov 2020 08:00:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is a JLabel with a translucent foreground color properly renders plain text, but with HTML text, the alpha component is discarded and the text is rendered using an opaque color.
> As per https://www.w3schools.com/cssref/func_rgba.asp, CSS supports rgba() to support alpha and render translucent text color
> but support for rgba() is not present in JDK html text rendering.
> 
> Added support for rgba() to render translucent text color.

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1403:

> 1401:           color = parseRGB(str);
> 1402:       } else if (str.startsWith("rgba(")) {
> 1403:           color = parseRGBA(str);

Probably we need to update the spec for StyleSheet.stringToColor()

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicHTML.java line 64:

> 62:     public static View createHTMLView(JComponent c, String html) {
> 63:         BasicEditorKit kit = getFactory();
> 64:         int beginIndex = html.indexOf("rgba(");

Don't we need to implement this parsing similarly to rgb()? somewhere inside kit.createDefaultDocument() or where we parse rgb()?

-------------

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

From serb at openjdk.java.net  Thu Nov 19 22:44:08 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 19 Nov 2020 22:44:08 GMT
Subject: <Swing Dev> Integrated: 4916923: In MetalRootPaneUI,
 MetalRootLayout does not correctly calculate minimumsize
In-Reply-To: <XfWa_6fqHjNYKcjjcPxOvXJe4YTTT52JS_agBhElZw4=.8b282884-1c8d-4ef3-b730-937709de8bbb@github.com>
References: <XfWa_6fqHjNYKcjjcPxOvXJe4YTTT52JS_agBhElZw4=.8b282884-1c8d-4ef3-b730-937709de8bbb@github.com>
Message-ID: <jIQLZCfDXO4ZTsI4SfREtPcE2oQo9iy6ipcN80DnWAs=.e983ffec-b5e4-447c-ac9b-444b36302f1b@github.com>

On Wed, 11 Nov 2020 06:12:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The typo in the MetalRootLayout is fixed. The tpWidth was replaced by the tpHeight for height calculation.

This pull request has now been integrated.

Changeset: c816464c
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c816464c
Stats:     126 lines in 2 files changed: 117 ins; 0 del; 9 mod

4916923: In MetalRootPaneUI, MetalRootLayout does not correctly calculate minimumsize

Reviewed-by: shade

-------------

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

From javalists at cbfiddle.com  Fri Nov 20 00:05:29 2020
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 19 Nov 2020 16:05:29 -0800
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <N7p7UzkSJr16E6KhZYLGLSlhVtXNNtBUkTz-USdjVzg=.825ed7ab-81e4-428e-b1ba-ec4646536393@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <1tz535gufWoNJ_jO-3KwmSsOfDHQN9Cqz-lvespNJpU=.bac9344b-310c-4af4-a623-0a29b2cc4eec@github.com>
 <5EU6riZkVpPCEF4g9XxJMtyfXiFEeV5A7Dd506uBn_w=.c3f68824-7756-4049-a3e2-52156bd8f014@github.com>
 <N7p7UzkSJr16E6KhZYLGLSlhVtXNNtBUkTz-USdjVzg=.825ed7ab-81e4-428e-b1ba-ec4646536393@github.com>
Message-ID: <F021DCB1-6081-4BB5-90D2-2DFE89B8EAA9@cbfiddle.com>

VAqua uses controlTextColor which has the value 255 255 255 217.

If you are seeing opaque white, then the alpha channel is getting lost somewhere.

  Alan


> On Nov 19, 2020, at 10:59 AM, Sergey Bylokhov <serb at openjdk.java.net> wrote:
> 
> On Thu, 19 Nov 2020 10:51:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org <mailto:psadhukhan at openjdk.org>> wrote:
> 
>>> I have tried to test this change on macOS 10.15 and found some differences from the old behavior.
>>> Before the fix:
>>> - The color was white for the selected tab while the window was focused, the same as in the native app(I have tested the tabs in the System preferences->Displays). So it worked fine.
>>> - The color was white for the selected tab while the window was unfocused(some other app is in focus). This is different from the native app, which uses black color. So this is a bug.
>>> 
>>> After the fix:
>>> - The color is "blurred white" or even "light blue" for the selected tab while the window is focused.
>>> - The color is "light blue" for the selected tab while the window is unfocused.
>>> 
>>> I think the new color used in the fix can be configured in the System Preferences -> General -> Highlight Color. If I select the green color then the tabs start to use green as a font color, which looks incorrect.
>> 
>> In Mohave, native System Preferences->Display tabs has 
>> white-text-on-blue-background when windows is focused
>> black-text-on-lightgray-background when window is unfocused
>> 
>> In macos11, it is always black-text-on-white-background whether focused/unfocused.
>> 
>> Current JDK tabpane always shows black background (when tab is selected) which is not configurable, at least I could not change it. Only thing i could change is the foreground text color. 
>> As was told to get color from native, I could see only "selectedTextBackground" and "selectedControlColor" works on both pre-macos11 and macos11 as it gives bluish text color which is legible on black (mohave) and white (macos11) background.
>> 
>> All other native-obtained-colors like selectedTextColor, selectedControlTextColor, controlTextColor, textBackgroundColor either gives black or white which is not legible on either pre-macos11 or macos11, so was not used.
> 
> Then try to dig into it a little bit, probably a good reason to ask about the current font color in the tab at the Apple forum.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/1182 <https://git.openjdk.java.net/jdk/pull/1182>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/swing-dev/attachments/20201119/e8e3b7c2/attachment-0001.htm>

From javalists at cbfiddle.com  Fri Nov 20 00:16:20 2020
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 19 Nov 2020 16:16:20 -0800
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <F021DCB1-6081-4BB5-90D2-2DFE89B8EAA9@cbfiddle.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <1tz535gufWoNJ_jO-3KwmSsOfDHQN9Cqz-lvespNJpU=.bac9344b-310c-4af4-a623-0a29b2cc4eec@github.com>
 <5EU6riZkVpPCEF4g9XxJMtyfXiFEeV5A7Dd506uBn_w=.c3f68824-7756-4049-a3e2-52156bd8f014@github.com>
 <N7p7UzkSJr16E6KhZYLGLSlhVtXNNtBUkTz-USdjVzg=.825ed7ab-81e4-428e-b1ba-ec4646536393@github.com>
 <F021DCB1-6081-4BB5-90D2-2DFE89B8EAA9@cbfiddle.com>
Message-ID: <07034857-95C5-4D21-B74E-09802C665ED1@cbfiddle.com>

When inactive, I use 0 0 0 192. As far as I can tell, this does not correspond to a named color.
It would be wrong to assume that Apple only uses named colors in their UIs.
The named colors are for application developers, not for Apple itself.

  Alan


> On Nov 19, 2020, at 4:05 PM, Alan Snyder <javalists at cbfiddle.com> wrote:
> 
> VAqua uses controlTextColor which has the value 255 255 255 217.
> 
> If you are seeing opaque white, then the alpha channel is getting lost somewhere.
> 
>   Alan
> 
> 
>> On Nov 19, 2020, at 10:59 AM, Sergey Bylokhov <serb at openjdk.java.net <mailto:serb at openjdk.java.net>> wrote:
>> 
>> On Thu, 19 Nov 2020 10:51:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org <mailto:psadhukhan at openjdk.org>> wrote:
>> 
>>>> I have tried to test this change on macOS 10.15 and found some differences from the old behavior.
>>>> Before the fix:
>>>> - The color was white for the selected tab while the window was focused, the same as in the native app(I have tested the tabs in the System preferences->Displays). So it worked fine.
>>>> - The color was white for the selected tab while the window was unfocused(some other app is in focus). This is different from the native app, which uses black color. So this is a bug.
>>>> 
>>>> After the fix:
>>>> - The color is "blurred white" or even "light blue" for the selected tab while the window is focused.
>>>> - The color is "light blue" for the selected tab while the window is unfocused.
>>>> 
>>>> I think the new color used in the fix can be configured in the System Preferences -> General -> Highlight Color. If I select the green color then the tabs start to use green as a font color, which looks incorrect.
>>> 
>>> In Mohave, native System Preferences->Display tabs has 
>>> white-text-on-blue-background when windows is focused
>>> black-text-on-lightgray-background when window is unfocused
>>> 
>>> In macos11, it is always black-text-on-white-background whether focused/unfocused.
>>> 
>>> Current JDK tabpane always shows black background (when tab is selected) which is not configurable, at least I could not change it. Only thing i could change is the foreground text color. 
>>> As was told to get color from native, I could see only "selectedTextBackground" and "selectedControlColor" works on both pre-macos11 and macos11 as it gives bluish text color which is legible on black (mohave) and white (macos11) background.
>>> 
>>> All other native-obtained-colors like selectedTextColor, selectedControlTextColor, controlTextColor, textBackgroundColor either gives black or white which is not legible on either pre-macos11 or macos11, so was not used.
>> 
>> Then try to dig into it a little bit, probably a good reason to ask about the current font color in the tab at the Apple forum.
>> 
>> -------------
>> 
>> PR: https://git.openjdk.java.net/jdk/pull/1182 <https://git.openjdk.java.net/jdk/pull/1182>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/swing-dev/attachments/20201119/4b40c171/attachment.htm>

From psadhukhan at openjdk.java.net  Fri Nov 20 03:41:21 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 20 Nov 2020 03:41:21 GMT
Subject: <Swing Dev> RFR: 8256019: JLabel HTML text does not support
 translucent text colors [v2]
In-Reply-To: <ZzkL8ZqJVoa-kuPtX_AY6LSHjHmSlaFCRubR4JcajVc=.6fbdb071-2141-4098-94c0-ba0fbf227668@github.com>
References: <ZzkL8ZqJVoa-kuPtX_AY6LSHjHmSlaFCRubR4JcajVc=.6fbdb071-2141-4098-94c0-ba0fbf227668@github.com>
Message-ID: <ChMGt-cbnMnmg3ADvh98fWqANTVy_bKPz-N1big5quY=.d821f4f9-c6d8-4492-bf7d-0855b0bc0b95@github.com>

> Issue is a JLabel with a translucent foreground color properly renders plain text, but with HTML text, the alpha component is discarded and the text is rendered using an opaque color.
> As per https://www.w3schools.com/cssref/func_rgba.asp, CSS supports rgba() to support alpha and render translucent text color
> but support for rgba() is not present in JDK html text rendering.
> 
> Added support for rgba() to render translucent text color.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Update spec

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1158/files
  - new: https://git.openjdk.java.net/jdk/pull/1158/files/769eb298..bf0c84ae

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1158&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1158&range=00-01

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

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

From psadhukhan at openjdk.java.net  Fri Nov 20 03:45:04 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 20 Nov 2020 03:45:04 GMT
Subject: <Swing Dev> RFR: 8256019: JLabel HTML text does not support
 translucent text colors [v2]
In-Reply-To: <wxFBtwc6OrSvzUzqvvsO0hoatY9j6ABGZ-5wGdQ3oY8=.f94b6769-25d0-416f-9159-a8e1c2a4bbc5@github.com>
References: <ZzkL8ZqJVoa-kuPtX_AY6LSHjHmSlaFCRubR4JcajVc=.6fbdb071-2141-4098-94c0-ba0fbf227668@github.com>
 <wxFBtwc6OrSvzUzqvvsO0hoatY9j6ABGZ-5wGdQ3oY8=.f94b6769-25d0-416f-9159-a8e1c2a4bbc5@github.com>
Message-ID: <tl9I69hvG58f85TSGF7S6B8mDDiMGbIfDIwwzJ54D6Q=.09004239-b544-4212-aae1-a9bb19cc4890@github.com>

On Thu, 19 Nov 2020 19:16:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update spec
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicHTML.java line 64:
> 
>> 62:     public static View createHTMLView(JComponent c, String html) {
>> 63:         BasicEditorKit kit = getFactory();
>> 64:         int beginIndex = html.indexOf("rgba(");
> 
> Don't we need to implement this parsing similarly to rgb()? somewhere inside kit.createDefaultDocument() or where we parse rgb()?

The problem is the alpha color not being present in c.getForeground() so we need to parse alpha here to pass the value to displayPropertiesToCSS(). I have already mentioned it below.

-------------

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

From psadhukhan at openjdk.java.net  Fri Nov 20 03:45:06 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 20 Nov 2020 03:45:06 GMT
Subject: <Swing Dev> RFR: 8256019: JLabel HTML text does not support
 translucent text colors [v2]
In-Reply-To: <2L1bXyzzioM0GGzPVTqfPGqi1G4NPlmgl9GtLz_rr58=.dace28e9-a6f0-4e9f-835b-9de7fc9f6902@github.com>
References: <ZzkL8ZqJVoa-kuPtX_AY6LSHjHmSlaFCRubR4JcajVc=.6fbdb071-2141-4098-94c0-ba0fbf227668@github.com>
 <2L1bXyzzioM0GGzPVTqfPGqi1G4NPlmgl9GtLz_rr58=.dace28e9-a6f0-4e9f-835b-9de7fc9f6902@github.com>
Message-ID: <5wfWwCD-9PxMH5yYE23IJwI_wrb1dlyaEY_Hy6HWOFE=.0396d9e4-01ba-4c9a-aa77-6e192a679c91@github.com>

On Wed, 11 Nov 2020 08:03:08 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update spec
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicHTML.java line 76:
> 
>> 74:             }
>> 75:             col = new Color(Integer.parseInt(color[0]), Integer.parseInt(color[1]),
>> 76:                             Integer.parseInt(color[2]), (int)(Float.parseFloat(color[3])*255));
> 
> It seems OceanTheme in Metal L&F supports only rgb
> 
> `ColorUIResource CONTROL_TEXT_COLOR =  new PrintColorUIResource(0x333333, Color.BLACK)`
> 
> so even when Color(r,g,b,a) is used, it creates rgb color and not rgba 
> so alpha is obtained and passed separately.

I have already mentioned it here.

-------------

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

From javalists at cbfiddle.com  Fri Nov 20 14:56:52 2020
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 20 Nov 2020 06:56:52 -0800
Subject: <Swing Dev> taskbar icon badge issue
In-Reply-To: <29bc2d5c-5782-7dbd-5909-364d9629fca1@oracle.com>
References: <BA52494A-563C-4AF1-B0C2-5512E638266A@cbfiddle.com>
 <18ffee46-69a5-752a-29d0-089573f82c22@oracle.com>
 <A8A3CBCA-1AD7-49CE-ADB9-66C7E25E9716@cbfiddle.com>
 <29bc2d5c-5782-7dbd-5909-364d9629fca1@oracle.com>
Message-ID: <B682783D-684D-4622-83BD-52DA89752B10@cbfiddle.com>

I don?t believe there is any bug here. Setting a badge on the app icon requires a permission that is controlled using the Notifications system preference.
Using JDK 12, I can allow or prevent the test program from setting a badge by enabling or disabling notifications from ?java?.
See linked image [1].

I hope the ?fix? can be reverted in JDK 16.

  Alan

[1] https://cr.openjdk.java.net/~alans/8230869/Notifications.png



> On Oct 26, 2020, at 2:29 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> On 26.10.2020 14:16, Alan Snyder wrote:
>>> I have tested the "DockBadge.java" from the https://bugs.openjdk.java.net/browse/JDK-8230869 on macOS 10.15.7 + JDK12 and it does not work =(
>> That seems odd. Are you saying that no dock icons ever show a badge on 10.15.7?
> 
> yes, in some updates it works, in another, it does not.
> 
>> On my 10.15.6, I see dock badges on System Preferences, App Store, and Feedback Assistant. How are they accomplishing this? Do Apple apps use a private API> I?m suspicious that the problem is in the JDK, in which case it should be fixable.
> 
> The Apple standard/public API for dock badges stop working when using with JRS.
> 
> -- 
> Best regards, Sergey.
> 


From serb at openjdk.java.net  Sun Nov 22 09:20:36 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 22 Nov 2020 09:20:36 GMT
Subject: <Swing Dev> RFR: 8256713: SwingSet2 : Slider leaves tracks in
 uiScale=2
Message-ID: <Ro0F4RB7lNhKqDM9QX_AoLYqmWuKPh0jHDea63h8Y8g=.e9dfb175-201a-4cdd-9a4a-163a6adab74c@github.com>

The problem became visible, when we draw a border across the component using drawLine, and expected that fillRect will clear a border of the component. This is incorrect because in the case of the scaled graphics(retina) some part of the line can be placed outside of the bounds of the rectangle. See additional information here:
https://bugs.openjdk.java.net/browse/JDK-8011764

This bug has occurred when the old default metal theme is used(DefaultMetalTheme) or thems based on it(Custom themes in the SwingSet2).

The fix applies the clip before the rendering so the paint method will not touch pixels outside the component.

As a fix, we could try to draw the lines using subpixel coordinates, but that code is expected to work using Graphics object(unlike current default metal theme: Ocean)  which uses the only int as a coordinate, not a Graphics2D

To make rendering a little bit better I tried antialiasing but it does not produce a better result, so did not use it in the fix.

-------------

Commit messages:
 - Update PaintThumbSize.java
 - Create PaintThumbSize.java
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/1373/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1373&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256713
  Stats: 192 lines in 3 files changed: 177 ins; 2 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1373.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1373/head:pull/1373

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

From jdv at openjdk.java.net  Mon Nov 23 05:37:55 2020
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 23 Nov 2020 05:37:55 GMT
Subject: <Swing Dev> RFR: 8256713: SwingSet2 : Slider leaves tracks in
 uiScale=2
In-Reply-To: <Ro0F4RB7lNhKqDM9QX_AoLYqmWuKPh0jHDea63h8Y8g=.e9dfb175-201a-4cdd-9a4a-163a6adab74c@github.com>
References: <Ro0F4RB7lNhKqDM9QX_AoLYqmWuKPh0jHDea63h8Y8g=.e9dfb175-201a-4cdd-9a4a-163a6adab74c@github.com>
Message-ID: <kmLN3xWu2xUhq10w17_4_eAiSSO5UkCD_UFE0rBG054=.1d168280-8436-492f-9c31-77591bf75b74@github.com>

On Sun, 22 Nov 2020 08:59:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The problem became visible, when we draw a border across the component using drawLine, and expected that fillRect will clear a border of the component. This is incorrect because in the case of the scaled graphics(retina) some part of the line can be placed outside of the bounds of the rectangle. See additional information here:
> https://bugs.openjdk.java.net/browse/JDK-8011764
> 
> This bug has occurred when the old default metal theme is used(DefaultMetalTheme) or thems based on it(Custom themes in the SwingSet2).
> 
> The fix applies the clip before the rendering so the paint method will not touch pixels outside the component.
> 
> As a fix, we could try to draw the lines using subpixel coordinates, but that code is expected to work using Graphics object(unlike current default metal theme: Ocean)  which uses the only int as a coordinate, not a Graphics2D
> 
> To make rendering a little bit better I tried antialiasing but it does not produce a better result, so did not use it in the fix.

Marked as reviewed by jdv (Reviewer).

-------------

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

From serb at openjdk.java.net  Mon Nov 23 05:55:56 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 23 Nov 2020 05:55:56 GMT
Subject: <Swing Dev> RFR: 8256019: JLabel HTML text does not support
 translucent text colors [v2]
In-Reply-To: <5wfWwCD-9PxMH5yYE23IJwI_wrb1dlyaEY_Hy6HWOFE=.0396d9e4-01ba-4c9a-aa77-6e192a679c91@github.com>
References: <ZzkL8ZqJVoa-kuPtX_AY6LSHjHmSlaFCRubR4JcajVc=.6fbdb071-2141-4098-94c0-ba0fbf227668@github.com>
 <2L1bXyzzioM0GGzPVTqfPGqi1G4NPlmgl9GtLz_rr58=.dace28e9-a6f0-4e9f-835b-9de7fc9f6902@github.com>
 <5wfWwCD-9PxMH5yYE23IJwI_wrb1dlyaEY_Hy6HWOFE=.0396d9e4-01ba-4c9a-aa77-6e192a679c91@github.com>
Message-ID: <IsRpGkC07Vl1ucXriID_LY3JlpIH07BRk3bt79YdXIk=.158e4cad-2abb-467b-a2ff-983f60c28d46@github.com>

On Fri, 20 Nov 2020 03:42:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicHTML.java line 76:
>> 
>>> 74:             }
>>> 75:             col = new Color(Integer.parseInt(color[0]), Integer.parseInt(color[1]),
>>> 76:                             Integer.parseInt(color[2]), (int)(Float.parseFloat(color[3])*255));
>> 
>> It seems OceanTheme in Metal L&F supports only rgb
>> 
>> `ColorUIResource CONTROL_TEXT_COLOR =  new PrintColorUIResource(0x333333, Color.BLACK)`
>> 
>> so even when Color(r,g,b,a) is used, it creates rgb color and not rgba 
>> so alpha is obtained and passed separately.
>
> I have already mentioned it here.

But in what place we parse "rgb(...)"? it does not seem mentioned in this method and does not depend on the c.getForeground()?

-------------

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

From psadhukhan at openjdk.java.net  Mon Nov 23 07:39:58 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 23 Nov 2020 07:39:58 GMT
Subject: <Swing Dev> RFR: 8256019: JLabel HTML text does not support
 translucent text colors [v2]
In-Reply-To: <IsRpGkC07Vl1ucXriID_LY3JlpIH07BRk3bt79YdXIk=.158e4cad-2abb-467b-a2ff-983f60c28d46@github.com>
References: <ZzkL8ZqJVoa-kuPtX_AY6LSHjHmSlaFCRubR4JcajVc=.6fbdb071-2141-4098-94c0-ba0fbf227668@github.com>
 <2L1bXyzzioM0GGzPVTqfPGqi1G4NPlmgl9GtLz_rr58=.dace28e9-a6f0-4e9f-835b-9de7fc9f6902@github.com>
 <5wfWwCD-9PxMH5yYE23IJwI_wrb1dlyaEY_Hy6HWOFE=.0396d9e4-01ba-4c9a-aa77-6e192a679c91@github.com>
 <IsRpGkC07Vl1ucXriID_LY3JlpIH07BRk3bt79YdXIk=.158e4cad-2abb-467b-a2ff-983f60c28d46@github.com>
Message-ID: <mZ55u8ijKPPeFNjlJgie7wPyFWuUlLTGJLrkwLKBVc4=.16febd82-1671-4c54-8f51-7c57a74f0c0f@github.com>

On Mon, 23 Nov 2020 05:52:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I have already mentioned it here.
>
> But in what place we parse "rgb(...)"? it does not seem mentioned in this method and does not depend on the c.getForeground()?

It is parsed in Parser.java#parseAttributeValue() which is being called from this method via kit.read().
It also parses rgba() and store it but JDK does not seem to support rgba() in CSS.java and also SwingUtilities2.displayPropertiesToCSS() which is being called prior to html parsing so alpha needs to be parsed separately.

-------------

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

From psadhukhan at openjdk.java.net  Mon Nov 23 09:21:00 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 23 Nov 2020 09:21:00 GMT
Subject: <Swing Dev> RFR: 8256713: SwingSet2 : Slider leaves tracks in
 uiScale=2
In-Reply-To: <Ro0F4RB7lNhKqDM9QX_AoLYqmWuKPh0jHDea63h8Y8g=.e9dfb175-201a-4cdd-9a4a-163a6adab74c@github.com>
References: <Ro0F4RB7lNhKqDM9QX_AoLYqmWuKPh0jHDea63h8Y8g=.e9dfb175-201a-4cdd-9a4a-163a6adab74c@github.com>
Message-ID: <ZtLWfaL-yFU-XlouVq2p4WCOjHVNzTBTNj2abE9ayUA=.76442042-c43d-4d8f-944a-74ee4adf1c74@github.com>

On Sun, 22 Nov 2020 08:59:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The problem became visible, when we draw a border across the component using drawLine, and expected that fillRect will clear a border of the component. This is incorrect because in the case of the scaled graphics(retina) some part of the line can be placed outside of the bounds of the rectangle. See additional information here:
> https://bugs.openjdk.java.net/browse/JDK-8011764
> 
> This bug has occurred when the old default metal theme is used(DefaultMetalTheme) or thems based on it(Custom themes in the SwingSet2).
> 
> The fix applies the clip before the rendering so the paint method will not touch pixels outside the component.
> 
> As a fix, we could try to draw the lines using subpixel coordinates, but that code is expected to work using Graphics object(unlike current default metal theme: Ocean)  which uses the only int as a coordinate, not a Graphics2D
> 
> To make rendering a little bit better I tried antialiasing but it does not produce a better result, so did not use it in the fix.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSliderUI.java line 1618:

> 1616:             }
> 1617:         }
> 1618:         g.setClip(clip);

Since it is normally seen in Metal L&F, shouldn't we do the clip setting in MetalSliderUI.paintThumb() instead?
If we are doing it in BasicSliderUI, can you please explain why are we not seeing it in other L&Fs like nimbus or motif?

-------------

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

From serb at openjdk.java.net  Tue Nov 24 00:11:59 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 24 Nov 2020 00:11:59 GMT
Subject: <Swing Dev> RFR: 8256713: SwingSet2 : Slider leaves tracks in
 uiScale=2
In-Reply-To: <ZtLWfaL-yFU-XlouVq2p4WCOjHVNzTBTNj2abE9ayUA=.76442042-c43d-4d8f-944a-74ee4adf1c74@github.com>
References: <Ro0F4RB7lNhKqDM9QX_AoLYqmWuKPh0jHDea63h8Y8g=.e9dfb175-201a-4cdd-9a4a-163a6adab74c@github.com>
 <ZtLWfaL-yFU-XlouVq2p4WCOjHVNzTBTNj2abE9ayUA=.76442042-c43d-4d8f-944a-74ee4adf1c74@github.com>
Message-ID: <Xp5GRYQicBWjgXzul0QHTpvw_bRCpY08IODCRrNa4dY=.a1afc135-7d61-4bab-9620-28a72705448a@github.com>

On Mon, 23 Nov 2020 09:18:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The problem became visible, when we draw a border across the component using drawLine, and expected that fillRect will clear a border of the component. This is incorrect because in the case of the scaled graphics(retina) some part of the line can be placed outside of the bounds of the rectangle. See additional information here:
>> https://bugs.openjdk.java.net/browse/JDK-8011764
>> 
>> This bug has occurred when the old default metal theme is used(DefaultMetalTheme) or thems based on it(Custom themes in the SwingSet2).
>> 
>> The fix applies the clip before the rendering so the paint method will not touch pixels outside the component.
>> 
>> As a fix, we could try to draw the lines using subpixel coordinates, but that code is expected to work using Graphics object(unlike current default metal theme: Ocean)  which uses the only int as a coordinate, not a Graphics2D
>> 
>> To make rendering a little bit better I tried antialiasing but it does not produce a better result, so did not use it in the fix.
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSliderUI.java line 1618:
> 
>> 1616:             }
>> 1617:         }
>> 1618:         g.setClip(clip);
> 
> Since it is normally seen in Metal L&F, shouldn't we do the clip setting in MetalSliderUI.paintThumb() instead?
> If we are doing it in BasicSliderUI, can you please explain why are we not seeing it in other L&Fs like nimbus or motif?

The bug in the motif was fixed by the JDK-8032219, the code in the BasicSliderUI is never used by the Metal L&F, I tested that code by the commented out the overridden code in the MetalSliderUI.

-------------

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

From serb at openjdk.java.net  Tue Nov 24 05:00:55 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 24 Nov 2020 05:00:55 GMT
Subject: <Swing Dev> RFR: 8256019: JLabel HTML text does not support
 translucent text colors [v2]
In-Reply-To: <tl9I69hvG58f85TSGF7S6B8mDDiMGbIfDIwwzJ54D6Q=.09004239-b544-4212-aae1-a9bb19cc4890@github.com>
References: <ZzkL8ZqJVoa-kuPtX_AY6LSHjHmSlaFCRubR4JcajVc=.6fbdb071-2141-4098-94c0-ba0fbf227668@github.com>
 <wxFBtwc6OrSvzUzqvvsO0hoatY9j6ABGZ-5wGdQ3oY8=.f94b6769-25d0-416f-9159-a8e1c2a4bbc5@github.com>
 <tl9I69hvG58f85TSGF7S6B8mDDiMGbIfDIwwzJ54D6Q=.09004239-b544-4212-aae1-a9bb19cc4890@github.com>
Message-ID: <oXG0PWDEQrGsn_laTgSgf3MCDKmdkmOn5t8bxsIzN0I=.de0611fa-8e3d-4852-9ed0-25ca19cfb85f@github.com>

On Fri, 20 Nov 2020 03:41:54 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicHTML.java line 64:
>> 
>>> 62:     public static View createHTMLView(JComponent c, String html) {
>>> 63:         BasicEditorKit kit = getFactory();
>>> 64:         int beginIndex = html.indexOf("rgba(");
>> 
>> Don't we need to implement this parsing similarly to rgb()? somewhere inside kit.createDefaultDocument() or where we parse rgb()?
>
> The problem is the alpha color not being present in c.getForeground() so we need to parse alpha here to pass the value to displayPropertiesToCSS(). I have already mentioned it below.

As far as I understand the only place where we decode `rgb()` is `CSS.stringToColor` and that code missing the `rgba()` case.
Just to double-check.
If the test case `TestTranslucentLabelText` will be modified to use `rgb()` instead of `rgba()` then the color which was set by the user to the `Component` will be ignored, and the correct color from the `rgb()` will be used. So it does not matter that `c.getForeground()` contains some opaque color, it is ignored, why the similar case for` rgba()` does not work in the same way?

-------------

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

From psadhukhan at openjdk.java.net  Tue Nov 24 08:50:57 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 24 Nov 2020 08:50:57 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <N7p7UzkSJr16E6KhZYLGLSlhVtXNNtBUkTz-USdjVzg=.825ed7ab-81e4-428e-b1ba-ec4646536393@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <1tz535gufWoNJ_jO-3KwmSsOfDHQN9Cqz-lvespNJpU=.bac9344b-310c-4af4-a623-0a29b2cc4eec@github.com>
 <5EU6riZkVpPCEF4g9XxJMtyfXiFEeV5A7Dd506uBn_w=.c3f68824-7756-4049-a3e2-52156bd8f014@github.com>
 <N7p7UzkSJr16E6KhZYLGLSlhVtXNNtBUkTz-USdjVzg=.825ed7ab-81e4-428e-b1ba-ec4646536393@github.com>
Message-ID: <rGXF9tOcJqQqSVEumo3gRN7jkrWLRjE_6cRJPgDWBFU=.c4be29cb-427c-4ac2-bd5d-7c2393744d03@github.com>

On Thu, 19 Nov 2020 18:56:43 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> In Mohave, native System Preferences->Display tabs has 
>> white-text-on-blue-background when windows is focused
>> black-text-on-lightgray-background when window is unfocused
>> 
>> In macos11, it is always black-text-on-white-background whether focused/unfocused.
>> 
>> Current JDK tabpane always shows black background (when tab is selected) which is not configurable, at least I could not change it. Only thing i could change is the foreground text color. 
>> As was told to get color from native, I could see only "selectedTextBackground" and "selectedControlColor" works on both pre-macos11 and macos11 as it gives bluish text color which is legible on black (mohave) and white (macos11) background.
>> 
>> All other native-obtained-colors like selectedTextColor, selectedControlTextColor, controlTextColor, textBackgroundColor either gives black or white which is not legible on either pre-macos11 or macos11, so was not used.
>
> Then try to dig into it a little bit, probably a good reason to ask about the current font color in the tab at the Apple forum.

Tried to find and change tabpane background color for "selected" tab but unable to do so. 
Tried changing AquaLookAndFeel.tabBackgroundColor, TabbedPane.background color to no avail. Tried to set background by calling tabPane.setbackground() in AquaTabbedPaneUI.installDefaults but it sets background for non-selected tab (keeping black background for selected tab in mohave unchanged). I see it's been like that at least from jdk8GA.
Post to apple forum is unanswered.

-------------

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

From psadhukhan at openjdk.java.net  Tue Nov 24 11:04:00 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 24 Nov 2020 11:04:00 GMT
Subject: <Swing Dev> RFR: 8256713: SwingSet2 : Slider leaves tracks in
 uiScale=2
In-Reply-To: <Xp5GRYQicBWjgXzul0QHTpvw_bRCpY08IODCRrNa4dY=.a1afc135-7d61-4bab-9620-28a72705448a@github.com>
References: <Ro0F4RB7lNhKqDM9QX_AoLYqmWuKPh0jHDea63h8Y8g=.e9dfb175-201a-4cdd-9a4a-163a6adab74c@github.com>
 <ZtLWfaL-yFU-XlouVq2p4WCOjHVNzTBTNj2abE9ayUA=.76442042-c43d-4d8f-944a-74ee4adf1c74@github.com>
 <Xp5GRYQicBWjgXzul0QHTpvw_bRCpY08IODCRrNa4dY=.a1afc135-7d61-4bab-9620-28a72705448a@github.com>
Message-ID: <ZVFsufLQyFngXodb3XPjkICJ6KPTUDz3JZsLn-RQfB0=.81b8c86a-9436-496a-b675-4a4cb9adf1e5@github.com>

On Tue, 24 Nov 2020 00:09:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSliderUI.java line 1618:
>> 
>>> 1616:             }
>>> 1617:         }
>>> 1618:         g.setClip(clip);
>> 
>> Since it is normally seen in Metal L&F, shouldn't we do the clip setting in MetalSliderUI.paintThumb() instead?
>> If we are doing it in BasicSliderUI, can you please explain why are we not seeing it in other L&Fs like nimbus or motif?
>
> The bug in the motif was fixed by the JDK-8032219, the code in the BasicSliderUI is never used by the Metal L&F, I tested that code by the commented out the overridden code in the MetalSliderUI.

If the code in BasicSliderUI is not used by Metal L&F, then, all the more reason to have the clip setting in MetalSliderUI.paintThumb(), no?
What about nimbus? Why it is not seen in nimbus l&f? 
I guess only reason I can think of putting the code in BasicL&F is if it's a generic issue and it will solve multiple L&F but it seems the issue only affects MetalL&F.

-------------

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

From psadhukhan at openjdk.java.net  Tue Nov 24 13:02:12 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 24 Nov 2020 13:02:12 GMT
Subject: <Swing Dev> RFR: 8256019: JLabel HTML text does not support
 translucent text colors [v3]
In-Reply-To: <ZzkL8ZqJVoa-kuPtX_AY6LSHjHmSlaFCRubR4JcajVc=.6fbdb071-2141-4098-94c0-ba0fbf227668@github.com>
References: <ZzkL8ZqJVoa-kuPtX_AY6LSHjHmSlaFCRubR4JcajVc=.6fbdb071-2141-4098-94c0-ba0fbf227668@github.com>
Message-ID: <xqRuHMw5xsEWqTNvoWLzCL0f9a4Xyehehgglvmk6kN8=.24ce6dc3-9b80-4185-b978-d149cb2c365a@github.com>

> Issue is a JLabel with a translucent foreground color properly renders plain text, but with HTML text, the alpha component is discarded and the text is rendered using an opaque color.
> As per https://www.w3schools.com/cssref/func_rgba.asp, CSS supports rgba() to support alpha and render translucent text color
> but support for rgba() is not present in JDK html text rendering.
> 
> Added support for rgba() to render translucent text color.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Revert unneeded additional code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1158/files
  - new: https://git.openjdk.java.net/jdk/pull/1158/files/bf0c84ae..f98cae53

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1158&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1158&range=01-02

  Stats: 64 lines in 3 files changed: 10 ins; 42 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1158.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1158/head:pull/1158

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

From psadhukhan at openjdk.java.net  Tue Nov 24 13:02:12 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 24 Nov 2020 13:02:12 GMT
Subject: <Swing Dev> RFR: 8256019: JLabel HTML text does not support
 translucent text colors [v3]
In-Reply-To: <oXG0PWDEQrGsn_laTgSgf3MCDKmdkmOn5t8bxsIzN0I=.de0611fa-8e3d-4852-9ed0-25ca19cfb85f@github.com>
References: <ZzkL8ZqJVoa-kuPtX_AY6LSHjHmSlaFCRubR4JcajVc=.6fbdb071-2141-4098-94c0-ba0fbf227668@github.com>
 <wxFBtwc6OrSvzUzqvvsO0hoatY9j6ABGZ-5wGdQ3oY8=.f94b6769-25d0-416f-9159-a8e1c2a4bbc5@github.com>
 <tl9I69hvG58f85TSGF7S6B8mDDiMGbIfDIwwzJ54D6Q=.09004239-b544-4212-aae1-a9bb19cc4890@github.com>
 <oXG0PWDEQrGsn_laTgSgf3MCDKmdkmOn5t8bxsIzN0I=.de0611fa-8e3d-4852-9ed0-25ca19cfb85f@github.com>
Message-ID: <sdYH0GmdkkJzr6VPHzOZU1jIBnaTofWVafbGzQaXZF4=.5fafa5d5-9b3d-4c5e-b76a-4b6f26c80524@github.com>

On Tue, 24 Nov 2020 04:58:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The problem is the alpha color not being present in c.getForeground() so we need to parse alpha here to pass the value to displayPropertiesToCSS(). I have already mentioned it below.
>
> As far as I understand the only place where we decode `rgb()` is `CSS.stringToColor` and that code missing the `rgba()` case.
> Just to double-check.
> If the test case `TestTranslucentLabelText` will be modified to use `rgb()` instead of `rgba()` then the color which was set by the user to the `Component` will be ignored, and the correct color from the `rgb()` will be used. So it does not matter that `c.getForeground()` contains some opaque color, it is ignored, why the similar case for` rgba()` does not work in the same way?

Yes, seems like overkill last time which is not needed. Reverted back unneeded code.

-------------

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

From serb at openjdk.java.net  Tue Nov 24 20:23:56 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 24 Nov 2020 20:23:56 GMT
Subject: <Swing Dev> RFR: 8256713: SwingSet2 : Slider leaves tracks in
 uiScale=2
In-Reply-To: <ZVFsufLQyFngXodb3XPjkICJ6KPTUDz3JZsLn-RQfB0=.81b8c86a-9436-496a-b675-4a4cb9adf1e5@github.com>
References: <Ro0F4RB7lNhKqDM9QX_AoLYqmWuKPh0jHDea63h8Y8g=.e9dfb175-201a-4cdd-9a4a-163a6adab74c@github.com>
 <ZtLWfaL-yFU-XlouVq2p4WCOjHVNzTBTNj2abE9ayUA=.76442042-c43d-4d8f-944a-74ee4adf1c74@github.com>
 <Xp5GRYQicBWjgXzul0QHTpvw_bRCpY08IODCRrNa4dY=.a1afc135-7d61-4bab-9620-28a72705448a@github.com>
 <ZVFsufLQyFngXodb3XPjkICJ6KPTUDz3JZsLn-RQfB0=.81b8c86a-9436-496a-b675-4a4cb9adf1e5@github.com>
Message-ID: <CHuxpjrDZB8XujbtEME3Ezly2k7m9IXelKgTtm062rs=.ee3c0144-de7f-47c0-802a-8e3e078799cc@github.com>

On Tue, 24 Nov 2020 11:00:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The bug in the motif was fixed by the JDK-8032219, the code in the BasicSliderUI is never used by the Metal L&F, I tested that code by the commented out the overridden code in the MetalSliderUI.
>
> If the code in BasicSliderUI is not used by Metal L&F, then, all the more reason to have the clip setting in MetalSliderUI.paintThumb(), no?
> What about nimbus? Why it is not seen in nimbus l&f? 
> I guess only reason I can think of putting the code in BasicL&F is if it's a generic issue and it will solve multiple L&F but it seems the issue only affects MetalL&F.

I have set the clip in the methods which do not draw the thumb properly - draw it outside the bounds of the thumb(it is a limitationGraphics). Only three places were affected, the motif - fixed in JDK-8032219, the old default metal L&F(steel) fixed in this fix in the MetalIconFactory.java. And the code in the BasicSliderUI is not executed by the metal but could be triggered by commenting on some code.

-------------

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

From Sergey.Bylokhov at oracle.com  Tue Nov 24 21:32:09 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 24 Nov 2020 13:32:09 -0800
Subject: <Swing Dev> taskbar icon badge issue
In-Reply-To: <B682783D-684D-4622-83BD-52DA89752B10@cbfiddle.com>
References: <BA52494A-563C-4AF1-B0C2-5512E638266A@cbfiddle.com>
 <18ffee46-69a5-752a-29d0-089573f82c22@oracle.com>
 <A8A3CBCA-1AD7-49CE-ADB9-66C7E25E9716@cbfiddle.com>
 <29bc2d5c-5782-7dbd-5909-364d9629fca1@oracle.com>
 <B682783D-684D-4622-83BD-52DA89752B10@cbfiddle.com>
Message-ID: <6a5a165b-8c0d-063e-9b57-ba8906ec7608@oracle.com>

On 20.11.2020 06:56, Alan Snyder wrote:
> I don?t believe there is any bug here.

It was there, and it was reported to Apple ID-7261735. Looks like this bug has a few
fixes and the last update was that it could work in 10.15.5 beta 3.
I'll take a look.

> Setting a badge on the app icon requires a permission that is controlled using the Notifications system preference.
> Using JDK 12, I can allow or prevent the test program from setting a badge by enabling or disabling notifications from ?java?.
> See linked image [1].
> 
> I hope the ?fix? can be reverted in JDK 16.
> 
>    Alan
> 
> [1] https://cr.openjdk.java.net/~alans/8230869/Notifications.png
> 
> 
> 
>> On Oct 26, 2020, at 2:29 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>
>> On 26.10.2020 14:16, Alan Snyder wrote:
>>>> I have tested the "DockBadge.java" from the https://bugs.openjdk.java.net/browse/JDK-8230869 on macOS 10.15.7 + JDK12 and it does not work =(
>>> That seems odd. Are you saying that no dock icons ever show a badge on 10.15.7?
>>
>> yes, in some updates it works, in another, it does not.
>>
>>> On my 10.15.6, I see dock badges on System Preferences, App Store, and Feedback Assistant. How are they accomplishing this? Do Apple apps use a private API> I?m suspicious that the problem is in the JDK, in which case it should be fixable.
>>
>> The Apple standard/public API for dock badges stop working when using with JRS.
>>
>> -- 
>> Best regards, Sergey.
>>
> 


-- 
Best regards, Sergey.

From darcy at openjdk.java.net  Tue Nov 24 21:58:03 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 24 Nov 2020 21:58:03 GMT
Subject: <Swing Dev> RFR: 8253753 Enable default constructor warning in
 client modules
Message-ID: <TE8bN62xLK1arlTDmI8Mu6LhKUjSOOZhcNFlKHifKGc=.10fe9076-1c0e-42cb-906d-a67020ed41b3@github.com>

With the default constructors warnings in java.desktop and jdk.accessibility now fixed, the warning should be enabled in the build for those modules.

-------------

Commit messages:
 - Merge branch 'JDK-8253753' of https://github.com/jddarcy/jdk into JDK-8253753
 - Update build to enable default constructor warning in client modules.
 - Update build to enable default constructor warning in client modules.

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

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

From serb at openjdk.java.net  Tue Nov 24 21:26:03 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 24 Nov 2020 21:26:03 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <rGXF9tOcJqQqSVEumo3gRN7jkrWLRjE_6cRJPgDWBFU=.c4be29cb-427c-4ac2-bd5d-7c2393744d03@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <1tz535gufWoNJ_jO-3KwmSsOfDHQN9Cqz-lvespNJpU=.bac9344b-310c-4af4-a623-0a29b2cc4eec@github.com>
 <5EU6riZkVpPCEF4g9XxJMtyfXiFEeV5A7Dd506uBn_w=.c3f68824-7756-4049-a3e2-52156bd8f014@github.com>
 <N7p7UzkSJr16E6KhZYLGLSlhVtXNNtBUkTz-USdjVzg=.825ed7ab-81e4-428e-b1ba-ec4646536393@github.com>
 <rGXF9tOcJqQqSVEumo3gRN7jkrWLRjE_6cRJPgDWBFU=.c4be29cb-427c-4ac2-bd5d-7c2393744d03@github.com>
Message-ID: <Vmq_aQuvjv30FpNqhdSXpzOvK9fPsOFw1CVoGAey6eU=.f5b9d2e6-0b9b-4bc7-96ac-43fa6200c56c@github.com>

On Tue, 24 Nov 2020 08:48:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Then try to dig into it a little bit, probably a good reason to ask about the current font color in the tab at the Apple forum.
>
> Tried to find and change tabpane background color for "selected" tab but unable to do so. 
> Tried changing AquaLookAndFeel.tabBackgroundColor, TabbedPane.background color to no avail. Tried to set background by calling tabPane.setbackground() in AquaTabbedPaneUI.installDefaults but it sets background for non-selected tab (keeping black background for selected tab in mohave unchanged). I see it's been like that at least from jdk8GA.
> Post to apple forum is unanswered.

> When inactive, I use 0 0 0 192. As far as I can tell, this does not correspond to a named color.
> It would be wrong to assume that Apple only uses named colors in their UIs.
> The named colors are for application developers, not for Apple itself.

The problem here is that we do not control the color of the tab pane, it is controlled by Apple, and if we hardcore some color on our side we will get the same bugs again and again. I am sure that a similar bug will come in the dark mode if we will enable it.

-------------

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

From prr at openjdk.java.net  Tue Nov 24 22:05:56 2020
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 24 Nov 2020 22:05:56 GMT
Subject: <Swing Dev> RFR: 8253753 Enable default constructor warning in
 client modules
In-Reply-To: <TE8bN62xLK1arlTDmI8Mu6LhKUjSOOZhcNFlKHifKGc=.10fe9076-1c0e-42cb-906d-a67020ed41b3@github.com>
References: <TE8bN62xLK1arlTDmI8Mu6LhKUjSOOZhcNFlKHifKGc=.10fe9076-1c0e-42cb-906d-a67020ed41b3@github.com>
Message-ID: <BP4VzaI8eQTAj_wfW36Wr1biHWHyqLY4H3gXXp8SDso=.a84ade98-e866-4751-a8b2-9b70ac68dc0a@github.com>

On Tue, 24 Nov 2020 19:10:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With the default constructors warnings in java.desktop and jdk.accessibility now fixed, the warning should be enabled in the build for those modules.

I tried this myself a few weeks ago and it was fine.

-------------

Marked as reviewed by prr (Reviewer).

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

From serb at openjdk.java.net  Tue Nov 24 23:09:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 24 Nov 2020 23:09:57 GMT
Subject: <Swing Dev> RFR: 8253753 Enable default constructor warning in
 client modules
In-Reply-To: <TE8bN62xLK1arlTDmI8Mu6LhKUjSOOZhcNFlKHifKGc=.10fe9076-1c0e-42cb-906d-a67020ed41b3@github.com>
References: <TE8bN62xLK1arlTDmI8Mu6LhKUjSOOZhcNFlKHifKGc=.10fe9076-1c0e-42cb-906d-a67020ed41b3@github.com>
Message-ID: <lGOBi45tYkyww3gcpndTbQ5eiQlxogS6mHN8nCvFoCw=.f3846039-0bc4-44aa-9a35-f18810094ca4@github.com>

On Tue, 24 Nov 2020 19:10:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With the default constructors warnings in java.desktop and jdk.accessibility now fixed, the warning should be enabled in the build for those modules.

Marked as reviewed by serb (Reviewer).

-------------

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

From serb at openjdk.java.net  Wed Nov 25 00:52:09 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 25 Nov 2020 00:52:09 GMT
Subject: <Swing Dev> RFR: 8196100:
 javax/swing/text/JTextComponent/5074573/bug5074573.java fails
Message-ID: <odiw68_aqTfJSmoCMm6W2c2KCfaE4H1zbdAtazkmmvc=.1b78ca1d-7820-478a-b3db-e5a72dd422cb@github.com>

Here is a fix for one of the annoying bug, which causes random test failures in the CI.

We have a method Robot.waitForIdle(), which supposed to wait until the java and the native queue stabilized. The common use case is to click on the button or show the window, and call waitForIdle() which will wait until the native event will be dispatched by the X11/Windows/macOS as well as followed Java event(paint/focus/etc event) will be dispatched to the EDT.

Currently, it is implemented in this way:
  1. Flush the EventQueue, so all old events will be posted to EDT.
  2. Flush the native event queue, by posting the native event.
  3. Flush the EDT, by posting a java event.
  4. If some events(unrelated to waitForIdle machinery) were dispatched on steps 2. or 3. then repeat since step 1.

It is implemented that they because the native events caused by the OS usually generate the java events, and the java events may generate native events. So we have to wait for both queues (java/native).

But it has the next disadvantages:
 - It is implemented as a busy loop, which does not give a chance for the application to proceed further since it blocks 3 threads EDT/native toolkit thread like appkit/main thread.
- It throws the InfiniteLoop exception if the number of attempts is bigger than 20. And this limitation is too small because some tests generate much more events during startup.
 - Note that the timeout value for the realSync method is 10 seconds, and it was assumed that this method will not be executed longer, but it uses this timeout for all events flushing which can lead up to 600 seconds (20 iters * 3  calls * 10 seconds).


The fix:
 - Add a small delay to the method, so the app can do something useful when waitForIdle() is called
 - The timeout=10 second is taken care of, we calculate the "end" time and exits if it is exceeded
 - The maximum number of attempts is increased to 100 and InfiniteLoop is removed.

Note that I have made one additional change to the new realSync implementation. At the beginning of the method I call:
 EventQueue.invokeAndWait(() -> {/*dummy implementation*/});
It is needed to be sure that we flush the first event on EDT even if we spend more time than 10 seconds.

-------------

Commit messages:
 - Update SunToolkit.java
 - The new tests
 - Do not use shared state
 - Update SunToolkit.java
 - realSync too slow
 - Update bug5074573.java
 - Test update
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/1424/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1424&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8196100
  Stats: 242 lines in 9 files changed: 192 ins; 20 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1424.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1424/head:pull/1424

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

From psadhukhan at openjdk.java.net  Wed Nov 25 02:57:56 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 25 Nov 2020 02:57:56 GMT
Subject: <Swing Dev> RFR: 8256713: SwingSet2 : Slider leaves tracks in
 uiScale=2
In-Reply-To: <Ro0F4RB7lNhKqDM9QX_AoLYqmWuKPh0jHDea63h8Y8g=.e9dfb175-201a-4cdd-9a4a-163a6adab74c@github.com>
References: <Ro0F4RB7lNhKqDM9QX_AoLYqmWuKPh0jHDea63h8Y8g=.e9dfb175-201a-4cdd-9a4a-163a6adab74c@github.com>
Message-ID: <kE9VRKUvK87w5XHOPIatf2jZ94sXkFQiymXEG6w9weA=.08e06e30-b1e2-4947-8f98-85765c480dd2@github.com>

On Sun, 22 Nov 2020 08:59:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The problem became visible, when we draw a border across the component using drawLine, and expected that fillRect will clear a border of the component. This is incorrect because in the case of the scaled graphics(retina) some part of the line can be placed outside of the bounds of the rectangle. See additional information here:
> https://bugs.openjdk.java.net/browse/JDK-8011764
> 
> This bug has occurred when the old default metal theme is used(DefaultMetalTheme) or thems based on it(Custom themes in the SwingSet2).
> 
> The fix applies the clip before the rendering so the paint method will not touch pixels outside the component.
> 
> As a fix, we could try to draw the lines using subpixel coordinates, but that code is expected to work using Graphics object(unlike current default metal theme: Ocean)  which uses the only int as a coordinate, not a Graphics2D
> 
> To make rendering a little bit better I tried antialiasing but it does not produce a better result, so did not use it in the fix.

Marked as reviewed by psadhukhan (Reviewer).

-------------

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

From psadhukhan at openjdk.java.net  Wed Nov 25 03:21:57 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 25 Nov 2020 03:21:57 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <Vmq_aQuvjv30FpNqhdSXpzOvK9fPsOFw1CVoGAey6eU=.f5b9d2e6-0b9b-4bc7-96ac-43fa6200c56c@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <1tz535gufWoNJ_jO-3KwmSsOfDHQN9Cqz-lvespNJpU=.bac9344b-310c-4af4-a623-0a29b2cc4eec@github.com>
 <5EU6riZkVpPCEF4g9XxJMtyfXiFEeV5A7Dd506uBn_w=.c3f68824-7756-4049-a3e2-52156bd8f014@github.com>
 <N7p7UzkSJr16E6KhZYLGLSlhVtXNNtBUkTz-USdjVzg=.825ed7ab-81e4-428e-b1ba-ec4646536393@github.com>
 <rGXF9tOcJqQqSVEumo3gRN7jkrWLRjE_6cRJPgDWBFU=.c4be29cb-427c-4ac2-bd5d-7c2393744d03@github.com>
 <Vmq_aQuvjv30FpNqhdSXpzOvK9fPsOFw1CVoGAey6eU=.f5b9d2e6-0b9b-4bc7-96ac-43fa6200c56c@github.com>
Message-ID: <VsiKqbB9re5mRsLRYwVAOSxAhkNA6EGkxN2UD0kMeoI=.6e6d2051-1d64-497d-abd8-b8197a3caa0b@github.com>

On Tue, 24 Nov 2020 21:23:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Tried to find and change tabpane background color for "selected" tab but unable to do so. 
>> Tried changing AquaLookAndFeel.tabBackgroundColor, TabbedPane.background color to no avail. Tried to set background by calling tabPane.setbackground() in AquaTabbedPaneUI.installDefaults but it sets background for non-selected tab (keeping black background for selected tab in mohave unchanged). I see it's been like that at least from jdk8GA.
>> Post to apple forum is unanswered.
>
>> When inactive, I use 0 0 0 192. As far as I can tell, this does not correspond to a named color.
>> It would be wrong to assume that Apple only uses named colors in their UIs.
>> The named colors are for application developers, not for Apple itself.
> 
> The problem here is that we do not control the color of the tab pane, it is controlled by Apple, and if we hardcore some color on our side we will get the same bugs again and again. I am sure that a similar bug will come in the dark mode if we will enable it.

Since color of tabpane is controlled by Apple, Can you point me to the code where we call Apple api to draw the color of tabpane?

-------------

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

From javalists at cbfiddle.com  Wed Nov 25 03:41:35 2020
From: javalists at cbfiddle.com (Alan Snyder)
Date: Tue, 24 Nov 2020 19:41:35 -0800
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <VsiKqbB9re5mRsLRYwVAOSxAhkNA6EGkxN2UD0kMeoI=.6e6d2051-1d64-497d-abd8-b8197a3caa0b@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <1tz535gufWoNJ_jO-3KwmSsOfDHQN9Cqz-lvespNJpU=.bac9344b-310c-4af4-a623-0a29b2cc4eec@github.com>
 <5EU6riZkVpPCEF4g9XxJMtyfXiFEeV5A7Dd506uBn_w=.c3f68824-7756-4049-a3e2-52156bd8f014@github.com>
 <N7p7UzkSJr16E6KhZYLGLSlhVtXNNtBUkTz-USdjVzg=.825ed7ab-81e4-428e-b1ba-ec4646536393@github.com>
 <rGXF9tOcJqQqSVEumo3gRN7jkrWLRjE_6cRJPgDWBFU=.c4be29cb-427c-4ac2-bd5d-7c2393744d03@github.com>
 <Vmq_aQuvjv30FpNqhdSXpzOvK9fPsOFw1CVoGAey6eU=.f5b9d2e6-0b9b-4bc7-96ac-43fa6200c56c@github.com>
 <VsiKqbB9re5mRsLRYwVAOSxAhkNA6EGkxN2UD0kMeoI=.6e6d2051-1d64-497d-abd8-b8197a3caa0b@github.com>
Message-ID: <B88F93A2-FA2E-48ED-B5D0-DF199A05549E@cbfiddle.com>

On Nov 24, 2020, at 7:21 PM, Prasanta Sadhukhan <psadhukhan at openjdk.java.net> wrote:
> 
> On Tue, 24 Nov 2020 21:23:38 GMT, Sergey Bylokhov <serb at openjdk.org <mailto:serb at openjdk.org>> wrote:
> 
>>> Tried to find and change tabpane background color for "selected" tab but unable to do so. 
>>> Tried changing AquaLookAndFeel.tabBackgroundColor, TabbedPane.background color to no avail. Tried to set background by calling tabPane.setbackground() in AquaTabbedPaneUI.installDefaults but it sets background for non-selected tab (keeping black background for selected tab in mohave unchanged). I see it's been like that at least from jdk8GA.
>>> Post to apple forum is unanswered.
>> 
>>> When inactive, I use 0 0 0 192. As far as I can tell, this does not correspond to a named color.
>>> It would be wrong to assume that Apple only uses named colors in their UIs.
>>> The named colors are for application developers, not for Apple itself.
>> 
>> The problem here is that we do not control the color of the tab pane, it is controlled by Apple, and if we hardcore some color on our side we will get the same bugs again and again. I am sure that a similar bug will come in the dark mode if we will enable it.
> 
> Since color of tabpane is controlled by Apple, Can you point me to the code where we call Apple api to draw the color of tabpane?
> 

You don?t. All you do is ask for a Tab style button:
protected final AquaPainter<JRSUIState> painter = AquaPainter.create(JRSUIStateFactory.getTab());
It's a nice abstract interface, but it lacks the corresponding API for getting the Tab text color to match a given appearance and state.

Basically, the API is incomplete and has not been kept up to date.
Otherwise, VAqua would not exist. :-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/swing-dev/attachments/20201124/e9e6f652/attachment-0001.htm>

From trebari at openjdk.java.net  Wed Nov 25 06:40:12 2020
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Wed, 25 Nov 2020 06:40:12 GMT
Subject: <Swing Dev> RFR: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions [v2]
In-Reply-To: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
Message-ID: <nVZYzoI4eN_80GmjOYX-dkHqWar80CN-p7toBkRMwA0=.844ba82a-af08-40cc-8e2f-126ffe332327@github.com>

> Please review the following fix for jdk16.
> 
> Issue : There is a  JToggleButton that will post/take down a JPopupMenu when the button is selected. If the button is selected and the menu is not posted the action listener will post the menu. If the button is selected and the menu is displayed the action listener will take the menu down. The use case is:
> 1 - select button
> 2 - menu posted
> 3 - select button
> 4 - menu taken down
> 
> With MetalLookAndFeel the above use case works fine, but with WindowsLookAndFeel the second button selection does not fire the actionPerformed event,  button needs to be selected third time for the menu to be taken down.
> 
> The issue is that the button must be selected twice after the menu is posted to have the actionPerformed event to fire when using the Windows look and feel.
> 
> Fix : MouseGrabber is not removed while uninstalling the listeners in the BasicPopupMenuUI.
> By removing the mouseGrabber in the uninstallListeners() methods fixes this issue.
> 
> Added a test to test the same in all the LookAndFeels

Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:

  modified the test after suggestions

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/600/files
  - new: https://git.openjdk.java.net/jdk/pull/600/files/a60ffa67..65c08eda

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=600&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=600&range=00-01

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

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

From javalists at cbfiddle.com  Wed Nov 25 17:30:34 2020
From: javalists at cbfiddle.com (Alan Snyder)
Date: Wed, 25 Nov 2020 09:30:34 -0800
Subject: <Swing Dev> taskbar icon badge issue
In-Reply-To: <6a5a165b-8c0d-063e-9b57-ba8906ec7608@oracle.com>
References: <BA52494A-563C-4AF1-B0C2-5512E638266A@cbfiddle.com>
 <18ffee46-69a5-752a-29d0-089573f82c22@oracle.com>
 <A8A3CBCA-1AD7-49CE-ADB9-66C7E25E9716@cbfiddle.com>
 <29bc2d5c-5782-7dbd-5909-364d9629fca1@oracle.com>
 <B682783D-684D-4622-83BD-52DA89752B10@cbfiddle.com>
 <6a5a165b-8c0d-063e-9b57-ba8906ec7608@oracle.com>
Message-ID: <E46707E4-C331-4F06-929C-3A4073C8840B@cbfiddle.com>



> On Nov 24, 2020, at 1:32 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> It was there, and it was reported to Apple ID-7261735. Looks like this bug has a few
> fixes and the last update was that it could work in 10.15.5 beta 3.
> I'll take a look.

Thanks.

By the way, it is not clear to me why it is a good idea to throw UnsupportedOperationException
based on the possibility that the badge *might not* be displayed on some OS releases. The obvious
downside is that the badge will then not be displayed even on releases where it would work.

Does the application need to know that the badge was not displayed? I don?t see why, but
it does, then are you prepared to throw an exception when the request was not permitted because
the user did not grant permission?

  Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/swing-dev/attachments/20201125/2c324721/attachment.htm>

From javalists at cbfiddle.com  Wed Nov 25 17:36:24 2020
From: javalists at cbfiddle.com (Alan Snyder)
Date: Wed, 25 Nov 2020 09:36:24 -0800
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <Vmq_aQuvjv30FpNqhdSXpzOvK9fPsOFw1CVoGAey6eU=.f5b9d2e6-0b9b-4bc7-96ac-43fa6200c56c@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <1tz535gufWoNJ_jO-3KwmSsOfDHQN9Cqz-lvespNJpU=.bac9344b-310c-4af4-a623-0a29b2cc4eec@github.com>
 <5EU6riZkVpPCEF4g9XxJMtyfXiFEeV5A7Dd506uBn_w=.c3f68824-7756-4049-a3e2-52156bd8f014@github.com>
 <N7p7UzkSJr16E6KhZYLGLSlhVtXNNtBUkTz-USdjVzg=.825ed7ab-81e4-428e-b1ba-ec4646536393@github.com>
 <rGXF9tOcJqQqSVEumo3gRN7jkrWLRjE_6cRJPgDWBFU=.c4be29cb-427c-4ac2-bd5d-7c2393744d03@github.com>
 <Vmq_aQuvjv30FpNqhdSXpzOvK9fPsOFw1CVoGAey6eU=.f5b9d2e6-0b9b-4bc7-96ac-43fa6200c56c@github.com>
Message-ID: <335E9105-88E8-4D70-BA5A-603B2F810FC1@cbfiddle.com>


> On Nov 24, 2020, at 1:26 PM, Sergey Bylokhov <serb at openjdk.java.net> wrote:
> 
> The problem here is that we do not control the color of the tab pane, it is controlled by Apple, and if we hardcore some color on our side we will get the same bugs again and again. I am sure that a similar bug will come in the dark mode if we will enable it.

I feel your pain. :-)

The only alternative would be for Apple to provide the text color information to the JDK. Good luck with that.
Even if they did, based on my experience, I predict that there would still be bugs with each new major release.
They would be Apple bugs rather than JDK bugs, but that is a small consolation.

  Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/swing-dev/attachments/20201125/6b954199/attachment.htm>

From kizune at openjdk.java.net  Wed Nov 25 17:52:03 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 25 Nov 2020 17:52:03 GMT
Subject: <Swing Dev> RFR: 8196100:
 javax/swing/text/JTextComponent/5074573/bug5074573.java fails
In-Reply-To: <odiw68_aqTfJSmoCMm6W2c2KCfaE4H1zbdAtazkmmvc=.1b78ca1d-7820-478a-b3db-e5a72dd422cb@github.com>
References: <odiw68_aqTfJSmoCMm6W2c2KCfaE4H1zbdAtazkmmvc=.1b78ca1d-7820-478a-b3db-e5a72dd422cb@github.com>
Message-ID: <-3MWzl2XJ7KjbSdtS3LZpz4mqE2hG4MLa5iL8XnDQLE=.1951234f-6a8c-4414-849b-c0f53ac52c16@github.com>

On Wed, 25 Nov 2020 00:15:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Here is a fix for one of the annoying bug, which causes random test failures in the CI.
> 
> We have a method Robot.waitForIdle(), which supposed to wait until the java and the native queue stabilized. The common use case is to click on the button or show the window, and call waitForIdle() which will wait until the native event will be dispatched by the X11/Windows/macOS as well as followed Java event(paint/focus/etc event) will be dispatched to the EDT.
> 
> Currently, it is implemented in this way:
>   1. Flush the EventQueue, so all old events will be posted to EDT.
>   2. Flush the native event queue, by posting the native event.
>   3. Flush the EDT, by posting a java event.
>   4. If some events(unrelated to waitForIdle machinery) were dispatched on steps 2. or 3. then repeat since step 1.
> 
> It is implemented that they because the native events caused by the OS usually generate the java events, and the java events may generate native events. So we have to wait for both queues (java/native).
> 
> But it has the next disadvantages:
>  - It is implemented as a busy loop, which does not give a chance for the application to proceed further since it blocks 3 threads EDT/native toolkit thread like appkit/main thread.
> - It throws the InfiniteLoop exception if the number of attempts is bigger than 20. And this limitation is too small because some tests generate much more events during startup.
>  - Note that the timeout value for the realSync method is 10 seconds, and it was assumed that this method will not be executed longer, but it uses this timeout for all events flushing which can lead up to 600 seconds (20 iters * 3  calls * 10 seconds).
> 
> 
> The fix:
>  - Add a small delay to the method, so the app can do something useful when waitForIdle() is called
>  - The timeout=10 second is taken care of, we calculate the "end" time and exits if it is exceeded
>  - The maximum number of attempts is increased to 100 and InfiniteLoop is removed.
> 
> Note that I have made one additional change to the new realSync implementation. At the beginning of the method I call:
>  EventQueue.invokeAndWait(() -> {/*dummy implementation*/});
> It is needed to be sure that we flush the first event on EDT even if we spend more time than 10 seconds.

src/java.desktop/share/classes/sun/awt/SunToolkit.java line 1383:

> 1381:                 it.next().modalityPopped(ev);
> 1382:             }
> 1383:         }

I think that the rationale behind this exception as that in case of really stuck loop we could identify it. Why are we throwing it away? Now when we exceed the maximum allowed number of iterations we are assuming that the native event queue synchronization happened while it might not be the case.

test/jdk/java/awt/Robot/InfiniteLoopException.java line 63:

> 61:         long time = TimeUnit.NANOSECONDS.toSeconds(System.nanoTime() - start);
> 62:         if (time > 20) {
> 63:             throw new RuntimeException("To slow:" + time);

Typo? Shouldn't it be "Too slow"?

-------------

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

From serb at openjdk.java.net  Wed Nov 25 20:30:59 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 25 Nov 2020 20:30:59 GMT
Subject: <Swing Dev> Integrated: 8256713: SwingSet2 : Slider leaves tracks
 in uiScale=2
In-Reply-To: <Ro0F4RB7lNhKqDM9QX_AoLYqmWuKPh0jHDea63h8Y8g=.e9dfb175-201a-4cdd-9a4a-163a6adab74c@github.com>
References: <Ro0F4RB7lNhKqDM9QX_AoLYqmWuKPh0jHDea63h8Y8g=.e9dfb175-201a-4cdd-9a4a-163a6adab74c@github.com>
Message-ID: <XXjaPHCWmfkpPgupb-E2sPWmYUIfY9M_xt8rDnbAGdo=.7534a616-3c17-4a98-ac8d-dcd5b2ecc4b1@github.com>

On Sun, 22 Nov 2020 08:59:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The problem became visible, when we draw a border across the component using drawLine, and expected that fillRect will clear a border of the component. This is incorrect because in the case of the scaled graphics(retina) some part of the line can be placed outside of the bounds of the rectangle. See additional information here:
> https://bugs.openjdk.java.net/browse/JDK-8011764
> 
> This bug has occurred when the old default metal theme is used(DefaultMetalTheme) or thems based on it(Custom themes in the SwingSet2).
> 
> The fix applies the clip before the rendering so the paint method will not touch pixels outside the component.
> 
> As a fix, we could try to draw the lines using subpixel coordinates, but that code is expected to work using Graphics object(unlike current default metal theme: Ocean)  which uses the only int as a coordinate, not a Graphics2D
> 
> To make rendering a little bit better I tried antialiasing but it does not produce a better result, so did not use it in the fix.

This pull request has now been integrated.

Changeset: 9d7121c1
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9d7121c1
Stats:     192 lines in 3 files changed: 177 ins; 2 del; 13 mod

8256713: SwingSet2 : Slider leaves tracks in uiScale=2

Reviewed-by: jdv, psadhukhan

-------------

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

From serb at openjdk.java.net  Thu Nov 26 04:45:58 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Nov 2020 04:45:58 GMT
Subject: <Swing Dev> RFR: 8196100:
 javax/swing/text/JTextComponent/5074573/bug5074573.java fails
In-Reply-To: <-3MWzl2XJ7KjbSdtS3LZpz4mqE2hG4MLa5iL8XnDQLE=.1951234f-6a8c-4414-849b-c0f53ac52c16@github.com>
References: <odiw68_aqTfJSmoCMm6W2c2KCfaE4H1zbdAtazkmmvc=.1b78ca1d-7820-478a-b3db-e5a72dd422cb@github.com>
 <-3MWzl2XJ7KjbSdtS3LZpz4mqE2hG4MLa5iL8XnDQLE=.1951234f-6a8c-4414-849b-c0f53ac52c16@github.com>
Message-ID: <I3bK-oKlSeKQIVrEfJ5uW6lq5QVjmz5KiOzIwrFyHD8=.4f3b4b6b-6cee-4081-9d6b-240ffccf8e17@github.com>

On Wed, 25 Nov 2020 17:48:06 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Here is a fix for one of the annoying bug, which causes random test failures in the CI.
>> 
>> We have a method Robot.waitForIdle(), which supposed to wait until the java and the native queue stabilized. The common use case is to click on the button or show the window, and call waitForIdle() which will wait until the native event will be dispatched by the X11/Windows/macOS as well as followed Java event(paint/focus/etc event) will be dispatched to the EDT.
>> 
>> Currently, it is implemented in this way:
>>   1. Flush the EventQueue, so all old events will be posted to EDT.
>>   2. Flush the native event queue, by posting the native event.
>>   3. Flush the EDT, by posting a java event.
>>   4. If some events(unrelated to waitForIdle machinery) were dispatched on steps 2. or 3. then repeat since step 1.
>> 
>> It is implemented that they because the native events caused by the OS usually generate the java events, and the java events may generate native events. So we have to wait for both queues (java/native).
>> 
>> But it has the next disadvantages:
>>  - It is implemented as a busy loop, which does not give a chance for the application to proceed further since it blocks 3 threads EDT/native toolkit thread like appkit/main thread.
>> - It throws the InfiniteLoop exception if the number of attempts is bigger than 20. And this limitation is too small because some tests generate much more events during startup.
>>  - Note that the timeout value for the realSync method is 10 seconds, and it was assumed that this method will not be executed longer, but it uses this timeout for all events flushing which can lead up to 600 seconds (20 iters * 3  calls * 10 seconds).
>> 
>> 
>> The fix:
>>  - Add a small delay to the method, so the app can do something useful when waitForIdle() is called
>>  - The timeout=10 second is taken care of, we calculate the "end" time and exits if it is exceeded
>>  - The maximum number of attempts is increased to 100 and InfiniteLoop is removed.
>> 
>> Note that I have made one additional change to the new realSync implementation. At the beginning of the method I call:
>>  EventQueue.invokeAndWait(() -> {/*dummy implementation*/});
>> It is needed to be sure that we flush the first event on EDT even if we spend more time than 10 seconds.
>
> src/java.desktop/share/classes/sun/awt/SunToolkit.java line 1383:
> 
>> 1381:                 it.next().modalityPopped(ev);
>> 1382:             }
>> 1383:         }
> 
> I think that the rationale behind this exception as that in case of really stuck loop we could identify it. Why are we throwing it away? Now when we exceed the maximum allowed number of iterations we are assuming that the native event queue synchronization happened while it might not be the case.

Yes, that was the initial goal, but currently, it does not work well if some of the components use animation and periodically repainted we hit this exception.

-------------

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

From serb at openjdk.java.net  Thu Nov 26 04:52:17 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Nov 2020 04:52:17 GMT
Subject: <Swing Dev> RFR: 8196100:
 javax/swing/text/JTextComponent/5074573/bug5074573.java fails [v2]
In-Reply-To: <odiw68_aqTfJSmoCMm6W2c2KCfaE4H1zbdAtazkmmvc=.1b78ca1d-7820-478a-b3db-e5a72dd422cb@github.com>
References: <odiw68_aqTfJSmoCMm6W2c2KCfaE4H1zbdAtazkmmvc=.1b78ca1d-7820-478a-b3db-e5a72dd422cb@github.com>
Message-ID: <ZLl36uuUpcZmP2V6pLn_krKMVxLzl-tiBQkPrPuzVV8=.a9773fe5-c856-4390-a075-5e01184c095b@github.com>

> Here is a fix for one of the annoying bug, which causes random test failures in the CI.
> 
> We have a method Robot.waitForIdle(), which supposed to wait until the java and the native queue stabilized. The common use case is to click on the button or show the window, and call waitForIdle() which will wait until the native event will be dispatched by the X11/Windows/macOS as well as followed Java event(paint/focus/etc event) will be dispatched to the EDT.
> 
> Currently, it is implemented in this way:
>   1. Flush the EventQueue, so all old events will be posted to EDT.
>   2. Flush the native event queue, by posting the native event.
>   3. Flush the EDT, by posting a java event.
>   4. If some events(unrelated to waitForIdle machinery) were dispatched on steps 2. or 3. then repeat since step 1.
> 
> It is implemented that they because the native events caused by the OS usually generate the java events, and the java events may generate native events. So we have to wait for both queues (java/native).
> 
> But it has the next disadvantages:
>  - It is implemented as a busy loop, which does not give a chance for the application to proceed further since it blocks 3 threads EDT/native toolkit thread like appkit/main thread.
> - It throws the InfiniteLoop exception if the number of attempts is bigger than 20. And this limitation is too small because some tests generate much more events during startup.
>  - Note that the timeout value for the realSync method is 10 seconds, and it was assumed that this method will not be executed longer, but it uses this timeout for all events flushing which can lead up to 600 seconds (20 iters * 3  calls * 10 seconds).
> 
> 
> The fix:
>  - Add a small delay to the method, so the app can do something useful when waitForIdle() is called
>  - The timeout=10 second is taken care of, we calculate the "end" time and exits if it is exceeded
>  - The maximum number of attempts is increased to 100 and InfiniteLoop is removed.
> 
> Note that I have made one additional change to the new realSync implementation. At the beginning of the method I call:
>  EventQueue.invokeAndWait(() -> {/*dummy implementation*/});
> It is needed to be sure that we flush the first event on EDT even if we spend more time than 10 seconds.

Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/awt/Robot/InfiniteLoopException.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1424/files
  - new: https://git.openjdk.java.net/jdk/pull/1424/files/1bbd7ba1..1229546b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1424&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1424&range=00-01

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

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

From serb at openjdk.java.net  Thu Nov 26 04:52:18 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Nov 2020 04:52:18 GMT
Subject: <Swing Dev> RFR: 8196100:
 javax/swing/text/JTextComponent/5074573/bug5074573.java fails [v2]
In-Reply-To: <ZLl36uuUpcZmP2V6pLn_krKMVxLzl-tiBQkPrPuzVV8=.a9773fe5-c856-4390-a075-5e01184c095b@github.com>
References: <odiw68_aqTfJSmoCMm6W2c2KCfaE4H1zbdAtazkmmvc=.1b78ca1d-7820-478a-b3db-e5a72dd422cb@github.com>
 <ZLl36uuUpcZmP2V6pLn_krKMVxLzl-tiBQkPrPuzVV8=.a9773fe5-c856-4390-a075-5e01184c095b@github.com>
Message-ID: <JAW7wzcLAxHk_wFW9KnVaCU0Oq5hKKNBAYPHETaZJCc=.1aaac54d-f748-42bf-bfb6-40fc0c9eaf23@github.com>

On Thu, 26 Nov 2020 04:49:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Here is a fix for one of the annoying bug, which causes random test failures in the CI.
>> 
>> We have a method Robot.waitForIdle(), which supposed to wait until the java and the native queue stabilized. The common use case is to click on the button or show the window, and call waitForIdle() which will wait until the native event will be dispatched by the X11/Windows/macOS as well as followed Java event(paint/focus/etc event) will be dispatched to the EDT.
>> 
>> Currently, it is implemented in this way:
>>   1. Flush the EventQueue, so all old events will be posted to EDT.
>>   2. Flush the native event queue, by posting the native event.
>>   3. Flush the EDT, by posting a java event.
>>   4. If some events(unrelated to waitForIdle machinery) were dispatched on steps 2. or 3. then repeat since step 1.
>> 
>> It is implemented that they because the native events caused by the OS usually generate the java events, and the java events may generate native events. So we have to wait for both queues (java/native).
>> 
>> But it has the next disadvantages:
>>  - It is implemented as a busy loop, which does not give a chance for the application to proceed further since it blocks 3 threads EDT/native toolkit thread like appkit/main thread.
>> - It throws the InfiniteLoop exception if the number of attempts is bigger than 20. And this limitation is too small because some tests generate much more events during startup.
>>  - Note that the timeout value for the realSync method is 10 seconds, and it was assumed that this method will not be executed longer, but it uses this timeout for all events flushing which can lead up to 600 seconds (20 iters * 3  calls * 10 seconds).
>> 
>> 
>> The fix:
>>  - Add a small delay to the method, so the app can do something useful when waitForIdle() is called
>>  - The timeout=10 second is taken care of, we calculate the "end" time and exits if it is exceeded
>>  - The maximum number of attempts is increased to 100 and InfiniteLoop is removed.
>> 
>> Note that I have made one additional change to the new realSync implementation. At the beginning of the method I call:
>>  EventQueue.invokeAndWait(() -> {/*dummy implementation*/});
>> It is needed to be sure that we flush the first event on EDT even if we spend more time than 10 seconds.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/awt/Robot/InfiniteLoopException.java

test/jdk/java/awt/Robot/InfiniteLoopException.java line 63:

> 61:         long time = TimeUnit.NANOSECONDS.toSeconds(System.nanoTime() - start);
> 62:         if (time > 20) {
> 63:             throw new RuntimeException("To slow:" + time);

Suggestion:

            throw new RuntimeException("Too slow:" + time);

-------------

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

From serb at openjdk.java.net  Thu Nov 26 04:52:19 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Nov 2020 04:52:19 GMT
Subject: <Swing Dev> RFR: 8196100:
 javax/swing/text/JTextComponent/5074573/bug5074573.java fails [v2]
In-Reply-To: <-3MWzl2XJ7KjbSdtS3LZpz4mqE2hG4MLa5iL8XnDQLE=.1951234f-6a8c-4414-849b-c0f53ac52c16@github.com>
References: <odiw68_aqTfJSmoCMm6W2c2KCfaE4H1zbdAtazkmmvc=.1b78ca1d-7820-478a-b3db-e5a72dd422cb@github.com>
 <-3MWzl2XJ7KjbSdtS3LZpz4mqE2hG4MLa5iL8XnDQLE=.1951234f-6a8c-4414-849b-c0f53ac52c16@github.com>
Message-ID: <531EebiGo8bJfvHe3ZrVadlO_nmVpLLi-f_j4y7FOL4=.6cc2a9be-02cd-44ad-956e-cae80209031e@github.com>

On Wed, 25 Nov 2020 17:49:22 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/jdk/java/awt/Robot/InfiniteLoopException.java
>
> test/jdk/java/awt/Robot/InfiniteLoopException.java line 63:
> 
>> 61:         long time = TimeUnit.NANOSECONDS.toSeconds(System.nanoTime() - start);
>> 62:         if (time > 20) {
>> 63:             throw new RuntimeException("To slow:" + time);
> 
> Typo? Shouldn't it be "Too slow"?

yes, fixed.

-------------

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

From kizune at openjdk.java.net  Thu Nov 26 05:35:01 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 26 Nov 2020 05:35:01 GMT
Subject: <Swing Dev> RFR: 8196100:
 javax/swing/text/JTextComponent/5074573/bug5074573.java fails [v2]
In-Reply-To: <ZLl36uuUpcZmP2V6pLn_krKMVxLzl-tiBQkPrPuzVV8=.a9773fe5-c856-4390-a075-5e01184c095b@github.com>
References: <odiw68_aqTfJSmoCMm6W2c2KCfaE4H1zbdAtazkmmvc=.1b78ca1d-7820-478a-b3db-e5a72dd422cb@github.com>
 <ZLl36uuUpcZmP2V6pLn_krKMVxLzl-tiBQkPrPuzVV8=.a9773fe5-c856-4390-a075-5e01184c095b@github.com>
Message-ID: <H_2K68r66MokY4SuMyZJ5xirmBS6wx4Cvsw2jIgWCZA=.da1f32fd-0f6f-4e07-af92-896848dd7d61@github.com>

On Thu, 26 Nov 2020 04:52:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Here is a fix for one of the annoying bug, which causes random test failures in the CI.
>> 
>> We have a method Robot.waitForIdle(), which supposed to wait until the java and the native queue stabilized. The common use case is to click on the button or show the window, and call waitForIdle() which will wait until the native event will be dispatched by the X11/Windows/macOS as well as followed Java event(paint/focus/etc event) will be dispatched to the EDT.
>> 
>> Currently, it is implemented in this way:
>>   1. Flush the EventQueue, so all old events will be posted to EDT.
>>   2. Flush the native event queue, by posting the native event.
>>   3. Flush the EDT, by posting a java event.
>>   4. If some events(unrelated to waitForIdle machinery) were dispatched on steps 2. or 3. then repeat since step 1.
>> 
>> It is implemented that they because the native events caused by the OS usually generate the java events, and the java events may generate native events. So we have to wait for both queues (java/native).
>> 
>> But it has the next disadvantages:
>>  - It is implemented as a busy loop, which does not give a chance for the application to proceed further since it blocks 3 threads EDT/native toolkit thread like appkit/main thread.
>> - It throws the InfiniteLoop exception if the number of attempts is bigger than 20. And this limitation is too small because some tests generate much more events during startup.
>>  - Note that the timeout value for the realSync method is 10 seconds, and it was assumed that this method will not be executed longer, but it uses this timeout for all events flushing which can lead up to 600 seconds (20 iters * 3  calls * 10 seconds).
>> 
>> 
>> The fix:
>>  - Add a small delay to the method, so the app can do something useful when waitForIdle() is called
>>  - The timeout=10 second is taken care of, we calculate the "end" time and exits if it is exceeded
>>  - The maximum number of attempts is increased to 100 and InfiniteLoop is removed.
>> 
>> Note that I have made one additional change to the new realSync implementation. At the beginning of the method I call:
>>  EventQueue.invokeAndWait(() -> {/*dummy implementation*/});
>> It is needed to be sure that we flush the first event on EDT even if we spend more time than 10 seconds.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/awt/Robot/InfiniteLoopException.java

Marked as reviewed by kizune (Reviewer).

-------------

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

From ihse at openjdk.java.net  Thu Nov 26 08:36:00 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 26 Nov 2020 08:36:00 GMT
Subject: <Swing Dev> RFR: 8253753 Enable default constructor warning in
 client modules
In-Reply-To: <TE8bN62xLK1arlTDmI8Mu6LhKUjSOOZhcNFlKHifKGc=.10fe9076-1c0e-42cb-906d-a67020ed41b3@github.com>
References: <TE8bN62xLK1arlTDmI8Mu6LhKUjSOOZhcNFlKHifKGc=.10fe9076-1c0e-42cb-906d-a67020ed41b3@github.com>
Message-ID: <x_6FE_oiykMwhzt8aakXJYn8-YQr-XVkK_b-3GIJ-HA=.26340932-fa93-43fa-b9cd-6e23157e448e@github.com>

On Tue, 24 Nov 2020 19:10:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With the default constructors warnings in java.desktop and jdk.accessibility now fixed, the warning should be enabled in the build for those modules.

Looks  good!

Thank you for your continued efforts to clean up the code base.

-------------

Marked as reviewed by ihse (Reviewer).

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

From serb at openjdk.java.net  Thu Nov 26 08:48:02 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Nov 2020 08:48:02 GMT
Subject: <Swing Dev> Integrated: 8196100:
 javax/swing/text/JTextComponent/5074573/bug5074573.java fails
In-Reply-To: <odiw68_aqTfJSmoCMm6W2c2KCfaE4H1zbdAtazkmmvc=.1b78ca1d-7820-478a-b3db-e5a72dd422cb@github.com>
References: <odiw68_aqTfJSmoCMm6W2c2KCfaE4H1zbdAtazkmmvc=.1b78ca1d-7820-478a-b3db-e5a72dd422cb@github.com>
Message-ID: <MNkg0tKd0qpLOVlqJ-Y2z4YQl5xAlMrmmQbOSGMe0Qg=.4ba7702d-f94d-45b3-b0ec-74490395bb2c@github.com>

On Wed, 25 Nov 2020 00:15:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Here is a fix for one of the annoying bug, which causes random test failures in the CI.
> 
> We have a method Robot.waitForIdle(), which supposed to wait until the java and the native queue stabilized. The common use case is to click on the button or show the window, and call waitForIdle() which will wait until the native event will be dispatched by the X11/Windows/macOS as well as followed Java event(paint/focus/etc event) will be dispatched to the EDT.
> 
> Currently, it is implemented in this way:
>   1. Flush the EventQueue, so all old events will be posted to EDT.
>   2. Flush the native event queue, by posting the native event.
>   3. Flush the EDT, by posting a java event.
>   4. If some events(unrelated to waitForIdle machinery) were dispatched on steps 2. or 3. then repeat since step 1.
> 
> It is implemented that they because the native events caused by the OS usually generate the java events, and the java events may generate native events. So we have to wait for both queues (java/native).
> 
> But it has the next disadvantages:
>  - It is implemented as a busy loop, which does not give a chance for the application to proceed further since it blocks 3 threads EDT/native toolkit thread like appkit/main thread.
> - It throws the InfiniteLoop exception if the number of attempts is bigger than 20. And this limitation is too small because some tests generate much more events during startup.
>  - Note that the timeout value for the realSync method is 10 seconds, and it was assumed that this method will not be executed longer, but it uses this timeout for all events flushing which can lead up to 600 seconds (20 iters * 3  calls * 10 seconds).
> 
> 
> The fix:
>  - Add a small delay to the method, so the app can do something useful when waitForIdle() is called
>  - The timeout=10 second is taken care of, we calculate the "end" time and exits if it is exceeded
>  - The maximum number of attempts is increased to 100 and InfiniteLoop is removed.
> 
> Note that I have made one additional change to the new realSync implementation. At the beginning of the method I call:
>  EventQueue.invokeAndWait(() -> {/*dummy implementation*/});
> It is needed to be sure that we flush the first event on EDT even if we spend more time than 10 seconds.

This pull request has now been integrated.

Changeset: 973255c4
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/973255c4
Stats:     242 lines in 9 files changed: 192 ins; 20 del; 30 mod

8196100: javax/swing/text/JTextComponent/5074573/bug5074573.java fails

Reviewed-by: kizune

-------------

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

From github.com+70650887+skodanda at openjdk.java.net  Fri Nov 27 08:31:14 2020
From: github.com+70650887+skodanda at openjdk.java.net (skodanda)
Date: Fri, 27 Nov 2020 08:31:14 GMT
Subject: <Swing Dev> RFR: 8256187: [TEST_BUG] Automate bug4275046.java test
Message-ID: <kndzqOopgQ_heDaWjZI2IQrkBJTj8EHD7Uu21JEasX0=.f1430cee-d323-4435-825b-62ef41a2d29d@github.com>

Hi All, Could you please review this fix for JDK16?

Problem Description: Automate bug4275046.java test.

Fix: This fix includes rewriting the applet based test to a regular java application and its been automated too.

-------------

Commit messages:
 - Have removed all the tabs and replaced with 4 spaces. 
 - This fix includes rewriting the applet based test to a regular java application. Also, the test is being automated by retaining the same functionality as that of applet based app.

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

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

From aivanov at openjdk.java.net  Fri Nov 27 08:31:14 2020
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 27 Nov 2020 08:31:14 GMT
Subject: <Swing Dev> RFR: 8256187: [TEST_BUG] Automate bug4275046.java
 test
In-Reply-To: <kndzqOopgQ_heDaWjZI2IQrkBJTj8EHD7Uu21JEasX0=.f1430cee-d323-4435-825b-62ef41a2d29d@github.com>
References: <kndzqOopgQ_heDaWjZI2IQrkBJTj8EHD7Uu21JEasX0=.f1430cee-d323-4435-825b-62ef41a2d29d@github.com>
Message-ID: <Hmc3rdKeu5XPs1DX3GX0qznd2_trgaB-YuXyNU_PgYs=.2b9428b1-c894-4c78-a3a5-8ba81dae75e0@github.com>

On Thu, 26 Nov 2020 17:01:16 GMT, skodanda <github.com+70650887+skodanda at openjdk.org> wrote:

> Hi All, Could you please review this fix for JDK16?
> 
> Problem Description: Automate bug4275046.java test.
> 
> Fix: This fix includes rewriting the applet based test to a regular java application and its been automated too.

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JTable/4275046/bug4275046.java line 179:

> 177:             editedValue = table.getModel().getValueAt(0, 1);
> 178:             System.out.println("The edited value is = " + editedValue);
> 179: 	    testResult = editedValue.equals(EXPECTED_VALUE);

The indentation is wrong: the body of the method must be indented by four spaces.
There are other misindented blocks; maybe it's because of the tabs in the file. Please correct indentation.

-------------

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

From aivanov at openjdk.java.net  Fri Nov 27 12:39:56 2020
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 27 Nov 2020 12:39:56 GMT
Subject: <Swing Dev> RFR: 8256187: [TEST_BUG] Automate bug4275046.java
 test
In-Reply-To: <kndzqOopgQ_heDaWjZI2IQrkBJTj8EHD7Uu21JEasX0=.f1430cee-d323-4435-825b-62ef41a2d29d@github.com>
References: <kndzqOopgQ_heDaWjZI2IQrkBJTj8EHD7Uu21JEasX0=.f1430cee-d323-4435-825b-62ef41a2d29d@github.com>
Message-ID: <JqfVw_AWuQSq8_tBYVxmBKP4K4isB92JeVlI8BYFtss=.8ea15b15-5f09-4d7f-876d-b6901617d2f5@github.com>

On Thu, 26 Nov 2020 17:01:16 GMT, skodanda <github.com+70650887+skodanda at openjdk.org> wrote:

> Hi All, Could you please review this fix for JDK16?
> 
> Problem Description: Automate bug4275046.java test.
> 
> Fix: This fix includes rewriting the applet based test to a regular java application and its been automated too.

Marked as reviewed by aivanov (Reviewer).

-------------

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

From darcy at openjdk.java.net  Fri Nov 27 21:34:54 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 27 Nov 2020 21:34:54 GMT
Subject: <Swing Dev> Integrated: 8253753 Enable default constructor warning
 in client modules
In-Reply-To: <TE8bN62xLK1arlTDmI8Mu6LhKUjSOOZhcNFlKHifKGc=.10fe9076-1c0e-42cb-906d-a67020ed41b3@github.com>
References: <TE8bN62xLK1arlTDmI8Mu6LhKUjSOOZhcNFlKHifKGc=.10fe9076-1c0e-42cb-906d-a67020ed41b3@github.com>
Message-ID: <cvs4ac6WaNuHmsqkf7FKp9CDtp13RxdkL9JGlK2kBiM=.b7ccfd40-092c-44b7-97cb-8700e5403e94@github.com>

On Tue, 24 Nov 2020 19:10:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With the default constructors warnings in java.desktop and jdk.accessibility now fixed, the warning should be enabled in the build for those modules.

This pull request has now been integrated.

Changeset: 65137ff0
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/65137ff0
Stats:     5 lines in 1 file changed: 0 ins; 5 del; 0 mod

8253753: Enable default constructor warning in client modules

Reviewed-by: prr, serb, ihse

-------------

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

From psadhukhan at openjdk.java.net  Mon Nov 30 04:51:55 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 30 Nov 2020 04:51:55 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <VsiKqbB9re5mRsLRYwVAOSxAhkNA6EGkxN2UD0kMeoI=.6e6d2051-1d64-497d-abd8-b8197a3caa0b@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <1tz535gufWoNJ_jO-3KwmSsOfDHQN9Cqz-lvespNJpU=.bac9344b-310c-4af4-a623-0a29b2cc4eec@github.com>
 <5EU6riZkVpPCEF4g9XxJMtyfXiFEeV5A7Dd506uBn_w=.c3f68824-7756-4049-a3e2-52156bd8f014@github.com>
 <N7p7UzkSJr16E6KhZYLGLSlhVtXNNtBUkTz-USdjVzg=.825ed7ab-81e4-428e-b1ba-ec4646536393@github.com>
 <rGXF9tOcJqQqSVEumo3gRN7jkrWLRjE_6cRJPgDWBFU=.c4be29cb-427c-4ac2-bd5d-7c2393744d03@github.com>
 <Vmq_aQuvjv30FpNqhdSXpzOvK9fPsOFw1CVoGAey6eU=.f5b9d2e6-0b9b-4bc7-96ac-43fa6200c56c@github.com>
 <VsiKqbB9re5mRsLRYwVAOSxAhkNA6EGkxN2UD0kMeoI=.6e6d2051-1d64-497d-abd8-b8197a3caa0b@github.com>
Message-ID: <ZgV7g3InFMypbgbeiockjSDojhBES1E0dvs-XK4Dy0w=.1293ca34-89cb-4e22-a60f-49027b48dadd@github.com>

On Wed, 25 Nov 2020 03:19:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> When inactive, I use 0 0 0 192. As far as I can tell, this does not correspond to a named color.
>>> It would be wrong to assume that Apple only uses named colors in their UIs.
>>> The named colors are for application developers, not for Apple itself.
>> 
>> The problem here is that we do not control the color of the tab pane, it is controlled by Apple, and if we hardcore some color on our side we will get the same bugs again and again. I am sure that a similar bug will come in the dark mode if we will enable it.
>
> Since color of tabpane is controlled by Apple, Can you point me to the code where we call Apple api to draw the color of tabpane?

Since the apple forum post is still unanswered and if we want it to be fixed for JDK16, I dont see any other alternative than to fix by what I did in the 1st iteration of this by hardcoding. I dont think we are going to enable dark mode in JDk16 so we will have time to think on that when we enable that and hopefully Apple will come back by that time and we can revisit this.

-------------

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

From psadhukhan at openjdk.java.net  Mon Nov 30 08:56:57 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 30 Nov 2020 08:56:57 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <ZgV7g3InFMypbgbeiockjSDojhBES1E0dvs-XK4Dy0w=.1293ca34-89cb-4e22-a60f-49027b48dadd@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <1tz535gufWoNJ_jO-3KwmSsOfDHQN9Cqz-lvespNJpU=.bac9344b-310c-4af4-a623-0a29b2cc4eec@github.com>
 <5EU6riZkVpPCEF4g9XxJMtyfXiFEeV5A7Dd506uBn_w=.c3f68824-7756-4049-a3e2-52156bd8f014@github.com>
 <N7p7UzkSJr16E6KhZYLGLSlhVtXNNtBUkTz-USdjVzg=.825ed7ab-81e4-428e-b1ba-ec4646536393@github.com>
 <rGXF9tOcJqQqSVEumo3gRN7jkrWLRjE_6cRJPgDWBFU=.c4be29cb-427c-4ac2-bd5d-7c2393744d03@github.com>
 <Vmq_aQuvjv30FpNqhdSXpzOvK9fPsOFw1CVoGAey6eU=.f5b9d2e6-0b9b-4bc7-96ac-43fa6200c56c@github.com>
 <VsiKqbB9re5mRsLRYwVAOSxAhkNA6EGkxN2UD0kMeoI=.6e6d2051-1d64-497d-abd8-b8197a3caa0b@github.com>
 <ZgV7g3InFMypbgbeiockjSDojhBES1E0dvs-XK4Dy0w=.1293ca34-89cb-4e22-a60f-49027b48dadd@github.com>
Message-ID: <8B_8kveKu6tB1Ob76SW3zQX8QowY_U3r2-VM1QxXsmY=.45a9100b-8ad4-40b7-a316-00b39735d8f0@github.com>

On Mon, 30 Nov 2020 04:49:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Since color of tabpane is controlled by Apple, Can you point me to the code where we call Apple api to draw the color of tabpane?
>
> Since the apple forum post is still unanswered and if we want it to be fixed for JDK16, I dont see any other alternative than to fix by what I did in the 1st iteration of this by hardcoding. I dont think we are going to enable dark mode in JDk16 so we will have time to think on that when we enable that and hopefully Apple will come back by that time and we can revisit this.

I dot see any further legibility issue with dark mode in macos11 (set with General->Theme)with SwingSet2 unless there's a dark mode commandline option to enable it for Java, which I am unaware of.

-------------

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

From psadhukhan at openjdk.java.net  Mon Nov 30 14:52:04 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 30 Nov 2020 14:52:04 GMT
Subject: <Swing Dev> RFR: 8256187: [TEST_BUG] Automate bug4275046.java
 test
In-Reply-To: <kndzqOopgQ_heDaWjZI2IQrkBJTj8EHD7Uu21JEasX0=.f1430cee-d323-4435-825b-62ef41a2d29d@github.com>
References: <kndzqOopgQ_heDaWjZI2IQrkBJTj8EHD7Uu21JEasX0=.f1430cee-d323-4435-825b-62ef41a2d29d@github.com>
Message-ID: <krnmB_Cgw7SXU1FpJZ_LFadpVpjfHxY367CNA2yiOJs=.a5c45b70-3c69-4fa3-831a-0fa0cd27ee51@github.com>

On Thu, 26 Nov 2020 17:01:16 GMT, skodanda <github.com+70650887+skodanda at openjdk.org> wrote:

> Hi All, Could you please review this fix for JDK16?
> 
> Problem Description: Automate bug4275046.java test.
> 
> Fix: This fix includes rewriting the applet based test to a regular java application and its been automated too.

Marked as reviewed by psadhukhan (Reviewer).

-------------

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

From javalists at cbfiddle.com  Mon Nov 30 15:24:56 2020
From: javalists at cbfiddle.com (Alan Snyder)
Date: Mon, 30 Nov 2020 07:24:56 -0800
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <8B_8kveKu6tB1Ob76SW3zQX8QowY_U3r2-VM1QxXsmY=.45a9100b-8ad4-40b7-a316-00b39735d8f0@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <1tz535gufWoNJ_jO-3KwmSsOfDHQN9Cqz-lvespNJpU=.bac9344b-310c-4af4-a623-0a29b2cc4eec@github.com>
 <5EU6riZkVpPCEF4g9XxJMtyfXiFEeV5A7Dd506uBn_w=.c3f68824-7756-4049-a3e2-52156bd8f014@github.com>
 <N7p7UzkSJr16E6KhZYLGLSlhVtXNNtBUkTz-USdjVzg=.825ed7ab-81e4-428e-b1ba-ec4646536393@github.com>
 <rGXF9tOcJqQqSVEumo3gRN7jkrWLRjE_6cRJPgDWBFU=.c4be29cb-427c-4ac2-bd5d-7c2393744d03@github.com>
 <Vmq_aQuvjv30FpNqhdSXpzOvK9fPsOFw1CVoGAey6eU=.f5b9d2e6-0b9b-4bc7-96ac-43fa6200c56c@github.com>
 <VsiKqbB9re5mRsLRYwVAOSxAhkNA6EGkxN2UD0kMeoI=.6e6d2051-1d64-497d-abd8-b8197a3caa0b@github.com>
 <ZgV7g3InFMypbgbeiockjSDojhBES1E0dvs-XK4Dy0w=.1293ca34-89cb-4e22-a60f-49027b48dadd@github.com>
 <8B_8kveKu6tB1Ob76SW3zQX8QowY_U3r2-VM1QxXsmY=.45a9100b-8ad4-40b7-a316-00b39735d8f0@github.com>
Message-ID: <CEBFD4E5-EF8C-427A-9A2E-DA219D77C994@cbfiddle.com>

Isn?t that what -Dapple.awt.application.appearance=system does?

> On Nov 30, 2020, at 12:56 AM, Prasanta Sadhukhan <psadhukhan at openjdk.java.net> wrote:
> 
> On Mon, 30 Nov 2020 04:49:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:
> 
>>> Since color of tabpane is controlled by Apple, Can you point me to the code where we call Apple api to draw the color of tabpane?
>> 
>> Since the apple forum post is still unanswered and if we want it to be fixed for JDK16, I dont see any other alternative than to fix by what I did in the 1st iteration of this by hardcoding. I dont think we are going to enable dark mode in JDk16 so we will have time to think on that when we enable that and hopefully Apple will come back by that time and we can revisit this.
> 
> I dot see any further legibility issue with dark mode in macos11 (set with General->Theme)with SwingSet2 unless there's a dark mode commandline option to enable it for Java, which I am unaware of.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/1182
> 


From psadhukhan at openjdk.java.net  Mon Nov 30 15:45:56 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 30 Nov 2020 15:45:56 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <8B_8kveKu6tB1Ob76SW3zQX8QowY_U3r2-VM1QxXsmY=.45a9100b-8ad4-40b7-a316-00b39735d8f0@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <1tz535gufWoNJ_jO-3KwmSsOfDHQN9Cqz-lvespNJpU=.bac9344b-310c-4af4-a623-0a29b2cc4eec@github.com>
 <5EU6riZkVpPCEF4g9XxJMtyfXiFEeV5A7Dd506uBn_w=.c3f68824-7756-4049-a3e2-52156bd8f014@github.com>
 <N7p7UzkSJr16E6KhZYLGLSlhVtXNNtBUkTz-USdjVzg=.825ed7ab-81e4-428e-b1ba-ec4646536393@github.com>
 <rGXF9tOcJqQqSVEumo3gRN7jkrWLRjE_6cRJPgDWBFU=.c4be29cb-427c-4ac2-bd5d-7c2393744d03@github.com>
 <Vmq_aQuvjv30FpNqhdSXpzOvK9fPsOFw1CVoGAey6eU=.f5b9d2e6-0b9b-4bc7-96ac-43fa6200c56c@github.com>
 <VsiKqbB9re5mRsLRYwVAOSxAhkNA6EGkxN2UD0kMeoI=.6e6d2051-1d64-497d-abd8-b8197a3caa0b@github.com>
 <ZgV7g3InFMypbgbeiockjSDojhBES1E0dvs-XK4Dy0w=.1293ca34-89cb-4e22-a60f-49027b48dadd@github.com>
 <8B_8kveKu6tB1Ob76SW3zQX8QowY_U3r2-VM1QxXsmY=.45a9100b-8ad4-40b7-a316-00b39735d8f0@github.com>
Message-ID: <BOUSRjWVG1PbfBuak1YrfHzlKCj4cRYz920ivdjmHE0=.59cb1532-0836-4d6d-8001-471fe9b1290f@github.com>

On Mon, 30 Nov 2020 08:54:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Since the apple forum post is still unanswered and if we want it to be fixed for JDK16, I dont see any other alternative than to fix by what I did in the 1st iteration of this by hardcoding. I dont think we are going to enable dark mode in JDk16 so we will have time to think on that when we enable that and hopefully Apple will come back by that time and we can revisit this.
>
> I dot see any further legibility issue with dark mode in macos11 (set with General->Theme)with SwingSet2 unless there's a dark mode commandline option to enable it for Java, which I am unaware of.

Ok. Tried that but it does not affect tabPane legibility issue more than what it is seen in normal theme, so the 1st fix should be ok.

-------------

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

From serb at openjdk.java.net  Mon Nov 30 17:33:58 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 30 Nov 2020 17:33:58 GMT
Subject: <Swing Dev> RFR: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions [v2]
In-Reply-To: <Ku_uQ7fKW6mm4r1mYQVgw8EizOyibJp51u_A68M26lY=.85d8e475-7bfe-451b-b4f1-6caca155b35b@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
 <Ku_uQ7fKW6mm4r1mYQVgw8EizOyibJp51u_A68M26lY=.85d8e475-7bfe-451b-b4f1-6caca155b35b@github.com>
Message-ID: <EyZceoRBKmp4IOfIwSnRsDS9aI1Nl8UNWLZmIXVouOw=.18bc37ca-e093-4b50-b3d7-44374c1d76b2@github.com>

On Wed, 14 Oct 2020 01:52:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   modified the test after suggestions
>
> Changes requested by serb (Reviewer).

@prsadhuk looks like your comment was added using the wrong account.

-------------

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

From github.com+70650887+skodanda at openjdk.java.net  Mon Nov 30 17:40:01 2020
From: github.com+70650887+skodanda at openjdk.java.net (skodanda)
Date: Mon, 30 Nov 2020 17:40:01 GMT
Subject: <Swing Dev> Integrated: 8256187: [TEST_BUG] Automate
 bug4275046.java test
In-Reply-To: <kndzqOopgQ_heDaWjZI2IQrkBJTj8EHD7Uu21JEasX0=.f1430cee-d323-4435-825b-62ef41a2d29d@github.com>
References: <kndzqOopgQ_heDaWjZI2IQrkBJTj8EHD7Uu21JEasX0=.f1430cee-d323-4435-825b-62ef41a2d29d@github.com>
Message-ID: <SQyfsNyS8cW1FYDCydF5tt-tbvJ5gaa4aNl4Rir6YQE=.3be555e2-fd5f-4d30-8725-a25e81c4008f@github.com>

On Thu, 26 Nov 2020 17:01:16 GMT, skodanda <github.com+70650887+skodanda at openjdk.org> wrote:

> Hi All, Could you please review this fix for JDK16?
> 
> Problem Description: Automate bug4275046.java test.
> 
> Fix: This fix includes rewriting the applet based test to a regular java application and its been automated too.

This pull request has now been integrated.

Changeset: 8aaee53c
Author:    skodanda <70650887+skodanda at users.noreply.github.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8aaee53c
Stats:     192 lines in 1 file changed: 192 ins; 0 del; 0 mod

8256187: [TEST_BUG] Automate bug4275046.java test

Reviewed-by: aivanov, psadhukhan

-------------

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

From psadhukhan at openjdk.java.net  Mon Nov 30 17:46:00 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 30 Nov 2020 17:46:00 GMT
Subject: <Swing Dev> RFR: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions [v2]
In-Reply-To: <EyZceoRBKmp4IOfIwSnRsDS9aI1Nl8UNWLZmIXVouOw=.18bc37ca-e093-4b50-b3d7-44374c1d76b2@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
 <Ku_uQ7fKW6mm4r1mYQVgw8EizOyibJp51u_A68M26lY=.85d8e475-7bfe-451b-b4f1-6caca155b35b@github.com>
 <EyZceoRBKmp4IOfIwSnRsDS9aI1Nl8UNWLZmIXVouOw=.18bc37ca-e093-4b50-b3d7-44374c1d76b2@github.com>
Message-ID: <sDdPHJvv1ho7TWT6W8shIa8DZMJX940sPcHPrQoCRGo=.4bda0a66-99c3-4b4b-886a-fc4de645c46f@github.com>

On Mon, 30 Nov 2020 17:30:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Changes requested by serb (Reviewer).
>
> @prsadhuk looks like your comment was added using the wrong account.

not wrong but different account but that doesnot make the comment invalid, I guess.

-------------

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

From serb at openjdk.java.net  Mon Nov 30 17:51:04 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 30 Nov 2020 17:51:04 GMT
Subject: <Swing Dev> RFR: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions [v2]
In-Reply-To: <sDdPHJvv1ho7TWT6W8shIa8DZMJX940sPcHPrQoCRGo=.4bda0a66-99c3-4b4b-886a-fc4de645c46f@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
 <Ku_uQ7fKW6mm4r1mYQVgw8EizOyibJp51u_A68M26lY=.85d8e475-7bfe-451b-b4f1-6caca155b35b@github.com>
 <EyZceoRBKmp4IOfIwSnRsDS9aI1Nl8UNWLZmIXVouOw=.18bc37ca-e093-4b50-b3d7-44374c1d76b2@github.com>
 <sDdPHJvv1ho7TWT6W8shIa8DZMJX940sPcHPrQoCRGo=.4bda0a66-99c3-4b4b-886a-fc4de645c46f@github.com>
Message-ID: <xqjdFHtMGRipN_MU3WgYAURNApoZw16-f9-hexRN1YE=.2221e2f7-6283-4d11-8287-c5aeaf03b9b8@github.com>

On Mon, 30 Nov 2020 17:43:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> not wrong but different account but that doesnot make the comment invalid, I guess.

But nobody sees it, it is hidden.

-------------

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

From psadhukhan at openjdk.java.net  Mon Nov 30 17:56:57 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 30 Nov 2020 17:56:57 GMT
Subject: <Swing Dev> RFR: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions [v2]
In-Reply-To: <xqjdFHtMGRipN_MU3WgYAURNApoZw16-f9-hexRN1YE=.2221e2f7-6283-4d11-8287-c5aeaf03b9b8@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
 <Ku_uQ7fKW6mm4r1mYQVgw8EizOyibJp51u_A68M26lY=.85d8e475-7bfe-451b-b4f1-6caca155b35b@github.com>
 <EyZceoRBKmp4IOfIwSnRsDS9aI1Nl8UNWLZmIXVouOw=.18bc37ca-e093-4b50-b3d7-44374c1d76b2@github.com>
 <sDdPHJvv1ho7TWT6W8shIa8DZMJX940sPcHPrQoCRGo=.4bda0a66-99c3-4b4b-886a-fc4de645c46f@github.com>
 <xqjdFHtMGRipN_MU3WgYAURNApoZw16-f9-hexRN1YE=.2221e2f7-6283-4d11-8287-c5aeaf03b9b8@github.com>
Message-ID: <DVUZhMVf3_lmQ6QCXXzWdysP66v-soh06u6kkBEFS-k=.f55767c7-5cd4-4327-80c4-b2c0c9ef9b97@github.com>

On Mon, 30 Nov 2020 17:47:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> not wrong but different account but that doesnot make the comment invalid, I guess.
>
>> not wrong but different account but that doesnot make the comment invalid, I guess.
> 
> But nobody sees it, it is hidden.

Well, the comment was added on Oct 15 and it got hidden on Oct28 because the ac was not of github author/committer. I think the fix submitter should have seen the comment lying there for 2 weeks before it got hidden.

-------------

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