From serb at openjdk.java.net  Sun Jan  3 02:24:57 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 3 Jan 2021 02:24:57 GMT
Subject: <Swing Dev> RFR: 8258924:
 javax/swing/JSplitPane/4201995/bug4201995.java fails in GTk L&F [v2]
In-Reply-To: <DR9unZ-cIskaInDB7XCusm1lLADglmG3Kr3Ue4vECgQ=.548aa562-2f39-4a69-b374-0d7d75495193@github.com>
References: <iZRGIGhDPuK1v-RuM3HKE-vDdwlY_TRzzWznl6dDKnM=.2a81b107-fe45-46ac-ab0a-09daf89478d1@github.com>
 <DR9unZ-cIskaInDB7XCusm1lLADglmG3Kr3Ue4vECgQ=.548aa562-2f39-4a69-b374-0d7d75495193@github.com>
Message-ID: <NsYygVjpfddat-7Dqe_6RBKaASEiuxH4vTVjVPwjAw0=.9177a376-01cb-40dd-bb5c-79626b6832cc@github.com>

On Thu, 31 Dec 2020 07:57:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> This test tests whether SplitPane is opaque or not but in nimbus and subseqeuently in GTK L&F the opaque property is set to false [1]
>> As nimbus is already handled in the test, it is modified to handle GTK L&F too. Along with this modification, the test is also updated to test all installed L&Fs.
>> Mach5 job running for several iterations for all platform is ok. Link in JBS.
>> 
>> [1] https://raw.githubusercontent.com/openjdk/jdk/master/src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf
>>       uiComponent opaque="false" type="javax.swing.JSplitPane" name="SplitPane" ui="SplitPaneUI" subregion="false"
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Continue to next L&F if current one is unsupported

Marked as reviewed by serb (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Mon Jan  4 04:35:56 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 4 Jan 2021 04:35:56 GMT
Subject: <Swing Dev> Integrated: 8258924:
 javax/swing/JSplitPane/4201995/bug4201995.java fails in GTk L&F
In-Reply-To: <iZRGIGhDPuK1v-RuM3HKE-vDdwlY_TRzzWznl6dDKnM=.2a81b107-fe45-46ac-ab0a-09daf89478d1@github.com>
References: <iZRGIGhDPuK1v-RuM3HKE-vDdwlY_TRzzWznl6dDKnM=.2a81b107-fe45-46ac-ab0a-09daf89478d1@github.com>
Message-ID: <uEvNgd63gHlrOFKPO4SsuE2Rk_2GUX7Q3Xp8-T29bv8=.6cd7e75d-b546-4529-bed1-f173224fea01@github.com>

On Thu, 24 Dec 2020 07:33:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test tests whether SplitPane is opaque or not but in nimbus and subseqeuently in GTK L&F the opaque property is set to false [1]
> As nimbus is already handled in the test, it is modified to handle GTK L&F too. Along with this modification, the test is also updated to test all installed L&Fs.
> Mach5 job running for several iterations for all platform is ok. Link in JBS.
> 
> [1] https://raw.githubusercontent.com/openjdk/jdk/master/src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf
>       uiComponent opaque="false" type="javax.swing.JSplitPane" name="SplitPane" ui="SplitPaneUI" subregion="false"

This pull request has now been integrated.

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

8258924: javax/swing/JSplitPane/4201995/bug4201995.java fails in GTk L&F

Reviewed-by: serb

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

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

From psadhukhan at openjdk.java.net  Mon Jan  4 04:39:57 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 4 Jan 2021 04:39:57 GMT
Subject: <Swing Dev> Withdrawn: 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: <GAv1GXDaeGx8HFRwQDJpoOLUMIKojB9RLPOEha9WwCc=.be57d065-a1bc-4f98-9964-71c231e85452@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.

This pull request has been closed without being integrated.

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

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

From psadhukhan at openjdk.java.net  Mon Jan  4 05:14:04 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 4 Jan 2021 05:14:04 GMT
Subject: <Swing Dev> RFR: 8193942: Regression automated test
 '/open/test/jdk/javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java'
 fails
Message-ID: <o9Mocgk159sqrmM-Vr-Oh_Y-GB3mECmXxuLCKyODIZU=.b37d10be-2364-4ad1-aeac-4200d11dad65@github.com>

This test use to fail in macos in mach5 nightly testing long time back. It used to fail in ubuntu17.10 due to unsupported wayland display mode. Recent run of this test on supported platforms does not fail.
Modified the test slightly to be consistent with other test regarding robot delays, moved frame to center of screen.
Mach5 job running several iterations of the test in all platforms is ok. Link in JBS.

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

Commit messages:
 - 8193942: Regression automated test '/open/test/jdk/javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java' fails

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

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

From psadhukhan at openjdk.java.net  Mon Jan  4 06:15:07 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 4 Jan 2021 06:15:07 GMT
Subject: <Swing Dev> RFR: 8196466:
 javax/swing/JFileChooser/8062561/bug8062561.java fails
Message-ID: <bzwxckNj36etDYXOeTj8UT2hhBv-tu-YMMAYmk5BoKE=.d8f98a77-1375-4143-b069-8d6e1d9a298a@github.com>

This test was marked for "windows only" in https://github.com/openjdk/jdk/commit/7cb9e5821e0e5bcc483bc7c587ea921e9b515e77 in JDK-8198333
but the test is redundantly problem listed for linux and mac. 
We can remove the test from ProblemList as it is being run in mach5 on windows without any issue and it will not run on linux,mac as 8062561 fix for which this test was created is windows specific.

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

Commit messages:
 - 8196466: javax/swing/JFileChooser/8062561/bug8062561.java fails

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

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

From serb at openjdk.java.net  Mon Jan  4 06:30:53 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 4 Jan 2021 06:30:53 GMT
Subject: <Swing Dev> RFR: 8196466:
 javax/swing/JFileChooser/8062561/bug8062561.java fails
In-Reply-To: <bzwxckNj36etDYXOeTj8UT2hhBv-tu-YMMAYmk5BoKE=.d8f98a77-1375-4143-b069-8d6e1d9a298a@github.com>
References: <bzwxckNj36etDYXOeTj8UT2hhBv-tu-YMMAYmk5BoKE=.d8f98a77-1375-4143-b069-8d6e1d9a298a@github.com>
Message-ID: <HEFZRHC764g_RQAU9vJVElVLwZgaGyrKwfbR2ehhMAs=.9e8cc5d6-ecc7-4612-afba-a0a06b423a10@github.com>

On Mon, 4 Jan 2021 06:06:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test was marked for "windows only" in https://github.com/openjdk/jdk/commit/7cb9e5821e0e5bcc483bc7c587ea921e9b515e77 in JDK-8198333
> but the test is redundantly problem listed for linux and mac. 
> We can remove the test from ProblemList as it is being run in mach5 on windows without any issue and it will not run on linux,mac as 8062561 fix for which this test was created is windows specific.

Marked as reviewed by serb (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Mon Jan  4 06:38:57 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 4 Jan 2021 06:38:57 GMT
Subject: <Swing Dev> Integrated: 8196466:
 javax/swing/JFileChooser/8062561/bug8062561.java fails
In-Reply-To: <bzwxckNj36etDYXOeTj8UT2hhBv-tu-YMMAYmk5BoKE=.d8f98a77-1375-4143-b069-8d6e1d9a298a@github.com>
References: <bzwxckNj36etDYXOeTj8UT2hhBv-tu-YMMAYmk5BoKE=.d8f98a77-1375-4143-b069-8d6e1d9a298a@github.com>
Message-ID: <AcRHdGmQzOc4lvTQN3wQmVVs2WiqpAn9wbTA-mI3vV8=.3dd082d0-c04d-421a-ba51-9586ad217c3b@github.com>

On Mon, 4 Jan 2021 06:06:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test was marked for "windows only" in https://github.com/openjdk/jdk/commit/7cb9e5821e0e5bcc483bc7c587ea921e9b515e77 in JDK-8198333
> but the test is redundantly problem listed for linux and mac. 
> We can remove the test from ProblemList as it is being run in mach5 on windows without any issue and it will not run on linux,mac as 8062561 fix for which this test was created is windows specific.

This pull request has now been integrated.

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

8196466: javax/swing/JFileChooser/8062561/bug8062561.java fails

Reviewed-by: serb

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

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

From serb at openjdk.java.net  Mon Jan  4 06:43:54 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 4 Jan 2021 06:43:54 GMT
Subject: <Swing Dev> RFR: 8193942: Regression automated test
 '/open/test/jdk/javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java'
 fails
In-Reply-To: <o9Mocgk159sqrmM-Vr-Oh_Y-GB3mECmXxuLCKyODIZU=.b37d10be-2364-4ad1-aeac-4200d11dad65@github.com>
References: <o9Mocgk159sqrmM-Vr-Oh_Y-GB3mECmXxuLCKyODIZU=.b37d10be-2364-4ad1-aeac-4200d11dad65@github.com>
Message-ID: <OzDj2KJiMi-kJYQRpGzMzSaq5n5Xso3Iek0blFKTmQo=.39f69d5f-4a92-496d-a727-00b5e5e7285a@github.com>

On Mon, 4 Jan 2021 05:09:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test use to fail in macos in mach5 nightly testing long time back. It used to fail in ubuntu17.10 due to unsupported wayland display mode. Recent run of this test on supported platforms does not fail.
> Modified the test slightly to be consistent with other test regarding robot delays, moved frame to center of screen.
> Mach5 job running several iterations of the test in all platforms is ok. Link in JBS.

Please check that the test will work if the Windows uses 125% , see https://bugs.openjdk.java.net/browse/JDK-8193942?focusedCommentId=14150509&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14150509

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

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

From psadhukhan at openjdk.java.net  Mon Jan  4 07:01:56 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 4 Jan 2021 07:01:56 GMT
Subject: <Swing Dev> RFR: 8193942: Regression automated test
 '/open/test/jdk/javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java'
 fails
In-Reply-To: <OzDj2KJiMi-kJYQRpGzMzSaq5n5Xso3Iek0blFKTmQo=.39f69d5f-4a92-496d-a727-00b5e5e7285a@github.com>
References: <o9Mocgk159sqrmM-Vr-Oh_Y-GB3mECmXxuLCKyODIZU=.b37d10be-2364-4ad1-aeac-4200d11dad65@github.com>
 <OzDj2KJiMi-kJYQRpGzMzSaq5n5Xso3Iek0blFKTmQo=.39f69d5f-4a92-496d-a727-00b5e5e7285a@github.com>
Message-ID: <a3VPMCuX4SB6V1cqcGLXAO8rrKx3-AZfy5YDvvm_5jI=.c61bf8a1-ed2c-434f-a652-2648f8930454@github.com>

On Mon, 4 Jan 2021 06:40:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This test use to fail in macos in mach5 nightly testing long time back. It used to fail in ubuntu17.10 due to unsupported wayland display mode. Recent run of this test on supported platforms does not fail.
>> Modified the test slightly to be consistent with other test regarding robot delays, moved frame to center of screen.
>> Mach5 job running several iterations of the test in all platforms is ok. Link in JBS.
>
> Please check that the test will work if the Windows uses 125% , see https://bugs.openjdk.java.net/browse/JDK-8193942?focusedCommentId=14150509&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14150509

Yes, it works

reason: User specified action: run main/othervm -Dsun.java2d.uiScale=1.25 -Dsun.java2d.d3d=true ScaledFrameBackgroundTest
Mode: othervm [/othervm specified]
Additional options from @modules: --add-modules java.desktop
elapsed time (seconds): 6.049
----------configuration:(3/43)----------
Boot Layer
  add modules: java.desktop

----------System.out:(0/0)----------
----------System.err:(1/16)----------
STATUS:Passed.

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

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

From github.com+70650887+skodanda at openjdk.java.net  Mon Jan  4 09:15:14 2021
From: github.com+70650887+skodanda at openjdk.java.net (K Suman Rajkumaar)
Date: Mon, 4 Jan 2021 09:15:14 GMT
Subject: <Swing Dev> RFR: JDK-8258884: [TEST_BUG] Convert applet-based
 test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a
 regular java test [v2]
In-Reply-To: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
References: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
Message-ID: <Qx5VCw7ATdgECt_vASUXHWTH19lWoreG04lxIvBFmXg=.16580897-696a-4807-a358-7938d918b99a@github.com>

> Hi All, Could you please review this fix for JDK16?
> 
> Problem Description: The test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java is applet based.
> 
> Fix: Rewritten the above applet based test to a regular java test.
> 
> Best Regards,
> K Suman Rajkumaar

K Suman Rajkumaar has updated the pull request incrementally with one additional commit since the last revision:

  Update bug8031573.java
  
  Corrected the jtreg tag from @run main bug8031573 to @run main/manual bug8031573 to make this test as a manual test.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1878/files
  - new: https://git.openjdk.java.net/jdk/pull/1878/files/9dbc094d..5f1ab6ea

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

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

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

From kizune at openjdk.java.net  Mon Jan  4 10:12:06 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 4 Jan 2021 10:12:06 GMT
Subject: <Swing Dev> RFR: 8258643:
 javax/swing/JComponent/7154030/bug7154030.java failed with "Exception:
 Failed to hide opaque button"
Message-ID: <-y0HLftBY_vzkjcq-mZjJpVoGRzwt9AT3naP7_nZItQ=.31305f63-b5e4-4a7e-ad01-998828f629a1@github.com>

8258643: javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button"

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

Commit messages:
 - 8258643: javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button"
 - Merge pull request #7 from openjdk/master
 - Merge pull request #6 from openjdk/master
 - Merge pull request #5 from openjdk/master
 - Merge pull request #4 from openjdk/master
 - Merge pull request #3 from openjdk/master
 - Merge pull request #2 from openjdk/master
 - Merge pull request #1 from openjdk/master

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

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

From psadhukhan at openjdk.java.net  Mon Jan  4 10:34:56 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 4 Jan 2021 10:34:56 GMT
Subject: <Swing Dev> RFR: 8258643:
 javax/swing/JComponent/7154030/bug7154030.java failed with "Exception:
 Failed to hide opaque button"
In-Reply-To: <-y0HLftBY_vzkjcq-mZjJpVoGRzwt9AT3naP7_nZItQ=.31305f63-b5e4-4a7e-ad01-998828f629a1@github.com>
References: <-y0HLftBY_vzkjcq-mZjJpVoGRzwt9AT3naP7_nZItQ=.31305f63-b5e4-4a7e-ad01-998828f629a1@github.com>
Message-ID: <9daNtfQdavO1sgoceBdTa_vmkmwqv2ZgwWZs5MTb3l0=.9644c009-e539-469e-adc6-e0c499c6300e@github.com>

On Mon, 4 Jan 2021 10:07:08 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8258643: javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button"

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

> 103:             locy = bounds.y + insets.top;
> 104:             frw = bounds.width - insets.left - insets.right;
> 105:             frh = bounds.height - insets.top - insets.bottom;

If the intent is to do away with window decorations, can't we just call frame.setUndecorated instead of this snippet?
Also, it will be better to post a mach5 job in JBS running several iterations as it fails in mach5 primarily.

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

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

From serb at openjdk.java.net  Mon Jan  4 11:24:59 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 4 Jan 2021 11:24:59 GMT
Subject: <Swing Dev> RFR: 8258643:
 javax/swing/JComponent/7154030/bug7154030.java failed with "Exception:
 Failed to hide opaque button"
In-Reply-To: <9daNtfQdavO1sgoceBdTa_vmkmwqv2ZgwWZs5MTb3l0=.9644c009-e539-469e-adc6-e0c499c6300e@github.com>
References: <-y0HLftBY_vzkjcq-mZjJpVoGRzwt9AT3naP7_nZItQ=.31305f63-b5e4-4a7e-ad01-998828f629a1@github.com>
 <9daNtfQdavO1sgoceBdTa_vmkmwqv2ZgwWZs5MTb3l0=.9644c009-e539-469e-adc6-e0c499c6300e@github.com>
Message-ID: <b4uuQ7ykgo_xzL64uqPh_PT_adZ3UvUqqnQww132k1U=.6ab15520-77e6-4f2e-8413-042cbafbc079@github.com>

On Mon, 4 Jan 2021 10:32:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> 8258643: javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button"
>
> test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 105:
> 
>> 103:             locy = bounds.y + insets.top;
>> 104:             frw = bounds.width - insets.left - insets.right;
>> 105:             frh = bounds.height - insets.top - insets.bottom;
> 
> If the intent is to do away with window decorations, can't we just call frame.setUndecorated instead of this snippet?
> Also, it will be better to post a mach5 job in JBS running several iterations as it fails in mach5 primarily.

Or even check the location of the button only?

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

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

From kizune at openjdk.java.net  Mon Jan  4 20:14:11 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 4 Jan 2021 20:14:11 GMT
Subject: <Swing Dev> RFR: 8258643:
 javax/swing/JComponent/7154030/bug7154030.java failed with "Exception:
 Failed to hide opaque button" [v2]
In-Reply-To: <-y0HLftBY_vzkjcq-mZjJpVoGRzwt9AT3naP7_nZItQ=.31305f63-b5e4-4a7e-ad01-998828f629a1@github.com>
References: <-y0HLftBY_vzkjcq-mZjJpVoGRzwt9AT3naP7_nZItQ=.31305f63-b5e4-4a7e-ad01-998828f629a1@github.com>
Message-ID: <hPzw4eu1IhFvXRkmnb1mMAequn9Hd4iVfflQiX0tcNY=.e7cdee97-dc3c-4258-a24d-b82cfff8af53@github.com>

> 8258643: javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button"

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

  Imports fixed.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1929/files
  - new: https://git.openjdk.java.net/jdk/pull/1929/files/94f6f859..1a8a0a19

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

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

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

From kizune at openjdk.java.net  Mon Jan  4 20:30:55 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 4 Jan 2021 20:30:55 GMT
Subject: <Swing Dev> RFR: 8258643:
 javax/swing/JComponent/7154030/bug7154030.java failed with "Exception:
 Failed to hide opaque button" [v2]
In-Reply-To: <b4uuQ7ykgo_xzL64uqPh_PT_adZ3UvUqqnQww132k1U=.6ab15520-77e6-4f2e-8413-042cbafbc079@github.com>
References: <-y0HLftBY_vzkjcq-mZjJpVoGRzwt9AT3naP7_nZItQ=.31305f63-b5e4-4a7e-ad01-998828f629a1@github.com>
 <9daNtfQdavO1sgoceBdTa_vmkmwqv2ZgwWZs5MTb3l0=.9644c009-e539-469e-adc6-e0c499c6300e@github.com>
 <b4uuQ7ykgo_xzL64uqPh_PT_adZ3UvUqqnQww132k1U=.6ab15520-77e6-4f2e-8413-042cbafbc079@github.com>
Message-ID: <yB1_LjL5cYxFma_WohFD9lplCyLTbyOeNhQRvvTeALs=.333a5a89-5433-41de-bef2-a4cf0f8ad1b8@github.com>

On Mon, 4 Jan 2021 11:22:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 105:
>> 
>>> 103:             locy = bounds.y + insets.top;
>>> 104:             frw = bounds.width - insets.left - insets.right;
>>> 105:             frh = bounds.height - insets.top - insets.bottom;
>> 
>> If the intent is to do away with window decorations, can't we just call frame.setUndecorated instead of this snippet?
>> Also, it will be better to post a mach5 job in JBS running several iterations as it fails in mach5 primarily.
>
> Or even check the location of the button only?

This is the simple fix and i don't want to make the analysis are too small because this will make artifacts harder to analyze. Test runs are linked in the bug comment.

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

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

From prr at openjdk.java.net  Mon Jan  4 21:11:58 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 4 Jan 2021 21:11:58 GMT
Subject: <Swing Dev> Integrated: 8257809: JNI warnings from Toolkit JPEG
 image decoding
In-Reply-To: <fSJstPuGwn4PqeN9JTO4YSpvC7WG9iPQYyPmMivV-YA=.979b8669-0299-4ca7-8f91-af9fa764384a@github.com>
References: <fSJstPuGwn4PqeN9JTO4YSpvC7WG9iPQYyPmMivV-YA=.979b8669-0299-4ca7-8f91-af9fa764384a@github.com>
Message-ID: <XkFIwrYoHNIGWSjdkKZomOXbPNZGwlRXont-wSz9T6M=.dca67a5e-b3cc-4a08-899d-d75f693ed91c@github.com>

On Sun, 20 Dec 2020 01:37:47 GMT, Phil Race <prr at openjdk.org> wrote:

> The fix is to reverse the order of acquisition to get dst before src so that the call to GetArrayLength() comes first.
> This also necessitates moving the RELEASE_ARRAYS() call on an error condition to the new "2nd" block.
> 
> The new regression test passes on all platforms and all the other headless tests passed too.
> So do the automated headful tests.

This pull request has now been integrated.

Changeset: e6f99260
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e6f99260
Stats:     126 lines in 4 files changed: 116 ins; 10 del; 0 mod

8257809: JNI warnings from Toolkit JPEG image decoding

Reviewed-by: serb

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

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

From serb at openjdk.java.net  Mon Jan  4 23:03:53 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 4 Jan 2021 23:03:53 GMT
Subject: <Swing Dev> RFR: 8193942: Regression automated test
 '/open/test/jdk/javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java'
 fails
In-Reply-To: <a3VPMCuX4SB6V1cqcGLXAO8rrKx3-AZfy5YDvvm_5jI=.c61bf8a1-ed2c-434f-a652-2648f8930454@github.com>
References: <o9Mocgk159sqrmM-Vr-Oh_Y-GB3mECmXxuLCKyODIZU=.b37d10be-2364-4ad1-aeac-4200d11dad65@github.com>
 <OzDj2KJiMi-kJYQRpGzMzSaq5n5Xso3Iek0blFKTmQo=.39f69d5f-4a92-496d-a727-00b5e5e7285a@github.com>
 <a3VPMCuX4SB6V1cqcGLXAO8rrKx3-AZfy5YDvvm_5jI=.c61bf8a1-ed2c-434f-a652-2648f8930454@github.com>
Message-ID: <CTFrtk9JgW31GRqPXqWsQWMxEcGu0b2cxSG4Hwc5vu4=.25705048-2ee3-4771-80bd-93ee02d915ce@github.com>

On Mon, 4 Jan 2021 06:59:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> reason: User specified action: run main/othervm -Dsun.java2d.uiScale=1.25 -Dsun.java2d.d3d=true 

You have set it via the property, but the bug was reported on the system where the 125% dpi was set in the windows settings and the test was run as-is.

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

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

From psadhukhan at openjdk.java.net  Tue Jan  5 04:15:54 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 5 Jan 2021 04:15:54 GMT
Subject: <Swing Dev> RFR: 8193942: Regression automated test
 '/open/test/jdk/javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java'
 fails
In-Reply-To: <CTFrtk9JgW31GRqPXqWsQWMxEcGu0b2cxSG4Hwc5vu4=.25705048-2ee3-4771-80bd-93ee02d915ce@github.com>
References: <o9Mocgk159sqrmM-Vr-Oh_Y-GB3mECmXxuLCKyODIZU=.b37d10be-2364-4ad1-aeac-4200d11dad65@github.com>
 <OzDj2KJiMi-kJYQRpGzMzSaq5n5Xso3Iek0blFKTmQo=.39f69d5f-4a92-496d-a727-00b5e5e7285a@github.com>
 <a3VPMCuX4SB6V1cqcGLXAO8rrKx3-AZfy5YDvvm_5jI=.c61bf8a1-ed2c-434f-a652-2648f8930454@github.com>
 <CTFrtk9JgW31GRqPXqWsQWMxEcGu0b2cxSG4Hwc5vu4=.25705048-2ee3-4771-80bd-93ee02d915ce@github.com>
Message-ID: <oVFfLMBhCl0zQz9mJQ6ovKfS2PO_OBaBEQ4Pgxgm7II=.e5d38eb2-a3c8-4d7a-8e23-71dcce9496cf@github.com>

On Mon, 4 Jan 2021 23:01:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Yes, it works
>> 
>> reason: User specified action: run main/othervm -Dsun.java2d.uiScale=1.25 -Dsun.java2d.d3d=true ScaledFrameBackgroundTest
>> Mode: othervm [/othervm specified]
>> Additional options from @modules: --add-modules java.desktop
>> elapsed time (seconds): 6.049
>> ----------configuration:(3/43)----------
>> Boot Layer
>>   add modules: java.desktop
>> 
>> ----------System.out:(0/0)----------
>> ----------System.err:(1/16)----------
>> STATUS:Passed.
>
>> reason: User specified action: run main/othervm -Dsun.java2d.uiScale=1.25 -Dsun.java2d.d3d=true 
> 
> You have set it via the property, but the bug was reported on the system where the 125% dpi was set in the windows settings and the test was run as-is.

I have tried that as well. In fact, my windows display setting is 125% and it worked without this property change in uiscale.

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

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

From serb at openjdk.java.net  Tue Jan  5 06:50:54 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 5 Jan 2021 06:50:54 GMT
Subject: <Swing Dev> RFR: 8193942: Regression automated test
 '/open/test/jdk/javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java'
 fails
In-Reply-To: <o9Mocgk159sqrmM-Vr-Oh_Y-GB3mECmXxuLCKyODIZU=.b37d10be-2364-4ad1-aeac-4200d11dad65@github.com>
References: <o9Mocgk159sqrmM-Vr-Oh_Y-GB3mECmXxuLCKyODIZU=.b37d10be-2364-4ad1-aeac-4200d11dad65@github.com>
Message-ID: <jlLD2gLlZbS_HQCAOo6_hPzy9Tc4y2CfHgd8Q7Aq0FY=.e21ff43b-e7b5-450f-9012-48c025db9458@github.com>

On Mon, 4 Jan 2021 05:09:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test use to fail in macos in mach5 nightly testing long time back. It used to fail in ubuntu17.10 due to unsupported wayland display mode. Recent run of this test on supported platforms does not fail.
> Modified the test slightly to be consistent with other test regarding robot delays, moved frame to center of screen.
> Mach5 job running several iterations of the test in all platforms is ok. Link in JBS.

Thank you for your confirmation. Looks fine.

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

Marked as reviewed by serb (Reviewer).

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

From aivanov at openjdk.java.net  Tue Jan  5 08:38:01 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 5 Jan 2021 08:38:01 GMT
Subject: <Swing Dev> RFR: JDK-8258884: [TEST_BUG] Convert applet-based
 test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a
 regular java test
In-Reply-To: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
References: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
Message-ID: <5Kct1QSD0z1McCmq3_CxPbjHNpFJZ56L2o-1Pw9CdDc=.f2aab69c-27ad-45ad-8660-71b30d76237a@github.com>

On Wed, 23 Dec 2020 11:50:41 GMT, K Suman Rajkumaar <github.com+70650887+skodanda at openjdk.org> wrote:

> Hi All, Could you please review this fix for JDK16?
> 
> Problem Description: The test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java is applet based.
> 
> Fix: Rewritten the above applet based test to a regular java test.
> 
> Best Regards,
> K Suman Rajkumaar

You should remove the HTML which hosts the applet.

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

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

From aivanov at openjdk.java.net  Tue Jan  5 08:38:01 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 5 Jan 2021 08:38:01 GMT
Subject: <Swing Dev> RFR: JDK-8258884: [TEST_BUG] Convert applet-based
 test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a
 regular java test [v2]
In-Reply-To: <Qx5VCw7ATdgECt_vASUXHWTH19lWoreG04lxIvBFmXg=.16580897-696a-4807-a358-7938d918b99a@github.com>
References: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
 <Qx5VCw7ATdgECt_vASUXHWTH19lWoreG04lxIvBFmXg=.16580897-696a-4807-a358-7938d918b99a@github.com>
Message-ID: <ysdRIWmEHvqjG7uY8G9mNkERQh9y4418HoHJUj9f2Iw=.f5fc8ab8-787d-4b90-bd40-3f7b1fd450c7@github.com>

On Mon, 4 Jan 2021 09:15:14 GMT, K Suman Rajkumaar <github.com+70650887+skodanda at openjdk.org> wrote:

>> Hi All, Could you please review this fix for JDK16?
>> 
>> Problem Description: The test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java is applet based.
>> 
>> Fix: Rewritten the above applet based test to a regular java test.
>> 
>> Best Regards,
>> K Suman Rajkumaar
>
> K Suman Rajkumaar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update bug8031573.java
>   
>   Corrected the jtreg tag from @run main bug8031573 to @run main/manual bug8031573 to make this test as a manual test.

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java line 60:

> 58:             + "If the display does not support HiDPI mode press PASS.\n"
> 59:             + "1. Run the test on HiDPI Display.\n"
> 60:             + "2. Press the Menu in the applet.\n"

There's no applet. Shall we say ?Open the menu? instead?

test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java line 61:

> 59:             + "1. Run the test on HiDPI Display.\n"
> 60:             + "2. Press the Menu in the applet.\n"
> 61:             + "3. Check that the icon on the JCheckBoxMenuItem is smooth If so, press PASS, else press FAIL.\n";

Suggestion:

            + "3. Check that the icon on the JCheckBoxMenuItem is smooth.\n"
            + "   If so, press PASS, otherwise press FAIL.";

test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java line 68:

> 66: 
> 67:         if (!latch.await(5, TimeUnit.MINUTES)) {
> 68:             frame.dispose();

The `dispose()` method should be called on EDT.

test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java line 78:

> 76:     private static void createTestGUI() {
> 77:         frame = new JFrame("bug8031573");
> 78:         frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

I propose to omit this line: the test should never call `System.exit()`.

test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java line 105:

> 103:             latch.countDown();
> 104:             frame.dispose();
> 105:             throw new RuntimeException("Test Failed!");

Throwing the exception on EDT is redundant and does not make the test fail; moreover you throw the exception in `main()` if `passed` is `false`.

test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java line 118:

> 116:             public void windowClosing(WindowEvent e) {
> 117:                 latch.countDown();
> 118:             }

Add here `frame.dispose();`  and then the frame will close without `frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);` and the app will exit even when launched as a stand-alone app.

test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java line 52:

> 50: public class bug8031573 {
> 51: 
> 52:     private static JFrame frame;

`frame` should also be `volatile` as it's accessed from multiple threads: main thread and EDT.

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

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

From turbanoff at gmail.com  Tue Jan  5 11:40:27 2021
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Tue, 5 Jan 2021 14:40:27 +0300
Subject: <Swing Dev> Suspicious field assignment in StrikeMetrics
Message-ID: <CAF+DQ5cKLZv0m0byeH68s0SVMC=+HcuLaaWabb0g=nWxxGnmwQ@mail.gmail.com>

Hello.
I've found suspicious code in constructor sun.font.StrikeMetrics#StrikeMetrics()

StrikeMetrics() {
    ascentX = ascentY = Integer.MAX_VALUE;
    descentX = descentY = leadingX = leadingY = Integer.MIN_VALUE;
    baselineX = baselineX = maxAdvanceX = maxAdvanceY = Integer.MIN_VALUE;
}

As you can see, basLineX field is assigned twice.
Looks like it's supposed to be like this:

baselineX = baselineY = maxAdvanceX = maxAdvanceY = Integer.MIN_VALUE;



Found by SpotBugs
https://spotbugs.readthedocs.io/en/stable/bugDescriptions.html#sa-double-assignment-of-field-sa-field-double-assignment

Andrey Turbanov

From vladislav.volodin at sap.com  Tue Jan  5 12:14:33 2021
From: vladislav.volodin at sap.com (Volodin, Vladislav)
Date: Tue, 5 Jan 2021 12:14:33 +0000
Subject: <Swing Dev> Suspicious field assignment in StrikeMetrics
In-Reply-To: <CAF+DQ5cKLZv0m0byeH68s0SVMC=+HcuLaaWabb0g=nWxxGnmwQ@mail.gmail.com>
References: <CAF+DQ5cKLZv0m0byeH68s0SVMC=+HcuLaaWabb0g=nWxxGnmwQ@mail.gmail.com>
Message-ID: <AM0PR02MB365190EBF8BF2D91550B2F91FED10@AM0PR02MB3651.eurprd02.prod.outlook.com>

Hello Andrey,

Nice catch! You can create a bug and prepare a pull request, so maintainers can review it. 
What I have just personally noticed, all fields have the type float, so probably instead of "Integer.MIN_VALUE", I would recommend to use "-Float.MAX_VALUE". But since this code is about 13-years old, I don't know if reviewers can accept your PR without additional tests.

Kind regards,
Vlad

-----Original Message-----
From: swing-dev <swing-dev-retn at openjdk.java.net> On Behalf Of Andrey Turbanov
Sent: Dienstag, 5. Januar 2021 12:40
To: swing-dev at openjdk.java.net
Subject: <Swing Dev> Suspicious field assignment in StrikeMetrics

Hello.
I've found suspicious code in constructor sun.font.StrikeMetrics#StrikeMetrics()

StrikeMetrics() {
    ascentX = ascentY = Integer.MAX_VALUE;
    descentX = descentY = leadingX = leadingY = Integer.MIN_VALUE;
    baselineX = baselineX = maxAdvanceX = maxAdvanceY = Integer.MIN_VALUE;
}

As you can see, basLineX field is assigned twice.
Looks like it's supposed to be like this:

baselineX = baselineY = maxAdvanceX = maxAdvanceY = Integer.MIN_VALUE;



Found by SpotBugs
https://spotbugs.readthedocs.io/en/stable/bugDescriptions.html#sa-double-assignment-of-field-sa-field-double-assignment

Andrey Turbanov

From psadhukhan at openjdk.java.net  Tue Jan  5 12:59:59 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 5 Jan 2021 12:59:59 GMT
Subject: <Swing Dev> RFR: 8258643:
 javax/swing/JComponent/7154030/bug7154030.java failed with "Exception:
 Failed to hide opaque button" [v2]
In-Reply-To: <hPzw4eu1IhFvXRkmnb1mMAequn9Hd4iVfflQiX0tcNY=.e7cdee97-dc3c-4258-a24d-b82cfff8af53@github.com>
References: <-y0HLftBY_vzkjcq-mZjJpVoGRzwt9AT3naP7_nZItQ=.31305f63-b5e4-4a7e-ad01-998828f629a1@github.com>
 <hPzw4eu1IhFvXRkmnb1mMAequn9Hd4iVfflQiX0tcNY=.e7cdee97-dc3c-4258-a24d-b82cfff8af53@github.com>
Message-ID: <eGcehFHbUWejzD-GFpW-cyELsm77q7RtRCkQaZcwxAM=.dcd9d95b-83f5-4e0b-8ee6-10244bbb89bb@github.com>

On Mon, 4 Jan 2021 20:14:11 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> 8258643: javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button"
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Imports fixed.

Marked as reviewed by psadhukhan (Reviewer).

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

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

From turbanoff at gmail.com  Tue Jan  5 14:23:05 2021
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Tue, 5 Jan 2021 17:23:05 +0300
Subject: <Swing Dev> Suspicious field assignment in StrikeMetrics
In-Reply-To: <AM0PR02MB365190EBF8BF2D91550B2F91FED10@AM0PR02MB3651.eurprd02.prod.outlook.com>
References: <CAF+DQ5cKLZv0m0byeH68s0SVMC=+HcuLaaWabb0g=nWxxGnmwQ@mail.gmail.com>
 <AM0PR02MB365190EBF8BF2D91550B2F91FED10@AM0PR02MB3651.eurprd02.prod.outlook.com>
Message-ID: <CAF+DQ5c7K7e3UV8nN4G+_SWGYS9kVtkfi0WZEwsftikPQJi77Q@mail.gmail.com>

I don't have a JBS account yet, so I can't create a bug.
I hope someone, who read it can create it.

Andrey Turbanov

??, 5 ???. 2021 ?. ? 15:14, Volodin, Vladislav <vladislav.volodin at sap.com>:
>
> Hello Andrey,
>
> Nice catch! You can create a bug and prepare a pull request, so maintainers can review it.
> What I have just personally noticed, all fields have the type float, so probably instead of "Integer.MIN_VALUE", I would recommend to use "-Float.MAX_VALUE". But since this code is about 13-years old, I don't know if reviewers can accept your PR without additional tests.
>
> Kind regards,
> Vlad
>
> -----Original Message-----
> From: swing-dev <swing-dev-retn at openjdk.java.net> On Behalf Of Andrey Turbanov
> Sent: Dienstag, 5. Januar 2021 12:40
> To: swing-dev at openjdk.java.net
> Subject: <Swing Dev> Suspicious field assignment in StrikeMetrics
>
> Hello.
> I've found suspicious code in constructor sun.font.StrikeMetrics#StrikeMetrics()
>
> StrikeMetrics() {
>     ascentX = ascentY = Integer.MAX_VALUE;
>     descentX = descentY = leadingX = leadingY = Integer.MIN_VALUE;
>     baselineX = baselineX = maxAdvanceX = maxAdvanceY = Integer.MIN_VALUE;
> }
>
> As you can see, basLineX field is assigned twice.
> Looks like it's supposed to be like this:
>
> baselineX = baselineY = maxAdvanceX = maxAdvanceY = Integer.MIN_VALUE;
>
>
>
> Found by SpotBugs
> https://spotbugs.readthedocs.io/en/stable/bugDescriptions.html#sa-double-assignment-of-field-sa-field-double-assignment
>
> Andrey Turbanov

From kizune at openjdk.java.net  Tue Jan  5 14:48:55 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 5 Jan 2021 14:48:55 GMT
Subject: <Swing Dev> Integrated: 8258643:
 javax/swing/JComponent/7154030/bug7154030.java failed with "Exception:
 Failed to hide opaque button"
In-Reply-To: <-y0HLftBY_vzkjcq-mZjJpVoGRzwt9AT3naP7_nZItQ=.31305f63-b5e4-4a7e-ad01-998828f629a1@github.com>
References: <-y0HLftBY_vzkjcq-mZjJpVoGRzwt9AT3naP7_nZItQ=.31305f63-b5e4-4a7e-ad01-998828f629a1@github.com>
Message-ID: <tPn0Mry5lzdPPV2iGHstzgb-8KNXckuV2FfzD7QMtpU=.0ecc159d-d77b-4153-9b56-14ba5ec9a6ad@github.com>

On Mon, 4 Jan 2021 10:07:08 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8258643: javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button"

This pull request has now been integrated.

Changeset: fc3b45c0
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fc3b45c0
Stats:     12 lines in 1 file changed: 1 ins; 5 del; 6 mod

8258643: javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button"

Reviewed-by: psadhukhan

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

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

From trebari at openjdk.java.net  Wed Jan  6 05:51:00 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Wed, 6 Jan 2021 05:51:00 GMT
Subject: <Swing Dev> RFR: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions [v4]
In-Reply-To: <LPGCW0REMlhU-7YxflrUnXlqI0z-sOaHY3n_Ge3pYs4=.27f9da7d-cd4a-474a-a979-81ebec915c26@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
 <PHdzaI5JYc2R_piiDx--o-fBMItTCED3WkmPi20L17s=.d7a423c0-b663-4c9d-9cbe-b7c2c761315b@github.com>
 <ad1ydktaZdQOjoPK23yhnAvJ6U1ZJ6LMztjkBeredmY=.97a6b118-8626-48a1-9005-ac8718f36abf@github.com>
 <-cE9eTaeK1Tb0uVNh4ICINADEJ7ca-22xQBAPcwoyAE=.42736629-8faa-471f-91c2-6d61cf913182@github.com>
 <odsYEKbosxjshVThQTuWLZFkc76emYTk-wlCXBBF5hc=.29bdbb13-d481-4f3a-8813-8b7e0f393ee0@github.com>
 <FH5R07msEXBJgDdW5U1hXrg1Iy34cRDln9rXxUGZgdw=.15e9bd14-bf6f-45bc-8d35-c053e473ee7c@github.com>
 <LPGCW0REMlhU-7YxflrUnXlqI0z-sOaHY3n_Ge3pYs4=.27f9da7d-cd4a-474a-a979-81ebec915c26@github.com>
Message-ID: <25o4tfqvGxXD1sCck6teaaGO8iuWtOVY2YUZ-yi-8yM=.030e72ee-29a8-46c6-b4e1-18d70e8fa6b8@github.com>

On Wed, 23 Dec 2020 23:47:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> yeah , i have checked in windows and ubuntu native apps and it is matching native behaviour.
>> The issue is seen in Motif, Nimbus, GTK and windows which sets consumeEventOnClose to true.
>> It is not seen in Metal And Aqua which doesn't set this variable and the value from BasicLookAndFeel.java is used which is false.
>
> Can you recheck that using the next usecase:
>  - Create menu in the frame
>  - Add jbutton to the frame exactly in the place where the menu popup is opened
>  - Open menu and click some menu item, will the jbutton be clicked?

Open menu and click some menu item, will the jbutton be clicked?
    No, the JButton is not clicked in this use case.

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

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

From psadhukhan at openjdk.java.net  Wed Jan  6 06:48:54 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 6 Jan 2021 06:48:54 GMT
Subject: <Swing Dev> Integrated: 8193942: Regression automated test
 '/open/test/jdk/javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java'
 fails
In-Reply-To: <o9Mocgk159sqrmM-Vr-Oh_Y-GB3mECmXxuLCKyODIZU=.b37d10be-2364-4ad1-aeac-4200d11dad65@github.com>
References: <o9Mocgk159sqrmM-Vr-Oh_Y-GB3mECmXxuLCKyODIZU=.b37d10be-2364-4ad1-aeac-4200d11dad65@github.com>
Message-ID: <865CDi3f3d59xRliHjmZtEmfsCYcFX9XViYP5hPT5EA=.f366a48a-a985-44c3-86ca-baba38ecef36@github.com>

On Mon, 4 Jan 2021 05:09:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test use to fail in macos in mach5 nightly testing long time back. It used to fail in ubuntu17.10 due to unsupported wayland display mode. Recent run of this test on supported platforms does not fail.
> Modified the test slightly to be consistent with other test regarding robot delays, moved frame to center of screen.
> Mach5 job running several iterations of the test in all platforms is ok. Link in JBS.

This pull request has now been integrated.

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

8193942: Regression automated test '/open/test/jdk/javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java' fails

Reviewed-by: serb

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

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

From psadhukhan at openjdk.java.net  Wed Jan  6 07:24:09 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 6 Jan 2021 07:24:09 GMT
Subject: <Swing Dev> RFR: 8233555: [TESTBUG] JRadioButton tests failing on
 MacoS
Message-ID: <uqEMWUhPMeVFuMxEfBFZmANucC7mW-GYv3OwCx3A8zs=.e4b06552-6318-41b9-9399-6bd70560bf00@github.com>

These radiobutton tests were failing on macos in nightly testing. However recent run of these test are working fine on local mac10.14.6, 10.15.7 systems as well as mach5 macos systems, so we can deproblemlist these tests. Mach5 job link is in JBS.

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

Commit messages:
 - 8233555: [TESTBUG] JRadioButton tests failing on MacoS

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

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

From github.com+70650887+skodanda at openjdk.java.net  Wed Jan  6 08:22:12 2021
From: github.com+70650887+skodanda at openjdk.java.net (K Suman Rajkumaar)
Date: Wed, 6 Jan 2021 08:22:12 GMT
Subject: <Swing Dev> RFR: JDK-8258884: [TEST_BUG] Convert applet-based
 test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a
 regular java test [v3]
In-Reply-To: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
References: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
Message-ID: <yy4RHBEqnnooAGZAcbhRmluRSNmwexy3xcWAXlAkC5w=.fca2639f-d859-46a0-b046-1a26704826a5@github.com>

> Hi All, Could you please review this fix for JDK16?
> 
> Problem Description: The test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java is applet based.
> 
> Fix: Rewritten the above applet based test to a regular java test.
> 
> Best Regards,
> K Suman Rajkumaar

K Suman Rajkumaar has updated the pull request incrementally with three additional commits since the last revision:

 - Update bug8031573.java
 - Update bug8031573.java
 - Incorporated the review comments from Alexey.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1878/files
  - new: https://git.openjdk.java.net/jdk/pull/1878/files/5f1ab6ea..9020f7bf

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

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

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

From github.com+70650887+skodanda at openjdk.java.net  Wed Jan  6 08:26:56 2021
From: github.com+70650887+skodanda at openjdk.java.net (K Suman Rajkumaar)
Date: Wed, 6 Jan 2021 08:26:56 GMT
Subject: <Swing Dev> RFR: JDK-8258884: [TEST_BUG] Convert applet-based
 test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a
 regular java test [v2]
In-Reply-To: <ysdRIWmEHvqjG7uY8G9mNkERQh9y4418HoHJUj9f2Iw=.f5fc8ab8-787d-4b90-bd40-3f7b1fd450c7@github.com>
References: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
 <Qx5VCw7ATdgECt_vASUXHWTH19lWoreG04lxIvBFmXg=.16580897-696a-4807-a358-7938d918b99a@github.com>
 <ysdRIWmEHvqjG7uY8G9mNkERQh9y4418HoHJUj9f2Iw=.f5fc8ab8-787d-4b90-bd40-3f7b1fd450c7@github.com>
Message-ID: <PqHqZnRPbqG0MjInv9HtkTGaf00O1LtNuPMpw91PELk=.9e618773-d274-4621-acee-8de021adbaa0@github.com>

On Tue, 5 Jan 2021 08:25:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> K Suman Rajkumaar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update bug8031573.java
>>   
>>   Corrected the jtreg tag from @run main bug8031573 to @run main/manual bug8031573 to make this test as a manual test.
>
> test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java line 68:
> 
>> 66: 
>> 67:         if (!latch.await(5, TimeUnit.MINUTES)) {
>> 68:             frame.dispose();
> 
> The `dispose()` method should be called on EDT.

If I remove the frame.dispose(), the frame doesn't gets disposed even after timeout.

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

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

From serb at openjdk.java.net  Wed Jan  6 08:47:54 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 6 Jan 2021 08:47:54 GMT
Subject: <Swing Dev> RFR: 8233555: [TESTBUG] JRadioButton tests failing
 on MacoS
In-Reply-To: <uqEMWUhPMeVFuMxEfBFZmANucC7mW-GYv3OwCx3A8zs=.e4b06552-6318-41b9-9399-6bd70560bf00@github.com>
References: <uqEMWUhPMeVFuMxEfBFZmANucC7mW-GYv3OwCx3A8zs=.e4b06552-6318-41b9-9399-6bd70560bf00@github.com>
Message-ID: <zXvZ505_3DHqNVTnkM1W0xzEqPc7NUGf3foZY_h5I0g=.dce40eb9-7017-4b1d-afc3-6f22cb2ef8b2@github.com>

On Wed, 6 Jan 2021 07:18:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> These radiobutton tests were failing on macos in nightly testing. However recent run of these test are working fine on local mac10.14.6, 10.15.7 systems as well as mach5 macos systems, so we can deproblemlist these tests. Mach5 job link is in JBS.

At least two of those tests were failed due to JDK-8226892. If they work fine now does it mean that some other fixes resolved the problem?

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

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

From psadhukhan at openjdk.java.net  Wed Jan  6 08:54:54 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 6 Jan 2021 08:54:54 GMT
Subject: <Swing Dev> RFR: 8233555: [TESTBUG] JRadioButton tests failing
 on MacoS
In-Reply-To: <zXvZ505_3DHqNVTnkM1W0xzEqPc7NUGf3foZY_h5I0g=.dce40eb9-7017-4b1d-afc3-6f22cb2ef8b2@github.com>
References: <uqEMWUhPMeVFuMxEfBFZmANucC7mW-GYv3OwCx3A8zs=.e4b06552-6318-41b9-9399-6bd70560bf00@github.com>
 <zXvZ505_3DHqNVTnkM1W0xzEqPc7NUGf3foZY_h5I0g=.dce40eb9-7017-4b1d-afc3-6f22cb2ef8b2@github.com>
Message-ID: <1Lj05iOcMpRAPysvAfXJbMQ2C4xu0fr0w3mrwSyLOls=.aad57d05-ca88-48fe-8eef-c0552dc98059@github.com>

On Wed, 6 Jan 2021 08:45:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> These radiobutton tests were failing on macos in nightly testing. However recent run of these test are working fine on local mac10.14.6, 10.15.7 systems as well as mach5 macos systems, so we can deproblemlist these tests. Mach5 job link is in JBS.
>
> At least two of those tests were failed due to JDK-8226892. If they work fine now does it mean that some other fixes resolved the problem?

Not sure but the code added by JDK-8226892 is reworked by JDK-8249548 and we dont see the issue now as can be seen by mach5 run.

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

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

From serb at openjdk.java.net  Wed Jan  6 09:00:56 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 6 Jan 2021 09:00:56 GMT
Subject: <Swing Dev> RFR: 8233555: [TESTBUG] JRadioButton tests failing
 on MacoS
In-Reply-To: <1Lj05iOcMpRAPysvAfXJbMQ2C4xu0fr0w3mrwSyLOls=.aad57d05-ca88-48fe-8eef-c0552dc98059@github.com>
References: <uqEMWUhPMeVFuMxEfBFZmANucC7mW-GYv3OwCx3A8zs=.e4b06552-6318-41b9-9399-6bd70560bf00@github.com>
 <zXvZ505_3DHqNVTnkM1W0xzEqPc7NUGf3foZY_h5I0g=.dce40eb9-7017-4b1d-afc3-6f22cb2ef8b2@github.com>
 <1Lj05iOcMpRAPysvAfXJbMQ2C4xu0fr0w3mrwSyLOls=.aad57d05-ca88-48fe-8eef-c0552dc98059@github.com>
Message-ID: <cSK7O4XEUvuBZ7kLQFcIDKLbK6kDpNHmEuLFn67uM5k=.378e6c1f-06d2-4665-aba6-65a20f4adfc5@github.com>

On Wed, 6 Jan 2021 08:51:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Not sure but the code added by JDK-8226892 is reworked by JDK-8249548 and we dont see the issue now as can be seen by mach5 run.

So the tests will fail on the builds before jdk16  b14?

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

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

From psadhukhan at openjdk.java.net  Wed Jan  6 09:22:54 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 6 Jan 2021 09:22:54 GMT
Subject: <Swing Dev> RFR: 8233555: [TESTBUG] JRadioButton tests failing
 on MacoS
In-Reply-To: <cSK7O4XEUvuBZ7kLQFcIDKLbK6kDpNHmEuLFn67uM5k=.378e6c1f-06d2-4665-aba6-65a20f4adfc5@github.com>
References: <uqEMWUhPMeVFuMxEfBFZmANucC7mW-GYv3OwCx3A8zs=.e4b06552-6318-41b9-9399-6bd70560bf00@github.com>
 <zXvZ505_3DHqNVTnkM1W0xzEqPc7NUGf3foZY_h5I0g=.dce40eb9-7017-4b1d-afc3-6f22cb2ef8b2@github.com>
 <1Lj05iOcMpRAPysvAfXJbMQ2C4xu0fr0w3mrwSyLOls=.aad57d05-ca88-48fe-8eef-c0552dc98059@github.com>
 <cSK7O4XEUvuBZ7kLQFcIDKLbK6kDpNHmEuLFn67uM5k=.378e6c1f-06d2-4665-aba6-65a20f4adfc5@github.com>
Message-ID: <XTPYhxDZqtXSP4w_kTURWuFUmjwXJ0KTGwP_PHF0axI=.19eb7f3e-7943-4a1b-8d2d-6835da8ba947@github.com>

On Wed, 6 Jan 2021 08:57:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Not sure but the code added by JDK-8226892 is reworked by JDK-8249548 and we dont see the issue now as can be seen by mach5 run.
>
>> Not sure but the code added by JDK-8226892 is reworked by JDK-8249548 and we dont see the issue now as can be seen by mach5 run.
> 
> So the tests will fail on the builds before jdk16  b14?

Yes, maybe not all but bug8033699 fails before 16b14

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

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

From pbansal at openjdk.java.net  Wed Jan  6 09:22:55 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Wed, 6 Jan 2021 09:22:55 GMT
Subject: <Swing Dev> RFR: 8233555: [TESTBUG] JRadioButton tests failing
 on MacoS
In-Reply-To: <XTPYhxDZqtXSP4w_kTURWuFUmjwXJ0KTGwP_PHF0axI=.19eb7f3e-7943-4a1b-8d2d-6835da8ba947@github.com>
References: <uqEMWUhPMeVFuMxEfBFZmANucC7mW-GYv3OwCx3A8zs=.e4b06552-6318-41b9-9399-6bd70560bf00@github.com>
 <zXvZ505_3DHqNVTnkM1W0xzEqPc7NUGf3foZY_h5I0g=.dce40eb9-7017-4b1d-afc3-6f22cb2ef8b2@github.com>
 <1Lj05iOcMpRAPysvAfXJbMQ2C4xu0fr0w3mrwSyLOls=.aad57d05-ca88-48fe-8eef-c0552dc98059@github.com>
 <cSK7O4XEUvuBZ7kLQFcIDKLbK6kDpNHmEuLFn67uM5k=.378e6c1f-06d2-4665-aba6-65a20f4adfc5@github.com>
 <XTPYhxDZqtXSP4w_kTURWuFUmjwXJ0KTGwP_PHF0axI=.19eb7f3e-7943-4a1b-8d2d-6835da8ba947@github.com>
Message-ID: <NUeKBCHwItZazXU_8Z5kDsKftFrU8fvh6M8CFrMu250=.bc6e2e02-b6d2-4b95-b996-f9a4e54b34d3@github.com>

On Wed, 6 Jan 2021 09:17:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> Not sure but the code added by JDK-8226892 is reworked by JDK-8249548 and we dont see the issue now as can be seen by mach5 run.
>> 
>> So the tests will fail on the builds before jdk16  b14?
>
> Yes, maybe not all but bug8033699 fails before 16b14

The JDK-8249548 may be backed out soon as it has caused some other issue JDK-8259237. I am working on it.

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

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

From github.com+70650887+skodanda at openjdk.java.net  Wed Jan  6 09:46:10 2021
From: github.com+70650887+skodanda at openjdk.java.net (K Suman Rajkumaar)
Date: Wed, 6 Jan 2021 09:46:10 GMT
Subject: <Swing Dev> RFR: JDK-8258884: [TEST_BUG] Convert applet-based
 test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a
 regular java test [v4]
In-Reply-To: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
References: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
Message-ID: <2ERHBWQCI41fV0E3qwGRQvz7ktEoDN7oaNCbJvYjzik=.b7ec58f0-5cdf-4a24-b828-919fc492b91f@github.com>

> Hi All, Could you please review this fix for JDK16?
> 
> Problem Description: The test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java is applet based.
> 
> Fix: Rewritten the above applet based test to a regular java test.
> 
> Best Regards,
> K Suman Rajkumaar

K Suman Rajkumaar has updated the pull request incrementally with one additional commit since the last revision:

  Deleted the bug8031573.html

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1878/files
  - new: https://git.openjdk.java.net/jdk/pull/1878/files/9020f7bf..0e675a02

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

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

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

From trebari at openjdk.java.net  Wed Jan  6 12:48:03 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Wed, 6 Jan 2021 12:48:03 GMT
Subject: <Swing Dev> RFR: 8049700: Deprecate obsolete classes and methods in
 javax/swing/plaf/basic
Message-ID: <LcIvlc2HZGDo6ErOfqf_QZlwCpO2a7o2pPIDeaCb40E=.80fa98b5-728e-4198-a4fd-8d70e21302fc@github.com>

Please review the following fix for jdk17.
In this fix i have deprecated and marked for removal following classes and methods 
   public void intervalAdded(ListDataEvent e)
   public void intervalRemoved(ListDataEvent e)
   protected boolean lt(File a, File b) in BasicDirectoryModel.java

   inner class PropertyChangeHandler, VSBChangeListener, HSBChangeListener, 
   ViewportChangeHandler in BasicScrollPaneUI.java
   inner class MouseInputHandler in BasicMenuItemUI.java
   method BasicToolBarUI.java#createFloatingFrame

>From 8049700 not deprecated the paintText(Graphics g, JComponent c, Rectangle textRect, String text) method in BasicButtonUI  as AquaButtonUI, MetalButtonUI and MetalToggleButtonUI overrides it.
Similarly not deprecated ChangeHandler of BasicMenuUI as AquaMenuUI and MotifMenuUI uses this class.

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

Commit messages:
 - initial fix

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

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

From aivanov at openjdk.java.net  Wed Jan  6 13:03:57 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 6 Jan 2021 13:03:57 GMT
Subject: <Swing Dev> RFR: JDK-8258884: [TEST_BUG] Convert applet-based
 test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a
 regular java test [v4]
In-Reply-To: <2ERHBWQCI41fV0E3qwGRQvz7ktEoDN7oaNCbJvYjzik=.b7ec58f0-5cdf-4a24-b828-919fc492b91f@github.com>
References: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
 <2ERHBWQCI41fV0E3qwGRQvz7ktEoDN7oaNCbJvYjzik=.b7ec58f0-5cdf-4a24-b828-919fc492b91f@github.com>
Message-ID: <UEOp9gPdmKkuLPyS-mlta3s4-EYT6YrzRXT-kUp-VjU=.4f0a6c87-7fc6-445a-94ac-bc43809fe881@github.com>

On Wed, 6 Jan 2021 09:46:10 GMT, K Suman Rajkumaar <github.com+70650887+skodanda at openjdk.org> wrote:

>> Hi All, Could you please review this fix for JDK16?
>> 
>> Problem Description: The test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java is applet based.
>> 
>> Fix: Rewritten the above applet based test to a regular java test.
>> 
>> Best Regards,
>> K Suman Rajkumaar
>
> K Suman Rajkumaar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Deleted the bug8031573.html

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java line 120:

> 118:             }
> 119:         });
> 120:         frame.setSize(760, 250);

Doesn't `pack()` work?

test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java line 121:

> 119:         });
> 120:         frame.setSize(760, 250);
> 121:         frame.setLocation(0, 250);

Shall the frame rather be centred on the screen by using `setLocationRelativeTo(null)`?

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

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

From aivanov at openjdk.java.net  Wed Jan  6 13:03:58 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 6 Jan 2021 13:03:58 GMT
Subject: <Swing Dev> RFR: JDK-8258884: [TEST_BUG] Convert applet-based
 test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a
 regular java test [v2]
In-Reply-To: <PqHqZnRPbqG0MjInv9HtkTGaf00O1LtNuPMpw91PELk=.9e618773-d274-4621-acee-8de021adbaa0@github.com>
References: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
 <Qx5VCw7ATdgECt_vASUXHWTH19lWoreG04lxIvBFmXg=.16580897-696a-4807-a358-7938d918b99a@github.com>
 <ysdRIWmEHvqjG7uY8G9mNkERQh9y4418HoHJUj9f2Iw=.f5fc8ab8-787d-4b90-bd40-3f7b1fd450c7@github.com>
 <PqHqZnRPbqG0MjInv9HtkTGaf00O1LtNuPMpw91PELk=.9e618773-d274-4621-acee-8de021adbaa0@github.com>
Message-ID: <8ozS5FWXgm7GTKAvvMLVTZTF-j51w_7rIkYwqQaENOE=.71272433-32ee-42a9-adef-5036c12ec03d@github.com>

On Wed, 6 Jan 2021 08:24:04 GMT, K Suman Rajkumaar <github.com+70650887+skodanda at openjdk.org> wrote:

>> test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java line 68:
>> 
>>> 66: 
>>> 67:         if (!latch.await(5, TimeUnit.MINUTES)) {
>>> 68:             frame.dispose();
>> 
>> The `dispose()` method should be called on EDT.
>
> If I remove the frame.dispose(), the frame doesn't gets disposed even after timeout.

You're right, in my previous comment I forgot about timeout.
Yet it should still be called on EDT.

However, to clean up the code a bit, I propose calling `dispose()` in finally block. Thus there'll be only one place where frame is disposed of instead of being scattered in multiple event handlers:
try {
    // Create GUI
    // Check conditions and throw exceptions on failure
} finally {
    SwingUtilities.invokeAndWait(() -> {
        if (frame != null) {
            frame.dispose();
        }
    }
}
In this case, frame will be accessed from one thread only, EDT, and does not need to be volatile.

Since the frame is always disposed of, other calls to `frame.dispose()` can be removed.

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

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

From github.com+70650887+skodanda at openjdk.java.net  Wed Jan  6 14:28:29 2021
From: github.com+70650887+skodanda at openjdk.java.net (K Suman Rajkumaar)
Date: Wed, 6 Jan 2021 14:28:29 GMT
Subject: <Swing Dev> RFR: JDK-8258884: [TEST_BUG] Convert applet-based
 test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a
 regular java test [v5]
In-Reply-To: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
References: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
Message-ID: <iZ0V0QbUpvYXL77fS-V2iTGX5hVbqRkhU9cZoXBIQ8M=.2e113fbc-39ae-4187-8a3f-a22424d00ca8@github.com>

> Hi All, Could you please review this fix for JDK16?
> 
> Problem Description: The test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java is applet based.
> 
> Fix: Rewritten the above applet based test to a regular java test.
> 
> Best Regards,
> K Suman Rajkumaar

K Suman Rajkumaar has updated the pull request incrementally with one additional commit since the last revision:

  Updated with another set of review comments from Alexey
  
  Updated with another set of review comments from Alexey.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1878/files
  - new: https://git.openjdk.java.net/jdk/pull/1878/files/0e675a02..72c48ff5

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

  Stats: 19 lines in 1 file changed: 8 ins; 3 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1878.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1878/head:pull/1878

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

From aivanov at openjdk.java.net  Wed Jan  6 15:36:58 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 6 Jan 2021 15:36:58 GMT
Subject: <Swing Dev> RFR: JDK-8258884: [TEST_BUG] Convert applet-based
 test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a
 regular java test [v5]
In-Reply-To: <iZ0V0QbUpvYXL77fS-V2iTGX5hVbqRkhU9cZoXBIQ8M=.2e113fbc-39ae-4187-8a3f-a22424d00ca8@github.com>
References: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
 <iZ0V0QbUpvYXL77fS-V2iTGX5hVbqRkhU9cZoXBIQ8M=.2e113fbc-39ae-4187-8a3f-a22424d00ca8@github.com>
Message-ID: <Ahp3D7kKxlkNqxxk2Z2EgBik40A7gHHLHIkrKsmDw2w=.949111e0-8307-4384-8dd8-91c6dc31f490@github.com>

On Wed, 6 Jan 2021 14:28:29 GMT, K Suman Rajkumaar <github.com+70650887+skodanda at openjdk.org> wrote:

>> Hi All, Could you please review this fix for JDK16?
>> 
>> Problem Description: The test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java is applet based.
>> 
>> Fix: Rewritten the above applet based test to a regular java test.
>> 
>> Best Regards,
>> K Suman Rajkumaar
>
> K Suman Rajkumaar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated with another set of review comments from Alexey
>   
>   Updated with another set of review comments from Alexey.

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java line 125:

> 123:         });
> 124:         frame.setSize(760, 250);
> 125:         frame.pack();

`setSize` is redundant when you call `pack`. The latter will also set size of the frame based on the preferred size determined by the layout manager.

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

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

From github.com+70650887+skodanda at openjdk.java.net  Wed Jan  6 16:25:16 2021
From: github.com+70650887+skodanda at openjdk.java.net (K Suman Rajkumaar)
Date: Wed, 6 Jan 2021 16:25:16 GMT
Subject: <Swing Dev> RFR: JDK-8258884: [TEST_BUG] Convert applet-based
 test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a
 regular java test [v6]
In-Reply-To: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
References: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
Message-ID: <fulElJSGZfjmiysZ6UIpVsOeNLSPwX_ijm_-iaLP4t4=.2fd6aa24-f381-45bf-a9b0-1fbd8178fc2e@github.com>

> Hi All, Could you please review this fix for JDK16?
> 
> Problem Description: The test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java is applet based.
> 
> Fix: Rewritten the above applet based test to a regular java test.
> 
> Best Regards,
> K Suman Rajkumaar

K Suman Rajkumaar has updated the pull request incrementally with one additional commit since the last revision:

  Removed the setSize()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1878/files
  - new: https://git.openjdk.java.net/jdk/pull/1878/files/72c48ff5..af8de106

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

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

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

From aivanov at openjdk.java.net  Wed Jan  6 19:54:56 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 6 Jan 2021 19:54:56 GMT
Subject: <Swing Dev> RFR: JDK-8258884: [TEST_BUG] Convert applet-based
 test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a
 regular java test [v6]
In-Reply-To: <fulElJSGZfjmiysZ6UIpVsOeNLSPwX_ijm_-iaLP4t4=.2fd6aa24-f381-45bf-a9b0-1fbd8178fc2e@github.com>
References: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
 <fulElJSGZfjmiysZ6UIpVsOeNLSPwX_ijm_-iaLP4t4=.2fd6aa24-f381-45bf-a9b0-1fbd8178fc2e@github.com>
Message-ID: <k2gUqCEpqFMUMuOm_Y3c3RO6f8htpbaf0RAvI3D5hyc=.67ccbd9f-f2de-4c05-a39c-92577b8d71f5@github.com>

On Wed, 6 Jan 2021 16:25:16 GMT, K Suman Rajkumaar <github.com+70650887+skodanda at openjdk.org> wrote:

>> Hi All, Could you please review this fix for JDK16?
>> 
>> Problem Description: The test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java is applet based.
>> 
>> Fix: Rewritten the above applet based test to a regular java test.
>> 
>> Best Regards,
>> K Suman Rajkumaar
>
> K Suman Rajkumaar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed the setSize()

Marked as reviewed by aivanov (Reviewer).

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

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

From prr at openjdk.java.net  Wed Jan  6 20:46:00 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 6 Jan 2021 20:46:00 GMT
Subject: <Swing Dev> RFR: JDK-8258884: [TEST_BUG] Convert applet-based
 test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a
 regular java test [v6]
In-Reply-To: <k2gUqCEpqFMUMuOm_Y3c3RO6f8htpbaf0RAvI3D5hyc=.67ccbd9f-f2de-4c05-a39c-92577b8d71f5@github.com>
References: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
 <fulElJSGZfjmiysZ6UIpVsOeNLSPwX_ijm_-iaLP4t4=.2fd6aa24-f381-45bf-a9b0-1fbd8178fc2e@github.com>
 <k2gUqCEpqFMUMuOm_Y3c3RO6f8htpbaf0RAvI3D5hyc=.67ccbd9f-f2de-4c05-a39c-92577b8d71f5@github.com>
Message-ID: <kuXE8FotlqQrmkyvMt_7X_VgY0_g635eBQNVn-c0NzU=.50199b62-6f65-4a88-9a34-a5f7de9466ab@github.com>

On Wed, 6 Jan 2021 19:52:35 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> K Suman Rajkumaar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed the setSize()
>
> Marked as reviewed by aivanov (Reviewer).

"Hi All, Could you please review this fix for JDK16?"
This is for JDK 17, not JDK 16, right ?  I can't imagine why it would be for 16 at this juncture ..

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

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

From prr at openjdk.java.net  Wed Jan  6 20:46:01 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 6 Jan 2021 20:46:01 GMT
Subject: <Swing Dev> RFR: JDK-8258884: [TEST_BUG] Convert applet-based
 test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a
 regular java test [v6]
In-Reply-To: <fulElJSGZfjmiysZ6UIpVsOeNLSPwX_ijm_-iaLP4t4=.2fd6aa24-f381-45bf-a9b0-1fbd8178fc2e@github.com>
References: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
 <fulElJSGZfjmiysZ6UIpVsOeNLSPwX_ijm_-iaLP4t4=.2fd6aa24-f381-45bf-a9b0-1fbd8178fc2e@github.com>
Message-ID: <kFW5u4g_1QVY3uD-QbYVXkD59CHvtZ7mSsh3aHLBqeA=.f982a2d7-f636-4b67-9c35-7453925c04f1@github.com>

On Wed, 6 Jan 2021 16:25:16 GMT, K Suman Rajkumaar <github.com+70650887+skodanda at openjdk.org> wrote:

>> Hi All, Could you please review this fix for JDK16?
>> 
>> Problem Description: The test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java is applet based.
>> 
>> Fix: Rewritten the above applet based test to a regular java test.
>> 
>> Best Regards,
>> K Suman Rajkumaar
>
> K Suman Rajkumaar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed the setSize()

test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java line 58:

> 56:     public static final String INSTRUCTIONS = "INSTRUCTIONS:\n\n"
> 57:             + "Verify that high resolution system icons are used JCheckBoxMenuItem on HiDPI displays.\n"
> 58:             + "If the display does not support HiDPI mode press PASS.\n"

"used" -> "used for"

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

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

From serb at openjdk.java.net  Thu Jan  7 00:25:00 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 7 Jan 2021 00:25:00 GMT
Subject: <Swing Dev> RFR: 8233555: [TESTBUG] JRadioButton tests failing
 on MacoS
In-Reply-To: <uqEMWUhPMeVFuMxEfBFZmANucC7mW-GYv3OwCx3A8zs=.e4b06552-6318-41b9-9399-6bd70560bf00@github.com>
References: <uqEMWUhPMeVFuMxEfBFZmANucC7mW-GYv3OwCx3A8zs=.e4b06552-6318-41b9-9399-6bd70560bf00@github.com>
Message-ID: <nfmdxUB1JjGR8JclUADPJokWEjAGOYfTzYcSZHZtfb8=.69f1ad60-ff8d-4ff0-b417-0586e4e0840a@github.com>

On Wed, 6 Jan 2021 07:18:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> These radiobutton tests were failing on macos in nightly testing. However recent run of these test are working fine on local mac10.14.6, 10.15.7 systems as well as mach5 macos systems, so we can deproblemlist these tests. Mach5 job link is in JBS.

Marked as reviewed by serb (Reviewer).

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

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

From serb at openjdk.java.net  Thu Jan  7 00:25:01 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 7 Jan 2021 00:25:01 GMT
Subject: <Swing Dev> RFR: 8233555: [TESTBUG] JRadioButton tests failing
 on MacoS
In-Reply-To: <NUeKBCHwItZazXU_8Z5kDsKftFrU8fvh6M8CFrMu250=.bc6e2e02-b6d2-4b95-b996-f9a4e54b34d3@github.com>
References: <uqEMWUhPMeVFuMxEfBFZmANucC7mW-GYv3OwCx3A8zs=.e4b06552-6318-41b9-9399-6bd70560bf00@github.com>
 <zXvZ505_3DHqNVTnkM1W0xzEqPc7NUGf3foZY_h5I0g=.dce40eb9-7017-4b1d-afc3-6f22cb2ef8b2@github.com>
 <1Lj05iOcMpRAPysvAfXJbMQ2C4xu0fr0w3mrwSyLOls=.aad57d05-ca88-48fe-8eef-c0552dc98059@github.com>
 <cSK7O4XEUvuBZ7kLQFcIDKLbK6kDpNHmEuLFn67uM5k=.378e6c1f-06d2-4665-aba6-65a20f4adfc5@github.com>
 <XTPYhxDZqtXSP4w_kTURWuFUmjwXJ0KTGwP_PHF0axI=.19eb7f3e-7943-4a1b-8d2d-6835da8ba947@github.com>
 <NUeKBCHwItZazXU_8Z5kDsKftFrU8fvh6M8CFrMu250=.bc6e2e02-b6d2-4b95-b996-f9a4e54b34d3@github.com>
Message-ID: <dvuBUwuDmCqTWysQiHD6WArNPa8gMU5Z-AaxWR-wjJ8=.e6beb90e-bba2-4cf1-9ed7-bc1fd0b57247@github.com>

On Wed, 6 Jan 2021 09:20:38 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> The JDK-8249548 may be backed out soon as it has caused some other issue JDK-8259237. I am working on it.

So please take care of these tests, so we do not break them again.

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

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

From psadhukhan at openjdk.java.net  Thu Jan  7 04:01:57 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 7 Jan 2021 04:01:57 GMT
Subject: <Swing Dev> Integrated: 8233555: [TESTBUG] JRadioButton tests
 failing on MacoS
In-Reply-To: <uqEMWUhPMeVFuMxEfBFZmANucC7mW-GYv3OwCx3A8zs=.e4b06552-6318-41b9-9399-6bd70560bf00@github.com>
References: <uqEMWUhPMeVFuMxEfBFZmANucC7mW-GYv3OwCx3A8zs=.e4b06552-6318-41b9-9399-6bd70560bf00@github.com>
Message-ID: <FVCCybHI94UamsLl-tdrY2L4j2uaEBRJFLGPAzNLqsA=.ba752b4a-54d2-4964-bb7d-32895606d609@github.com>

On Wed, 6 Jan 2021 07:18:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> These radiobutton tests were failing on macos in nightly testing. However recent run of these test are working fine on local mac10.14.6, 10.15.7 systems as well as mach5 macos systems, so we can deproblemlist these tests. Mach5 job link is in JBS.

This pull request has now been integrated.

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

8233555: [TESTBUG] JRadioButton tests failing on MacoS

Reviewed-by: serb

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

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

From github.com+70650887+skodanda at openjdk.java.net  Thu Jan  7 05:54:07 2021
From: github.com+70650887+skodanda at openjdk.java.net (K Suman Rajkumaar)
Date: Thu, 7 Jan 2021 05:54:07 GMT
Subject: <Swing Dev> RFR: JDK-8258884: [TEST_BUG] Convert applet-based
 test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a
 regular java test [v7]
In-Reply-To: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
References: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
Message-ID: <IuUpw2bK128XXWWVlWmj8ihC8FfHxNX8MCsaCUiXsx8=.f26ac7ee-e0be-4bbc-b866-0a6bd5f76110@github.com>

> Hi All, Could you please review this fix for JDK16?
> 
> Problem Description: The test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java is applet based.
> 
> Fix: Rewritten the above applet based test to a regular java test.
> 
> Best Regards,
> K Suman Rajkumaar

K Suman Rajkumaar has updated the pull request incrementally with one additional commit since the last revision:

  Changed "used" to "used for" as per Phil's review comment.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1878/files
  - new: https://git.openjdk.java.net/jdk/pull/1878/files/af8de106..b51bf3bd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1878&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1878&range=05-06

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

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

From aivanov at openjdk.java.net  Thu Jan  7 15:56:57 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 7 Jan 2021 15:56:57 GMT
Subject: <Swing Dev> RFR: JDK-8258884: [TEST_BUG] Convert applet-based
 test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a
 regular java test [v6]
In-Reply-To: <kuXE8FotlqQrmkyvMt_7X_VgY0_g635eBQNVn-c0NzU=.50199b62-6f65-4a88-9a34-a5f7de9466ab@github.com>
References: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
 <fulElJSGZfjmiysZ6UIpVsOeNLSPwX_ijm_-iaLP4t4=.2fd6aa24-f381-45bf-a9b0-1fbd8178fc2e@github.com>
 <k2gUqCEpqFMUMuOm_Y3c3RO6f8htpbaf0RAvI3D5hyc=.67ccbd9f-f2de-4c05-a39c-92577b8d71f5@github.com>
 <kuXE8FotlqQrmkyvMt_7X_VgY0_g635eBQNVn-c0NzU=.50199b62-6f65-4a88-9a34-a5f7de9466ab@github.com>
Message-ID: <P6FAvanMOev-ktJYfKrKOA-FhKSDGNTeTgHQ-JliIiY=.bc3da18f-a8f5-44d3-8f4f-446e0e4db485@github.com>

On Wed, 6 Jan 2021 20:42:55 GMT, Phil Race <prr at openjdk.org> wrote:

> "Hi All, Could you please review this fix for JDK16?"
> This is for JDK 17, not JDK 16, right ? I can't imagine why it would be for 16 at this juncture ..

No, it's not meant for JDK 16 ? it's for jdk-dev, the main development line which is JDK 17 at this very moment.

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

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

From psadhukhan at openjdk.java.net  Fri Jan  8 11:08:05 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 8 Jan 2021 11:08:05 GMT
Subject: <Swing Dev> RFR: 8225045:
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails on
 linux-x64
Message-ID: <_Z-JJqhyCnKAUaKRK370cz9rCtIdrdL3bSBtDM-atKA=.c33c5d38-607b-4c72-849c-be0e6442e2c9@github.com>

This test was failing on mach5 nightly on ubuntu systems long time back. Modified the test to add some delays and call robot.waitForIdle() to make it more stable and the resultant test passes on all mach5 systems including linux consisting of ubuntu 19.10, 18.04,20.10,20.04 so we can remove the test from problemlist.
mach5 job running for several iterations is posted in JBS.

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

Commit messages:
 - 8225045: javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails on linux-x64

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

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

From serb at openjdk.java.net  Sat Jan  9 00:19:05 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 9 Jan 2021 00:19:05 GMT
Subject: <Swing Dev> RFR: 8225045:
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails on
 linux-x64
In-Reply-To: <_Z-JJqhyCnKAUaKRK370cz9rCtIdrdL3bSBtDM-atKA=.c33c5d38-607b-4c72-849c-be0e6442e2c9@github.com>
References: <_Z-JJqhyCnKAUaKRK370cz9rCtIdrdL3bSBtDM-atKA=.c33c5d38-607b-4c72-849c-be0e6442e2c9@github.com>
Message-ID: <aXw_8NrFAWAfR5H68MCJjfSbSv8LKjrFt3FPkCDsZFc=.45a363fe-2ab2-4ba0-91e4-0c3910d84fb3@github.com>

On Fri, 8 Jan 2021 11:03:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test was failing on mach5 nightly on ubuntu systems long time back. Modified the test to add some delays and call robot.waitForIdle() to make it more stable and the resultant test passes on all mach5 systems including linux consisting of ubuntu 19.10, 18.04,20.10,20.04 so we can remove the test from problemlist.
> mach5 job running for several iterations is posted in JBS.

test/jdk/javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java line 66:

> 64:     public static void main(String[] args) throws Exception {
> 65:         robot = new Robot();
> 66:         robot.setAutoDelay(100);

Why do you need an autodeley here? It seems the test does not use any of mouseXXX/keyXXX methods.

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

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

From pbansal at openjdk.java.net  Sat Jan  9 12:53:11 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Sat, 9 Jan 2021 12:53:11 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection.
Message-ID: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>

Please review a fix for jdk16

Issue: In SwingSet2, if the user navigates through the demos, the demo gets selected/starts on pressing left/right key only. There is no need to press the "space" key. Earlier, on pressing the left/right key, only demo icon used to get focused and user needed to press the "space" to actually select a demo.

Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, when the user pressed Left/Right button, only the selected button used to change. The Action set on JToggleButton used to perform only  on pressing the "Space" button. Now, the Action is performed on navigating the JToggleButtons using Left/Right keys without the need to press the "space" key.

This issue is a side effect of fix done for https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in JDK-8249548 were not present in JRadioButton as there was code available to handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available for JToggleButton and JRadioButton for all L&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, the AbstractAction is performed on selection of Button itself without the need to press "space". 

Fix: The current change fixes the issue in present bug and keeps the fixes done in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton for different L&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix.

Before fix for JDK-8249548
JToggleButton: 
For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548.
JRadioButton: 
For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. 
For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action.
For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space"

After fix for JDK-8249548
JToggleButton:
For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
JRadioButton:
For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".

After current fix:
JToggleButton:
For all L&Fs, user can navigate/select the buttons added to ButtonGroups.  User needs to press "space" to perform the set AbstractAction.
JRadioButton:
For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action.
For all other L&Fs (including Synth L&F), the behaviour is same. User can navigate/select the buttons added to ButtonGroups and set Action is performed without pressing "space"

I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The test TestButtonGroupFocusTraversal.java is modified such that it fails without current fix and passes after the fix. The fix also should be verified by running SwingSet2.

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

Commit messages:
 - 8259237: Demo selection changes with left/right arrow key. No need to press space for selection.

Changes: https://git.openjdk.java.net/jdk16/pull/99/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=99&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259237
  Stats: 375 lines in 4 files changed: 350 ins; 20 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/99.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/99/head:pull/99

PR: https://git.openjdk.java.net/jdk16/pull/99

From serb at openjdk.java.net  Sun Jan 10 02:58:00 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 10 Jan 2021 02:58:00 GMT
Subject: <Swing Dev> RFR: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions [v4]
In-Reply-To: <PHdzaI5JYc2R_piiDx--o-fBMItTCED3WkmPi20L17s=.d7a423c0-b663-4c9d-9cbe-b7c2c761315b@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
 <PHdzaI5JYc2R_piiDx--o-fBMItTCED3WkmPi20L17s=.d7a423c0-b663-4c9d-9cbe-b7c2c761315b@github.com>
Message-ID: <UeI-QxZ3D1AzgFT5PYZaUvnPTSMc2V1mZzwr_KWUGjE=.1f2f4518-458d-4ff4-8ceb-41214123c1a1@github.com>

On Thu, 10 Dec 2020 16:06:00 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

>> 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:
> 
>   changed mode of files

OK, let's see how it will work.

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

Marked as reviewed by serb (Reviewer).

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

From trebari at openjdk.java.net  Sun Jan 10 12:42:02 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Sun, 10 Jan 2021 12:42:02 GMT
Subject: <Swing Dev> Integrated: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions
In-Reply-To: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
Message-ID: <pyaeSephGckg0km5zQ2uv-Sr6AQx8Z15z6xyYcBkRUo=.a3f29e91-f036-46fc-bc35-f0c7617cd7b9@github.com>

On Mon, 12 Oct 2020 08:01:43 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

> 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

This pull request has now been integrated.

Changeset: 65ca5c66
Author:    Tejpal Rebari <trebari at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/65ca5c66
Stats:     169 lines in 5 files changed: 165 ins; 0 del; 4 mod

8048109: JToggleButton does not fire actionPerformed under certain conditions

Reviewed-by: serb, psadhukhan, vdyakov

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

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

From herrick at openjdk.java.net  Mon Jan 11 01:56:56 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 11 Jan 2021 01:56:56 GMT
Subject: <Swing Dev> Withdrawn: 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: <W1UkrX-Pby-7JTwj25LZVphkdeZ1merEib-AWXWU93Q=.79b50980-33b7-4b1e-8141-6e6939819f1f@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

This pull request has been closed without being integrated.

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

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

From psadhukhan at openjdk.java.net  Mon Jan 11 04:50:09 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 11 Jan 2021 04:50:09 GMT
Subject: <Swing Dev> RFR: 8225045:
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails on
 linux-x64 [v2]
In-Reply-To: <_Z-JJqhyCnKAUaKRK370cz9rCtIdrdL3bSBtDM-atKA=.c33c5d38-607b-4c72-849c-be0e6442e2c9@github.com>
References: <_Z-JJqhyCnKAUaKRK370cz9rCtIdrdL3bSBtDM-atKA=.c33c5d38-607b-4c72-849c-be0e6442e2c9@github.com>
Message-ID: <MDwAMXM9fXaKLWqIYpklkvuKjFWgeFuzFU1unLs3vME=.1f2cb67a-0987-4057-bffc-fe9cd3cfd042@github.com>

> This test was failing on mach5 nightly on ubuntu systems long time back. Modified the test to add some delays and call robot.waitForIdle() to make it more stable and the resultant test passes on all mach5 systems including linux consisting of ubuntu 19.10, 18.04,20.10,20.04 so we can remove the test from problemlist.
> mach5 job running for several iterations is posted in JBS.

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

  Remove unneeded setAutoDelay

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2003/files
  - new: https://git.openjdk.java.net/jdk/pull/2003/files/9c02b54d..c9c12efc

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

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

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

From trebari at openjdk.java.net  Mon Jan 11 05:33:56 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Mon, 11 Jan 2021 05:33:56 GMT
Subject: <Swing Dev> RFR: 8225045:
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails on
 linux-x64 [v2]
In-Reply-To: <MDwAMXM9fXaKLWqIYpklkvuKjFWgeFuzFU1unLs3vME=.1f2cb67a-0987-4057-bffc-fe9cd3cfd042@github.com>
References: <_Z-JJqhyCnKAUaKRK370cz9rCtIdrdL3bSBtDM-atKA=.c33c5d38-607b-4c72-849c-be0e6442e2c9@github.com>
 <MDwAMXM9fXaKLWqIYpklkvuKjFWgeFuzFU1unLs3vME=.1f2cb67a-0987-4057-bffc-fe9cd3cfd042@github.com>
Message-ID: <7Ias379b9ALHZBOMtmS_iJAj2zXxaGjp4s2hMj5TDS8=.4395ff0f-f56c-47b6-87e8-6651012c7ecc@github.com>

On Mon, 11 Jan 2021 04:50:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> This test was failing on mach5 nightly on ubuntu systems long time back. Modified the test to add some delays and call robot.waitForIdle() to make it more stable and the resultant test passes on all mach5 systems including linux consisting of ubuntu 19.10, 18.04,20.10,20.04 so we can remove the test from problemlist.
>> mach5 job running for several iterations is posted in JBS.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded setAutoDelay

test/jdk/javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java line 220:

> 218:         if (!bufferedImagesEqual(imageIconImage, iconImage)) {
> 219:             ImageIO.write(imageIconImage, "png", new File("imageicon-fail.png"));
> 220:             ImageIO.write(iconImage, "png", new File("iconImage-fail.png"));

Is this for debugging purpose when the test fails ?

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

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

From serb at openjdk.java.net  Mon Jan 11 05:44:55 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 11 Jan 2021 05:44:55 GMT
Subject: <Swing Dev> RFR: 8225045:
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails on
 linux-x64 [v2]
In-Reply-To: <MDwAMXM9fXaKLWqIYpklkvuKjFWgeFuzFU1unLs3vME=.1f2cb67a-0987-4057-bffc-fe9cd3cfd042@github.com>
References: <_Z-JJqhyCnKAUaKRK370cz9rCtIdrdL3bSBtDM-atKA=.c33c5d38-607b-4c72-849c-be0e6442e2c9@github.com>
 <MDwAMXM9fXaKLWqIYpklkvuKjFWgeFuzFU1unLs3vME=.1f2cb67a-0987-4057-bffc-fe9cd3cfd042@github.com>
Message-ID: <I-Ok9kA5GsWazlqhQKAJIWvITNqQz-nkr_zYvL1hitU=.41e17a35-8f26-4a1f-a01b-31737f6f2db7@github.com>

On Mon, 11 Jan 2021 04:50:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> This test was failing on mach5 nightly on ubuntu systems long time back. Modified the test to add some delays and call robot.waitForIdle() to make it more stable and the resultant test passes on all mach5 systems including linux consisting of ubuntu 19.10, 18.04,20.10,20.04 so we can remove the test from problemlist.
>> mach5 job running for several iterations is posted in JBS.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded setAutoDelay

Marked as reviewed by serb (Reviewer).

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

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

From pbansal at openjdk.java.net  Mon Jan 11 06:00:03 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 11 Jan 2021 06:00:03 GMT
Subject: <Swing Dev> RFR: 8225045:
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails on
 linux-x64 [v2]
In-Reply-To: <MDwAMXM9fXaKLWqIYpklkvuKjFWgeFuzFU1unLs3vME=.1f2cb67a-0987-4057-bffc-fe9cd3cfd042@github.com>
References: <_Z-JJqhyCnKAUaKRK370cz9rCtIdrdL3bSBtDM-atKA=.c33c5d38-607b-4c72-849c-be0e6442e2c9@github.com>
 <MDwAMXM9fXaKLWqIYpklkvuKjFWgeFuzFU1unLs3vME=.1f2cb67a-0987-4057-bffc-fe9cd3cfd042@github.com>
Message-ID: <w9Z8cLsPRExuAlF9pDccyk2Ls1cMKWpwHrjGAbP05B4=.fb01965b-0ec6-4f80-82bb-4550f1758b06@github.com>

On Mon, 11 Jan 2021 04:50:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> This test was failing on mach5 nightly on ubuntu systems long time back. Modified the test to add some delays and call robot.waitForIdle() to make it more stable and the resultant test passes on all mach5 systems including linux consisting of ubuntu 19.10, 18.04,20.10,20.04 so we can remove the test from problemlist.
>> mach5 job running for several iterations is posted in JBS.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded setAutoDelay

Marked as reviewed by pbansal (Reviewer).

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

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

From serb at openjdk.java.net  Mon Jan 11 08:19:19 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 11 Jan 2021 08:19:19 GMT
Subject: <Swing Dev> RFR: 8259522: Apply java.io.Serial annotations in
 java.desktop
Message-ID: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>

Please review the application of @java.io.Serial annotation (JDK-8202385) to types in the desktop module to enable stricter compile-time checking of serialization-related declarations.

This annotation can be applied to these methods in the module:

    private void writeObject(java.io.ObjectOutputStream stream) throws IOException
    private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
    private void readObjectNoData() throws ObjectStreamException
    ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
    ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
    private static final ObjectStreamField[] serialPersistentFields
    private static final long serialVersionUID

Notes:
  - I have tried to update the comments for serialVersionUID as accurately as possible, but mostly based on the source code history and bugs in JBS where that field was added
  - Some of the readObject/writeObject methods in the javax.swing package does not have a spec, because this package and some others are excluded from the serialization specification.

A similar fix was implemented for java.base module as well:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html

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

Commit messages:
 - Update TextAttribute.java
 - Update readResolve
 - Update writeReplace
 - Update readObject
 - Update writeObject
 - Update serialPersistentFields
 - Update serialVersionUID

Changes: https://git.openjdk.java.net/jdk/pull/2020/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2020&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259522
  Stats: 3426 lines in 343 files changed: 2268 ins; 287 del; 871 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2020.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2020/head:pull/2020

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

From psadhukhan at openjdk.java.net  Mon Jan 11 08:22:59 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 11 Jan 2021 08:22:59 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection.
In-Reply-To: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
Message-ID: <lGIg_uPD9j5pfmbMr9wvGZQiVw6tSN69WcSx5kvatv4=.3500a5b5-7f89-48a5-b605-c4b7c2319dab@github.com>

On Sat, 9 Jan 2021 12:47:48 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> Please review a fix for jdk16
> 
> Issue: In SwingSet2, if the user navigates through the demos, the demo gets selected/starts on pressing left/right key only. There is no need to press the "space" key. Earlier, on pressing the left/right key, only demo icon used to get focused and user needed to press the "space" to actually select a demo.
> 
> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, when the user pressed Left/Right button, only the selected button used to change. The Action set on JToggleButton used to perform only  on pressing the "Space" button. Now, the Action is performed on navigating the JToggleButtons using Left/Right keys without the need to press the "space" key.
> 
> This issue is a side effect of fix done for https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in JDK-8249548 were not present in JRadioButton as there was code available to handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available for JToggleButton and JRadioButton for all L&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, the AbstractAction is performed on selection of Button itself without the need to press "space". 
> 
> Fix: The current change fixes the issue in present bug and keeps the fixes done in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton for different L&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix.
> 
> Before fix for JDK-8249548
> JToggleButton: 
> For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548.
> JRadioButton: 
> For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. 
> For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action.
> For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space"
> 
> After fix for JDK-8249548
> JToggleButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
> JRadioButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
> 
> After current fix:
> JToggleButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups.  User needs to press "space" to perform the set AbstractAction.
> JRadioButton:
> For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action.
> For all other L&Fs (including Synth L&F), the behaviour is same. User can navigate/select the buttons added to ButtonGroups and set Action is performed without pressing "space"
> 
> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The test TestButtonGroupFocusTraversal.java is modified such that it fails without current fix and passes after the fix. The fix also should be verified by running SwingSet2.

I guess you did not run jtreg job with latest problemlist as it did not run
javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java
javax/swing/JRadioButton/8075609/bug8075609.java
javax/swing/JRadioButton/8033699/bug8033699.java
Please see this test pass with your change as some of them used to fail  after JDK-8226892 which was reworked by fix of  JDK-8249548

src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 228:

> 226:         if (listener != null) {
> 227:             b.removeMouseListener(listener);
> 228:             b.removeMouseListener(listener);

Why are we removing same listener twice?

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From pbansal at openjdk.java.net  Mon Jan 11 08:37:57 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 11 Jan 2021 08:37:57 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection.
In-Reply-To: <lGIg_uPD9j5pfmbMr9wvGZQiVw6tSN69WcSx5kvatv4=.3500a5b5-7f89-48a5-b605-c4b7c2319dab@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
 <lGIg_uPD9j5pfmbMr9wvGZQiVw6tSN69WcSx5kvatv4=.3500a5b5-7f89-48a5-b605-c4b7c2319dab@github.com>
Message-ID: <vaJ3RBhtAW_-WcNRfOPBdWyD_lbiv0XB_74eHpfx9fE=.8c3f0471-cb2c-4256-a748-f0ec98411091@github.com>

On Mon, 11 Jan 2021 08:05:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Please review a fix for jdk16
>> 
>> Issue: In SwingSet2, if the user navigates through the demos, the demo gets selected/starts on pressing left/right key only. There is no need to press the "space" key. Earlier, on pressing the left/right key, only demo icon used to get focused and user needed to press the "space" to actually select a demo.
>> 
>> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, when the user pressed Left/Right button, only the selected button used to change. The Action set on JToggleButton used to perform only  on pressing the "Space" button. Now, the Action is performed on navigating the JToggleButtons using Left/Right keys without the need to press the "space" key.
>> 
>> This issue is a side effect of fix done for https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in JDK-8249548 were not present in JRadioButton as there was code available to handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available for JToggleButton and JRadioButton for all L&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, the AbstractAction is performed on selection of Button itself without the need to press "space". 
>> 
>> Fix: The current change fixes the issue in present bug and keeps the fixes done in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton for different L&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix.
>> 
>> Before fix for JDK-8249548
>> JToggleButton: 
>> For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548.
>> JRadioButton: 
>> For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. 
>> For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action.
>> For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space"
>> 
>> After fix for JDK-8249548
>> JToggleButton:
>> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
>> JRadioButton:
>> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
>> 
>> After current fix:
>> JToggleButton:
>> For all L&Fs, user can navigate/select the buttons added to ButtonGroups.  User needs to press "space" to perform the set AbstractAction.
>> JRadioButton:
>> For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action.
>> For all other L&Fs (including Synth L&F), the behaviour is same. User can navigate/select the buttons added to ButtonGroups and set Action is performed without pressing "space"
>> 
>> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The test TestButtonGroupFocusTraversal.java is modified such that it fails without current fix and passes after the fix. The fix also should be verified by running SwingSet2.
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 228:
> 
>> 226:         if (listener != null) {
>> 227:             b.removeMouseListener(listener);
>> 228:             b.removeMouseListener(listener);
> 
> Why are we removing same listener twice?

I just rolled back the changes I did in this file in JDK-8249548. Looks like this was has been there for some time. See the file in commit made in this file before JDK-8249548 https://github.com/openjdk/jdk/blob/c18080fef714949221c8ddabc4e23d409575c3d3/src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java. 
But yes, it should not be done and I will remove it and update the PR.

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From pbansal at openjdk.java.net  Mon Jan 11 09:52:18 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 11 Jan 2021 09:52:18 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection. [v2]
In-Reply-To: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
Message-ID: <DuaFVSJxGNy9Ckys-vthZvKgVji4pJLBYejlj6PNaPY=.50f196e5-37b6-490f-aec2-a237b1479ce9@github.com>

> Please review a fix for jdk16
> 
> Issue: In SwingSet2, if the user navigates through the demos, the demo gets selected/starts on pressing left/right key only. There is no need to press the "space" key. Earlier, on pressing the left/right key, only demo icon used to get focused and user needed to press the "space" to actually select a demo.
> 
> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, when the user pressed Left/Right button, only the selected button used to change. The Action set on JToggleButton used to perform only  on pressing the "Space" button. Now, the Action is performed on navigating the JToggleButtons using Left/Right keys without the need to press the "space" key.
> 
> This issue is a side effect of fix done for https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in JDK-8249548 were not present in JRadioButton as there was code available to handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available for JToggleButton and JRadioButton for all L&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, the AbstractAction is performed on selection of Button itself without the need to press "space". 
> 
> Fix: The current change fixes the issue in present bug and keeps the fixes done in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton for different L&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix.
> 
> Before fix for JDK-8249548
> JToggleButton: 
> For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548.
> JRadioButton: 
> For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. 
> For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action.
> For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space"
> 
> After fix for JDK-8249548
> JToggleButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
> JRadioButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
> 
> After current fix:
> JToggleButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups.  User needs to press "space" to perform the set AbstractAction.
> JRadioButton:
> For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action.
> For all other L&Fs (including Synth L&F), the behaviour is same. User can navigate/select the buttons added to ButtonGroups and set Action is performed without pressing "space"
> 
> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The test TestButtonGroupFocusTraversal.java is modified such that it fails without current fix and passes after the fix. The fix also should be verified by running SwingSet2.

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

  Remove duplicate call to remove listener

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/99/files
  - new: https://git.openjdk.java.net/jdk16/pull/99/files/903ffcbd..724f5999

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

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/99.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/99/head:pull/99

PR: https://git.openjdk.java.net/jdk16/pull/99

From kizune at openjdk.java.net  Mon Jan 11 11:19:04 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 11 Jan 2021 11:19:04 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection. [v2]
In-Reply-To: <lGIg_uPD9j5pfmbMr9wvGZQiVw6tSN69WcSx5kvatv4=.3500a5b5-7f89-48a5-b605-c4b7c2319dab@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
 <lGIg_uPD9j5pfmbMr9wvGZQiVw6tSN69WcSx5kvatv4=.3500a5b5-7f89-48a5-b605-c4b7c2319dab@github.com>
Message-ID: <LtHsnZIbspthwSFnQyQBaPIGdW9TL_GWZkLMaWb7hqg=.abc44411-51f7-40da-90aa-a2b9bec1c753@github.com>

On Mon, 11 Jan 2021 08:20:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove duplicate call to remove listener
>
> I guess you did not run jtreg job with latest problemlist as it did not run
> javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java
> javax/swing/JRadioButton/8075609/bug8075609.java
> javax/swing/JRadioButton/8033699/bug8033699.java
> Please see this test pass with your change as some of them used to fail  after JDK-8226892 which was reworked by fix of  JDK-8249548

Quick question: why we special casing JRadioButton case? Is there any reason we should call the action on them?

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From pbansal at openjdk.java.net  Mon Jan 11 12:01:04 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 11 Jan 2021 12:01:04 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection. [v2]
In-Reply-To: <LtHsnZIbspthwSFnQyQBaPIGdW9TL_GWZkLMaWb7hqg=.abc44411-51f7-40da-90aa-a2b9bec1c753@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
 <lGIg_uPD9j5pfmbMr9wvGZQiVw6tSN69WcSx5kvatv4=.3500a5b5-7f89-48a5-b605-c4b7c2319dab@github.com>
 <LtHsnZIbspthwSFnQyQBaPIGdW9TL_GWZkLMaWb7hqg=.abc44411-51f7-40da-90aa-a2b9bec1c753@github.com>
Message-ID: <BNoH7zJqMQRdKZWUmU3Ubdq797NAglCVP0T8BhSzuko=.ff2bf736-d95d-4e71-83d9-83ca5a60e148@github.com>

On Mon, 11 Jan 2021 11:16:02 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Quick question: why we special casing JRadioButton case? Is there any reason we should call the action on them?

This was the behaviour which was there before JDK-8249548 for JRadioButton and I am just reverting to it. As explained in the PR description, the behaviour before JDK-8249548 was as below

Before fix for JDK-8249548
JToggleButton:
    For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548.
JRadioButton:
    For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup.
    For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action.
    For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space"

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From pbansal at openjdk.java.net  Mon Jan 11 13:30:15 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 11 Jan 2021 13:30:15 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection. [v3]
In-Reply-To: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
Message-ID: <EdLMyy_wwV7imwOEV0zPbuwOsBhUHP5zbVzugcX60Tw=.5d0840e0-8ffc-466b-aadb-e7ec3678a79a@github.com>

> Please review a fix for jdk16
> 
> Issue: In SwingSet2, if the user navigates through the demos, the demo gets selected/starts on pressing left/right key only. There is no need to press the "space" key. Earlier, on pressing the left/right key, only demo icon used to get focused and user needed to press the "space" to actually select a demo.
> 
> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, when the user pressed Left/Right button, only the selected button used to change. The Action set on JToggleButton used to perform only  on pressing the "Space" button. Now, the Action is performed on navigating the JToggleButtons using Left/Right keys without the need to press the "space" key.
> 
> This issue is a side effect of fix done for https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in JDK-8249548 were not present in JRadioButton as there was code available to handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available for JToggleButton and JRadioButton for all L&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, the AbstractAction is performed on selection of Button itself without the need to press "space". 
> 
> Fix: The current change fixes the issue in present bug and keeps the fixes done in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton for different L&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix.
> 
> Before fix for JDK-8249548
> JToggleButton: 
> For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548.
> JRadioButton: 
> For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. 
> For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action.
> For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space"
> 
> After fix for JDK-8249548
> JToggleButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
> JRadioButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
> 
> After current fix:
> JToggleButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups.  User needs to press "space" to perform the set AbstractAction.
> JRadioButton:
> For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action.
> For all other L&Fs (including Synth L&F), the behaviour is same. User can navigate/select the buttons added to ButtonGroups and set Action is performed without pressing "space"
> 
> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The test TestButtonGroupFocusTraversal.java is modified such that it fails without current fix and passes after the fix. The fix also should be verified by running SwingSet2.

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

  Remove duplicate code for AquaL&F

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/99/files
  - new: https://git.openjdk.java.net/jdk16/pull/99/files/724f5999..de3db58a

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

  Stats: 337 lines in 2 files changed: 19 ins; 317 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/99.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/99/head:pull/99

PR: https://git.openjdk.java.net/jdk16/pull/99

From pbansal at openjdk.java.net  Mon Jan 11 13:40:00 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 11 Jan 2021 13:40:00 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection. [v3]
In-Reply-To: <BNoH7zJqMQRdKZWUmU3Ubdq797NAglCVP0T8BhSzuko=.ff2bf736-d95d-4e71-83d9-83ca5a60e148@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
 <lGIg_uPD9j5pfmbMr9wvGZQiVw6tSN69WcSx5kvatv4=.3500a5b5-7f89-48a5-b605-c4b7c2319dab@github.com>
 <LtHsnZIbspthwSFnQyQBaPIGdW9TL_GWZkLMaWb7hqg=.abc44411-51f7-40da-90aa-a2b9bec1c753@github.com>
 <BNoH7zJqMQRdKZWUmU3Ubdq797NAglCVP0T8BhSzuko=.ff2bf736-d95d-4e71-83d9-83ca5a60e148@github.com>
Message-ID: <TJaFAPgsaNJM8aCvJXdjSNI118CcF_HcVvGHvBorU0c=.62d1b3f9-0a5e-483b-9987-bb2e95a2be8a@github.com>

On Mon, 11 Jan 2021 11:57:49 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> Quick question: why we special casing JRadioButton case? Is there any reason we should call the action on them?
>
>> Quick question: why we special casing JRadioButton case? Is there any reason we should call the action on them?
> 
> This was the behaviour which was there before JDK-8249548 for JRadioButton and I am just reverting to it. As explained in the PR description, the behaviour before JDK-8249548 was as below
> 
> Before fix for JDK-8249548
> JToggleButton:
>     For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548.
> JRadioButton:
>     For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup.
>     For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action.
>     For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space"

I have removed the duplicate code for AquaL&F. I think during the fix made for JDK-8226892, it was a mistake to not change the AquaL&F code. So, the behaviour of JRadioButton should be similar across L&Fs and the duplicate code in AquaL&F is not needed. A mach5 job with all jtreg/jck tests is being run and I will will update when it finishes.

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From kizune at openjdk.java.net  Mon Jan 11 18:17:05 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 11 Jan 2021 18:17:05 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection. [v3]
In-Reply-To: <EdLMyy_wwV7imwOEV0zPbuwOsBhUHP5zbVzugcX60Tw=.5d0840e0-8ffc-466b-aadb-e7ec3678a79a@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
 <EdLMyy_wwV7imwOEV0zPbuwOsBhUHP5zbVzugcX60Tw=.5d0840e0-8ffc-466b-aadb-e7ec3678a79a@github.com>
Message-ID: <oGmg8waIzmcIQ8RWKK5WHFxsiOyXtmVcjTKGU2Mn0ig=.a3ebdf70-6b19-40e3-b265-ce971e8e8d65@github.com>

On Mon, 11 Jan 2021 13:30:15 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> Please review a fix for jdk16
>> 
>> Issue: In SwingSet2, if the user navigates through the demos, the demo gets selected/starts on pressing left/right key only. There is no need to press the "space" key. Earlier, on pressing the left/right key, only demo icon used to get focused and user needed to press the "space" to actually select a demo.
>> 
>> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, when the user pressed Left/Right button, only the selected button used to change. The Action set on JToggleButton used to perform only  on pressing the "Space" button. Now, the Action is performed on navigating the JToggleButtons using Left/Right keys without the need to press the "space" key.
>> 
>> This issue is a side effect of fix done for https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in JDK-8249548 were not present in JRadioButton as there was code available to handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available for JToggleButton and JRadioButton for all L&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, the AbstractAction is performed on selection of Button itself without the need to press "space". 
>> 
>> Fix: The current change fixes the issue in present bug and keeps the fixes done in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton for different L&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix.
>> 
>> Before fix for JDK-8249548
>> JToggleButton: 
>> For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548.
>> JRadioButton: 
>> For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. 
>> For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action.
>> For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space"
>> 
>> After fix for JDK-8249548
>> JToggleButton:
>> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
>> JRadioButton:
>> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
>> 
>> After current fix:
>> JToggleButton:
>> For all L&Fs, user can navigate/select the buttons added to ButtonGroups.  User needs to press "space" to perform the set AbstractAction.
>> JRadioButton:
>> For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action.
>> For all other L&Fs (including Synth L&F), the behaviour is same. User can navigate/select the buttons added to ButtonGroups and set Action is performed without pressing "space"
>> 
>> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The test TestButtonGroupFocusTraversal.java is modified such that it fails without current fix and passes after the fix. The fix also should be verified by running SwingSet2.
>
> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove duplicate code for AquaL&F

Looks ok now.

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

Marked as reviewed by kizune (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/99

From pbansal at openjdk.java.net  Mon Jan 11 18:24:00 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 11 Jan 2021 18:24:00 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection. [v3]
In-Reply-To: <lGIg_uPD9j5pfmbMr9wvGZQiVw6tSN69WcSx5kvatv4=.3500a5b5-7f89-48a5-b605-c4b7c2319dab@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
 <lGIg_uPD9j5pfmbMr9wvGZQiVw6tSN69WcSx5kvatv4=.3500a5b5-7f89-48a5-b605-c4b7c2319dab@github.com>
Message-ID: <B02LbFLgYuetKYzjjcB1VgdvHQJoVbcVI4mCKrwYyPs=.324b0cef-f5be-431a-b509-9d940359a9b3@github.com>

On Mon, 11 Jan 2021 08:20:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I guess you did not run jtreg job with latest problemlist as it did not run
> javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java
> javax/swing/JRadioButton/8075609/bug8075609.java
> javax/swing/JRadioButton/8033699/bug8033699.java
> Please see this test pass with your change as some of them used to fail after JDK-8226892 which was reworked by fix of JDK-8249548

I have updated the PR with some commits and ran the full jtreg/jck tests including the tests you have mentioned. The fix is not breaking anything.

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From psadhukhan at openjdk.java.net  Tue Jan 12 04:02:05 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 12 Jan 2021 04:02:05 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection. [v3]
In-Reply-To: <EdLMyy_wwV7imwOEV0zPbuwOsBhUHP5zbVzugcX60Tw=.5d0840e0-8ffc-466b-aadb-e7ec3678a79a@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
 <EdLMyy_wwV7imwOEV0zPbuwOsBhUHP5zbVzugcX60Tw=.5d0840e0-8ffc-466b-aadb-e7ec3678a79a@github.com>
Message-ID: <1G-TYyhdBLCszc12GMj_LRKqkWbU4U8ADN3qf_NcVVY=.14d71d20-57e4-4ffa-9c79-67a522f5afd6@github.com>

On Mon, 11 Jan 2021 13:30:15 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> Please review a fix for jdk16
>> 
>> Issue: In SwingSet2, if the user navigates through the demos, the demo gets selected/starts on pressing left/right key only. There is no need to press the "space" key. Earlier, on pressing the left/right key, only demo icon used to get focused and user needed to press the "space" to actually select a demo.
>> 
>> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, when the user pressed Left/Right button, only the selected button used to change. The Action set on JToggleButton used to perform only  on pressing the "Space" button. Now, the Action is performed on navigating the JToggleButtons using Left/Right keys without the need to press the "space" key.
>> 
>> This issue is a side effect of fix done for https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in JDK-8249548 were not present in JRadioButton as there was code available to handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available for JToggleButton and JRadioButton for all L&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, the AbstractAction is performed on selection of Button itself without the need to press "space". 
>> 
>> Fix: The current change fixes the issue in present bug and keeps the fixes done in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton for different L&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix.
>> 
>> Before fix for JDK-8249548
>> JToggleButton: 
>> For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548.
>> JRadioButton: 
>> For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. 
>> For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action.
>> For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space"
>> 
>> After fix for JDK-8249548
>> JToggleButton:
>> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
>> JRadioButton:
>> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
>> 
>> After current fix:
>> JToggleButton:
>> For all L&Fs, user can navigate/select the buttons added to ButtonGroups.  User needs to press "space" to perform the set AbstractAction.
>> JRadioButton:
>> For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action.
>> For all other L&Fs (including Synth L&F), the behaviour is same. User can navigate/select the buttons added to ButtonGroups and set Action is performed without pressing "space"
>> 
>> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The test TestButtonGroupFocusTraversal.java is modified such that it fails without current fix and passes after the fix. The fix also should be verified by running SwingSet2.
>
> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove duplicate code for AquaL&F

test/jdk/javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java line 32:

> 30:  * @run main TestButtonGroupFocusTraversal
> 31:  */
> 32: 

We need to append this bugid as product code is changed for which this testcase is modified

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From pbansal at openjdk.java.net  Tue Jan 12 04:18:13 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 12 Jan 2021 04:18:13 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection. [v4]
In-Reply-To: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
Message-ID: <HjtVubH1qGZtNYWdHKpy5AkIgr2Cuthbc1Dckav_Rz4=.b2424454-07cf-4e68-90b1-2e04b623df68@github.com>

> Please review a fix for jdk16
> 
> Issue: In SwingSet2, if the user navigates through the demos, the demo gets selected/starts on pressing left/right key only. There is no need to press the "space" key. Earlier, on pressing the left/right key, only demo icon used to get focused and user needed to press the "space" to actually select a demo.
> 
> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, when the user pressed Left/Right button, only the selected button used to change. The Action set on JToggleButton used to perform only  on pressing the "Space" button. Now, the Action is performed on navigating the JToggleButtons using Left/Right keys without the need to press the "space" key.
> 
> This issue is a side effect of fix done for https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in JDK-8249548 were not present in JRadioButton as there was code available to handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available for JToggleButton and JRadioButton for all L&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, the AbstractAction is performed on selection of Button itself without the need to press "space". 
> 
> Fix: The current change fixes the issue in present bug and keeps the fixes done in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton for different L&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix.
> 
> Before fix for JDK-8249548
> JToggleButton: 
> For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548.
> JRadioButton: 
> For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. 
> For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action.
> For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space"
> 
> After fix for JDK-8249548
> JToggleButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
> JRadioButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
> 
> After current fix:
> JToggleButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups.  User needs to press "space" to perform the set AbstractAction.
> JRadioButton:
> For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action.
> For all other L&Fs (including Synth L&F), the behaviour is same. User can navigate/select the buttons added to ButtonGroups and set Action is performed without pressing "space"
> 
> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The test TestButtonGroupFocusTraversal.java is modified such that it fails without current fix and passes after the fix. The fix also should be verified by running SwingSet2.

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

  Add current bugid

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/99/files
  - new: https://git.openjdk.java.net/jdk16/pull/99/files/de3db58a..6c745600

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/99.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/99/head:pull/99

PR: https://git.openjdk.java.net/jdk16/pull/99

From psadhukhan at openjdk.java.net  Tue Jan 12 04:18:13 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 12 Jan 2021 04:18:13 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection. [v4]
In-Reply-To: <HjtVubH1qGZtNYWdHKpy5AkIgr2Cuthbc1Dckav_Rz4=.b2424454-07cf-4e68-90b1-2e04b623df68@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
 <HjtVubH1qGZtNYWdHKpy5AkIgr2Cuthbc1Dckav_Rz4=.b2424454-07cf-4e68-90b1-2e04b623df68@github.com>
Message-ID: <iWREcKXV14h2hpyxH3_kwB9NQLv4V4PfSV6cziZ9PyA=.ab8f080b-d12b-409c-b5fe-ceaf6c583b13@github.com>

On Tue, 12 Jan 2021 04:15:31 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> Please review a fix for jdk16
>> 
>> Issue: In SwingSet2, if the user navigates through the demos, the demo gets selected/starts on pressing left/right key only. There is no need to press the "space" key. Earlier, on pressing the left/right key, only demo icon used to get focused and user needed to press the "space" to actually select a demo.
>> 
>> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, when the user pressed Left/Right button, only the selected button used to change. The Action set on JToggleButton used to perform only  on pressing the "Space" button. Now, the Action is performed on navigating the JToggleButtons using Left/Right keys without the need to press the "space" key.
>> 
>> This issue is a side effect of fix done for https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in JDK-8249548 were not present in JRadioButton as there was code available to handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available for JToggleButton and JRadioButton for all L&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, the AbstractAction is performed on selection of Button itself without the need to press "space". 
>> 
>> Fix: The current change fixes the issue in present bug and keeps the fixes done in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton for different L&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix.
>> 
>> Before fix for JDK-8249548
>> JToggleButton: 
>> For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548.
>> JRadioButton: 
>> For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. 
>> For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action.
>> For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space"
>> 
>> After fix for JDK-8249548
>> JToggleButton:
>> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
>> JRadioButton:
>> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
>> 
>> After current fix:
>> JToggleButton:
>> For all L&Fs, user can navigate/select the buttons added to ButtonGroups.  User needs to press "space" to perform the set AbstractAction.
>> JRadioButton:
>> For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action.
>> For all other L&Fs (including Synth L&F), the behaviour is same. User can navigate/select the buttons added to ButtonGroups and set Action is performed without pressing "space"
>> 
>> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The test TestButtonGroupFocusTraversal.java is modified such that it fails without current fix and passes after the fix. The fix also should be verified by running SwingSet2.
>
> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add current bugid

Marked as reviewed by psadhukhan (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From pbansal at openjdk.java.net  Tue Jan 12 04:18:14 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 12 Jan 2021 04:18:14 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection. [v3]
In-Reply-To: <1G-TYyhdBLCszc12GMj_LRKqkWbU4U8ADN3qf_NcVVY=.14d71d20-57e4-4ffa-9c79-67a522f5afd6@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
 <EdLMyy_wwV7imwOEV0zPbuwOsBhUHP5zbVzugcX60Tw=.5d0840e0-8ffc-466b-aadb-e7ec3678a79a@github.com>
 <1G-TYyhdBLCszc12GMj_LRKqkWbU4U8ADN3qf_NcVVY=.14d71d20-57e4-4ffa-9c79-67a522f5afd6@github.com>
Message-ID: <iuljCXYGj_ghKn8iye97vrQGTA-kUUZm4tXOjiUNwqo=.a438babd-637f-44ac-8556-0a0b4a4a7cfc@github.com>

On Tue, 12 Jan 2021 03:58:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove duplicate code for AquaL&F
>
> test/jdk/javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java line 32:
> 
>> 30:  * @run main TestButtonGroupFocusTraversal
>> 31:  */
>> 32: 
> 
> We need to append this bugid as product code is changed for which this testcase is modified

Done, please have a look.

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From serb at openjdk.java.net  Tue Jan 12 04:28:58 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Jan 2021 04:28:58 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection. [v4]
In-Reply-To: <iWREcKXV14h2hpyxH3_kwB9NQLv4V4PfSV6cziZ9PyA=.ab8f080b-d12b-409c-b5fe-ceaf6c583b13@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
 <HjtVubH1qGZtNYWdHKpy5AkIgr2Cuthbc1Dckav_Rz4=.b2424454-07cf-4e68-90b1-2e04b623df68@github.com>
 <iWREcKXV14h2hpyxH3_kwB9NQLv4V4PfSV6cziZ9PyA=.ab8f080b-d12b-409c-b5fe-ceaf6c583b13@github.com>
Message-ID: <Zj2359vd8cv27A6XTc-8RdVkwVegTH1z_N5n6eLj1Fs=.d23cb648-b773-4006-b9cb-e6cc92cba9fa@github.com>

On Tue, 12 Jan 2021 04:14:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add current bugid
>
> Marked as reviewed by psadhukhan (Reviewer).

The spec of the update method seems outdated:
         * Find the new toggle button that focus needs to be
         * moved to in the group, select the button

BTW I am not sure why the Aqua is so specific and requires an additional press while the same radio buttons do not require that. Is it possible that some fix was implemented in the shared code so now all L&F skip the "space"?

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From pbansal at openjdk.java.net  Tue Jan 12 04:41:58 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 12 Jan 2021 04:41:58 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection. [v4]
In-Reply-To: <Zj2359vd8cv27A6XTc-8RdVkwVegTH1z_N5n6eLj1Fs=.d23cb648-b773-4006-b9cb-e6cc92cba9fa@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
 <HjtVubH1qGZtNYWdHKpy5AkIgr2Cuthbc1Dckav_Rz4=.b2424454-07cf-4e68-90b1-2e04b623df68@github.com>
 <iWREcKXV14h2hpyxH3_kwB9NQLv4V4PfSV6cziZ9PyA=.ab8f080b-d12b-409c-b5fe-ceaf6c583b13@github.com>
 <Zj2359vd8cv27A6XTc-8RdVkwVegTH1z_N5n6eLj1Fs=.d23cb648-b773-4006-b9cb-e6cc92cba9fa@github.com>
Message-ID: <riIixu68vc7B2Iy9TMjt1JT5JQ6Q0kwZm7pS-cRE3oY=.2bab67e6-4740-4a38-b407-c3c8695d9093@github.com>

On Tue, 12 Jan 2021 04:26:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The spec of the update method seems outdated:
> * Find the new toggle button that focus needs to be
> * moved to in the group, select the button
> 
> BTW I am not sure why the Aqua is so specific and requires an additional press while the same radio buttons do not require that. Is it possible that some fix was implemented in the shared code so now all L&F skip the "space"?

The AquaL&F also does not need the additional "space" press for JRadioButton. During the fix of JDK-8226892, code was added for other L&F, so that the additional "space" press is not needed. But same code was not added for AquaL&F. So, the additional key press was needed. Now, the additional press should not be needed for AquaL&F also for JRadioButton. So now, for all L&Fs, the additional key press is needed for JToggleButton and is not needed for JRadioButton.

I did not add radio button to spec as RadioButton are also ToggleButton only. But yes, I will highlight that. So I will update the spec as below. Hope that is ok.
         * Find the new toggle/radio button that focus needs to be
         * moved to in the group, select the button

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From serb at openjdk.java.net  Tue Jan 12 05:10:01 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Jan 2021 05:10:01 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection. [v4]
In-Reply-To: <riIixu68vc7B2Iy9TMjt1JT5JQ6Q0kwZm7pS-cRE3oY=.2bab67e6-4740-4a38-b407-c3c8695d9093@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
 <HjtVubH1qGZtNYWdHKpy5AkIgr2Cuthbc1Dckav_Rz4=.b2424454-07cf-4e68-90b1-2e04b623df68@github.com>
 <iWREcKXV14h2hpyxH3_kwB9NQLv4V4PfSV6cziZ9PyA=.ab8f080b-d12b-409c-b5fe-ceaf6c583b13@github.com>
 <Zj2359vd8cv27A6XTc-8RdVkwVegTH1z_N5n6eLj1Fs=.d23cb648-b773-4006-b9cb-e6cc92cba9fa@github.com>
 <riIixu68vc7B2Iy9TMjt1JT5JQ6Q0kwZm7pS-cRE3oY=.2bab67e6-4740-4a38-b407-c3c8695d9093@github.com>
Message-ID: <YQ-VfzwFIzTWxfOIGd0nqgZvEbxqXlGb6QseZSIm35k=.9a9826a3-b010-4db3-8864-3668b63444ad@github.com>

On Tue, 12 Jan 2021 04:39:39 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> I did not add radio button to spec as RadioButton are also ToggleButton only. But yes, I will highlight that. So I will update the spec as below. Hope that is ok.
> * Find the new toggle/radio button that focus needs to be
> * moved to in the group, select the button

Also please add a comment of why we need to use the setPressed/setArmed it seems unrelated to the selection of the button, and is not described anywhere.

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From trebari at openjdk.java.net  Tue Jan 12 05:21:03 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Tue, 12 Jan 2021 05:21:03 GMT
Subject: <Swing Dev> RFR: 8225045:
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails on
 linux-x64 [v2]
In-Reply-To: <MDwAMXM9fXaKLWqIYpklkvuKjFWgeFuzFU1unLs3vME=.1f2cb67a-0987-4057-bffc-fe9cd3cfd042@github.com>
References: <_Z-JJqhyCnKAUaKRK370cz9rCtIdrdL3bSBtDM-atKA=.c33c5d38-607b-4c72-849c-be0e6442e2c9@github.com>
 <MDwAMXM9fXaKLWqIYpklkvuKjFWgeFuzFU1unLs3vME=.1f2cb67a-0987-4057-bffc-fe9cd3cfd042@github.com>
Message-ID: <93Y3ruAIsL7iXnTq7UvXbq4uIOsU1CNlJs5MJzgR_a8=.00ba6f9d-2d12-45cb-a7a8-b30488d60f7d@github.com>

On Mon, 11 Jan 2021 04:50:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> This test was failing on mach5 nightly on ubuntu systems long time back. Modified the test to add some delays and call robot.waitForIdle() to make it more stable and the resultant test passes on all mach5 systems including linux consisting of ubuntu 19.10, 18.04,20.10,20.04 so we can remove the test from problemlist.
>> mach5 job running for several iterations is posted in JBS.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded setAutoDelay

Marked as reviewed by trebari (Committer).

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

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

From pbansal at openjdk.java.net  Tue Jan 12 05:56:16 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 12 Jan 2021 05:56:16 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection. [v5]
In-Reply-To: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
Message-ID: <eLYszuAO1qF_5VsRvyCCdJZSvOKb5dIaByGRBQXAF2A=.59ee7bdd-08d1-4221-a355-9a0b33d8ea15@github.com>

> Please review a fix for jdk16
> 
> Issue: In SwingSet2, if the user navigates through the demos, the demo gets selected/starts on pressing left/right key only. There is no need to press the "space" key. Earlier, on pressing the left/right key, only demo icon used to get focused and user needed to press the "space" to actually select a demo.
> 
> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, when the user pressed Left/Right button, only the selected button used to change. The Action set on JToggleButton used to perform only  on pressing the "Space" button. Now, the Action is performed on navigating the JToggleButtons using Left/Right keys without the need to press the "space" key.
> 
> This issue is a side effect of fix done for https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in JDK-8249548 were not present in JRadioButton as there was code available to handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available for JToggleButton and JRadioButton for all L&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, the AbstractAction is performed on selection of Button itself without the need to press "space". 
> 
> Fix: The current change fixes the issue in present bug and keeps the fixes done in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton for different L&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix.
> 
> Before fix for JDK-8249548
> JToggleButton: 
> For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548.
> JRadioButton: 
> For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. 
> For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action.
> For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space"
> 
> After fix for JDK-8249548
> JToggleButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
> JRadioButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
> 
> After current fix:
> JToggleButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups.  User needs to press "space" to perform the set AbstractAction.
> JRadioButton:
> For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action.
> For all other L&Fs (including Synth L&F), the behaviour is same. User can navigate/select the buttons added to ButtonGroups and set Action is performed without pressing "space"
> 
> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The test TestButtonGroupFocusTraversal.java is modified such that it fails without current fix and passes after the fix. The fix also should be verified by running SwingSet2.

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

  Update Spec

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/99/files
  - new: https://git.openjdk.java.net/jdk16/pull/99/files/6c745600..fca7f7a4

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

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From pbansal at openjdk.java.net  Tue Jan 12 05:56:16 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 12 Jan 2021 05:56:16 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection. [v4]
In-Reply-To: <YQ-VfzwFIzTWxfOIGd0nqgZvEbxqXlGb6QseZSIm35k=.9a9826a3-b010-4db3-8864-3668b63444ad@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
 <HjtVubH1qGZtNYWdHKpy5AkIgr2Cuthbc1Dckav_Rz4=.b2424454-07cf-4e68-90b1-2e04b623df68@github.com>
 <iWREcKXV14h2hpyxH3_kwB9NQLv4V4PfSV6cziZ9PyA=.ab8f080b-d12b-409c-b5fe-ceaf6c583b13@github.com>
 <Zj2359vd8cv27A6XTc-8RdVkwVegTH1z_N5n6eLj1Fs=.d23cb648-b773-4006-b9cb-e6cc92cba9fa@github.com>
 <riIixu68vc7B2Iy9TMjt1JT5JQ6Q0kwZm7pS-cRE3oY=.2bab67e6-4740-4a38-b407-c3c8695d9093@github.com>
 <YQ-VfzwFIzTWxfOIGd0nqgZvEbxqXlGb6QseZSIm35k=.9a9826a3-b010-4db3-8864-3668b63444ad@github.com>
Message-ID: <40WXxYHrQoinLbEVbHlp58UUv5Bdzg5x_wFptPAOibM=.2cb48050-c47b-4806-858d-705fdbdc4d31@github.com>

On Tue, 12 Jan 2021 05:07:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I did not add radio button to spec as RadioButton are also ToggleButton only. But yes, I will highlight that. So I will update the spec as below. Hope that is ok.
> > 
> > * Find the new toggle/radio button that focus needs to be
> > * moved to in the group, select the button
> 
> Also please add a comment of why we need to use the setPressed/setArmed it seems unrelated to the selection of the button, and is not described anywhere.

Done, please have a look.

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From serb at openjdk.java.net  Tue Jan 12 06:24:01 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Jan 2021 06:24:01 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection. [v5]
In-Reply-To: <eLYszuAO1qF_5VsRvyCCdJZSvOKb5dIaByGRBQXAF2A=.59ee7bdd-08d1-4221-a355-9a0b33d8ea15@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
 <eLYszuAO1qF_5VsRvyCCdJZSvOKb5dIaByGRBQXAF2A=.59ee7bdd-08d1-4221-a355-9a0b33d8ea15@github.com>
Message-ID: <0VUkqD1QzgxChCwQY-u3_I-bJOX6-LlrRLCxaKkDqSA=.a9ed2a08-b06a-4b3c-ae61-bd7d9a2ebd69@github.com>

On Tue, 12 Jan 2021 05:56:16 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> Please review a fix for jdk16
>> 
>> Issue: In SwingSet2, if the user navigates through the demos, the demo gets selected/starts on pressing left/right key only. There is no need to press the "space" key. Earlier, on pressing the left/right key, only demo icon used to get focused and user needed to press the "space" to actually select a demo.
>> 
>> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, when the user pressed Left/Right button, only the selected button used to change. The Action set on JToggleButton used to perform only  on pressing the "Space" button. Now, the Action is performed on navigating the JToggleButtons using Left/Right keys without the need to press the "space" key.
>> 
>> This issue is a side effect of fix done for https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in JDK-8249548 were not present in JRadioButton as there was code available to handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available for JToggleButton and JRadioButton for all L&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, the AbstractAction is performed on selection of Button itself without the need to press "space". 
>> 
>> Fix: The current change fixes the issue in present bug and keeps the fixes done in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton for different L&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix.
>> 
>> Before fix for JDK-8249548
>> JToggleButton: 
>> For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548.
>> JRadioButton: 
>> For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. 
>> For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action.
>> For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space"
>> 
>> After fix for JDK-8249548
>> JToggleButton:
>> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
>> JRadioButton:
>> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
>> 
>> After current fix:
>> JToggleButton:
>> For all L&Fs, user can navigate/select the buttons added to ButtonGroups.  User needs to press "space" to perform the set AbstractAction.
>> JRadioButton:
>> For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action.
>> For all other L&Fs (including Synth L&F), the behaviour is same. User can navigate/select the buttons added to ButtonGroups and set Action is performed without pressing "space"
>> 
>> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The test TestButtonGroupFocusTraversal.java is modified such that it fails without current fix and passes after the fix. The fix also should be verified by running SwingSet2.
>
> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Spec

test/jdk/javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java line 80:

> 78:                 toggleButton2 = new JToggleButton("2");
> 79:                 radioButton1 = new JRadioButton("1");
> 80:                 radioButton2 = new JRadioButton("2");

Just to be safe please check the JCheckBox, it also extends the JToggleButton and we should not break it.

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From pbansal at openjdk.java.net  Tue Jan 12 07:08:16 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 12 Jan 2021 07:08:16 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection. [v6]
In-Reply-To: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
Message-ID: <Tk0iMl-cWfW-rSVkh647kL14F5_NeFPJXOD_ecF1wlk=.6bf697d7-0780-474a-9e1f-5fe7e2f85dd9@github.com>

> Please review a fix for jdk16
> 
> Issue: In SwingSet2, if the user navigates through the demos, the demo gets selected/starts on pressing left/right key only. There is no need to press the "space" key. Earlier, on pressing the left/right key, only demo icon used to get focused and user needed to press the "space" to actually select a demo.
> 
> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, when the user pressed Left/Right button, only the selected button used to change. The Action set on JToggleButton used to perform only  on pressing the "Space" button. Now, the Action is performed on navigating the JToggleButtons using Left/Right keys without the need to press the "space" key.
> 
> This issue is a side effect of fix done for https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in JDK-8249548 were not present in JRadioButton as there was code available to handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available for JToggleButton and JRadioButton for all L&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, the AbstractAction is performed on selection of Button itself without the need to press "space". 
> 
> Fix: The current change fixes the issue in present bug and keeps the fixes done in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton for different L&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix.
> 
> Before fix for JDK-8249548
> JToggleButton: 
> For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548.
> JRadioButton: 
> For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. 
> For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action.
> For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space"
> 
> After fix for JDK-8249548
> JToggleButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
> JRadioButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
> 
> After current fix:
> JToggleButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups.  User needs to press "space" to perform the set AbstractAction.
> JRadioButton:
> For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action.
> For all other L&Fs (including Synth L&F), the behaviour is same. User can navigate/select the buttons added to ButtonGroups and set Action is performed without pressing "space"
> 
> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The test TestButtonGroupFocusTraversal.java is modified such that it fails without current fix and passes after the fix. The fix also should be verified by running SwingSet2.

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

  Add checkbox in test

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/99/files
  - new: https://git.openjdk.java.net/jdk16/pull/99/files/fca7f7a4..9962d615

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=99&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=99&range=04-05

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From serb at openjdk.java.net  Tue Jan 12 09:29:59 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Jan 2021 09:29:59 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection. [v6]
In-Reply-To: <Tk0iMl-cWfW-rSVkh647kL14F5_NeFPJXOD_ecF1wlk=.6bf697d7-0780-474a-9e1f-5fe7e2f85dd9@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
 <Tk0iMl-cWfW-rSVkh647kL14F5_NeFPJXOD_ecF1wlk=.6bf697d7-0780-474a-9e1f-5fe7e2f85dd9@github.com>
Message-ID: <VcWN8d7dRVWJUQJZunp6K1R4jJ9cr-6EBnHBglHZ-DA=.5886ee85-f3a8-43ac-a8e0-0300bcf99464@github.com>

On Tue, 12 Jan 2021 07:08:16 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> Please review a fix for jdk16
>> 
>> Issue: In SwingSet2, if the user navigates through the demos, the demo gets selected/starts on pressing left/right key only. There is no need to press the "space" key. Earlier, on pressing the left/right key, only demo icon used to get focused and user needed to press the "space" to actually select a demo.
>> 
>> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, when the user pressed Left/Right button, only the selected button used to change. The Action set on JToggleButton used to perform only  on pressing the "Space" button. Now, the Action is performed on navigating the JToggleButtons using Left/Right keys without the need to press the "space" key.
>> 
>> This issue is a side effect of fix done for https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in JDK-8249548 were not present in JRadioButton as there was code available to handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available for JToggleButton and JRadioButton for all L&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, the AbstractAction is performed on selection of Button itself without the need to press "space". 
>> 
>> Fix: The current change fixes the issue in present bug and keeps the fixes done in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton for different L&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix.
>> 
>> Before fix for JDK-8249548
>> JToggleButton: 
>> For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548.
>> JRadioButton: 
>> For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. 
>> For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action.
>> For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space"
>> 
>> After fix for JDK-8249548
>> JToggleButton:
>> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
>> JRadioButton:
>> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
>> 
>> After current fix:
>> JToggleButton:
>> For all L&Fs, user can navigate/select the buttons added to ButtonGroups.  User needs to press "space" to perform the set AbstractAction.
>> JRadioButton:
>> For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action.
>> For all other L&Fs (including Synth L&F), the behaviour is same. User can navigate/select the buttons added to ButtonGroups and set Action is performed without pressing "space"
>> 
>> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The test TestButtonGroupFocusTraversal.java is modified such that it fails without current fix and passes after the fix. The fix also should be verified by running SwingSet2.
>
> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add checkbox in test

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From serb at openjdk.java.net  Tue Jan 12 09:30:00 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Jan 2021 09:30:00 GMT
Subject: <Swing Dev> [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection. [v4]
In-Reply-To: <40WXxYHrQoinLbEVbHlp58UUv5Bdzg5x_wFptPAOibM=.2cb48050-c47b-4806-858d-705fdbdc4d31@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
 <HjtVubH1qGZtNYWdHKpy5AkIgr2Cuthbc1Dckav_Rz4=.b2424454-07cf-4e68-90b1-2e04b623df68@github.com>
 <iWREcKXV14h2hpyxH3_kwB9NQLv4V4PfSV6cziZ9PyA=.ab8f080b-d12b-409c-b5fe-ceaf6c583b13@github.com>
 <Zj2359vd8cv27A6XTc-8RdVkwVegTH1z_N5n6eLj1Fs=.d23cb648-b773-4006-b9cb-e6cc92cba9fa@github.com>
 <riIixu68vc7B2Iy9TMjt1JT5JQ6Q0kwZm7pS-cRE3oY=.2bab67e6-4740-4a38-b407-c3c8695d9093@github.com>
 <YQ-VfzwFIzTWxfOIGd0nqgZvEbxqXlGb6QseZSIm35k=.9a9826a3-b010-4db3-8864-3668b63444ad@github.com>
 <40WXxYHrQoinLbEVbHlp58UUv5Bdzg5x_wFptPAOibM=.2cb48050-c47b-4806-858d-705fdbdc4d31@github.com>
Message-ID: <au7LAXf0PqCC1p1IbhLzdaPFyxedz0ZeoyUvJitVYIc=.58413351-7c88-4b54-8a9f-41f92af6609f@github.com>

On Tue, 12 Jan 2021 05:52:33 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>>> I did not add radio button to spec as RadioButton are also ToggleButton only. But yes, I will highlight that. So I will update the spec as below. Hope that is ok.
>>> * Find the new toggle/radio button that focus needs to be
>>> * moved to in the group, select the button
>> 
>> Also please add a comment of why we need to use the setPressed/setArmed it seems unrelated to the selection of the button, and is not described anywhere.
>
>> > I did not add radio button to spec as RadioButton are also ToggleButton only. But yes, I will highlight that. So I will update the spec as below. Hope that is ok.
>> > 
>> > * Find the new toggle/radio button that focus needs to be
>> > * moved to in the group, select the button
>> 
>> Also please add a comment of why we need to use the setPressed/setArmed it seems unrelated to the selection of the button, and is not described anywhere.
> 
> Done, please have a look.

Just small summary info for the future: we have a JToggleButton class and two subclasses: JCheckBox and JRadioButton.
1. It was decided(but not strictly specified) to generate an action when the selection is changed by the arrow keys for JRadioButton. It is just common sense.
2. It was decided to not generate an action when the selection is changed by arrow keys for JCheckBox. Since the user should have the ability to move over different checkboxes without toggling them.
3. The parent class JToggleButton is a root cause of the current bug under discussion. We could implement it in any way, we can generate an action when the user presses the arrow key, but the opposite just a safer solution now.

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From pbansal at openjdk.java.net  Tue Jan 12 09:48:56 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 12 Jan 2021 09:48:56 GMT
Subject: <Swing Dev> [jdk16] Integrated: 8259237: Demo selection changes
 with left/right arrow key. No need to press space for selection.
In-Reply-To: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
Message-ID: <NmYPmPleQMsI5XEUM__hEvzomeN264160cJlJ4zPxZs=.b1229136-40a3-42fc-83f3-0f9b2b3930e5@github.com>

On Sat, 9 Jan 2021 12:47:48 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> Please review a fix for jdk16
> 
> Issue: In SwingSet2, if the user navigates through the demos, the demo gets selected/starts on pressing left/right key only. There is no need to press the "space" key. Earlier, on pressing the left/right key, only demo icon used to get focused and user needed to press the "space" to actually select a demo.
> 
> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, when the user pressed Left/Right button, only the selected button used to change. The Action set on JToggleButton used to perform only  on pressing the "Space" button. Now, the Action is performed on navigating the JToggleButtons using Left/Right keys without the need to press the "space" key.
> 
> This issue is a side effect of fix done for https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in JDK-8249548 were not present in JRadioButton as there was code available to handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available for JToggleButton and JRadioButton for all L&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, the AbstractAction is performed on selection of Button itself without the need to press "space". 
> 
> Fix: The current change fixes the issue in present bug and keeps the fixes done in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton for different L&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix.
> 
> Before fix for JDK-8249548
> JToggleButton: 
> For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548.
> JRadioButton: 
> For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. 
> For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action.
> For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space"
> 
> After fix for JDK-8249548
> JToggleButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
> JRadioButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
> 
> After current fix:
> JToggleButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups.  User needs to press "space" to perform the set AbstractAction.
> JRadioButton:
> For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action.
> For all other L&Fs (including Synth L&F), the behaviour is same. User can navigate/select the buttons added to ButtonGroups and set Action is performed without pressing "space"
> 
> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The test TestButtonGroupFocusTraversal.java is modified such that it fails without current fix and passes after the fix. The fix also should be verified by running SwingSet2.

This pull request has now been integrated.

Changeset: 28ff2de1
Author:    Pankaj Bansal <pbansal at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/28ff2de1
Stats:     99 lines in 2 files changed: 92 ins; 1 del; 6 mod

8259237: Demo selection changes with left/right arrow key. No need to press space for selection.

Reviewed-by: psadhukhan, kizune, serb

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From aivanov at openjdk.java.net  Tue Jan 12 20:25:56 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 12 Jan 2021 20:25:56 GMT
Subject: <Swing Dev> RFR: 8259522: Apply java.io.Serial annotations in
 java.desktop
In-Reply-To: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>
References: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>
Message-ID: <UztmJrze0OeVjg6dEapP5V_nrHNSw4tpoLmh1gvDRMI=.8db78595-8929-43ea-8194-95989eca450f@github.com>

On Mon, 11 Jan 2021 06:21:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please review the application of @java.io.Serial annotation (JDK-8202385) to types in the desktop module to enable stricter compile-time checking of serialization-related declarations.
> 
> This annotation can be applied to these methods in the module:
> 
>     private void writeObject(java.io.ObjectOutputStream stream) throws IOException
>     private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
>     private void readObjectNoData() throws ObjectStreamException
>     ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
>     ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
>     private static final ObjectStreamField[] serialPersistentFields
>     private static final long serialVersionUID
> 
> Notes:
>   - I have tried to update the comments for serialVersionUID as accurately as possible, but mostly based on the source code history and bugs in JBS where that field was added
>   - Some of the readObject/writeObject methods in the javax.swing package does not have a spec, because this package and some others are excluded from the serialization specification.
> 
> A similar fix was implemented for java.base module as well:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/share/classes/com/sun/media/sound/InvalidDataException.java line 42:

> 40:      */
> 41:     @Serial
> 42:     private static final long serialVersionUID = 1L;

This is the standard wording, yet should it mention the serialization is between the same versions only because the value of serialVersionUID is not unique?

src/java.desktop/share/classes/java/awt/image/RasterFormatException.java line 28:

> 26: package java.awt.image;
> 27: 
> 28: 

Suggestion:


In the majority of classes, there's only one empty line between package declaration and the first import statement.

src/java.desktop/share/classes/java/awt/image/ImagingOpException.java line 28:

> 26: package java.awt.image;
> 27: 
> 28: 

Suggestion:

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

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

From serb at openjdk.java.net  Tue Jan 12 20:42:18 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Jan 2021 20:42:18 GMT
Subject: <Swing Dev> RFR: 8259522: Apply java.io.Serial annotations in
 java.desktop [v2]
In-Reply-To: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>
References: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>
Message-ID: <7X46pwNuTDGbEN3-jFa2QY2qUtMCK2dAu-BiPdoMK14=.19bc926b-62ba-4f79-8f32-be27898077a8@github.com>

> Please review the application of @java.io.Serial annotation (JDK-8202385) to types in the desktop module to enable stricter compile-time checking of serialization-related declarations.
> 
> This annotation can be applied to these methods in the module:
> 
>     private void writeObject(java.io.ObjectOutputStream stream) throws IOException
>     private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
>     private void readObjectNoData() throws ObjectStreamException
>     ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
>     ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
>     private static final ObjectStreamField[] serialPersistentFields
>     private static final long serialVersionUID
> 
> Notes:
>   - I have tried to update the comments for serialVersionUID as accurately as possible, but mostly based on the source code history and bugs in JBS where that field was added
>   - Some of the readObject/writeObject methods in the javax.swing package does not have a spec, because this package and some others are excluded from the serialization specification.
> 
> A similar fix was implemented for java.base module as well:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html

Sergey Bylokhov has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.desktop/share/classes/java/awt/image/ImagingOpException.java
   
   Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/java/awt/image/RasterFormatException.java
   
   Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2020/files
  - new: https://git.openjdk.java.net/jdk/pull/2020/files/2e50a258..502c1a40

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

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

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

From serb at openjdk.java.net  Tue Jan 12 20:42:19 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Jan 2021 20:42:19 GMT
Subject: <Swing Dev> RFR: 8259522: Apply java.io.Serial annotations in
 java.desktop [v2]
In-Reply-To: <UztmJrze0OeVjg6dEapP5V_nrHNSw4tpoLmh1gvDRMI=.8db78595-8929-43ea-8194-95989eca450f@github.com>
References: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>
 <UztmJrze0OeVjg6dEapP5V_nrHNSw4tpoLmh1gvDRMI=.8db78595-8929-43ea-8194-95989eca450f@github.com>
Message-ID: <jEKeQUNA-jwXnAiKoNZHHZn98Qhrudsp4JEw42uyZOg=.51107fd8-8634-4db8-8628-f9c79171d399@github.com>

On Tue, 12 Jan 2021 11:29:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/java.desktop/share/classes/java/awt/image/ImagingOpException.java
>>    
>>    Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/java/awt/image/RasterFormatException.java
>>    
>>    Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>
> src/java.desktop/share/classes/com/sun/media/sound/InvalidDataException.java line 42:
> 
>> 40:      */
>> 41:     @Serial
>> 42:     private static final long serialVersionUID = 1L;
> 
> This is the standard wording, yet should it mention the serialization is between the same versions only because the value of serialVersionUID is not unique?

I think it is "quite" unique, the "1L" is used from the beginning. It is just different from the value which could be generated by the "serialver" but still should work fine.

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

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

From aivanov at openjdk.java.net  Tue Jan 12 21:58:14 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 12 Jan 2021 21:58:14 GMT
Subject: <Swing Dev> RFR: 8259522: Apply java.io.Serial annotations in
 java.desktop [v2]
In-Reply-To: <jEKeQUNA-jwXnAiKoNZHHZn98Qhrudsp4JEw42uyZOg=.51107fd8-8634-4db8-8628-f9c79171d399@github.com>
References: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>
 <UztmJrze0OeVjg6dEapP5V_nrHNSw4tpoLmh1gvDRMI=.8db78595-8929-43ea-8194-95989eca450f@github.com>
 <jEKeQUNA-jwXnAiKoNZHHZn98Qhrudsp4JEw42uyZOg=.51107fd8-8634-4db8-8628-f9c79171d399@github.com>
Message-ID: <eHpId3lh9IG_0cG0uspjUi6kCrxfYgVYUSbb3XSQiQU=.5e6df1db-b584-4630-be4b-26f0d1be955c@github.com>

On Tue, 12 Jan 2021 20:36:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/media/sound/InvalidDataException.java line 42:
>> 
>>> 40:      */
>>> 41:     @Serial
>>> 42:     private static final long serialVersionUID = 1L;
>> 
>> This is the standard wording, yet should it mention the serialization is between the same versions only because the value of serialVersionUID is not unique?
>
> I think it is "quite" unique, the "1L" is used from the beginning. It is just different from the value which could be generated by the "serialver" but still should work fine.

Okay. There are several classes which extend this one, all of them use the same 1L value which makes it not "quite" unique.

Changing the values at this time presents more risks than benefits.

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

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

From psadhukhan at openjdk.java.net  Wed Jan 13 05:56:00 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 13 Jan 2021 05:56:00 GMT
Subject: <Swing Dev> RFR: 8049700: Deprecate obsolete classes and
 methods in javax/swing/plaf/basic
In-Reply-To: <LcIvlc2HZGDo6ErOfqf_QZlwCpO2a7o2pPIDeaCb40E=.80fa98b5-728e-4198-a4fd-8d70e21302fc@github.com>
References: <LcIvlc2HZGDo6ErOfqf_QZlwCpO2a7o2pPIDeaCb40E=.80fa98b5-728e-4198-a4fd-8d70e21302fc@github.com>
Message-ID: <y3oqqpwrNBwm3msFEQzyThS0DiGor2HrFHWG8lJRVWw=.3c80f178-4bc5-4bb6-87ca-ddf20890e7a7@github.com>

On Wed, 6 Jan 2021 12:43:41 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

> Please review the following fix for jdk17.
> In this fix i have deprecated and marked for removal following classes and methods 
>    public void intervalAdded(ListDataEvent e)
>    public void intervalRemoved(ListDataEvent e)
>    protected boolean lt(File a, File b) in BasicDirectoryModel.java
> 
>    inner class PropertyChangeHandler, VSBChangeListener, HSBChangeListener, 
>    ViewportChangeHandler in BasicScrollPaneUI.java
>    inner class MouseInputHandler in BasicMenuItemUI.java
>    method BasicToolBarUI.java#createFloatingFrame
> 
> From 8049700 not deprecated the paintText(Graphics g, JComponent c, Rectangle textRect, String text) method in BasicButtonUI  as AquaButtonUI, MetalButtonUI and MetalToggleButtonUI overrides it.
> Similarly not deprecated ChangeHandler of BasicMenuUI as AquaMenuUI and MotifMenuUI uses this class.

Please elaborate as to why this methods are to be deprecated.
It will be useful if you give alternate methods to be used in the javadoc in @deprecated tag 
which are supposed to be called by user once these are removed.

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

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

From psadhukhan at openjdk.java.net  Wed Jan 13 06:13:57 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 13 Jan 2021 06:13:57 GMT
Subject: <Swing Dev> RFR: 8259522: Apply java.io.Serial annotations in
 java.desktop [v2]
In-Reply-To: <7X46pwNuTDGbEN3-jFa2QY2qUtMCK2dAu-BiPdoMK14=.19bc926b-62ba-4f79-8f32-be27898077a8@github.com>
References: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>
 <7X46pwNuTDGbEN3-jFa2QY2qUtMCK2dAu-BiPdoMK14=.19bc926b-62ba-4f79-8f32-be27898077a8@github.com>
Message-ID: <0BeCSRlVfit-78buTvO8-tci6rZDhwsML4JXKzujLM8=.ff5ba622-5c99-4925-b690-5b348d0d0e18@github.com>

On Tue, 12 Jan 2021 20:42:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Please review the application of @java.io.Serial annotation (JDK-8202385) to types in the desktop module to enable stricter compile-time checking of serialization-related declarations.
>> 
>> This annotation can be applied to these methods in the module:
>> 
>>     private void writeObject(java.io.ObjectOutputStream stream) throws IOException
>>     private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
>>     private void readObjectNoData() throws ObjectStreamException
>>     ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
>>     ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
>>     private static final ObjectStreamField[] serialPersistentFields
>>     private static final long serialVersionUID
>> 
>> Notes:
>>   - I have tried to update the comments for serialVersionUID as accurately as possible, but mostly based on the source code history and bugs in JBS where that field was added
>>   - Some of the readObject/writeObject methods in the javax.swing package does not have a spec, because this package and some others are excluded from the serialization specification.
>> 
>> A similar fix was implemented for java.base module as well:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html
>
> Sergey Bylokhov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.desktop/share/classes/java/awt/image/ImagingOpException.java
>    
>    Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/java/awt/image/RasterFormatException.java
>    
>    Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

Why do we add serialVersionUID in some classes like DefaultMutableTreeNode.java but not in other swing classes?
Also, if this change is for stricter compile-time checking, shouldn't we remove @SuppressWarnings("serial") check?

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

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

From psadhukhan at openjdk.java.net  Wed Jan 13 07:01:01 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 13 Jan 2021 07:01:01 GMT
Subject: <Swing Dev> Integrated: 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: <IwnE70TAYWOV99pVlTGxbMakT-qCF6NhDg2LnnIFMCc=.b61398f2-dd45-47bc-a2d6-af1479642817@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.

This pull request has now been integrated.

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

8256019: JLabel HTML text does not support translucent text colors

Reviewed-by: serb

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

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

From psadhukhan at openjdk.java.net  Wed Jan 13 07:03:56 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 13 Jan 2021 07:03:56 GMT
Subject: <Swing Dev> RFR: 8225045:
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails on
 linux-x64 [v2]
In-Reply-To: <7Ias379b9ALHZBOMtmS_iJAj2zXxaGjp4s2hMj5TDS8=.4395ff0f-f56c-47b6-87e8-6651012c7ecc@github.com>
References: <_Z-JJqhyCnKAUaKRK370cz9rCtIdrdL3bSBtDM-atKA=.c33c5d38-607b-4c72-849c-be0e6442e2c9@github.com>
 <MDwAMXM9fXaKLWqIYpklkvuKjFWgeFuzFU1unLs3vME=.1f2cb67a-0987-4057-bffc-fe9cd3cfd042@github.com>
 <7Ias379b9ALHZBOMtmS_iJAj2zXxaGjp4s2hMj5TDS8=.4395ff0f-f56c-47b6-87e8-6651012c7ecc@github.com>
Message-ID: <AQV1xRm7RkqOF1JcrwBLaQ7ChpjhpF93QETryVslKgI=.dd1c4781-2cde-432c-a715-18310e5f9456@github.com>

On Mon, 11 Jan 2021 05:31:15 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unneeded setAutoDelay
>
> test/jdk/javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java line 220:
> 
>> 218:         if (!bufferedImagesEqual(imageIconImage, iconImage)) {
>> 219:             ImageIO.write(imageIconImage, "png", new File("imageicon-fail.png"));
>> 220:             ImageIO.write(iconImage, "png", new File("iconImage-fail.png"));
> 
> Is this for debugging purpose when the test fails ?

yes

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

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

From psadhukhan at openjdk.java.net  Wed Jan 13 07:03:57 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 13 Jan 2021 07:03:57 GMT
Subject: <Swing Dev> Integrated: 8225045:
 javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails on
 linux-x64
In-Reply-To: <_Z-JJqhyCnKAUaKRK370cz9rCtIdrdL3bSBtDM-atKA=.c33c5d38-607b-4c72-849c-be0e6442e2c9@github.com>
References: <_Z-JJqhyCnKAUaKRK370cz9rCtIdrdL3bSBtDM-atKA=.c33c5d38-607b-4c72-849c-be0e6442e2c9@github.com>
Message-ID: <t-MQ1Z9lK3Zr9Jp1KpoqExa5oEJAHUhfAjVKPZn6avI=.5d441e0c-1fce-4c3a-be3a-9bebde2cbdcd@github.com>

On Fri, 8 Jan 2021 11:03:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test was failing on mach5 nightly on ubuntu systems long time back. Modified the test to add some delays and call robot.waitForIdle() to make it more stable and the resultant test passes on all mach5 systems including linux consisting of ubuntu 19.10, 18.04,20.10,20.04 so we can remove the test from problemlist.
> mach5 job running for several iterations is posted in JBS.

This pull request has now been integrated.

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

8225045: javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails on linux-x64

Reviewed-by: serb, pbansal, trebari

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

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

From serb at openjdk.java.net  Wed Jan 13 07:07:54 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 13 Jan 2021 07:07:54 GMT
Subject: <Swing Dev> RFR: 8259522: Apply java.io.Serial annotations in
 java.desktop [v2]
In-Reply-To: <0BeCSRlVfit-78buTvO8-tci6rZDhwsML4JXKzujLM8=.ff5ba622-5c99-4925-b690-5b348d0d0e18@github.com>
References: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>
 <7X46pwNuTDGbEN3-jFa2QY2qUtMCK2dAu-BiPdoMK14=.19bc926b-62ba-4f79-8f32-be27898077a8@github.com>
 <0BeCSRlVfit-78buTvO8-tci6rZDhwsML4JXKzujLM8=.ff5ba622-5c99-4925-b690-5b348d0d0e18@github.com>
Message-ID: <ovc9uQxs9Nsvg5htYdyziTomnyod4crBGjDNjpBwiUk=.24dc5383-bb0c-4013-a049-8226fc1e81b7@github.com>

On Wed, 13 Jan 2021 06:10:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Why do we add serialVersionUID in some classes like DefaultMutableTreeNode.java but not in other swing classes?

Most Swing classes are marked by the specific "Warning" that "Same-version serialization only" is supported. (I think such a warning is missed in a few classes). So generally the serialVersionUID field is not needed in such classes, but if present this provides a small benefit -> this UID is not generated at runtime.

For example, the DefaultMutableTreeNode was updated by the JDK-5017904 fix, which was unrelated to serialization but was targeted for the performance issue.

> Also, if this change is for stricter compile-time checking, shouldn't we remove @SuppressWarnings("serial") check?

At some point, we probably can remove it but will need to fix all serialization warnings which were disabled.

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

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

From psadhukhan at openjdk.java.net  Wed Jan 13 07:34:56 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 13 Jan 2021 07:34:56 GMT
Subject: <Swing Dev> RFR: 8259522: Apply java.io.Serial annotations in
 java.desktop [v2]
In-Reply-To: <7X46pwNuTDGbEN3-jFa2QY2qUtMCK2dAu-BiPdoMK14=.19bc926b-62ba-4f79-8f32-be27898077a8@github.com>
References: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>
 <7X46pwNuTDGbEN3-jFa2QY2qUtMCK2dAu-BiPdoMK14=.19bc926b-62ba-4f79-8f32-be27898077a8@github.com>
Message-ID: <o6X-8cvIt6irtlI8WJGGl7ihtAzO2dau_KSDayRdh2Q=.36788283-5a33-4e4f-97f5-890d36d18359@github.com>

On Tue, 12 Jan 2021 20:42:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Please review the application of @java.io.Serial annotation (JDK-8202385) to types in the desktop module to enable stricter compile-time checking of serialization-related declarations.
>> 
>> This annotation can be applied to these methods in the module:
>> 
>>     private void writeObject(java.io.ObjectOutputStream stream) throws IOException
>>     private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
>>     private void readObjectNoData() throws ObjectStreamException
>>     ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
>>     ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
>>     private static final ObjectStreamField[] serialPersistentFields
>>     private static final long serialVersionUID
>> 
>> Notes:
>>   - I have tried to update the comments for serialVersionUID as accurately as possible, but mostly based on the source code history and bugs in JBS where that field was added
>>   - Some of the readObject/writeObject methods in the javax.swing package does not have a spec, because this package and some others are excluded from the serialization specification.
>> 
>> A similar fix was implemented for java.base module as well:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html
>
> Sergey Bylokhov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.desktop/share/classes/java/awt/image/ImagingOpException.java
>    
>    Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/java/awt/image/RasterFormatException.java
>    
>    Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

Marked as reviewed by psadhukhan (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Wed Jan 13 12:49:05 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 13 Jan 2021 12:49:05 GMT
Subject: <Swing Dev> RFR: 8202880: Test
 javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java fails
Message-ID: <6jy3ChTwGm7xXWBrZYtD1_KSLgUdvAy69BrKhH_q958=.1b0b51a9-3f50-4352-85bd-c3d440dff2a4@github.com>

This test was unstable in linux in nightly testing. Modified to move the frame to center of screen so that the left-taskbar of linux doesn't interfere with the mouse movement along with delay after frame is visible to make it more stable. 
Mach5 job running for several iterations on all platforms is ok. Link in JBS.

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

Commit messages:
 - 8202880: Test javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java fails

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

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

From aivanov at openjdk.java.net  Wed Jan 13 15:48:03 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 13 Jan 2021 15:48:03 GMT
Subject: <Swing Dev> RFR: 8202880: Test
 javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java fails
In-Reply-To: <6jy3ChTwGm7xXWBrZYtD1_KSLgUdvAy69BrKhH_q958=.1b0b51a9-3f50-4352-85bd-c3d440dff2a4@github.com>
References: <6jy3ChTwGm7xXWBrZYtD1_KSLgUdvAy69BrKhH_q958=.1b0b51a9-3f50-4352-85bd-c3d440dff2a4@github.com>
Message-ID: <GaKWgdzGE8AWqFeiGNdi10n5rOl_ybwD1cgoVwnrl7M=.ce332954-7c3f-48fc-9b70-93495225cdbf@github.com>

On Wed, 13 Jan 2021 10:41:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test was unstable in linux in nightly testing. Modified to move the frame to center of screen so that the left-taskbar of linux doesn't interfere with the mouse movement along with delay after frame is visible to make it more stable. 
> Mach5 job running for several iterations on all platforms is ok. Link in JBS.

Copyright year in the test and in the ProblemList.txt, since it exists there, should be updated.

test/jdk/javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java line 55:

> 53:     private static JMenuItem paste;
> 54:     private static JMenuItem delete;
> 55:     private static JMenuItem selectAll;

These can be local variables; as well as the menuBar. They're not accessed anywhere else but createGUI().

test/jdk/javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java line 183:

> 181:         frame.pack();
> 182:         frame.setVisible(true);
> 183:         frame.setLocationRelativeTo(null);

Shall `setLocationRelativeTo` be called before `setVisible(true)`?

test/jdk/javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java line 82:

> 80:             robot.delay(1000);
> 81: 
> 82:             System.out.println("popmenu visible " + menu.isPopupMenuVisible());

`menu.isPopupMenuVisible()` should also be called on EDT.

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

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

From github.com+70650887+skodanda at openjdk.java.net  Wed Jan 13 16:30:05 2021
From: github.com+70650887+skodanda at openjdk.java.net (K Suman Rajkumaar)
Date: Wed, 13 Jan 2021 16:30:05 GMT
Subject: <Swing Dev> RFR: JDK-8258884: [TEST_BUG] Convert applet-based
 test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a
 regular java test [v6]
In-Reply-To: <P6FAvanMOev-ktJYfKrKOA-FhKSDGNTeTgHQ-JliIiY=.bc3da18f-a8f5-44d3-8f4f-446e0e4db485@github.com>
References: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
 <fulElJSGZfjmiysZ6UIpVsOeNLSPwX_ijm_-iaLP4t4=.2fd6aa24-f381-45bf-a9b0-1fbd8178fc2e@github.com>
 <k2gUqCEpqFMUMuOm_Y3c3RO6f8htpbaf0RAvI3D5hyc=.67ccbd9f-f2de-4c05-a39c-92577b8d71f5@github.com>
 <kuXE8FotlqQrmkyvMt_7X_VgY0_g635eBQNVn-c0NzU=.50199b62-6f65-4a88-9a34-a5f7de9466ab@github.com>
 <P6FAvanMOev-ktJYfKrKOA-FhKSDGNTeTgHQ-JliIiY=.bc3da18f-a8f5-44d3-8f4f-446e0e4db485@github.com>
Message-ID: <HDQ50luZS022Dobx2kJhulaW062rB8cLjy9c_SugZzM=.c10cceca-964f-4ac0-ad1e-908103d2d9a8@github.com>

On Thu, 7 Jan 2021 15:54:12 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> "Hi All, Could you please review this fix for JDK16?"
>> This is for JDK 17, not JDK 16, right ?  I can't imagine why it would be for 16 at this juncture ..
>
>> "Hi All, Could you please review this fix for JDK16?"
>> This is for JDK 17, not JDK 16, right ? I can't imagine why it would be for 16 at this juncture ..
> 
> No, it's not meant for JDK 16 ? it's for jdk-dev, the main development line which is JDK 17 at this very moment.

Dear Phil/Sergey,

I have taken care of the review comments. Please have a look.

Best Regards,
K Suman Rajkumaar

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

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

From serb at openjdk.java.net  Wed Jan 13 21:17:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 13 Jan 2021 21:17:09 GMT
Subject: <Swing Dev> RFR: JDK-8258884: [TEST_BUG] Convert applet-based
 test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a
 regular java test [v7]
In-Reply-To: <IuUpw2bK128XXWWVlWmj8ihC8FfHxNX8MCsaCUiXsx8=.f26ac7ee-e0be-4bbc-b866-0a6bd5f76110@github.com>
References: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
 <IuUpw2bK128XXWWVlWmj8ihC8FfHxNX8MCsaCUiXsx8=.f26ac7ee-e0be-4bbc-b866-0a6bd5f76110@github.com>
Message-ID: <YzDjIlXSqZYgCwdueZdAUiXjFf6eTmTuk7tZcEB7ITk=.2fe80483-d7e6-4aef-a050-74ad911b20a2@github.com>

On Thu, 7 Jan 2021 05:54:07 GMT, K Suman Rajkumaar <github.com+70650887+skodanda at openjdk.org> wrote:

>> Hi All, Could you please review this fix for JDK16?
>> 
>> Problem Description: The test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java is applet based.
>> 
>> Fix: Rewritten the above applet based test to a regular java test.
>> 
>> Best Regards,
>> K Suman Rajkumaar
>
> K Suman Rajkumaar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed "used" to "used for" as per Phil's review comment.

Marked as reviewed by serb (Reviewer).

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

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

From github.com+1247730+stanio at openjdk.java.net  Wed Jan 13 21:41:13 2021
From: github.com+1247730+stanio at openjdk.java.net (Stanimir Stamenkov)
Date: Wed, 13 Jan 2021 21:41:13 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative font
 sizes
Message-ID: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>

Fix for [JDK-8257664][] ? HTMLEditorKit: Wrong CSS relative font sizes.

_Disclaimer:_ I'm the reporter of the issue and I've been advised the best chance to get it addressed is to submit a pull request against this repository.  I haven't built the JDK myself, I'll need guidance if required.  I have a proof-of-concept example ? demonstrating the bug and a workaround available as a [public gist](https://gist.github.com/stanio/b79ce9348946aa6b3395328ec4c59d14).  I have included a sample test though I don't know if it is annotated properly.

**Current behavior**

<style>
  h2, .h2 { font-size: 150% }
</style>

<body>

  <h2>Foo</h2>            

  <div class=h2>Bar</div> 

  <ol class=h2>           
    <li>Baz</li>          
  </ol>

  <table class=h2>
    <tr>
      <td>Qux</td>        
    </tr>
  </table>

</body>

**Expected behavior**

All text should be displayed with a font size of the computed `<body>` font-size ? 1.5.

[JDK-8257664]: https://bugs.openjdk.java.net/browse/JDK-8257664

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

Commit messages:
 - 8257664: Fix font-size inheritance with percentage values

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

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

From github.com+1247730+stanio at openjdk.java.net  Wed Jan 13 21:41:13 2021
From: github.com+1247730+stanio at openjdk.java.net (Stanimir Stamenkov)
Date: Wed, 13 Jan 2021 21:41:13 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes
In-Reply-To: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
Message-ID: <9BOPWTWFGoZdPM6XZhrIsehHu7FagIIAkzpsIR6udcc=.c3a81f47-68de-4905-b7bc-ff7a829958c9@github.com>

On Sun, 13 Dec 2020 14:51:47 GMT, Stanimir Stamenkov <github.com+1247730+stanio at openjdk.org> wrote:

> Fix for [JDK-8257664][] ? HTMLEditorKit: Wrong CSS relative font sizes.
> 
> _Disclaimer:_ I'm the reporter of the issue and I've been advised the best chance to get it addressed is to submit a pull request against this repository.  I haven't built the JDK myself, I'll need guidance if required.  I have a proof-of-concept example ? demonstrating the bug and a workaround available as a [public gist](https://gist.github.com/stanio/b79ce9348946aa6b3395328ec4c59d14).  I have included a sample test though I don't know if it is annotated properly.
> 
> **Current behavior**
> 
> <style>
>   h2, .h2 { font-size: 150% }
> </style>
> 
> <body>
> 
>   <h2>Foo</h2>            
> 
>   <div class=h2>Bar</div> 
> 
>   <ol class=h2>           
>     <li>Baz</li>          
>   </ol>
> 
>   <table class=h2>
>     <tr>
>       <td>Qux</td>        
>     </tr>
>   </table>
> 
> </body>
> 
> **Expected behavior**
> 
> All text should be displayed with a font size of the computed `<body>` font-size ? 1.5.
> 
> [JDK-8257664]: https://bugs.openjdk.java.net/browse/JDK-8257664

I'll need a few days to find a printer and a scanner for submitting OCA.

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

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

From github.com+1247730+stanio at openjdk.java.net  Wed Jan 13 21:41:14 2021
From: github.com+1247730+stanio at openjdk.java.net (Stanimir Stamenkov)
Date: Wed, 13 Jan 2021 21:41:14 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes
In-Reply-To: <9BOPWTWFGoZdPM6XZhrIsehHu7FagIIAkzpsIR6udcc=.c3a81f47-68de-4905-b7bc-ff7a829958c9@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <9BOPWTWFGoZdPM6XZhrIsehHu7FagIIAkzpsIR6udcc=.c3a81f47-68de-4905-b7bc-ff7a829958c9@github.com>
Message-ID: <8I8iiGtAjkh4TPzYWZS4gzpdXaIenmX7plLzcR_0OYo=.843ede15-987e-4ea6-9c14-184f64a39cdc@github.com>

On Sun, 13 Dec 2020 14:58:07 GMT, Stanimir Stamenkov <github.com+1247730+stanio at openjdk.org> wrote:

>> Fix for [JDK-8257664][] ? HTMLEditorKit: Wrong CSS relative font sizes.
>> 
>> _Disclaimer:_ I'm the reporter of the issue and I've been advised the best chance to get it addressed is to submit a pull request against this repository.  I haven't built the JDK myself, I'll need guidance if required.  I have a proof-of-concept example ? demonstrating the bug and a workaround available as a [public gist](https://gist.github.com/stanio/b79ce9348946aa6b3395328ec4c59d14).  I have included a sample test though I don't know if it is annotated properly.
>> 
>> **Current behavior**
>> 
>> <style>
>>   h2, .h2 { font-size: 150% }
>> </style>
>> 
>> <body>
>> 
>>   <h2>Foo</h2>            
>> 
>>   <div class=h2>Bar</div> 
>> 
>>   <ol class=h2>           
>>     <li>Baz</li>          
>>   </ol>
>> 
>>   <table class=h2>
>>     <tr>
>>       <td>Qux</td>        
>>     </tr>
>>   </table>
>> 
>> </body>
>> 
>> **Expected behavior**
>> 
>> All text should be displayed with a font size of the computed `<body>` font-size ? 1.5.
>> 
>> [JDK-8257664]: https://bugs.openjdk.java.net/browse/JDK-8257664
>
> I'll need a few days to find a printer and a scanner for submitting OCA.

I'll try to get my OCA done this week.

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

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

From github.com+1247730+stanio at openjdk.java.net  Wed Jan 13 21:41:14 2021
From: github.com+1247730+stanio at openjdk.java.net (Stanimir Stamenkov)
Date: Wed, 13 Jan 2021 21:41:14 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes
In-Reply-To: <8I8iiGtAjkh4TPzYWZS4gzpdXaIenmX7plLzcR_0OYo=.843ede15-987e-4ea6-9c14-184f64a39cdc@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <9BOPWTWFGoZdPM6XZhrIsehHu7FagIIAkzpsIR6udcc=.c3a81f47-68de-4905-b7bc-ff7a829958c9@github.com>
 <8I8iiGtAjkh4TPzYWZS4gzpdXaIenmX7plLzcR_0OYo=.843ede15-987e-4ea6-9c14-184f64a39cdc@github.com>
Message-ID: <9lvhXeoEpJbEESHDc_q4NOXZ6aAzD4lgkCDT0hJ2WsQ=.4a460617-19e2-4787-80f1-697a2ad3f528@github.com>

On Mon, 11 Jan 2021 07:52:25 GMT, Stanimir Stamenkov <github.com+1247730+stanio at openjdk.org> wrote:

>> I'll need a few days to find a printer and a scanner for submitting OCA.
>
> I'll try to get my OCA done this week.

I've just emailed my scanned OCA.

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

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

From robilad at openjdk.java.net  Wed Jan 13 21:49:03 2021
From: robilad at openjdk.java.net (Dalibor Topic)
Date: Wed, 13 Jan 2021 21:49:03 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes
In-Reply-To: <9lvhXeoEpJbEESHDc_q4NOXZ6aAzD4lgkCDT0hJ2WsQ=.4a460617-19e2-4787-80f1-697a2ad3f528@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <9BOPWTWFGoZdPM6XZhrIsehHu7FagIIAkzpsIR6udcc=.c3a81f47-68de-4905-b7bc-ff7a829958c9@github.com>
 <8I8iiGtAjkh4TPzYWZS4gzpdXaIenmX7plLzcR_0OYo=.843ede15-987e-4ea6-9c14-184f64a39cdc@github.com>
 <9lvhXeoEpJbEESHDc_q4NOXZ6aAzD4lgkCDT0hJ2WsQ=.4a460617-19e2-4787-80f1-697a2ad3f528@github.com>
Message-ID: <AQomuYPvRg3gvMhs2sH4KdqDKzdAXz3Z4KJNw0uNsFE=.2039a2b2-13c8-41a0-bc95-b02fbbf2ba42@github.com>

On Wed, 13 Jan 2021 16:12:26 GMT, Stanimir Stamenkov <github.com+1247730+stanio at openjdk.org> wrote:

>> I'll try to get my OCA done this week.
>
> I've just emailed my scanned OCA.

Thank you. Your OCA has been processed and your account has been marked as verified.

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

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

From kizune at openjdk.java.net  Wed Jan 13 22:31:15 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 13 Jan 2021 22:31:15 GMT
Subject: <Swing Dev> [jdk16] RFR: 8258643: [TESTBUG]
 javax/swing/JComponent/7154030/bug7154030.java failed with "Exception:
 Failed to hide opaque button"
Message-ID: <ztDy6dZafIlrEiPUkV7Agfxc4u8FZ9ybntdpgg9NMUg=.64330edd-6db7-49a2-88ba-c1584c5b8570@github.com>

Backport from mainline.

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

Commit messages:
 - 8258643: [TESTBUG] javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button"

Changes: https://git.openjdk.java.net/jdk16/pull/119/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=119&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258643
  Stats: 12 lines in 1 file changed: 1 ins; 5 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/119.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/119/head:pull/119

PR: https://git.openjdk.java.net/jdk16/pull/119

From jwilhelm at openjdk.java.net  Thu Jan 14 01:25:23 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 14 Jan 2021 01:25:23 GMT
Subject: <Swing Dev> RFR: Merge jdk16
Message-ID: <-aqBh7X3owjZhc7NJ9IadTg_pDoBEcSVULP6D9ZQlwc=.2f9552f6-95ee-4bdd-8591-e2fea0f2ee47@github.com>

Forwardport JDK 16 -> JDK 17

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

Commit messages:
 - Merge
 - 8259719: ProblemList runtime/cds/appcds/jigsaw/modulepath/ModulePathAndCP_JFR.java on Windows
 - 8259720: ProblemList java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java on Windows
 - 8259722: ProblemList two jdk/jfr/startupargs tests on Windows
 - 8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference
 - 8259063: Possible deadlock with vtable/itable creation vs concurrent class unloading
 - 8259657: typo in generated HELP page prevents localization
 - 8258272: LoadVectorMaskedNode can't be replaced by zero con
 - 8259560: Zero m68k: "static assertion failed: align" after JDK-8252049
 - 8258985: Parallel WeakProcessor may use too few threads
 - ... and 11 more: https://git.openjdk.java.net/jdk/compare/c7e2174b...64cae854

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2072&range=00.0
 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2072&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/2072/files
  Stats: 991 lines in 48 files changed: 764 ins; 123 del; 104 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2072.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2072/head:pull/2072

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

From jwilhelm at openjdk.java.net  Thu Jan 14 01:33:06 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 14 Jan 2021 01:33:06 GMT
Subject: <Swing Dev> Integrated: Merge jdk16
In-Reply-To: <-aqBh7X3owjZhc7NJ9IadTg_pDoBEcSVULP6D9ZQlwc=.2f9552f6-95ee-4bdd-8591-e2fea0f2ee47@github.com>
References: <-aqBh7X3owjZhc7NJ9IadTg_pDoBEcSVULP6D9ZQlwc=.2f9552f6-95ee-4bdd-8591-e2fea0f2ee47@github.com>
Message-ID: <p82dsXEA151UnNYF39BzaZih5zQ83U7-B3lppnrTHfk=.6a1b52e8-1a0c-4956-819f-99c79172a356@github.com>

On Thu, 14 Jan 2021 01:20:13 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: 51e14f2e
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/51e14f2e
Stats:     991 lines in 48 files changed: 764 ins; 123 del; 104 mod

Merge

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

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

From ljiang at openjdk.java.net  Thu Jan 14 14:05:11 2021
From: ljiang at openjdk.java.net (Leo Jiang)
Date: Thu, 14 Jan 2021 14:05:11 GMT
Subject: <Swing Dev> [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file
 update - msg drop 10
Message-ID: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>

This is the changes for JDK 16 msg drop 10.

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

Commit messages:
 - JDK-8259732: JDK 16 L10n resource file update - msg drop 10

Changes: https://git.openjdk.java.net/jdk16/pull/123/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=123&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259732
  Stats: 215 lines in 30 files changed: 118 ins; 16 del; 81 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/123.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/123/head:pull/123

PR: https://git.openjdk.java.net/jdk16/pull/123

From ljiang at openjdk.java.net  Thu Jan 14 14:13:02 2021
From: ljiang at openjdk.java.net (Leo Jiang)
Date: Thu, 14 Jan 2021 14:13:02 GMT
Subject: <Swing Dev> [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file
 update - msg drop 10
In-Reply-To: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
References: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
Message-ID: <FCX2HQfImkF__vutic3srcM1McfxwuYWER_V_y2p-so=.aaace982-47ea-4f6a-b600-33049e81d7b9@github.com>

On Thu, 14 Jan 2021 14:00:00 GMT, Leo Jiang <ljiang at openjdk.org> wrote:

> This is the changes for JDK 16 msg drop 10.

[webrev.tar.gz](https://github.com/openjdk/jdk16/files/5814846/webrev.tar.gz)

Since they're Unicode escape sequences in the l10n resource files, so I attached a human readable webrev, created by `git webrev` and converted. Pls find this to help your review.

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

PR: https://git.openjdk.java.net/jdk16/pull/123

From ljiang at openjdk.java.net  Thu Jan 14 14:27:25 2021
From: ljiang at openjdk.java.net (Leo Jiang)
Date: Thu, 14 Jan 2021 14:27:25 GMT
Subject: <Swing Dev> [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file
 update - msg drop 10 [v2]
In-Reply-To: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
References: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
Message-ID: <QceWk9N7q2iV9alfICITS0Sdr8eacuR15Mrihph-doI=.1cee427c-0be1-4cb9-8a77-098696ddd5da@github.com>

> This is the changes for JDK 16 msg drop 10.

Leo Jiang 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 msgdrop
 - JDK-8259732: JDK 16 L10n resource file update - msg drop 10

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/123/files
  - new: https://git.openjdk.java.net/jdk16/pull/123/files/230117b4..d72f444a

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

  Stats: 718 lines in 32 files changed: 616 ins; 38 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/123.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/123/head:pull/123

PR: https://git.openjdk.java.net/jdk16/pull/123

From ljiang at openjdk.java.net  Thu Jan 14 15:38:09 2021
From: ljiang at openjdk.java.net (Leo Jiang)
Date: Thu, 14 Jan 2021 15:38:09 GMT
Subject: <Swing Dev> [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file
 update - msg drop 10
In-Reply-To: <FCX2HQfImkF__vutic3srcM1McfxwuYWER_V_y2p-so=.aaace982-47ea-4f6a-b600-33049e81d7b9@github.com>
References: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
 <FCX2HQfImkF__vutic3srcM1McfxwuYWER_V_y2p-so=.aaace982-47ea-4f6a-b600-33049e81d7b9@github.com>
Message-ID: <QQcGq2C1aAOYLUlOr_YOSb8PJgna7OYeWKJuT23UH3Y=.35c72bba-5d48-42c5-8be1-f67d528f3d41@github.com>

On Thu, 14 Jan 2021 14:10:12 GMT, Leo Jiang <ljiang at openjdk.org> wrote:

>> This is the changes for JDK 16 msg drop 10.
>
> [webrev.tar.gz](https://github.com/openjdk/jdk16/files/5814846/webrev.tar.gz)
> 
> Since they're Unicode escape sequences in the l10n resource files, so I attached a human readable webrev, created by `git webrev` and converted. Pls find this to help your review.

@naotoj Would you have time to take a look at this change? Very appreciated!

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

PR: https://git.openjdk.java.net/jdk16/pull/123

From naoto at openjdk.java.net  Thu Jan 14 17:22:09 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 14 Jan 2021 17:22:09 GMT
Subject: <Swing Dev> [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file
 update - msg drop 10 [v2]
In-Reply-To: <QceWk9N7q2iV9alfICITS0Sdr8eacuR15Mrihph-doI=.1cee427c-0be1-4cb9-8a77-098696ddd5da@github.com>
References: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
 <QceWk9N7q2iV9alfICITS0Sdr8eacuR15Mrihph-doI=.1cee427c-0be1-4cb9-8a77-098696ddd5da@github.com>
Message-ID: <ZkHoKP8fL7uRj0TIiwqYtVch0eyxQGv2JeY-BDgf310=.91ef28d1-d91b-4b37-aa9f-edd81b94f235@github.com>

On Thu, 14 Jan 2021 14:27:25 GMT, Leo Jiang <ljiang at openjdk.org> wrote:

>> This is the changes for JDK 16 msg drop 10.
>
> Leo Jiang 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 msgdrop
>  - JDK-8259732: JDK 16 L10n resource file update - msg drop 10

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 518:

> 516: doclet.footer_specified=\
> 517:     The -footer option is no longer supported and will be ignored.\n\
> 518:     It may be removed in a future release.

I believe this is to fix no newline at the end (unrelated to l10n changes). Do we need to change the copyright year for this?

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

PR: https://git.openjdk.java.net/jdk16/pull/123

From serb at openjdk.java.net  Fri Jan 15 00:31:01 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 15 Jan 2021 00:31:01 GMT
Subject: <Swing Dev> Integrated: 8259522: Apply java.io.Serial annotations
 in java.desktop
In-Reply-To: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>
References: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>
Message-ID: <G3x8Wr0SIEUSodquvRdnsV88amw32tPuXweX4QBcSXU=.f7d4d3fd-d9c1-4092-b223-49bc919e980d@github.com>

On Mon, 11 Jan 2021 06:21:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please review the application of @java.io.Serial annotation (JDK-8202385) to types in the desktop module to enable stricter compile-time checking of serialization-related declarations.
> 
> This annotation can be applied to these methods in the module:
> 
>     private void writeObject(java.io.ObjectOutputStream stream) throws IOException
>     private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
>     private void readObjectNoData() throws ObjectStreamException
>     ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
>     ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
>     private static final ObjectStreamField[] serialPersistentFields
>     private static final long serialVersionUID
> 
> Notes:
>   - I have tried to update the comments for serialVersionUID as accurately as possible, but mostly based on the source code history and bugs in JBS where that field was added
>   - Some of the readObject/writeObject methods in the javax.swing package does not have a spec, because this package and some others are excluded from the serialization specification.
> 
> A similar fix was implemented for java.base module as well:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html

This pull request has now been integrated.

Changeset: 978bed6c
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/978bed6c
Stats:     3424 lines in 343 files changed: 2264 ins; 287 del; 873 mod

8259522: Apply java.io.Serial annotations in java.desktop

Reviewed-by: aivanov, psadhukhan

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

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

From ljiang at openjdk.java.net  Fri Jan 15 02:02:11 2021
From: ljiang at openjdk.java.net (Leo Jiang)
Date: Fri, 15 Jan 2021 02:02:11 GMT
Subject: <Swing Dev> [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file
 update - msg drop 10 [v2]
In-Reply-To: <ZkHoKP8fL7uRj0TIiwqYtVch0eyxQGv2JeY-BDgf310=.91ef28d1-d91b-4b37-aa9f-edd81b94f235@github.com>
References: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
 <QceWk9N7q2iV9alfICITS0Sdr8eacuR15Mrihph-doI=.1cee427c-0be1-4cb9-8a77-098696ddd5da@github.com>
 <ZkHoKP8fL7uRj0TIiwqYtVch0eyxQGv2JeY-BDgf310=.91ef28d1-d91b-4b37-aa9f-edd81b94f235@github.com>
Message-ID: <1Bb8sf6zFDnQSM5kRQIlrgBNwEpO-IvxsPmN05F0QFs=.13eb3035-71d5-4310-98e5-d9989e51cf60@github.com>

On Thu, 14 Jan 2021 17:19:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Leo Jiang 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 msgdrop
>>  - JDK-8259732: JDK 16 L10n resource file update - msg drop 10
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 518:
> 
>> 516: doclet.footer_specified=\
>> 517:     The -footer option is no longer supported and will be ignored.\n\
>> 518:     It may be removed in a future release.
> 
> I believe this is to fix no newline at the end (unrelated to l10n changes). Do we need to change the copyright year for this?

Actually I was correcting the L217, changed {) -> {}. But 2 days ago, Jonathan Gibbons fixed it in another commit 6bb6093. I found his fix after running the merge. Looks both of us forgot to update the copyright year. Any suggestion? 
doclet.help.systemProperties.body=\
    The {0} page lists references to system properties.

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

PR: https://git.openjdk.java.net/jdk16/pull/123

From trebari at openjdk.java.net  Fri Jan 15 05:16:01 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Fri, 15 Jan 2021 05:16:01 GMT
Subject: <Swing Dev> [jdk16] RFR: 8258643: [TESTBUG]
 javax/swing/JComponent/7154030/bug7154030.java failed with "Exception:
 Failed to hide opaque button"
In-Reply-To: <ztDy6dZafIlrEiPUkV7Agfxc4u8FZ9ybntdpgg9NMUg=.64330edd-6db7-49a2-88ba-c1584c5b8570@github.com>
References: <ztDy6dZafIlrEiPUkV7Agfxc4u8FZ9ybntdpgg9NMUg=.64330edd-6db7-49a2-88ba-c1584c5b8570@github.com>
Message-ID: <LYkFTOQD13AXqlR5M8Sf2T2HSLjgKNOdYPFizc397Kc=.f313e75b-51bd-4950-8aad-07b72d0c26b9@github.com>

On Wed, 13 Jan 2021 22:26:47 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Backport from mainline.

Marked as reviewed by trebari (Committer).

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

PR: https://git.openjdk.java.net/jdk16/pull/119

From psadhukhan at openjdk.java.net  Fri Jan 15 05:38:05 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 15 Jan 2021 05:38:05 GMT
Subject: <Swing Dev> [jdk16] RFR: 8258643: [TESTBUG]
 javax/swing/JComponent/7154030/bug7154030.java failed with "Exception:
 Failed to hide opaque button"
In-Reply-To: <ztDy6dZafIlrEiPUkV7Agfxc4u8FZ9ybntdpgg9NMUg=.64330edd-6db7-49a2-88ba-c1584c5b8570@github.com>
References: <ztDy6dZafIlrEiPUkV7Agfxc4u8FZ9ybntdpgg9NMUg=.64330edd-6db7-49a2-88ba-c1584c5b8570@github.com>
Message-ID: <PbyNrRTwwTQ_uvq37g24uPrgznBVCwHU7P93rwtxFzM=.e8fe7061-01d0-4957-902d-d66d7a797b9b@github.com>

On Wed, 13 Jan 2021 22:26:47 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Backport from mainline.

Marked as reviewed by psadhukhan (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/119

From serb at openjdk.java.net  Fri Jan 15 06:15:04 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 15 Jan 2021 06:15:04 GMT
Subject: <Swing Dev> [jdk16] RFR: 8258643: [TESTBUG]
 javax/swing/JComponent/7154030/bug7154030.java failed with "Exception:
 Failed to hide opaque button"
In-Reply-To: <PbyNrRTwwTQ_uvq37g24uPrgznBVCwHU7P93rwtxFzM=.e8fe7061-01d0-4957-902d-d66d7a797b9b@github.com>
References: <ztDy6dZafIlrEiPUkV7Agfxc4u8FZ9ybntdpgg9NMUg=.64330edd-6db7-49a2-88ba-c1584c5b8570@github.com>
 <PbyNrRTwwTQ_uvq37g24uPrgznBVCwHU7P93rwtxFzM=.e8fe7061-01d0-4957-902d-d66d7a797b9b@github.com>
Message-ID: <9ApFtEJnjQjbHNB0t2M4z9ik_luPXD63A5xJQL9WirA=.9f591c04-a491-4202-98db-a36e9a53ab8e@github.com>

On Fri, 15 Jan 2021 05:35:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Backport from mainline.
>
> Marked as reviewed by psadhukhan (Reviewer).

Looks like this test still fails in the mainline as well: https://bugs.openjdk.java.net/browse/JDK-8259650

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

PR: https://git.openjdk.java.net/jdk16/pull/119

From kizune at openjdk.java.net  Fri Jan 15 06:22:04 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 15 Jan 2021 06:22:04 GMT
Subject: <Swing Dev> [jdk16] RFR: 8258643: [TESTBUG]
 javax/swing/JComponent/7154030/bug7154030.java failed with "Exception:
 Failed to hide opaque button"
In-Reply-To: <9ApFtEJnjQjbHNB0t2M4z9ik_luPXD63A5xJQL9WirA=.9f591c04-a491-4202-98db-a36e9a53ab8e@github.com>
References: <ztDy6dZafIlrEiPUkV7Agfxc4u8FZ9ybntdpgg9NMUg=.64330edd-6db7-49a2-88ba-c1584c5b8570@github.com>
 <PbyNrRTwwTQ_uvq37g24uPrgznBVCwHU7P93rwtxFzM=.e8fe7061-01d0-4957-902d-d66d7a797b9b@github.com>
 <9ApFtEJnjQjbHNB0t2M4z9ik_luPXD63A5xJQL9WirA=.9f591c04-a491-4202-98db-a36e9a53ab8e@github.com>
Message-ID: <RtYHgWau9C7bu3by_KMZ9Y1lBP2FCJvMBvjL3yYF6Lg=.6ad4a6f4-d955-4ac4-9ae9-d8ac35df7889@github.com>

On Fri, 15 Jan 2021 06:12:15 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Looks like this test still fails in the mainline as well: https://bugs.openjdk.java.net/browse/JDK-8259650

Yes but the reason is different. Now it seems like component's screenshot taken when component is not fully painted. Looking into it.

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

PR: https://git.openjdk.java.net/jdk16/pull/119

From psadhukhan at openjdk.java.net  Fri Jan 15 06:33:19 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 15 Jan 2021 06:33:19 GMT
Subject: <Swing Dev> RFR: 8202880: Test
 javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java fails [v2]
In-Reply-To: <6jy3ChTwGm7xXWBrZYtD1_KSLgUdvAy69BrKhH_q958=.1b0b51a9-3f50-4352-85bd-c3d440dff2a4@github.com>
References: <6jy3ChTwGm7xXWBrZYtD1_KSLgUdvAy69BrKhH_q958=.1b0b51a9-3f50-4352-85bd-c3d440dff2a4@github.com>
Message-ID: <7UBZ96Nh6YdPKEF0C06wkbrPdLLHSeKLgdEf-i4yHrc=.52da70b4-7c8e-4f6d-9fc3-1637e509e34e@github.com>

> This test was unstable in linux in nightly testing. Modified to move the frame to center of screen so that the left-taskbar of linux doesn't interfere with the mouse movement along with delay after frame is visible to make it more stable. 
> Mach5 job running for several iterations on all platforms is ok. Link in JBS.

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

  Address review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2061/files
  - new: https://git.openjdk.java.net/jdk/pull/2061/files/ca7e5589..bc7ef81f

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

  Stats: 15 lines in 2 files changed: 6 ins; 7 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2061.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2061/head:pull/2061

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

From psadhukhan at openjdk.java.net  Fri Jan 15 09:42:07 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 15 Jan 2021 09:42:07 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes
In-Reply-To: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
Message-ID: <lm2mFxyPLEfcaQlaKMDGi8-klj95JaF_Fs9prTVg-Ic=.23a230ff-7633-4e57-b7d2-447889daff25@github.com>

On Sun, 13 Dec 2020 14:51:47 GMT, Stanimir Stamenkov <github.com+1247730+stanio at openjdk.org> wrote:

> Fix for [JDK-8257664][] ? HTMLEditorKit: Wrong CSS relative font sizes.
> 
> _Disclaimer:_ I'm the reporter of the issue and I've been advised the best chance to get it addressed is to submit a pull request against this repository.  I haven't built the JDK myself, I'll need guidance if required.  I have a proof-of-concept example ? demonstrating the bug and a workaround available as a [public gist](https://gist.github.com/stanio/b79ce9348946aa6b3395328ec4c59d14).  I have included a sample test though I don't know if it is annotated properly.
> 
> **Current behavior**
> 
> <style>
>   h2, .h2 { font-size: 150% }
> </style>
> 
> <body>
> 
>   <h2>Foo</h2>            
> 
>   <div class=h2>Bar</div> 
> 
>   <ol class=h2>           
>     <li>Baz</li>          
>   </ol>
> 
>   <table class=h2>
>     <tr>
>       <td>Qux</td>        
>     </tr>
>   </table>
> 
> </body>
> 
> **Expected behavior**
> 
> All text should be displayed with a font size of the computed `<body>` font-size ? 1.5.
> 
> [JDK-8257664]: https://bugs.openjdk.java.net/browse/JDK-8257664

test/jdk/javax/swing/text/html/StyleSheet/bug8257665.java line 4:

> 2:  * <Copyright>
> 3:  */
> 4: 

You can copy the copyright from any of the test present in this directory, just change the year to 2021

test/jdk/javax/swing/text/html/StyleSheet/bug8257665.java line 14:

> 12: /*
> 13:  * @test
> 14:  * @key headless

No need to specify headless tag. If it's not @key headful, then it is implicitly headless

test/jdk/javax/swing/text/html/StyleSheet/bug8257665.java line 17:

> 15:  * @bug 8257665
> 16:  * @summary  Tests inherited font-size with parent percentage specification.
> 17:  * @run main bug8257665

We normally dont use bugid as name for the test. You probably can name it TestWrongCSSFontSize.java

src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java line 3423:

> 3421:      */
> 3422:     static final Object FONT_SIZE_INHERIT =
> 3423:             new CSS().new FontSize().parseCssValue("100%");

Do we need to instantiate new CSS object here? Can't we reuse "css" variable which is already initialized?

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

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

From github.com+70650887+skodanda at openjdk.java.net  Fri Jan 15 09:43:04 2021
From: github.com+70650887+skodanda at openjdk.java.net (K Suman Rajkumaar)
Date: Fri, 15 Jan 2021 09:43:04 GMT
Subject: <Swing Dev> Integrated: JDK-8258884: [TEST_BUG] Convert
 applet-based test
 open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a regular
 java test
In-Reply-To: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
References: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
Message-ID: <gLG6H8t-YUwrp3q0aP7jekGZ2J4pA7UL-uzP67v_eeU=.ab51b70a-9a1b-4bd1-8d4c-66c4a10a830a@github.com>

On Wed, 23 Dec 2020 11:50:41 GMT, K Suman Rajkumaar <github.com+70650887+skodanda at openjdk.org> wrote:

> Hi All, Could you please review this fix for JDK16?
> 
> Problem Description: The test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java is applet based.
> 
> Fix: Rewritten the above applet based test to a regular java test.
> 
> Best Regards,
> K Suman Rajkumaar

This pull request has now been integrated.

Changeset: b01a15e4
Author:    K Suman Rajkumaar <70650887+skodanda at users.noreply.github.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b01a15e4
Stats:     130 lines in 2 files changed: 68 ins; 44 del; 18 mod

8258884: [TEST_BUG] Convert applet-based test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a regular java test

Reviewed-by: aivanov, serb

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

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

From github.com+70650887+skodanda at openjdk.java.net  Fri Jan 15 10:38:10 2021
From: github.com+70650887+skodanda at openjdk.java.net (K Suman Rajkumaar)
Date: Fri, 15 Jan 2021 10:38:10 GMT
Subject: <Swing Dev> RFR: JDK-8259818: [TEST_BUG] Convert applet-based test
 test/jdk/javax/swing/JCheckBox/8032667/bug8032667.java to a regular java
Message-ID: <bH5GWlDU1MsCjYSn1Bf8JfQakEJY4KMyeYGyAlnlYAg=.3027998f-d5ef-4e3c-a116-3a124e66d721@github.com>

Dear All,

Hi All, Could you please review this fix for JDK17?

Problem Description: The test open/test/jdk/javax/swing/JCheckBox/8032667/bug8032667.java is applet based.

Fix: Rewritten the above applet based test as a regular java test.

Best Regards,
K Suman Rajkumaar

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

Commit messages:
 - Removed white spaces
 - Rewritten the test test/jdk/javax/swing/JCheckBox/8032667/bug8032667.java as a regular java application.

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

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

From github.com+1247730+stanio at openjdk.java.net  Fri Jan 15 12:47:28 2021
From: github.com+1247730+stanio at openjdk.java.net (Stanimir Stamenkov)
Date: Fri, 15 Jan 2021 12:47:28 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v2]
In-Reply-To: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
Message-ID: <huSSY-n_oqIlnX8JeeL5AREMhgeU9AXkA7n0eJ42CSA=.ea7e6663-d140-428c-ba00-ae7bbbd86b17@github.com>

> Fix for [JDK-8257664][] ? HTMLEditorKit: Wrong CSS relative font sizes.
> 
> _Disclaimer:_ I'm the reporter of the issue and I've been advised the best chance to get it addressed is to submit a pull request against this repository.  I haven't built the JDK myself, I'll need guidance if required.  I have a proof-of-concept example ? demonstrating the bug and a workaround available as a [public gist](https://gist.github.com/stanio/b79ce9348946aa6b3395328ec4c59d14).  I have included a sample test though I don't know if it is annotated properly.
> 
> **Current behavior**
> 
> <style>
>   h2, .h2 { font-size: 150% }
> </style>
> 
> <body>
> 
>   <h2>Foo</h2>            
> 
>   <div class=h2>Bar</div> 
> 
>   <ol class=h2>           
>     <li>Baz</li>          
>   </ol>
> 
>   <table class=h2>
>     <tr>
>       <td>Qux</td>        
>     </tr>
>   </table>
> 
> </body>
> 
> **Expected behavior**
> 
> All text should be displayed with a font size of the computed `<body>` font-size ? 1.5.
> 
> [JDK-8257664]: https://bugs.openjdk.java.net/browse/JDK-8257664

Stanimir Stamenkov has updated the pull request incrementally with one additional commit since the last revision:

  fixup! 8257664: Fix font-size inheritance with percentage values
  
  -   Renamed bug8257665.java -> TestWrongCSSFontSize.java
  -   Added full copyright statement
  -   Removed redundant @key headless
  -   Corrected bug no. 8257665 -> 8257664

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1759/files
  - new: https://git.openjdk.java.net/jdk/pull/1759/files/ea857fcf..c5b6d41c

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

  Stats: 250 lines in 2 files changed: 134 ins; 116 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1759.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1759/head:pull/1759

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

From github.com+1247730+stanio at openjdk.java.net  Fri Jan 15 12:47:29 2021
From: github.com+1247730+stanio at openjdk.java.net (Stanimir Stamenkov)
Date: Fri, 15 Jan 2021 12:47:29 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v2]
In-Reply-To: <lm2mFxyPLEfcaQlaKMDGi8-klj95JaF_Fs9prTVg-Ic=.23a230ff-7633-4e57-b7d2-447889daff25@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <lm2mFxyPLEfcaQlaKMDGi8-klj95JaF_Fs9prTVg-Ic=.23a230ff-7633-4e57-b7d2-447889daff25@github.com>
Message-ID: <lftZ3FXrR8RddidcDCiO02cb5Ybkui3mRvHj2qVWXHg=.eb7c2b7f-fd9f-40ce-8a29-a8d6e59c8ab7@github.com>

On Fri, 15 Jan 2021 09:32:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Stanimir Stamenkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixup! 8257664: Fix font-size inheritance with percentage values
>>   
>>   -   Renamed bug8257665.java -> TestWrongCSSFontSize.java
>>   -   Added full copyright statement
>>   -   Removed redundant @key headless
>>   -   Corrected bug no. 8257665 -> 8257664
>
> test/jdk/javax/swing/text/html/StyleSheet/bug8257665.java line 17:
> 
>> 15:  * @bug 8257665
>> 16:  * @summary  Tests inherited font-size with parent percentage specification.
>> 17:  * @run main bug8257665
> 
> We normally dont use bugid as name for the test. You probably can name it TestWrongCSSFontSize.java

Renamed.  I had mimicked the existing `bug4936917.java`, initially.  I also had the `@bug` number wrong.

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

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

From github.com+1247730+stanio at openjdk.java.net  Fri Jan 15 12:56:05 2021
From: github.com+1247730+stanio at openjdk.java.net (Stanimir Stamenkov)
Date: Fri, 15 Jan 2021 12:56:05 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v2]
In-Reply-To: <lm2mFxyPLEfcaQlaKMDGi8-klj95JaF_Fs9prTVg-Ic=.23a230ff-7633-4e57-b7d2-447889daff25@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <lm2mFxyPLEfcaQlaKMDGi8-klj95JaF_Fs9prTVg-Ic=.23a230ff-7633-4e57-b7d2-447889daff25@github.com>
Message-ID: <rBAeCHKLaFHFLtGpWNN__axnH-lmvn1beBkgE5QhWik=.a7290a81-9e58-453f-b453-290453890d1b@github.com>

On Fri, 15 Jan 2021 09:38:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Stanimir Stamenkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixup! 8257664: Fix font-size inheritance with percentage values
>>   
>>   -   Renamed bug8257665.java -> TestWrongCSSFontSize.java
>>   -   Added full copyright statement
>>   -   Removed redundant @key headless
>>   -   Corrected bug no. 8257665 -> 8257664
>
> src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java line 3423:
> 
>> 3421:      */
>> 3422:     static final Object FONT_SIZE_INHERIT =
>> 3423:             new CSS().new FontSize().parseCssValue("100%");
> 
> Do we need to instantiate new CSS object here? Can't we reuse "css" variable which is already initialized?

I hadn't previously realized the `ViewAttributeSet` class is not static, so it should be possible to reuse the instance `css`.  Not sure if a separate instance per style sheet is necessary, but I'll prepare a revision.

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

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

From aivanov at openjdk.java.net  Fri Jan 15 13:24:04 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 15 Jan 2021 13:24:04 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes
In-Reply-To: <AQomuYPvRg3gvMhs2sH4KdqDKzdAXz3Z4KJNw0uNsFE=.2039a2b2-13c8-41a0-bc95-b02fbbf2ba42@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <9BOPWTWFGoZdPM6XZhrIsehHu7FagIIAkzpsIR6udcc=.c3a81f47-68de-4905-b7bc-ff7a829958c9@github.com>
 <8I8iiGtAjkh4TPzYWZS4gzpdXaIenmX7plLzcR_0OYo=.843ede15-987e-4ea6-9c14-184f64a39cdc@github.com>
 <9lvhXeoEpJbEESHDc_q4NOXZ6aAzD4lgkCDT0hJ2WsQ=.4a460617-19e2-4787-80f1-697a2ad3f528@github.com>
 <AQomuYPvRg3gvMhs2sH4KdqDKzdAXz3Z4KJNw0uNsFE=.2039a2b2-13c8-41a0-bc95-b02fbbf2ba42@github.com>
Message-ID: <6gfK8xPDLEjtARTMW97tt3ud4gGuh8F9Kx8IOiFoIJk=.f17715d2-f11f-49f8-b2ab-e43bc4a4a445@github.com>

On Wed, 13 Jan 2021 21:46:45 GMT, Dalibor Topic <robilad at openjdk.org> wrote:

>> I've just emailed my scanned OCA.
>
> Thank you. Your OCA has been processed and your account has been marked as verified.

Providing a way to display the rendered HTML, especially when the test fails, for visual inspection could be a bonus. This feature could be activated with a parameter passed to the test. It's not a requirement, just a suggestion.

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

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

From aivanov at openjdk.java.net  Fri Jan 15 13:24:07 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 15 Jan 2021 13:24:07 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v2]
In-Reply-To: <lm2mFxyPLEfcaQlaKMDGi8-klj95JaF_Fs9prTVg-Ic=.23a230ff-7633-4e57-b7d2-447889daff25@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <lm2mFxyPLEfcaQlaKMDGi8-klj95JaF_Fs9prTVg-Ic=.23a230ff-7633-4e57-b7d2-447889daff25@github.com>
Message-ID: <COsFXN8tJ66XFGB3koIrmCRfFI5MIJgvMiDMAvben3w=.203166d5-b250-4a70-9274-39e695d5f4b2@github.com>

On Fri, 15 Jan 2021 09:31:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Stanimir Stamenkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixup! 8257664: Fix font-size inheritance with percentage values
>>   
>>   -   Renamed bug8257665.java -> TestWrongCSSFontSize.java
>>   -   Added full copyright statement
>>   -   Removed redundant @key headless
>>   -   Corrected bug no. 8257665 -> 8257664
>
> test/jdk/javax/swing/text/html/StyleSheet/bug8257665.java line 14:
> 
>> 12: /*
>> 13:  * @test
>> 14:  * @key headless
> 
> No need to specify headless tag. If it's not @key headful, then it is implicitly headless

I believe the test is _headful_ because it uses `SwingUtilities.invokeAndWait` even though it does not show any UI.

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

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

From github.com+1247730+stanio at openjdk.java.net  Fri Jan 15 15:35:04 2021
From: github.com+1247730+stanio at openjdk.java.net (Stanimir Stamenkov)
Date: Fri, 15 Jan 2021 15:35:04 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v2]
In-Reply-To: <COsFXN8tJ66XFGB3koIrmCRfFI5MIJgvMiDMAvben3w=.203166d5-b250-4a70-9274-39e695d5f4b2@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <lm2mFxyPLEfcaQlaKMDGi8-klj95JaF_Fs9prTVg-Ic=.23a230ff-7633-4e57-b7d2-447889daff25@github.com>
 <COsFXN8tJ66XFGB3koIrmCRfFI5MIJgvMiDMAvben3w=.203166d5-b250-4a70-9274-39e695d5f4b2@github.com>
Message-ID: <4kOQwc_o73RnC2NkOs5V_74VJf_NaQG_gCGutpR0pZ4=.8307e31e-9ca8-4427-a859-9dc3b0063b0e@github.com>

On Fri, 15 Jan 2021 13:18:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/text/html/StyleSheet/bug8257665.java line 14:
>> 
>>> 12: /*
>>> 13:  * @test
>>> 14:  * @key headless
>> 
>> No need to specify headless tag. If it's not @key headful, then it is implicitly headless
>
> I believe the test is _headful_ because it uses `SwingUtilities.invokeAndWait` even though it does not show any UI.

I've used `SwingUtilities.invokeAndWait` just to be on the safe side that "everything Swing should be executed on the EDT" but I guess I could drop it as no UI ever shown?

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

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

From psadhukhan at openjdk.java.net  Fri Jan 15 15:49:01 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 15 Jan 2021 15:49:01 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v2]
In-Reply-To: <4kOQwc_o73RnC2NkOs5V_74VJf_NaQG_gCGutpR0pZ4=.8307e31e-9ca8-4427-a859-9dc3b0063b0e@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <lm2mFxyPLEfcaQlaKMDGi8-klj95JaF_Fs9prTVg-Ic=.23a230ff-7633-4e57-b7d2-447889daff25@github.com>
 <COsFXN8tJ66XFGB3koIrmCRfFI5MIJgvMiDMAvben3w=.203166d5-b250-4a70-9274-39e695d5f4b2@github.com>
 <4kOQwc_o73RnC2NkOs5V_74VJf_NaQG_gCGutpR0pZ4=.8307e31e-9ca8-4427-a859-9dc3b0063b0e@github.com>
Message-ID: <u5WoxxnqeQBVnmQDPMk8Zlk3XphS5k6-4NWefBI0xCM=.6a4a5a71-4805-4dd6-9c3d-33610580bea4@github.com>

On Fri, 15 Jan 2021 15:31:54 GMT, Stanimir Stamenkov <github.com+1247730+stanio at openjdk.org> wrote:

>> I believe the test is _headful_ because it uses `SwingUtilities.invokeAndWait` even though it does not show any UI.
>
> I've used `SwingUtilities.invokeAndWait` just to be on the safe side that "everything Swing should be executed on the EDT" but I guess I could drop it as no UI ever shown?

I am not sure that if we use invokeAndWait(), it needs to be headful..There are many test where we use invokeAndWait but they are headless. But it will be good to see what the test is doing visually so you probably can make it headful.

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

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

From psadhukhan at openjdk.java.net  Fri Jan 15 15:49:06 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 15 Jan 2021 15:49:06 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v2]
In-Reply-To: <huSSY-n_oqIlnX8JeeL5AREMhgeU9AXkA7n0eJ42CSA=.ea7e6663-d140-428c-ba00-ae7bbbd86b17@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <huSSY-n_oqIlnX8JeeL5AREMhgeU9AXkA7n0eJ42CSA=.ea7e6663-d140-428c-ba00-ae7bbbd86b17@github.com>
Message-ID: <V1njNgvVTkXTFKhU2chy-JihjFSPc8OwQ7G_7CtiVZY=.b2b979ed-f501-4500-a924-23e08f8e0e93@github.com>

On Fri, 15 Jan 2021 12:47:28 GMT, Stanimir Stamenkov <github.com+1247730+stanio at openjdk.org> wrote:

>> Fix for [JDK-8257664][] ? HTMLEditorKit: Wrong CSS relative font sizes.
>> 
>> _Disclaimer:_ I'm the reporter of the issue and I've been advised the best chance to get it addressed is to submit a pull request against this repository.  I haven't built the JDK myself, I'll need guidance if required.  I have a proof-of-concept example ? demonstrating the bug and a workaround available as a [public gist](https://gist.github.com/stanio/b79ce9348946aa6b3395328ec4c59d14).  I have included a sample test though I don't know if it is annotated properly.
>> 
>> **Current behavior**
>> 
>> <style>
>>   h2, .h2 { font-size: 150% }
>> </style>
>> 
>> <body>
>> 
>>   <h2>Foo</h2>            
>> 
>>   <div class=h2>Bar</div> 
>> 
>>   <ol class=h2>           
>>     <li>Baz</li>          
>>   </ol>
>> 
>>   <table class=h2>
>>     <tr>
>>       <td>Qux</td>        
>>     </tr>
>>   </table>
>> 
>> </body>
>> 
>> **Expected behavior**
>> 
>> All text should be displayed with a font size of the computed `<body>` font-size ? 1.5.
>> 
>> [JDK-8257664]: https://bugs.openjdk.java.net/browse/JDK-8257664
>
> Stanimir Stamenkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixup! 8257664: Fix font-size inheritance with percentage values
>   
>   -   Renamed bug8257665.java -> TestWrongCSSFontSize.java
>   -   Added full copyright statement
>   -   Removed redundant @key headless
>   -   Corrected bug no. 8257665 -> 8257664

test/jdk/javax/swing/text/html/StyleSheet/TestWrongCSSFontSize.java line 119:

> 117: 
> 118:     public static void main(String[] args) throws Throwable {
> 119:         bug8257665 test = new bug8257665();

I guess this needs to be changed now that the testname is modified.

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

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

From psadhukhan at openjdk.java.net  Fri Jan 15 15:50:05 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 15 Jan 2021 15:50:05 GMT
Subject: <Swing Dev> RFR: 8202880: Test
 javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java fails [v2]
In-Reply-To: <GaKWgdzGE8AWqFeiGNdi10n5rOl_ybwD1cgoVwnrl7M=.ce332954-7c3f-48fc-9b70-93495225cdbf@github.com>
References: <6jy3ChTwGm7xXWBrZYtD1_KSLgUdvAy69BrKhH_q958=.1b0b51a9-3f50-4352-85bd-c3d440dff2a4@github.com>
 <GaKWgdzGE8AWqFeiGNdi10n5rOl_ybwD1cgoVwnrl7M=.ce332954-7c3f-48fc-9b70-93495225cdbf@github.com>
Message-ID: <fzC7N7G9_sg1PQ7UvB67XGwu2tkc1Q22dc-_C0IkKNo=.2256a9b7-65f7-4299-9ed5-f5249beadc90@github.com>

On Wed, 13 Jan 2021 15:45:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> Copyright year in the test and in the ProblemList.txt, since it exists there, should be updated.

@aivanov-jdk any more comment on this?

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

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

From aivanov at openjdk.java.net  Fri Jan 15 16:37:15 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 15 Jan 2021 16:37:15 GMT
Subject: <Swing Dev> RFR: 8202880: Test
 javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java fails [v2]
In-Reply-To: <7UBZ96Nh6YdPKEF0C06wkbrPdLLHSeKLgdEf-i4yHrc=.52da70b4-7c8e-4f6d-9fc3-1637e509e34e@github.com>
References: <6jy3ChTwGm7xXWBrZYtD1_KSLgUdvAy69BrKhH_q958=.1b0b51a9-3f50-4352-85bd-c3d440dff2a4@github.com>
 <7UBZ96Nh6YdPKEF0C06wkbrPdLLHSeKLgdEf-i4yHrc=.52da70b4-7c8e-4f6d-9fc3-1637e509e34e@github.com>
Message-ID: <wQmQQryDJKxCuRV9-SHAe_V_3bVhekkKmRnVMRAHAZM=.8586e85c-0c2c-4d2d-92d1-c8f939b59aa1@github.com>

On Fri, 15 Jan 2021 06:33:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> This test was unstable in linux in nightly testing. Modified to move the frame to center of screen so that the left-taskbar of linux doesn't interfere with the mouse movement along with delay after frame is visible to make it more stable. 
>> Mach5 job running for several iterations on all platforms is ok. Link in JBS.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java line 93:

> 91:         JMenuItem delete;
> 92:         JMenuItem selectAll;
> 93:         JMenuBar menuBar;

Why at the top of the method instead of the first usage?
What about `undo`, `redo`, `cut`, `copy`? I cannot see they're used anywhere else but this method too.

test/jdk/javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java line 80:

> 78:             robot.mouseWheel(1);
> 79:             robot.waitForIdle();
> 80:             if (!menu.isPopupMenuVisible()) {

This still calls `menu.isPopupMenuVisible()` on main thread, doesn't it?

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

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

From psadhukhan at openjdk.java.net  Fri Jan 15 17:06:22 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 15 Jan 2021 17:06:22 GMT
Subject: <Swing Dev> RFR: 8202880: Test
 javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java fails [v3]
In-Reply-To: <6jy3ChTwGm7xXWBrZYtD1_KSLgUdvAy69BrKhH_q958=.1b0b51a9-3f50-4352-85bd-c3d440dff2a4@github.com>
References: <6jy3ChTwGm7xXWBrZYtD1_KSLgUdvAy69BrKhH_q958=.1b0b51a9-3f50-4352-85bd-c3d440dff2a4@github.com>
Message-ID: <o53bH4vVzDEKinKDOlhw9lTp4tk6Rykie8PAVbLBgww=.6edfe17b-fc37-4d10-99a4-a6778296b171@github.com>

> This test was unstable in linux in nightly testing. Modified to move the frame to center of screen so that the left-taskbar of linux doesn't interfere with the mouse movement along with delay after frame is visible to make it more stable. 
> Mach5 job running for several iterations on all platforms is ok. Link in JBS.

Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision:

 - Review fix
 - Revert "Address review comments"
   
   This reverts commit cb12e5bf447b0922fe601c11bbceb2200904b1c3.
 - Address review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2061/files
  - new: https://git.openjdk.java.net/jdk/pull/2061/files/bc7ef81f..9f3bbbf6

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

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

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

From github.com+1247730+stanio at openjdk.java.net  Fri Jan 15 17:54:26 2021
From: github.com+1247730+stanio at openjdk.java.net (Stanimir Stamenkov)
Date: Fri, 15 Jan 2021 17:54:26 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v3]
In-Reply-To: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
Message-ID: <xRKk1DkOcCikhhegqi9taN2AhYnQWtiGFRJn73QV1wg=.aef0a68f-3453-4261-89b7-b5830a63d807@github.com>

> Fix for [JDK-8257664][] ? HTMLEditorKit: Wrong CSS relative font sizes.
> 
> _Disclaimer:_ I'm the reporter of the issue and I've been advised the best chance to get it addressed is to submit a pull request against this repository.  I haven't built the JDK myself, I'll need guidance if required.  I have a proof-of-concept example ? demonstrating the bug and a workaround available as a [public gist](https://gist.github.com/stanio/b79ce9348946aa6b3395328ec4c59d14).  I have included a sample test though I don't know if it is annotated properly.
> 
> **Current behavior**
> 
> <style>
>   h2, .h2 { font-size: 150% }
> </style>
> 
> <body>
> 
>   <h2>Foo</h2>            
> 
>   <div class=h2>Bar</div> 
> 
>   <ol class=h2>           
>     <li>Baz</li>          
>   </ol>
> 
>   <table class=h2>
>     <tr>
>       <td>Qux</td>        
>     </tr>
>   </table>
> 
> </body>
> 
> **Expected behavior**
> 
> All text should be displayed with a font size of the computed `<body>` font-size ? 1.5.
> 
> [JDK-8257664]: https://bugs.openjdk.java.net/browse/JDK-8257664

Stanimir Stamenkov has updated the pull request incrementally with one additional commit since the last revision:

  fixup! 8257664: Fix font-size inheritance with percentage values
  
  -   Correct test type/ctor name in main()
  -   Add program option to save image capture of the editor

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1759/files
  - new: https://git.openjdk.java.net/jdk/pull/1759/files/c5b6d41c..117e01ff

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

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

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

From github.com+1247730+stanio at openjdk.java.net  Fri Jan 15 17:58:03 2021
From: github.com+1247730+stanio at openjdk.java.net (Stanimir Stamenkov)
Date: Fri, 15 Jan 2021 17:58:03 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes
In-Reply-To: <6gfK8xPDLEjtARTMW97tt3ud4gGuh8F9Kx8IOiFoIJk=.f17715d2-f11f-49f8-b2ab-e43bc4a4a445@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <9BOPWTWFGoZdPM6XZhrIsehHu7FagIIAkzpsIR6udcc=.c3a81f47-68de-4905-b7bc-ff7a829958c9@github.com>
 <8I8iiGtAjkh4TPzYWZS4gzpdXaIenmX7plLzcR_0OYo=.843ede15-987e-4ea6-9c14-184f64a39cdc@github.com>
 <9lvhXeoEpJbEESHDc_q4NOXZ6aAzD4lgkCDT0hJ2WsQ=.4a460617-19e2-4787-80f1-697a2ad3f528@github.com>
 <AQomuYPvRg3gvMhs2sH4KdqDKzdAXz3Z4KJNw0uNsFE=.2039a2b2-13c8-41a0-bc95-b02fbbf2ba42@github.com>
 <6gfK8xPDLEjtARTMW97tt3ud4gGuh8F9Kx8IOiFoIJk=.f17715d2-f11f-49f8-b2ab-e43bc4a4a445@github.com>
Message-ID: <nbB3Zbdgcl6fdXRBTLe61k2ZWwhvKhFjfCfw5EqOy84=.7bae678c-cbd2-4b57-8d32-27941ea9e7dd@github.com>

On Fri, 15 Jan 2021 13:21:29 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Thank you. Your OCA has been processed and your account has been marked as verified.
>
> Providing a way to display the rendered HTML, especially when the test fails, for visual inspection could be a bonus. This feature could be activated with a parameter passed to the test. It's not a requirement, just a suggestion.

Added an option to save editor image capture to a file.  Here's the current (wrong) output:

![wrongCssFontSize](https://user-images.githubusercontent.com/1247730/104761222-3f4c1500-576b-11eb-8ff4-cc67e5d341e2.png)

All text should use the same font size ? here's a side-by-side (wrong-right) comparison using the workaround I've referenced in the PR description:

![wrong-right](https://user-images.githubusercontent.com/1247730/104761383-7f12fc80-576b-11eb-95ba-68a0edf8e60a.png)

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

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

From github.com+1247730+stanio at openjdk.java.net  Fri Jan 15 18:07:25 2021
From: github.com+1247730+stanio at openjdk.java.net (Stanimir Stamenkov)
Date: Fri, 15 Jan 2021 18:07:25 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v4]
In-Reply-To: <u5WoxxnqeQBVnmQDPMk8Zlk3XphS5k6-4NWefBI0xCM=.6a4a5a71-4805-4dd6-9c3d-33610580bea4@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <lm2mFxyPLEfcaQlaKMDGi8-klj95JaF_Fs9prTVg-Ic=.23a230ff-7633-4e57-b7d2-447889daff25@github.com>
 <COsFXN8tJ66XFGB3koIrmCRfFI5MIJgvMiDMAvben3w=.203166d5-b250-4a70-9274-39e695d5f4b2@github.com>
 <4kOQwc_o73RnC2NkOs5V_74VJf_NaQG_gCGutpR0pZ4=.8307e31e-9ca8-4427-a859-9dc3b0063b0e@github.com>
 <u5WoxxnqeQBVnmQDPMk8Zlk3XphS5k6-4NWefBI0xCM=.6a4a5a71-4805-4dd6-9c3d-33610580bea4@github.com>
Message-ID: <vCH6dKJIsrtNHKZ4-bAMGJRm6FkxKOLTp6EgVFBLvTg=.5e2e21e0-d09c-451d-be16-b6253d405ae5@github.com>

On Fri, 15 Jan 2021 15:46:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> I've used `SwingUtilities.invokeAndWait` just to be on the safe side that "everything Swing should be executed on the EDT" but I guess I could drop it as no UI ever shown?
>
> I am not sure that if we use invokeAndWait(), it needs to be headful..There are many test where we use invokeAndWait but they are headless. But it will be good to see what the test is doing visually so you probably can make it headful.

Please, see if the option I've added to save an image capture of the editor component appears sufficient for the visual inspection.

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

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

From github.com+1247730+stanio at openjdk.java.net  Fri Jan 15 18:11:05 2021
From: github.com+1247730+stanio at openjdk.java.net (Stanimir Stamenkov)
Date: Fri, 15 Jan 2021 18:11:05 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v4]
In-Reply-To: <rBAeCHKLaFHFLtGpWNN__axnH-lmvn1beBkgE5QhWik=.a7290a81-9e58-453f-b453-290453890d1b@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <lm2mFxyPLEfcaQlaKMDGi8-klj95JaF_Fs9prTVg-Ic=.23a230ff-7633-4e57-b7d2-447889daff25@github.com>
 <rBAeCHKLaFHFLtGpWNN__axnH-lmvn1beBkgE5QhWik=.a7290a81-9e58-453f-b453-290453890d1b@github.com>
Message-ID: <I51ucBzIDij05ITLgFzWUtyFoYv-TBhduFLX5A4bQ9o=.c2ad3148-5afe-4591-8649-68295474382f@github.com>

On Fri, 15 Jan 2021 12:53:43 GMT, Stanimir Stamenkov <github.com+1247730+stanio at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java line 3423:
>> 
>>> 3421:      */
>>> 3422:     static final Object FONT_SIZE_INHERIT =
>>> 3423:             new CSS().new FontSize().parseCssValue("100%");
>> 
>> Do we need to instantiate new CSS object here? Can't we reuse "css" variable which is already initialized?
>
> I hadn't previously realized the `ViewAttributeSet` class is not static, so it should be possible to reuse the instance `css`.  Not sure if a separate instance per style sheet is necessary, but I'll prepare a revision.

I have now made it use the instance `StyleSheet.css` variable.

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

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

From github.com+1247730+stanio at openjdk.java.net  Fri Jan 15 18:07:25 2021
From: github.com+1247730+stanio at openjdk.java.net (Stanimir Stamenkov)
Date: Fri, 15 Jan 2021 18:07:25 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v4]
In-Reply-To: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
Message-ID: <slAYSpjokcv-f9rL2w1NW3K0-ZWuDONqlMP5bLEF9Uk=.7a07b294-ae1b-49d0-9606-eb75db6695ea@github.com>

> Fix for [JDK-8257664][] ? HTMLEditorKit: Wrong CSS relative font sizes.
> 
> _Disclaimer:_ I'm the reporter of the issue and I've been advised the best chance to get it addressed is to submit a pull request against this repository.  I haven't built the JDK myself, I'll need guidance if required.  I have a proof-of-concept example ? demonstrating the bug and a workaround available as a [public gist](https://gist.github.com/stanio/b79ce9348946aa6b3395328ec4c59d14).  I have included a sample test though I don't know if it is annotated properly.
> 
> **Current behavior**
> 
> <style>
>   h2, .h2 { font-size: 150% }
> </style>
> 
> <body>
> 
>   <h2>Foo</h2>            
> 
>   <div class=h2>Bar</div> 
> 
>   <ol class=h2>           
>     <li>Baz</li>          
>   </ol>
> 
>   <table class=h2>
>     <tr>
>       <td>Qux</td>        
>     </tr>
>   </table>
> 
> </body>
> 
> **Expected behavior**
> 
> All text should be displayed with a font size of the computed `<body>` font-size ? 1.5.
> 
> [JDK-8257664]: https://bugs.openjdk.java.net/browse/JDK-8257664

Stanimir Stamenkov has updated the pull request incrementally with one additional commit since the last revision:

  fixup! 8257664: Fix font-size inheritance with percentage values
  
  Init the "fontSizeInherit" value using the instance "StyleSheet.css".

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1759/files
  - new: https://git.openjdk.java.net/jdk/pull/1759/files/117e01ff..497b9556

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

  Stats: 25 lines in 1 file changed: 15 ins; 9 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1759.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1759/head:pull/1759

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

From aivanov at openjdk.java.net  Fri Jan 15 20:09:06 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 15 Jan 2021 20:09:06 GMT
Subject: <Swing Dev> RFR: 8202880: Test
 javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java fails [v3]
In-Reply-To: <o53bH4vVzDEKinKDOlhw9lTp4tk6Rykie8PAVbLBgww=.6edfe17b-fc37-4d10-99a4-a6778296b171@github.com>
References: <6jy3ChTwGm7xXWBrZYtD1_KSLgUdvAy69BrKhH_q958=.1b0b51a9-3f50-4352-85bd-c3d440dff2a4@github.com>
 <o53bH4vVzDEKinKDOlhw9lTp4tk6Rykie8PAVbLBgww=.6edfe17b-fc37-4d10-99a4-a6778296b171@github.com>
Message-ID: <2DEBY1PTfoWULLp7Kua2C889eG7-IhRFg1Pob9fFBl0=.b12510ca-928d-4e93-b9ee-c8df26535560@github.com>

On Fri, 15 Jan 2021 17:06:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> This test was unstable in linux in nightly testing. Modified to move the frame to center of screen so that the left-taskbar of linux doesn't interfere with the mouse movement along with delay after frame is visible to make it more stable. 
>> Mach5 job running for several iterations on all platforms is ok. Link in JBS.
>
> Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Review fix
>  - Revert "Address review comments"
>    
>    This reverts commit cb12e5bf447b0922fe601c11bbceb2200904b1c3.
>  - Address review comments

Marked as reviewed by aivanov (Reviewer).

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

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

From aivanov at openjdk.java.net  Sat Jan 16 00:21:07 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Sat, 16 Jan 2021 00:21:07 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v4]
In-Reply-To: <slAYSpjokcv-f9rL2w1NW3K0-ZWuDONqlMP5bLEF9Uk=.7a07b294-ae1b-49d0-9606-eb75db6695ea@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <slAYSpjokcv-f9rL2w1NW3K0-ZWuDONqlMP5bLEF9Uk=.7a07b294-ae1b-49d0-9606-eb75db6695ea@github.com>
Message-ID: <JqJsD2bfVVefhRtm9w2sykeQX9iMXLBiilcLkAk_tgE=.4f71b045-1cd7-4ed6-b804-3c4e0c722b35@github.com>

On Fri, 15 Jan 2021 18:07:25 GMT, Stanimir Stamenkov <github.com+1247730+stanio at openjdk.org> wrote:

>> Fix for [JDK-8257664][] ? HTMLEditorKit: Wrong CSS relative font sizes.
>> 
>> _Disclaimer:_ I'm the reporter of the issue and I've been advised the best chance to get it addressed is to submit a pull request against this repository.  I haven't built the JDK myself, I'll need guidance if required.  I have a proof-of-concept example ? demonstrating the bug and a workaround available as a [public gist](https://gist.github.com/stanio/b79ce9348946aa6b3395328ec4c59d14).  I have included a sample test though I don't know if it is annotated properly.
>> 
>> **Current behavior**
>> 
>> <style>
>>   h2, .h2 { font-size: 150% }
>> </style>
>> 
>> <body>
>> 
>>   <h2>Foo</h2>            
>> 
>>   <div class=h2>Bar</div> 
>> 
>>   <ol class=h2>           
>>     <li>Baz</li>          
>>   </ol>
>> 
>>   <table class=h2>
>>     <tr>
>>       <td>Qux</td>        
>>     </tr>
>>   </table>
>> 
>> </body>
>> 
>> **Expected behavior**
>> 
>> All text should be displayed with a font size of the computed `<body>` font-size ? 1.5.
>> 
>> [JDK-8257664]: https://bugs.openjdk.java.net/browse/JDK-8257664
>
> Stanimir Stamenkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixup! 8257664: Fix font-size inheritance with percentage values
>   
>   Init the "fontSizeInherit" value using the instance "StyleSheet.css".

Looks good to me.

The test runs successfully on headless hosts in mach5.
As for the visual inspection, I thought about creating a frame with JEditorPane but saving an image is will also work on headless systems. That is to say, saving the image is even better.

src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java line 1737:

> 1735:      *          property values, Cascading, and Inheritance</a>
> 1736:      */
> 1737:     Object fontSizeInherit() {

The method can be private, right?

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

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

From serb at openjdk.java.net  Sat Jan 16 00:45:03 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 16 Jan 2021 00:45:03 GMT
Subject: <Swing Dev> RFR: JDK-8259818: [TEST_BUG] Convert applet-based
 test test/jdk/javax/swing/JCheckBox/8032667/bug8032667.java to a regular
 java
In-Reply-To: <bH5GWlDU1MsCjYSn1Bf8JfQakEJY4KMyeYGyAlnlYAg=.3027998f-d5ef-4e3c-a116-3a124e66d721@github.com>
References: <bH5GWlDU1MsCjYSn1Bf8JfQakEJY4KMyeYGyAlnlYAg=.3027998f-d5ef-4e3c-a116-3a124e66d721@github.com>
Message-ID: <i6kNaINfZsYGdFKJBp0GLB7szgTJLNfVRTC0p0AxJis=.fd07bca7-e529-4591-9c91-432950b31911@github.com>

On Fri, 15 Jan 2021 07:59:24 GMT, K Suman Rajkumaar <github.com+70650887+skodanda at openjdk.org> wrote:

> Dear All,
> 
> Hi All, Could you please review this fix for JDK17?
> 
> Problem Description: The test open/test/jdk/javax/swing/JCheckBox/8032667/bug8032667.java is applet based.
> 
> Fix: Rewritten the above applet based test as a regular java test.
> 
> Best Regards,
> K Suman Rajkumaar

test/jdk/javax/swing/JCheckBox/8032667/bug8032667.java line 50:

> 48:  * @bug 8032667
> 49:  * @summary [macosx] Components cannot be rendered in HiDPI to BufferedImage
> 50:  * @run main bug8032667

I suggest do not convert manual tests from the applet to the regular tests, until we will not find a way to unify them, in a similar way as it was for "applet/manual=yesno". Otherwise, all our manual tests will look differently, since different people will make the UI differently.

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

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

From naoto at openjdk.java.net  Sat Jan 16 00:51:09 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Sat, 16 Jan 2021 00:51:09 GMT
Subject: <Swing Dev> [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file
 update - msg drop 10 [v2]
In-Reply-To: <1Bb8sf6zFDnQSM5kRQIlrgBNwEpO-IvxsPmN05F0QFs=.13eb3035-71d5-4310-98e5-d9989e51cf60@github.com>
References: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
 <QceWk9N7q2iV9alfICITS0Sdr8eacuR15Mrihph-doI=.1cee427c-0be1-4cb9-8a77-098696ddd5da@github.com>
 <ZkHoKP8fL7uRj0TIiwqYtVch0eyxQGv2JeY-BDgf310=.91ef28d1-d91b-4b37-aa9f-edd81b94f235@github.com>
 <1Bb8sf6zFDnQSM5kRQIlrgBNwEpO-IvxsPmN05F0QFs=.13eb3035-71d5-4310-98e5-d9989e51cf60@github.com>
Message-ID: <F3h1x-ZgNClOKHsAunvSztkl9XxmH7cP9YPZoz_O08I=.2d76925f-b12f-49c0-9631-94e663df59e3@github.com>

On Fri, 15 Jan 2021 01:59:07 GMT, Leo Jiang <ljiang at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 518:
>> 
>>> 516: doclet.footer_specified=\
>>> 517:     The -footer option is no longer supported and will be ignored.\n\
>>> 518:     It may be removed in a future release.
>> 
>> I believe this is to fix no newline at the end (unrelated to l10n changes). Do we need to change the copyright year for this?
>
> Actually I was correcting the L217, changed {) -> {}. But 2 days ago, Jonathan Gibbons fixed it in another commit 6bb6093. I found his fix after running the merge. Looks both of us forgot to update the copyright year. Any suggestion? 
> doclet.help.systemProperties.body=\
>     The {0} page lists references to system properties.

I believe your PR still contains the fix to add the newline at the end of the file (at L518). So I think you can simply change the copyright year in `standard.properties` file.

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

PR: https://git.openjdk.java.net/jdk16/pull/123

From github.com+1247730+stanio at openjdk.java.net  Sat Jan 16 06:45:35 2021
From: github.com+1247730+stanio at openjdk.java.net (Stanimir Stamenkov)
Date: Sat, 16 Jan 2021 06:45:35 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v5]
In-Reply-To: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
Message-ID: <KG8PuSyeWLNrr-SURStOiAakLjBsGDmzSoeMXnBT5ks=.20e1acaa-2b4c-4d41-854c-df477a4b72ca@github.com>

> Fix for [JDK-8257664][] ? HTMLEditorKit: Wrong CSS relative font sizes.
> 
> _Disclaimer:_ I'm the reporter of the issue and I've been advised the best chance to get it addressed is to submit a pull request against this repository.  I haven't built the JDK myself, I'll need guidance if required.  I have a proof-of-concept example ? demonstrating the bug and a workaround available as a [public gist](https://gist.github.com/stanio/b79ce9348946aa6b3395328ec4c59d14).  I have included a sample test though I don't know if it is annotated properly.
> 
> **Current behavior**
> 
> <style>
>   h2, .h2 { font-size: 150% }
> </style>
> 
> <body>
> 
>   <h2>Foo</h2>            
> 
>   <div class=h2>Bar</div> 
> 
>   <ol class=h2>           
>     <li>Baz</li>          
>   </ol>
> 
>   <table class=h2>
>     <tr>
>       <td>Qux</td>        
>     </tr>
>   </table>
> 
> </body>
> 
> **Expected behavior**
> 
> All text should be displayed with a font size of the computed `<body>` font-size ? 1.5.
> 
> [JDK-8257664]: https://bugs.openjdk.java.net/browse/JDK-8257664

Stanimir Stamenkov has updated the pull request incrementally with one additional commit since the last revision:

  fixup! 8257664: Fix font-size inheritance with percentage values
  
  Declare fontSizeInherit() accessor private.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1759/files
  - new: https://git.openjdk.java.net/jdk/pull/1759/files/497b9556..10a61015

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

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

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

From github.com+1247730+stanio at openjdk.java.net  Sat Jan 16 06:56:16 2021
From: github.com+1247730+stanio at openjdk.java.net (Stanimir Stamenkov)
Date: Sat, 16 Jan 2021 06:56:16 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v4]
In-Reply-To: <JqJsD2bfVVefhRtm9w2sykeQX9iMXLBiilcLkAk_tgE=.4f71b045-1cd7-4ed6-b804-3c4e0c722b35@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <slAYSpjokcv-f9rL2w1NW3K0-ZWuDONqlMP5bLEF9Uk=.7a07b294-ae1b-49d0-9606-eb75db6695ea@github.com>
 <JqJsD2bfVVefhRtm9w2sykeQX9iMXLBiilcLkAk_tgE=.4f71b045-1cd7-4ed6-b804-3c4e0c722b35@github.com>
Message-ID: <Wjv0avHrp9DekzRqrexJcn0jFunZn7LFjzDTaL_NILI=.db2e95fb-187e-490b-86fc-0aab070aa7a7@github.com>

On Fri, 15 Jan 2021 23:27:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Stanimir Stamenkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixup! 8257664: Fix font-size inheritance with percentage values
>>   
>>   Init the "fontSizeInherit" value using the instance "StyleSheet.css".
>
> src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java line 1737:
> 
>> 1735:      *          property values, Cascading, and Inheritance</a>
>> 1736:      */
>> 1737:     Object fontSizeInherit() {
> 
> The method can be private, right?

Made it private now.

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

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

From kizune at openjdk.java.net  Sun Jan 17 09:32:59 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sun, 17 Jan 2021 09:32:59 GMT
Subject: <Swing Dev> RFR: 8259650:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button"
Message-ID: <XXLflqJDIAAkASMMCw9siQKb2uEFHOdqit4A1c-bSbg=.ee7147fc-51c0-4b60-acb5-bb9e2220a9e8@github.com>

8259650: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"

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

Commit messages:
 - 8259650: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"
 - Merge remote-tracking branch 'upstream/master' into master
 - Merge remote-tracking branch 'upstream/master' into master
 - Merge branch 'openjdk-master' into master
 - Merge branch 'master' of https://github.com/openjdk/jdk into openjdk-master
 - Merge pull request #7 from openjdk/master
 - Merge pull request #6 from openjdk/master
 - Merge pull request #5 from openjdk/master
 - Merge pull request #4 from openjdk/master
 - Merge pull request #3 from openjdk/master
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/da4cf05d...c20f311a

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

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

From kizune at openjdk.java.net  Sun Jan 17 10:45:53 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sun, 17 Jan 2021 10:45:53 GMT
Subject: <Swing Dev> [jdk16] RFR: 8258643: [TESTBUG]
 javax/swing/JComponent/7154030/bug7154030.java failed with "Exception:
 Failed to hide opaque button" [v2]
In-Reply-To: <ztDy6dZafIlrEiPUkV7Agfxc4u8FZ9ybntdpgg9NMUg=.64330edd-6db7-49a2-88ba-c1584c5b8570@github.com>
References: <ztDy6dZafIlrEiPUkV7Agfxc4u8FZ9ybntdpgg9NMUg=.64330edd-6db7-49a2-88ba-c1584c5b8570@github.com>
Message-ID: <8D6d0EmbNSd5W17D6rVGTZ8nNBLSsh9RoFnA1ReYa4Y=.72a667c2-41ab-4d65-97d7-44556bdfba2e@github.com>

> Backport from mainline.

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

  Added 1s delay before taking the first screenshot to give slow systems
  enough time to finish painting.

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/119/files
  - new: https://git.openjdk.java.net/jdk16/pull/119/files/c3b4e3bf..24bb1c8e

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

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/119.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/119/head:pull/119

PR: https://git.openjdk.java.net/jdk16/pull/119

From jdv at openjdk.java.net  Mon Jan 18 03:10:36 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 18 Jan 2021 03:10:36 GMT
Subject: <Swing Dev> RFR: 8259650:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button"
In-Reply-To: <XXLflqJDIAAkASMMCw9siQKb2uEFHOdqit4A1c-bSbg=.ee7147fc-51c0-4b60-acb5-bb9e2220a9e8@github.com>
References: <XXLflqJDIAAkASMMCw9siQKb2uEFHOdqit4A1c-bSbg=.ee7147fc-51c0-4b60-acb5-bb9e2220a9e8@github.com>
Message-ID: <2gSe0GmiUQzjFoO3tVCwhohxonAvopmArDMy9dYXTS4=.bf0bc534-b6ca-46b7-8ad7-b6fa0e24291f@github.com>

On Sun, 17 Jan 2021 09:26:52 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8259650: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"

Marked as reviewed by jdv (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Mon Jan 18 04:54:39 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 18 Jan 2021 04:54:39 GMT
Subject: <Swing Dev> RFR: 8259650:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button"
In-Reply-To: <XXLflqJDIAAkASMMCw9siQKb2uEFHOdqit4A1c-bSbg=.ee7147fc-51c0-4b60-acb5-bb9e2220a9e8@github.com>
References: <XXLflqJDIAAkASMMCw9siQKb2uEFHOdqit4A1c-bSbg=.ee7147fc-51c0-4b60-acb5-bb9e2220a9e8@github.com>
Message-ID: <MRmnmXtG0cH5NyY7zQqOwXMdg_TWXrYVaSQ5aV__eZ8=.69013ef9-c03d-406a-9506-43a7d04c8ca8@github.com>

On Sun, 17 Jan 2021 09:26:52 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8259650: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"

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

> 94:             robot.waitForIdle(1000);
> 95: 
> 96:             Rectangle bounds = frame.getBounds();

Iguess we missed putting this getBounds and getInsets call in EDT. Maybe that thread context switch can make up for the delay that is introduced now as we already have a 1s wait before screen capture.

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

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

From ljiang at openjdk.java.net  Mon Jan 18 05:52:57 2021
From: ljiang at openjdk.java.net (Leo Jiang)
Date: Mon, 18 Jan 2021 05:52:57 GMT
Subject: <Swing Dev> [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file
 update - msg drop 10 [v3]
In-Reply-To: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
References: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
Message-ID: <VR1_KkzLukMWQ9XA_kj1FBe43uAJDkK85cOZjB60vvU=.d08b1f75-a587-4cb5-9a63-46243a4126b9@github.com>

> This is the changes for JDK 16 msg drop 10.

Leo Jiang has updated the pull request incrementally with one additional commit since the last revision:

  fix the missing copyright year for standard.properties

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/123/files
  - new: https://git.openjdk.java.net/jdk16/pull/123/files/d72f444a..9c7574e2

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/123.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/123/head:pull/123

PR: https://git.openjdk.java.net/jdk16/pull/123

From ljiang at openjdk.java.net  Mon Jan 18 05:52:57 2021
From: ljiang at openjdk.java.net (Leo Jiang)
Date: Mon, 18 Jan 2021 05:52:57 GMT
Subject: <Swing Dev> [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file
 update - msg drop 10 [v2]
In-Reply-To: <F3h1x-ZgNClOKHsAunvSztkl9XxmH7cP9YPZoz_O08I=.2d76925f-b12f-49c0-9631-94e663df59e3@github.com>
References: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
 <QceWk9N7q2iV9alfICITS0Sdr8eacuR15Mrihph-doI=.1cee427c-0be1-4cb9-8a77-098696ddd5da@github.com>
 <ZkHoKP8fL7uRj0TIiwqYtVch0eyxQGv2JeY-BDgf310=.91ef28d1-d91b-4b37-aa9f-edd81b94f235@github.com>
 <1Bb8sf6zFDnQSM5kRQIlrgBNwEpO-IvxsPmN05F0QFs=.13eb3035-71d5-4310-98e5-d9989e51cf60@github.com>
 <F3h1x-ZgNClOKHsAunvSztkl9XxmH7cP9YPZoz_O08I=.2d76925f-b12f-49c0-9631-94e663df59e3@github.com>
Message-ID: <GwheKm_jhEEkNScvPOWJL_eye7kQD7VXk6gLUi09JKQ=.8e7a23d0-f978-4734-99c3-e6f611f380e9@github.com>

On Sat, 16 Jan 2021 00:48:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Actually I was correcting the L217, changed {) -> {}. But 2 days ago, Jonathan Gibbons fixed it in another commit 6bb6093. I found his fix after running the merge. Looks both of us forgot to update the copyright year. Any suggestion? 
>> doclet.help.systemProperties.body=\
>>     The {0} page lists references to system properties.
>
> I believe your PR still contains the fix to add the newline at the end of the file (at L518). So I think you can simply change the copyright year in `standard.properties` file.

Thx! Fixed the copyright year for this file.

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

PR: https://git.openjdk.java.net/jdk16/pull/123

From psadhukhan at openjdk.java.net  Mon Jan 18 07:23:37 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 18 Jan 2021 07:23:37 GMT
Subject: <Swing Dev> Integrated: 8202880: Test
 javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java fails
In-Reply-To: <6jy3ChTwGm7xXWBrZYtD1_KSLgUdvAy69BrKhH_q958=.1b0b51a9-3f50-4352-85bd-c3d440dff2a4@github.com>
References: <6jy3ChTwGm7xXWBrZYtD1_KSLgUdvAy69BrKhH_q958=.1b0b51a9-3f50-4352-85bd-c3d440dff2a4@github.com>
Message-ID: <z8w_O4s2RT3MG9EXNO1Bx-pAGpFDUEL_4b0iMl5YnjY=.eec52492-3c8f-47e7-acb9-28281e95b421@github.com>

On Wed, 13 Jan 2021 10:41:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test was unstable in linux in nightly testing. Modified to move the frame to center of screen so that the left-taskbar of linux doesn't interfere with the mouse movement along with delay after frame is visible to make it more stable. 
> Mach5 job running for several iterations on all platforms is ok. Link in JBS.

This pull request has now been integrated.

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

8202880: Test javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java fails

Reviewed-by: aivanov

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

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

From kizune at openjdk.java.net  Mon Jan 18 08:26:39 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 18 Jan 2021 08:26:39 GMT
Subject: <Swing Dev> Integrated: 8259650:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button"
In-Reply-To: <XXLflqJDIAAkASMMCw9siQKb2uEFHOdqit4A1c-bSbg=.ee7147fc-51c0-4b60-acb5-bb9e2220a9e8@github.com>
References: <XXLflqJDIAAkASMMCw9siQKb2uEFHOdqit4A1c-bSbg=.ee7147fc-51c0-4b60-acb5-bb9e2220a9e8@github.com>
Message-ID: <6tDVD3i10MqQjfPYX3xSLyOuyfS6gZmWi8FwYTDmzyg=.c7d3c163-96e0-4281-8b87-5bd24b3db43e@github.com>

On Sun, 17 Jan 2021 09:26:52 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8259650: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"

This pull request has now been integrated.

Changeset: 917f7e9a
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/917f7e9a
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8259650: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"

Reviewed-by: jdv

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

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

From aivanov at openjdk.java.net  Mon Jan 18 11:33:41 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 18 Jan 2021 11:33:41 GMT
Subject: <Swing Dev> RFR: JDK-8259818: [TEST_BUG] Convert applet-based
 test test/jdk/javax/swing/JCheckBox/8032667/bug8032667.java to a regular
 java
In-Reply-To: <i6kNaINfZsYGdFKJBp0GLB7szgTJLNfVRTC0p0AxJis=.fd07bca7-e529-4591-9c91-432950b31911@github.com>
References: <bH5GWlDU1MsCjYSn1Bf8JfQakEJY4KMyeYGyAlnlYAg=.3027998f-d5ef-4e3c-a116-3a124e66d721@github.com>
 <i6kNaINfZsYGdFKJBp0GLB7szgTJLNfVRTC0p0AxJis=.fd07bca7-e529-4591-9c91-432950b31911@github.com>
Message-ID: <765zFxcbZfKE4vd3QFpnl2su3ibljAuiNehF_xboaV4=.9a4fc3f7-8728-431c-9960-82ca93d645c2@github.com>

On Sat, 16 Jan 2021 00:42:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Dear All,
>> 
>> Hi All, Could you please review this fix for JDK17?
>> 
>> Problem Description: The test open/test/jdk/javax/swing/JCheckBox/8032667/bug8032667.java is applet based.
>> 
>> Fix: Rewritten the above applet based test as a regular java test.
>> 
>> Best Regards,
>> K Suman Rajkumaar
>
> test/jdk/javax/swing/JCheckBox/8032667/bug8032667.java line 50:
> 
>> 48:  * @bug 8032667
>> 49:  * @summary [macosx] Components cannot be rendered in HiDPI to BufferedImage
>> 50:  * @run main bug8032667
> 
> I suggest do not convert manual tests from the applet to the regular tests, until we will not find a way to unify them, in a similar way as it was for "applet/manual=yesno". Otherwise, all our manual tests will look differently, since different people will make the UI differently.

Unifying the UI makes sense in the long run. Will it involve retrofitting all the existing manual test which already have its own UI?

In most cases, the UI in manual tests is similar: Pass / Fail buttons at the bottom with the test instructions above. Then there are differences? Other parts of the UI depend on the nature of the test.

I've always found manual tests a bit confusing: a test, especially applet-based one, opens two windows; however, one window is easier to focus on.

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

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

From psadhukhan at openjdk.java.net  Mon Jan 18 12:14:47 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 18 Jan 2021 12:14:47 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v5]
In-Reply-To: <KG8PuSyeWLNrr-SURStOiAakLjBsGDmzSoeMXnBT5ks=.20e1acaa-2b4c-4d41-854c-df477a4b72ca@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <KG8PuSyeWLNrr-SURStOiAakLjBsGDmzSoeMXnBT5ks=.20e1acaa-2b4c-4d41-854c-df477a4b72ca@github.com>
Message-ID: <CVqrAYWWzxJwDb8OEAMF02OaerjIc7VWKzfD5xIIkTU=.2f290a86-bf73-4c5f-91b5-96172e0051fe@github.com>

On Sat, 16 Jan 2021 06:45:35 GMT, Stanimir Stamenkov <github.com+1247730+stanio at openjdk.org> wrote:

>> Fix for [JDK-8257664][] ? HTMLEditorKit: Wrong CSS relative font sizes.
>> 
>> _Disclaimer:_ I'm the reporter of the issue and I've been advised the best chance to get it addressed is to submit a pull request against this repository.  I haven't built the JDK myself, I'll need guidance if required.  I have a proof-of-concept example ? demonstrating the bug and a workaround available as a [public gist](https://gist.github.com/stanio/b79ce9348946aa6b3395328ec4c59d14).  I have included a sample test though I don't know if it is annotated properly.
>> 
>> **Current behavior**
>> 
>> <style>
>>   h2, .h2 { font-size: 150% }
>> </style>
>> 
>> <body>
>> 
>>   <h2>Foo</h2>            
>> 
>>   <div class=h2>Bar</div> 
>> 
>>   <ol class=h2>           
>>     <li>Baz</li>          
>>   </ol>
>> 
>>   <table class=h2>
>>     <tr>
>>       <td>Qux</td>        
>>     </tr>
>>   </table>
>> 
>> </body>
>> 
>> **Expected behavior**
>> 
>> All text should be displayed with a font size of the computed `<body>` font-size ? 1.5.
>> 
>> [JDK-8257664]: https://bugs.openjdk.java.net/browse/JDK-8257664
>
> Stanimir Stamenkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixup! 8257664: Fix font-size inheritance with percentage values
>   
>   Declare fontSizeInherit() accessor private.

Looks good to me. Internal testing is also ok. 
However, I have one question, html text is honouring "font-size" value(say 1.5 as per testcase) but if Display resolution in windows system setting or via -Dsun.java2d.uiScale is set to something different(say 1.25), then should it honour the font-size property (1.5) or Display resolution (1.25)?

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

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

From aivanov at openjdk.java.net  Mon Jan 18 12:14:48 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 18 Jan 2021 12:14:48 GMT
Subject: <Swing Dev> RFR: JDK-8259818: [TEST_BUG] Convert applet-based
 test test/jdk/javax/swing/JCheckBox/8032667/bug8032667.java to a regular
 java
In-Reply-To: <765zFxcbZfKE4vd3QFpnl2su3ibljAuiNehF_xboaV4=.9a4fc3f7-8728-431c-9960-82ca93d645c2@github.com>
References: <bH5GWlDU1MsCjYSn1Bf8JfQakEJY4KMyeYGyAlnlYAg=.3027998f-d5ef-4e3c-a116-3a124e66d721@github.com>
 <i6kNaINfZsYGdFKJBp0GLB7szgTJLNfVRTC0p0AxJis=.fd07bca7-e529-4591-9c91-432950b31911@github.com>
 <765zFxcbZfKE4vd3QFpnl2su3ibljAuiNehF_xboaV4=.9a4fc3f7-8728-431c-9960-82ca93d645c2@github.com>
Message-ID: <0CkmITP6hhucT5SsWhZzFdsZ1AwxNlFvl8m4p5ZBqhc=.65bd44c0-2a18-4d6a-bd66-1c72f7bb5ada@github.com>

On Mon, 18 Jan 2021 11:30:55 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/JCheckBox/8032667/bug8032667.java line 50:
>> 
>>> 48:  * @bug 8032667
>>> 49:  * @summary [macosx] Components cannot be rendered in HiDPI to BufferedImage
>>> 50:  * @run main bug8032667
>> 
>> I suggest do not convert manual tests from the applet to the regular tests, until we will not find a way to unify them, in a similar way as it was for "applet/manual=yesno". Otherwise, all our manual tests will look differently, since different people will make the UI differently.
>
> Unifying the UI makes sense in the long run. Will it involve retrofitting all the existing manual test which already have its own UI?
> 
> In most cases, the UI in manual tests is similar: Pass / Fail buttons at the bottom with the test instructions above. Then there are differences? Other parts of the UI depend on the nature of the test.
> 
> I've always found manual tests a bit confusing: a test, especially applet-based one, opens two windows; however, one window is easier to focus on.

To confirm: we're not modifying the current applet-based manual tests until there's a common framework to migrate them off the applet API. Do I understand it correctly?

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

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

From aivanov at openjdk.java.net  Mon Jan 18 12:26:43 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 18 Jan 2021 12:26:43 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v5]
In-Reply-To: <KG8PuSyeWLNrr-SURStOiAakLjBsGDmzSoeMXnBT5ks=.20e1acaa-2b4c-4d41-854c-df477a4b72ca@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <KG8PuSyeWLNrr-SURStOiAakLjBsGDmzSoeMXnBT5ks=.20e1acaa-2b4c-4d41-854c-df477a4b72ca@github.com>
Message-ID: <FFRP_ZzLyjUFxWb859k1Oal4BuaafQ2UJn6ZWjrcBuM=.ff70782d-8c44-4d93-9782-a4e5d08a0ebe@github.com>

On Sat, 16 Jan 2021 06:45:35 GMT, Stanimir Stamenkov <github.com+1247730+stanio at openjdk.org> wrote:

>> Fix for [JDK-8257664][] ? HTMLEditorKit: Wrong CSS relative font sizes.
>> 
>> _Disclaimer:_ I'm the reporter of the issue and I've been advised the best chance to get it addressed is to submit a pull request against this repository.  I haven't built the JDK myself, I'll need guidance if required.  I have a proof-of-concept example ? demonstrating the bug and a workaround available as a [public gist](https://gist.github.com/stanio/b79ce9348946aa6b3395328ec4c59d14).  I have included a sample test though I don't know if it is annotated properly.
>> 
>> **Current behavior**
>> 
>> <style>
>>   h2, .h2 { font-size: 150% }
>> </style>
>> 
>> <body>
>> 
>>   <h2>Foo</h2>            
>> 
>>   <div class=h2>Bar</div> 
>> 
>>   <ol class=h2>           
>>     <li>Baz</li>          
>>   </ol>
>> 
>>   <table class=h2>
>>     <tr>
>>       <td>Qux</td>        
>>     </tr>
>>   </table>
>> 
>> </body>
>> 
>> **Expected behavior**
>> 
>> All text should be displayed with a font size of the computed `<body>` font-size ? 1.5.
>> 
>> [JDK-8257664]: https://bugs.openjdk.java.net/browse/JDK-8257664
>
> Stanimir Stamenkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixup! 8257664: Fix font-size inheritance with percentage values
>   
>   Declare fontSizeInherit() accessor private.

Looks good to me.

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

Marked as reviewed by aivanov (Reviewer).

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

From aivanov at openjdk.java.net  Mon Jan 18 12:26:44 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 18 Jan 2021 12:26:44 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v5]
In-Reply-To: <CVqrAYWWzxJwDb8OEAMF02OaerjIc7VWKzfD5xIIkTU=.2f290a86-bf73-4c5f-91b5-96172e0051fe@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <KG8PuSyeWLNrr-SURStOiAakLjBsGDmzSoeMXnBT5ks=.20e1acaa-2b4c-4d41-854c-df477a4b72ca@github.com>
 <CVqrAYWWzxJwDb8OEAMF02OaerjIc7VWKzfD5xIIkTU=.2f290a86-bf73-4c5f-91b5-96172e0051fe@github.com>
Message-ID: <aCOUriGwgdD3fK6QOeQenfqt3L4pLeU6OlIzBbd5U3g=.474e13cb-d9f7-4678-a03b-5248e7822da4@github.com>

On Mon, 18 Jan 2021 12:11:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Stanimir Stamenkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixup! 8257664: Fix font-size inheritance with percentage values
>>   
>>   Declare fontSizeInherit() accessor private.
>
> Looks good to me. Internal testing is also ok. 
> However, I have one question, html text is honouring "font-size" value(say 1.5 as per testcase) but if Display resolution in windows system setting or via -Dsun.java2d.uiScale is set to something different(say 1.25), then should it honour the font-size property (1.5) or Display resolution (1.25)?

Shouldn't UI scaling be applied automatically? The font size in user space should remain the same, yet the actual font size would be scaled up according to the DPI setting. That is in my understanding, CSS rule applies 150% to the base font size according to its rules; then `uiScale` is applied to whatever the computed font size is.

Does it make sense to run the test with different `uiScale` explicitly?
I ran the test on my laptop with 150% scaling, it passed successfully.

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

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

From serb at openjdk.java.net  Mon Jan 18 12:30:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 18 Jan 2021 12:30:40 GMT
Subject: <Swing Dev> RFR: JDK-8259818: [TEST_BUG] Convert applet-based
 test test/jdk/javax/swing/JCheckBox/8032667/bug8032667.java to a regular
 java
In-Reply-To: <0CkmITP6hhucT5SsWhZzFdsZ1AwxNlFvl8m4p5ZBqhc=.65bd44c0-2a18-4d6a-bd66-1c72f7bb5ada@github.com>
References: <bH5GWlDU1MsCjYSn1Bf8JfQakEJY4KMyeYGyAlnlYAg=.3027998f-d5ef-4e3c-a116-3a124e66d721@github.com>
 <i6kNaINfZsYGdFKJBp0GLB7szgTJLNfVRTC0p0AxJis=.fd07bca7-e529-4591-9c91-432950b31911@github.com>
 <765zFxcbZfKE4vd3QFpnl2su3ibljAuiNehF_xboaV4=.9a4fc3f7-8728-431c-9960-82ca93d645c2@github.com>
 <0CkmITP6hhucT5SsWhZzFdsZ1AwxNlFvl8m4p5ZBqhc=.65bd44c0-2a18-4d6a-bd66-1c72f7bb5ada@github.com>
Message-ID: <MF6d7udQtQU8zVXX4AOAS7daGOPrXCWIojvjCURSVLI=.3a5ba909-c91f-4955-a40a-405467f4c6fd@github.com>

On Mon, 18 Jan 2021 12:12:10 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Unifying the UI makes sense in the long run. Will it involve retrofitting all the existing manual test which already have its own UI?
>> 
>> In most cases, the UI in manual tests is similar: Pass / Fail buttons at the bottom with the test instructions above. Then there are differences? Other parts of the UI depend on the nature of the test.
>> 
>> I've always found manual tests a bit confusing: a test, especially applet-based one, opens two windows; however, one window is easier to focus on.
>
> To confirm: we're not modifying the current applet-based manual tests until there's a common framework to migrate them off the applet API. Do I understand it correctly?

Yes, I suggest that. Maybe we can start with that replacement? In the jtreg itself or via separate lib.

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

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

From aivanov at openjdk.java.net  Mon Jan 18 12:34:48 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 18 Jan 2021 12:34:48 GMT
Subject: <Swing Dev> RFR: JDK-8259818: [TEST_BUG] Convert applet-based
 test test/jdk/javax/swing/JCheckBox/8032667/bug8032667.java to a regular
 java
In-Reply-To: <MF6d7udQtQU8zVXX4AOAS7daGOPrXCWIojvjCURSVLI=.3a5ba909-c91f-4955-a40a-405467f4c6fd@github.com>
References: <bH5GWlDU1MsCjYSn1Bf8JfQakEJY4KMyeYGyAlnlYAg=.3027998f-d5ef-4e3c-a116-3a124e66d721@github.com>
 <i6kNaINfZsYGdFKJBp0GLB7szgTJLNfVRTC0p0AxJis=.fd07bca7-e529-4591-9c91-432950b31911@github.com>
 <765zFxcbZfKE4vd3QFpnl2su3ibljAuiNehF_xboaV4=.9a4fc3f7-8728-431c-9960-82ca93d645c2@github.com>
 <0CkmITP6hhucT5SsWhZzFdsZ1AwxNlFvl8m4p5ZBqhc=.65bd44c0-2a18-4d6a-bd66-1c72f7bb5ada@github.com>
 <MF6d7udQtQU8zVXX4AOAS7daGOPrXCWIojvjCURSVLI=.3a5ba909-c91f-4955-a40a-405467f4c6fd@github.com>
Message-ID: <iEFJkjRLwee5fAm4YB6QT9S9iROrdBE6wFLzwTzEwMc=.a785b01d-a679-4321-8d65-40ebd4c38bff@github.com>

On Mon, 18 Jan 2021 12:28:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> To confirm: we're not modifying the current applet-based manual tests until there's a common framework to migrate them off the applet API. Do I understand it correctly?
>
> Yes, I suggest that. Maybe we can start with that replacement? In the jtreg itself or via separate lib.

A separate lib seems more convenient as it will allow running such tests without test harness which is quicker and useful for debugging.

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

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

From github.com+1247730+stanio at openjdk.java.net  Mon Jan 18 13:23:50 2021
From: github.com+1247730+stanio at openjdk.java.net (Stanimir Stamenkov)
Date: Mon, 18 Jan 2021 13:23:50 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v5]
In-Reply-To: <FFRP_ZzLyjUFxWb859k1Oal4BuaafQ2UJn6ZWjrcBuM=.ff70782d-8c44-4d93-9782-a4e5d08a0ebe@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <KG8PuSyeWLNrr-SURStOiAakLjBsGDmzSoeMXnBT5ks=.20e1acaa-2b4c-4d41-854c-df477a4b72ca@github.com>
 <FFRP_ZzLyjUFxWb859k1Oal4BuaafQ2UJn6ZWjrcBuM=.ff70782d-8c44-4d93-9782-a4e5d08a0ebe@github.com>
Message-ID: <KtNJr-UaLiyE6zrhWlDKHOBsLio8D7uKb1xZPIBAfPs=.bebb4f28-3d4b-47c8-adff-fc9d3fde3197@github.com>

On Mon, 18 Jan 2021 12:23:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Stanimir Stamenkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixup! 8257664: Fix font-size inheritance with percentage values
>>   
>>   Declare fontSizeInherit() accessor private.
>
> Looks good to me.

The display dpi shouldn't matter.  I've tried it in a couple of different monitor configurations: 1.25, 1.5, and 2.0 scaling.  I've also tried it with non-dpi-aware Java 8.  I've used `body { font-size: 14 }` which should always evaluate to `Font.size=14` (no matter the `w3cLengthUnits` value, for example) ? the other elements use relative to that base font-size.

Before I type `/integrate`, is the rebase smart enough to squash the _fixup!_ commits, or should I rebase manually once for that purpose?  Maybe it would squash the commits in any case?  @aivanov-jdk or @prsadhuk, would you sponsor this PR?

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

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

From aivanov at openjdk.java.net  Mon Jan 18 14:25:56 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 18 Jan 2021 14:25:56 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v5]
In-Reply-To: <FFRP_ZzLyjUFxWb859k1Oal4BuaafQ2UJn6ZWjrcBuM=.ff70782d-8c44-4d93-9782-a4e5d08a0ebe@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <KG8PuSyeWLNrr-SURStOiAakLjBsGDmzSoeMXnBT5ks=.20e1acaa-2b4c-4d41-854c-df477a4b72ca@github.com>
 <FFRP_ZzLyjUFxWb859k1Oal4BuaafQ2UJn6ZWjrcBuM=.ff70782d-8c44-4d93-9782-a4e5d08a0ebe@github.com>
Message-ID: <mrpuRPhB0ew31_be_RC08TkC29bUZp_FcKuKqrH4O9s=.e818dbcd-f707-499a-8c19-4f071d84fb1c@github.com>

On Mon, 18 Jan 2021 12:23:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Stanimir Stamenkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixup! 8257664: Fix font-size inheritance with percentage values
>>   
>>   Declare fontSizeInherit() accessor private.
>
> Looks good to me.

> Before I type `/integrate`, is the rebase smart enough to squash the _fixup!_ commits, or should I rebase manually once for that purpose? Maybe it would squash the commits in any case? @aivanov-jdk or @prsadhuk, would you sponsor this PR?

Yes, your commits in the branch will be squashed into one commit in the upstream.

I am ready to sponsor, I think @prsadhuk wouldn't mind to sponsor too. However, @prsadhuk hasn't approved it yet; I'd like to wait until he does so.

Thank you @stanio for contributing the fix!

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

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

From kizune at openjdk.java.net  Mon Jan 18 22:14:45 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 18 Jan 2021 22:14:45 GMT
Subject: <Swing Dev> [jdk16] Integrated: 8258643: [TESTBUG]
 javax/swing/JComponent/7154030/bug7154030.java failed with "Exception:
 Failed to hide opaque button"
In-Reply-To: <ztDy6dZafIlrEiPUkV7Agfxc4u8FZ9ybntdpgg9NMUg=.64330edd-6db7-49a2-88ba-c1584c5b8570@github.com>
References: <ztDy6dZafIlrEiPUkV7Agfxc4u8FZ9ybntdpgg9NMUg=.64330edd-6db7-49a2-88ba-c1584c5b8570@github.com>
Message-ID: <Y0oNojFuoK4PKhR2x3qBT79VwXxlKTcCYC10MkHMRZU=.5dac2904-daf2-4aac-9db0-cbf4003adaba@github.com>

On Wed, 13 Jan 2021 22:26:47 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Backport from mainline.

This pull request has now been integrated.

Changeset: bb0821eb
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/bb0821eb
Stats:     13 lines in 1 file changed: 2 ins; 5 del; 6 mod

8258643: [TESTBUG] javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button"

Reviewed-by: trebari, psadhukhan

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

PR: https://git.openjdk.java.net/jdk16/pull/119

From trebari at openjdk.java.net  Tue Jan 19 14:33:52 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Tue, 19 Jan 2021 14:33:52 GMT
Subject: <Swing Dev> RFR: 8049700: Deprecate obsolete classes and
 methods in javax/swing/plaf/basic
In-Reply-To: <y3oqqpwrNBwm3msFEQzyThS0DiGor2HrFHWG8lJRVWw=.3c80f178-4bc5-4bb6-87ca-ddf20890e7a7@github.com>
References: <LcIvlc2HZGDo6ErOfqf_QZlwCpO2a7o2pPIDeaCb40E=.80fa98b5-728e-4198-a4fd-8d70e21302fc@github.com>
 <y3oqqpwrNBwm3msFEQzyThS0DiGor2HrFHWG8lJRVWw=.3c80f178-4bc5-4bb6-87ca-ddf20890e7a7@github.com>
Message-ID: <wiiczD0Ann83s0Xphrf_mKm_HsL8RwHKRtOqRE16AMY=.c003bd15-9779-40f9-b6a5-ec13e6549040@github.com>

On Wed, 13 Jan 2021 05:52:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Please review the following fix for jdk17.
>> In this fix i have deprecated and marked for removal following classes and methods 
>>    public void intervalAdded(ListDataEvent e)
>>    public void intervalRemoved(ListDataEvent e)
>>    protected boolean lt(File a, File b) in BasicDirectoryModel.java
>> 
>>    inner class PropertyChangeHandler, VSBChangeListener, HSBChangeListener, 
>>    ViewportChangeHandler in BasicScrollPaneUI.java
>>    inner class MouseInputHandler in BasicMenuItemUI.java
>>    method BasicToolBarUI.java#createFloatingFrame
>> 
>> From 8049700 not deprecated the paintText(Graphics g, JComponent c, Rectangle textRect, String text) method in BasicButtonUI  as AquaButtonUI, MetalButtonUI and MetalToggleButtonUI overrides it.
>> Similarly not deprecated ChangeHandler of BasicMenuUI as AquaMenuUI and MotifMenuUI uses this class.
>
> Please elaborate as to why this methods are to be deprecated.
> It will be useful if you give alternate methods to be used in the javadoc in @deprecated tag 
> which are supposed to be called by user once these are removed.

The methods intervalAdded(ListDataEvent e) ,intervalRemoved(ListDataEvent e) and  lt(File a, File b) of  javax/swing/plaf/basic/BasicDirectoryModel.java  states that "Obsolete - not used" ( in the doc).

The BasicDirectoryModel uses similar methods like fireIntervalAdded, fireIntervalRemoved which calls AbstractListModel#fireIntervalAdded.
But not sure that these are the  alternate methods.Also dont see anything similar to lt(File a, File b).

The method createFloatingFrame in the BasicToolBarUI.java states that it is "No longer used" and also specifies to use BasicToolBarUI.createFloatingWindow(JToolBar).

The class MouseInputHandler in BasicMenuUI.java and classes PropertyChangeHandler, VSBChangeListener, HSBChangeListener, ViewportChangeHandler in BasicScrollPaneUI.java states that(as comments inside the class)
        "This class exists only for backward compatibility. All
        its functionality has been moved into Handler."
we can add the above in the doc for these classes.

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

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

From trebari at openjdk.java.net  Tue Jan 19 14:40:07 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Tue, 19 Jan 2021 14:40:07 GMT
Subject: <Swing Dev> RFR: 8049700: Deprecate obsolete classes and
 methods in javax/swing/plaf/basic [v2]
In-Reply-To: <LcIvlc2HZGDo6ErOfqf_QZlwCpO2a7o2pPIDeaCb40E=.80fa98b5-728e-4198-a4fd-8d70e21302fc@github.com>
References: <LcIvlc2HZGDo6ErOfqf_QZlwCpO2a7o2pPIDeaCb40E=.80fa98b5-728e-4198-a4fd-8d70e21302fc@github.com>
Message-ID: <Ivbcu46iJibKuog5Jr0DPd_zgrKOqejBgI52ByTb6JQ=.cdcade67-0a9b-4dda-8e96-da8436673097@github.com>

> Please review the following fix for jdk17.
> In this fix i have deprecated and marked for removal following classes and methods 
>    public void intervalAdded(ListDataEvent e)
>    public void intervalRemoved(ListDataEvent e)
>    protected boolean lt(File a, File b) in BasicDirectoryModel.java
> 
>    inner class PropertyChangeHandler, VSBChangeListener, HSBChangeListener, 
>    ViewportChangeHandler in BasicScrollPaneUI.java
>    inner class MouseInputHandler in BasicMenuItemUI.java
>    method BasicToolBarUI.java#createFloatingFrame
> 
> From 8049700 not deprecated the paintText(Graphics g, JComponent c, Rectangle textRect, String text) method in BasicButtonUI  as AquaButtonUI, MetalButtonUI and MetalToggleButtonUI overrides it.
> Similarly not deprecated ChangeHandler of BasicMenuUI as AquaMenuUI and MotifMenuUI uses this class.

Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:

  minor correction

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1958/files
  - new: https://git.openjdk.java.net/jdk/pull/1958/files/8504fc7c..9bdb67a3

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

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

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

From naoto at openjdk.java.net  Tue Jan 19 16:55:46 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 19 Jan 2021 16:55:46 GMT
Subject: <Swing Dev> [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file
 update - msg drop 10 [v3]
In-Reply-To: <VR1_KkzLukMWQ9XA_kj1FBe43uAJDkK85cOZjB60vvU=.d08b1f75-a587-4cb5-9a63-46243a4126b9@github.com>
References: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
 <VR1_KkzLukMWQ9XA_kj1FBe43uAJDkK85cOZjB60vvU=.d08b1f75-a587-4cb5-9a63-46243a4126b9@github.com>
Message-ID: <ZW3t1ah5vc0nMrrtyC7SvWQdVXwtu7BY4-Z9Nc2hk98=.f5a22fa9-b0f6-4c8f-86e9-dbd93c2fa09f@github.com>

On Mon, 18 Jan 2021 05:52:57 GMT, Leo Jiang <ljiang at openjdk.org> wrote:

>> This is the changes for JDK 16 msg drop 10.
>
> Leo Jiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix the missing copyright year for standard.properties

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/123

From psadhukhan at openjdk.java.net  Wed Jan 20 04:49:52 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 20 Jan 2021 04:49:52 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v5]
In-Reply-To: <KG8PuSyeWLNrr-SURStOiAakLjBsGDmzSoeMXnBT5ks=.20e1acaa-2b4c-4d41-854c-df477a4b72ca@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <KG8PuSyeWLNrr-SURStOiAakLjBsGDmzSoeMXnBT5ks=.20e1acaa-2b4c-4d41-854c-df477a4b72ca@github.com>
Message-ID: <ZbcCzfn2QqzvSzCM-LeKtTIxFIJrUmt3J3_DI2oK9C8=.b9387e9e-4030-4806-87f7-bcc871fc7b7a@github.com>

On Sat, 16 Jan 2021 06:45:35 GMT, Stanimir Stamenkov <github.com+1247730+stanio at openjdk.org> wrote:

>> Fix for [JDK-8257664][] ? HTMLEditorKit: Wrong CSS relative font sizes.
>> 
>> _Disclaimer:_ I'm the reporter of the issue and I've been advised the best chance to get it addressed is to submit a pull request against this repository.  I haven't built the JDK myself, I'll need guidance if required.  I have a proof-of-concept example ? demonstrating the bug and a workaround available as a [public gist](https://gist.github.com/stanio/b79ce9348946aa6b3395328ec4c59d14).  I have included a sample test though I don't know if it is annotated properly.
>> 
>> **Current behavior**
>> 
>> <style>
>>   h2, .h2 { font-size: 150% }
>> </style>
>> 
>> <body>
>> 
>>   <h2>Foo</h2>            
>> 
>>   <div class=h2>Bar</div> 
>> 
>>   <ol class=h2>           
>>     <li>Baz</li>          
>>   </ol>
>> 
>>   <table class=h2>
>>     <tr>
>>       <td>Qux</td>        
>>     </tr>
>>   </table>
>> 
>> </body>
>> 
>> **Expected behavior**
>> 
>> All text should be displayed with a font size of the computed `<body>` font-size ? 1.5.
>> 
>> [JDK-8257664]: https://bugs.openjdk.java.net/browse/JDK-8257664
>
> Stanimir Stamenkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixup! 8257664: Fix font-size inheritance with percentage values
>   
>   Declare fontSizeInherit() accessor private.

Marked as reviewed by psadhukhan (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Wed Jan 20 04:49:53 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 20 Jan 2021 04:49:53 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v5]
In-Reply-To: <KtNJr-UaLiyE6zrhWlDKHOBsLio8D7uKb1xZPIBAfPs=.bebb4f28-3d4b-47c8-adff-fc9d3fde3197@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <KG8PuSyeWLNrr-SURStOiAakLjBsGDmzSoeMXnBT5ks=.20e1acaa-2b4c-4d41-854c-df477a4b72ca@github.com>
 <FFRP_ZzLyjUFxWb859k1Oal4BuaafQ2UJn6ZWjrcBuM=.ff70782d-8c44-4d93-9782-a4e5d08a0ebe@github.com>
 <KtNJr-UaLiyE6zrhWlDKHOBsLio8D7uKb1xZPIBAfPs=.bebb4f28-3d4b-47c8-adff-fc9d3fde3197@github.com>
Message-ID: <E4BE3GZQGomH7NwjqIGS8096R2sbYiSkB8DC2rMpvjM=.7981ddb7-5875-4515-b970-7c9398961b1d@github.com>

On Mon, 18 Jan 2021 13:21:18 GMT, Stanimir Stamenkov <github.com+1247730+stanio at openjdk.org> wrote:

> 
> 
> The display dpi shouldn't matter. I've tried it in a couple of different monitor configurations: 1.25, 1.5, and 2.0 scaling. I've also tried it with non-dpi-aware Java 8. I've used `body { font-size: 14 }` which should always evaluate to `Font.size=14` (no matter the `w3cLengthUnits` value, for example) ? the other elements use relative to that base font-size.

OK. Good to know dpi factor is not affecting this usecase, but speaking of `w3cLengthUnits` value, it seems there is another JBS issue https://bugs.openjdk.java.net/browse/JDK-8231286 where "font-size" value with this w3cLengthUnits attribute set is affected by the hidpi factor, so was wondering
	if this fix will have any impact on that issue as well, but it seems it's not and need something more to be done. Anyway, this is good to go.

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

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

From psadhukhan at openjdk.java.net  Wed Jan 20 11:58:00 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 20 Jan 2021 11:58:00 GMT
Subject: <Swing Dev> RFR: 8260035: Deproblemlist few problemlisted test
Message-ID: <4rZCe2nLn47Y02BI7JNSuQSFsfj7ZK7ytsymrihoY48=.bc3879ee-bda4-4b4b-b577-3c3560d51832@github.com>

Few problemlisted test
javax/swing/plaf/basic/Test6984643.java
javax/swing/JMenuItem/6249972/bug6249972.java
javax/swing/JTree/6263446/bug6263446.java
were unstable in mach5 nightly testing. These can be deproblemlisted now with appropriate stability fixes. 
Mach5 jobs running for several iterations for all these tests in all platforms is ok. Link in JBS.

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

Commit messages:
 - 8260035: Deproblemlist few problemlisted test

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

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

From github.com+1247730+stanio at openjdk.java.net  Wed Jan 20 13:27:57 2021
From: github.com+1247730+stanio at openjdk.java.net (Stanimir Stamenkov)
Date: Wed, 20 Jan 2021 13:27:57 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v5]
In-Reply-To: <ZbcCzfn2QqzvSzCM-LeKtTIxFIJrUmt3J3_DI2oK9C8=.b9387e9e-4030-4806-87f7-bcc871fc7b7a@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <KG8PuSyeWLNrr-SURStOiAakLjBsGDmzSoeMXnBT5ks=.20e1acaa-2b4c-4d41-854c-df477a4b72ca@github.com>
 <ZbcCzfn2QqzvSzCM-LeKtTIxFIJrUmt3J3_DI2oK9C8=.b9387e9e-4030-4806-87f7-bcc871fc7b7a@github.com>
Message-ID: <wVZANac9ztFhZ7193n-adJKO-sWmMXIFx2Th0HoG8lY=.0808ef73-3ad3-4d8f-a693-b8f222f26049@github.com>

On Wed, 20 Jan 2021 04:47:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Stanimir Stamenkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixup! 8257664: Fix font-size inheritance with percentage values
>>   
>>   Declare fontSizeInherit() accessor private.
>
> Marked as reviewed by psadhukhan (Reviewer).

Thank you @prsadhuk for reviewing this.  Should/could I go with `/integrate` now?

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

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

From psadhukhan at openjdk.java.net  Wed Jan 20 13:27:58 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 20 Jan 2021 13:27:58 GMT
Subject: <Swing Dev> RFR: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes [v5]
In-Reply-To: <wVZANac9ztFhZ7193n-adJKO-sWmMXIFx2Th0HoG8lY=.0808ef73-3ad3-4d8f-a693-b8f222f26049@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
 <KG8PuSyeWLNrr-SURStOiAakLjBsGDmzSoeMXnBT5ks=.20e1acaa-2b4c-4d41-854c-df477a4b72ca@github.com>
 <ZbcCzfn2QqzvSzCM-LeKtTIxFIJrUmt3J3_DI2oK9C8=.b9387e9e-4030-4806-87f7-bcc871fc7b7a@github.com>
 <wVZANac9ztFhZ7193n-adJKO-sWmMXIFx2Th0HoG8lY=.0808ef73-3ad3-4d8f-a693-b8f222f26049@github.com>
Message-ID: <zMR_xhtqCSgWkFUyGJAJ807_TyBCXYGVbFyi4w75j6M=.00166f65-1339-440b-94db-82f799385b04@github.com>

On Wed, 20 Jan 2021 13:24:36 GMT, Stanimir Stamenkov <github.com+1247730+stanio at openjdk.org> wrote:

> 
> 
> Thank you @prsadhuk for reviewing this. Should/could I go with `/integrate` now?

yes sure

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

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

From github.com+1247730+stanio at openjdk.java.net  Wed Jan 20 13:39:00 2021
From: github.com+1247730+stanio at openjdk.java.net (Stanimir Stamenkov)
Date: Wed, 20 Jan 2021 13:39:00 GMT
Subject: <Swing Dev> Integrated: 8257664: HTMLEditorKit: Wrong CSS relative
 font sizes
In-Reply-To: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
References: <PSt-H5kmexUq65oWRZZ9FZgGwuAeQFJuilrRenrf2yI=.ecb963c4-4dfe-4e13-8ca7-39da9ff485df@github.com>
Message-ID: <yLJfnH7MHYm0OY_TzqHy8bYHTKsvhOfnSuCZOU-QeQ0=.eee2bbe8-3fd8-4a4b-a76d-8317c81546b3@github.com>

On Sun, 13 Dec 2020 14:51:47 GMT, Stanimir Stamenkov <github.com+1247730+stanio at openjdk.org> wrote:

> Fix for [JDK-8257664][] ? HTMLEditorKit: Wrong CSS relative font sizes.
> 
> _Disclaimer:_ I'm the reporter of the issue and I've been advised the best chance to get it addressed is to submit a pull request against this repository.  I haven't built the JDK myself, I'll need guidance if required.  I have a proof-of-concept example ? demonstrating the bug and a workaround available as a [public gist](https://gist.github.com/stanio/b79ce9348946aa6b3395328ec4c59d14).  I have included a sample test though I don't know if it is annotated properly.
> 
> **Current behavior**
> 
> <style>
>   h2, .h2 { font-size: 150% }
> </style>
> 
> <body>
> 
>   <h2>Foo</h2>            
> 
>   <div class=h2>Bar</div> 
> 
>   <ol class=h2>           
>     <li>Baz</li>          
>   </ol>
> 
>   <table class=h2>
>     <tr>
>       <td>Qux</td>        
>     </tr>
>   </table>
> 
> </body>
> 
> **Expected behavior**
> 
> All text should be displayed with a font size of the computed `<body>` font-size ? 1.5.
> 
> [JDK-8257664]: https://bugs.openjdk.java.net/browse/JDK-8257664

This pull request has now been integrated.

Changeset: 70b5b311
Author:    Stanimir Stamenkov <stanio at yahoo.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/70b5b311
Stats:     178 lines in 2 files changed: 178 ins; 0 del; 0 mod

8257664: HTMLEditorKit: Wrong CSS relative font sizes

Reviewed-by: aivanov, psadhukhan

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

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

From ljiang at openjdk.java.net  Wed Jan 20 14:01:48 2021
From: ljiang at openjdk.java.net (Leo Jiang)
Date: Wed, 20 Jan 2021 14:01:48 GMT
Subject: <Swing Dev> [jdk16] Integrated: JDK-8259732: JDK 16 L10n resource
 file update - msg drop 10
In-Reply-To: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
References: <rkW5Jag8UgaOwMqc-YOrjNy_HsmdGihHNUvdDQCzpmg=.c1379936-24ff-48d5-b3a6-7980c67174c5@github.com>
Message-ID: <PsjsxJ4kew4pjTts5SUpHNnJecCD6WeOjLF2KThGY6w=.e649b3eb-5863-4b6f-b557-5b7f1ae2471a@github.com>

On Thu, 14 Jan 2021 14:00:00 GMT, Leo Jiang <ljiang at openjdk.org> wrote:

> This is the changes for JDK 16 msg drop 10.

This pull request has now been integrated.

Changeset: 01205109
Author:    Leo Jiang <ljiang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/01205109
Stats:     215 lines in 30 files changed: 118 ins; 16 del; 81 mod

8259732: JDK 16 L10n resource file update - msg drop 10

Reviewed-by: naoto

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

PR: https://git.openjdk.java.net/jdk16/pull/123

From jwilhelm at openjdk.java.net  Thu Jan 21 04:41:15 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 21 Jan 2021 04:41:15 GMT
Subject: <Swing Dev> RFR: Merge jdk16
Message-ID: <NN4thzbqhjubg5TRbiID80k6v0JGR5OY0Dqgz1uGyAI=.814e8aac-06b7-4e64-8072-426e852e1998@github.com>

Forwardport JDK 16 -> JDK 17

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

Commit messages:
 - Merge
 - 8259757: add a regression test for 8259353 and 8259601
 - 8259732: JDK 16 L10n resource file update - msg drop 10

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2176&range=00.0
 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2176&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/2176/files
  Stats: 296 lines in 31 files changed: 200 ins; 16 del; 80 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2176.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2176/head:pull/2176

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

From jwilhelm at openjdk.java.net  Thu Jan 21 05:26:59 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 21 Jan 2021 05:26:59 GMT
Subject: <Swing Dev> Integrated: Merge jdk16
In-Reply-To: <NN4thzbqhjubg5TRbiID80k6v0JGR5OY0Dqgz1uGyAI=.814e8aac-06b7-4e64-8072-426e852e1998@github.com>
References: <NN4thzbqhjubg5TRbiID80k6v0JGR5OY0Dqgz1uGyAI=.814e8aac-06b7-4e64-8072-426e852e1998@github.com>
Message-ID: <9sHQ5RFKu7eMA2dnKWQ9ZWXPzT_HnSJdXDZ2j4kX8to=.69bf5258-7371-4404-a1af-b54febf7cad7@github.com>

On Thu, 21 Jan 2021 04:33:47 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: 133bcb09
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/133bcb09
Stats:     296 lines in 31 files changed: 200 ins; 16 del; 80 mod

Merge

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

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

From jdv at openjdk.java.net  Thu Jan 21 07:21:57 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 21 Jan 2021 07:21:57 GMT
Subject: <Swing Dev> RFR: 8260035: Deproblemlist few problemlisted test
In-Reply-To: <4rZCe2nLn47Y02BI7JNSuQSFsfj7ZK7ytsymrihoY48=.bc3879ee-bda4-4b4b-b577-3c3560d51832@github.com>
References: <4rZCe2nLn47Y02BI7JNSuQSFsfj7ZK7ytsymrihoY48=.bc3879ee-bda4-4b4b-b577-3c3560d51832@github.com>
Message-ID: <6oI4cnAONyOuxAmoPjp_rkZU5IsA7tQjwhElxBxrWK4=.84954094-f156-4d03-a496-9f6a5930b5d0@github.com>

On Wed, 20 Jan 2021 11:49:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few problemlisted test
> javax/swing/plaf/basic/Test6984643.java
> javax/swing/JMenuItem/6249972/bug6249972.java
> javax/swing/JTree/6263446/bug6263446.java
> were unstable in mach5 nightly testing. These can be deproblemlisted now with appropriate stability fixes. 
> Mach5 jobs running for several iterations for all these tests in all platforms is ok. Link in JBS.

Marked as reviewed by jdv (Reviewer).

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

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

From serb at openjdk.java.net  Thu Jan 21 07:42:57 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 21 Jan 2021 07:42:57 GMT
Subject: <Swing Dev> RFR: 8260035: Deproblemlist few problemlisted test
In-Reply-To: <6oI4cnAONyOuxAmoPjp_rkZU5IsA7tQjwhElxBxrWK4=.84954094-f156-4d03-a496-9f6a5930b5d0@github.com>
References: <4rZCe2nLn47Y02BI7JNSuQSFsfj7ZK7ytsymrihoY48=.bc3879ee-bda4-4b4b-b577-3c3560d51832@github.com>
 <6oI4cnAONyOuxAmoPjp_rkZU5IsA7tQjwhElxBxrWK4=.84954094-f156-4d03-a496-9f6a5930b5d0@github.com>
Message-ID: <3DjZv6sTdGVPfpA_0Pg0Or8gwarXxkHHbwrSdAfHpwk=.63294614-29f0-4a0f-94fb-ab970f57fb6a@github.com>

On Thu, 21 Jan 2021 07:19:10 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Few problemlisted test
>> javax/swing/plaf/basic/Test6984643.java
>> javax/swing/JMenuItem/6249972/bug6249972.java
>> javax/swing/JTree/6263446/bug6263446.java
>> were unstable in mach5 nightly testing. These can be deproblemlisted now with appropriate stability fixes. 
>> Mach5 jobs running for several iterations for all these tests in all platforms is ok. Link in JBS.
>
> Marked as reviewed by jdv (Reviewer).

Does the JDK-8198340 bug is a test issue?

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

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

From psadhukhan at openjdk.java.net  Thu Jan 21 07:45:55 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 21 Jan 2021 07:45:55 GMT
Subject: <Swing Dev> RFR: 8260035: Deproblemlist few problemlisted test
In-Reply-To: <3DjZv6sTdGVPfpA_0Pg0Or8gwarXxkHHbwrSdAfHpwk=.63294614-29f0-4a0f-94fb-ab970f57fb6a@github.com>
References: <4rZCe2nLn47Y02BI7JNSuQSFsfj7ZK7ytsymrihoY48=.bc3879ee-bda4-4b4b-b577-3c3560d51832@github.com>
 <6oI4cnAONyOuxAmoPjp_rkZU5IsA7tQjwhElxBxrWK4=.84954094-f156-4d03-a496-9f6a5930b5d0@github.com>
 <3DjZv6sTdGVPfpA_0Pg0Or8gwarXxkHHbwrSdAfHpwk=.63294614-29f0-4a0f-94fb-ab970f57fb6a@github.com>
Message-ID: <DLwqolzLFu8aWB1KQmXdGkiNk7HrtX6Tymw2sT6ynhA=.6105e822-5540-4d6f-8942-44cec3ac6403@github.com>

On Thu, 21 Jan 2021 07:39:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> 
> 
> Does the JDK-8198340 bug is a test issue?

Could be...It shows 
Caused by: java.lang.IllegalStateException: Shutdown in progress
which I think could be caused by invokeLater so that test tried to do the execution when the main is actually finishing.

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

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

From psadhukhan at openjdk.java.net  Thu Jan 21 08:30:57 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 21 Jan 2021 08:30:57 GMT
Subject: <Swing Dev> Integrated: 8260035: Deproblemlist few problemlisted
 test
In-Reply-To: <4rZCe2nLn47Y02BI7JNSuQSFsfj7ZK7ytsymrihoY48=.bc3879ee-bda4-4b4b-b577-3c3560d51832@github.com>
References: <4rZCe2nLn47Y02BI7JNSuQSFsfj7ZK7ytsymrihoY48=.bc3879ee-bda4-4b4b-b577-3c3560d51832@github.com>
Message-ID: <OzSMFuDjmeM6bV4JT2uO6fyfoNqt6GHy7zyV_XyNDO4=.13beb809-b383-4ff5-8fe3-5a57fd27b987@github.com>

On Wed, 20 Jan 2021 11:49:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few problemlisted test
> javax/swing/plaf/basic/Test6984643.java
> javax/swing/JMenuItem/6249972/bug6249972.java
> javax/swing/JTree/6263446/bug6263446.java
> were unstable in mach5 nightly testing. These can be deproblemlisted now with appropriate stability fixes. 
> Mach5 jobs running for several iterations for all these tests in all platforms is ok. Link in JBS.

This pull request has now been integrated.

Changeset: 7f7166db
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7f7166db
Stats:     114 lines in 4 files changed: 29 ins; 9 del; 76 mod

8260035: Deproblemlist few problemlisted test

Reviewed-by: jdv

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

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

From prr at openjdk.java.net  Thu Jan 21 15:58:35 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 21 Jan 2021 15:58:35 GMT
Subject: <Swing Dev> RFR: 8259869: [macOS] Remove desktop module
 dependencies on JNF Reference APIs
In-Reply-To: <BdKXgBEjuo8QIlIOWbz04oa9qor_eHxiFFGjihFlWXo=.b14dc0cd-8d4d-4219-aad1-f1a6b89c8b27@github.com>
References: <D2p15HR3Un60LWe1Z_AQWgaKYiNx6XXL3j2EFpu-BCk=.b73c3c14-1bce-4837-8c06-771416fd83c2@github.com>
 <BdKXgBEjuo8QIlIOWbz04oa9qor_eHxiFFGjihFlWXo=.b14dc0cd-8d4d-4219-aad1-f1a6b89c8b27@github.com>
Message-ID: <2LpmfCGqLhdLNlvFIrgycqOOgQi2cJx0OZk6E15zgBE=.26f9fe00-bf88-42b1-b61e-5efc693d9bc7@github.com>

On Wed, 20 Jan 2021 06:02:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This removes desktop module usage of the JNF JNI reference convenience APIs
>> These are simply a direct conversion
>> JNFNewGlobalRef 
>> JNFDeleteGlobalRef 
>> JNFNewWeakGlobalRef 
>> JNFDeleteWeakGlobalRef 
>> 
>> These two
>> JNFJObjectWrapper 
>> JNFWeakJObjectWrapper 
>> exist to allow clean up of the refs when a Cocoa wrapper object is released.
>> However in all cases there are more direct ways to clean it up and in at least one usage
>> the existing code directly releases it with the comment that this is more efficient.
>> 
>> All our automated regression and JCK tests pass with this change.
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m line 1547:
> 
>> 1545:         AWTWindow *awtWindow = [AWTWindow getTopmostWindowUnderMouse];
>> 1546:         if (awtWindow != nil) {
>> 1547:             topmostWindowUnderMouse = awtWindow.javaPlatformWindow;
> 
> I wonder what type of "reference" we should return here, I do not remember how the "NewWeakGlobalRef" behave when returned to java.

It is no different than other cases. Java will get a new strong ref to the object
and expect it to be of the return type of this native method.

> src/java.desktop/macosx/native/libawt_lwawt/awt/CDragSourceContextPeer.m line 58:
> 
>> 56:     jobject gTriggerEvent = (*env)->NewGlobalRef(env, jtrigger);
>> 57:     jlongArray gFormats = (*env)->NewGlobalRef(env, jformats);
>> 58:     jobject gFormatMap = (*env)->NewGlobalRef(env, jformatmap);
> 
> All above should be checked for NULL since OOM may occur, but it looks like it does not throw OOM?
> https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html#NewGlobalRef

It is the case that per even the latest spec. none of these throw any exception.
https://docs.oracle.com/en/java/javase/15/docs/specs/jni/functions.html#newglobalref
So I think the existing code doesn't do anything in the event of a NULL return.
And if you want to check for NULL here and return NULL from the native method there's semantic implications that require the caller never pass NULL for any of these.
It is not illegal to pass NULL to NewGlobalRef.
Investigating and confirming that is beyond the scope of this change.
Or we make the code a bit more complex here and check that we get back non-null for a non-null arg. But once again nothing new here.

> src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.h line 55:
> 
>> 53: @property (nonatomic, retain) NSWindow *nsWindow;
>> 54: 
>> 55: @property (nonatomic) jobject javaPlatformWindow;
> 
> I think it will be useful to have a comment here that this value is a weak reference and should be copied to the local ref before usage.

I suppose I can add a comment ... but it is already done in the couple of dozen usages so any one adding a new usage who misses that will likely miss the comment too.

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

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

From prr at openjdk.java.net  Thu Jan 21 16:28:19 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 21 Jan 2021 16:28:19 GMT
Subject: <Swing Dev> RFR: 8259869: [macOS] Remove desktop module
 dependencies on JNF Reference APIs [v2]
In-Reply-To: <D2p15HR3Un60LWe1Z_AQWgaKYiNx6XXL3j2EFpu-BCk=.b73c3c14-1bce-4837-8c06-771416fd83c2@github.com>
References: <D2p15HR3Un60LWe1Z_AQWgaKYiNx6XXL3j2EFpu-BCk=.b73c3c14-1bce-4837-8c06-771416fd83c2@github.com>
Message-ID: <AfQYxLuSbpCkD2FiXE4QsmxFoNL5Pknz8RHHC3UynNU=.2dfe6a9b-1c37-41cb-b505-0cf816366b27@github.com>

> This removes desktop module usage of the JNF JNI reference convenience APIs
> These are simply a direct conversion
> JNFNewGlobalRef 
> JNFDeleteGlobalRef 
> JNFNewWeakGlobalRef 
> JNFDeleteWeakGlobalRef 
> 
> These two
> JNFJObjectWrapper 
> JNFWeakJObjectWrapper 
> exist to allow clean up of the refs when a Cocoa wrapper object is released.
> However in all cases there are more direct ways to clean it up and in at least one usage
> the existing code directly releases it with the comment that this is more efficient.
> 
> All our automated regression and JCK tests pass with this change.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8259869: [macOS] Remove desktop module dependencies on JNF Reference APIs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2133/files
  - new: https://git.openjdk.java.net/jdk/pull/2133/files/61d6476b..6a9e7a0d

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

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

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

From serb at openjdk.java.net  Fri Jan 22 01:22:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Jan 2021 01:22:10 GMT
Subject: <Swing Dev> RFR: 8259869: [macOS] Remove desktop module
 dependencies on JNF Reference APIs [v2]
In-Reply-To: <AfQYxLuSbpCkD2FiXE4QsmxFoNL5Pknz8RHHC3UynNU=.2dfe6a9b-1c37-41cb-b505-0cf816366b27@github.com>
References: <D2p15HR3Un60LWe1Z_AQWgaKYiNx6XXL3j2EFpu-BCk=.b73c3c14-1bce-4837-8c06-771416fd83c2@github.com>
 <AfQYxLuSbpCkD2FiXE4QsmxFoNL5Pknz8RHHC3UynNU=.2dfe6a9b-1c37-41cb-b505-0cf816366b27@github.com>
Message-ID: <JLeqiWR-nCpZeVhOB9-VGVkhXxXiJt5cftHwIbW2law=.572d5124-843e-476b-bb7d-703c01243072@github.com>

On Thu, 21 Jan 2021 16:28:19 GMT, Phil Race <prr at openjdk.org> wrote:

>> This removes desktop module usage of the JNF JNI reference convenience APIs
>> These are simply a direct conversion
>> JNFNewGlobalRef 
>> JNFDeleteGlobalRef 
>> JNFNewWeakGlobalRef 
>> JNFDeleteWeakGlobalRef 
>> 
>> These two
>> JNFJObjectWrapper 
>> JNFWeakJObjectWrapper 
>> exist to allow clean up of the refs when a Cocoa wrapper object is released.
>> However in all cases there are more direct ways to clean it up and in at least one usage
>> the existing code directly releases it with the comment that this is more efficient.
>> 
>> All our automated regression and JCK tests pass with this change.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8259869: [macOS] Remove desktop module dependencies on JNF Reference APIs

Marked as reviewed by serb (Reviewer).

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

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

From prr at openjdk.java.net  Fri Jan 22 01:55:58 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 22 Jan 2021 01:55:58 GMT
Subject: <Swing Dev> Integrated: 8259869: [macOS] Remove desktop module
 dependencies on JNF Reference APIs
In-Reply-To: <D2p15HR3Un60LWe1Z_AQWgaKYiNx6XXL3j2EFpu-BCk=.b73c3c14-1bce-4837-8c06-771416fd83c2@github.com>
References: <D2p15HR3Un60LWe1Z_AQWgaKYiNx6XXL3j2EFpu-BCk=.b73c3c14-1bce-4837-8c06-771416fd83c2@github.com>
Message-ID: <FfX-lFywRZFbBKISx9Lsyrl7hKiUfL_yVAeW53vJzSk=.89301b4d-5671-484e-a9a5-a6004b4885d4@github.com>

On Mon, 18 Jan 2021 16:08:37 GMT, Phil Race <prr at openjdk.org> wrote:

> This removes desktop module usage of the JNF JNI reference convenience APIs
> These are simply a direct conversion
> JNFNewGlobalRef 
> JNFDeleteGlobalRef 
> JNFNewWeakGlobalRef 
> JNFDeleteWeakGlobalRef 
> 
> These two
> JNFJObjectWrapper 
> JNFWeakJObjectWrapper 
> exist to allow clean up of the refs when a Cocoa wrapper object is released.
> However in all cases there are more direct ways to clean it up and in at least one usage
> the existing code directly releases it with the comment that this is more efficient.
> 
> All our automated regression and JCK tests pass with this change.

This pull request has now been integrated.

Changeset: 92c2f084
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/92c2f084
Stats:     153 lines in 21 files changed: 19 ins; 7 del; 127 mod

8259869: [macOS] Remove desktop module dependencies on JNF Reference APIs

Reviewed-by: serb

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

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

From psadhukhan at openjdk.java.net  Fri Jan 22 07:27:55 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 22 Jan 2021 07:27:55 GMT
Subject: <Swing Dev> RFR: 8164484: Unity, JTable cell editor,
 javax/swing/JComboBox/6559152/bug6559152.java
Message-ID: <3TceOEHg5ssPawNPnKBN1ih8hEiepbvhOJhKJJyjgLI=.34e7bf6f-7f66-4533-b686-b8de42cd0aa8@github.com>

This test was problemlisted for linux as it fails only on ubuntu18.04 in mach5 nightly testing. It was infact passing on ubuntu19.10, 20.04 and 20.10 so it was test specific issue. Made appropriate stability fix by adding waitForIdle() at appropriate location.
Mach5 job running specifically on ubuntu18.04 and all other platforms is ok. Link in JBS.

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

Commit messages:
 - 8164484: Unity, JTable cell editor, javax/swing/JComboBox/6559152/bug6559152.java

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

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

From serb at openjdk.java.net  Fri Jan 22 07:45:50 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Jan 2021 07:45:50 GMT
Subject: <Swing Dev> RFR: 8164484: Unity, JTable cell editor,
 javax/swing/JComboBox/6559152/bug6559152.java
In-Reply-To: <3TceOEHg5ssPawNPnKBN1ih8hEiepbvhOJhKJJyjgLI=.34e7bf6f-7f66-4533-b686-b8de42cd0aa8@github.com>
References: <3TceOEHg5ssPawNPnKBN1ih8hEiepbvhOJhKJJyjgLI=.34e7bf6f-7f66-4533-b686-b8de42cd0aa8@github.com>
Message-ID: <htZxVVmNnQvg3Uw-Lk5UbFFx3Sb8zCM0v5TEFcrkDr0=.c370dae2-0089-41de-b0eb-a8f19348d62d@github.com>

On Fri, 22 Jan 2021 07:23:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test was problemlisted for linux as it fails only on ubuntu18.04 in mach5 nightly testing. It was infact passing on ubuntu19.10, 20.04 and 20.10 so it was test specific issue. Made appropriate stability fix by adding waitForIdle() at appropriate location.
> Mach5 job running specifically on ubuntu18.04 and all other platforms is ok. Link in JBS.

Marked as reviewed by serb (Reviewer).

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

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

From jdv at openjdk.java.net  Fri Jan 22 08:02:53 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Fri, 22 Jan 2021 08:02:53 GMT
Subject: <Swing Dev> RFR: 8164484: Unity, JTable cell editor,
 javax/swing/JComboBox/6559152/bug6559152.java
In-Reply-To: <3TceOEHg5ssPawNPnKBN1ih8hEiepbvhOJhKJJyjgLI=.34e7bf6f-7f66-4533-b686-b8de42cd0aa8@github.com>
References: <3TceOEHg5ssPawNPnKBN1ih8hEiepbvhOJhKJJyjgLI=.34e7bf6f-7f66-4533-b686-b8de42cd0aa8@github.com>
Message-ID: <2AvQHUZOvTSMqUo8teW22Ckq_3cHQgYBldyHI8lO14U=.92b3e18c-7e48-49b0-ba5f-7bb8458a33c2@github.com>

On Fri, 22 Jan 2021 07:23:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test was problemlisted for linux as it fails only on ubuntu18.04 in mach5 nightly testing. It was infact passing on ubuntu19.10, 20.04 and 20.10 so it was test specific issue. Made appropriate stability fix by adding waitForIdle() at appropriate location.
> Mach5 job running specifically on ubuntu18.04 and all other platforms is ok. Link in JBS.

Marked as reviewed by jdv (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Fri Jan 22 08:06:05 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 22 Jan 2021 08:06:05 GMT
Subject: <Swing Dev> Integrated: 8164484: Unity, JTable cell editor,
 javax/swing/JComboBox/6559152/bug6559152.java
In-Reply-To: <3TceOEHg5ssPawNPnKBN1ih8hEiepbvhOJhKJJyjgLI=.34e7bf6f-7f66-4533-b686-b8de42cd0aa8@github.com>
References: <3TceOEHg5ssPawNPnKBN1ih8hEiepbvhOJhKJJyjgLI=.34e7bf6f-7f66-4533-b686-b8de42cd0aa8@github.com>
Message-ID: <Jcawvg56ODwjeZNYnVaAnWagbZQrFny9iMyfLsfPffM=.f52b4202-86be-4015-a5d9-8f339a5f3b2d@github.com>

On Fri, 22 Jan 2021 07:23:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test was problemlisted for linux as it fails only on ubuntu18.04 in mach5 nightly testing. It was infact passing on ubuntu19.10, 20.04 and 20.10 so it was test specific issue. Made appropriate stability fix by adding waitForIdle() at appropriate location.
> Mach5 job running specifically on ubuntu18.04 and all other platforms is ok. Link in JBS.

This pull request has now been integrated.

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

8164484: Unity, JTable cell editor, javax/swing/JComboBox/6559152/bug6559152.java

Reviewed-by: serb, jdv

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

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

From aivanov at openjdk.java.net  Fri Jan 22 20:04:02 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 22 Jan 2021 20:04:02 GMT
Subject: <Swing Dev> RFR: 8240247: No longer need to wrap files with
 contentContainer
Message-ID: <MFwS33I1hyEjvrcgku75FpvmBqhBUZWrQN-vKuYxlis=.e8f6ff59-75a2-4a88-854b-771f6c286174@github.com>

[JDK-8231144](https://bugs.openjdk.java.net/browse/JDK-8231144) wrapped the contents of plain HTML documents into `<div class="contentContainer">` to apply the styles and add the margins around the content for a consistent look.

This is no longer necessary after [JDK-8239817](https://bugs.openjdk.java.net/browse/JDK-8239817) was fixed.

These documents looks fine without being wrapped. So this fix basically undoes changes under JDK-8231144 and removes the redundant `<div>` wrapper element.

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

Commit messages:
 - Remove contentContainer wrapper

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

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

From serb at openjdk.java.net  Fri Jan 22 20:14:41 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Jan 2021 20:14:41 GMT
Subject: <Swing Dev> RFR: 8240247: No longer need to wrap files with
 contentContainer
In-Reply-To: <MFwS33I1hyEjvrcgku75FpvmBqhBUZWrQN-vKuYxlis=.e8f6ff59-75a2-4a88-854b-771f6c286174@github.com>
References: <MFwS33I1hyEjvrcgku75FpvmBqhBUZWrQN-vKuYxlis=.e8f6ff59-75a2-4a88-854b-771f6c286174@github.com>
Message-ID: <OebNzkpRqT4MbTTQd4n4bAgMH6y5UwSyB3Z_rnFS5HY=.e5342598-aa26-4b97-8d6c-1760a0eb452a@github.com>

On Fri, 22 Jan 2021 19:50:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> [JDK-8231144](https://bugs.openjdk.java.net/browse/JDK-8231144) wrapped the contents of plain HTML documents into `<div class="contentContainer">` to apply the styles and add the margins around the content for a consistent look.
> 
> This is no longer necessary after [JDK-8239817](https://bugs.openjdk.java.net/browse/JDK-8239817) was fixed.
> 
> These documents looks fine without being wrapped. So this fix basically undoes changes under JDK-8231144 and removes the redundant `<div>` wrapper element.

Marked as reviewed by serb (Reviewer).

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

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

From aivanov at openjdk.java.net  Sat Jan 23 11:40:39 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Sat, 23 Jan 2021 11:40:39 GMT
Subject: <Swing Dev> Integrated: 8240247: No longer need to wrap files with
 contentContainer
In-Reply-To: <MFwS33I1hyEjvrcgku75FpvmBqhBUZWrQN-vKuYxlis=.e8f6ff59-75a2-4a88-854b-771f6c286174@github.com>
References: <MFwS33I1hyEjvrcgku75FpvmBqhBUZWrQN-vKuYxlis=.e8f6ff59-75a2-4a88-854b-771f6c286174@github.com>
Message-ID: <os42JCT7FvcBC4zyHuQ76264EZkfn7-bqKwnIabRhRU=.0920c1cb-01c2-4c38-ab3c-3ba0d4b01c82@github.com>

On Fri, 22 Jan 2021 19:50:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> [JDK-8231144](https://bugs.openjdk.java.net/browse/JDK-8231144) wrapped the contents of plain HTML documents into `<div class="contentContainer">` to apply the styles and add the margins around the content for a consistent look.
> 
> This is no longer necessary after [JDK-8239817](https://bugs.openjdk.java.net/browse/JDK-8239817) was fixed.
> 
> These documents looks fine without being wrapped. So this fix basically undoes changes under JDK-8231144 and removes the redundant `<div>` wrapper element.

This pull request has now been integrated.

Changeset: f624dba6
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f624dba6
Stats:     45 lines in 15 files changed: 0 ins; 30 del; 15 mod

8240247: No longer need to wrap files with contentContainer

Reviewed-by: serb

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

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

From aivanov at openjdk.java.net  Sat Jan 23 19:10:46 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Sat, 23 Jan 2021 19:10:46 GMT
Subject: <Swing Dev> RFR: 8260314: Replace border="1" on tables with CSS
Message-ID: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>

Replace presentational attribute `border="1"` on `<table>` element with CSS styles:
table {border: outset 1px}
th, td {border: inset 1px} 

These declarations produce the same rendering as the default one in Firefox and Edge. 

Another option is to use `solid` in both cases.

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

Commit messages:
 - Move table styles to common <style> block
 - 8260314: Replace border="1" on tables with CSS

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

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

From serb at openjdk.java.net  Mon Jan 25 07:27:45 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 25 Jan 2021 07:27:45 GMT
Subject: <Swing Dev> RFR: 8260343: Delete obsolete classes in the Windows L&F
Message-ID: <5TYicN2UEIJLgiU-fiwlUAKsMEjf9EW7Gvn9XWeHvPI=.492b2d30-10ad-4e3d-9912-e2eccb97e908@github.com>

Obsolete/unused classes are removed.

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

Commit messages:
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/2216/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2216&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260343
  Stats: 151 lines in 3 files changed: 48 ins; 86 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2216.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2216/head:pull/2216

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

From pbansal at openjdk.java.net  Mon Jan 25 07:35:42 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 25 Jan 2021 07:35:42 GMT
Subject: <Swing Dev> RFR: 8260343: Delete obsolete classes in the
 Windows L&F
In-Reply-To: <5TYicN2UEIJLgiU-fiwlUAKsMEjf9EW7Gvn9XWeHvPI=.492b2d30-10ad-4e3d-9912-e2eccb97e908@github.com>
References: <5TYicN2UEIJLgiU-fiwlUAKsMEjf9EW7Gvn9XWeHvPI=.492b2d30-10ad-4e3d-9912-e2eccb97e908@github.com>
Message-ID: <AJmcYHB4Dl7sPp5mfj8ExW8VvcmfidzW9O-3mldkWh0=.98506c9e-7aff-4a91-b170-8bcdd075b845@github.com>

On Mon, 25 Jan 2021 07:08:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Obsolete/unused classes are removed.

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsButtonListener.java line 41:

> 39:     }
> 40:     /*
> 41:      This class is currently not used, but exists in case customers

Should not removing this public class need a CSR?

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

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

From psadhukhan at openjdk.java.net  Mon Jan 25 08:12:44 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 25 Jan 2021 08:12:44 GMT
Subject: <Swing Dev> RFR: 8260343: Delete obsolete classes in the
 Windows L&F
In-Reply-To: <5TYicN2UEIJLgiU-fiwlUAKsMEjf9EW7Gvn9XWeHvPI=.492b2d30-10ad-4e3d-9912-e2eccb97e908@github.com>
References: <5TYicN2UEIJLgiU-fiwlUAKsMEjf9EW7Gvn9XWeHvPI=.492b2d30-10ad-4e3d-9912-e2eccb97e908@github.com>
Message-ID: <ec47xJfnuTfcVXvzaipXAjmIAC8g7GZCr0s-BCtFgtM=.d910de45-a0a9-4e2a-87d5-7557cabeedfe@github.com>

On Mon, 25 Jan 2021 07:08:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Obsolete/unused classes are removed.

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java line 529:

> 527:      * @deprecated As of Java 2 platform v1.4.
> 528:      */
> 529:     @Deprecated

Should we not mark it "forRemoval=true" before actually removing it?

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

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

From aivanov at openjdk.java.net  Mon Jan 25 11:52:40 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 25 Jan 2021 11:52:40 GMT
Subject: <Swing Dev> RFR: 8260314: Replace border="1" on tables with CSS
In-Reply-To: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
References: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
Message-ID: <YKhi4Zzu38p92cIBzy68kH9JZCRxNPvYE7yHshV-V5o=.91b1d2d6-b53e-4ae0-9c33-16fa1f8afc88@github.com>

On Sat, 23 Jan 2021 19:06:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replace presentational attribute `border="1"` on `<table>` element with CSS styles:
> table {border: outset 1px}
> th, td {border: inset 1px} 
> 
> These declarations produce the same rendering as the default one in Firefox and Edge. 
> 
> Another option is to use `solid` in both cases.

@jonathan-gibbons, what do you think?

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

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

From psadhukhan at openjdk.java.net  Mon Jan 25 12:17:46 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 25 Jan 2021 12:17:46 GMT
Subject: <Swing Dev> RFR: 8049700: Deprecate obsolete classes and
 methods in javax/swing/plaf/basic [v2]
In-Reply-To: <wiiczD0Ann83s0Xphrf_mKm_HsL8RwHKRtOqRE16AMY=.c003bd15-9779-40f9-b6a5-ec13e6549040@github.com>
References: <LcIvlc2HZGDo6ErOfqf_QZlwCpO2a7o2pPIDeaCb40E=.80fa98b5-728e-4198-a4fd-8d70e21302fc@github.com>
 <y3oqqpwrNBwm3msFEQzyThS0DiGor2HrFHWG8lJRVWw=.3c80f178-4bc5-4bb6-87ca-ddf20890e7a7@github.com>
 <wiiczD0Ann83s0Xphrf_mKm_HsL8RwHKRtOqRE16AMY=.c003bd15-9779-40f9-b6a5-ec13e6549040@github.com>
Message-ID: <j2wL44J-8wdzB-nth8P-wY8yZ8kh6uur49v8zF16ae4=.e5d32b98-9c9c-4367-9d78-f376b34811c6@github.com>

On Tue, 19 Jan 2021 14:31:03 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

> 
> 
> The methods intervalAdded(ListDataEvent e) ,intervalRemoved(ListDataEvent e) and lt(File a, File b) of javax/swing/plaf/basic/BasicDirectoryModel.java states that "Obsolete - not used" ( in the doc).
> 
> The BasicDirectoryModel uses similar methods like fireIntervalAdded, fireIntervalRemoved which calls AbstractListModel#fireIntervalAdded.
> But not sure that these are the alternate methods.Also dont see anything similar to lt(File a, File b).
> 
> The method createFloatingFrame in the BasicToolBarUI.java states that it is "No longer used" and also specifies to use BasicToolBarUI.createFloatingWindow(JToolBar).
> 
> The class MouseInputHandler in BasicMenuUI.java and classes PropertyChangeHandler, VSBChangeListener, HSBChangeListener, ViewportChangeHandler in BasicScrollPaneUI.java states that(as comments inside the class)
> "This class exists only for backward compatibility. All
> its functionality has been moved into Handler."
> we can add the above in the doc for these classes.

OK. Please add these statements in the doc, wherever possible.
Also, try to run all jtreg/jck tests with these classes/methods removed so that we dont get any surprises once they are removed.

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

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

From psadhukhan at openjdk.java.net  Mon Jan 25 13:28:56 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 25 Jan 2021 13:28:56 GMT
Subject: <Swing Dev> RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test
Message-ID: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>

This test was failing in our nightly mach5 testing. Appropriate stability code in form of waitForIdle and delay is added.
mach5 job running for several iterations on all platforms is ok. Link in JBS.

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

Commit messages:
 - 8197825: [Test] Intermiitent timeout with javax/swing JColorChooser Test

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

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

From trebari at openjdk.java.net  Mon Jan 25 13:56:40 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Mon, 25 Jan 2021 13:56:40 GMT
Subject: <Swing Dev> RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test
In-Reply-To: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
Message-ID: <J1cSKHUQzAFIVky0I_Oj3Y2FL-zHJeJQahNaRXlGbuI=.2687dbe9-020e-4df0-8ef7-499231369077@github.com>

On Mon, 25 Jan 2021 13:24:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test was failing in our nightly mach5 testing. Appropriate stability code in form of waitForIdle and delay is added.
> mach5 job running for several iterations on all platforms is ok. Link in JBS.

Marked as reviewed by trebari (Committer).

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

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

From aivanov at openjdk.java.net  Mon Jan 25 15:12:47 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 25 Jan 2021 15:12:47 GMT
Subject: <Swing Dev> RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test
In-Reply-To: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
Message-ID: <vYPIGrTTyov0IBGu9IjlWDlxPSjgPIqhMUuJeXiPB38=.f7d16e82-defa-4cb7-b897-9b0547cc5d04@github.com>

On Mon, 25 Jan 2021 13:24:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test was failing in our nightly mach5 testing. Appropriate stability code in form of waitForIdle and delay is added.
> mach5 job running for several iterations on all platforms is ok. Link in JBS.

Looks good to me.
Yet I suggest fixing the typo in the bug synopsis: Intermiitent ? Intermittent

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

Marked as reviewed by aivanov (Reviewer).

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

From github.com+7334069+mperktold at openjdk.java.net  Mon Jan 25 17:38:59 2021
From: github.com+7334069+mperktold at openjdk.java.net (Matthias Perktold)
Date: Mon, 25 Jan 2021 17:38:59 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with high-DPI
 scaling and W3C_UNIT_LENGTHS
Message-ID: <_roSs6ziF8cjPCIIM13zLtLxn8WyvqeieWWA5lt1jBk=.5edac143-998a-4ef4-8f9b-b1882d3cfc73@github.com>

@prsadhuk asked me to take over his pull request #1628, since I filed the bug an suggested this fix.

I thought the current behavior would be buggy, but actually the units are quite precise. I checked the size of a text in font-size of 1 in, and it really was approximately 1 inch. The problem is just that browsers behave differently.

Swing follows the CSS 2.1 spec: https://www.w3.org/TR/CSS21/syndata.html#length-units.
But in CSS 2.2, length units where redefined: https://www.w3.org/TR/CSS22/syndata.html#length-units.
Now `px` is also an absolute unit, and there are constant conversion factors between all absolute units.

The CSS 2.2 spec includes the following two notes regarding this change:

> Note that if the anchor unit is the pixel unit, the physical units might not match their physical measurements. Alternatively if the anchor unit is a physical unit, the pixel unit might not map to a whole number of device pixels.

> Note that this definition of the pixel unit and the physical units differs from previous versions of CSS. In particular, in previous versions of CSS the pixel unit and the physical units were not related by a fixed ratio: the physical units were always tied to their physical measurements while the pixel unit would vary to most closely match the reference pixel. (This change was made because too much existing content relies on the assumption of 96dpi, and breaking that assumption breaks the content.)

So the spec changed the behavior to better support high-DPI devices with existing content, and that is exactly my intention with this PR as well.

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

Commit messages:
 - Fixed jcheck
 - Removed unnecessary imports
 - Convert tabs to spaces
 - Fix JDK-8231286

Changes: https://git.openjdk.java.net/jdk/pull/2223/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2223&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8231286
  Stats: 114 lines in 3 files changed: 100 ins; 6 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2223.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2223/head:pull/2223

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

From serb at openjdk.java.net  Mon Jan 25 18:37:41 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 25 Jan 2021 18:37:41 GMT
Subject: <Swing Dev> RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test
In-Reply-To: <vYPIGrTTyov0IBGu9IjlWDlxPSjgPIqhMUuJeXiPB38=.f7d16e82-defa-4cb7-b897-9b0547cc5d04@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <vYPIGrTTyov0IBGu9IjlWDlxPSjgPIqhMUuJeXiPB38=.f7d16e82-defa-4cb7-b897-9b0547cc5d04@github.com>
Message-ID: <Kvlsx4f34GyiIErqtc4Rump92hWeA8OTvS7mIokNysM=.72553b0f-aee0-45c3-b58e-55d5acc98d2a@github.com>

On Mon, 25 Jan 2021 15:09:35 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This test was failing in our nightly mach5 testing. Appropriate stability code in form of waitForIdle and delay is added.
>> mach5 job running for several iterations on all platforms is ok. Link in JBS.
>
> Looks good to me.
> Yet I suggest fixing the typo in the bug synopsis: Intermiitent ? Intermittent

This bug looks like a product bug, infinite loop in the "Toolkit.shutdown", so it is better to fix the jdk than the test.

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

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

From serb at openjdk.java.net  Mon Jan 25 18:40:45 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 25 Jan 2021 18:40:45 GMT
Subject: <Swing Dev> RFR: 8260343: Delete obsolete classes in the
 Windows L&F
In-Reply-To: <AJmcYHB4Dl7sPp5mfj8ExW8VvcmfidzW9O-3mldkWh0=.98506c9e-7aff-4a91-b170-8bcdd075b845@github.com>
References: <5TYicN2UEIJLgiU-fiwlUAKsMEjf9EW7Gvn9XWeHvPI=.492b2d30-10ad-4e3d-9912-e2eccb97e908@github.com>
 <AJmcYHB4Dl7sPp5mfj8ExW8VvcmfidzW9O-3mldkWh0=.98506c9e-7aff-4a91-b170-8bcdd075b845@github.com>
Message-ID: <ddaMR4p9foB1n5juIPemVTlW4c3VxDYiTB2xtz7GFVw=.584265ab-6dbe-439b-973a-092d9552c60e@github.com>

On Mon, 25 Jan 2021 07:32:35 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> Obsolete/unused classes are removed.
>
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsButtonListener.java line 41:
> 
>> 39:     }
>> 40:     /*
>> 41:      This class is currently not used, but exists in case customers
> 
> Should not removing this public class need a CSR?

it is not needed, this is not a public API.

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

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

From serb at openjdk.java.net  Mon Jan 25 18:40:47 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 25 Jan 2021 18:40:47 GMT
Subject: <Swing Dev> RFR: 8260343: Delete obsolete classes in the
 Windows L&F
In-Reply-To: <ec47xJfnuTfcVXvzaipXAjmIAC8g7GZCr0s-BCtFgtM=.d910de45-a0a9-4e2a-87d5-7557cabeedfe@github.com>
References: <5TYicN2UEIJLgiU-fiwlUAKsMEjf9EW7Gvn9XWeHvPI=.492b2d30-10ad-4e3d-9912-e2eccb97e908@github.com>
 <ec47xJfnuTfcVXvzaipXAjmIAC8g7GZCr0s-BCtFgtM=.d910de45-a0a9-4e2a-87d5-7557cabeedfe@github.com>
Message-ID: <0-bOzI1wZEzyC1KGh51s5nePU8JeT70T0DIqqMPR550=.491b6c70-c4e7-46f8-8baa-f0aa0f5a561e@github.com>

On Mon, 25 Jan 2021 08:09:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Obsolete/unused classes are removed.
>
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java line 529:
> 
>> 527:      * @deprecated As of Java 2 platform v1.4.
>> 528:      */
>> 529:     @Deprecated
> 
> Should we not mark it "forRemoval=true" before actually removing it?

it is not needed, this is not a public API.

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

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

From aivanov at openjdk.java.net  Mon Jan 25 18:58:46 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 25 Jan 2021 18:58:46 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_UNIT_LENGTHS
In-Reply-To: <_roSs6ziF8cjPCIIM13zLtLxn8WyvqeieWWA5lt1jBk=.5edac143-998a-4ef4-8f9b-b1882d3cfc73@github.com>
References: <_roSs6ziF8cjPCIIM13zLtLxn8WyvqeieWWA5lt1jBk=.5edac143-998a-4ef4-8f9b-b1882d3cfc73@github.com>
Message-ID: <V4jnHk7FfsJGOgzE4_f-6QWCQdUIzCL-D30lsfy6QXg=.cf36cfd4-6dba-469c-a864-c850ace611e1@github.com>

On Mon, 25 Jan 2021 16:22:33 GMT, Matthias Perktold <github.com+7334069+mperktold at openjdk.org> wrote:

> @prsadhuk asked me to take over his pull request #1628, since I filed the bug an suggested this fix.
> 
> I thought the current behavior would be buggy, but actually the units are quite precise. I checked the size of a text in font-size of 1 in, and it really was approximately 1 inch. The problem is just that browsers behave differently.
> 
> Swing follows the CSS 2.1 spec: https://www.w3.org/TR/CSS21/syndata.html#length-units.
> But in CSS 2.2, length units where redefined: https://www.w3.org/TR/CSS22/syndata.html#length-units.
> Now `px` is also an absolute unit, and there are constant conversion factors between all absolute units.
> 
> The CSS 2.2 spec includes the following two notes regarding this change:
> 
>> Note that if the anchor unit is the pixel unit, the physical units might not match their physical measurements. Alternatively if the anchor unit is a physical unit, the pixel unit might not map to a whole number of device pixels.
> 
>> Note that this definition of the pixel unit and the physical units differs from previous versions of CSS. In particular, in previous versions of CSS the pixel unit and the physical units were not related by a fixed ratio: the physical units were always tied to their physical measurements while the pixel unit would vary to most closely match the reference pixel. (This change was made because too much existing content relies on the assumption of 96dpi, and breaking that assumption breaks the content.)
> 
> So the spec changed the behavior to better support high-DPI devices with existing content, and that is exactly my intention with this PR as well.

src/java.desktop/share/classes/javax/swing/JEditorPane.java line 1567:

> 1565:     /**
> 1566:      * Key for a client property used to indicate whether
> 1567:      * <a href="https://www.w3.org/TR/CSS22/syndata.html#length-units">

Does this change require a CSR?

test/jdk/javax/swing/text/html/HtmlFontSizeTest.java line 42:

> 40: 
> 41: public class HtmlFontSizeTest {
> 42:     static Rectangle w3cFrameSize, stdFrameSize;

These fields are accessed from two different threads. Shall they be declared as `volatile` then?
Declaring each field on its own line would follow the Java Code Conventions.

test/jdk/javax/swing/text/html/HtmlFontSizeTest.java line 92:

> 90:         System.out.println("frame height without W3C:" + stdFrameSize);
> 91: 
> 92:         float ratio = (float)w3cFrameSize.width/(float)stdFrameSize.width;

Spaces around / operator.
Java Code Conventions recommend ?casts should be followed by a blank,? however, it's not always followed.
Suggestion:

        float ratio = (float)w3cFrameSize.width / (float)stdFrameSize.width;

test/jdk/javax/swing/text/html/HtmlFontSizeTest.java line 96:

> 94: 
> 95:         String str = String.format("%.1g%n",ratio);
> 96:         if (str.compareTo(String.format("%.1g%n",1.3f)) != 0) {

?A comma should appear after commas in argument lists.?
Suggestion:

        String str = String.format("%.1g%n", ratio);
        if (str.compareTo(String.format("%.1g%n", 1.3f)) != 0) {

test/jdk/javax/swing/text/html/HtmlFontSizeTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.

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

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

From aivanov at openjdk.java.net  Mon Jan 25 19:05:42 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 25 Jan 2021 19:05:42 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_UNIT_LENGTHS
In-Reply-To: <_roSs6ziF8cjPCIIM13zLtLxn8WyvqeieWWA5lt1jBk=.5edac143-998a-4ef4-8f9b-b1882d3cfc73@github.com>
References: <_roSs6ziF8cjPCIIM13zLtLxn8WyvqeieWWA5lt1jBk=.5edac143-998a-4ef4-8f9b-b1882d3cfc73@github.com>
Message-ID: <GA7rjIkTGMf84joU-AeqXUzZ-Ucwxl6w70Vb7hgtAuE=.da42d7d5-c08a-44ad-8dfa-e75703f85960@github.com>

On Mon, 25 Jan 2021 16:22:33 GMT, Matthias Perktold <github.com+7334069+mperktold at openjdk.org> wrote:

> @prsadhuk asked me to take over his pull request #1628, since I filed the bug an suggested this fix.
> 
> I thought the current behavior would be buggy, but actually the units are quite precise. I checked the size of a text in font-size of 1 in, and it really was approximately 1 inch. The problem is just that browsers behave differently.
> 
> Swing follows the CSS 2.1 spec: https://www.w3.org/TR/CSS21/syndata.html#length-units.
> But in CSS 2.2, length units where redefined: https://www.w3.org/TR/CSS22/syndata.html#length-units.
> Now `px` is also an absolute unit, and there are constant conversion factors between all absolute units.
> 
> The CSS 2.2 spec includes the following two notes regarding this change:
> 
>> Note that if the anchor unit is the pixel unit, the physical units might not match their physical measurements. Alternatively if the anchor unit is a physical unit, the pixel unit might not map to a whole number of device pixels.
> 
>> Note that this definition of the pixel unit and the physical units differs from previous versions of CSS. In particular, in previous versions of CSS the pixel unit and the physical units were not related by a fixed ratio: the physical units were always tied to their physical measurements while the pixel unit would vary to most closely match the reference pixel. (This change was made because too much existing content relies on the assumption of 96dpi, and breaking that assumption breaks the content.)
> 
> So the spec changed the behavior to better support high-DPI devices with existing content, and that is exactly my intention with this PR as well.

The comment in the bug description says, the subject contains `W3C_UNIT_LENGTHS` instead of `W3C_LENGTH_UNITS`. Shall we edit the bug subject so that it contains the correct constant name?

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

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

From aivanov at openjdk.java.net  Mon Jan 25 19:06:44 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 25 Jan 2021 19:06:44 GMT
Subject: <Swing Dev> RFR: 8260343: Delete obsolete classes in the
 Windows L&F
In-Reply-To: <5TYicN2UEIJLgiU-fiwlUAKsMEjf9EW7Gvn9XWeHvPI=.492b2d30-10ad-4e3d-9912-e2eccb97e908@github.com>
References: <5TYicN2UEIJLgiU-fiwlUAKsMEjf9EW7Gvn9XWeHvPI=.492b2d30-10ad-4e3d-9912-e2eccb97e908@github.com>
Message-ID: <msF2qqsuziI9sfl0tg8tn8gTWenagPy52mDjZuIVwCc=.c17f8c88-f0ab-4ce7-bff2-b7b55a18ab35@github.com>

On Mon, 25 Jan 2021 07:08:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Obsolete/unused classes are removed.

Marked as reviewed by aivanov (Reviewer).

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

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

From serb at openjdk.java.net  Mon Jan 25 19:17:41 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 25 Jan 2021 19:17:41 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_UNIT_LENGTHS
In-Reply-To: <GA7rjIkTGMf84joU-AeqXUzZ-Ucwxl6w70Vb7hgtAuE=.da42d7d5-c08a-44ad-8dfa-e75703f85960@github.com>
References: <_roSs6ziF8cjPCIIM13zLtLxn8WyvqeieWWA5lt1jBk=.5edac143-998a-4ef4-8f9b-b1882d3cfc73@github.com>
 <GA7rjIkTGMf84joU-AeqXUzZ-Ucwxl6w70Vb7hgtAuE=.da42d7d5-c08a-44ad-8dfa-e75703f85960@github.com>
Message-ID: <6LwVSkAXZxS_tERxb0VZO2SggbiDGaLeqSl1yE-Zo8A=.40787e99-753d-419e-a34c-7b7e196564ac@github.com>

On Mon, 25 Jan 2021 19:03:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @prsadhuk asked me to take over his pull request #1628, since I filed the bug an suggested this fix.
>> 
>> I thought the current behavior would be buggy, but actually the units are quite precise. I checked the size of a text in font-size of 1 in, and it really was approximately 1 inch. The problem is just that browsers behave differently.
>> 
>> Swing follows the CSS 2.1 spec: https://www.w3.org/TR/CSS21/syndata.html#length-units.
>> But in CSS 2.2, length units where redefined: https://www.w3.org/TR/CSS22/syndata.html#length-units.
>> Now `px` is also an absolute unit, and there are constant conversion factors between all absolute units.
>> 
>> The CSS 2.2 spec includes the following two notes regarding this change:
>> 
>>> Note that if the anchor unit is the pixel unit, the physical units might not match their physical measurements. Alternatively if the anchor unit is a physical unit, the pixel unit might not map to a whole number of device pixels.
>> 
>>> Note that this definition of the pixel unit and the physical units differs from previous versions of CSS. In particular, in previous versions of CSS the pixel unit and the physical units were not related by a fixed ratio: the physical units were always tied to their physical measurements while the pixel unit would vary to most closely match the reference pixel. (This change was made because too much existing content relies on the assumption of 96dpi, and breaking that assumption breaks the content.)
>> 
>> So the spec changed the behavior to better support high-DPI devices with existing content, and that is exactly my intention with this PR as well.
>
> The comment in the bug description says, the subject contains `W3C_UNIT_LENGTHS` instead of `W3C_LENGTH_UNITS`. Shall we edit the bug subject so that it contains the correct constant name?

As of now, I did not check the change in the spec, just noted that the quoted text in the PR is the same for both links: CSS 2.1 and CSS 2.2.

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

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

From aivanov at openjdk.java.net  Mon Jan 25 19:23:42 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 25 Jan 2021 19:23:42 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_UNIT_LENGTHS
In-Reply-To: <6LwVSkAXZxS_tERxb0VZO2SggbiDGaLeqSl1yE-Zo8A=.40787e99-753d-419e-a34c-7b7e196564ac@github.com>
References: <_roSs6ziF8cjPCIIM13zLtLxn8WyvqeieWWA5lt1jBk=.5edac143-998a-4ef4-8f9b-b1882d3cfc73@github.com>
 <GA7rjIkTGMf84joU-AeqXUzZ-Ucwxl6w70Vb7hgtAuE=.da42d7d5-c08a-44ad-8dfa-e75703f85960@github.com>
 <6LwVSkAXZxS_tERxb0VZO2SggbiDGaLeqSl1yE-Zo8A=.40787e99-753d-419e-a34c-7b7e196564ac@github.com>
Message-ID: <0_yPrBKAdpbWSMG4A7TeoSYDTf2Va819zjiHBDUFLEM=.ea47acc5-431d-4701-b29f-dacf64ce9299@github.com>

On Mon, 25 Jan 2021 19:14:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As of now, I did not check the change in the spec, just noted that the quoted text in the PR is the same for both links: CSS 2.1 and CSS 2.2.

The text remains the same but the external link changes from CSS 2.1 to 2.2.
It probably does not change the spec; just updates the link to the more recent spec which Swing will follow after the fix.

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

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

From serb at openjdk.java.net  Tue Jan 26 01:37:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 26 Jan 2021 01:37:40 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_UNIT_LENGTHS
In-Reply-To: <0_yPrBKAdpbWSMG4A7TeoSYDTf2Va819zjiHBDUFLEM=.ea47acc5-431d-4701-b29f-dacf64ce9299@github.com>
References: <_roSs6ziF8cjPCIIM13zLtLxn8WyvqeieWWA5lt1jBk=.5edac143-998a-4ef4-8f9b-b1882d3cfc73@github.com>
 <GA7rjIkTGMf84joU-AeqXUzZ-Ucwxl6w70Vb7hgtAuE=.da42d7d5-c08a-44ad-8dfa-e75703f85960@github.com>
 <6LwVSkAXZxS_tERxb0VZO2SggbiDGaLeqSl1yE-Zo8A=.40787e99-753d-419e-a34c-7b7e196564ac@github.com>
 <0_yPrBKAdpbWSMG4A7TeoSYDTf2Va819zjiHBDUFLEM=.ea47acc5-431d-4701-b29f-dacf64ce9299@github.com>
Message-ID: <YoPBfOJWMiqpgjEG9IOBrFIqMto8hcobH9zIDVT3rYo=.9795d58e-63bb-4766-b3dc-277db836520d@github.com>

On Mon, 25 Jan 2021 19:21:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The text remains the same but the external link changes from CSS 2.1 to 2.2.
> It probably does not change the spec; just updates the link to the more recent spec which Swing will follow after the fix.

This is what I mean, the quoted text of the CSS spec is the same for both versions.

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

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

From serb at openjdk.java.net  Tue Jan 26 01:56:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 26 Jan 2021 01:56:40 GMT
Subject: <Swing Dev> RFR: 8260314: Replace border="1" on tables with CSS
In-Reply-To: <YKhi4Zzu38p92cIBzy68kH9JZCRxNPvYE7yHshV-V5o=.91b1d2d6-b53e-4ae0-9c33-16fa1f8afc88@github.com>
References: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
 <YKhi4Zzu38p92cIBzy68kH9JZCRxNPvYE7yHshV-V5o=.91b1d2d6-b53e-4ae0-9c33-16fa1f8afc88@github.com>
Message-ID: <aUTDefEe39WcMRteFMcjWsCBxrZoLmKcBB08UdN9YH8=.ec6f9042-e386-47e3-8153-600e4ed5c3e9@github.com>

On Mon, 25 Jan 2021 11:50:20 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Replace presentational attribute `border="1"` on `<table>` element with CSS styles:
>> table {border: outset 1px}
>> th, td {border: inset 1px} 
>> 
>> These declarations produce the same rendering as the default one in Firefox and Edge. 
>> 
>> Another option is to use `solid` in both cases.
>
> @jonathan-gibbons, what do you think?

Probably we can import the CSS used by the javadoc itself?

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

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

From pbansal at openjdk.java.net  Tue Jan 26 06:25:43 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 26 Jan 2021 06:25:43 GMT
Subject: <Swing Dev> RFR: 8260343: Delete obsolete classes in the
 Windows L&F
In-Reply-To: <5TYicN2UEIJLgiU-fiwlUAKsMEjf9EW7Gvn9XWeHvPI=.492b2d30-10ad-4e3d-9912-e2eccb97e908@github.com>
References: <5TYicN2UEIJLgiU-fiwlUAKsMEjf9EW7Gvn9XWeHvPI=.492b2d30-10ad-4e3d-9912-e2eccb97e908@github.com>
Message-ID: <IC0is74iUuw4eoi_USL6_7lKzAqk1QV__p_zlEZqhTo=.cf345fb5-a941-4a2a-b324-93a0496a4013@github.com>

On Mon, 25 Jan 2021 07:08:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Obsolete/unused classes are removed.

Marked as reviewed by pbansal (Reviewer).

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

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

From github.com+7334069+mperktold at openjdk.java.net  Tue Jan 26 07:53:40 2021
From: github.com+7334069+mperktold at openjdk.java.net (Matthias Perktold)
Date: Tue, 26 Jan 2021 07:53:40 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_UNIT_LENGTHS
In-Reply-To: <YoPBfOJWMiqpgjEG9IOBrFIqMto8hcobH9zIDVT3rYo=.9795d58e-63bb-4766-b3dc-277db836520d@github.com>
References: <_roSs6ziF8cjPCIIM13zLtLxn8WyvqeieWWA5lt1jBk=.5edac143-998a-4ef4-8f9b-b1882d3cfc73@github.com>
 <GA7rjIkTGMf84joU-AeqXUzZ-Ucwxl6w70Vb7hgtAuE=.da42d7d5-c08a-44ad-8dfa-e75703f85960@github.com>
 <6LwVSkAXZxS_tERxb0VZO2SggbiDGaLeqSl1yE-Zo8A=.40787e99-753d-419e-a34c-7b7e196564ac@github.com>
 <0_yPrBKAdpbWSMG4A7TeoSYDTf2Va819zjiHBDUFLEM=.ea47acc5-431d-4701-b29f-dacf64ce9299@github.com>
 <YoPBfOJWMiqpgjEG9IOBrFIqMto8hcobH9zIDVT3rYo=.9795d58e-63bb-4766-b3dc-277db836520d@github.com>
Message-ID: <EQlFeLUzR-_bTgpZJYbJAGdSASUmgDv8pi5nEL04-GE=.f2cf8ad5-c6bc-4188-9fe6-6b1cf9625ff5@github.com>

On Tue, 26 Jan 2021 01:34:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is what I mean, the quoted text of the CSS spec is the same for both versions.

Oh right I misread that, I really thought it changed, but it didn't.
In that case I can also leave the link as it was, should I revert that change?

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

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

From aivanov at openjdk.java.net  Tue Jan 26 14:38:41 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 26 Jan 2021 14:38:41 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_UNIT_LENGTHS
In-Reply-To: <EQlFeLUzR-_bTgpZJYbJAGdSASUmgDv8pi5nEL04-GE=.f2cf8ad5-c6bc-4188-9fe6-6b1cf9625ff5@github.com>
References: <_roSs6ziF8cjPCIIM13zLtLxn8WyvqeieWWA5lt1jBk=.5edac143-998a-4ef4-8f9b-b1882d3cfc73@github.com>
 <GA7rjIkTGMf84joU-AeqXUzZ-Ucwxl6w70Vb7hgtAuE=.da42d7d5-c08a-44ad-8dfa-e75703f85960@github.com>
 <6LwVSkAXZxS_tERxb0VZO2SggbiDGaLeqSl1yE-Zo8A=.40787e99-753d-419e-a34c-7b7e196564ac@github.com>
 <0_yPrBKAdpbWSMG4A7TeoSYDTf2Va819zjiHBDUFLEM=.ea47acc5-431d-4701-b29f-dacf64ce9299@github.com>
 <YoPBfOJWMiqpgjEG9IOBrFIqMto8hcobH9zIDVT3rYo=.9795d58e-63bb-4766-b3dc-277db836520d@github.com>
 <EQlFeLUzR-_bTgpZJYbJAGdSASUmgDv8pi5nEL04-GE=.f2cf8ad5-c6bc-4188-9fe6-6b1cf9625ff5@github.com>
Message-ID: <OamZdihdBmoNtPYVNnFmUn3XyUit1dk9ifsbV7vUs8Q=.a127bf41-212c-4325-a2db-976d19c840cc@github.com>

On Tue, 26 Jan 2021 07:50:54 GMT, Matthias Perktold <github.com+7334069+mperktold at openjdk.org> wrote:

> > This is what I mean, the quoted text of the CSS spec is the same for both versions.
> 
> Oh right I misread that, I really thought it changed, but it didn't.
> In that case I can also leave the link as it was, should I revert that change?

I believe we're talking about javadoc spec: its text has not changed.
CSS spec is updated. Since you follow the rules of CSS 2.2, it's better to link to CSS 2.2.

So, the changes are good as they are. Do I get right, @mrserb?

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

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

From aivanov at openjdk.java.net  Tue Jan 26 15:42:42 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 26 Jan 2021 15:42:42 GMT
Subject: <Swing Dev> RFR: 8260314: Replace border="1" on tables with CSS
In-Reply-To: <aUTDefEe39WcMRteFMcjWsCBxrZoLmKcBB08UdN9YH8=.ec6f9042-e386-47e3-8153-600e4ed5c3e9@github.com>
References: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
 <YKhi4Zzu38p92cIBzy68kH9JZCRxNPvYE7yHshV-V5o=.91b1d2d6-b53e-4ae0-9c33-16fa1f8afc88@github.com>
 <aUTDefEe39WcMRteFMcjWsCBxrZoLmKcBB08UdN9YH8=.ec6f9042-e386-47e3-8153-600e4ed5c3e9@github.com>
Message-ID: <Trl0CXTObhupISF-aQFAmoUV6ARx_4ErgpfjPk2Fzq8=.a40a4a8f-a8e6-4996-bd71-b014d1aed178@github.com>

On Tue, 26 Jan 2021 01:54:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Probably we can import the CSS used by the javadoc itself?

We do. For example, [AWT Modality in JDK 15](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/doc-files/Modality.html) has borders because of `border="1"` attribute. If you remove it or change it to `border="1"` in Developer Tools in browser, the borders around cells disappear.

However, I looked into it further: there are tables in Javadoc comments. One example is [AWTKeyStroke constructor](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/AWTKeyStroke.html#%3Cinit%3E()) which uses `class="striped"`. In most cases, classes in java.desktop module use striped tables.

There's also `plain` class. I've found one usage of `class=plain"` in [NumericShaper class](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/font/NumericShaper.html). This style has collapsed borders around each cell. It looks similar to what we have now in ?plain? HTML documents, yet by default the borders are not collapsed, that is you see borders around each individual cell.

The stylesheet also declares `borderless` class which has no borders.

For the consistent look and feel of documentation, I think `striped` is the most appropriate class. However, I prefer `plain` class for `componentProperties.html` file.

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

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

From github.com+7334069+mperktold at openjdk.java.net  Tue Jan 26 15:58:48 2021
From: github.com+7334069+mperktold at openjdk.java.net (Matthias Perktold)
Date: Tue, 26 Jan 2021 15:58:48 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_UNIT_LENGTHS
In-Reply-To: <OamZdihdBmoNtPYVNnFmUn3XyUit1dk9ifsbV7vUs8Q=.a127bf41-212c-4325-a2db-976d19c840cc@github.com>
References: <_roSs6ziF8cjPCIIM13zLtLxn8WyvqeieWWA5lt1jBk=.5edac143-998a-4ef4-8f9b-b1882d3cfc73@github.com>
 <GA7rjIkTGMf84joU-AeqXUzZ-Ucwxl6w70Vb7hgtAuE=.da42d7d5-c08a-44ad-8dfa-e75703f85960@github.com>
 <6LwVSkAXZxS_tERxb0VZO2SggbiDGaLeqSl1yE-Zo8A=.40787e99-753d-419e-a34c-7b7e196564ac@github.com>
 <0_yPrBKAdpbWSMG4A7TeoSYDTf2Va819zjiHBDUFLEM=.ea47acc5-431d-4701-b29f-dacf64ce9299@github.com>
 <YoPBfOJWMiqpgjEG9IOBrFIqMto8hcobH9zIDVT3rYo=.9795d58e-63bb-4766-b3dc-277db836520d@github.com>
 <EQlFeLUzR-_bTgpZJYbJAGdSASUmgDv8pi5nEL04-GE=.f2cf8ad5-c6bc-4188-9fe6-6b1cf9625ff5@github.com>
 <OamZdihdBmoNtPYVNnFmUn3XyUit1dk9ifsbV7vUs8Q=.a127bf41-212c-4325-a2db-976d19c840cc@github.com>
Message-ID: <WqjXehYNK8EQhoHyDLwz47mL_HFPaChpZTEfxK8xrBk=.248c5c00-82c7-48da-b309-b9a9d3fefc4e@github.com>

On Tue, 26 Jan 2021 14:36:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> This is what I mean, the quoted text of the CSS spec is the same for both versions.
>> 
>> Oh right I misread that, I really thought it changed, but it didn't.
>> In that case I can also leave the link as it was, should I revert that change?
>
>> > This is what I mean, the quoted text of the CSS spec is the same for both versions.
>> 
>> Oh right I misread that, I really thought it changed, but it didn't.
>> In that case I can also leave the link as it was, should I revert that change?
> 
> I believe we're talking about javadoc spec: its text has not changed.
> CSS spec is updated. Since you follow the rules of CSS 2.2, it's better to link to CSS 2.2.
> 
> So, the changes are good as they are. Do I get right, @mrserb?

> 
> 
> ?? @mperktold a branch with the same name as the source branch for this pull request (`master`) is present in the [target repository](https://github.com/openjdk/jdk). If you eventually integrate this pull request then the branch `master` in your [personal fork](https://github.com/mperktold/jdk) will diverge once you sync your personal fork with the upstream repository.
> 
> To avoid this situation, create a new branch for your changes and reset the master branch. You can do this by running the following commands in a local repository for your personal fork. [...]

I am not sure whether I should still do this or not, since there is already some feedback, and I don't know what happens to that.
In particular, I didn't understand if this is just a suggestion or actually required.

@aivanov-jdk if it's not required, do you have any preferences?

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

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

From aivanov at openjdk.java.net  Tue Jan 26 16:44:40 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 26 Jan 2021 16:44:40 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_UNIT_LENGTHS
In-Reply-To: <WqjXehYNK8EQhoHyDLwz47mL_HFPaChpZTEfxK8xrBk=.248c5c00-82c7-48da-b309-b9a9d3fefc4e@github.com>
References: <_roSs6ziF8cjPCIIM13zLtLxn8WyvqeieWWA5lt1jBk=.5edac143-998a-4ef4-8f9b-b1882d3cfc73@github.com>
 <GA7rjIkTGMf84joU-AeqXUzZ-Ucwxl6w70Vb7hgtAuE=.da42d7d5-c08a-44ad-8dfa-e75703f85960@github.com>
 <6LwVSkAXZxS_tERxb0VZO2SggbiDGaLeqSl1yE-Zo8A=.40787e99-753d-419e-a34c-7b7e196564ac@github.com>
 <0_yPrBKAdpbWSMG4A7TeoSYDTf2Va819zjiHBDUFLEM=.ea47acc5-431d-4701-b29f-dacf64ce9299@github.com>
 <YoPBfOJWMiqpgjEG9IOBrFIqMto8hcobH9zIDVT3rYo=.9795d58e-63bb-4766-b3dc-277db836520d@github.com>
 <EQlFeLUzR-_bTgpZJYbJAGdSASUmgDv8pi5nEL04-GE=.f2cf8ad5-c6bc-4188-9fe6-6b1cf9625ff5@github.com>
 <OamZdihdBmoNtPYVNnFmUn3XyUit1dk9ifsbV7vUs8Q=.a127bf41-212c-4325-a2db-976d19c840cc@github.com>
 <WqjXehYNK8EQhoHyDLwz47mL_HFPaChpZTEfxK8xrBk=.248c5c00-82c7-48da-b309-b9a9d3fefc4e@github.com>
Message-ID: <N-LPaOGwCg-BDTO5cdyKu00XOUPVquiSGYywoMuju3I=.4e4e7ece-fec0-4b1f-9149-d9744751ae63@github.com>

On Tue, 26 Jan 2021 15:55:53 GMT, Matthias Perktold <github.com+7334069+mperktold at openjdk.org> wrote:

> > ?? @mperktold a branch with the same name as the source branch for this pull request (`master`) is present in the [target repository](https://github.com/openjdk/jdk). If you eventually integrate this pull request then the branch `master` in your [personal fork](https://github.com/mperktold/jdk) will diverge once you sync your personal fork with the upstream repository.
> > To avoid this situation, create a new branch for your changes and reset the master branch. You can do this by running the following commands in a local repository for your personal fork. [...]
> 
> I am not sure whether I should still do this or not, since there is already some feedback, and I don't know what happens to that.
> In particular, I didn't understand if this is just a suggestion or actually required.
> 
> @aivanov-jdk if it's not required, do you have any preferences?

I see you opened the PR from master branch in your personal fork rather than a new branch.

Yes, I think you should go on as suggested: create a new PR from a new branch.

You can create the new PR with comments addressed and link to the old PR in the description.

In addition to that, if I get it right, you, @mperktold, have taken over this issue from @prsadhuk, thus #1628 is superseded by this PR and should be closed without integration. Eventually, this PR will be superseded by a new PR that you'll create.

Can you edit the subject of the JBS issue to amend the constant `W3C_LENGTH_UNITS`?

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

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

From aivanov at openjdk.java.net  Tue Jan 26 17:26:56 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 26 Jan 2021 17:26:56 GMT
Subject: <Swing Dev> RFR: 8260314: Replace border="1" on tables with CSS
 [v2]
In-Reply-To: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
References: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
Message-ID: <IYM4buU_FjWSDBpUrojgyEL7N6qV1NbxswKLu87B8xw=.a32211d6-fb92-4e10-bbb9-e7b8315fd890@github.com>

> Replace presentational attribute `border="1"` on `<table>` element with CSS styles:
> table {border: outset 1px}
> th, td {border: inset 1px} 
> 
> These declarations produce the same rendering as the default one in Firefox and Edge. 
> 
> Another option is to use `solid` in both cases.

Alexey Ivanov has updated the pull request incrementally with two additional commits since the last revision:

 - Remove redundant center-align for <tr> element
 - Apply class="striped" to the tables

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2210/files
  - new: https://git.openjdk.java.net/jdk/pull/2210/files/eb057764..b6f95ed8

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

  Stats: 59 lines in 6 files changed: 0 ins; 24 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2210.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2210/head:pull/2210

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

From aivanov at openjdk.java.net  Tue Jan 26 17:32:54 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 26 Jan 2021 17:32:54 GMT
Subject: <Swing Dev> RFR: 8260314: Replace border="1" on tables with CSS
 [v3]
In-Reply-To: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
References: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
Message-ID: <jFvdBcb-LwcRK3b82mXIogE4tleQqKjdMhNqzVYcCVw=.b66a66a1-8cf6-4911-9353-1362f43e1509@github.com>

> Replace presentational attribute `border="1"` on `<table>` element with CSS styles:
> table {border: outset 1px}
> th, td {border: inset 1px} 
> 
> These declarations produce the same rendering as the default one in Firefox and Edge. 
> 
> Another option is to use `solid` in both cases.

Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Revert changes to style block in componentProperties.html

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2210/files
  - new: https://git.openjdk.java.net/jdk/pull/2210/files/b6f95ed8..9a7d1315

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

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

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

From github.com+7334069+mperktold at openjdk.java.net  Tue Jan 26 17:36:41 2021
From: github.com+7334069+mperktold at openjdk.java.net (Matthias Perktold)
Date: Tue, 26 Jan 2021 17:36:41 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_UNIT_LENGTHS
In-Reply-To: <N-LPaOGwCg-BDTO5cdyKu00XOUPVquiSGYywoMuju3I=.4e4e7ece-fec0-4b1f-9149-d9744751ae63@github.com>
References: <_roSs6ziF8cjPCIIM13zLtLxn8WyvqeieWWA5lt1jBk=.5edac143-998a-4ef4-8f9b-b1882d3cfc73@github.com>
 <GA7rjIkTGMf84joU-AeqXUzZ-Ucwxl6w70Vb7hgtAuE=.da42d7d5-c08a-44ad-8dfa-e75703f85960@github.com>
 <6LwVSkAXZxS_tERxb0VZO2SggbiDGaLeqSl1yE-Zo8A=.40787e99-753d-419e-a34c-7b7e196564ac@github.com>
 <0_yPrBKAdpbWSMG4A7TeoSYDTf2Va819zjiHBDUFLEM=.ea47acc5-431d-4701-b29f-dacf64ce9299@github.com>
 <YoPBfOJWMiqpgjEG9IOBrFIqMto8hcobH9zIDVT3rYo=.9795d58e-63bb-4766-b3dc-277db836520d@github.com>
 <EQlFeLUzR-_bTgpZJYbJAGdSASUmgDv8pi5nEL04-GE=.f2cf8ad5-c6bc-4188-9fe6-6b1cf9625ff5@github.com>
 <OamZdihdBmoNtPYVNnFmUn3XyUit1dk9ifsbV7vUs8Q=.a127bf41-212c-4325-a2db-976d19c840cc@github.com>
 <WqjXehYNK8EQhoHyDLwz47mL_HFPaChpZTEfxK8xrBk=.248c5c00-82c7-48da-b309-b9a9d3fefc4e@github.com>
 <N-LPaOGwCg-BDTO5cdyKu00XOUPVquiSGYywoMuju3I=.4e4e7ece-fec0-4b1f-9149-d9744751ae63@github.com>
Message-ID: <_a9SF6p5-zcBer4qkDKGtdZKj9JUkOPX3dXe5ve4SOQ=.21527809-e48c-460e-8bda-e462e5fba235@github.com>

On Tue, 26 Jan 2021 16:41:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I see you opened the PR from master branch in your personal fork rather than a new branch.
> 
> Yes, I think you should go on as suggested: create a new PR from a new branch.

OK, will do. If you don't mind, I have a couple of noob questions, as I'm new to the whole process:

> You can create the new PR with comments addressed and link to the old PR in the description.

Is there anything special I need to do to have "comments addressed"? Should I first apply your patches, and then proceed with the new fork afterwards?

> Can you edit the subject of the JBS issue to amend the constant W3C_LENGTH_UNITS?

I don't think I have the rights to do this. I don't even have an JBS account, I submitted the bug through the https://bugs.java.com/bugdatabase/. I just recently signed the OCA, is that sufficient to create a JBS account?

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

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

From serb at openjdk.java.net  Tue Jan 26 18:34:45 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 26 Jan 2021 18:34:45 GMT
Subject: <Swing Dev> Integrated: 8260343: Delete obsolete classes in the
 Windows L&F
In-Reply-To: <5TYicN2UEIJLgiU-fiwlUAKsMEjf9EW7Gvn9XWeHvPI=.492b2d30-10ad-4e3d-9912-e2eccb97e908@github.com>
References: <5TYicN2UEIJLgiU-fiwlUAKsMEjf9EW7Gvn9XWeHvPI=.492b2d30-10ad-4e3d-9912-e2eccb97e908@github.com>
Message-ID: <qWksutLM91XquiAgmxSf0dI3avnw6MXcs5vwuyvjlYc=.22ecec42-6af9-497a-b5bf-2f1e7815cfa5@github.com>

On Mon, 25 Jan 2021 07:08:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Obsolete/unused classes are removed.

This pull request has now been integrated.

Changeset: 42cef27f
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/42cef27f
Stats:     151 lines in 3 files changed: 48 ins; 86 del; 17 mod

8260343: Delete obsolete classes in the Windows L&F

Reviewed-by: aivanov, pbansal

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

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

From aivanov at openjdk.java.net  Tue Jan 26 18:36:40 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 26 Jan 2021 18:36:40 GMT
Subject: <Swing Dev> RFR: 8260314: Replace border="1" on tables with CSS
In-Reply-To: <Trl0CXTObhupISF-aQFAmoUV6ARx_4ErgpfjPk2Fzq8=.a40a4a8f-a8e6-4996-bd71-b014d1aed178@github.com>
References: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
 <YKhi4Zzu38p92cIBzy68kH9JZCRxNPvYE7yHshV-V5o=.91b1d2d6-b53e-4ae0-9c33-16fa1f8afc88@github.com>
 <aUTDefEe39WcMRteFMcjWsCBxrZoLmKcBB08UdN9YH8=.ec6f9042-e386-47e3-8153-600e4ed5c3e9@github.com>
 <Trl0CXTObhupISF-aQFAmoUV6ARx_4ErgpfjPk2Fzq8=.a40a4a8f-a8e6-4996-bd71-b014d1aed178@github.com>
Message-ID: <-a9q9HZa8vBMJc_T0Th_Q-rw2H-gm_sNj-Wz8s7hjsc=.c8791127-4eeb-40f7-b7f0-ad07b6af97ee@github.com>

On Tue, 26 Jan 2021 15:39:30 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Probably we can import the CSS used by the javadoc itself?
>
>> Probably we can import the CSS used by the javadoc itself?
> 
> We do. For example, [AWT Modality in JDK 15](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/doc-files/Modality.html) has borders because of `border="1"` attribute. If you remove it or change it to `border="1"` in Developer Tools in browser, the borders around cells disappear.
> 
> However, I looked into it further: there are tables in Javadoc comments. One example is [AWTKeyStroke constructor](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/AWTKeyStroke.html#%3Cinit%3E()) which uses `class="striped"`. In most cases, classes in java.desktop module use striped tables.
> 
> There's also `plain` class. I've found one usage of `class=plain"` in [NumericShaper class](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/font/NumericShaper.html). This style has collapsed borders around each cell. It looks similar to what we have now in ?plain? HTML documents, yet by default the borders are not collapsed, that is you see borders around each individual cell.
> 
> The stylesheet also declares `borderless` class which has no borders.
> 
> For the consistent look and feel of documentation, I think `striped` is the most appropriate class. However, I prefer `plain` class for `componentProperties.html` file.

I updated all the tables with `class="striped"`.

I've also uploaded the files with different styles for visual comparison:

### Current: JDK 15

- [DesktopProperties.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/doc-files/DesktopProperties.html)
- [Modality.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/doc-files/Modality.html)
- [gif_metadata.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/imageio/metadata/doc-files/gif_metadata.html)
- [tiff_metadata.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/imageio/metadata/doc-files/tiff_metadata.html)
- [componentProperties.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/plaf/synth/doc-files/componentProperties.html)
- [synthFileFormat.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/plaf/synth/doc-files/synthFileFormat.html)

### Manual: as suggested initially

- [DesktopProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/java/awt/doc-files/DesktopProperties.html)
- [Modality.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/java/awt/doc-files/Modality.html)
- [gif_metadata.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/javax/imageio/metadata/doc-files/gif_metadata.html)
- [tiff_metadata.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/javax/imageio/metadata/doc-files/tiff_metadata.html)
- [componentProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/javax/swing/plaf/synth/doc-files/componentProperties.html)
- [synthFileFormat.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/javax/swing/plaf/synth/doc-files/synthFileFormat.html)

### Striped: `class="striped"`

- [DesktopProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/java/awt/doc-files/DesktopProperties.html)
- [Modality.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/java/awt/doc-files/Modality.html)
- [gif_metadata.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/javax/imageio/metadata/doc-files/gif_metadata.html)
- [tiff_metadata.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/javax/imageio/metadata/doc-files/tiff_metadata.html)
- [componentProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/javax/swing/plaf/synth/doc-files/componentProperties.html)
- [synthFileFormat.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/javax/swing/plaf/synth/doc-files/synthFileFormat.html)

### Plain: `class="plain"`

- [DesktopProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v3-plain/api/java.desktop/java/awt/doc-files/DesktopProperties.html)
- [Modality.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v3-plain/api/java.desktop/java/awt/doc-files/Modality.html)
- [componentProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v3-plain/api/java.desktop/javax/swing/plaf/synth/doc-files/componentProperties.html)

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

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

From aivanov at openjdk.java.net  Tue Jan 26 18:56:40 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 26 Jan 2021 18:56:40 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_UNIT_LENGTHS
In-Reply-To: <_a9SF6p5-zcBer4qkDKGtdZKj9JUkOPX3dXe5ve4SOQ=.21527809-e48c-460e-8bda-e462e5fba235@github.com>
References: <_roSs6ziF8cjPCIIM13zLtLxn8WyvqeieWWA5lt1jBk=.5edac143-998a-4ef4-8f9b-b1882d3cfc73@github.com>
 <GA7rjIkTGMf84joU-AeqXUzZ-Ucwxl6w70Vb7hgtAuE=.da42d7d5-c08a-44ad-8dfa-e75703f85960@github.com>
 <6LwVSkAXZxS_tERxb0VZO2SggbiDGaLeqSl1yE-Zo8A=.40787e99-753d-419e-a34c-7b7e196564ac@github.com>
 <0_yPrBKAdpbWSMG4A7TeoSYDTf2Va819zjiHBDUFLEM=.ea47acc5-431d-4701-b29f-dacf64ce9299@github.com>
 <YoPBfOJWMiqpgjEG9IOBrFIqMto8hcobH9zIDVT3rYo=.9795d58e-63bb-4766-b3dc-277db836520d@github.com>
 <EQlFeLUzR-_bTgpZJYbJAGdSASUmgDv8pi5nEL04-GE=.f2cf8ad5-c6bc-4188-9fe6-6b1cf9625ff5@github.com>
 <OamZdihdBmoNtPYVNnFmUn3XyUit1dk9ifsbV7vUs8Q=.a127bf41-212c-4325-a2db-976d19c840cc@github.com>
 <WqjXehYNK8EQhoHyDLwz47mL_HFPaChpZTEfxK8xrBk=.248c5c00-82c7-48da-b309-b9a9d3fefc4e@github.com>
 <N-LPaOGwCg-BDTO5cdyKu00XOUPVquiSGYywoMuju3I=.4e4e7ece-fec0-4b1f-9149-d9744751ae63@github.com>
 <_a9SF6p5-zcBer4qkDKGtdZKj9JUkOPX3dXe5ve4SOQ=.21527809-e48c-460e-8bda-e462e5fba235@github.com>
Message-ID: <B7plpvS-PMC8Hm12Va-p71moNXWF51yj6En554BeeKA=.95b116e3-2e2d-4dcc-8970-f3e4fa9db3be@github.com>

On Tue, 26 Jan 2021 17:34:04 GMT, Matthias Perktold <github.com+7334069+mperktold at openjdk.org> wrote:

> > You can create the new PR with comments addressed and link to the old PR in the description.
> 
> Is there anything special I need to do to have "comments addressed"? Should I first apply your patches, and then proceed with the new fork afterwards?

Whatever you like. You can incorporate the fixes to comments in your initial commit to the new branch, or you can fix them after you create the new branch with your exiting changeset.


> > Can you edit the subject of the JBS issue to amend the constant W3C_LENGTH_UNITS?
> 
> I don't think I have the rights to do this. I don't even have an JBS account, I submitted the bug through the https://bugs.java.com/bugdatabase/. I just recently signed the OCA, is that sufficient to create a JBS account?

No, it is not sufficient.
I have amended the subject of the bug.

I wondered why I didn't see OCA request in the PR. You had gotten it before you created your first PR.

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

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

From philip.race at oracle.com  Tue Jan 26 19:05:15 2021
From: philip.race at oracle.com (Philip Race)
Date: Tue, 26 Jan 2021 11:05:15 -0800
Subject: <Swing Dev> Project Lanai (New Metal Java 2D Rendering pipeline for
 macOS) FINAL planned EA build has been released
Message-ID: <ef6ce471-1b0e-acb0-8a7d-95a8be82a278@oracle.com>

All,

The Lanai project has reached the stage where we are aiming to move the 
JEP [1]
to Proposed-To-Target [2] to JDK 17 very soon.

We have made one final planned EA release which includes all the latest 
fixes.

So please visit https://jdk.java.net/lanai/ and download the EA 9 build 
and test with your apps and hardware. and provide feedback via the 
lanai-dev at openjdk.java.net mailing list.

-phil.

[1] https://openjdk.java.net/jeps/382

[2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html


From jjg at openjdk.java.net  Tue Jan 26 19:19:39 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 26 Jan 2021 19:19:39 GMT
Subject: <Swing Dev> RFR: 8260314: Replace border="1" on tables with CSS
In-Reply-To: <-a9q9HZa8vBMJc_T0Th_Q-rw2H-gm_sNj-Wz8s7hjsc=.c8791127-4eeb-40f7-b7f0-ad07b6af97ee@github.com>
References: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
 <YKhi4Zzu38p92cIBzy68kH9JZCRxNPvYE7yHshV-V5o=.91b1d2d6-b53e-4ae0-9c33-16fa1f8afc88@github.com>
 <aUTDefEe39WcMRteFMcjWsCBxrZoLmKcBB08UdN9YH8=.ec6f9042-e386-47e3-8153-600e4ed5c3e9@github.com>
 <Trl0CXTObhupISF-aQFAmoUV6ARx_4ErgpfjPk2Fzq8=.a40a4a8f-a8e6-4996-bd71-b014d1aed178@github.com>
 <-a9q9HZa8vBMJc_T0Th_Q-rw2H-gm_sNj-Wz8s7hjsc=.c8791127-4eeb-40f7-b7f0-ad07b6af97ee@github.com>
Message-ID: <8iEqmKYzPqc_Y1A5rBHkR7_4rrFy-G__ruCFxIvFhf4=.116926f8-e276-4429-8c51-35aadfa017ae@github.com>

On Tue, 26 Jan 2021 18:33:48 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> Probably we can import the CSS used by the javadoc itself?
>> 
>> We do. For example, [AWT Modality in JDK 15](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/doc-files/Modality.html) has borders because of `border="1"` attribute. If you remove it or change it to `border="1"` in Developer Tools in browser, the borders around cells disappear.
>> 
>> However, I looked into it further: there are tables in Javadoc comments. One example is [AWTKeyStroke constructor](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/AWTKeyStroke.html#%3Cinit%3E()) which uses `class="striped"`. In most cases, classes in java.desktop module use striped tables.
>> 
>> There's also `plain` class. I've found one usage of `class=plain"` in [NumericShaper class](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/font/NumericShaper.html). This style has collapsed borders around each cell. It looks similar to what we have now in ?plain? HTML documents, yet by default the borders are not collapsed, that is you see borders around each individual cell.
>> 
>> The stylesheet also declares `borderless` class which has no borders.
>> 
>> For the consistent look and feel of documentation, I think `striped` is the most appropriate class. However, I prefer `plain` class for `componentProperties.html` file.
>
> I updated all the tables with `class="striped"`.
> 
> I've also uploaded the files with different styles for visual comparison:
> 
> ### Current: JDK 15
> 
> - [DesktopProperties.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/doc-files/DesktopProperties.html)
> - [Modality.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/doc-files/Modality.html)
> - [gif_metadata.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/imageio/metadata/doc-files/gif_metadata.html)
> - [tiff_metadata.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/imageio/metadata/doc-files/tiff_metadata.html)
> - [componentProperties.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/plaf/synth/doc-files/componentProperties.html)
> - [synthFileFormat.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/plaf/synth/doc-files/synthFileFormat.html)
> 
> ### Manual: as suggested initially
> 
> - [DesktopProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/java/awt/doc-files/DesktopProperties.html)
> - [Modality.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/java/awt/doc-files/Modality.html)
> - [gif_metadata.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/javax/imageio/metadata/doc-files/gif_metadata.html)
> - [tiff_metadata.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/javax/imageio/metadata/doc-files/tiff_metadata.html)
> - [componentProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/javax/swing/plaf/synth/doc-files/componentProperties.html)
> - [synthFileFormat.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/javax/swing/plaf/synth/doc-files/synthFileFormat.html)
> 
> ### Striped: `class="striped"`
> 
> - [DesktopProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/java/awt/doc-files/DesktopProperties.html)
> - [Modality.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/java/awt/doc-files/Modality.html)
> - [gif_metadata.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/javax/imageio/metadata/doc-files/gif_metadata.html)
> - [tiff_metadata.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/javax/imageio/metadata/doc-files/tiff_metadata.html)
> - [componentProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/javax/swing/plaf/synth/doc-files/componentProperties.html)
> - [synthFileFormat.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/javax/swing/plaf/synth/doc-files/synthFileFormat.html)
> 
> ### Plain: `class="plain"`
> 
> - [DesktopProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v3-plain/api/java.desktop/java/awt/doc-files/DesktopProperties.html)
> - [Modality.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v3-plain/api/java.desktop/java/awt/doc-files/Modality.html)
> - [componentProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v3-plain/api/java.desktop/javax/swing/plaf/synth/doc-files/componentProperties.html)

In general, I recommend where possible using the styles provided in the standard stylesheet, for overall visual consistency.

FYI, although it seems like the standard styles work for you in this case, if you should ever need it, javadoc now supports package-specific and module-specific stylesheets. Just put `*.css` files in the `doc-files` subdirectory or a package or module, and javadoc should pick it up and use it.

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

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

From aivanov at openjdk.java.net  Tue Jan 26 19:42:39 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 26 Jan 2021 19:42:39 GMT
Subject: <Swing Dev> RFR: 8260314: Replace border="1" on tables with CSS
In-Reply-To: <8iEqmKYzPqc_Y1A5rBHkR7_4rrFy-G__ruCFxIvFhf4=.116926f8-e276-4429-8c51-35aadfa017ae@github.com>
References: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
 <YKhi4Zzu38p92cIBzy68kH9JZCRxNPvYE7yHshV-V5o=.91b1d2d6-b53e-4ae0-9c33-16fa1f8afc88@github.com>
 <aUTDefEe39WcMRteFMcjWsCBxrZoLmKcBB08UdN9YH8=.ec6f9042-e386-47e3-8153-600e4ed5c3e9@github.com>
 <Trl0CXTObhupISF-aQFAmoUV6ARx_4ErgpfjPk2Fzq8=.a40a4a8f-a8e6-4996-bd71-b014d1aed178@github.com>
 <-a9q9HZa8vBMJc_T0Th_Q-rw2H-gm_sNj-Wz8s7hjsc=.c8791127-4eeb-40f7-b7f0-ad07b6af97ee@github.com>
 <8iEqmKYzPqc_Y1A5rBHkR7_4rrFy-G__ruCFxIvFhf4=.116926f8-e276-4429-8c51-35aadfa017ae@github.com>
Message-ID: <Jqo-_zfXyaISQ4mIiJVNW6d8AVx7Oiu4RcARjESLA88=.b9ef5259-6e63-4da7-8fbf-f4665021fe56@github.com>

On Tue, 26 Jan 2021 19:17:24 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> In general, I recommend where possible using the styles provided in the standard stylesheet, for overall visual consistency.

I totally agree.  I overlooked the standard styles for the tables. Thanks to @mrserb for pointing me in the right direction.

Since most tables in java.desktop use striped tables, it makes sense to use this style in these files too.

Although I had said I preferred `plain` class for `componentProperties.html`, I changed my opinion after looking at the updated file, it feels lighter when striped.

The table in `NumericShaper` has confusing rendering with `striped` class, that's why it uses `plain`.

> FYI, although it seems like the standard styles work for you in this case, if you should ever need it, javadoc now supports package-specific and module-specific stylesheets. Just put `*.css` files in the `doc-files` subdirectory or a package or module, and javadoc should pick it up and use it.

Thank you. It's good to know as it allows for keeping consistent look across files as opposed to applying style changes in individual files.

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

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

From serb at openjdk.java.net  Tue Jan 26 20:44:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 26 Jan 2021 20:44:40 GMT
Subject: <Swing Dev> RFR: 8260314: Replace border="1" on tables with CSS
 [v3]
In-Reply-To: <jFvdBcb-LwcRK3b82mXIogE4tleQqKjdMhNqzVYcCVw=.b66a66a1-8cf6-4911-9353-1362f43e1509@github.com>
References: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
 <jFvdBcb-LwcRK3b82mXIogE4tleQqKjdMhNqzVYcCVw=.b66a66a1-8cf6-4911-9353-1362f43e1509@github.com>
Message-ID: <YPpf5B9mPYkcqG-seo__zQm1vRk6PChZpmD2-5BnVt8=.e4e4908f-aaa6-4d74-b4f1-6133020ba8e8@github.com>

On Tue, 26 Jan 2021 17:32:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Replace presentational attribute `border="1"` on `<table>` element with CSS styles:
>> table {border: outset 1px}
>> th, td {border: inset 1px} 
>> 
>> These declarations produce the same rendering as the default one in Firefox and Edge. 
>> 
>> Another option is to use `solid` in both cases.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to style block in componentProperties.html

Marked as reviewed by serb (Reviewer).

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

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

From serb at openjdk.java.net  Tue Jan 26 20:49:41 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 26 Jan 2021 20:49:41 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_UNIT_LENGTHS
In-Reply-To: <OamZdihdBmoNtPYVNnFmUn3XyUit1dk9ifsbV7vUs8Q=.a127bf41-212c-4325-a2db-976d19c840cc@github.com>
References: <_roSs6ziF8cjPCIIM13zLtLxn8WyvqeieWWA5lt1jBk=.5edac143-998a-4ef4-8f9b-b1882d3cfc73@github.com>
 <GA7rjIkTGMf84joU-AeqXUzZ-Ucwxl6w70Vb7hgtAuE=.da42d7d5-c08a-44ad-8dfa-e75703f85960@github.com>
 <6LwVSkAXZxS_tERxb0VZO2SggbiDGaLeqSl1yE-Zo8A=.40787e99-753d-419e-a34c-7b7e196564ac@github.com>
 <0_yPrBKAdpbWSMG4A7TeoSYDTf2Va819zjiHBDUFLEM=.ea47acc5-431d-4701-b29f-dacf64ce9299@github.com>
 <YoPBfOJWMiqpgjEG9IOBrFIqMto8hcobH9zIDVT3rYo=.9795d58e-63bb-4766-b3dc-277db836520d@github.com>
 <EQlFeLUzR-_bTgpZJYbJAGdSASUmgDv8pi5nEL04-GE=.f2cf8ad5-c6bc-4188-9fe6-6b1cf9625ff5@github.com>
 <OamZdihdBmoNtPYVNnFmUn3XyUit1dk9ifsbV7vUs8Q=.a127bf41-212c-4325-a2db-976d19c840cc@github.com>
Message-ID: <YgNx_PP3ouTxsph1kL5r83hKMEqZ6B1B-nFD_ketHS4=.3258db47-b751-4f15-bbe9-89e48239aaa9@github.com>

On Tue, 26 Jan 2021 14:36:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I believe we're talking about javadoc spec: its text has not changed.
> CSS spec is updated. Since you follow the rules of CSS 2.2, it's better to link to CSS 2.2.

No, I did not mean the JavaDoc, my question was - "what part of the CSS spec was updated"?

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

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

From psadhukhan at openjdk.java.net  Wed Jan 27 07:03:42 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 27 Jan 2021 07:03:42 GMT
Subject: <Swing Dev> Withdrawn: 8231286: HTML font size too large with
 high-DPI scaling and W3C_UNIT_LENGTHS
In-Reply-To: <-jVAtf9GBLL4lTDyPsecYJ4kHnHj0ZK8bMEko5V4GLM=.9c04222b-ed0c-4d31-a159-0ca89661446b@github.com>
References: <-jVAtf9GBLL4lTDyPsecYJ4kHnHj0ZK8bMEko5V4GLM=.9c04222b-ed0c-4d31-a159-0ca89661446b@github.com>
Message-ID: <TCf19SmdW1jyrvfZZnsdRuHoVTziBFDKKvdr_NazgEU=.8206484b-130b-4cc0-9431-1b4a07294857@github.com>

On Fri, 4 Dec 2020 17:30:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is when using a JEditorPane to render HTML views with W3C_UNIT_LENGTHS enabled, font-sizes set using CSS are much larger than the same font size outside the HTML.
> It's because CSS LengthUnit uses screen resolution to calculate units so for hidpi screens, the html font size is bigger. 
> Fix is to calculate the units based on the CSS absolute length mentioned in https://drafts.csswg.org/css-values-3/#absolute-lengths so hidpi scaling is not applied twice in CSS and again by Java.

This pull request has been closed without being integrated.

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

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

From github.com+7334069+mperktold at openjdk.java.net  Wed Jan 27 10:15:58 2021
From: github.com+7334069+mperktold at openjdk.java.net (Matthias Perktold)
Date: Wed, 27 Jan 2021 10:15:58 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_UNIT_LENGTHS [v2]
In-Reply-To: <_roSs6ziF8cjPCIIM13zLtLxn8WyvqeieWWA5lt1jBk=.5edac143-998a-4ef4-8f9b-b1882d3cfc73@github.com>
References: <_roSs6ziF8cjPCIIM13zLtLxn8WyvqeieWWA5lt1jBk=.5edac143-998a-4ef4-8f9b-b1882d3cfc73@github.com>
Message-ID: <DxXjys_26o20_vPdwqI0r4_xPCv1_SmPHqc_vtJlmQs=.444657d7-a6a3-4466-b132-3b3ff36792d9@github.com>

> @prsadhuk asked me to take over his pull request #1628, since I filed the bug an suggested this fix.
> 
> I thought the current behavior would be buggy, but actually the units are quite precise. I checked the size of a text in font-size of 1 in, and it really was approximately 1 inch. The problem is just that browsers behave differently.
> 
> Swing follows the CSS 2.1 spec: https://www.w3.org/TR/CSS21/syndata.html#length-units.
> But in CSS 2.2, length units where redefined: https://www.w3.org/TR/CSS22/syndata.html#length-units.
> Now `px` is also an absolute unit, and there are constant conversion factors between all absolute units.
> 
> The CSS 2.2 spec includes the following two notes regarding this change:
> 
>> Note that if the anchor unit is the pixel unit, the physical units might not match their physical measurements. Alternatively if the anchor unit is a physical unit, the pixel unit might not map to a whole number of device pixels.
> 
>> Note that this definition of the pixel unit and the physical units differs from previous versions of CSS. In particular, in previous versions of CSS the pixel unit and the physical units were not related by a fixed ratio: the physical units were always tied to their physical measurements while the pixel unit would vary to most closely match the reference pixel. (This change was made because too much existing content relies on the assumption of 96dpi, and breaking that assumption breaks the content.)
> 
> So the spec changed the behavior to better support high-DPI devices with existing content, and that is exactly my intention with this PR as well.

Matthias Perktold has updated the pull request incrementally with two additional commits since the last revision:

 - Space after comma in argument lists
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Spaces around / operator
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2223/files
  - new: https://git.openjdk.java.net/jdk/pull/2223/files/7c29cfa6..7b4e87e8

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

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

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

From psadhukhan at openjdk.java.net  Wed Jan 27 10:15:58 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 27 Jan 2021 10:15:58 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_UNIT_LENGTHS
In-Reply-To: <_a9SF6p5-zcBer4qkDKGtdZKj9JUkOPX3dXe5ve4SOQ=.21527809-e48c-460e-8bda-e462e5fba235@github.com>
References: <_roSs6ziF8cjPCIIM13zLtLxn8WyvqeieWWA5lt1jBk=.5edac143-998a-4ef4-8f9b-b1882d3cfc73@github.com>
 <GA7rjIkTGMf84joU-AeqXUzZ-Ucwxl6w70Vb7hgtAuE=.da42d7d5-c08a-44ad-8dfa-e75703f85960@github.com>
 <6LwVSkAXZxS_tERxb0VZO2SggbiDGaLeqSl1yE-Zo8A=.40787e99-753d-419e-a34c-7b7e196564ac@github.com>
 <0_yPrBKAdpbWSMG4A7TeoSYDTf2Va819zjiHBDUFLEM=.ea47acc5-431d-4701-b29f-dacf64ce9299@github.com>
 <YoPBfOJWMiqpgjEG9IOBrFIqMto8hcobH9zIDVT3rYo=.9795d58e-63bb-4766-b3dc-277db836520d@github.com>
 <EQlFeLUzR-_bTgpZJYbJAGdSASUmgDv8pi5nEL04-GE=.f2cf8ad5-c6bc-4188-9fe6-6b1cf9625ff5@github.com>
 <OamZdihdBmoNtPYVNnFmUn3XyUit1dk9ifsbV7vUs8Q=.a127bf41-212c-4325-a2db-976d19c840cc@github.com>
 <WqjXehYNK8EQhoHyDLwz47mL_HFPaChpZTEfxK8xrBk=.248c5c00-82c7-48da-b309-b9a9d3fefc4e@github.com>
 <N-LPaOGwCg-BDTO5cdyKu00XOUPVquiSGYywoMuju3I=.4e4e7ece-fec0-4b1f-9149-d9744751ae63@github.com>
 <_a9SF6p5-zcBer4qkDKGtdZKj9JUkOPX3dXe5ve4SOQ=.21527809-e48c-460e-8bda-e462e5fba235@github.com>
Message-ID: <y0_W9HSC9zOgGpQiVwlW6KVr6yUW9X8OoVdaZCaqLTw=.7cc4d474-17f0-41c1-a2e6-40a1968949a8@github.com>

On Tue, 26 Jan 2021 17:34:04 GMT, Matthias Perktold <github.com+7334069+mperktold at openjdk.org> wrote:

>>> > ?? @mperktold a branch with the same name as the source branch for this pull request (`master`) is present in the [target repository](https://github.com/openjdk/jdk). If you eventually integrate this pull request then the branch `master` in your [personal fork](https://github.com/mperktold/jdk) will diverge once you sync your personal fork with the upstream repository.
>>> > To avoid this situation, create a new branch for your changes and reset the master branch. You can do this by running the following commands in a local repository for your personal fork. [...]
>>> 
>>> I am not sure whether I should still do this or not, since there is already some feedback, and I don't know what happens to that.
>>> In particular, I didn't understand if this is just a suggestion or actually required.
>>> 
>>> @aivanov-jdk if it's not required, do you have any preferences?
>> 
>> I see you opened the PR from master branch in your personal fork rather than a new branch.
>> 
>> Yes, I think you should go on as suggested: create a new PR from a new branch.
>> 
>> You can create the new PR with comments addressed and link to the old PR in the description.
>> 
>> In addition to that, if I get it right, you, @mperktold, have taken over this issue from @prsadhuk, thus #1628 is superseded by this PR and should be closed without integration. Eventually, this PR will be superseded by a new PR that you'll create.
>> 
>> Can you edit the subject of the JBS issue to amend the constant `W3C_LENGTH_UNITS`?
>
>> I see you opened the PR from master branch in your personal fork rather than a new branch.
>> 
>> Yes, I think you should go on as suggested: create a new PR from a new branch.
> 
> OK, will do. If you don't mind, I have a couple of noob questions, as I'm new to the whole process:
> 
>> You can create the new PR with comments addressed and link to the old PR in the description.
> 
> Is there anything special I need to do to have "comments addressed"? Should I first apply your patches, and then proceed with the new fork afterwards?
> 
>> Can you edit the subject of the JBS issue to amend the constant W3C_LENGTH_UNITS?
> 
> I don't think I have the rights to do this. I don't even have an JBS account, I submitted the bug through the https://bugs.java.com/bugdatabase/. I just recently signed the OCA, is that sufficient to create a JBS account?

@mperktold I guess this PR needs to be closed since this is from master branch. Please create a new PR from your fix branch with this latest changeset. The review will continue on top of that.

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

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

From github.com+7334069+mperktold at openjdk.java.net  Wed Jan 27 10:38:07 2021
From: github.com+7334069+mperktold at openjdk.java.net (Matthias Perktold)
Date: Wed, 27 Jan 2021 10:38:07 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_UNIT_LENGTHS [v3]
In-Reply-To: <_roSs6ziF8cjPCIIM13zLtLxn8WyvqeieWWA5lt1jBk=.5edac143-998a-4ef4-8f9b-b1882d3cfc73@github.com>
References: <_roSs6ziF8cjPCIIM13zLtLxn8WyvqeieWWA5lt1jBk=.5edac143-998a-4ef4-8f9b-b1882d3cfc73@github.com>
Message-ID: <mwcOhQg0eAmlpLA3Aertto7E74LGcFRhGjbdUlxlpNM=.676e961f-23e6-4c29-8f3d-b18ff1383cc2@github.com>

> @prsadhuk asked me to take over his pull request #1628, since I filed the bug an suggested this fix.
> 
> I thought the current behavior would be buggy, but actually the units are quite precise. I checked the size of a text in font-size of 1 in, and it really was approximately 1 inch. The problem is just that browsers behave differently.
> 
> Swing follows the CSS 2.1 spec: https://www.w3.org/TR/CSS21/syndata.html#length-units.
> But in CSS 2.2, length units where redefined: https://www.w3.org/TR/CSS22/syndata.html#length-units.
> Now `px` is also an absolute unit, and there are constant conversion factors between all absolute units.
> 
> The CSS 2.2 spec includes the following two notes regarding this change:
> 
>> Note that if the anchor unit is the pixel unit, the physical units might not match their physical measurements. Alternatively if the anchor unit is a physical unit, the pixel unit might not map to a whole number of device pixels.
> 
>> Note that this definition of the pixel unit and the physical units differs from previous versions of CSS. In particular, in previous versions of CSS the pixel unit and the physical units were not related by a fixed ratio: the physical units were always tied to their physical measurements while the pixel unit would vary to most closely match the reference pixel. (This change was made because too much existing content relies on the assumption of 96dpi, and breaking that assumption breaks the content.)
> 
> So the spec changed the behavior to better support high-DPI devices with existing content, and that is exactly my intention with this PR as well.

Matthias Perktold has updated the pull request incrementally with one additional commit since the last revision:

  Corrected copyright year
  
  Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2223/files
  - new: https://git.openjdk.java.net/jdk/pull/2223/files/7b4e87e8..d10824f7

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

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

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

From aivanov at openjdk.java.net  Wed Jan 27 11:50:39 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 27 Jan 2021 11:50:39 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_UNIT_LENGTHS
In-Reply-To: <YgNx_PP3ouTxsph1kL5r83hKMEqZ6B1B-nFD_ketHS4=.3258db47-b751-4f15-bbe9-89e48239aaa9@github.com>
References: <_roSs6ziF8cjPCIIM13zLtLxn8WyvqeieWWA5lt1jBk=.5edac143-998a-4ef4-8f9b-b1882d3cfc73@github.com>
 <GA7rjIkTGMf84joU-AeqXUzZ-Ucwxl6w70Vb7hgtAuE=.da42d7d5-c08a-44ad-8dfa-e75703f85960@github.com>
 <6LwVSkAXZxS_tERxb0VZO2SggbiDGaLeqSl1yE-Zo8A=.40787e99-753d-419e-a34c-7b7e196564ac@github.com>
 <0_yPrBKAdpbWSMG4A7TeoSYDTf2Va819zjiHBDUFLEM=.ea47acc5-431d-4701-b29f-dacf64ce9299@github.com>
 <YoPBfOJWMiqpgjEG9IOBrFIqMto8hcobH9zIDVT3rYo=.9795d58e-63bb-4766-b3dc-277db836520d@github.com>
 <EQlFeLUzR-_bTgpZJYbJAGdSASUmgDv8pi5nEL04-GE=.f2cf8ad5-c6bc-4188-9fe6-6b1cf9625ff5@github.com>
 <OamZdihdBmoNtPYVNnFmUn3XyUit1dk9ifsbV7vUs8Q=.a127bf41-212c-4325-a2db-976d19c840cc@github.com>
 <YgNx_PP3ouTxsph1kL5r83hKMEqZ6B1B-nFD_ketHS4=.3258db47-b751-4f15-bbe9-89e48239aaa9@github.com>
Message-ID: <kXaFxSMy-NGqsQuQ-fYcIxusi7PpzpviycLVMyZRkJY=.ef04343c-1072-4c00-a1c1-d38d852eefa4@github.com>

On Tue, 26 Jan 2021 20:46:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I believe we're talking about javadoc spec: its text has not changed.
> > CSS spec is updated. Since you follow the rules of CSS 2.2, it's better to link to CSS 2.2.
> 
> No, I did not mean the JavaDoc, my question was - "what part of the CSS spec was updated"?

You're right. I looked closely at the text in CSS 2.1 and 2.2 and length definitions are the same. CSS 2.1 contains a warning that several sections have been updated. Yet this particular one seems to have remained the same.

Yet the fix is still required. Swing handles High DPI by scaling all UI therefore all length units factors should not depend on the screen resolution or print resolution, the changes in resolution are automatically handled by 2d transform.

However, changing the link to the CSS specification is optional. Shall we update it to the most recent one?

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

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

From aivanov at openjdk.java.net  Wed Jan 27 12:12:42 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 27 Jan 2021 12:12:42 GMT
Subject: <Swing Dev> Integrated: 8260314: Replace border="1" on tables with
 CSS
In-Reply-To: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
References: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
Message-ID: <7RcNV3W7jLLvISTygnpyRzuUXDr6ZoCw6pJf_Ywz-dg=.a80267b0-0333-4d91-a88d-f4b1660f8b64@github.com>

On Sat, 23 Jan 2021 19:06:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replace presentational attribute `border="1"` on `<table>` element with CSS styles:
> table {border: outset 1px}
> th, td {border: inset 1px} 
> 
> These declarations produce the same rendering as the default one in Firefox and Edge. 
> 
> Another option is to use `solid` in both cases.

This pull request has now been integrated.

Changeset: 7ed591cc
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7ed591cc
Stats:     36 lines in 6 files changed: 0 ins; 1 del; 35 mod

8260314: Replace border="1" on tables with CSS

Reviewed-by: serb

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

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

From github.com+7334069+mperktold at openjdk.java.net  Wed Jan 27 12:29:58 2021
From: github.com+7334069+mperktold at openjdk.java.net (Matthias Perktold)
Date: Wed, 27 Jan 2021 12:29:58 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with high-DPI
 scaling and W3C_LENGTH_UNITS
Message-ID: <qVnKDIsDXYHah8E6GcVLY--nlmHZgOmZrT-rl-PxFuw=.1565fb15-986b-4721-96dd-617c58ab7f6e@github.com>

This PR supersedes #2223.
The original PR was created from master, whereas this PR is created from a fresh branch.

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

Commit messages:
 - Make fields volatile since changed from other thread, and put them on separate lines
 - Corrected copyright year
 - Space after comma in argument lists
 - Spaces around / operator
 - Fixed jcheck
 - Removed unnecessary imports
 - Convert tabs to spaces
 - Fix JDK-8231286

Changes: https://git.openjdk.java.net/jdk/pull/2256/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2256&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8231286
  Stats: 115 lines in 3 files changed: 101 ins; 6 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2256.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2256/head:pull/2256

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

From aivanov at openjdk.java.net  Wed Jan 27 12:29:58 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 27 Jan 2021 12:29:58 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_LENGTH_UNITS
In-Reply-To: <qVnKDIsDXYHah8E6GcVLY--nlmHZgOmZrT-rl-PxFuw=.1565fb15-986b-4721-96dd-617c58ab7f6e@github.com>
References: <qVnKDIsDXYHah8E6GcVLY--nlmHZgOmZrT-rl-PxFuw=.1565fb15-986b-4721-96dd-617c58ab7f6e@github.com>
Message-ID: <ij72WkHLVEl9iJo3CvakizJ-d0SpLigi2ilLmHLnn04=.02c61517-cfd8-4ed5-b75c-a5145225b53e@github.com>

On Wed, 27 Jan 2021 11:40:10 GMT, Matthias Perktold <github.com+7334069+mperktold at openjdk.org> wrote:

> This PR supersedes #2223.
> The original PR was created from master, whereas this PR is created from a fresh branch.

You should edit the title of the PR to be the same as the subject of the bug in JBS:
8231286: HTML font size too large with high-DPI scaling and W3C_LENGTH_UNITS

Please also provide the additional information in the description from the PR #2223.

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

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

From psadhukhan at openjdk.java.net  Wed Jan 27 12:39:02 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 27 Jan 2021 12:39:02 GMT
Subject: <Swing Dev> RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v2]
In-Reply-To: <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
Message-ID: <SAuXiT6mTsmobACwj6F9j6T7-dCAqifISJtxOVhd6DQ=.9c45b782-144d-4f68-9e18-4beabf7bae90@github.com>

On Wed, 27 Jan 2021 12:35:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> This test was failing in our nightly mach5 testing. Appropriate stability code in form of waitForIdle and delay is added.
>> mach5 job running for several iterations on all platforms is ok. Link in JBS.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prevent infinite loop

src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp line 2611:

> 2609:         Sleep(100);
> 2610:     }
> 2611: 

It can cause infinite looping as the message queue to get DISPOSE events is removed so if we are not getting disposed by now, we probably will not get DISPOSE event ever causing infinite loop.
XToolkit, LWToolkit does not have this infinite loop.

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

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

From psadhukhan at openjdk.java.net  Wed Jan 27 12:39:01 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 27 Jan 2021 12:39:01 GMT
Subject: <Swing Dev> RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v2]
In-Reply-To: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
Message-ID: <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>

> This test was failing in our nightly mach5 testing. Appropriate stability code in form of waitForIdle and delay is added.
> mach5 job running for several iterations on all platforms is ok. Link in JBS.

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

  Prevent infinite loop

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2220/files
  - new: https://git.openjdk.java.net/jdk/pull/2220/files/3db928b1..87d371ad

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

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

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

From psadhukhan at openjdk.java.net  Wed Jan 27 12:45:40 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 27 Jan 2021 12:45:40 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_LENGTH_UNITS
In-Reply-To: <qVnKDIsDXYHah8E6GcVLY--nlmHZgOmZrT-rl-PxFuw=.1565fb15-986b-4721-96dd-617c58ab7f6e@github.com>
References: <qVnKDIsDXYHah8E6GcVLY--nlmHZgOmZrT-rl-PxFuw=.1565fb15-986b-4721-96dd-617c58ab7f6e@github.com>
Message-ID: <WJen4AcAiUOf9Z9i9LHvI6uQ-MlncRmaHTsY_xtKreE=.357eadd7-741c-402c-8269-d3eda0106346@github.com>

On Wed, 27 Jan 2021 11:40:10 GMT, Matthias Perktold <github.com+7334069+mperktold at openjdk.org> wrote:

> This PR supersedes #2223.
> The original PR was created from master, whereas this PR is created from a fresh branch.
> 
> Below is a copy of the original description, but as @mrserb correctly [pointed out](https://github.com/openjdk/jdk/pull/2223#issuecomment-767048399), there is actually no relevant change from CSS 2.1 to CSS 2.2, so I <strike>striked out</strike> that part.
> 
> ### Original Description
> 
> @prsadhuk asked me to take over his pull request #1628, since I filed the bug an suggested this fix.
> 
> I thought the current behavior would be buggy, but actually the units are quite precise. I checked the size of a text in font-size of 1 in, and it really was approximately 1 inch. The problem is just that browsers behave differently.
> 
> <strike>
> Swing follows the CSS 2.1 spec: https://www.w3.org/TR/CSS21/syndata.html#length-units.
> But in CSS 2.2, length units where redefined: https://www.w3.org/TR/CSS22/syndata.html#length-units.
> Now px is also an absolute unit, and there are constant conversion factors between all absolute units.
> 
> The CSS 2.2 spec includes the following two notes regarding this change:
> 
>     Note that if the anchor unit is the pixel unit, the physical units might not match their physical measurements. Alternatively if the anchor unit is a physical unit, the pixel unit might not map to a whole number of device pixels.
> 
>     Note that this definition of the pixel unit and the physical units differs from previous versions of CSS. In particular, in previous versions of CSS the pixel unit and the physical units were not related by a fixed ratio: the physical units were always tied to their physical measurements while the pixel unit would vary to most closely match the reference pixel. (This change was made because too much existing content relies on the assumption of 96dpi, and breaking that assumption breaks the content.)
> 
> So the spec changed the behavior to better support high-DPI devices with existing content, and that is exactly my intention with this PR as well.
> </strike>

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2864:

> 2862:             lengthMapping.put("pc", 12f);
> 2863:             lengthMapping.put("in", 72f);
> 2864:             // mapping according to the CSS2.2 spec

Should we not put the latest CSS link here in addition/instead of in JEditorPane?

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

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

From aivanov at openjdk.java.net  Wed Jan 27 22:33:43 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 27 Jan 2021 22:33:43 GMT
Subject: <Swing Dev> RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v2]
In-Reply-To: <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
Message-ID: <oY4NqtBD3uXqXd8KqACmktMv1dJp6244-XgTCTODdAo=.1885ce9e-588e-4d85-838f-13e27e200d2a@github.com>

On Wed, 27 Jan 2021 12:39:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> This test was failing in our nightly mach5 testing. Appropriate stability code in form of waitForIdle and delay is added.
>> mach5 job running for several iterations on all platforms is ok. Link in JBS.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prevent infinite loop

test/jdk/javax/swing/JColorChooser/Test6827032.java line 78:

> 76:         } finally {
> 77:             if (frame != null) {
> 78:                 SwingUtilities.invokeAndWait(() -> frame.dispose());

Shall the frame be `volatile` too? It's accessed from main thread for the null-check.

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

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

From serb at openjdk.java.net  Thu Jan 28 00:43:42 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Jan 2021 00:43:42 GMT
Subject: <Swing Dev> RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v2]
In-Reply-To: <SAuXiT6mTsmobACwj6F9j6T7-dCAqifISJtxOVhd6DQ=.9c45b782-144d-4f68-9e18-4beabf7bae90@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
 <SAuXiT6mTsmobACwj6F9j6T7-dCAqifISJtxOVhd6DQ=.9c45b782-144d-4f68-9e18-4beabf7bae90@github.com>
Message-ID: <HadOE0oL2cGzuSQ_F1s7Lx_uVy9srbVKZwuU78ZBeo0=.6025e1f8-3d77-4f4d-856f-c8ebf559f6c0@github.com>

On Wed, 27 Jan 2021 12:35:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Prevent infinite loop
>
> src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp line 2611:
> 
>> 2609:         Sleep(100);
>> 2610:     }
>> 2611: 
> 
> It can cause infinite looping as the message queue to get DISPOSE events is removed so if we are not getting disposed by now, we probably will not get DISPOSE event ever causing infinite loop.
> XToolkit, LWToolkit does not have this infinite loop.

My point is that this is not a test bug, so the test should not be changed.

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

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

From psadhukhan at openjdk.java.net  Thu Jan 28 05:17:55 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 28 Jan 2021 05:17:55 GMT
Subject: <Swing Dev> RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v3]
In-Reply-To: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
Message-ID: <zgUUjbxUyXbNB9ob84MBBP21qqdha_Y32bPLBhxR3H8=.e56376fb-0155-402c-82ed-c60804322d29@github.com>

> This test was failing in our nightly mach5 testing. Appropriate stability code in form of waitForIdle and delay is added.
> mach5 job running for several iterations on all platforms is ok. Link in JBS.

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

  Test changes reverted

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2220/files
  - new: https://git.openjdk.java.net/jdk/pull/2220/files/87d371ad..6fdcc0d7

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

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

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

From serb at openjdk.java.net  Thu Jan 28 05:55:45 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Jan 2021 05:55:45 GMT
Subject: <Swing Dev> RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v3]
In-Reply-To: <HadOE0oL2cGzuSQ_F1s7Lx_uVy9srbVKZwuU78ZBeo0=.6025e1f8-3d77-4f4d-856f-c8ebf559f6c0@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
 <SAuXiT6mTsmobACwj6F9j6T7-dCAqifISJtxOVhd6DQ=.9c45b782-144d-4f68-9e18-4beabf7bae90@github.com>
 <HadOE0oL2cGzuSQ_F1s7Lx_uVy9srbVKZwuU78ZBeo0=.6025e1f8-3d77-4f4d-856f-c8ebf559f6c0@github.com>
Message-ID: <0bcS5tGMNFwilc6DdEXG6iGJgG9Jjqh7OcayzCaohzI=.54f0bdad-8804-43c1-a282-3949bcb1f575@github.com>

On Thu, 28 Jan 2021 00:41:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp line 2611:
>> 
>>> 2609:         Sleep(100);
>>> 2610:     }
>>> 2611: 
>> 
>> It can cause infinite looping as the message queue to get DISPOSE events is removed so if we are not getting disposed by now, we probably will not get DISPOSE event ever causing infinite loop.
>> XToolkit, LWToolkit does not have this infinite loop.
>
> My point is that this is not a test bug, so the test should not be changed.

Please take a look at the "AwtToolkit::Dispose()" method, on how much stuff should be done to properly shutdown the toolkit. This Dispose() method is executed immediately when we exit the message loop in the "Java_sun_awt_windows_WToolkit_eventLoop". So when the shutdown hook is executed we should have the message loop, then we call tk.QuitMessageLoop to stop it, and wait until all code in the Dispose() is executed. But since the IsDisposed() return false we for unknow reason hang, does it mean that the message loop still operates? Or we got some error during "QuitMessageLoop"?

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

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

From psadhukhan at openjdk.java.net  Thu Jan 28 10:01:42 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 28 Jan 2021 10:01:42 GMT
Subject: <Swing Dev> RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v3]
In-Reply-To: <0bcS5tGMNFwilc6DdEXG6iGJgG9Jjqh7OcayzCaohzI=.54f0bdad-8804-43c1-a282-3949bcb1f575@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
 <SAuXiT6mTsmobACwj6F9j6T7-dCAqifISJtxOVhd6DQ=.9c45b782-144d-4f68-9e18-4beabf7bae90@github.com>
 <HadOE0oL2cGzuSQ_F1s7Lx_uVy9srbVKZwuU78ZBeo0=.6025e1f8-3d77-4f4d-856f-c8ebf559f6c0@github.com>
 <0bcS5tGMNFwilc6DdEXG6iGJgG9Jjqh7OcayzCaohzI=.54f0bdad-8804-43c1-a282-3949bcb1f575@github.com>
Message-ID: <kMLumQiQftTjXvrvwZDG0xbDaxsmb98l36qxCAxl02M=.32d40e3d-fa1b-48d5-828b-2e10ef91b9b2@github.com>

On Thu, 28 Jan 2021 05:53:05 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> My point is that this is not a test bug, so the test should not be changed.
>
> Please take a look at the "AwtToolkit::Dispose()" method, on how much stuff should be done to properly shutdown the toolkit. This Dispose() method is executed immediately when we exit the message loop in the "Java_sun_awt_windows_WToolkit_eventLoop". So when the shutdown hook is executed we should have the message loop, then we call tk.QuitMessageLoop to stop it, and wait until all code in the Dispose() is executed. But since the IsDisposed() return false we for unknow reason hang, does it mean that the message loop still operates? Or we got some error during "QuitMessageLoop"?

It seems in successful run, when the test finish 
- AwtToolkit::MessageLoop starts
- DoQuitMessageLoop is called
- AwtToolkit::QuitMessageLoop starts
- AwtToolkit::QuitMessageLoop finishes
- AwtToolkit::MessageLoop finish
- Dispose() is called, m_isDisposed sets to true
- shutdown hook isDisposed is true so no infinite loop 

During unsuccessful run,
 - AwtToolkit::MessageLoop starts
- DoQuitMessageLoop is called
- AwtToolkit::QuitMessageLoop starts
- AwtToolkit::QuitMessageLoop finishes
- AwtToolkit::MessageLoop NEVER ends so Dispose() is not called so m_isDisposed is not set to true so shutdown hook goes in infinite loop.

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

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

From aivanov at openjdk.java.net  Thu Jan 28 11:59:42 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 28 Jan 2021 11:59:42 GMT
Subject: <Swing Dev> RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v3]
In-Reply-To: <kMLumQiQftTjXvrvwZDG0xbDaxsmb98l36qxCAxl02M=.32d40e3d-fa1b-48d5-828b-2e10ef91b9b2@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
 <SAuXiT6mTsmobACwj6F9j6T7-dCAqifISJtxOVhd6DQ=.9c45b782-144d-4f68-9e18-4beabf7bae90@github.com>
 <HadOE0oL2cGzuSQ_F1s7Lx_uVy9srbVKZwuU78ZBeo0=.6025e1f8-3d77-4f4d-856f-c8ebf559f6c0@github.com>
 <0bcS5tGMNFwilc6DdEXG6iGJgG9Jjqh7OcayzCaohzI=.54f0bdad-8804-43c1-a282-3949bcb1f575@github.com>
 <kMLumQiQftTjXvrvwZDG0xbDaxsmb98l36qxCAxl02M=.32d40e3d-fa1b-48d5-828b-2e10ef91b9b2@github.com>
Message-ID: <DgfEpEd-E08sicKACCRf750lrijk2IahUBuABohtmnE=.0e462c8e-ef29-4b11-8967-78fbe77a7830@github.com>

On Thu, 28 Jan 2021 09:59:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Please take a look at the "AwtToolkit::Dispose()" method, on how much stuff should be done to properly shutdown the toolkit. This Dispose() method is executed immediately when we exit the message loop in the "Java_sun_awt_windows_WToolkit_eventLoop". So when the shutdown hook is executed we should have the message loop, then we call tk.QuitMessageLoop to stop it, and wait until all code in the Dispose() is executed. But since the IsDisposed() return false we for unknow reason hang, does it mean that the message loop still operates? Or we got some error during "QuitMessageLoop"?
>
> It seems in successful run, when the test finish 
> - AwtToolkit::MessageLoop starts
> - DoQuitMessageLoop is called
> - AwtToolkit::QuitMessageLoop starts
> - AwtToolkit::QuitMessageLoop finishes
> - AwtToolkit::MessageLoop finish
> - Dispose() is called, m_isDisposed sets to true
> - shutdown hook isDisposed is true so no infinite loop 
> 
> During unsuccessful run,
>  - AwtToolkit::MessageLoop starts
> - DoQuitMessageLoop is called
> - AwtToolkit::QuitMessageLoop starts
> - AwtToolkit::QuitMessageLoop finishes
> - AwtToolkit::MessageLoop NEVER ends so Dispose() is not called so m_isDisposed is not set to true so shutdown hook goes in infinite loop.

I was looking at the code yesterday. Could it be because of synchronisation? I mean, do we need to use native synchronisation to guarantee variable changes are seen across the threads?

Does MessageLoop not receive Quit / Null message?

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

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

From aivanov at openjdk.java.net  Thu Jan 28 12:05:42 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 28 Jan 2021 12:05:42 GMT
Subject: <Swing Dev> RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v3]
In-Reply-To: <DgfEpEd-E08sicKACCRf750lrijk2IahUBuABohtmnE=.0e462c8e-ef29-4b11-8967-78fbe77a7830@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
 <SAuXiT6mTsmobACwj6F9j6T7-dCAqifISJtxOVhd6DQ=.9c45b782-144d-4f68-9e18-4beabf7bae90@github.com>
 <HadOE0oL2cGzuSQ_F1s7Lx_uVy9srbVKZwuU78ZBeo0=.6025e1f8-3d77-4f4d-856f-c8ebf559f6c0@github.com>
 <0bcS5tGMNFwilc6DdEXG6iGJgG9Jjqh7OcayzCaohzI=.54f0bdad-8804-43c1-a282-3949bcb1f575@github.com>
 <kMLumQiQftTjXvrvwZDG0xbDaxsmb98l36qxCAxl02M=.32d40e3d-fa1b-48d5-828b-2e10ef91b9b2@github.com>
 <DgfEpEd-E08sicKACCRf750lrijk2IahUBuABohtmnE=.0e462c8e-ef29-4b11-8967-78fbe77a7830@github.com>
Message-ID: <VX-WLQqxEzFQjZTe0NSCMfFQ_PJXGn5dyXNzAnv420g=.f4dc9247-e2ef-4b9e-88e3-09ad8f1485da@github.com>

On Thu, 28 Jan 2021 11:57:06 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> It seems in successful run, when the test finish 
>> - AwtToolkit::MessageLoop starts
>> - DoQuitMessageLoop is called
>> - AwtToolkit::QuitMessageLoop starts
>> - AwtToolkit::QuitMessageLoop finishes
>> - AwtToolkit::MessageLoop finish
>> - Dispose() is called, m_isDisposed sets to true
>> - shutdown hook isDisposed is true so no infinite loop 
>> 
>> During unsuccessful run,
>>  - AwtToolkit::MessageLoop starts
>> - DoQuitMessageLoop is called
>> - AwtToolkit::QuitMessageLoop starts
>> - AwtToolkit::QuitMessageLoop finishes
>> - AwtToolkit::MessageLoop NEVER ends so Dispose() is not called so m_isDisposed is not set to true so shutdown hook goes in infinite loop.
>
> I was looking at the code yesterday. Could it be because of synchronisation? I mean, do we need to use native synchronisation to guarantee variable changes are seen across the threads?
> 
> Does MessageLoop not receive Quit / Null message?

> 
> My point is that this is not a test bug, so the test should not be changed.

The test never dispose of the frame. Why is it expected to shut down the toolkit? Shall the frame be disposed of when the main thread in the test finishes?

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

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

From serb at openjdk.java.net  Thu Jan 28 19:53:43 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Jan 2021 19:53:43 GMT
Subject: <Swing Dev> RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v3]
In-Reply-To: <VX-WLQqxEzFQjZTe0NSCMfFQ_PJXGn5dyXNzAnv420g=.f4dc9247-e2ef-4b9e-88e3-09ad8f1485da@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
 <SAuXiT6mTsmobACwj6F9j6T7-dCAqifISJtxOVhd6DQ=.9c45b782-144d-4f68-9e18-4beabf7bae90@github.com>
 <HadOE0oL2cGzuSQ_F1s7Lx_uVy9srbVKZwuU78ZBeo0=.6025e1f8-3d77-4f4d-856f-c8ebf559f6c0@github.com>
 <0bcS5tGMNFwilc6DdEXG6iGJgG9Jjqh7OcayzCaohzI=.54f0bdad-8804-43c1-a282-3949bcb1f575@github.com>
 <kMLumQiQftTjXvrvwZDG0xbDaxsmb98l36qxCAxl02M=.32d40e3d-fa1b-48d5-828b-2e10ef91b9b2@github.com>
 <DgfEpEd-E08sicKACCRf750lrijk2IahUBuABohtmnE=.0e462c8e-ef29-4b11-8967-78fbe77a7830@github.com>
 <VX-WLQqxEzFQjZTe0NSCMfFQ_PJXGn5dyXNzAnv420g=.f4dc9247-e2ef-4b9e-88e3-09ad8f1485da@github.com>
Message-ID: <gyacujYwcYebhdSEb-sqHGwWHehe2oc1QJj4mV0187Y=.54ee682d-bd7f-4776-b59f-65c604d17488@github.com>

On Thu, 28 Jan 2021 12:02:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The test never dispose of the frame. Why is it expected to shut down the toolkit? Shall the frame be disposed of when the main thread in the test finishes?

The shutdown is caused by the System.exit call while the toolkit active, so we should shut down it before the end.

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

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

From psadhukhan at openjdk.java.net  Fri Jan 29 04:06:47 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 29 Jan 2021 04:06:47 GMT
Subject: <Swing Dev> RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v3]
In-Reply-To: <gyacujYwcYebhdSEb-sqHGwWHehe2oc1QJj4mV0187Y=.54ee682d-bd7f-4776-b59f-65c604d17488@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
 <SAuXiT6mTsmobACwj6F9j6T7-dCAqifISJtxOVhd6DQ=.9c45b782-144d-4f68-9e18-4beabf7bae90@github.com>
 <HadOE0oL2cGzuSQ_F1s7Lx_uVy9srbVKZwuU78ZBeo0=.6025e1f8-3d77-4f4d-856f-c8ebf559f6c0@github.com>
 <0bcS5tGMNFwilc6DdEXG6iGJgG9Jjqh7OcayzCaohzI=.54f0bdad-8804-43c1-a282-3949bcb1f575@github.com>
 <kMLumQiQftTjXvrvwZDG0xbDaxsmb98l36qxCAxl02M=.32d40e3d-fa1b-48d5-828b-2e10ef91b9b2@github.com>
 <DgfEpEd-E08sicKACCRf750lrijk2IahUBuABohtmnE=.0e462c8e-ef29-4b11-8967-78fbe77a7830@github.com>
 <VX-WLQqxEzFQjZTe0NSCMfFQ_PJXGn5dyXNzAnv420g=.f4dc9247-e2ef-4b9e-88e3-09ad8f1485da@github.com>
 <gyacujYwcYebhdSEb-sqHGwWHehe2oc1QJj4mV0187Y=.54ee682d-bd7f-4776-b59f-65c604d17488@github.com>
Message-ID: <VVuXv9sLyBXZHg9JSdz9QZWz5erSYaqt2jakdh_Ub3Q=.cd55b9d2-08cc-428a-96b7-4b99a86421ff@github.com>

On Thu, 28 Jan 2021 19:50:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> 
>>> My point is that this is not a test bug, so the test should not be changed.
>> 
>> The test never dispose of the frame. Why is it expected to shut down the toolkit? Shall the frame be disposed of when the main thread in the test finishes?
>
>> The test never dispose of the frame. Why is it expected to shut down the toolkit? Shall the frame be disposed of when the main thread in the test finishes?
> 
> The shutdown is caused by the System.exit call while the toolkit active, so we should shut down it before the end.

It seems "m_breakMessageLoop" is never true for unsuccessful run even though AwtToolkit::QuitMessageLoop finish execution (where m_breakMessageLoop is set to true),
so AwtToolkit::MessageLoop never ends, seems to be some timing issue.

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

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

From aivanov at openjdk.java.net  Fri Jan 29 13:31:51 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 29 Jan 2021 13:31:51 GMT
Subject: <Swing Dev> RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v3]
In-Reply-To: <VVuXv9sLyBXZHg9JSdz9QZWz5erSYaqt2jakdh_Ub3Q=.cd55b9d2-08cc-428a-96b7-4b99a86421ff@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
 <SAuXiT6mTsmobACwj6F9j6T7-dCAqifISJtxOVhd6DQ=.9c45b782-144d-4f68-9e18-4beabf7bae90@github.com>
 <HadOE0oL2cGzuSQ_F1s7Lx_uVy9srbVKZwuU78ZBeo0=.6025e1f8-3d77-4f4d-856f-c8ebf559f6c0@github.com>
 <0bcS5tGMNFwilc6DdEXG6iGJgG9Jjqh7OcayzCaohzI=.54f0bdad-8804-43c1-a282-3949bcb1f575@github.com>
 <kMLumQiQftTjXvrvwZDG0xbDaxsmb98l36qxCAxl02M=.32d40e3d-fa1b-48d5-828b-2e10ef91b9b2@github.com>
 <DgfEpEd-E08sicKACCRf750lrijk2IahUBuABohtmnE=.0e462c8e-ef29-4b11-8967-78fbe77a7830@github.com>
 <VX-WLQqxEzFQjZTe0NSCMfFQ_PJXGn5dyXNzAnv420g=.f4dc9247-e2ef-4b9e-88e3-09ad8f1485da@github.com>
 <gyacujYwcYebhdSEb-sqHGwWHehe2oc1QJj4mV0187Y=.54ee682d-bd7f-4776-b59f-65c604d17488@github.com>
 <VVuXv9sLyBXZHg9JSdz9QZWz5erSYaqt2jakdh_Ub3Q=.cd55b9d2-08cc-428a-96b7-4b99a86421ff@github.com>
Message-ID: <pUqFjpjotb8m93AvXfPY3kzH4b6QGtSZq6UBYV98-aA=.32b2d092-23fd-4058-843b-8b6913f6c8e4@github.com>

On Fri, 29 Jan 2021 04:03:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It seems "m_breakMessageLoop" is never true for unsuccessful run even though AwtToolkit::QuitMessageLoop finish execution (where m_breakMessageLoop is set to true),
> so AwtToolkit::MessageLoop never ends and shutdown hook gets called where tk.isDisposed() loop start spinning. seems to be some timing issue.

Then this does look like a synchronisation problem. One thread changes the value of `m_breakMessageLoop` but another doesn't see it's changed. Should `m_breakMessageLoop` be declared as `volatile`?

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

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

From aivanov at openjdk.java.net  Fri Jan 29 13:34:45 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 29 Jan 2021 13:34:45 GMT
Subject: <Swing Dev> RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v3]
In-Reply-To: <vYPIGrTTyov0IBGu9IjlWDlxPSjgPIqhMUuJeXiPB38=.f7d16e82-defa-4cb7-b897-9b0547cc5d04@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <vYPIGrTTyov0IBGu9IjlWDlxPSjgPIqhMUuJeXiPB38=.f7d16e82-defa-4cb7-b897-9b0547cc5d04@github.com>
Message-ID: <xjl6bagLsI8M_cqsgZrVQFzUKHzn4bpYIwmZi_gV6Yg=.c5aae607-6eb7-4cd8-a095-46f0871cad72@github.com>

On Mon, 25 Jan 2021 15:09:35 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Yet I suggest fixing the typo in the bug synopsis: Intermiitent ? Intermittent

I've edited the JBS synopsis. Please also update the PR subject.

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

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

From psadhukhan at openjdk.java.net  Fri Jan 29 15:57:46 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 29 Jan 2021 15:57:46 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_LENGTH_UNITS
In-Reply-To: <ij72WkHLVEl9iJo3CvakizJ-d0SpLigi2ilLmHLnn04=.02c61517-cfd8-4ed5-b75c-a5145225b53e@github.com>
References: <qVnKDIsDXYHah8E6GcVLY--nlmHZgOmZrT-rl-PxFuw=.1565fb15-986b-4721-96dd-617c58ab7f6e@github.com>
 <ij72WkHLVEl9iJo3CvakizJ-d0SpLigi2ilLmHLnn04=.02c61517-cfd8-4ed5-b75c-a5145225b53e@github.com>
Message-ID: <4t81cloV5PlgwoqWmAd7dNG4HOIgRrqvCti0t5IwDak=.b5972e8d-c7ed-4f42-9adf-60648aa5b45e@github.com>

On Wed, 27 Jan 2021 12:06:43 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This PR supersedes #2223.
>> The original PR was created from master, whereas this PR is created from a fresh branch.
>> 
>> Below is a copy of the original description, but as @mrserb correctly [pointed out](https://github.com/openjdk/jdk/pull/2223#issuecomment-767048399), there is actually no relevant change from CSS 2.1 to CSS 2.2, so I <strike>striked out</strike> that part.
>> 
>> ### Original Description
>> 
>> @prsadhuk asked me to take over his pull request #1628, since I filed the bug an suggested this fix.
>> 
>> I thought the current behavior would be buggy, but actually the units are quite precise. I checked the size of a text in font-size of 1 in, and it really was approximately 1 inch. The problem is just that browsers behave differently.
>> 
>> <strike>
>> Swing follows the CSS 2.1 spec: https://www.w3.org/TR/CSS21/syndata.html#length-units.
>> But in CSS 2.2, length units where redefined: https://www.w3.org/TR/CSS22/syndata.html#length-units.
>> Now px is also an absolute unit, and there are constant conversion factors between all absolute units.
>> 
>> The CSS 2.2 spec includes the following two notes regarding this change:
>> 
>>     Note that if the anchor unit is the pixel unit, the physical units might not match their physical measurements. Alternatively if the anchor unit is a physical unit, the pixel unit might not map to a whole number of device pixels.
>> 
>>     Note that this definition of the pixel unit and the physical units differs from previous versions of CSS. In particular, in previous versions of CSS the pixel unit and the physical units were not related by a fixed ratio: the physical units were always tied to their physical measurements while the pixel unit would vary to most closely match the reference pixel. (This change was made because too much existing content relies on the assumption of 96dpi, and breaking that assumption breaks the content.)
>> 
>> So the spec changed the behavior to better support high-DPI devices with existing content, and that is exactly my intention with this PR as well.
>> </strike>
>
> You should edit the title of the PR to be the same as the subject of the bug in JBS:
> 8231286: HTML font size too large with high-DPI scaling and W3C_LENGTH_UNITS
> 
> Please also provide the additional information in the description from the PR #2223.

It seems for screen with low resolution, this change might cause some failure as can be seen in the testcase attached in JBS Test.java.

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

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

From psadhukhan at openjdk.java.net  Fri Jan 29 18:05:07 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 29 Jan 2021 18:05:07 GMT
Subject: <Swing Dev> RFR: 8197825: [Test] Intermittent timeout with
 javax/swing JColorChooser Test [v4]
In-Reply-To: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
Message-ID: <1CsrezyIfA0wd0VG07w9RkwqitKm_k3MbR2HHJftehg=.e8afc861-30ce-4f1a-a4b0-78345b21973c@github.com>

> This test was failing in our nightly mach5 testing. Appropriate stability code in form of waitForIdle and delay is added.
> mach5 job running for several iterations on all platforms is ok. Link in JBS.

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

  Declare m_breakMessageLoop volatile

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2220/files
  - new: https://git.openjdk.java.net/jdk/pull/2220/files/6fdcc0d7..d7dc2a52

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

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

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

From aivanov at openjdk.java.net  Fri Jan 29 19:49:48 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 29 Jan 2021 19:49:48 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_LENGTH_UNITS
In-Reply-To: <L6LF38m7HHM8hWj8ex6s94UXwUnIeN5AUxx3E7ziHVY=.64b0cf77-ca36-4fae-ba28-7df7e3497967@github.com>
References: <qVnKDIsDXYHah8E6GcVLY--nlmHZgOmZrT-rl-PxFuw=.1565fb15-986b-4721-96dd-617c58ab7f6e@github.com>
 <L6LF38m7HHM8hWj8ex6s94UXwUnIeN5AUxx3E7ziHVY=.64b0cf77-ca36-4fae-ba28-7df7e3497967@github.com>
Message-ID: <CWJPSKLaaTfSbTaIy9M5nlI-HhGWRXm0NqOkP_IDBY4=.712ff5f2-1a76-4a2a-a357-74c6909a07e8@github.com>

On Fri, 29 Jan 2021 14:15:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This PR supersedes #2223.
>> The original PR was created from master, whereas this PR is created from a fresh branch.
>> 
>> Below is a copy of the original description, but as @mrserb correctly [pointed out](https://github.com/openjdk/jdk/pull/2223#issuecomment-767048399), there is actually no relevant change from CSS 2.1 to CSS 2.2, so I <strike>striked out</strike> that part.
>> 
>> ### Original Description
>> 
>> @prsadhuk asked me to take over his pull request #1628, since I filed the bug an suggested this fix.
>> 
>> I thought the current behavior would be buggy, but actually the units are quite precise. I checked the size of a text in font-size of 1 in, and it really was approximately 1 inch. The problem is just that browsers behave differently.
>> 
>> <strike>
>> Swing follows the CSS 2.1 spec: https://www.w3.org/TR/CSS21/syndata.html#length-units.
>> But in CSS 2.2, length units where redefined: https://www.w3.org/TR/CSS22/syndata.html#length-units.
>> Now px is also an absolute unit, and there are constant conversion factors between all absolute units.
>> 
>> The CSS 2.2 spec includes the following two notes regarding this change:
>> 
>>     Note that if the anchor unit is the pixel unit, the physical units might not match their physical measurements. Alternatively if the anchor unit is a physical unit, the pixel unit might not map to a whole number of device pixels.
>> 
>>     Note that this definition of the pixel unit and the physical units differs from previous versions of CSS. In particular, in previous versions of CSS the pixel unit and the physical units were not related by a fixed ratio: the physical units were always tied to their physical measurements while the pixel unit would vary to most closely match the reference pixel. (This change was made because too much existing content relies on the assumption of 96dpi, and breaking that assumption breaks the content.)
>> 
>> So the spec changed the behavior to better support high-DPI devices with existing content, and that is exactly my intention with this PR as well.
>> </strike>
>
> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2870:
> 
>> 2868:             w3cLengthMapping.put("cm", 37.7952f); //96px/2.54
>> 2869:             w3cLengthMapping.put("pc", 16f); //1/6 of 1in
>> 2870:             w3cLengthMapping.put("in", 96f); //96px
> 
> I suggest adding a space after `//`.
> Align the comments?
> 
> As for *px*, CSS defines, ?1px is equal to 0.75pt?, then 1pt is 4/3px ? this is where 1.3f comes from (=96/72).

Copyright year in CSS.java needs updating to 2021 too.

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

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

From aivanov at openjdk.java.net  Fri Jan 29 19:49:46 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 29 Jan 2021 19:49:46 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_LENGTH_UNITS
In-Reply-To: <qVnKDIsDXYHah8E6GcVLY--nlmHZgOmZrT-rl-PxFuw=.1565fb15-986b-4721-96dd-617c58ab7f6e@github.com>
References: <qVnKDIsDXYHah8E6GcVLY--nlmHZgOmZrT-rl-PxFuw=.1565fb15-986b-4721-96dd-617c58ab7f6e@github.com>
Message-ID: <L6LF38m7HHM8hWj8ex6s94UXwUnIeN5AUxx3E7ziHVY=.64b0cf77-ca36-4fae-ba28-7df7e3497967@github.com>

On Wed, 27 Jan 2021 11:40:10 GMT, Matthias Perktold <github.com+7334069+mperktold at openjdk.org> wrote:

> This PR supersedes #2223.
> The original PR was created from master, whereas this PR is created from a fresh branch.
> 
> Below is a copy of the original description, but as @mrserb correctly [pointed out](https://github.com/openjdk/jdk/pull/2223#issuecomment-767048399), there is actually no relevant change from CSS 2.1 to CSS 2.2, so I <strike>striked out</strike> that part.
> 
> ### Original Description
> 
> @prsadhuk asked me to take over his pull request #1628, since I filed the bug an suggested this fix.
> 
> I thought the current behavior would be buggy, but actually the units are quite precise. I checked the size of a text in font-size of 1 in, and it really was approximately 1 inch. The problem is just that browsers behave differently.
> 
> <strike>
> Swing follows the CSS 2.1 spec: https://www.w3.org/TR/CSS21/syndata.html#length-units.
> But in CSS 2.2, length units where redefined: https://www.w3.org/TR/CSS22/syndata.html#length-units.
> Now px is also an absolute unit, and there are constant conversion factors between all absolute units.
> 
> The CSS 2.2 spec includes the following two notes regarding this change:
> 
>     Note that if the anchor unit is the pixel unit, the physical units might not match their physical measurements. Alternatively if the anchor unit is a physical unit, the pixel unit might not map to a whole number of device pixels.
> 
>     Note that this definition of the pixel unit and the physical units differs from previous versions of CSS. In particular, in previous versions of CSS the pixel unit and the physical units were not related by a fixed ratio: the physical units were always tied to their physical measurements while the pixel unit would vary to most closely match the reference pixel. (This change was made because too much existing content relies on the assumption of 96dpi, and breaking that assumption breaks the content.)
> 
> So the spec changed the behavior to better support high-DPI devices with existing content, and that is exactly my intention with this PR as well.
> </strike>

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2864:

> 2862:             lengthMapping.put("pc", 12f);
> 2863:             lengthMapping.put("in", 72f);
> 2864:             // mapping according to the CSS2.2 spec

> Should we not put the latest CSS link here in addition/instead of in JEditorPane?
I agree the link to Length Units should also be added here:
Suggestion:

            // Mapping according to the CSS2.2 spec
            // https://www.w3.org/TR/CSS22/syndata.html#length-units
Or https://www.w3.org/TR/CSS22/syndata.html#x39 which leads directly to _Absolute length units_.

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2870:

> 2868:             w3cLengthMapping.put("cm", 37.7952f); //96px/2.54
> 2869:             w3cLengthMapping.put("pc", 16f); //1/6 of 1in
> 2870:             w3cLengthMapping.put("in", 96f); //96px

I suggest adding a space after `//`.
Align the comments?

As for *px*, CSS defines, ?1px is equal to 0.75pt?, then 1pt is 4/3px ? this is where 1.3f comes from (=96/72).

test/jdk/javax/swing/text/html/HtmlFontSizeTest.java line 79:

> 77:             frame.setLocationRelativeTo(null);
> 78: 
> 79:             return frame.getBounds();

`frame` is redundant, `htmlPane.getPreferredSize()` does the job.

test/jdk/javax/swing/text/html/HtmlFontSizeTest.java line 94:

> 92: 
> 93:         float ratio = (float)w3cFrameSize.width / (float)stdFrameSize.width;
> 94:         System.out.println("w3cFrameSize.width/stdFrameSize.width " + ratio);

Shall the ratio be `(float)w3cFrameSize.height / (float)stdFrameSize.height`?
You measure the font size so height seems a better candidate. However, the width does change as well.

test/jdk/javax/swing/text/html/HtmlFontSizeTest.java line 98:

> 96:         String str = String.format("%.1g%n", ratio);
> 97:         if (str.compareTo(String.format("%.1g%n", 1.3f)) != 0) {
> 98:             throw new RuntimeException("HTML font size too large with high-DPI scaling and W3C_LENGTH_UNITS");

The test passes for me with the fresh build of JDK, even without the fix applied.
Indeed, I get the same frame dimensions in both cases: 150?42.

However, the test fails when run with JDK 11.0.10 or JDK 15, the dimension of `htmlPane` is 409?76.

The formatted string, `str`, contains only the number before the decimal point. I mean for `1.3f`, the formatted string is `"1"`. I'd expect the formatted string to have at least one digit after the decimal point but there's none.

Does
if ("1.3".equals(String.format("%1.1", ratio))
look clearer?


I guess the test does not fail if the system scaling (of the main monitor) is set to 100% because `res` value read from `Toolkit.getDefaultToolkit().getScreenResolution()` is 96/72 which is 1.3.

In my testing, `sun.java2d.uiScale` has no effect on the result.

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

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

From aivanov at openjdk.java.net  Fri Jan 29 20:01:42 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 29 Jan 2021 20:01:42 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_LENGTH_UNITS
In-Reply-To: <L6LF38m7HHM8hWj8ex6s94UXwUnIeN5AUxx3E7ziHVY=.64b0cf77-ca36-4fae-ba28-7df7e3497967@github.com>
References: <qVnKDIsDXYHah8E6GcVLY--nlmHZgOmZrT-rl-PxFuw=.1565fb15-986b-4721-96dd-617c58ab7f6e@github.com>
 <L6LF38m7HHM8hWj8ex6s94UXwUnIeN5AUxx3E7ziHVY=.64b0cf77-ca36-4fae-ba28-7df7e3497967@github.com>
Message-ID: <KU8ASq8Eh9mFZLxCjoJOfbgclfRnkdSl4MBvvjPph1I=.3085f5f6-ed2f-4d83-ab7d-e70a86f82500@github.com>

On Fri, 29 Jan 2021 19:45:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This PR supersedes #2223.
>> The original PR was created from master, whereas this PR is created from a fresh branch.
>> 
>> Below is a copy of the original description, but as @mrserb correctly [pointed out](https://github.com/openjdk/jdk/pull/2223#issuecomment-767048399), there is actually no relevant change from CSS 2.1 to CSS 2.2, so I <strike>striked out</strike> that part.
>> 
>> ### Original Description
>> 
>> @prsadhuk asked me to take over his pull request #1628, since I filed the bug an suggested this fix.
>> 
>> I thought the current behavior would be buggy, but actually the units are quite precise. I checked the size of a text in font-size of 1 in, and it really was approximately 1 inch. The problem is just that browsers behave differently.
>> 
>> <strike>
>> Swing follows the CSS 2.1 spec: https://www.w3.org/TR/CSS21/syndata.html#length-units.
>> But in CSS 2.2, length units where redefined: https://www.w3.org/TR/CSS22/syndata.html#length-units.
>> Now px is also an absolute unit, and there are constant conversion factors between all absolute units.
>> 
>> The CSS 2.2 spec includes the following two notes regarding this change:
>> 
>>     Note that if the anchor unit is the pixel unit, the physical units might not match their physical measurements. Alternatively if the anchor unit is a physical unit, the pixel unit might not map to a whole number of device pixels.
>> 
>>     Note that this definition of the pixel unit and the physical units differs from previous versions of CSS. In particular, in previous versions of CSS the pixel unit and the physical units were not related by a fixed ratio: the physical units were always tied to their physical measurements while the pixel unit would vary to most closely match the reference pixel. (This change was made because too much existing content relies on the assumption of 96dpi, and breaking that assumption breaks the content.)
>> 
>> So the spec changed the behavior to better support high-DPI devices with existing content, and that is exactly my intention with this PR as well.
>> </strike>
>
> test/jdk/javax/swing/text/html/HtmlFontSizeTest.java line 98:
> 
>> 96:         String str = String.format("%.1g%n", ratio);
>> 97:         if (str.compareTo(String.format("%.1g%n", 1.3f)) != 0) {
>> 98:             throw new RuntimeException("HTML font size too large with high-DPI scaling and W3C_LENGTH_UNITS");
> 
> The test passes for me with the fresh build of JDK, even without the fix applied.
> Indeed, I get the same frame dimensions in both cases: 150?42.
> 
> However, the test fails when run with JDK 11.0.10 or JDK 15, the dimension of `htmlPane` is 409?76.
> 
> The formatted string, `str`, contains only the number before the decimal point. I mean for `1.3f`, the formatted string is `"1"`. I'd expect the formatted string to have at least one digit after the decimal point but there's none.
> 
> Does
> if ("1.3".equals(String.format("%1.1", ratio))
> look clearer?
> 
> 
> I guess the test does not fail if the system scaling (of the main monitor) is set to 100% because `res` value read from `Toolkit.getDefaultToolkit().getScreenResolution()` is 96/72 which is 1.3.
> 
> In my testing, `sun.java2d.uiScale` has no effect on the result.

I propose to move the test into CSS folder, and probably to create its own folder, `8231286` or 'font-size`.

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

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

From aivanov at openjdk.java.net  Fri Jan 29 20:22:47 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 29 Jan 2021 20:22:47 GMT
Subject: <Swing Dev> RFR: 8197825: [Test] Intermittent timeout with
 javax/swing JColorChooser Test [v4]
In-Reply-To: <1CsrezyIfA0wd0VG07w9RkwqitKm_k3MbR2HHJftehg=.e8afc861-30ce-4f1a-a4b0-78345b21973c@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <1CsrezyIfA0wd0VG07w9RkwqitKm_k3MbR2HHJftehg=.e8afc861-30ce-4f1a-a4b0-78345b21973c@github.com>
Message-ID: <G12L2Gb0el3JVIiigiA5McrFbYkhaw38CJF6yovO77M=.a5d4a1c4-17a7-446b-a903-b2a476a98b32@github.com>

On Fri, 29 Jan 2021 18:05:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> This test was failing in our nightly mach5 testing. Appropriate stability code in form of waitForIdle and delay is added.
>> mach5 job running for several iterations on all platforms is ok. Link in JBS.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Declare m_breakMessageLoop volatile

src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h line 478:

> 476:     BOOL m_breakOnError;
> 477: 
> 478:     volatile BOOL  m_breakMessageLoop;

Does this volatile modifier resolve the now-removed infinite loop in `while (!tk.IsDisposed())` in `WToolkit_shutdown`?

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

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

From aivanov at openjdk.java.net  Fri Jan 29 23:19:42 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 29 Jan 2021 23:19:42 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_LENGTH_UNITS
In-Reply-To: <KU8ASq8Eh9mFZLxCjoJOfbgclfRnkdSl4MBvvjPph1I=.3085f5f6-ed2f-4d83-ab7d-e70a86f82500@github.com>
References: <qVnKDIsDXYHah8E6GcVLY--nlmHZgOmZrT-rl-PxFuw=.1565fb15-986b-4721-96dd-617c58ab7f6e@github.com>
 <L6LF38m7HHM8hWj8ex6s94UXwUnIeN5AUxx3E7ziHVY=.64b0cf77-ca36-4fae-ba28-7df7e3497967@github.com>
 <KU8ASq8Eh9mFZLxCjoJOfbgclfRnkdSl4MBvvjPph1I=.3085f5f6-ed2f-4d83-ab7d-e70a86f82500@github.com>
Message-ID: <eny_HxN8dwKgR2rvg9CODNA-A8XQ25HJ7MMQW6i8OAo=.11118ea0-04a9-4ddb-bfa9-4ff5f6b8e1a9@github.com>

On Fri, 29 Jan 2021 19:58:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/text/html/HtmlFontSizeTest.java line 98:
>> 
>>> 96:         String str = String.format("%.1g%n", ratio);
>>> 97:         if (str.compareTo(String.format("%.1g%n", 1.3f)) != 0) {
>>> 98:             throw new RuntimeException("HTML font size too large with high-DPI scaling and W3C_LENGTH_UNITS");
>> 
>> The test passes for me with the fresh build of JDK, even without the fix applied.
>> Indeed, I get the same frame dimensions in both cases: 150?42.
>> 
>> However, the test fails when run with JDK 11.0.10 or JDK 15, the dimension of `htmlPane` is 409?76.
>> 
>> The formatted string, `str`, contains only the number before the decimal point. I mean for `1.3f`, the formatted string is `"1"`. I'd expect the formatted string to have at least one digit after the decimal point but there's none.
>> 
>> Does
>> if ("1.3".equals(String.format("%1.1", ratio))
>> look clearer?
>> 
>> 
>> I guess the test does not fail if the system scaling (of the main monitor) is set to 100% because `res` value read from `Toolkit.getDefaultToolkit().getScreenResolution()` is 96/72 which is 1.3.
>> 
>> In my testing, `sun.java2d.uiScale` has no effect on the result.
>
> I propose to move the test into CSS folder, and probably to create its own folder, `8231286` or 'font-size`.

> The test passes for me with the fresh build of JDK, even without the fix applied.
> Indeed, I get the same frame dimensions in both cases: 150?42.
> 
> However, the test fails when run with JDK 11.0.10 or JDK 15, the dimension of `htmlPane` is 409?76.
> 
[JDK-8257664](https://bugs.openjdk.java.net/browse/JDK-8257664): HTMLEditorKit: Wrong CSS relative font sizes
has changed the behaviour. With the fix reverted, I get frame size of 409?76 as in previous versions.

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

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

From serb at openjdk.java.net  Fri Jan 29 23:48:47 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Jan 2021 23:48:47 GMT
Subject: <Swing Dev> RFR: 8197825: [Test] Intermittent timeout with
 javax/swing JColorChooser Test [v4]
In-Reply-To: <G12L2Gb0el3JVIiigiA5McrFbYkhaw38CJF6yovO77M=.a5d4a1c4-17a7-446b-a903-b2a476a98b32@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <1CsrezyIfA0wd0VG07w9RkwqitKm_k3MbR2HHJftehg=.e8afc861-30ce-4f1a-a4b0-78345b21973c@github.com>
 <G12L2Gb0el3JVIiigiA5McrFbYkhaw38CJF6yovO77M=.a5d4a1c4-17a7-446b-a903-b2a476a98b32@github.com>
Message-ID: <EZwnt0x_oWw4rChiTItKrXZGf8Wwcd7uDsZmCYEp6H8=.07293f38-eb31-4c44-ae09-9d5bd2f3313d@github.com>

On Fri, 29 Jan 2021 20:19:43 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Does this volatile modifier resolve the now-removed infinite loop in `while (!tk.IsDisposed())` in `WToolkit_shutdown`?

The loop should not be removed.

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

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

From psadhukhan at openjdk.java.net  Sat Jan 30 05:12:45 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Sat, 30 Jan 2021 05:12:45 GMT
Subject: <Swing Dev> RFR: 8197825: [Test] Intermittent timeout with
 javax/swing JColorChooser Test [v4]
In-Reply-To: <EZwnt0x_oWw4rChiTItKrXZGf8Wwcd7uDsZmCYEp6H8=.07293f38-eb31-4c44-ae09-9d5bd2f3313d@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <1CsrezyIfA0wd0VG07w9RkwqitKm_k3MbR2HHJftehg=.e8afc861-30ce-4f1a-a4b0-78345b21973c@github.com>
 <G12L2Gb0el3JVIiigiA5McrFbYkhaw38CJF6yovO77M=.a5d4a1c4-17a7-446b-a903-b2a476a98b32@github.com>
 <EZwnt0x_oWw4rChiTItKrXZGf8Wwcd7uDsZmCYEp6H8=.07293f38-eb31-4c44-ae09-9d5bd2f3313d@github.com>
Message-ID: <RIAmNY3u3cjoGoL4oIVYQuc_inbCjo588QUmziaQqyQ=.4ae71128-8347-4d28-889d-c50db05383d8@github.com>

On Fri, 29 Jan 2021 23:46:14 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h line 478:
>> 
>>> 476:     BOOL m_breakOnError;
>>> 477: 
>>> 478:     volatile BOOL  m_breakMessageLoop;
>> 
>> Does this volatile modifier resolve the now-removed infinite loop in `while (!tk.IsDisposed())` in `WToolkit_shutdown`?
>
>> Does this volatile modifier resolve the now-removed infinite loop in `while (!tk.IsDisposed())` in `WToolkit_shutdown`?
> 
> The loop should not be removed.

Unfortunately, volatile modifier has no effect if infinite loop is reinstated..

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

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

From aivanov at openjdk.java.net  Sat Jan 30 12:03:47 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Sat, 30 Jan 2021 12:03:47 GMT
Subject: <Swing Dev> RFR: 8197825: [Test] Intermittent timeout with
 javax/swing JColorChooser Test [v4]
In-Reply-To: <RIAmNY3u3cjoGoL4oIVYQuc_inbCjo588QUmziaQqyQ=.4ae71128-8347-4d28-889d-c50db05383d8@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <1CsrezyIfA0wd0VG07w9RkwqitKm_k3MbR2HHJftehg=.e8afc861-30ce-4f1a-a4b0-78345b21973c@github.com>
 <G12L2Gb0el3JVIiigiA5McrFbYkhaw38CJF6yovO77M=.a5d4a1c4-17a7-446b-a903-b2a476a98b32@github.com>
 <EZwnt0x_oWw4rChiTItKrXZGf8Wwcd7uDsZmCYEp6H8=.07293f38-eb31-4c44-ae09-9d5bd2f3313d@github.com>
 <RIAmNY3u3cjoGoL4oIVYQuc_inbCjo588QUmziaQqyQ=.4ae71128-8347-4d28-889d-c50db05383d8@github.com>
Message-ID: <fKh6RlNhnhCu4AJ89wXRzQiN2nJ_TRDiqQXmYJPwTII=.43000072-5ac6-4ad2-81c2-cd3e09f5526a@github.com>

On Sat, 30 Jan 2021 05:10:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> Does this volatile modifier resolve the now-removed infinite loop in `while (!tk.IsDisposed())` in `WToolkit_shutdown`?
>> 
>> The loop should not be removed.
>
> Unfortunately, volatile modifier has no effect if infinite loop is reinstated..

> > Does this volatile modifier resolve the now-removed infinite loop in `while (!tk.IsDisposed())` in `WToolkit_shutdown`?
> 
> The loop should not be removed.

No, it should not, as you noted previously.

However, making `m_breakMessageLoop` volatile does not look right either. If `QuitMessageLoop` is called from `!IsMainThread()` thread, it is posted as a message to run on the correct thread. Thus `m_breakMessageLoop` should be accessed on a single thread only; if it's the case, volatile is unneeded.

And @prsadhuk's latest test confirms it. There must be something else?

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

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

From aivanov at openjdk.java.net  Sat Jan 30 18:06:47 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Sat, 30 Jan 2021 18:06:47 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_LENGTH_UNITS
In-Reply-To: <eny_HxN8dwKgR2rvg9CODNA-A8XQ25HJ7MMQW6i8OAo=.11118ea0-04a9-4ddb-bfa9-4ff5f6b8e1a9@github.com>
References: <qVnKDIsDXYHah8E6GcVLY--nlmHZgOmZrT-rl-PxFuw=.1565fb15-986b-4721-96dd-617c58ab7f6e@github.com>
 <L6LF38m7HHM8hWj8ex6s94UXwUnIeN5AUxx3E7ziHVY=.64b0cf77-ca36-4fae-ba28-7df7e3497967@github.com>
 <KU8ASq8Eh9mFZLxCjoJOfbgclfRnkdSl4MBvvjPph1I=.3085f5f6-ed2f-4d83-ab7d-e70a86f82500@github.com>
 <eny_HxN8dwKgR2rvg9CODNA-A8XQ25HJ7MMQW6i8OAo=.11118ea0-04a9-4ddb-bfa9-4ff5f6b8e1a9@github.com>
Message-ID: <Zpxw5uMBSEVXwiqcRHFkFTjzBcTpKLTTLMFeEfYdozw=.2001ae0f-64f5-4297-ac47-20a637794a3f@github.com>

On Fri, 29 Jan 2021 23:17:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > The test passes for me with the fresh build of JDK, even without the fix applied.
> > Indeed, I get the same frame dimensions in both cases: 150?42.
> > However, the test fails when run with JDK 11.0.10 or JDK 15, the dimension of `htmlPane` is 409?76.
> 
> [JDK-8257664](https://bugs.openjdk.java.net/browse/JDK-8257664): HTMLEditorKit: Wrong CSS relative font sizes
> has changed the behaviour. With the fix reverted, I get frame size of 409?76 as in previous versions.

I have submitted [JDK-8260687](https://bugs.openjdk.java.net/browse/JDK-8260687): _Inherited font size is smaller than expected when using StyleSheet to add styles_.

I suggest declaring the `font-size` property on the `<body>` element in `style` attribute.

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

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

From roger.toenz at gmx.ch  Mon Jan  4 12:27:38 2021
From: roger.toenz at gmx.ch (=?utf-8?Q?Roger_T=C3=B6nz?=)
Date: Mon, 04 Jan 2021 12:27:38 -0000
Subject: <Swing Dev> MacOS BigSur: AllowsAutomaticWindowTabbing
Message-ID: <62490AE6-FBB3-4C3A-8574-8E9A2F970F25@gmx.ch>

Hi,

A little workaround for:
https://bugs.openjdk.java.net/browse/JDK-8256465

Calling:
ObjCRuntime.disableAllowsAutomaticWindowTabbing()
before first Window opens.

It?s just a workaround, not a solution.

Cheers
Roger T?nz



import java.util.logging.Level;
import java.util.logging.Logger;

import com.sun.jna.Library;
import com.sun.jna.Native;
import com.sun.jna.Pointer;

public interface ObjCRuntime extends Library {

  Pointer objc_lookUpClass(final String className);
  Pointer sel_getUid(final String s);
  long objc_msgSend(final Pointer pointer, final Pointer selector, Object... args);


  private static long invoke(final String className, final String selectorN, Object... args){
    final ObjCRuntime objCRuntime = Native.load("objc", ObjCRuntime.class);
    final Pointer clazz = objCRuntime.objc_lookUpClass(className);
    final Pointer selector = objCRuntime.sel_getUid(selectorN);
    return objCRuntime.objc_msgSend(clazz, selector, args);
  }

  //for MacOS 10.13 and higher (workaround for https://bugs.openjdk.java.net/browse/JDK-8256465)
  public static void disableAllowsAutomaticWindowTabbing() {
    try {
      ObjCRuntime.invoke("NSWindow", "setAllowsAutomaticWindowTabbing:", Boolean.FALSE);
    } catch(Throwable e){
      Logger.getAnonymousLogger("ObjCRuntime").log(Level.WARNING, e, ()->"NSWindow#AllowsAutomaticWindowTabbing=???");
    }
  }
}