From arapte at openjdk.org  Tue Apr  1 06:40:13 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 1 Apr 2025 06:40:13 GMT
Subject: RFR: 8352982: gradle TEST_SDK_PATH param doesn't work with relative
 paths
Message-ID: <nQBSuBQvVW0itJLRR-Cs0TOm6ymltaWG-2BufQky1xI=.b39146a4-4f68-4459-929a-6b54d4ba0437@github.com>

Issue:
The test execution fails when a relative path is specified a relative path for `TEST_SDK_PATH`.
For example:
1. gradle -PTEST_ONLY=true -PTEST_SDK_PATH=**..**/jfx1/build test 
2. gradle -PTEST_ONLY=true -PTEST_SDK_PATH=**~**/jfx1/build test

Solution:
Convert the relative path to an absolute path.

More about fix:
The property TEST_SDK_PATH belongs to the root project rt in build.gradle.
If we modify this property in build.gradle, it does not reflect in the child projects. The child projects for example graphics, controls would still have the value of TEST_SDK_PATH before modification.
To solve this, I Introduced a new variable in build.gradle `TEST_SDK_DIR`. It would hold the modified value of `TEST_SDK_PATH` and gets correctly reflected across all sub-projects.

Verified that both relative paths and absolute path work fine after this change.

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

Commit messages:
 - relative test sdk path

Changes: https://git.openjdk.org/jfx/pull/1751/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1751&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352982
  Stats: 28 lines in 1 file changed: 12 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jfx/pull/1751.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1751/head:pull/1751

PR: https://git.openjdk.org/jfx/pull/1751

From duke at openjdk.org  Tue Apr  1 06:51:42 2025
From: duke at openjdk.org (Gopal Pattnaik)
Date: Tue, 1 Apr 2025 06:51:42 GMT
Subject: RFR: 8245602: Ensemble8: HTMLEditor Toolbar gets scrolled out of view.
Message-ID: <i5KZzkR5fsUwTcXq9l0hvB8CGYsykOfGuqrydwF53oc=.4399fc6c-6041-4cf2-a78d-27b054ca4dfa@github.com>

There was a scrolling issue with multiline edit control with text controls at the top of the edit box [JDK-8245602](https://bugs.openjdk.org/browse/JDK-8245602),

We replaced the ScrollPane with VBox control as the parent of the html edit control.

Verification:
This makes the controls on the top of the edit control, And the texts scroll inside the text area as expected.
Similar kind of behavior is seen in normal web pages with multiline edit controls inside it.

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

Commit messages:
 - JDK-8245602 HTMLEditor Toolbar gets scrolled out of view

Changes: https://git.openjdk.org/jfx/pull/1752/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1752&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8245602
  Stats: 7 lines in 1 file changed: 0 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1752.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1752/head:pull/1752

PR: https://git.openjdk.org/jfx/pull/1752

From lkostyra at openjdk.org  Tue Apr  1 09:30:21 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 1 Apr 2025 09:30:21 GMT
Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v9]
In-Reply-To: <6moTmxOBtB4kYIrBSM6cKcvKkTQzUZNis6PH-zO_t_M=.161ed456-b29d-472c-831a-da4247b4e4ea@github.com>
References: <LvJixztC_ZNQwr0Xl6sojxnSF-xh0B3R_n3R949I8C8=.3acac72f-ca46-4fec-9885-3969de6870a9@github.com>
 <6moTmxOBtB4kYIrBSM6cKcvKkTQzUZNis6PH-zO_t_M=.161ed456-b29d-472c-831a-da4247b4e4ea@github.com>
Message-ID: <gkQLyxnqFJX_mUEHAh5_ndIV7cpdpwfBfswD1Gn9T98=.75c6b9d9-61fd-4554-a54a-d41fb64668df@github.com>

On Mon, 31 Mar 2025 17:48:50 GMT, Oliver Schmidtmer <oschmidtmer at openjdk.org> wrote:

>> Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. 
>> The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars.
>> 
>> The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue.
>> If this should be added as a unit test, I'm open for advice how to do that.
>
> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   explicit break

LGTM

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

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1724#pullrequestreview-2732074557

From duke at openjdk.org  Tue Apr  1 11:02:26 2025
From: duke at openjdk.org (duke)
Date: Tue, 1 Apr 2025 11:02:26 GMT
Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v9]
In-Reply-To: <6moTmxOBtB4kYIrBSM6cKcvKkTQzUZNis6PH-zO_t_M=.161ed456-b29d-472c-831a-da4247b4e4ea@github.com>
References: <LvJixztC_ZNQwr0Xl6sojxnSF-xh0B3R_n3R949I8C8=.3acac72f-ca46-4fec-9885-3969de6870a9@github.com>
 <6moTmxOBtB4kYIrBSM6cKcvKkTQzUZNis6PH-zO_t_M=.161ed456-b29d-472c-831a-da4247b4e4ea@github.com>
Message-ID: <7qNIagxLsJY_fCgGv9raRjjp4L0XxPdjdcdk0nfan9M=.0d2601b5-bf8c-4488-b37d-b5d51a693055@github.com>

On Mon, 31 Mar 2025 17:48:50 GMT, Oliver Schmidtmer <oschmidtmer at openjdk.org> wrote:

>> Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. 
>> The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars.
>> 
>> The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue.
>> If this should be added as a unit test, I'm open for advice how to do that.
>
> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   explicit break

@Schmidor 
Your change (at version 337a67fd708344af1ea9e641a0a2ed2d1e46510a) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1724#issuecomment-2768983040

From kcr at openjdk.org  Tue Apr  1 11:02:49 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 1 Apr 2025 11:02:49 GMT
Subject: RFR: 8351733: Crash when creating too many nested event loops [v7]
In-Reply-To: <42VwnlUL9gTsLrjc5spYh7KulNsAkp2qAR-UW5Nlps8=.dfb81bcc-cc2a-4d55-9554-e9fd53b62f51@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <42VwnlUL9gTsLrjc5spYh7KulNsAkp2qAR-UW5Nlps8=.dfb81bcc-cc2a-4d55-9554-e9fd53b62f51@github.com>
Message-ID: <sM_XCHSQAg4H_MtrJ_2oOATrwLljiRYJxT2sb_99Gk8=.f906e9b2-e7ac-4b0a-958d-b844446b4bac@github.com>

On Mon, 31 Mar 2025 17:49:59 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
>> 
>> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
>> 
>> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added description of the new nested event loop limit.

All good.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1741#pullrequestreview-2732314240

From kcr at openjdk.org  Tue Apr  1 11:22:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 1 Apr 2025 11:22:20 GMT
Subject: RFR: 8351733: Crash when creating too many nested event loops [v3]
In-Reply-To: <of0OzcnjCK98ouVcF7eh0antA3HARGJz2Kk4U3m7Z5I=.f3f86181-0bfd-4ad3-adcb-8284c881b17f@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
 <bIULSAqVn74mPcT3Il2HQ2OhW_e3L9cfHcK94WTrBkM=.66f9df16-84e2-4979-8b75-57009ede4ad6@github.com>
 <of0OzcnjCK98ouVcF7eh0antA3HARGJz2Kk4U3m7Z5I=.f3f86181-0bfd-4ad3-adcb-8284c881b17f@github.com>
Message-ID: <U5xhpc4s307OtcywQGeRzM1TFvfipR5TFN4s512Z-kA=.5731fcda-02c7-42fa-9634-eddf5f935884@github.com>

On Thu, 27 Mar 2025 22:19:29 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> In any case, this PR should at least add the following bits of information to `Platform.enterNestedEventLoop()`:
>> 1. There is some limit to the number of nested event loops.
>> 2. Applications should always check `Platform.canStartNestedEventLoop()` before invoking `enterNestedEventLoop()`.
>> 3. An exception will be thrown if the limit is exceeded.
>
>> I think the suggestion made by @mstr2 to recommend calling `canStartNestedLoop` if the app wants to know whether or not this call will succeed is a good one.
> 
> The docs on `canStartNestedEventLoop` describe its behavior already. I'm not sure what further information would be useful. Would it be enough to add a see also link?

@beldenfox I also reviewed the CSR and it is ready to be Finalized.

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

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2769026824

From oschmidtmer at openjdk.org  Tue Apr  1 11:22:50 2025
From: oschmidtmer at openjdk.org (Oliver Schmidtmer)
Date: Tue, 1 Apr 2025 11:22:50 GMT
Subject: Integrated: 8281384: Random chars on paste from Windows clipboard
In-Reply-To: <LvJixztC_ZNQwr0Xl6sojxnSF-xh0B3R_n3R949I8C8=.3acac72f-ca46-4fec-9885-3969de6870a9@github.com>
References: <LvJixztC_ZNQwr0Xl6sojxnSF-xh0B3R_n3R949I8C8=.3acac72f-ca46-4fec-9885-3969de6870a9@github.com>
Message-ID: <58Ali61MUzwgcD0XTNyii6F4_j2Pbqo7yqpiQp1Iiic=.bfd94770-7d18-4d52-adcf-080bba236edb@github.com>

On Tue, 25 Feb 2025 13:25:07 GMT, Oliver Schmidtmer <oschmidtmer at openjdk.org> wrote:

> Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. 
> The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars.
> 
> The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue.
> If this should be added as a unit test, I'm open for advice how to do that.

This pull request has now been integrated.

Changeset: 5c78234b
Author:    Oliver Schmidtmer <oschmidtmer at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/5c78234b43d1fffa1fea0d1406599ed46af8c863
Stats:     10 lines in 2 files changed: 8 ins; 1 del; 1 mod

8281384: Random chars on paste from Windows clipboard

Reviewed-by: kcr, lkostyra

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

PR: https://git.openjdk.org/jfx/pull/1724

From k.dahlberg at siemens.com  Tue Apr  1 10:49:00 2025
From: k.dahlberg at siemens.com (Dahlberg, Magnus)
Date: Tue, 1 Apr 2025 10:49:00 +0000
Subject: Reporting a JavaFx bug
Message-ID: <AS8PR10MB6363044DB5728FA1BF32A4CD89AC2@AS8PR10MB6363.EURPRD10.PROD.OUTLOOK.COM>

Hi,

I'm trying to report a bug with JavaFx 21.0.5 (and later versions)

The only place I've seen where that would be possible is https://bugreport.java.com/bugreport/, but that page reports an error when I try to submit.

Is there anywhere else it can be done?

Many thanks,
Magnus Dahlberg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250401/0fc921fb/attachment.htm>

From kevin.rushforth at oracle.com  Tue Apr  1 11:54:12 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 1 Apr 2025 04:54:12 -0700
Subject: Reporting a JavaFx bug
In-Reply-To: <AS8PR10MB6363044DB5728FA1BF32A4CD89AC2@AS8PR10MB6363.EURPRD10.PROD.OUTLOOK.COM>
References: <AS8PR10MB6363044DB5728FA1BF32A4CD89AC2@AS8PR10MB6363.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <f2decb6d-828c-410c-a9a0-d8d2d9471d34@oracle.com>

I just tried a test bug report at bugreport.java.com and it is working 
for me. Can you try again?

If it still fails to work for you, let me know and I can ask someone to 
take a look at it.

-- Kevin

On 4/1/2025 3:49 AM, Dahlberg, Magnus wrote:
> Hi,
>
> I'm trying to report a bug with JavaFx 21.0.5 (and later versions)
>
> The only place I've seen where that would be possible is 
> https://bugreport.java.com/bugreport/, but that page reports an error 
> when I try to submit.
>
> Is there anywhere else it can be done?
>
> Many thanks,
> Magnus Dahlberg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250401/11e89207/attachment-0001.htm>

From kcr at openjdk.org  Tue Apr  1 12:38:16 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 1 Apr 2025 12:38:16 GMT
Subject: RFR: 8352982: gradle TEST_SDK_PATH param doesn't work with
 relative paths
In-Reply-To: <nQBSuBQvVW0itJLRR-Cs0TOm6ymltaWG-2BufQky1xI=.b39146a4-4f68-4459-929a-6b54d4ba0437@github.com>
References: <nQBSuBQvVW0itJLRR-Cs0TOm6ymltaWG-2BufQky1xI=.b39146a4-4f68-4459-929a-6b54d4ba0437@github.com>
Message-ID: <_b7HCKmYx8H-Ec_GdVyX4fmgUUUFOzghdQeZgGeEIZw=.5be185c8-5ac5-4991-bb4b-255c1522500f@github.com>

On Tue, 1 Apr 2025 06:36:24 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Issue:
> The test execution fails when a relative path is specified a relative path for `TEST_SDK_PATH`.
> For example:
> 1. gradle -PTEST_ONLY=true -PTEST_SDK_PATH=**..**/jfx1/build test 
> 2. gradle -PTEST_ONLY=true -PTEST_SDK_PATH=**~**/jfx1/build test
> 
> Solution:
> Convert the relative path to an absolute path.
> 
> More about fix:
> The property TEST_SDK_PATH belongs to the root project rt in build.gradle.
> If we modify this property in build.gradle, it does not reflect in the child projects. The child projects for example graphics, controls would still have the value of TEST_SDK_PATH before modification.
> To solve this, I Introduced a new variable in build.gradle `TEST_SDK_DIR`. It would hold the modified value of `TEST_SDK_PATH` and gets correctly reflected across all sub-projects.
> 
> Verified that both relative paths and absolute path work fine after this change.

I'll test and review this later, but one quick comment:

> 2. gradle -PTEST_ONLY=true -PTEST_SDK_PATH=~/jfx1/build test

This isn't a bug, but is a known limitation in the way shell expansion of `~` works. If we were going to deal with this, we would want to do it consistently for all path names, in all of our build scripts, not just this one path name in `build.gradle`. Let's not.

build.gradle line 729:

> 727:     }
> 728:     String testSdkPath = "${TEST_SDK_PATH}"
> 729:     if (testSdkPath.startsWith("~")) {

This isn't related to handling relative paths at all. Rather it is related to how bash works. The `~` character is handled by the shell and it is a known limitation that you can't use it in the middle of a string.

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

PR Review: https://git.openjdk.org/jfx/pull/1751#pullrequestreview-2732529408
PR Review Comment: https://git.openjdk.org/jfx/pull/1751#discussion_r2022761463

From jdv at openjdk.org  Tue Apr  1 14:39:41 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 1 Apr 2025 14:39:41 GMT
Subject: RFR: 8350976: MenuBarSkin: exception initializing in a background
 thread [v2]
In-Reply-To: <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
References: <rlPnhzYl_h3-WkWw7gxtdN8n5JKBVqgyu9HzWkUan8c=.5839a05f-0331-4437-bcc1-77169cdd00c8@github.com>
 <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
Message-ID: <BeVYjFVdUEhP4qM8Jt9xLKbposv7gi9G0TYn0F7rI4w=.ff9641fe-b04c-4b49-b1d4-5b679add34cd@github.com>

On Wed, 5 Mar 2025 18:19:53 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Allows MenuBar to be created in a background thread by delaying MenuBarSkin::rebuildUI() call until after the MenuBar becomes a part of the scene graph.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8350976.menubarskin.thread.safety
>  - spelling
>  - use system menu
>  - cleanup
>  - possible fix
>  - test

Previously i had commit until march 26 so again i synced the code to latest master branch build it and then took the changes from this PR(`git fetch https://git.openjdk.org/jfx.git pull/1727/head:pull/1727` & `git checkout pull/1727`) and ran the test and still passes on my macOS 14.7.4 macbook pro laptop.

In the test results also i can see menuBar test as passed.

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

PR Comment: https://git.openjdk.org/jfx/pull/1727#issuecomment-2769598489

From angorya at openjdk.org  Tue Apr  1 15:08:25 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 1 Apr 2025 15:08:25 GMT
Subject: RFR: 8350976: MenuBarSkin: exception initializing in a background
 thread [v2]
In-Reply-To: <BeVYjFVdUEhP4qM8Jt9xLKbposv7gi9G0TYn0F7rI4w=.ff9641fe-b04c-4b49-b1d4-5b679add34cd@github.com>
References: <rlPnhzYl_h3-WkWw7gxtdN8n5JKBVqgyu9HzWkUan8c=.5839a05f-0331-4437-bcc1-77169cdd00c8@github.com>
 <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
 <BeVYjFVdUEhP4qM8Jt9xLKbposv7gi9G0TYn0F7rI4w=.ff9641fe-b04c-4b49-b1d4-5b679add34cd@github.com>
Message-ID: <Fw4LzhVDoOKF1cUbHC9qk6YMFRswU35_nsZi79M-yV4=.f246ec81-37d1-4749-addc-220592241afa@github.com>

On Tue, 1 Apr 2025 14:36:39 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8350976.menubarskin.thread.safety
>>  - spelling
>>  - use system menu
>>  - cleanup
>>  - possible fix
>>  - test
>
> Previously i had commit until march 26 so again i synced the code to latest master branch build it and then took the changes from this PR(`git fetch https://git.openjdk.org/jfx.git pull/1727/head:pull/1727` & `git checkout pull/1727`) and ran the test and still passes on my macOS 14.7.4 macbook pro laptop.
> 
> In the test results also i can see menuBar test as passed.

@jayathirthrao 

Are you saying that the test taken from this PR passes when added to the current master branch?

If so, I wonder if the laptop/os version might be relevant: I am testing with macOS 15.3.2 on M1 silicon, and the test from this PR fails with the master branch.  (I also do a clean build before running the test).  Can you try running on a different machine (maybe Windows?)

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

PR Comment: https://git.openjdk.org/jfx/pull/1727#issuecomment-2769686822

From jdv at openjdk.org  Tue Apr  1 15:15:18 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 1 Apr 2025 15:15:18 GMT
Subject: RFR: 8353163: [XWayland] Disable SwingNodePlatformExitCrashTest on
 wayland
In-Reply-To: <2o_BDXwphZRgKE4vhr-JDy70tNmxCDnG7jrmQc87x4I=.e3d2420a-b993-4f8a-91e8-ad1ccffa2e47@github.com>
References: <2o_BDXwphZRgKE4vhr-JDy70tNmxCDnG7jrmQc87x4I=.e3d2420a-b993-4f8a-91e8-ad1ccffa2e47@github.com>
Message-ID: <hCYpQsV8uM-qJXxWxkMBzl4UaELsA-tj7wJbLnZnxdY=.6131ceec-825e-452e-ad53-fe76fb477070@github.com>

On Fri, 28 Mar 2025 08:56:36 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> SwingNodePlatformExitCrashTest hangs while running on wayland, we need to skip this test on wayland until https://bugs.openjdk.org/browse/JDK-8350009 is fixed.

I ran the test multiple times with wayland and JDK 24 on Ubuntu24.04 and it passes all the time.
I will close this PR and [JDK-8353163](https://bugs.openjdk.org/browse/JDK-8353163) and raise PR under [JDK-8350009](https://bugs.openjdk.org/browse/JDK-8350009) only.

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

PR Comment: https://git.openjdk.org/jfx/pull/1745#issuecomment-2769705973

From jdv at openjdk.org  Tue Apr  1 15:15:19 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 1 Apr 2025 15:15:19 GMT
Subject: Withdrawn: 8353163: [XWayland] Disable SwingNodePlatformExitCrashTest
 on wayland
In-Reply-To: <2o_BDXwphZRgKE4vhr-JDy70tNmxCDnG7jrmQc87x4I=.e3d2420a-b993-4f8a-91e8-ad1ccffa2e47@github.com>
References: <2o_BDXwphZRgKE4vhr-JDy70tNmxCDnG7jrmQc87x4I=.e3d2420a-b993-4f8a-91e8-ad1ccffa2e47@github.com>
Message-ID: <GgJNYj3rLhreE9qYzolwEqkhhm52tuqjIFFA1yRzR1s=.933a38e0-bfcf-4c4d-add1-bca54c725ef7@github.com>

On Fri, 28 Mar 2025 08:56:36 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> SwingNodePlatformExitCrashTest hangs while running on wayland, we need to skip this test on wayland until https://bugs.openjdk.org/browse/JDK-8350009 is fixed.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jfx/pull/1745

From jdv at openjdk.org  Tue Apr  1 15:57:13 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 1 Apr 2025 15:57:13 GMT
Subject: RFR: 8350009: [XWayland] SwingNodePlatformExitCrashTest hangs on
 Ubuntu 24.04
Message-ID: <iJQT2nk6Ipc_FfiJZPDMmgsKy4J4PHZYnzufuLuaTNM=.6e92de90-7143-4982-a68d-c9987d94a4be@github.com>

SwingNodePlatformExitCrashTest hangs on Ubuntu 24.04 and wayland when we use < JDK 24.

This is happening because of issue identified in https://bugs.openjdk.org/browse/JDK-8335468 and it is fixed in JDK 24.
So we need to run this test on wayland only when we use JDK 24 or later.
Test is updated and verified that it works appropriately now on Ubuntu 24.04.

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

Commit messages:
 - 8350009: [XWayland] SwingNodePlatformExitCrashTest hangs on Ubuntu 24.04

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

PR: https://git.openjdk.org/jfx/pull/1753

From angorya at openjdk.org  Tue Apr  1 16:09:24 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 1 Apr 2025 16:09:24 GMT
Subject: RFR: 8352746: [TestBug] Monkey Tester Application Update 5
Message-ID: <actvM3rNHh_Z40XsdTOlze1lNr6sWeH3nXbchpMCiSg=.7945ddac-466c-4fd6-a262-74c0a9a8ef94@github.com>

Further additions to the MonkeyTester application:

- platform preferences monitor
- improved pages: hbox, vbox
- improved css playground
- mouse listener option in some context menus
- additional choices: background
- additional properties: Node::clip, Region::shape, TextInputControl::textFormatter
- font selector in Tools -> JTextArea/JTextField Embedded in SwingNode

## New Pages
- anchor pane
- border pane
- button bar
- flow pane
- grid pane
- media player
- progress indicator
- separator
- slider
- stack pane
- stage
- tile pane

## Properties Monitor

![Screenshot 2025-03-31 at 16 18 17](https://github.com/user-attachments/assets/fa4256ab-c58a-4f93-bee1-a9b5236f64a6)

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

Commit messages:
 - cleanup
 - whitespace
 - mt update 5

Changes: https://git.openjdk.org/jfx/pull/1750/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1750&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352746
  Stats: 4404 lines in 60 files changed: 4063 ins; 167 del; 174 mod
  Patch: https://git.openjdk.org/jfx/pull/1750.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1750/head:pull/1750

PR: https://git.openjdk.org/jfx/pull/1750

From kcr at openjdk.org  Tue Apr  1 17:02:23 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 1 Apr 2025 17:02:23 GMT
Subject: RFR: 8245602: Ensemble8: HTMLEditor Toolbar gets scrolled out of
 view
In-Reply-To: <i5KZzkR5fsUwTcXq9l0hvB8CGYsykOfGuqrydwF53oc=.4399fc6c-6041-4cf2-a78d-27b054ca4dfa@github.com>
References: <i5KZzkR5fsUwTcXq9l0hvB8CGYsykOfGuqrydwF53oc=.4399fc6c-6041-4cf2-a78d-27b054ca4dfa@github.com>
Message-ID: <cmhX4cH8jSxNxRhC3gtTUNrqmVuEHnC8E3RucO-OYaE=.64532ebc-a92e-4921-9a7a-f3da63bd02da@github.com>

On Tue, 1 Apr 2025 06:47:59 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

> There was a scrolling issue with multiline edit control with text controls at the top of the edit box [JDK-8245602](https://bugs.openjdk.org/browse/JDK-8245602),
> 
> We replaced the ScrollPane with VBox control as the parent of the html edit control.
> 
> Verification:
> This makes the controls on the top of the edit control, And the texts scroll inside the text area as expected.
> Similar kind of behavior is seen in normal web pages with multiline edit controls inside it.

Reviewer: @arapte or @andy-goryachev-oracle

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

PR Comment: https://git.openjdk.org/jfx/pull/1752#issuecomment-2770001779

From jdv at openjdk.org  Tue Apr  1 17:03:23 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 1 Apr 2025 17:03:23 GMT
Subject: RFR: 8350976: MenuBarSkin: exception initializing in a background
 thread [v2]
In-Reply-To: <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
References: <rlPnhzYl_h3-WkWw7gxtdN8n5JKBVqgyu9HzWkUan8c=.5839a05f-0331-4437-bcc1-77169cdd00c8@github.com>
 <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
Message-ID: <DZc7xO9ImezwGeIwu2GeD7E74isGB7OHwlvLzaFCsCk=.79eacea0-548d-4715-85d3-ad842dead242@github.com>

On Wed, 5 Mar 2025 18:19:53 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Allows MenuBar to be created in a background thread by delaying MenuBarSkin::rebuildUI() call until after the MenuBar becomes a part of the scene graph.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8350976.menubarskin.thread.safety
>  - spelling
>  - use system menu
>  - cleanup
>  - possible fix
>  - test

Yes updated NodeInitializationStressTest with master branch code passes on my M1 macOS 14.7.4 Macbook pro laptop. I again checked with clean build.

Also since i am working Ubuntu 24.04 issues, i tested with clean master branch build and updated test. Here also i see that the menuBar test passes with master branch build. I have little order setup on my Windows with older toolchain, once i make it work on latest code i will share my findings.

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

PR Comment: https://git.openjdk.org/jfx/pull/1727#issuecomment-2770003849

From kcr at openjdk.org  Tue Apr  1 17:05:13 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 1 Apr 2025 17:05:13 GMT
Subject: RFR: 8352746: [TestBug] Monkey Tester Application Update 5
In-Reply-To: <actvM3rNHh_Z40XsdTOlze1lNr6sWeH3nXbchpMCiSg=.7945ddac-466c-4fd6-a262-74c0a9a8ef94@github.com>
References: <actvM3rNHh_Z40XsdTOlze1lNr6sWeH3nXbchpMCiSg=.7945ddac-466c-4fd6-a262-74c0a9a8ef94@github.com>
Message-ID: <wSCR60IAEmWrevWTU40HOsw86ANNHTy6NtTncxcjxdQ=.131be511-47a4-4dfb-a2c0-37d8769e957c@github.com>

On Mon, 31 Mar 2025 23:11:42 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Further additions to the MonkeyTester application:
> 
> - platform preferences monitor
> - improved pages: hbox, vbox
> - improved css playground
> - mouse listener option in some context menus
> - additional choices: background
> - additional properties: Node::clip, Region::shape, TextInputControl::textFormatter
> - font selector in Tools -> JTextArea/JTextField Embedded in SwingNode
> 
> ## New Pages
> - anchor pane
> - border pane
> - button bar
> - flow pane
> - grid pane
> - media player
> - progress indicator
> - separator
> - slider
> - stack pane
> - stage
> - tile pane
> 
> ## Properties Monitor
> 
> ![Screenshot 2025-03-31 at 16 18 17](https://github.com/user-attachments/assets/fa4256ab-c58a-4f93-bee1-a9b5236f64a6)

Reviewers: @lukostyra @jayathirthrao

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

PR Comment: https://git.openjdk.org/jfx/pull/1750#issuecomment-2770009828

From angorya at openjdk.org  Tue Apr  1 17:09:15 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 1 Apr 2025 17:09:15 GMT
Subject: RFR: 8350976: MenuBarSkin: exception initializing in a background
 thread [v2]
In-Reply-To: <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
References: <rlPnhzYl_h3-WkWw7gxtdN8n5JKBVqgyu9HzWkUan8c=.5839a05f-0331-4437-bcc1-77169cdd00c8@github.com>
 <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
Message-ID: <Fzd9AHMGbc0g5MLz5h4D0U2nSH0rw_rb60nQSwW_6io=.081d0403-b021-4951-9131-64a8486a85c9@github.com>

On Wed, 5 Mar 2025 18:19:53 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Allows MenuBar to be created in a background thread by delaying MenuBarSkin::rebuildUI() call until after the MenuBar becomes a part of the scene graph.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8350976.menubarskin.thread.safety
>  - spelling
>  - use system menu
>  - cleanup
>  - possible fix
>  - test

Do you have the `glass.disableThreadChecks` system property set?

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

PR Comment: https://git.openjdk.org/jfx/pull/1727#issuecomment-2770031755

From jdv at openjdk.org  Tue Apr  1 17:09:14 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 1 Apr 2025 17:09:14 GMT
Subject: RFR: 8350976: MenuBarSkin: exception initializing in a background
 thread [v2]
In-Reply-To: <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
References: <rlPnhzYl_h3-WkWw7gxtdN8n5JKBVqgyu9HzWkUan8c=.5839a05f-0331-4437-bcc1-77169cdd00c8@github.com>
 <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
Message-ID: <UKGW-JbxpcdcILhGe4H-UjyzSspnjdPJ17GIvks7o4o=.21ea8c12-f870-495f-adcd-b6dc19ec260c@github.com>

On Wed, 5 Mar 2025 18:19:53 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Allows MenuBar to be created in a background thread by delaying MenuBarSkin::rebuildUI() call until after the MenuBar becomes a part of the scene graph.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8350976.menubarskin.thread.safety
>  - spelling
>  - use system menu
>  - cleanup
>  - possible fix
>  - test

More info i am running this test using below command:
`gradle --continue --info -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:cleanTest :systemTests:test --tests test.robot.javafx.scene.NodeInitializationStressTest`

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

PR Comment: https://git.openjdk.org/jfx/pull/1727#issuecomment-2770028488

From kcr at openjdk.org  Tue Apr  1 17:30:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 1 Apr 2025 17:30:20 GMT
Subject: RFR: 8350009: [XWayland] SwingNodePlatformExitCrashTest hangs on
 Ubuntu 24.04
In-Reply-To: <iJQT2nk6Ipc_FfiJZPDMmgsKy4J4PHZYnzufuLuaTNM=.6e92de90-7143-4982-a68d-c9987d94a4be@github.com>
References: <iJQT2nk6Ipc_FfiJZPDMmgsKy4J4PHZYnzufuLuaTNM=.6e92de90-7143-4982-a68d-c9987d94a4be@github.com>
Message-ID: <FkJY5-zJouVG4MqQaCj67ygRW4b7LuxENbBglF1y4_k=.541ab217-6e4c-43e3-9bc6-4b154bed224a@github.com>

On Tue, 1 Apr 2025 15:51:07 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> SwingNodePlatformExitCrashTest hangs on Ubuntu 24.04 and wayland when we use < JDK 24.
> 
> This is happening because of issue identified in https://bugs.openjdk.org/browse/JDK-8335468 and it is fixed in JDK 24.
> So we need to run this test on wayland only when we use JDK 24 or later.
> Test is updated and verified that it works appropriately now on Ubuntu 24.04.

Looks good. I confirm that without this fix, the test hangs when using JDK 23 to run it and passes using JDK 24. With your fix, the test is skipped when using JDK 23 and still passes using JDK 24.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1753#pullrequestreview-2733520958

From angorya at openjdk.org  Tue Apr  1 17:35:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 1 Apr 2025 17:35:22 GMT
Subject: RFR: 8245602: Ensemble8: HTMLEditor Toolbar gets scrolled out of
 view
In-Reply-To: <i5KZzkR5fsUwTcXq9l0hvB8CGYsykOfGuqrydwF53oc=.4399fc6c-6041-4cf2-a78d-27b054ca4dfa@github.com>
References: <i5KZzkR5fsUwTcXq9l0hvB8CGYsykOfGuqrydwF53oc=.4399fc6c-6041-4cf2-a78d-27b054ca4dfa@github.com>
Message-ID: <M4meCl4ERJPUbrA_y0plDCdUz0RhrdWW94lke44BNRE=.f101243a-1a0b-405a-b8ef-0b4ce0d9998f@github.com>

On Tue, 1 Apr 2025 06:47:59 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

> There was a scrolling issue with multiline edit control with text controls at the top of the edit box [JDK-8245602](https://bugs.openjdk.org/browse/JDK-8245602),
> 
> We replaced the ScrollPane with VBox control as the parent of the html edit control.
> 
> Verification:
> This makes the controls on the top of the edit control, And the texts scroll inside the text area as expected.
> Similar kind of behavior is seen in normal web pages with multiline edit controls inside it.

I'll take a look.

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

PR Comment: https://git.openjdk.org/jfx/pull/1752#issuecomment-2770201895

From jpereda at openjdk.org  Tue Apr  1 17:35:34 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Tue, 1 Apr 2025 17:35:34 GMT
Subject: RFR: 8207333: [linux] Column sorting is triggered always after context
 menu request on table header
Message-ID: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>

Note: The JBS issue [JDK-8207333](https://bugs.openjdk.org/browse/JDK-8207333) refers to Linux, but it happens on macOS too. 

When a TableColumn has a ContextMenu, if the user right clicks on the tableColumnHeader, the ContextMenu shows up, but, as described on the issue, on macOS and Linux, the table gets sorted as well.

Currently, `TableColumnHeader#mouseReleasedHandler` checks for `MouseEvent::isPopupTriggered`, but it doesn't have a check on `mousePressed`. However,  it can be seen that a right click on the header has the following values for `MouseEvent:: isPopupTriggered` on the different platforms and mouse pressed and released events:

| isPopupTriggered on: | Windows  | macOS | Linux |
| ------------- | ------------- | ------------- | ------------- |
| mousePressed  | false  | true | true |
| mouseReleased  | true  | false | false?|

Also, the JavaDoc for `MouseEvent:: isPopupTriggered` clearly states that:

> **Note**: Popup menus are triggered differently on different systems. Therefore, `popupTrigger` should be checked in both `onMousePressed` and `mouseReleased` for proper cross-platform functionality.

Therefore, this PR adds a check to `MouseEvent::isPopupTrigger` in the mouse pressed event, that can be used later on to cancel the header sorting when the mouse released event happens.

Also a system test has been added. It fails on macOS and Linux, and passes on Windows before this PR, and passes on the three platforms with this PR.

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

Commit messages:
 - Check popupTrigger on mouse pressed too for tableColumnHeaders

Changes: https://git.openjdk.org/jfx/pull/1754/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1754&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8207333
  Stats: 164 lines in 2 files changed: 162 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1754.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1754/head:pull/1754

PR: https://git.openjdk.org/jfx/pull/1754

From angorya at openjdk.org  Tue Apr  1 17:42:28 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 1 Apr 2025 17:42:28 GMT
Subject: RFR: 8207333: [linux] Column sorting is triggered always after
 context menu request on table header
In-Reply-To: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
Message-ID: <Xy2pVJrvV0tysZcR6IynGZYUrcuw7DlgpOcdPJt-aVo=.0a6e3afe-91b7-4797-88f7-41568cb75ae2@github.com>

On Tue, 1 Apr 2025 17:31:14 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> Note: The JBS issue [JDK-8207333](https://bugs.openjdk.org/browse/JDK-8207333) refers to Linux, but it happens on macOS too. 
> 
> When a TableColumn has a ContextMenu, if the user right clicks on the tableColumnHeader, the ContextMenu shows up, but, as described on the issue, on macOS and Linux, the table gets sorted as well.
> 
> Currently, `TableColumnHeader#mouseReleasedHandler` checks for `MouseEvent::isPopupTriggered`, but it doesn't have a check on `mousePressed`. However,  it can be seen that a right click on the header has the following values for `MouseEvent:: isPopupTriggered` on the different platforms and mouse pressed and released events:
> 
> | isPopupTriggered on: | Windows  | macOS | Linux |
> | ------------- | ------------- | ------------- | ------------- |
> | mousePressed  | false  | true | true |
> | mouseReleased  | true  | false | false?|
> 
> Also, the JavaDoc for `MouseEvent::isPopupTriggered` clearly states that:
> 
>> **Note**: Popup menus are triggered differently on different systems. Therefore, `popupTrigger` should be checked in both `onMousePressed` and `mouseReleased` for proper cross-platform functionality.
> 
> Therefore, this PR adds a check to `MouseEvent::isPopupTrigger` in the mouse pressed event, that can be used later on to cancel the header sorting when the mouse released event happens.
> 
> Also a system test has been added. It fails on macOS and Linux, and passes on Windows before this PR, and passes on the three platforms with this PR.

I'll take a look.
Should we update the JBS and this PR title to remove `[linux]` as it applies to both platforms?

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

PR Comment: https://git.openjdk.org/jfx/pull/1754#issuecomment-2770219261

From angorya at openjdk.org  Tue Apr  1 17:47:15 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 1 Apr 2025 17:47:15 GMT
Subject: RFR: 8245602: Ensemble8: HTMLEditor Toolbar gets scrolled out of
 view
In-Reply-To: <i5KZzkR5fsUwTcXq9l0hvB8CGYsykOfGuqrydwF53oc=.4399fc6c-6041-4cf2-a78d-27b054ca4dfa@github.com>
References: <i5KZzkR5fsUwTcXq9l0hvB8CGYsykOfGuqrydwF53oc=.4399fc6c-6041-4cf2-a78d-27b054ca4dfa@github.com>
Message-ID: <S5ATSnIJCywfLwbK3LWWVwWpNh7hdHR8RjqS2Jkne5s=.9c168092-7fa4-446b-9f8c-5b1da3cdea32@github.com>

On Tue, 1 Apr 2025 06:47:59 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

> There was a scrolling issue with multiline edit control with text controls at the top of the edit box [JDK-8245602](https://bugs.openjdk.org/browse/JDK-8245602),
> 
> We replaced the ScrollPane with VBox control as the parent of the html edit control.
> 
> Verification:
> This makes the controls on the top of the edit control, And the texts scroll inside the text area as expected.
> Similar kind of behavior is seen in normal web pages with multiline edit controls inside it.

the change fixes the issue at hand.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1752#pullrequestreview-2733567667

From kcr at openjdk.org  Tue Apr  1 17:50:14 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 1 Apr 2025 17:50:14 GMT
Subject: RFR: 8350976: MenuBarSkin: exception initializing in a background
 thread [v2]
In-Reply-To: <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
References: <rlPnhzYl_h3-WkWw7gxtdN8n5JKBVqgyu9HzWkUan8c=.5839a05f-0331-4437-bcc1-77169cdd00c8@github.com>
 <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
Message-ID: <hUwjuEHe0JGTBO1YInUHaTf7dh2-8QT1sl2Qsy1f_Vk=.f3e1093a-607c-4850-a2fd-3404b3044792@github.com>

On Wed, 5 Mar 2025 18:19:53 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Allows MenuBar to be created in a background thread by delaying MenuBarSkin::rebuildUI() call until after the MenuBar becomes a part of the scene graph.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8350976.menubarskin.thread.safety
>  - spelling
>  - use system menu
>  - cleanup
>  - possible fix
>  - test

I also have macOS 14 (14.7.4 to be exact). `NodeInitializationStressTest.menuBar` test fails consistently for me without this fix and passes with the fix.

@jayathirthrao Can you double-check that you were actually running the version of the test from this PR (without the fix)? The easiest way to do that, which will also save you a bunch of time, is to run just that one test method (although it fails for me if I run the whole thing, `NodeInitializationStressTest` takes nearly 10 minutes on my system).


gradle --continue --info -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:cleanTest :systemTests:test \
--tests test.robot.javafx.scene.NodeInitializationStressTest.menuBar

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

PR Comment: https://git.openjdk.org/jfx/pull/1727#issuecomment-2770237809

From angorya at openjdk.org  Tue Apr  1 17:51:23 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 1 Apr 2025 17:51:23 GMT
Subject: RFR: 8245602: Ensemble8: HTMLEditor Toolbar gets scrolled out of
 view
In-Reply-To: <i5KZzkR5fsUwTcXq9l0hvB8CGYsykOfGuqrydwF53oc=.4399fc6c-6041-4cf2-a78d-27b054ca4dfa@github.com>
References: <i5KZzkR5fsUwTcXq9l0hvB8CGYsykOfGuqrydwF53oc=.4399fc6c-6041-4cf2-a78d-27b054ca4dfa@github.com>
Message-ID: <L2c900JfnPf5IS0sXKLqJ7G0ZebaYDz7AleuWK1JcKQ=.8da8e61e-c83b-490f-95b3-1baeb69d65a4@github.com>

On Tue, 1 Apr 2025 06:47:59 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

> There was a scrolling issue with multiline edit control with text controls at the top of the edit box [JDK-8245602](https://bugs.openjdk.org/browse/JDK-8245602),
> 
> We replaced the ScrollPane with VBox control as the parent of the html edit control.
> 
> Verification:
> This makes the controls on the top of the edit control, And the texts scroll inside the text area as expected.
> Similar kind of behavior is seen in normal web pages with multiline edit controls inside it.

A general comment (tangentially related to the issue): the layout could be better in utilizing the available space:

![Screenshot 2025-04-01 at 10 37 01](https://github.com/user-attachments/assets/f852885d-8aba-46cb-b7e4-1d3a504711fb)
![Screenshot 2025-04-01 at 10 37 11](https://github.com/user-attachments/assets/80c668b0-a8e4-4811-b88f-19e2f28f6e34)
![Screenshot 2025-04-01 at 10 37 27](https://github.com/user-attachments/assets/cad80822-3ae1-4acb-af85-9c2a371c385a)

This fix is simple enough, 1 reviewer is probably sufficient.

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

PR Comment: https://git.openjdk.org/jfx/pull/1752#issuecomment-2770241601
PR Comment: https://git.openjdk.org/jfx/pull/1752#issuecomment-2770244367

From angorya at openjdk.org  Tue Apr  1 17:54:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 1 Apr 2025 17:54:16 GMT
Subject: RFR: 8350976: MenuBarSkin: exception initializing in a background
 thread [v2]
In-Reply-To: <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
References: <rlPnhzYl_h3-WkWw7gxtdN8n5JKBVqgyu9HzWkUan8c=.5839a05f-0331-4437-bcc1-77169cdd00c8@github.com>
 <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
Message-ID: <zl2LcHOp2qqtYRKr6WGV6ByQSrC5uR3FHRfjbOfg-tw=.7ecabc0e-ba0d-48c2-a393-aa6cbab3fbae@github.com>

On Wed, 5 Mar 2025 18:19:53 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Allows MenuBar to be created in a background thread by delaying MenuBarSkin::rebuildUI() call until after the MenuBar becomes a part of the scene graph.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8350976.menubarskin.thread.safety
>  - spelling
>  - use system menu
>  - cleanup
>  - possible fix
>  - test

`javafx.graphics/com.sun.glass.ui.Application.checkEventThread()` throws an IllegalStateException since 2013, and probably earlier than that.

The only way this functionality is suppressed is when `glass.disableThreadChecks` system property is set to `true`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1727#issuecomment-2770249357

From angorya at openjdk.org  Tue Apr  1 17:57:34 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 1 Apr 2025 17:57:34 GMT
Subject: RFR: 8207333: [linux] Column sorting is triggered always after
 context menu request on table header
In-Reply-To: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
Message-ID: <tJCt9tsrSrVhLvzGcgRKTJHSSNayqHDZP48tlY8RO4Y=.cd22e302-1ea9-4573-9e78-0c690726d833@github.com>

On Tue, 1 Apr 2025 17:31:14 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> Note: The JBS issue [JDK-8207333](https://bugs.openjdk.org/browse/JDK-8207333) refers to Linux, but it happens on macOS too. 
> 
> When a TableColumn has a ContextMenu, if the user right clicks on the tableColumnHeader, the ContextMenu shows up, but, as described on the issue, on macOS and Linux, the table gets sorted as well.
> 
> Currently, `TableColumnHeader#mouseReleasedHandler` checks for `MouseEvent::isPopupTriggered`, but it doesn't have a check on `mousePressed`. However,  it can be seen that a right click on the header has the following values for `MouseEvent:: isPopupTriggered` on the different platforms and mouse pressed and released events:
> 
> | isPopupTriggered on: | Windows  | macOS | Linux |
> | ------------- | ------------- | ------------- | ------------- |
> | mousePressed  | false  | true | true |
> | mouseReleased  | true  | false | false?|
> 
> Also, the JavaDoc for `MouseEvent::isPopupTriggered` clearly states that:
> 
>> **Note**: Popup menus are triggered differently on different systems. Therefore, `popupTrigger` should be checked in both `onMousePressed` and `mouseReleased` for proper cross-platform functionality.
> 
> Therefore, this PR adds a check to `MouseEvent::isPopupTrigger` in the mouse pressed event, that can be used later on to cancel the header sorting when the mouse released event happens.
> 
> Also a system test has been added. It fails on macOS and Linux, and passes on Windows before this PR, and passes on the three platforms with this PR.

I can only test it on macOS and Windows.  Could someone with a linux system help please?

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

PR Comment: https://git.openjdk.org/jfx/pull/1754#issuecomment-2770256133

From kcr at openjdk.org  Tue Apr  1 18:05:38 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 1 Apr 2025 18:05:38 GMT
Subject: RFR: 8350976: MenuBarSkin: exception initializing in a background
 thread [v2]
In-Reply-To: <zl2LcHOp2qqtYRKr6WGV6ByQSrC5uR3FHRfjbOfg-tw=.7ecabc0e-ba0d-48c2-a393-aa6cbab3fbae@github.com>
References: <rlPnhzYl_h3-WkWw7gxtdN8n5JKBVqgyu9HzWkUan8c=.5839a05f-0331-4437-bcc1-77169cdd00c8@github.com>
 <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
 <zl2LcHOp2qqtYRKr6WGV6ByQSrC5uR3FHRfjbOfg-tw=.7ecabc0e-ba0d-48c2-a393-aa6cbab3fbae@github.com>
Message-ID: <riBmmbCSMGk-xUt3vOQkCn3i3Drb-z-uL2E1HR6Y89U=.129d0056-b578-48c8-8ea0-7a629a952786@github.com>

On Tue, 1 Apr 2025 17:51:15 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> The only way this functionality is suppressed is when glass.disableThreadChecks system property is set to true.

There is no easy way to set this, so I'm almost certain that isn't the case here. Jay can confirm, but I think there is a much easier explanation: I suspect that it didn't run the new test method in question. Thus my earlier comment above about running that test in isolation.

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

PR Comment: https://git.openjdk.org/jfx/pull/1727#issuecomment-2770280906

From angorya at openjdk.org  Tue Apr  1 18:09:08 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 1 Apr 2025 18:09:08 GMT
Subject: RFR: 8350976: MenuBarSkin: exception initializing in a background
 thread [v2]
In-Reply-To: <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
References: <rlPnhzYl_h3-WkWw7gxtdN8n5JKBVqgyu9HzWkUan8c=.5839a05f-0331-4437-bcc1-77169cdd00c8@github.com>
 <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
Message-ID: <7Jy-SPl2ZF6XmCoT-MQsgm2kKdmXv7oIJoknTKB5xrI=.62a9e244-b371-4d6e-83d8-74d90a97d52a@github.com>

On Wed, 5 Mar 2025 18:19:53 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Allows MenuBar to be created in a background thread by delaying MenuBarSkin::rebuildUI() call until after the MenuBar becomes a part of the scene graph.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8350976.menubarskin.thread.safety
>  - spelling
>  - use system menu
>  - cleanup
>  - possible fix
>  - test

I ran his `gradle` command and it failed as expected.  Maybe Jay ran it in some other directory?

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

PR Comment: https://git.openjdk.org/jfx/pull/1727#issuecomment-2770288718

From kcr at openjdk.org  Tue Apr  1 18:21:07 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 1 Apr 2025 18:21:07 GMT
Subject: RFR: 8352999: [macOS] Conditional behavior by directly querying
 the Objective-C call stack
In-Reply-To: <zbgaETsVLGXADa6CiIUh5vxMQwL0V3538SgjN_bqeqg=.f047ecab-0d6b-4e9b-aa6b-bc473e9dba25@github.com>
References: <zbgaETsVLGXADa6CiIUh5vxMQwL0V3538SgjN_bqeqg=.f047ecab-0d6b-4e9b-aa6b-bc473e9dba25@github.com>
Message-ID: <W5VIF_st-jWoz7mDVc0Z9H_h76KtbfNhEx6YJFTO_E8=.d5100866-09a9-403b-b9a1-c43c84dc458f@github.com>

On Mon, 31 Mar 2025 18:29:21 GMT, Martin Fox <mfox at openjdk.org> wrote:

> Before a window is maximized glass records its existing size and location. This rectangle is stored in native screen coordinates. Compared to Java screen coordinates native coordinates are flipped along the Y axis.
> 
> When the window is un-maximized that native rectangle is passed to a routine that normally takes Java screen coordinates. To determine whether the rectangle is flipped or not the code inspects the Objective-C stack to figure out which routine called it.
> 
> At the risk of re-writing working code this PR takes a more conventional approach to the problem.
> 
> I?ve also re-enabled the related system test. I had to increase the animation delay to get it to pass on the Mac. 400 milliseconds is enough but 500 gives us some headroom.

Seems like a good idea to get rid of what looks like very "questionable" code.

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

PR Comment: https://git.openjdk.org/jfx/pull/1749#issuecomment-2770317924

From angorya at openjdk.org  Tue Apr  1 18:39:29 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 1 Apr 2025 18:39:29 GMT
Subject: RFR: 8207333: [linux] Column sorting is triggered always after
 context menu request on table header
In-Reply-To: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
Message-ID: <fitRlk8nc56xc4-UMLNFRn8PnIKq-jP38dCYg3goQnA=.081c4c96-ed3a-4546-8ce6-6f140e6d0731@github.com>

On Tue, 1 Apr 2025 17:31:14 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> Note: The JBS issue [JDK-8207333](https://bugs.openjdk.org/browse/JDK-8207333) refers to Linux, but it happens on macOS too. 
> 
> When a TableColumn has a ContextMenu, if the user right clicks on the tableColumnHeader, the ContextMenu shows up, but, as described on the issue, on macOS and Linux, the table gets sorted as well.
> 
> Currently, `TableColumnHeader#mouseReleasedHandler` checks for `MouseEvent::isPopupTriggered`, but it doesn't have a check on `mousePressed`. However,  it can be seen that a right click on the header has the following values for `MouseEvent:: isPopupTriggered` on the different platforms and mouse pressed and released events:
> 
> | isPopupTriggered on: | Windows  | macOS | Linux |
> | ------------- | ------------- | ------------- | ------------- |
> | mousePressed  | false  | true | true |
> | mouseReleased  | true  | false | false?|
> 
> Also, the JavaDoc for `MouseEvent::isPopupTriggered` clearly states that:
> 
>> **Note**: Popup menus are triggered differently on different systems. Therefore, `popupTrigger` should be checked in both `onMousePressed` and `mouseReleased` for proper cross-platform functionality.
> 
> Therefore, this PR adds a check to `MouseEvent::isPopupTrigger` in the mouse pressed event, that can be used later on to cancel the header sorting when the mouse released event happens.
> 
> Also a system test has been added. It fails on macOS and Linux, and passes on Windows before this PR, and passes on the three platforms with this PR.

thank you for fixing this bug, @jperedadnr !

testing with the monkey tester looks good on macOS 15.3.2 and windows 11.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1754#pullrequestreview-2733727401

From jhendrikx at openjdk.org  Tue Apr  1 19:43:19 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 1 Apr 2025 19:43:19 GMT
Subject: Integrated: 8351047: TitledPane should handle titles that are
 resizable
In-Reply-To: <VhqVuIpZvCg2LhyfnYRn80rhB7iHa2uEHED40VVi-2s=.f3093612-690a-4a72-b27f-b5ed02acfb0c@github.com>
References: <VhqVuIpZvCg2LhyfnYRn80rhB7iHa2uEHED40VVi-2s=.f3093612-690a-4a72-b27f-b5ed02acfb0c@github.com>
Message-ID: <UZYFweeDDAVyVvlcYb6d_TXz-Kl6AZokq3Wozj2JMpg=.672b0005-18f4-4d8f-b08c-459038aa56a7@github.com>

On Sat, 22 Mar 2025 12:20:17 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This PR will forward more Label calculations to LabeledSkinBase, as they are quite complex, especially when a Graphic is involved which is a full-fledged `Node`. More specifically, this solves issues with TitledPane when the graphic is resizable (ie. an HBox is placed as Graphic in the titled pane's title area).  Before, the calculations would only look at the preferred size of the graphic, and use these regardless of available space, even if the maximum size allowed for the graphic to be larger. After this fix, the more extensive LabeledSkinBase calculations are used.
> 
> This PR also simplifies the layout calculation.  Instead of manually calculating where the label should be positioned (according to alignment), this is left to `layoutLabelInArea` which will do this automatically when its provided with the available space for the label instead of the label's width.
> 
> See the ticket for a sample program; take a look at the graphic-only case where an HBox is used to put a label + gap + button as the graphic of the titled pane.

This pull request has now been integrated.

Changeset: cc949cd0
Author:    John Hendrikx <jhendrikx at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/cc949cd0c26ade3754906e5ff932b1a14a6ea902
Stats:     136 lines in 1 file changed: 40 ins; 89 del; 7 mod

8351047: TitledPane should handle titles that are resizable

Reviewed-by: angorya, mstrauss

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

PR: https://git.openjdk.org/jfx/pull/1742

From kcr at openjdk.org  Tue Apr  1 20:14:37 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 1 Apr 2025 20:14:37 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v3]
In-Reply-To: <OQ2S6cYNrQGoLP9c7ZB2_4zBi08ET_WBw0SLX6b8sHI=.099b388e-cc36-400c-b057-e4ae47dff034@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <OQ2S6cYNrQGoLP9c7ZB2_4zBi08ET_WBw0SLX6b8sHI=.099b388e-cc36-400c-b057-e4ae47dff034@github.com>
Message-ID: <X2YcvgaLHi03iTJUjSco8vO917zb-MSlqGe9_rfpU2U=.41643344-f983-4fd0-844c-136f1fc8739a@github.com>

On Mon, 31 Mar 2025 18:35:03 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.
>> 
>> The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.
>> 
>> The log contains a base-64 encoded screenshot (like this: `data:image/png;base64,iVBORw0KGgoAAAANSUhEU...` )
>> so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)
>> 
>> Example:
>> 
>> ![jenkins-screenshot](https://github.com/user-attachments/assets/abebd76f-747a-4d6d-a9a6-63c6e9426830)
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   data url

I tested this by injecting a failure into one of the Robot screen capture tests, `RectangleTest` (see the patch I applied below):

While it did trigger the screen shot, the rendered window had already been closed before the screen shot was taken, meaning it didn't capture the screen at the point of failure. This suggests that the test watcher doesn't get called until after the `@AfterEach` method has run. Since a well-written test will cleanup after itself in the `@AfterEach` method, this will limit the usefulness of doing it via an annotation. Is there an option or some other annotation that will allow us to intercept at the point of failure?



--- a/tests/system/src/test/java/test/robot/helloworld/RectangleTest.java
+++ b/tests/system/src/test/java/test/robot/helloworld/RectangleTest.java
@@ -34,10 +34,13 @@ import javafx.stage.Stage;
 import org.junit.jupiter.api.Test;
 import org.junit.jupiter.api.Timeout;
 import test.robot.testharness.VisualTestBase;
+import org.junit.jupiter.api.extension.ExtendWith;
+import test.util.ScreenCaptureTestWatcher;

 /**
  * Basic visual tests using glass Robot to sample pixels.
  */
+ at ExtendWith(ScreenCaptureTestWatcher.class)
 @Timeout(value=15000, unit=TimeUnit.MILLISECONDS)
 public class RectangleTest extends VisualTestBase {

@@ -79,7 +82,7 @@ public class RectangleTest extends VisualTestBase {
         waitFirstFrame();
         runAndWait(() -> {
             Color color = getColor(testScene, WIDTH / 2, HEIGHT / 2);
-            assertColorEquals(Color.CORNFLOWERBLUE, color, TOLERANCE);
+            assertColorEquals(Color.GREEN, color, TOLERANCE);
         });
     }

tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 59:

> 57:     public void testFailed(ExtensionContext extensionContext, Throwable err) {
> 58:         // can be pasted into Safari address bar
> 59:         System.err.println(generateScreenshot("Screenshot:{\ndata:image/png;base64,", null));

I'm not sure if an inline base64-encoded image -- between 2 and 3 megabytes of ascii text that needs to be copy/pasted -- is the best choice from a usability point of view. Have you considered writing PNG files? One drawback of  my suggestion is that getting it back from a remote Jenkins build is more complicated.

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

PR Review: https://git.openjdk.org/jfx/pull/1746#pullrequestreview-2733900908
PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2023588701

From kcr at openjdk.org  Tue Apr  1 20:14:37 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 1 Apr 2025 20:14:37 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v3]
In-Reply-To: <rMoa3GU-CTt53qX-3pfBhgzPg3toFwkncJ2HCWXktZE=.04e226e8-8fb5-426c-beba-97c8df5ed329@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <qDP0hIdl0xmGt47bTS8B0AZKLGcSN3pxPWUJo1vmqCQ=.9301440a-6a4a-4cb2-a843-a2914682f3df@github.com>
 <W6i3URblcpspzWvt65Xdabwt-JKNMj3hTwudiugN1zU=.afe3cbb0-02b0-4791-a256-2b60961236f6@github.com>
 <v6Z5pWtUrvtNBBUdkZGZlkSmqCV_WTumuN7L2SIdZPY=.1a3606e4-d396-4c5f-a619-f2c0b267d0d0@github.com>
 <rMoa3GU-CTt53qX-3pfBhgzPg3toFwkncJ2HCWXktZE=.04e226e8-8fb5-426c-beba-97c8df5ed329@github.com>
Message-ID: <KYQjRuffM99O0l5poNAFTTd-KhO0bvca__yQX0e1clc=.83f5da74-cd6c-4edc-b803-9917a01e17bf@github.com>

On Mon, 31 Mar 2025 16:59:31 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Hmm. That isn't what I thought we were doing. I thought the idea was to annotate most (if not all all) screen capture tests, qualified by a system property, enable that property in our CI test runs, so that when we do get intermittent failures, we'll be able to take a look at them.
>> 
>> We _could_ to what you propose, but in that case I wouldn't want _any_ tests annotated as part of this or any other PR. Once we have this annotation on any test in our repo, then my objection about not having it on by default needs to be addressed, at which point you might as well annotate more tests, since we have seen occasional failures on many of them.
>
> There is more than one way to sk^H^H pet the cat.
> 
> We could use a property to disable (or rather, enable) the screenshots, and only enable the capture during the debugging session.  This will prevent us from catching those hard-to-reproduce intermittent tests that fail only occasionally.
> 
> The other concern is that in the case of some infrastructure misconfiguration (for example, a sudden loss of screen capture permission) would result in log file size explosion, and I don't think we have `tailwatch`-like facility to halt the test run when this happens.
> 
> I think the debug-only annotation is a meaningful compromise, but I would very much welcome other ideas.
> 
> (I am ok with removing the annotation from two tests that currently use it).

Yes, there are two main approaches we could take:

Option 1: A utility that is available for developers to add to one or more specific tests in a branch in their personal fork when debugging failures in those tests. We would not add it to any test in the mainline repo in this case. Since it is a developer-only utility, it isn't necessary to have a system property to enable it.

Option 2: A utility that is added to all robot tests in the repo, with a flag to enable it (off by default).

There are pros / cons of each approach. The second approach is more likely to catch a failing test that fails rarely and would easily allow us to enable it and run it on a new platform (e.g., for testing a new version of macOS or Ubuntu), although it is also more prone to the "runaway" screenshot problem unless we can come up with a good way to limit it.

I left a couple usability questions that are independent of this. It probably makes sense to address those first and then come back to this.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2023612881

From angorya at openjdk.org  Tue Apr  1 20:42:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 1 Apr 2025 20:42:16 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v3]
In-Reply-To: <X2YcvgaLHi03iTJUjSco8vO917zb-MSlqGe9_rfpU2U=.41643344-f983-4fd0-844c-136f1fc8739a@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <OQ2S6cYNrQGoLP9c7ZB2_4zBi08ET_WBw0SLX6b8sHI=.099b388e-cc36-400c-b057-e4ae47dff034@github.com>
 <X2YcvgaLHi03iTJUjSco8vO917zb-MSlqGe9_rfpU2U=.41643344-f983-4fd0-844c-136f1fc8739a@github.com>
Message-ID: <jb5ZKcM9tSlwqZ7jFaLGj8HZPlyqnPdjd732NZslMNE=.d735416b-47a8-4d6a-bb4e-5b5b00808fb5@github.com>

On Tue, 1 Apr 2025 20:11:13 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This suggests that the test watcher doesn't get called until after the @AfterEach method has run.

That's entirely possible.  I suppose one can register a Thread::uncaughtExceptionHandler and call a static method, something like ScreenCapture::takeScreenshot() (to be added).

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

PR Comment: https://git.openjdk.org/jfx/pull/1746#issuecomment-2770628641

From angorya at openjdk.org  Tue Apr  1 20:46:12 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 1 Apr 2025 20:46:12 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v3]
In-Reply-To: <X2YcvgaLHi03iTJUjSco8vO917zb-MSlqGe9_rfpU2U=.41643344-f983-4fd0-844c-136f1fc8739a@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <OQ2S6cYNrQGoLP9c7ZB2_4zBi08ET_WBw0SLX6b8sHI=.099b388e-cc36-400c-b057-e4ae47dff034@github.com>
 <X2YcvgaLHi03iTJUjSco8vO917zb-MSlqGe9_rfpU2U=.41643344-f983-4fd0-844c-136f1fc8739a@github.com>
Message-ID: <tfgk_UM2N-AYq9a7VCGHXoXQivi3LPGXWfj-UBZycno=.331a3dfb-6e45-44fd-b29b-258a85f0bbae@github.com>

On Tue, 1 Apr 2025 19:51:16 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   data url
>
> tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 59:
> 
>> 57:     public void testFailed(ExtensionContext extensionContext, Throwable err) {
>> 58:         // can be pasted into Safari address bar
>> 59:         System.err.println(generateScreenshot("Screenshot:{\ndata:image/png;base64,", null));
> 
> I'm not sure if an inline base64-encoded image -- between 2 and 3 megabytes of ascii text that needs to be copy/pasted -- is the best choice from a usability point of view. Have you considered writing PNG files? One drawback of  my suggestion is that getting it back from a remote Jenkins build is more complicated.

yes, and you pointed to the problem exactly - not only it creates a difficult task of retrieving files from the remote system, require a [complex] cleanup schedule, as well as run a risk of losing the files after a while and impossibility of finding the right screenshot after the fact (sometimes much later).

at the same time, the suggested approach keeps the screenshot in the context, available for analysis at any point in time.  the only drawback is base-64 inflation of about 33-37% relative to the raw binary.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2023650628

From angorya at openjdk.org  Tue Apr  1 20:50:48 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 1 Apr 2025 20:50:48 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v3]
In-Reply-To: <KYQjRuffM99O0l5poNAFTTd-KhO0bvca__yQX0e1clc=.83f5da74-cd6c-4edc-b803-9917a01e17bf@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <qDP0hIdl0xmGt47bTS8B0AZKLGcSN3pxPWUJo1vmqCQ=.9301440a-6a4a-4cb2-a843-a2914682f3df@github.com>
 <W6i3URblcpspzWvt65Xdabwt-JKNMj3hTwudiugN1zU=.afe3cbb0-02b0-4791-a256-2b60961236f6@github.com>
 <v6Z5pWtUrvtNBBUdkZGZlkSmqCV_WTumuN7L2SIdZPY=.1a3606e4-d396-4c5f-a619-f2c0b267d0d0@github.com>
 <rMoa3GU-CTt53qX-3pfBhgzPg3toFwkncJ2HCWXktZE=.04e226e8-8fb5-426c-beba-97c8df5ed329@github.com>
 <KYQjRuffM99O0l5poNAFTTd-KhO0bvca__yQX0e1clc=.83f5da74-cd6c-4edc-b803-9917a01e17bf@github.com>
Message-ID: <WC3TwZrRthzO9rWzS4yNuJfXkHqBioUlqSv5vk8OWZI=.9fbf394b-3e41-41ae-b182-b63d1d99db3a@github.com>

On Tue, 1 Apr 2025 20:11:46 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> There is more than one way to sk^H^H pet the cat.
>> 
>> We could use a property to disable (or rather, enable) the screenshots, and only enable the capture during the debugging session.  This will prevent us from catching those hard-to-reproduce intermittent tests that fail only occasionally.
>> 
>> The other concern is that in the case of some infrastructure misconfiguration (for example, a sudden loss of screen capture permission) would result in log file size explosion, and I don't think we have `tailwatch`-like facility to halt the test run when this happens.
>> 
>> I think the debug-only annotation is a meaningful compromise, but I would very much welcome other ideas.
>> 
>> (I am ok with removing the annotation from two tests that currently use it).
>
> Yes, there are two main approaches we could take:
> 
> Option 1: A utility that is available for developers to add to one or more specific tests in a branch in their personal fork when debugging failures in those tests. We would not add it to any test in the mainline repo in this case. Since it is a developer-only utility, it isn't necessary to have a system property to enable it.
> 
> Option 2: A utility that is added to all robot tests in the repo, with a flag to enable it (off by default).
> 
> There are pros / cons of each approach. The second approach is more likely to catch a failing test that fails rarely and would easily allow us to enable it and run it on a new platform (e.g., for testing a new version of macOS or Ubuntu), although it is also more prone to the "runaway" screenshot problem unless we can come up with a good way to limit it.
> 
> I left a couple usability questions that are independent of this. It probably makes sense to address those first and then come back to this.

I would choose the Option 1 (debug utility), with an addition of a static `ScreenCapture.takeScreenshot()`.

I don't think there is a need to add this tool to the hundreds of tests which work just fine.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2023655635

From angorya at openjdk.org  Tue Apr  1 21:20:37 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 1 Apr 2025 21:20:37 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v3]
In-Reply-To: <OQ2S6cYNrQGoLP9c7ZB2_4zBi08ET_WBw0SLX6b8sHI=.099b388e-cc36-400c-b057-e4ae47dff034@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <OQ2S6cYNrQGoLP9c7ZB2_4zBi08ET_WBw0SLX6b8sHI=.099b388e-cc36-400c-b057-e4ae47dff034@github.com>
Message-ID: <2EIopJ4OMG_3VR_sHcLhFP-vOAkIDtjk1P8KCvX2BlY=.40d1c1cb-5480-49b4-9377-200dccbc6560@github.com>

On Mon, 31 Mar 2025 18:35:03 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.
>> 
>> The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.
>> 
>> The log contains a base-64 encoded screenshot (like this: `data:image/png;base64,iVBORw0KGgoAAAANSUhEU...` )
>> so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)
>> 
>> Example:
>> 
>> ![jenkins-screenshot](https://github.com/user-attachments/assets/abebd76f-747a-4d6d-a9a6-63c6e9426830)
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   data url

Turns out one can't intercept assertion exceptions with `Thread.setDefaultUncaughtExceptionHandler()` (duh!), so this is likely to be a known limitation.

We might still provide general purpose methods in `ScreenCapture` (new class) like 


    /**
     * Captures a screenshot using JavaFX {@link Robot} in the PNG format.
     * <p>
     * This method can be called from any thread.  If called from a thread other than
     * the JavaFX Application Thread, the current thread will be paused until the screenshot is taken.
     *
     * @return the byte array containing the screenshot
     * @throws IOException when an I/O error occurs
     */
    public static byte[] takeScreenshot() throws IOException {


and 


    /**
     * Captures a screenshot using JavaFX {@link Robot} in the PNG format,
     * in the form of a Base-64 encoded {@code String}.
     * <p>
     * This method can be called from any thread.  If called from a thread other than
     * the JavaFX Application Thread, the current thread will be paused until the screenshot is taken.
     *
     * @param prefix the string to append before the base-64 representation, or null
     * @param postfix the string to append after the base-64 representation, or null
     * @return the screenshot in Base-64 encoded PNG, or an error message
     */
    public static String takeScreenshotBase64(String prefix, String postfix) {


What do you think?

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

PR Comment: https://git.openjdk.org/jfx/pull/1746#issuecomment-2770707191

From mfox at openjdk.org  Tue Apr  1 21:50:29 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 1 Apr 2025 21:50:29 GMT
Subject: Integrated: 8351733: Crash when creating too many nested event loops
In-Reply-To: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
Message-ID: <q76XKzjex8i2h-bPhOMurXScldT0w6KEyEYmA3UpjZo=.fdf5d5c6-426c-455b-9284-c8a4cccd7891@github.com>

On Fri, 21 Mar 2025 20:56:01 GMT, Martin Fox <mfox at openjdk.org> wrote:

> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
> 
> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
> 
> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.

This pull request has now been integrated.

Changeset: c452189e
Author:    Martin Fox <mfox at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/c452189e54124a941201bfa4d68830f7a6d65333
Stats:     78 lines in 5 files changed: 76 ins; 0 del; 2 mod

8351733: Crash when creating too many nested event loops

Reviewed-by: kcr, angorya

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

PR: https://git.openjdk.org/jfx/pull/1741

From kcr at openjdk.org  Tue Apr  1 22:44:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 1 Apr 2025 22:44:57 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v3]
In-Reply-To: <2EIopJ4OMG_3VR_sHcLhFP-vOAkIDtjk1P8KCvX2BlY=.40d1c1cb-5480-49b4-9377-200dccbc6560@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <OQ2S6cYNrQGoLP9c7ZB2_4zBi08ET_WBw0SLX6b8sHI=.099b388e-cc36-400c-b057-e4ae47dff034@github.com>
 <2EIopJ4OMG_3VR_sHcLhFP-vOAkIDtjk1P8KCvX2BlY=.40d1c1cb-5480-49b4-9377-200dccbc6560@github.com>
Message-ID: <WDLXSGolTRT60rkhN2cV_Sd1k8u7j_4TmW6lSdHJxzY=.a62e23da-f9fc-499d-a18e-a612c14f1aec@github.com>

On Tue, 1 Apr 2025 21:17:35 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> We might still provide general purpose methods in ScreenCapture (new class) like

That might work. So the idea would be a utility class not tied to a JUnit5 annotation? The usage would then be adding a call to that while debugging a test wherever it makes sense for your test, possible from an AfterEach method.

>     public static byte[] takeScreenshot() throws IOException {

What would this do? I can see the usefulness of returning a WritableImage (basically calling `Robot::getScreenCapture` on the whole screen) or a base64-encoded PNG file, but what does it mean to return a raw byte array? I probably wouldn't recommend this one.

>     public static String takeScreenshotBase64(String prefix, String postfix) {

This seems useful, although what are "prefix" and "postfix" for?

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

PR Comment: https://git.openjdk.org/jfx/pull/1746#issuecomment-2770843700

From angorya at openjdk.org  Tue Apr  1 22:44:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 1 Apr 2025 22:44:57 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v4]
In-Reply-To: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
Message-ID: <EhxCbcV0JSuKF2mbF-IICNBg9lqPh3isHYbRgliSOjY=.4615f1fb-dcc8-4260-aa9e-f9768a52b76d@github.com>

> Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.
> 
> The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.
> 
> The log contains a base-64 encoded screenshot (like this: `data:image/png;base64,iVBORw0KGgoAAAANSUhEU...` )
> so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)
> 
> Example:
> 
> ![jenkins-screenshot](https://github.com/user-attachments/assets/abebd76f-747a-4d6d-a9a6-63c6e9426830)

Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:

 - cleanup
 - screen capture

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1746/files
  - new: https://git.openjdk.org/jfx/pull/1746/files/5e184b0d..02c185f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1746&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1746&range=02-03

  Stats: 199 lines in 2 files changed: 150 ins; 48 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1746.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1746/head:pull/1746

PR: https://git.openjdk.org/jfx/pull/1746

From arapte at openjdk.org  Wed Apr  2 00:28:36 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 2 Apr 2025 00:28:36 GMT
Subject: RFR: 8352982: gradle TEST_SDK_PATH param doesn't work with
 relative paths
In-Reply-To: <_b7HCKmYx8H-Ec_GdVyX4fmgUUUFOzghdQeZgGeEIZw=.5be185c8-5ac5-4991-bb4b-255c1522500f@github.com>
References: <nQBSuBQvVW0itJLRR-Cs0TOm6ymltaWG-2BufQky1xI=.b39146a4-4f68-4459-929a-6b54d4ba0437@github.com>
 <_b7HCKmYx8H-Ec_GdVyX4fmgUUUFOzghdQeZgGeEIZw=.5be185c8-5ac5-4991-bb4b-255c1522500f@github.com>
Message-ID: <O6D5WNhZI-UevzRby4dF_wro0rxRfbbDtVJffOe32XQ=.34299376-8a07-403e-9bd3-38060aa39269@github.com>

On Tue, 1 Apr 2025 12:31:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Issue:
>> The test execution fails when a relative path is specified a relative path for `TEST_SDK_PATH`.
>> For example:
>> 1. gradle -PTEST_ONLY=true -PTEST_SDK_PATH=**..**/jfx1/build test 
>> 2. gradle -PTEST_ONLY=true -PTEST_SDK_PATH=**~**/jfx1/build test
>> 
>> Solution:
>> Convert the relative path to an absolute path.
>> 
>> More about fix:
>> The property TEST_SDK_PATH belongs to the root project rt in build.gradle.
>> If we modify this property in build.gradle, it does not reflect in the child projects. The child projects for example graphics, controls would still have the value of TEST_SDK_PATH before modification.
>> To solve this, I Introduced a new variable in build.gradle `TEST_SDK_DIR`. It would hold the modified value of `TEST_SDK_PATH` and gets correctly reflected across all sub-projects.
>> 
>> Verified that both relative paths and absolute path work fine after this change.
>
> build.gradle line 729:
> 
>> 727:     }
>> 728:     String testSdkPath = "${TEST_SDK_PATH}"
>> 729:     if (testSdkPath.startsWith("~")) {
> 
> This isn't related to handling relative paths at all. Rather it is related to how bash works. The `~` character is handled by the shell and it is a known limitation that you can't use it in the middle of a string.

Thanks Kevin, I shall remove the part related to `~`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1751#discussion_r2023838838

From jdv at openjdk.org  Wed Apr  2 06:10:20 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 2 Apr 2025 06:10:20 GMT
Subject: RFR: 8350976: MenuBarSkin: exception initializing in a background
 thread [v2]
In-Reply-To: <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
References: <rlPnhzYl_h3-WkWw7gxtdN8n5JKBVqgyu9HzWkUan8c=.5839a05f-0331-4437-bcc1-77169cdd00c8@github.com>
 <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
Message-ID: <YGlbBy8aM3b4uB3t2f31N7hovUPxHOzwgVOcoYOVdxE=.da95f474-789d-4e6a-a334-8162cb43510a@github.com>

On Wed, 5 Mar 2025 18:19:53 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Allows MenuBar to be created in a background thread by delaying MenuBarSkin::rebuildUI() call until after the MenuBar becomes a part of the scene graph.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8350976.menubarskin.thread.safety
>  - spelling
>  - use system menu
>  - cleanup
>  - possible fix
>  - test

Marked as reviewed by jdv (Committer).

For test verification i was following what i do in JDK of checking out the branch in the PR and without build verify that the test fails and then build the branch(which will build source code change also) and then make sure test passes.

Got to know that we need to use -PTEST_ONLY=true in FX to make sure that source code changes are not built when i use gradle to run the test. With this approach i can see that the test fails without product change and passes with it :)

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

PR Review: https://git.openjdk.org/jfx/pull/1727#pullrequestreview-2734751229
PR Comment: https://git.openjdk.org/jfx/pull/1727#issuecomment-2771426392

From jdv at openjdk.org  Wed Apr  2 06:13:07 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 2 Apr 2025 06:13:07 GMT
Subject: Integrated: 8350009: [XWayland] SwingNodePlatformExitCrashTest hangs
 on Ubuntu 24.04
In-Reply-To: <iJQT2nk6Ipc_FfiJZPDMmgsKy4J4PHZYnzufuLuaTNM=.6e92de90-7143-4982-a68d-c9987d94a4be@github.com>
References: <iJQT2nk6Ipc_FfiJZPDMmgsKy4J4PHZYnzufuLuaTNM=.6e92de90-7143-4982-a68d-c9987d94a4be@github.com>
Message-ID: <M5Bjh7TF6KOJokKyQ6jmujusyjKyS6TsO0r5vAS_AVY=.b81b19f0-7e15-4b54-8810-46cb04a51f05@github.com>

On Tue, 1 Apr 2025 15:51:07 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> SwingNodePlatformExitCrashTest hangs on Ubuntu 24.04 and wayland when we use < JDK 24.
> 
> This is happening because of issue identified in https://bugs.openjdk.org/browse/JDK-8335468 and it is fixed in JDK 24.
> So we need to run this test on wayland only when we use JDK 24 or later.
> Test is updated and verified that it works appropriately now on Ubuntu 24.04.

This pull request has now been integrated.

Changeset: 056c7f52
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/056c7f52e544fa0f462a9c8f81e82df834bfd596
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8350009: [XWayland] SwingNodePlatformExitCrashTest hangs on Ubuntu 24.04

Reviewed-by: kcr

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

PR: https://git.openjdk.org/jfx/pull/1753

From arapte at openjdk.org  Wed Apr  2 06:14:31 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 2 Apr 2025 06:14:31 GMT
Subject: RFR: 8352982: gradle TEST_SDK_PATH param doesn't work with
 relative paths [v2]
In-Reply-To: <nQBSuBQvVW0itJLRR-Cs0TOm6ymltaWG-2BufQky1xI=.b39146a4-4f68-4459-929a-6b54d4ba0437@github.com>
References: <nQBSuBQvVW0itJLRR-Cs0TOm6ymltaWG-2BufQky1xI=.b39146a4-4f68-4459-929a-6b54d4ba0437@github.com>
Message-ID: <7NOEK_py0Uv07O86R5E400mBdAC9lq-c4g9k9ELdwyk=.28100c76-f12f-442b-a166-e1bd5e801a17@github.com>

> Issue:
> The test execution fails when a relative path is specified a relative path for `TEST_SDK_PATH`.
> For example:
> 1. gradle -PTEST_ONLY=true -PTEST_SDK_PATH=**..**/jfx1/build test 
> 2. gradle -PTEST_ONLY=true -PTEST_SDK_PATH=**~**/jfx1/build test
> 
> Solution:
> Convert the relative path to an absolute path.
> 
> More about fix:
> The property TEST_SDK_PATH belongs to the root project rt in build.gradle.
> If we modify this property in build.gradle, it does not reflect in the child projects. The child projects for example graphics, controls would still have the value of TEST_SDK_PATH before modification.
> To solve this, I Introduced a new variable in build.gradle `TEST_SDK_DIR`. It would hold the modified value of `TEST_SDK_PATH` and gets correctly reflected across all sub-projects.
> 
> Verified that both relative paths and absolute path work fine after this change.

Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:

  review comment: remove handling of path with ~

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1751/files
  - new: https://git.openjdk.org/jfx/pull/1751/files/5d3ec763..92945555

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1751&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1751&range=00-01

  Stats: 9 lines in 1 file changed: 0 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1751.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1751/head:pull/1751

PR: https://git.openjdk.org/jfx/pull/1751

From jhendrikx at openjdk.org  Wed Apr  2 08:36:22 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 2 Apr 2025 08:36:22 GMT
Subject: RFR: 8351276: Prevent redundant computeValue calls when a chain of
 mappings becomes observed [v2]
In-Reply-To: <IyHADMCaatpnRYZ2g7a6OHCDsuw7JZULs-dbWKmssv8=.25763986-bb17-4600-b505-0fdd9b601f26@github.com>
References: <IyHADMCaatpnRYZ2g7a6OHCDsuw7JZULs-dbWKmssv8=.25763986-bb17-4600-b505-0fdd9b601f26@github.com>
Message-ID: <XNlwzdSP5rvOtUngLSHFj33W8yMzv2O3iDkRzk7hv9U=.a32ff784-5487-4018-8ed0-0ec1f66f1c88@github.com>

> 8351276: Prevent redundant computeValue calls when a chain of mappings becomes observed

John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:

  Fix review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1730/files
  - new: https://git.openjdk.org/jfx/pull/1730/files/43e774a4..87e2bd88

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1730&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1730&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1730.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1730/head:pull/1730

PR: https://git.openjdk.org/jfx/pull/1730

From jhendrikx at openjdk.org  Wed Apr  2 08:36:22 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 2 Apr 2025 08:36:22 GMT
Subject: RFR: 8351276: Prevent redundant computeValue calls when a chain of
 mappings becomes observed
In-Reply-To: <IyHADMCaatpnRYZ2g7a6OHCDsuw7JZULs-dbWKmssv8=.25763986-bb17-4600-b505-0fdd9b601f26@github.com>
References: <IyHADMCaatpnRYZ2g7a6OHCDsuw7JZULs-dbWKmssv8=.25763986-bb17-4600-b505-0fdd9b601f26@github.com>
Message-ID: <rqLIS_5ctLL3MPd1_cEbi48bRSP_HVG0GfTG4DPMO5w=.d39f7859-2e5b-4539-966d-614ab651d19c@github.com>

On Thu, 6 Mar 2025 15:22:58 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> 8351276: Prevent redundant computeValue calls when a chain of mappings becomes observed

@nlisker fixed the review comments, if you want to take another look

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

PR Comment: https://git.openjdk.org/jfx/pull/1730#issuecomment-2771809021

From kcr at openjdk.org  Wed Apr  2 11:23:59 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 2 Apr 2025 11:23:59 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v4]
In-Reply-To: <WC3TwZrRthzO9rWzS4yNuJfXkHqBioUlqSv5vk8OWZI=.9fbf394b-3e41-41ae-b182-b63d1d99db3a@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <qDP0hIdl0xmGt47bTS8B0AZKLGcSN3pxPWUJo1vmqCQ=.9301440a-6a4a-4cb2-a843-a2914682f3df@github.com>
 <W6i3URblcpspzWvt65Xdabwt-JKNMj3hTwudiugN1zU=.afe3cbb0-02b0-4791-a256-2b60961236f6@github.com>
 <v6Z5pWtUrvtNBBUdkZGZlkSmqCV_WTumuN7L2SIdZPY=.1a3606e4-d396-4c5f-a619-f2c0b267d0d0@github.com>
 <rMoa3GU-CTt53qX-3pfBhgzPg3toFwkncJ2HCWXktZE=.04e226e8-8fb5-426c-beba-97c8df5ed329@github.com>
 <KYQjRuffM99O0l5poNAFTTd-KhO0bvca__yQX0e1clc=.83f5da74-cd6c-4edc-b803-9917a01e17bf@github.com>
 <WC3TwZrRthzO9rWzS4yNuJfXkHqBioUlqSv5vk8OWZI=.9fbf394b-3e41-41ae-b182-b63d1d99db3a@github.com>
Message-ID: <2n2BPxtmZZDPHi5Lc5QuH7Om9C3LsEkVkHtyQGQrHtM=.27bcfadd-dd8a-4ebc-815e-1948f80980ea@github.com>

On Tue, 1 Apr 2025 20:47:32 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Yes, there are two main approaches we could take:
>> 
>> Option 1: A utility that is available for developers to add to one or more specific tests in a branch in their personal fork when debugging failures in those tests. We would not add it to any test in the mainline repo in this case. Since it is a developer-only utility, it isn't necessary to have a system property to enable it.
>> 
>> Option 2: A utility that is added to all robot tests in the repo, with a flag to enable it (off by default).
>> 
>> There are pros / cons of each approach. The second approach is more likely to catch a failing test that fails rarely and would easily allow us to enable it and run it on a new platform (e.g., for testing a new version of macOS or Ubuntu), although it is also more prone to the "runaway" screenshot problem unless we can come up with a good way to limit it.
>> 
>> I left a couple usability questions that are independent of this. It probably makes sense to address those first and then come back to this.
>
> I would choose the Option 1 (debug utility), with an addition of a static `ScreenCapture.takeScreenshot()`.
> 
> I don't think there is a need to add this tool to the hundreds of tests which work just fine.

I would agree with this given the limitations using the annotation (especially the fact that it runs _after_ the `@AfterEach` method) and that we have no good way to throttle it.

If we go this way, the final version of the PR would need to remove the annotation from the existing tests.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2024623918

From kcr at openjdk.org  Wed Apr  2 11:59:08 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 2 Apr 2025 11:59:08 GMT
Subject: RFR: 8352982: gradle TEST_SDK_PATH param doesn't work with
 relative paths [v2]
In-Reply-To: <7NOEK_py0Uv07O86R5E400mBdAC9lq-c4g9k9ELdwyk=.28100c76-f12f-442b-a166-e1bd5e801a17@github.com>
References: <nQBSuBQvVW0itJLRR-Cs0TOm6ymltaWG-2BufQky1xI=.b39146a4-4f68-4459-929a-6b54d4ba0437@github.com>
 <7NOEK_py0Uv07O86R5E400mBdAC9lq-c4g9k9ELdwyk=.28100c76-f12f-442b-a166-e1bd5e801a17@github.com>
Message-ID: <P6Sa8W1DzzQbmKd3A8A5o3trgRpAVSL1sKvyRQt4kR4=.78f7c357-a305-4fcd-951c-643191b5ce46@github.com>

On Wed, 2 Apr 2025 06:14:31 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Issue:
>> The test execution fails when a relative path is specified a relative path for `TEST_SDK_PATH`.
>> For example:
>> 1. gradle -PTEST_ONLY=true -PTEST_SDK_PATH=**..**/jfx1/build test 
>> 2. gradle -PTEST_ONLY=true -PTEST_SDK_PATH=**~**/jfx1/build test
>> 
>> Solution:
>> Convert the relative path to an absolute path.
>> 
>> More about fix:
>> The property TEST_SDK_PATH belongs to the root project rt in build.gradle.
>> If we modify this property in build.gradle, it does not reflect in the child projects. The child projects for example graphics, controls would still have the value of TEST_SDK_PATH before modification.
>> To solve this, I Introduced a new variable in build.gradle `TEST_SDK_DIR`. It would hold the modified value of `TEST_SDK_PATH` and gets correctly reflected across all sub-projects.
>> 
>> Verified that both relative paths and absolute path work fine after this change.
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment: remove handling of path with ~

Relative paths that start with a `.` now work for me. I noted one more case that should be handled and also left one minor comment.

build.gradle line 729:

> 727:     }
> 728:     String testSdkPath = "${TEST_SDK_PATH}"
> 729:     if (testSdkPath.startsWith(".")) {

This will exclude relative paths underneath the jfx directory you are in unless you explicitly add `./` before the directory. It's a rare case, but seems worth handling. Perhaps you can remove the `if` test entirely and always use `file(testSdkPath).absolutePath`?

build.gradle line 745:

> 743:     ext.TEST_SDK_DIR = "${rootProject.buildDir}"
> 744: }
> 745: println "TEST_SDK_PATH: " + TEST_SDK_DIR

Minor: Consider moving this down to the block where most other build properties like this are logged?

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

PR Review: https://git.openjdk.org/jfx/pull/1751#pullrequestreview-2735963827
PR Review Comment: https://git.openjdk.org/jfx/pull/1751#discussion_r2024651013
PR Review Comment: https://git.openjdk.org/jfx/pull/1751#discussion_r2024654305

From nlisker at openjdk.org  Wed Apr  2 13:56:03 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 2 Apr 2025 13:56:03 GMT
Subject: RFR: 8351276: Prevent redundant computeValue calls when a chain of
 mappings becomes observed [v2]
In-Reply-To: <XNlwzdSP5rvOtUngLSHFj33W8yMzv2O3iDkRzk7hv9U=.a32ff784-5487-4018-8ed0-0ec1f66f1c88@github.com>
References: <IyHADMCaatpnRYZ2g7a6OHCDsuw7JZULs-dbWKmssv8=.25763986-bb17-4600-b505-0fdd9b601f26@github.com>
 <XNlwzdSP5rvOtUngLSHFj33W8yMzv2O3iDkRzk7hv9U=.a32ff784-5487-4018-8ed0-0ec1f66f1c88@github.com>
Message-ID: <5erLesYrjEz_OmlqMbhkIsYmFhx5Uw7PWB3DCrPpJQw=.376d9cc1-67dd-4fd5-9a71-c5e79ecf4b6e@github.com>

On Wed, 2 Apr 2025 08:36:22 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> 8351276: Prevent redundant computeValue calls when a chain of mappings becomes observed
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix review comments

Marked as reviewed by nlisker (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1730#pullrequestreview-2736364293

From bahaazaid at gmail.com  Wed Apr  2 14:01:46 2025
From: bahaazaid at gmail.com (Bahaa Zaid)
Date: Wed, 2 Apr 2025 16:01:46 +0200
Subject: Feature Request: Support for Transparent Title Bars in JavaFX Stages
Message-ID: <96527358-3EA3-40DE-8992-658AF141C42E@gmail.com>

Hello,

Modern macOS apps tend to expand the client area of the window to take the entire window area including the titlebar. This is usually done by:
Setting NSWindow.titlebarAppearsTransparent to true.
Setting NSWindow.styleMask NSWindowStyleMaskFullSizeContentView flag.

This can be useful because it gives the app modern look, make use of all available window real-estate, and allows JavaFX developers to create completely custom windows like UNDECORATED styles without loosing the platform resize-window feature and the three window buttons.

Swing supports this already using code like this:
final var frame = new JFrame();
final var rootPane = frame.getRootPane();
rootPane.putClientProperty("apple.awt.fullWindowContent", true);
rootPane.putClientProperty("apple.awt.transparentTitleBar", true);

This can be done easily today using reflection to access non-public API to get the Stage native NSWindow handle and using FFM to change styleMask and set the titlebarAppearsTransparent property. I have created an example here (https://github.com/bahaa/jfx-transparent-window-titlebar). But this approach has the following drawbacks:
It uses non-public API.
JavaFX stage native window handle is available only after the stage is shown, this cause some flicker because the window style is changed after it?s shown to the user.

I think JavaFX should support this out of the box. One possible solution is to introduce a new StageStyle that behaves like UNIFIED style (it falls back to DECORATED) if it?s not supported by the platform. I think something similar can be done on Windows (https://learn.microsoft.com/en-us/windows/win32/dwm/customframe) but I?m not sure about GTK.

Thanks,
Bahaa.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250402/7d0571a9/attachment.htm>

From angorya at openjdk.org  Wed Apr  2 14:35:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 2 Apr 2025 14:35:16 GMT
Subject: RFR: 8350976: MenuBarSkin: exception initializing in a background
 thread [v2]
In-Reply-To: <YGlbBy8aM3b4uB3t2f31N7hovUPxHOzwgVOcoYOVdxE=.da95f474-789d-4e6a-a334-8162cb43510a@github.com>
References: <rlPnhzYl_h3-WkWw7gxtdN8n5JKBVqgyu9HzWkUan8c=.5839a05f-0331-4437-bcc1-77169cdd00c8@github.com>
 <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
 <YGlbBy8aM3b4uB3t2f31N7hovUPxHOzwgVOcoYOVdxE=.da95f474-789d-4e6a-a334-8162cb43510a@github.com>
Message-ID: <k8vVcVOlCqNLmbEJw0O3aTzS5_WVwNdxYlZQNYdqY_0=.b1c4ae1f-97a7-4cf5-a922-6c474c61520f@github.com>

On Wed, 2 Apr 2025 06:06:58 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8350976.menubarskin.thread.safety
>>  - spelling
>>  - use system menu
>>  - cleanup
>>  - possible fix
>>  - test
>
> For test verification i was following what i do in JDK of checking out the branch in the PR and without build verify that the test fails and then build the branch(which will build source code change also) and then make sure test passes.
> 
> Got to know that we need to use -PTEST_ONLY=true in FX to make sure that source code changes are not built when i use gradle to run the test. With this approach i can see that the test fails without product change and passes with it :)

The mystery solved!  Thank you @jayathirthrao !

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

PR Comment: https://git.openjdk.org/jfx/pull/1727#issuecomment-2772754855

From angorya at openjdk.org  Wed Apr  2 14:35:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 2 Apr 2025 14:35:16 GMT
Subject: Integrated: 8350976: MenuBarSkin: exception initializing in a
 background thread
In-Reply-To: <rlPnhzYl_h3-WkWw7gxtdN8n5JKBVqgyu9HzWkUan8c=.5839a05f-0331-4437-bcc1-77169cdd00c8@github.com>
References: <rlPnhzYl_h3-WkWw7gxtdN8n5JKBVqgyu9HzWkUan8c=.5839a05f-0331-4437-bcc1-77169cdd00c8@github.com>
Message-ID: <IpxuLjn6HxT8_UgWPXl7pgbgFAwUxK-sXz4b1ala6Ko=.b915aa52-bab5-44a7-adbf-3d1d4f5d2e82@github.com>

On Mon, 3 Mar 2025 23:50:07 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Allows MenuBar to be created in a background thread by delaying MenuBarSkin::rebuildUI() call until after the MenuBar becomes a part of the scene graph.

This pull request has now been integrated.

Changeset: 4a4272b7
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/4a4272b79225f31b574b237a20a403a2fc106591
Stats:     67 lines in 2 files changed: 56 ins; 7 del; 4 mod

8350976: MenuBarSkin: exception initializing in a background thread

Reviewed-by: lkostyra, jdv

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

PR: https://git.openjdk.org/jfx/pull/1727

From angorya at openjdk.org  Wed Apr  2 14:39:46 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 2 Apr 2025 14:39:46 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v5]
In-Reply-To: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
Message-ID: <h_g_jpLBfcaha_l2I2orbjzrvr41YA0vwcvai7iW1BM=.3f8d09d4-e8f1-4d31-b1bf-86b29d80396f@github.com>

> Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.
> 
> The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.
> 
> The log contains a base-64 encoded screenshot (like this: `data:image/png;base64,iVBORw0KGgoAAAANSUhEU...` )
> so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)
> 
> Example:
> 
> ![jenkins-screenshot](https://github.com/user-attachments/assets/abebd76f-747a-4d6d-a9a6-63c6e9426830)

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  removed watchers

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1746/files
  - new: https://git.openjdk.org/jfx/pull/1746/files/02c185f9..5f6fee46

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1746&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1746&range=03-04

  Stats: 6 lines in 2 files changed: 0 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1746.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1746/head:pull/1746

PR: https://git.openjdk.org/jfx/pull/1746

From angorya at openjdk.org  Wed Apr  2 14:54:15 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 2 Apr 2025 14:54:15 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v5]
In-Reply-To: <h_g_jpLBfcaha_l2I2orbjzrvr41YA0vwcvai7iW1BM=.3f8d09d4-e8f1-4d31-b1bf-86b29d80396f@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <h_g_jpLBfcaha_l2I2orbjzrvr41YA0vwcvai7iW1BM=.3f8d09d4-e8f1-4d31-b1bf-86b29d80396f@github.com>
Message-ID: <1QFYu5P0dFvqoo4RY9KkLOZDcyRe3exRXA1ihAQjTFo=.d59a009e-cd8e-47aa-89ce-0d6a86b89358@github.com>

On Wed, 2 Apr 2025 14:39:46 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.
>> 
>> The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.
>> 
>> The log contains a base-64 encoded screenshot (like this: `data:image/png;base64,iVBORw0KGgoAAAANSUhEU...` )
>> so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)
>> 
>> Example:
>> 
>> ![jenkins-screenshot](https://github.com/user-attachments/assets/abebd76f-747a-4d6d-a9a6-63c6e9426830)
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed watchers

Adding `ScreenshotCapture.writeScreenshot(System.err);` before the failing line in the `RectangleTest` successfully captures the screenshot:

![ss-3](https://github.com/user-attachments/assets/1a2a49bc-6085-4158-b87d-8c788186a8c0)

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

PR Comment: https://git.openjdk.org/jfx/pull/1746#issuecomment-2772815565

From angorya at openjdk.org  Wed Apr  2 15:04:54 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 2 Apr 2025 15:04:54 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v6]
In-Reply-To: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
Message-ID: <5NHefa7QPAKVumTruzFaSy0ZZJwIKhF9gvK2jI3bDYs=.75ff7ebb-2a02-43be-a73f-9f5d1d7858c3@github.com>

> Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.
> 
> The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.
> 
> The log contains a base-64 encoded screenshot (like this: `data:image/png;base64,iVBORw0KGgoAAAANSUhEU...` )
> so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)
> 
> Additionally, provided a utility class to capture the screenshots at the specific point in a test and write it to stdout/stderr:
> 
> 
> // write a base-64 encoded screenshot to stderr
> ScreenshotCapture.writeScreenshot(System.err);
> 
> 
> Example:
> 
> ![jenkins-screenshot](https://github.com/user-attachments/assets/abebd76f-747a-4d6d-a9a6-63c6e9426830)

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  javadoc

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1746/files
  - new: https://git.openjdk.org/jfx/pull/1746/files/5f6fee46..469cd437

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1746&range=05
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1746&range=04-05

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1746.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1746/head:pull/1746

PR: https://git.openjdk.org/jfx/pull/1746

From duke at openjdk.org  Wed Apr  2 16:15:04 2025
From: duke at openjdk.org (duke)
Date: Wed, 2 Apr 2025 16:15:04 GMT
Subject: RFR: 8245602: Ensemble8: HTMLEditor Toolbar gets scrolled out of
 view
In-Reply-To: <i5KZzkR5fsUwTcXq9l0hvB8CGYsykOfGuqrydwF53oc=.4399fc6c-6041-4cf2-a78d-27b054ca4dfa@github.com>
References: <i5KZzkR5fsUwTcXq9l0hvB8CGYsykOfGuqrydwF53oc=.4399fc6c-6041-4cf2-a78d-27b054ca4dfa@github.com>
Message-ID: <8cXBcMze6mz-gJAXRg9iyPxnM9xF4l3K2uFinstxzoU=.6927602d-e1e5-4d6d-b4b5-2cc71b5b7a00@github.com>

On Tue, 1 Apr 2025 06:47:59 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

> There was a scrolling issue with multiline edit control with text controls at the top of the edit box [JDK-8245602](https://bugs.openjdk.org/browse/JDK-8245602),
> 
> We replaced the ScrollPane with VBox control as the parent of the html edit control.
> 
> Verification:
> This makes the controls on the top of the edit control, And the texts scroll inside the text area as expected.
> Similar kind of behavior is seen in normal web pages with multiline edit controls inside it.

@Gopalora 
Your change (at version cbbcfb034e9c0e6d3190ad12e13e841a9bb682dd) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1752#issuecomment-2773084054

From duke at openjdk.org  Wed Apr  2 16:18:02 2025
From: duke at openjdk.org (Gopal Pattnaik)
Date: Wed, 2 Apr 2025 16:18:02 GMT
Subject: Integrated: 8245602: Ensemble8: HTMLEditor Toolbar gets scrolled out
 of view
In-Reply-To: <i5KZzkR5fsUwTcXq9l0hvB8CGYsykOfGuqrydwF53oc=.4399fc6c-6041-4cf2-a78d-27b054ca4dfa@github.com>
References: <i5KZzkR5fsUwTcXq9l0hvB8CGYsykOfGuqrydwF53oc=.4399fc6c-6041-4cf2-a78d-27b054ca4dfa@github.com>
Message-ID: <--6JfTPhKZogA4KTMCZN3EQNJSrLWkBKdzZgBiWJg6o=.cab9ea53-939f-4836-9ec5-c5eabd54a7ec@github.com>

On Tue, 1 Apr 2025 06:47:59 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

> There was a scrolling issue with multiline edit control with text controls at the top of the edit box [JDK-8245602](https://bugs.openjdk.org/browse/JDK-8245602),
> 
> We replaced the ScrollPane with VBox control as the parent of the html edit control.
> 
> Verification:
> This makes the controls on the top of the edit control, And the texts scroll inside the text area as expected.
> Similar kind of behavior is seen in normal web pages with multiline edit controls inside it.

This pull request has now been integrated.

Changeset: 097c017d
Author:    Gopal Pattnaik <gopal.pattnaik at oracle.com>
Committer: Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/097c017dc5925ac3dc218a32a646aeb37b83ee5e
Stats:     7 lines in 1 file changed: 0 ins; 3 del; 4 mod

8245602: Ensemble8: HTMLEditor Toolbar gets scrolled out of view

Reviewed-by: angorya

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

PR: https://git.openjdk.org/jfx/pull/1752

From mfox at openjdk.org  Wed Apr  2 16:21:59 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 2 Apr 2025 16:21:59 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests
In-Reply-To: <Qb30PCbXciWeMPT5vRRyYrN92uyPmYW3hctqNjGQYw0=.d46689f0-b49b-42ee-9e4a-4d6b78c43326@github.com>
References: <t57zeYPEQbapfqSW9CwHWjTRqXCTWwO0Kq25r9AfP_I=.90a718e0-a50b-4a10-9fae-19efbee4b1ba@github.com>
 <31yf5mJD12V39DQxj-2UclRnKHf5INKMRKRySQtDsJc=.7c561e2f-ddcd-49ef-824a-b04d1bb80264@github.com>
 <aMccVsXfGF7ykv7TZCzBzDfn9fkzAVe5IYsr5Dsrhx8=.f00272fb-a183-479b-a2c7-0a5a5a3f71f7@github.com>
 <omeS_mnF-w3ojZgmkw20Lx0t-ERu_dmxKB8NGxm128w=.9b9e5712-8b16-4760-852e-0e5e2884c463@github.com>
 <Qb30PCbXciWeMPT5vRRyYrN92uyPmYW3hctqNjGQYw0=.d46689f0-b49b-42ee-9e4a-4d6b78c43326@github.com>
Message-ID: <4dWQuDSDIhul9SnKi43qTZ_paWdp9mfg98rcKoqKlpA=.3d8e3f33-e15d-4173-8d24-fe8b22a68154@github.com>

On Mon, 31 Mar 2025 18:27:11 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Good idea. I might need some help with this though - this command line
> 
> `java @build/testrun.args ./tests/manual/text/EmojiTest.java` fails because it cannot find

Sorry, I don't think this can be made to work. I've been able to get Java's single-file source code mode to compile classes from more than one file but I now realize the setup is too restrictive to work here and isn't actually documented.

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

PR Comment: https://git.openjdk.org/jfx/pull/1747#issuecomment-2773102078

From angorya at openjdk.org  Wed Apr  2 16:36:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 2 Apr 2025 16:36:03 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v3]
In-Reply-To: <WDLXSGolTRT60rkhN2cV_Sd1k8u7j_4TmW6lSdHJxzY=.a62e23da-f9fc-499d-a18e-a612c14f1aec@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <OQ2S6cYNrQGoLP9c7ZB2_4zBi08ET_WBw0SLX6b8sHI=.099b388e-cc36-400c-b057-e4ae47dff034@github.com>
 <2EIopJ4OMG_3VR_sHcLhFP-vOAkIDtjk1P8KCvX2BlY=.40d1c1cb-5480-49b4-9377-200dccbc6560@github.com>
 <WDLXSGolTRT60rkhN2cV_Sd1k8u7j_4TmW6lSdHJxzY=.a62e23da-f9fc-499d-a18e-a612c14f1aec@github.com>
Message-ID: <PsqQUKVkGrM9mrIYZwrIcMO-R4t1SXVt38assMzS-Js=.fd91b84f-377a-4bd3-b15e-fdaa18bd440f@github.com>

On Tue, 1 Apr 2025 22:42:25 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Turns out one can't intercept assertion exceptions with `Thread.setDefaultUncaughtExceptionHandler()` (duh!), so this is likely to be a known limitation.
>> 
>> We might still provide general purpose methods in `ScreenCapture` (new class) like 
>> 
>> 
>>     /**
>>      * Captures a screenshot using JavaFX {@link Robot} in the PNG format.
>>      * <p>
>>      * This method can be called from any thread.  If called from a thread other than
>>      * the JavaFX Application Thread, the current thread will be paused until the screenshot is taken.
>>      *
>>      * @return the byte array containing the screenshot
>>      * @throws IOException when an I/O error occurs
>>      */
>>     public static byte[] takeScreenshot() throws IOException {
>> 
>> 
>> and 
>> 
>> 
>>     /**
>>      * Captures a screenshot using JavaFX {@link Robot} in the PNG format,
>>      * in the form of a Base-64 encoded {@code String}.
>>      * <p>
>>      * This method can be called from any thread.  If called from a thread other than
>>      * the JavaFX Application Thread, the current thread will be paused until the screenshot is taken.
>>      *
>>      * @param prefix the string to append before the base-64 representation, or null
>>      * @param postfix the string to append after the base-64 representation, or null
>>      * @return the screenshot in Base-64 encoded PNG, or an error message
>>      */
>>     public static String takeScreenshotBase64(String prefix, String postfix) {
>> 
>> 
>> What do you think?
>
>> We might still provide general purpose methods in ScreenCapture (new class) like
> 
> That might work. So the idea would be a utility class not tied to a JUnit5 annotation? The usage would then be adding a call to that while debugging a test wherever it makes sense for your test, possible from an AfterEach method.
> 
>>     public static byte[] takeScreenshot() throws IOException {
> 
> What would this do? I can see the usefulness of returning a WritableImage (basically calling `Robot::getScreenCapture` on the whole screen) or a base64-encoded PNG file, but what does it mean to return a raw byte array? I probably wouldn't recommend this one.
> 
>>     public static String takeScreenshotBase64(String prefix, String postfix) {
> 
> This seems useful, although what are "prefix" and "postfix" for?

@kevinrushforth do you know why there are two java windows in the screenshot above?

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

PR Comment: https://git.openjdk.org/jfx/pull/1746#issuecomment-2773133380

From jpereda at openjdk.org  Wed Apr  2 17:10:06 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Wed, 2 Apr 2025 17:10:06 GMT
Subject: RFR: 8353548: [macOS] DragEvent.getScreenY() returns incorrect value
 in secondary monitor
Message-ID: <xWx93iazM2hTIGMWyRIRHDN8ZU74rNyCk5vyOrFLkmM=.c4bd574c-0dbe-4430-9112-9859401fe899@github.com>

This PR fixes an issue when dragEvents occur in a secondary screen which doesn't have the same height or (macOS) origin as the main screen.

The calculations for `xAbs, yAbs` are defined from the main screen macOS absolute origin, an in order to flip the coordinates defined from the JavaFX origin, the height from the main screen should be used, and not the height from secondary screens, which was the case in `GlassViewDelegate::sendJavaDndEvent`.

The PR doesn't include tests because it needs a complex setup (two monitors), but the change has been tested on macOS 15.3.2 with the test case from https://bugs.openjdk.org/browse/JDK-8353548, using two monitors (built-in Retina and external 4K display), rearranging their layout (left-bottom-right from main screen), and relative resolution.

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

Commit messages:
 - Use correct screen to calculate yAbs in a dragEvent

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

PR: https://git.openjdk.org/jfx/pull/1756

From angorya at openjdk.org  Wed Apr  2 18:02:54 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 2 Apr 2025 18:02:54 GMT
Subject: RFR: 8353548: [macOS] DragEvent.getScreenY() returns incorrect
 value in secondary monitor
In-Reply-To: <xWx93iazM2hTIGMWyRIRHDN8ZU74rNyCk5vyOrFLkmM=.c4bd574c-0dbe-4430-9112-9859401fe899@github.com>
References: <xWx93iazM2hTIGMWyRIRHDN8ZU74rNyCk5vyOrFLkmM=.c4bd574c-0dbe-4430-9112-9859401fe899@github.com>
Message-ID: <ParfRCdIM0lvRt9vZccEkDYQVyGXtoxZFy3MjxXNbGM=.5239c538-23a8-4b16-beef-cdd6dcd38627@github.com>

On Wed, 2 Apr 2025 17:05:58 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR fixes an issue when dragEvents occur in a secondary screen which doesn't have the same height or (macOS) origin as the main screen.
> 
> The calculations for `xAbs, yAbs` are defined from the main screen macOS absolute origin, an in order to flip the coordinates defined from the JavaFX origin, the height from the main screen should be used, and not the height from secondary screens, which was the case in `GlassViewDelegate::sendJavaDndEvent`.
> 
> The PR doesn't include tests because it needs a complex setup (two monitors), but the change has been tested on macOS 15.3.2 with the test case from https://bugs.openjdk.org/browse/JDK-8353548, using two monitors (built-in Retina and external 4K display), rearranging their layout (left-bottom-right from main screen), and relative resolution.

The fix works on macOS 15.3.2 M1, using the secondary monitor at different position relative to the primary retina one, as well as at different resolutions. 

Also, noticing `objectAtIndex: 0]`, tried with three monitors, all good:

![Screenshot 2025-04-02 at 10 58 16](https://github.com/user-attachments/assets/d8b66ade-c339-4b3c-b1bd-20da5b603c44)

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1756#pullrequestreview-2737136576

From angorya at openjdk.org  Wed Apr  2 18:43:53 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 2 Apr 2025 18:43:53 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests
In-Reply-To: <4dWQuDSDIhul9SnKi43qTZ_paWdp9mfg98rcKoqKlpA=.3d8e3f33-e15d-4173-8d24-fe8b22a68154@github.com>
References: <t57zeYPEQbapfqSW9CwHWjTRqXCTWwO0Kq25r9AfP_I=.90a718e0-a50b-4a10-9fae-19efbee4b1ba@github.com>
 <31yf5mJD12V39DQxj-2UclRnKHf5INKMRKRySQtDsJc=.7c561e2f-ddcd-49ef-824a-b04d1bb80264@github.com>
 <aMccVsXfGF7ykv7TZCzBzDfn9fkzAVe5IYsr5Dsrhx8=.f00272fb-a183-479b-a2c7-0a5a5a3f71f7@github.com>
 <omeS_mnF-w3ojZgmkw20Lx0t-ERu_dmxKB8NGxm128w=.9b9e5712-8b16-4760-852e-0e5e2884c463@github.com>
 <Qb30PCbXciWeMPT5vRRyYrN92uyPmYW3hctqNjGQYw0=.d46689f0-b49b-42ee-9e4a-4d6b78c43326@github.com>
 <4dWQuDSDIhul9SnKi43qTZ_paWdp9mfg98rcKoqKlpA=.3d8e3f33-e15d-4173-8d24-fe8b22a68154@github.com>
Message-ID: <1wmkxs2oCIMyToiSUOyvJCZ6fRMigNQGDmsxMdjvmOM=.5fc74f7d-87d4-406a-a49d-c2560efea658@github.com>

On Wed, 2 Apr 2025 16:19:36 GMT, Martin Fox <mfox at openjdk.org> wrote:

> I don't think this can be made to work.

The only other though I have is to build a special `test-common` module and include it in the `--module-path` in `build/testrun.args`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1747#issuecomment-2773404653

From angorya at openjdk.org  Wed Apr  2 22:29:24 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 2 Apr 2025 22:29:24 GMT
Subject: RFR: 8353587: Spelling errors and dead code
Message-ID: <JsCpNkfgSc-GS_IFokWtVGUDrJMiC4bZ0WAh6geC7n8=.1f052ec0-0b93-4b60-a68e-d43acce92c58@github.com>

Corrects annoying spelling errors in the code:

- propogated
- Hueristic2D

Also fixes unnecessary field in MenuBar:171

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

Commit messages:
 - 2025
 - unnecessary field
 - spelling

Changes: https://git.openjdk.org/jfx/pull/1757/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1757&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353587
  Stats: 43 lines in 7 files changed: 11 ins; 16 del; 16 mod
  Patch: https://git.openjdk.org/jfx/pull/1757.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1757/head:pull/1757

PR: https://git.openjdk.org/jfx/pull/1757

From kcr at openjdk.org  Wed Apr  2 23:22:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 2 Apr 2025 23:22:52 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests
In-Reply-To: <t57zeYPEQbapfqSW9CwHWjTRqXCTWwO0Kq25r9AfP_I=.90a718e0-a50b-4a10-9fae-19efbee4b1ba@github.com>
References: <t57zeYPEQbapfqSW9CwHWjTRqXCTWwO0Kq25r9AfP_I=.90a718e0-a50b-4a10-9fae-19efbee4b1ba@github.com>
Message-ID: <CZFbRdmgH0SsZ0bmwOGnRr_qtyKaiTjpGzTlF8EZIZk=.410cc856-0b1b-410d-8392-b0911dbb0a95@github.com>

On Fri, 28 Mar 2025 18:43:34 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Provides the base class for manual tests which displays the test instructions, the UI under test, and the Pass/Fail buttons.
> 
> Uses `EmojiTest` to illustrate the use of the new class.
> 
> Example:
> 
> 
> public class ManualTestExample extends ManualTestWindow {
>     public ManualTestExample() {
>         super(
>             "Manual Test Example",
>             """
>             Instructions:
>             1. you will see a button named "Test"
>             2. press the button
>             3. verify that the button can be pressed""",
>             400, 250
>         );
>      }
> 
>      public static void main(String[] args) throws Exception {
>          launch(args);
>      }
> 
>      @Override
>      protected Node createContent() {
>          return new Button("Test");
>      }
> }
> 
> 
> ![Screenshot 2025-03-28 at 11 50 16](https://github.com/user-attachments/assets/b44a7eb1-d98f-44a5-b13e-612b31c94c60)

I like the idea of a standard test utility, as long as there is some sort of build script or easy way to get at it. Probably not `build/testrun.args`, though, since is meant for unit tests and includes the shims classes, so isn't suitable for most manual tests where we typically want to stick to the public API.

We might want to wait until we implement at least part of [JDK-8296441](https://bugs.openjdk.org/browse/JDK-8296441) is implemented.

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

PR Comment: https://git.openjdk.org/jfx/pull/1747#issuecomment-2773940206

From kcr at openjdk.org  Wed Apr  2 23:24:55 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 2 Apr 2025 23:24:55 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v3]
In-Reply-To: <WDLXSGolTRT60rkhN2cV_Sd1k8u7j_4TmW6lSdHJxzY=.a62e23da-f9fc-499d-a18e-a612c14f1aec@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <OQ2S6cYNrQGoLP9c7ZB2_4zBi08ET_WBw0SLX6b8sHI=.099b388e-cc36-400c-b057-e4ae47dff034@github.com>
 <2EIopJ4OMG_3VR_sHcLhFP-vOAkIDtjk1P8KCvX2BlY=.40d1c1cb-5480-49b4-9377-200dccbc6560@github.com>
 <WDLXSGolTRT60rkhN2cV_Sd1k8u7j_4TmW6lSdHJxzY=.a62e23da-f9fc-499d-a18e-a612c14f1aec@github.com>
Message-ID: <G6kWebMEVnzBq0aSERGyr6CHdoyxfpjzTL6U3Z650Ow=.c68a3e30-4b8d-42f4-bd08-f21dd08dd766@github.com>

On Tue, 1 Apr 2025 22:42:25 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Turns out one can't intercept assertion exceptions with `Thread.setDefaultUncaughtExceptionHandler()` (duh!), so this is likely to be a known limitation.
>> 
>> We might still provide general purpose methods in `ScreenCapture` (new class) like 
>> 
>> 
>>     /**
>>      * Captures a screenshot using JavaFX {@link Robot} in the PNG format.
>>      * <p>
>>      * This method can be called from any thread.  If called from a thread other than
>>      * the JavaFX Application Thread, the current thread will be paused until the screenshot is taken.
>>      *
>>      * @return the byte array containing the screenshot
>>      * @throws IOException when an I/O error occurs
>>      */
>>     public static byte[] takeScreenshot() throws IOException {
>> 
>> 
>> and 
>> 
>> 
>>     /**
>>      * Captures a screenshot using JavaFX {@link Robot} in the PNG format,
>>      * in the form of a Base-64 encoded {@code String}.
>>      * <p>
>>      * This method can be called from any thread.  If called from a thread other than
>>      * the JavaFX Application Thread, the current thread will be paused until the screenshot is taken.
>>      *
>>      * @param prefix the string to append before the base-64 representation, or null
>>      * @param postfix the string to append after the base-64 representation, or null
>>      * @return the screenshot in Base-64 encoded PNG, or an error message
>>      */
>>     public static String takeScreenshotBase64(String prefix, String postfix) {
>> 
>> 
>> What do you think?
>
>> We might still provide general purpose methods in ScreenCapture (new class) like
> 
> That might work. So the idea would be a utility class not tied to a JUnit5 annotation? The usage would then be adding a call to that while debugging a test wherever it makes sense for your test, possible from an AfterEach method.
> 
>>     public static byte[] takeScreenshot() throws IOException {
> 
> What would this do? I can see the usefulness of returning a WritableImage (basically calling `Robot::getScreenCapture` on the whole screen) or a base64-encoded PNG file, but what does it mean to return a raw byte array? I probably wouldn't recommend this one.
> 
>>     public static String takeScreenshotBase64(String prefix, String postfix) {
> 
> This seems useful, although what are "prefix" and "postfix" for?

> @kevinrushforth do you know why there are two java windows in the screenshot above?

If you mean two _terminal_ windows, no I don't know. They're probably leftovers.

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

PR Comment: https://git.openjdk.org/jfx/pull/1746#issuecomment-2773942588

From crschnick at xpipe.io  Thu Apr  3 03:57:40 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Thu, 3 Apr 2025 05:57:40 +0200
Subject: [External] : Re: JVM crashes on macOS when entering too many
 nested event loops
In-Reply-To: <CB995A83-E9E7-497E-815E-5D414368A614@gmail.com>
References: <6f326d6d-6069-43fe-800d-a01583c7558c@xpipe.io>
 <DEE5BE59-8CB7-46A0-9DBC-70CBF0756759@gmail.com>
 <BYAPR10MB30138F9BCE8C7CD533D86221E5D62@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8778bda9-69a9-4393-9ea9-642df4a93304@xpipe.io>
 <DM6PR10MB30179CEC6B7069ADD0AD2101E5A72@DM6PR10MB3017.namprd10.prod.outlook.com>
 <226e4247-b39b-4a3c-bcbd-912f663a0219@xpipe.io>
 <DM6PR10MB301706BE497AFA1E391C016EE5A72@DM6PR10MB3017.namprd10.prod.outlook.com>
 <9560C9BE-BC2F-4F0D-B914-425969699179@gmail.com>
 <e709b633-6c49-4623-a15f-50a294d56e2a@xpipe.io>
 <6532F614-D25B-4C55-9519-4DE1CD8629E0@gmail.com>
 <53b467d6-d40e-46bd-8a15-56ddf2c9f55f@xpipe.io>
 <9F065E4B-F67A-40E2-9D3D-CAF9225CE191@gmail.com>
 <a4a7adf8-a19b-4981-afc6-ef288583145d@xpipe.io>
 <CB995A83-E9E7-497E-815E-5D414368A614@gmail.com>
Message-ID: <15ea8a75-c608-4cdf-a060-dfcb45b7d47b@xpipe.io>

Looking at the related issues in the bug tracker, it seems like one 
common cause are modifications on a non-platform thread. I hooked up our 
application to a detection mechanism, but didn't get any meaningful hits 
so far. Maybe I will find something in the future with this.

For reference, is there any already existing best practice to detect 
these non-platform thread modifications? I just wrote my own, feel free 
to check if I'm missing anything:

public class NodeCallback {

     private static final Set<Window>windows =new HashSet<>();
     private static final Set<Node>nodes =new HashSet<>();

     public static void init() {
         if (!AppProperties.get().isDebugPlatformThreadAccess()) {
             return;
         }

         Window.getWindows().addListener((ListChangeListener<?super Window>) change -> {
             for (Window window : change.getList()) {
                 if (!windows.add(window)) {
                     continue;
                 }

                 window.sceneProperty().subscribe(scene -> {
                     if (scene ==null) {
                         return;
                     }

                     scene.rootProperty().subscribe(root -> {
                         if (root !=null) {
                             watchPlatformThreadChanges(root);
                         }
                     });
                 });
             }
         });
     }

     private static void watchPlatformThreadChanges(Node node) {
         watchGraph(node, c -> {
             if (!nodes.add(c)) {
                 return;
             }

             if (cinstanceof Parent p) {
                 p.getChildrenUnmodifiable().addListener((ListChangeListener<?super Node>) change -> {
                     checkPlatformThread();
                 });
             }
             c.visibleProperty().addListener((observable, oldValue, newValue) -> {
                 checkPlatformThread();
             });
             c.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
                 checkPlatformThread();
             });
             c.managedProperty().addListener((observable, oldValue, newValue) -> {
                 checkPlatformThread();
             });
             c.opacityProperty().addListener((observable, oldValue, newValue) -> {
                 checkPlatformThread();
             });
         });
     }

     private static void watchGraph(Node node, Consumer<Node> callback) {
         if (nodeinstanceof Parent p) {
             for (Node c : p.getChildrenUnmodifiable()) {
                 watchGraph(c, callback);
             }
             p.getChildrenUnmodifiable().addListener((ListChangeListener<?super Node>) change -> {
                 for (Node c : change.getList()) {
                     watchGraph(c,callback);
                 }
             });
         }
         callback.accept(node);
     }

     private static void checkPlatformThread() {
         if (!Platform.isFxApplicationThread()) {
             throw new IllegalStateException("Not in Fx application thread");
         }
     }
}

On 28/03/2025 21:06, Martin Fox wrote:
> This isn?t an area of the code that I?m familiar with. Searching for 
> updateCachedBounds in the bug database shows that there?s some history 
> here so maybe someone with more experience can chime in.
>
>> On Mar 28, 2025, at 11:06?AM, Christopher Schnick 
>> <crschnick at xpipe.io> wrote:
>>
>> So I tried various different things to reproduce it without the 
>> StackOverflow, but no success so far. But I can definitely tell you 
>> from many user issue reports that this issue frequently happens. 
>> Looking at the logs when this happens, there were no other exceptions 
>> reported when this happens.
>>
>> It however doesn't leave the node in a bad state in most cases, in 
>> production this exception usually only occurs once without the same 
>> exception happening in later pulses. Having a loop of pulse 
>> exceptions that happened with the JVM crash is rarer. It breaks the 
>> layout however, so a restart is required.
>>
>> I would already be happy with a simple index check to not throw an 
>> OOB exception in the implementation, I don't think there's any harm 
>> in that. While the StackOverflow is a very made-up case, I think even 
>> for that it would be good if it wouldn't throw exceptions in later 
>> pulses if you're looking for a justification on why to implement an 
>> index check.
>>
>> On 28/03/2025 17:26, Martin Fox wrote:
>>> I?ve been able to reproduce this inside a debugger on my Mac every 
>>> eighth try or so.
>>>
>>> I?m not sure what I?m seeing is all that helpful. Your reproducing 
>>> case is inducing a stack overflow exception. If the exception occurs 
>>> while Parent.updateCachedBounds is executing the StackPane will be 
>>> left in a bad state. This leads to the dirtyChildrenCount exceeding 
>>> the number of children and then Parent.updateCachedBounds will start 
>>> throwing the same AIOOBE on every layout pulse.
>>>
>>> At least in my debug runs it?s all about the timing of the stack 
>>> overflow. That probably doesn?t explain why your production app is 
>>> getting into the same bad state.
>>>
>>> And you?re right, this has nothing to do with the Alert. I was 
>>> confused by the gap between when the exception occurs and when it?s 
>>> reported.
>>>
>>> Martin
>>>
>>>> On Mar 26, 2025, at 9:20?PM, Christopher Schnick 
>>>> <crschnick at xpipe.io> wrote:
>>>>
>>>> Interesting, that exception does not happen on my macOS 15.3 
>>>> system. The reproducer somehow also doesn't seem to trigger the 
>>>> IndexOutOfBoundsExceptions on macOS for me, only on Windows so far. 
>>>> On Windows, the large alert is shown as a broken stage with no 
>>>> content and controls for me, which I guess is slightly better than 
>>>> an exception, but also not ideal.? So it seems like the reproducer 
>>>> behavior depends a lot on the specific system.
>>>>
>>>> On 26/03/2025 19:35, Martin Fox wrote:
>>>>> Christopher,
>>>>>
>>>>> Yes, there might be more than one issue here. On the Mac the call 
>>>>> to Stage.showAndWait is making its way into the Mac glass code 
>>>>> where an exception is being thrown leading to another call to 
>>>>> Stage.showAndWait. I?ve attached the repeating block below. I 
>>>>> don?t see that pattern in the Windows stack trace you provided.
>>>>>
>>>>> Martin
>>>>>
>>>>> at ParentBoundsBug.lambda$start$0(ParentBoundsBug.java:25)
>>>>> at 
>>>>> java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:663)
>>>>> at 
>>>>> java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:658)
>>>>> at 
>>>>> javafx.graphics at 25-internal/com.sun.glass.ui.Application.reportException(Application.java:452)
>>>>> at 
>>>>> javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacWindow._setBounds2(Native 
>>>>> Method)
>>>>> at 
>>>>> javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacWindow._setBounds(MacWindow.java:70)
>>>>> at 
>>>>> javafx.graphics at 25-internal/com.sun.glass.ui.Window.setBounds(Window.java:589)
>>>>> at 
>>>>> javafx.graphics at 25-internal/com.sun.javafx.tk.quantum.WindowStage.setBounds(WindowStage.java:304)
>>>>> at 
>>>>> javafx.graphics at 25-internal/javafx.stage.Window$TKBoundsConfigurator.apply(Window.java:1566)
>>>>> at 
>>>>> javafx.graphics at 25-internal/javafx.stage.Window.applyBounds(Window.java:1424)
>>>>> at 
>>>>> javafx.graphics at 25-internal/javafx.stage.Window.adjustSize(Window.java:327)
>>>>> at 
>>>>> javafx.graphics at 25-internal/javafx.stage.Window.sizeToScene(Window.java:284)
>>>>> at 
>>>>> javafx.graphics at 25-internal/javafx.stage.Window$12.invalidated(Window.java:1215)
>>>>> at 
>>>>> javafx.base at 25-internal/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
>>>>> at 
>>>>> javafx.base at 25-internal/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
>>>>> at 
>>>>> javafx.graphics at 25-internal/javafx.stage.Window.setShowing(Window.java:1235)
>>>>> at 
>>>>> javafx.graphics at 25-internal/javafx.stage.Window.show(Window.java:1250)
>>>>> at javafx.graphics at 25-internal/javafx.stage.Stage.show(Stage.java:272)
>>>>> at 
>>>>> javafx.graphics at 25-internal/javafx.stage.Stage.showAndWait(Stage.java:427)
>>>>> at 
>>>>> javafx.controls at 25-internal/javafx.scene.control.HeavyweightDialog.showAndWait(HeavyweightDialog.java:162)
>>>>> at 
>>>>> javafx.controls at 25-internal/javafx.scene.control.Dialog.showAndWait(Dialog.java:347)
>>>>> at ParentBoundsBug.lambda$start$0(ParentBoundsBug.java:25)
>>>>> at 
>>>>> java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:663)
>>>>> at 
>>>>> java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:658)
>>>>>
>>>>>> On Mar 26, 2025, at 10:49?AM, Christopher Schnick 
>>>>>> <crschnick at xpipe.io> wrote:
>>>>>>
>>>>>> Hey Martin,
>>>>>>
>>>>>> thank you for looking into this. The initial StackOverflow is a 
>>>>>> result of me forcing to reproduce the bounds 
>>>>>> IndexOutOfBoundsException. The StackOverflow can be ignored, it 
>>>>>> was merely the best method I found to transition the scene graph 
>>>>>> into a state where the IndexOutOfBoundsExceptions are thrown. The 
>>>>>> OOBs are not thrown in every run though, it sometimes takes a few 
>>>>>> tries. In our production application, the same 
>>>>>> IndexOutOfBoundsExceptions also occur randomly without a previous 
>>>>>> exception. You can probably also reproduce the 
>>>>>> IndexOutOfBoundsExceptions without the StackOverflow, but 
>>>>>> reproducing it was very fragile, so I didn't look into it more.
>>>>>>
>>>>>> I don't think it has necessarily something to do with the alert 
>>>>>> bounds as the IndexOutOfBoundsException is also thrown if you 
>>>>>> don't show an alert at all. The constant 
>>>>>> IndexOutOfBoundsExceptions in combination with the alert 
>>>>>> showAndWait was how our application entered the original crashing 
>>>>>> state. So the reproducer is more like a two-in-one.
>>>>>>
>>>>>> Best
>>>>>> Christopher Schnick
>>>>>>
>>>>>> On 26/03/2025 18:33, Martin Fox wrote:
>>>>>>> Yes, thank you Christopher for providing a reproducible test case!
>>>>>>>
>>>>>>> I was able to trigger the problem on my Mac on the first try. 
>>>>>>> Since I?m using a modified version of JavaFX the system didn?t 
>>>>>>> crash but instead hit a Java stack overflow error and produced a 
>>>>>>> very long stack trace.
>>>>>>>
>>>>>>> At least on the Mac the problem seems to be that you?re trying 
>>>>>>> to pop an Alert containing a long stack trace. While trying to 
>>>>>>> adjust the Alert?s bounds JavaFX is throwing another exception 
>>>>>>> but I?m not sure why. I?ll continue to look into it.
>>>>>>>
>>>>>>> Thanks again,
>>>>>>> Martin
>>>>>>>
>>>>>>>> On Mar 25, 2025, at 12:16?PM, Andy Goryachev 
>>>>>>>> <andy.goryachev at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Thank you, Christopher, for clarification!
>>>>>>>> Personally, I would consider this to be a problem with the 
>>>>>>>> application design: the code should limit the number of alerts 
>>>>>>>> shown to the user.? Do you really want the user to click 
>>>>>>>> through hundreds of alerts?
>>>>>>>> Nevertheless, you are right about the need for the platform to 
>>>>>>>> gracefully handle the case of too many nested event loops - by 
>>>>>>>> throwing an exception with a meaningful message, as Martin 
>>>>>>>> proposed inhttps://github.com/openjdk/jfx/pull/1741
>>>>>>>> Cheers,
>>>>>>>> -andy
>>>>>>>>
>>>>>>>> *From:*Christopher Schnick <crschnick at xpipe.io>
>>>>>>>> *Date:*Tuesday, March 25, 2025 at 11:52
>>>>>>>> *To:*Andy Goryachev <andy.goryachev at oracle.com>
>>>>>>>> *Cc:*OpenJFX <openjfx-dev at openjdk.org>
>>>>>>>> *Subject:*Re: [External] : Re: JVM crashes on macOS when 
>>>>>>>> entering too many nested event loops
>>>>>>>>
>>>>>>>> Hey Andy,
>>>>>>>>
>>>>>>>> so I think I was able to reproduce this issue for our application.
>>>>>>>>
>>>>>>>> There are two main factors how this can happen:
>>>>>>>> - We use an alert-based error reporter, meaning that we have a 
>>>>>>>> default uncaught exception handler set for all threads which 
>>>>>>>> will showAndWait an Alert with the exception message
>>>>>>>> - As I reported yesterday 
>>>>>>>> withhttps://mail.openjdk.org/pipermail/openjfx-dev/2025-March/052963.html, 
>>>>>>>> there are some rare exceptions that can occur in a normal event 
>>>>>>>> loop without interference of the application, probably because 
>>>>>>>> of a small bug in the bounds calculation code
>>>>>>>>
>>>>>>>> If you combine these two factors, you will end up with an 
>>>>>>>> infinite loop of the showAndWait entering a nested event loop, 
>>>>>>>> the event loop throwing an internal exception, and the uncaught 
>>>>>>>> exception handler starting the same loop with another alert. I 
>>>>>>>> don't think this is a bad implementation from our side, the 
>>>>>>>> only thing that we can improve is to maybe check how deep the 
>>>>>>>> uncaught exception loop is in to prevent this from occurring 
>>>>>>>> indefinitely. But I would argue this can happen to any 
>>>>>>>> application. Here is a sample code, based on the reproducer 
>>>>>>>> from the OutOfBounds report from yesterday:
>>>>>>>>
>>>>>>>> import javafx.application.Application;
>>>>>>>> import javafx.application.Platform;
>>>>>>>> import javafx.scene.Scene;
>>>>>>>> import javafx.scene.control.Alert;
>>>>>>>> import javafx.scene.control.Button;
>>>>>>>> import javafx.scene.layout.Region;
>>>>>>>> import javafx.scene.layout.StackPane;
>>>>>>>> import javafx.scene.layout.VBox;
>>>>>>>> import javafx.stage.Stage;
>>>>>>>> import java.io.IOException;
>>>>>>>> import java.util.Arrays;
>>>>>>>> public class ParentBoundsBug extends Application {
>>>>>>>> @Override
>>>>>>>> public void start(Stage stage) throws IOException {
>>>>>>>> ??????? Thread./setDefaultUncaughtExceptionHandler/((thread, 
>>>>>>>> throwable) -> {
>>>>>>>> ??????????? throwable.printStackTrace();
>>>>>>>> if (Platform./isFxApplicationThread/()) {
>>>>>>>> var alert = new Alert(Alert.AlertType./ERROR/);
>>>>>>>> ??????????????? alert.setHeaderText(throwable.getMessage());
>>>>>>>> ??????????????? 
>>>>>>>> alert.setContentText(Arrays./toString/(throwable.getStackTrace()));
>>>>>>>> ??????????????? alert.showAndWait();
>>>>>>>> ??????????? } else {
>>>>>>>> // Do some other error handling for non-platform threads
>>>>>>>> ??????????????? // Probably just show the alert with a runLater()
>>>>>>>> ??????????????? // For this example, there are no exceptions 
>>>>>>>> outside the platform thread
>>>>>>>> }
>>>>>>>> ??????? });
>>>>>>>> // Run delayed as Application::reportException will only be 
>>>>>>>> called for exceptions
>>>>>>>> ??????? // after the application has started
>>>>>>>> Platform./runLater/(() -> {
>>>>>>>> ??????????? Scene scene = new Scene(createContent(), 640, 480);
>>>>>>>> stage.setScene(scene);
>>>>>>>> stage.show();
>>>>>>>> stage.centerOnScreen();
>>>>>>>> ??????? });
>>>>>>>> ??? }
>>>>>>>> private Region createContent() {
>>>>>>>> var b1 = new Button("Click me!");
>>>>>>>> var b2 = new Button("Click me!");
>>>>>>>> var vbox = new VBox(b1, b2);
>>>>>>>> ??????? b1.boundsInParentProperty().addListener((observable, 
>>>>>>>> oldValue, newValue) -> {
>>>>>>>> vbox.setVisible(!vbox.isVisible());
>>>>>>>> ??????? });
>>>>>>>> ??????? b2.boundsInParentProperty().addListener((observable, 
>>>>>>>> oldValue, newValue) -> {
>>>>>>>> vbox.setVisible(!vbox.isVisible());
>>>>>>>> ??????? });
>>>>>>>> ??????? vbox.boundsInParentProperty().addListener((observable, 
>>>>>>>> oldValue, newValue) -> {
>>>>>>>> vbox.setVisible(!vbox.isVisible());
>>>>>>>> ??????? });
>>>>>>>> var stack = new StackPane(vbox, new StackPane());
>>>>>>>> ??????? stack.boundsInParentProperty().addListener((observable, 
>>>>>>>> oldValue, newValue) -> {
>>>>>>>> vbox.setVisible(!vbox.isVisible());
>>>>>>>> ??????? });
>>>>>>>> return stack;
>>>>>>>> ??? }
>>>>>>>> public static void main(String[] args) {
>>>>>>>> /launch/();
>>>>>>>> ??? }
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> If the same OutOfBounds exception from the reported I linked 
>>>>>>>> happens in the bounds calculation, which happens approximately 
>>>>>>>> 1/5 runs for me, this application will enter new event loops 
>>>>>>>> until it crashes. If the OutOfBounds doesn't trigger, it will 
>>>>>>>> just throw a StackOverflow but won't continue the infinite loop 
>>>>>>>> of nested event loops. So for the reproducer it is important to 
>>>>>>>> try a few times until you get the described OutOfBounds.
>>>>>>>>
>>>>>>>> I attached the stacktrace of how this fails. The initial 
>>>>>>>> StackOverflow causes infinitely many following exceptions in 
>>>>>>>> the nested event loop.
>>>>>>>>
>>>>>>>> Best
>>>>>>>> Christopher Schnick
>>>>>>>>
>>>>>>>> On 25/03/2025 18:28, Andy Goryachev wrote:
>>>>>>>>
>>>>>>>>     Dear Christopher:
>>>>>>>>     Were you able to root cause why your application enters
>>>>>>>>     that many nested event loops?
>>>>>>>>     I believe a well-behaved application should never
>>>>>>>>     experience that, unless there is some design flaw or a bug.
>>>>>>>>     -andy
>>>>>>>>
>>>>>>>>     *From:*Christopher Schnick<crschnick at xpipe.io>
>>>>>>>>     <mailto:crschnick at xpipe.io>
>>>>>>>>     *Date:*Monday, March 10, 2025 at 19:45
>>>>>>>>     *To:*Andy Goryachev<andy.goryachev at oracle.com>
>>>>>>>>     <mailto:andy.goryachev at oracle.com>
>>>>>>>>     *Subject:*[External] : Re: JVM crashes on macOS when
>>>>>>>>     entering too many nested event loops
>>>>>>>>
>>>>>>>>     Our code and some libraries do enter some nested event
>>>>>>>>     loops at a few places when it makes sense, but we didn't do
>>>>>>>>     anything to explicitly provoke this, this occurred
>>>>>>>>     naturally in our application. So it would be nice if JavaFX
>>>>>>>>     could somehow guard against this, especially since crashing
>>>>>>>>     the JVM is probably the worst thing that can happen.
>>>>>>>>
>>>>>>>>     I looked at the documentation, but it seems like the public
>>>>>>>>     API at Platform::enterNestedEventLoop does not mention this.
>>>>>>>>     From my understanding, the method
>>>>>>>>     Platform::canStartNestedEventLoop is potentially the right
>>>>>>>>     method to indicate to the caller that the limit is close by
>>>>>>>>     returning false.
>>>>>>>>     And even if something like an exception is thrown when a
>>>>>>>>     nested event loop is started while it is close to the
>>>>>>>>     limit, that would still be much better than a direct crash.
>>>>>>>>
>>>>>>>>     Best
>>>>>>>>     Christopher Schnick
>>>>>>>>
>>>>>>>>     On 10/03/2025 18:51, Andy Goryachev wrote:
>>>>>>>>
>>>>>>>>         This looks to me like it might be hitting the (native)
>>>>>>>>         thread stack size limit.
>>>>>>>>         c.s.glass.ui.Application::enterNestedEventLoop() even
>>>>>>>>         warns about it:
>>>>>>>>         * An application may enter several nested loops
>>>>>>>>         recursively. There's no
>>>>>>>>         * limit of recursion other than that imposed by the
>>>>>>>>         native stack size.
>>>>>>>>         -andy
>>>>>>>>
>>>>>>>>         *From:*openjfx-dev<openjfx-dev-retn at openjdk.org>
>>>>>>>>         <mailto:openjfx-dev-retn at openjdk.org>on behalf of
>>>>>>>>         Martin Fox<martinfox656 at gmail.com>
>>>>>>>>         <mailto:martinfox656 at gmail.com>
>>>>>>>>         *Date:*Monday, March 10, 2025 at 10:10
>>>>>>>>         *To:*Christopher Schnick<crschnick at xpipe.io>
>>>>>>>>         <mailto:crschnick at xpipe.io>
>>>>>>>>         *Cc:*OpenJFX<openjfx-dev at openjdk.org>
>>>>>>>>         <mailto:openjfx-dev at openjdk.org>
>>>>>>>>         *Subject:*Re: JVM crashes on macOS when entering too
>>>>>>>>         many nested event loops
>>>>>>>>
>>>>>>>>         Hi Christopher,
>>>>>>>>
>>>>>>>>         I was able to reproduce this crash. I wrote a small
>>>>>>>>         routine that recursively calls itself in a runLater
>>>>>>>>         block and then enters a nested event loop. The program
>>>>>>>>         crashes when creating loop 254. I?m not sure where that
>>>>>>>>         limit comes from so it?s possible that consuming some
>>>>>>>>         other system resource could lower it. I couldn?t see
>>>>>>>>         any good way to determine how many loops are active by
>>>>>>>>         looking at the crash report since it doesn?t show the
>>>>>>>>         entire call stack.
>>>>>>>>         I did a quick trial on Linux and was able to create a
>>>>>>>>         lot more loops (over 600) but then started seeing
>>>>>>>>         erratic behavior and errors coming from the Java VM.
>>>>>>>>         The behavior was variable unlike on the Mac which
>>>>>>>>         always crashes when creating loop 254.
>>>>>>>>
>>>>>>>>         Martin
>>>>>>>>
>>>>>>>>         > On Mar 7, 2025, at 6:24?AM, Christopher
>>>>>>>>         Schnick<crschnick at xpipe.io>
>>>>>>>>         <mailto:crschnick at xpipe.io>wrote:
>>>>>>>>         >
>>>>>>>>         > Hello,
>>>>>>>>         >
>>>>>>>>         > I have attached a JVM fatal error log that seemingly
>>>>>>>>         was caused by our JavaFX application entering too many
>>>>>>>>         nested event loops, which macOS apparently doesn't like.
>>>>>>>>         >
>>>>>>>>         > As far as I know, there is no upper limit defined on
>>>>>>>>         how often an event loop can be nested, so I think this
>>>>>>>>         is a bug that can occur in rare situations.
>>>>>>>>         >
>>>>>>>>         > Best
>>>>>>>>         > Christopher Schnick<hs_err_pid.txt>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250403/3e8d0785/attachment-0001.htm>

From arapte at openjdk.org  Thu Apr  3 05:13:55 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 3 Apr 2025 05:13:55 GMT
Subject: RFR: 8353587: Spelling errors and dead code
In-Reply-To: <JsCpNkfgSc-GS_IFokWtVGUDrJMiC4bZ0WAh6geC7n8=.1f052ec0-0b93-4b60-a68e-d43acce92c58@github.com>
References: <JsCpNkfgSc-GS_IFokWtVGUDrJMiC4bZ0WAh6geC7n8=.1f052ec0-0b93-4b60-a68e-d43acce92c58@github.com>
Message-ID: <I6F3IL2ckEHhG0r_CYd3hdXrSlMxhFlUc7g8eW6WrFo=.1b8d3afe-cd67-41f2-b7a6-89c1f107fd88@github.com>

On Wed, 2 Apr 2025 22:03:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Corrects annoying spelling errors in the code:
> 
> - propogated
> - Hueristic2D
> 
> Also fixes unnecessary field in MenuBar:171

LGTM

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1757#pullrequestreview-2738527666

From mstrauss at openjdk.org  Thu Apr  3 08:32:54 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 3 Apr 2025 08:32:54 GMT
Subject: RFR: 8351276: Prevent redundant computeValue calls when a chain of
 mappings becomes observed [v2]
In-Reply-To: <XNlwzdSP5rvOtUngLSHFj33W8yMzv2O3iDkRzk7hv9U=.a32ff784-5487-4018-8ed0-0ec1f66f1c88@github.com>
References: <IyHADMCaatpnRYZ2g7a6OHCDsuw7JZULs-dbWKmssv8=.25763986-bb17-4600-b505-0fdd9b601f26@github.com>
 <XNlwzdSP5rvOtUngLSHFj33W8yMzv2O3iDkRzk7hv9U=.a32ff784-5487-4018-8ed0-0ec1f66f1c88@github.com>
Message-ID: <zFF9BaYYRvmS3ReZyIudjP3IeXK6xc6iz_ZInFk-u5w=.25aeb3d1-bc39-4a7d-a84b-4666c3a5dd9d@github.com>

On Wed, 2 Apr 2025 08:36:22 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> 8351276: Prevent redundant computeValue calls when a chain of mappings becomes observed
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix review comments

Marked as reviewed by mstrauss (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1730#pullrequestreview-2738959420

From arapte at openjdk.org  Thu Apr  3 08:33:59 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 3 Apr 2025 08:33:59 GMT
Subject: RFR: 8353548: [macOS] DragEvent.getScreenY() returns incorrect
 value in secondary monitor
In-Reply-To: <xWx93iazM2hTIGMWyRIRHDN8ZU74rNyCk5vyOrFLkmM=.c4bd574c-0dbe-4430-9112-9859401fe899@github.com>
References: <xWx93iazM2hTIGMWyRIRHDN8ZU74rNyCk5vyOrFLkmM=.c4bd574c-0dbe-4430-9112-9859401fe899@github.com>
Message-ID: <rkfI0bspyEtIA3VunoQ6spOEWJzO-8VDliGG-4xqDUc=.61e24faf-394f-4665-b665-b079777b3396@github.com>

On Wed, 2 Apr 2025 17:05:58 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR fixes an issue when dragEvents occur in a secondary screen which doesn't have the same height or (macOS) origin as the main screen.
> 
> The calculations for `xAbs, yAbs` are defined from the main screen macOS absolute origin, an in order to flip the coordinates defined from the JavaFX origin, the height from the main screen should be used, and not the height from secondary screens, which was the case in `GlassViewDelegate::sendJavaDndEvent`.
> 
> The PR doesn't include tests because it needs a complex setup (two monitors), but the change has been tested on macOS 15.3.2 with the test case from https://bugs.openjdk.org/browse/JDK-8353548, using two monitors (built-in Retina and external 4K display), rearranging their layout (left-bottom-right from main screen), and relative resolution.

Looks safe from documentation of [[NSScreen screens]](https://developer.apple.com/documentation/appkit/nsscreen/screens?language=objc).
Tested with 2 external monitors, tried several combinations and samples. LGTM.

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1756#pullrequestreview-2738961436

From arapte at openjdk.org  Thu Apr  3 08:48:47 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 3 Apr 2025 08:48:47 GMT
Subject: RFR: 8352982: gradle TEST_SDK_PATH param doesn't work with
 relative paths [v3]
In-Reply-To: <nQBSuBQvVW0itJLRR-Cs0TOm6ymltaWG-2BufQky1xI=.b39146a4-4f68-4459-929a-6b54d4ba0437@github.com>
References: <nQBSuBQvVW0itJLRR-Cs0TOm6ymltaWG-2BufQky1xI=.b39146a4-4f68-4459-929a-6b54d4ba0437@github.com>
Message-ID: <mJltA1dyuLEv04cofj6XcU7bTPMO64H-7Wd_CQ8CnGM=.7923c286-04fc-4a47-8f0e-b9f4efb40647@github.com>

> Issue:
> The test execution fails when a relative path is specified a relative path for `TEST_SDK_PATH`.
> For example:
> 1. gradle -PTEST_ONLY=true -PTEST_SDK_PATH=**..**/jfx1/build test 
> 2. gradle -PTEST_ONLY=true -PTEST_SDK_PATH=**~**/jfx1/build test
> 
> Solution:
> Convert the relative path to an absolute path.
> 
> More about fix:
> The property TEST_SDK_PATH belongs to the root project rt in build.gradle.
> If we modify this property in build.gradle, it does not reflect in the child projects. The child projects for example graphics, controls would still have the value of TEST_SDK_PATH before modification.
> To solve this, I Introduced a new variable in build.gradle `TEST_SDK_DIR`. It would hold the modified value of `TEST_SDK_PATH` and gets correctly reflected across all sub-projects.
> 
> Verified that both relative paths and absolute path work fine after this change.

Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:

  review fix

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1751/files
  - new: https://git.openjdk.org/jfx/pull/1751/files/92945555..021d9069

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1751&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1751&range=01-02

  Stats: 9 lines in 1 file changed: 3 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1751.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1751/head:pull/1751

PR: https://git.openjdk.org/jfx/pull/1751

From mstrauss at openjdk.org  Thu Apr  3 08:52:47 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 3 Apr 2025 08:52:47 GMT
Subject: RFR: 8353617: Remove deprecated TransitionEvent constructor
Message-ID: <7nUoQ15p5_0UbIAu4LF1zhu3EJiNeMbDIGKQyvwD2Bk=.af1d3026-dd66-403d-a65c-a9401da0d56f@github.com>

Remove the deprecated `TransitionEvent(EventType, StyleableProperty, Duration)` constructor.

A single reviewer should be sufficient.

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

Commit messages:
 - remove TransitionEvent constructor

Changes: https://git.openjdk.org/jfx/pull/1758/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1758&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353617
  Stats: 17 lines in 1 file changed: 0 ins; 16 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1758.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1758/head:pull/1758

PR: https://git.openjdk.org/jfx/pull/1758

From jhendrikx at openjdk.org  Thu Apr  3 10:39:08 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 3 Apr 2025 10:39:08 GMT
Subject: Integrated: 8351276: Prevent redundant computeValue calls when a chain
 of mappings becomes observed
In-Reply-To: <IyHADMCaatpnRYZ2g7a6OHCDsuw7JZULs-dbWKmssv8=.25763986-bb17-4600-b505-0fdd9b601f26@github.com>
References: <IyHADMCaatpnRYZ2g7a6OHCDsuw7JZULs-dbWKmssv8=.25763986-bb17-4600-b505-0fdd9b601f26@github.com>
Message-ID: <0kAHFlNbbJjpjYBjYYbGEd9-mqpn1Fib2pFTETXei_A=.8d722bd6-3947-4ba2-8174-12083a73f3c8@github.com>

On Thu, 6 Mar 2025 15:22:58 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> 8351276: Prevent redundant computeValue calls when a chain of mappings becomes observed

This pull request has now been integrated.

Changeset: ab94b5e7
Author:    John Hendrikx <jhendrikx at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/ab94b5e71c17ebe941f3086d43164ee58d19f4b7
Stats:     147 lines in 3 files changed: 139 ins; 1 del; 7 mod

8351276: Prevent redundant computeValue calls when a chain of mappings becomes observed

Reviewed-by: mstrauss, nlisker

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

PR: https://git.openjdk.org/jfx/pull/1730

From jhendrikx at openjdk.org  Thu Apr  3 10:41:58 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 3 Apr 2025 10:41:58 GMT
Subject: RFR: 8353617: Remove deprecated TransitionEvent constructor
In-Reply-To: <7nUoQ15p5_0UbIAu4LF1zhu3EJiNeMbDIGKQyvwD2Bk=.af1d3026-dd66-403d-a65c-a9401da0d56f@github.com>
References: <7nUoQ15p5_0UbIAu4LF1zhu3EJiNeMbDIGKQyvwD2Bk=.af1d3026-dd66-403d-a65c-a9401da0d56f@github.com>
Message-ID: <U_Nbg3r0ociS7GJ6l7qEYoetpqmBa4Vrm8rdHN8aC0Q=.60b5b0b0-c133-4d64-a0fd-0f7488603f13@github.com>

On Thu, 3 Apr 2025 08:47:51 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Remove the deprecated `TransitionEvent(EventType, StyleableProperty, Duration)` constructor.
> 
> A single reviewer should be sufficient.

Marked as reviewed by jhendrikx (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1758#pullrequestreview-2739370644

From arapte at openjdk.org  Thu Apr  3 10:58:09 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 3 Apr 2025 10:58:09 GMT
Subject: RFR: 8352982: gradle TEST_SDK_PATH param doesn't work with
 relative paths [v2]
In-Reply-To: <P6Sa8W1DzzQbmKd3A8A5o3trgRpAVSL1sKvyRQt4kR4=.78f7c357-a305-4fcd-951c-643191b5ce46@github.com>
References: <nQBSuBQvVW0itJLRR-Cs0TOm6ymltaWG-2BufQky1xI=.b39146a4-4f68-4459-929a-6b54d4ba0437@github.com>
 <7NOEK_py0Uv07O86R5E400mBdAC9lq-c4g9k9ELdwyk=.28100c76-f12f-442b-a166-e1bd5e801a17@github.com>
 <P6Sa8W1DzzQbmKd3A8A5o3trgRpAVSL1sKvyRQt4kR4=.78f7c357-a305-4fcd-951c-643191b5ce46@github.com>
Message-ID: <3nuRsTy7iEMTo-TTB9qWgxo0cdg4YScj3l0WwXrN9T4=.609bddbc-710b-42c9-b8db-c6cc5775584e@github.com>

On Wed, 2 Apr 2025 11:41:23 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> always use file(testSdkPath).absolutePath?

This sounds better, changed accordingly.

> build.gradle line 745:
> 
>> 743:     ext.TEST_SDK_DIR = "${rootProject.buildDir}"
>> 744: }
>> 745: println "TEST_SDK_PATH: " + TEST_SDK_DIR
> 
> Minor: Consider moving this down to the block where most other build properties like this are logged?

Moved to use `logger.quiet` along with other properties.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1751#discussion_r2026743417
PR Review Comment: https://git.openjdk.org/jfx/pull/1751#discussion_r2026743373

From kcr at openjdk.org  Thu Apr  3 12:37:05 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 3 Apr 2025 12:37:05 GMT
Subject: RFR: 8353617: Remove deprecated TransitionEvent constructor
In-Reply-To: <7nUoQ15p5_0UbIAu4LF1zhu3EJiNeMbDIGKQyvwD2Bk=.af1d3026-dd66-403d-a65c-a9401da0d56f@github.com>
References: <7nUoQ15p5_0UbIAu4LF1zhu3EJiNeMbDIGKQyvwD2Bk=.af1d3026-dd66-403d-a65c-a9401da0d56f@github.com>
Message-ID: <dKE40rXOqeNtdHj3YFtFcOyITD-yI_KmwcuSbix6Ixk=.592635b2-29f2-42f7-8014-0a20f26e2b31@github.com>

On Thu, 3 Apr 2025 08:47:51 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Remove the deprecated `TransitionEvent(EventType, StyleableProperty, Duration)` constructor.
> 
> A single reviewer should be sufficient.

Marked as reviewed by kcr (Lead).

Since this needs a CSR, a second reviewer is best. I'll do that, since I want to review the CSR anyway.

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

PR Review: https://git.openjdk.org/jfx/pull/1758#pullrequestreview-2739689212
PR Comment: https://git.openjdk.org/jfx/pull/1758#issuecomment-2775647602

From kcr at openjdk.org  Thu Apr  3 12:40:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 3 Apr 2025 12:40:57 GMT
Subject: RFR: 8353617: Remove deprecated TransitionEvent constructor
In-Reply-To: <7nUoQ15p5_0UbIAu4LF1zhu3EJiNeMbDIGKQyvwD2Bk=.af1d3026-dd66-403d-a65c-a9401da0d56f@github.com>
References: <7nUoQ15p5_0UbIAu4LF1zhu3EJiNeMbDIGKQyvwD2Bk=.af1d3026-dd66-403d-a65c-a9401da0d56f@github.com>
Message-ID: <K9rDiRtA3H5yH52KlOqNmg4U6-N93nrKB8C_pOmRNik=.6aad8e3d-cb5e-4527-bc0e-a81e8ffa0471@github.com>

On Thu, 3 Apr 2025 08:47:51 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Remove the deprecated `TransitionEvent(EventType, StyleableProperty, Duration)` constructor.
> 
> A single reviewer should be sufficient.

@mstr2 I reviewed the CSR, so you can Finalize it at your convenience.

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

PR Comment: https://git.openjdk.org/jfx/pull/1758#issuecomment-2775657182

From kcr at openjdk.org  Thu Apr  3 12:47:54 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 3 Apr 2025 12:47:54 GMT
Subject: RFR: 8352982: gradle TEST_SDK_PATH param doesn't work with
 relative paths [v3]
In-Reply-To: <mJltA1dyuLEv04cofj6XcU7bTPMO64H-7Wd_CQ8CnGM=.7923c286-04fc-4a47-8f0e-b9f4efb40647@github.com>
References: <nQBSuBQvVW0itJLRR-Cs0TOm6ymltaWG-2BufQky1xI=.b39146a4-4f68-4459-929a-6b54d4ba0437@github.com>
 <mJltA1dyuLEv04cofj6XcU7bTPMO64H-7Wd_CQ8CnGM=.7923c286-04fc-4a47-8f0e-b9f4efb40647@github.com>
Message-ID: <fssQb9Q8zikk-n2waKfGFJ5UtOCqFobmJoxIN8s3zOM=.5441bb81-f575-471f-b473-07db48af116a@github.com>

On Thu, 3 Apr 2025 08:48:47 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Issue:
>> The test execution fails when a relative path is specified a relative path for `TEST_SDK_PATH`.
>> For example:
>> 1. gradle -PTEST_ONLY=true -PTEST_SDK_PATH=**..**/jfx1/build test 
>> 2. gradle -PTEST_ONLY=true -PTEST_SDK_PATH=**~**/jfx1/build test
>> 
>> Solution:
>> Convert the relative path to an absolute path.
>> 
>> More about fix:
>> The property TEST_SDK_PATH belongs to the root project rt in build.gradle.
>> If we modify this property in build.gradle, it does not reflect in the child projects. The child projects for example graphics, controls would still have the value of TEST_SDK_PATH before modification.
>> To solve this, I Introduced a new variable in build.gradle `TEST_SDK_DIR`. It would hold the modified value of `TEST_SDK_PATH` and gets correctly reflected across all sub-projects.
>> 
>> Verified that both relative paths and absolute path work fine after this change.
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review fix

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1751#pullrequestreview-2739719022

From jbhaskar at openjdk.org  Thu Apr  3 13:15:31 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Thu, 3 Apr 2025 13:15:31 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
Message-ID: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>

Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.

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

Commit messages:
 - remove trailing white space
 - 8340464: [TestBug] Convert parametrized base tests to JUnit 5

Changes: https://git.openjdk.org/jfx/pull/1759/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1759&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340464
  Stats: 5126 lines in 38 files changed: 2144 ins; 771 del; 2211 mod
  Patch: https://git.openjdk.org/jfx/pull/1759.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1759/head:pull/1759

PR: https://git.openjdk.org/jfx/pull/1759

From arapte at openjdk.org  Thu Apr  3 14:19:00 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 3 Apr 2025 14:19:00 GMT
Subject: Integrated: 8352982: gradle TEST_SDK_PATH param doesn't work with
 relative paths
In-Reply-To: <nQBSuBQvVW0itJLRR-Cs0TOm6ymltaWG-2BufQky1xI=.b39146a4-4f68-4459-929a-6b54d4ba0437@github.com>
References: <nQBSuBQvVW0itJLRR-Cs0TOm6ymltaWG-2BufQky1xI=.b39146a4-4f68-4459-929a-6b54d4ba0437@github.com>
Message-ID: <6efxQ5dTGUW0YgyQZutT497tS6Gkl0HfGPvShM5AN_8=.c351bc6d-bee6-45c2-aacc-06114f51169a@github.com>

On Tue, 1 Apr 2025 06:36:24 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Issue:
> The test execution fails when a relative path is specified a relative path for `TEST_SDK_PATH`.
> For example:
> 1. gradle -PTEST_ONLY=true -PTEST_SDK_PATH=**..**/jfx1/build test 
> 2. gradle -PTEST_ONLY=true -PTEST_SDK_PATH=**~**/jfx1/build test
> 
> Solution:
> Convert the relative path to an absolute path.
> 
> More about fix:
> The property TEST_SDK_PATH belongs to the root project rt in build.gradle.
> If we modify this property in build.gradle, it does not reflect in the child projects. The child projects for example graphics, controls would still have the value of TEST_SDK_PATH before modification.
> To solve this, I Introduced a new variable in build.gradle `TEST_SDK_DIR`. It would hold the modified value of `TEST_SDK_PATH` and gets correctly reflected across all sub-projects.
> 
> Verified that both relative paths and absolute path work fine after this change.

This pull request has now been integrated.

Changeset: c0db2dcd
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/c0db2dcda40db09bbcb9ec12a549fefa85e4325e
Stats:     18 lines in 1 file changed: 6 ins; 0 del; 12 mod

8352982: gradle TEST_SDK_PATH param doesn't work with relative paths

Reviewed-by: kcr

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

PR: https://git.openjdk.org/jfx/pull/1751

From kevin.rushforth at oracle.com  Thu Apr  3 14:43:19 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 3 Apr 2025 07:43:19 -0700
Subject: JavaFX slides from JavaOne 2025
Message-ID: <097511ee-7b76-4729-b783-32dea2714df0@oracle.com>

In case anyone is interested, here is the slide deck I presented at 
JavaOne 2025 for the "JavaFX 24 and Beyond" session.

https://cr.openjdk.org/~kcr/presentations/javaone-2025/JavaFX-24-Final.pdf

-- Kevin


From michaelstrau2 at gmail.com  Thu Apr  3 14:59:49 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Thu, 3 Apr 2025 16:59:49 +0200
Subject: Feature Request: Support for Transparent Title Bars in JavaFX
 Stages
In-Reply-To: <96527358-3EA3-40DE-8992-658AF141C42E@gmail.com>
References: <96527358-3EA3-40DE-8992-658AF141C42E@gmail.com>
Message-ID: <CAJEpuXSdBbSydpZ-sFbTVWieEPSyYxFb3ZYidEvR78NaTBTv1g@mail.gmail.com>

Already under way: https://github.com/openjdk/jfx/pull/1605

From jpereda at openjdk.org  Thu Apr  3 15:08:05 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Thu, 3 Apr 2025 15:08:05 GMT
Subject: Integrated: 8353548: [macOS] DragEvent.getScreenY() returns incorrect
 value in secondary monitor
In-Reply-To: <xWx93iazM2hTIGMWyRIRHDN8ZU74rNyCk5vyOrFLkmM=.c4bd574c-0dbe-4430-9112-9859401fe899@github.com>
References: <xWx93iazM2hTIGMWyRIRHDN8ZU74rNyCk5vyOrFLkmM=.c4bd574c-0dbe-4430-9112-9859401fe899@github.com>
Message-ID: <E_qS8-d0js2_vwmoew_9oVQ_diRmh_KS1zsTnGsRD3s=.29f4ac8c-8581-4f30-b5c8-87fa69c85a02@github.com>

On Wed, 2 Apr 2025 17:05:58 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR fixes an issue when dragEvents occur in a secondary screen which doesn't have the same height or (macOS) origin as the main screen.
> 
> The calculations for `xAbs, yAbs` are defined from the main screen macOS absolute origin, an in order to flip the coordinates defined from the JavaFX origin, the height from the main screen should be used, and not the height from secondary screens, which was the case in `GlassViewDelegate::sendJavaDndEvent`.
> 
> The PR doesn't include tests because it needs a complex setup (two monitors), but the change has been tested on macOS 15.3.2 with the test case from https://bugs.openjdk.org/browse/JDK-8353548, using two monitors (built-in Retina and external 4K display), rearranging their layout (left-bottom-right from main screen), and relative resolution.

This pull request has now been integrated.

Changeset: 9ab20363
Author:    Jose Pereda <jpereda at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/9ab20363e334541a2c82a573d35603c2a2945f03
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8353548: [macOS] DragEvent.getScreenY() returns incorrect value in secondary monitor

Reviewed-by: angorya, arapte

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

PR: https://git.openjdk.org/jfx/pull/1756

From crschnick at xpipe.io  Thu Apr  3 15:08:51 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Thu, 3 Apr 2025 17:08:51 +0200
Subject: Feature Request: Support for Transparent Title Bars in JavaFX
 Stages
In-Reply-To: <96527358-3EA3-40DE-8992-658AF141C42E@gmail.com>
References: <96527358-3EA3-40DE-8992-658AF141C42E@gmail.com>
Message-ID: <03e3f13b-33b2-4f73-bdc7-b560e873857c@xpipe.io>

I just want to add that the native window handles are available prior to 
the windows being shown if you listen to the observable list 
Window.getWindows().

On 02/04/2025 16:01, Bahaa Zaid wrote:
> Hello,
>
> Modern macOS apps tend to expand the client area of the window to take 
> the entire window area including the titlebar. This is usually done by:
>
>  1. Setting NSWindow.titlebarAppearsTransparent to true.
>  2. Setting NSWindow.styleMask NSWindowStyleMaskFullSizeContentView flag.
>
>
> This can be useful because it gives the app modern look, make use of 
> all available window real-estate, and allows JavaFX developers to 
> create completely custom windows like UNDECORATED styles without 
> loosing the platform resize-window feature and the three window buttons.
>
> Swing supports this already using code like this:
> final var frame = new JFrame();
> final var rootPane = frame.getRootPane();
> rootPane.putClientProperty("apple.awt.fullWindowContent", true);
> rootPane.putClientProperty("apple.awt.transparentTitleBar", true);
>
> This can be done easily today using reflection to access non-public 
> API to get the Stage native NSWindow handle and using FFM to change 
> styleMask and set the titlebarAppearsTransparent property. I have 
> created an example here 
> (https://github.com/bahaa/jfx-transparent-window-titlebar). But this 
> approach has the following drawbacks:
>
>   * It uses non-public API.
>   * JavaFX stage native window handle is available only after the
>     stage is shown, this cause some flicker because the window style
>     is changed after it?s shown to the user.
>
>
> I think JavaFX should support this out of the box. One possible 
> solution is to introduce a new StageStyle that behaves like UNIFIED 
> style (it falls back to DECORATED) if it?s not supported by the 
> platform. I think something similar can be done on Windows 
> (https://learn.microsoft.com/en-us/windows/win32/dwm/customframe) but 
> I?m not sure about GTK.
>
> Thanks,
> Bahaa.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250403/7bfae024/attachment.htm>

From angorya at openjdk.org  Thu Apr  3 15:18:58 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 3 Apr 2025 15:18:58 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
In-Reply-To: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
Message-ID: <fZVSpB2gDPzz0IXw2zsWNnlwKiJiitb0o0Cx_tuV8lo=.3707e656-8162-412b-8dde-75571361f32e@github.com>

On Thu, 3 Apr 2025 12:34:37 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.

First batch of comments (up until `ObservableArrayTest`) - the general direction is good, but I would suggest to re-work the set up in all the parameterized tests, mainly for simplicity and consistency.

modules/javafx.base/src/test/java/test/com/sun/javafx/binding/BidirectionalBindingTest.java line 73:

> 71:     private T[] v;
> 72: 
> 73:     public void BidirectionalBindingTest_(Factory<T> factory) {

general comment:
1. the factory (or any other parameterized argument or arguments) should be passed to setUp() in each parameterized test
2. the setUp() should be made private (unless it's overriden by the child class)
3. what used to be the constructor should be removed

modules/javafx.base/src/test/java/test/com/sun/javafx/binding/BidirectionalBindingTest.java line 77:

> 75:     }
> 76: 
> 77:     //@BeforeEach

this comment can be removed

modules/javafx.base/src/test/java/test/com/sun/javafx/binding/BidirectionalBindingWithConversionTest.java line 68:

> 66:     private PropertyMock<T> op1;
> 67: 
> 68:     public void BidirectionalBindingWithConversionTest_(Functions<S, T> func, S[] v0, T[] v1) {

same thing, rename this method to setup() or something like that and make it private

modules/javafx.base/src/test/java/test/com/sun/javafx/event/EventDispatchChainTest.java line 51:

> 49:                 Arguments.of(EventDispatchChainImpl.class),
> 50:                 Arguments.of(EventDispatchTreeImpl.class)
> 51:         );

even though the return value is ok (`Stream<Arguments>`) the parameter supplier method can simply return a List of `Class<? extends EventDispatchChain>` - the framework is smart enough to figure it out.

this is just FYI, no need to make the change.

modules/javafx.base/src/test/java/test/javafx/beans/property/adapter/JavaBeanPropertyTestBase.java line 54:

> 52:     protected abstract JavaBeanProperty<T> extractProperty(Object bean) throws NoSuchMethodException;
> 53: 
> 54:     @BeforeEach

private?

modules/javafx.base/src/test/java/test/javafx/beans/property/adapter/JavaBeanPropertyTestBase.java line 68:

> 66:         assertThrows(NullPointerException.class, () -> {
> 67:             this.property = extractProperty(null);
> 68:         });

my first though about this was - what about `NoSuchMethodException`?
then I realized that in this case the test will fail, and it will similarly fail if any other exception gets thrown.
all good.

modules/javafx.base/src/test/java/test/javafx/binding/BindingsCreateBindingTest.java line 75:

> 73:     }
> 74: 
> 75:     public void BindingsCreateBindingTest_(Property<T> p0, Property<T> p1, Functions<T> f, T value0, T value1, T defaultValue) {

it's better to rename the method to something like `setup()` and make it `private`.

modules/javafx.base/src/test/java/test/javafx/binding/BindingsEqualsTest.java line 75:

> 73:     private InvalidationListenerMock observer;
> 74: 
> 75:     public void BindingsEqualsTest_(ObservableValue op1, ObservableValue op2, Functions<T> func, T... v) {

move the functionality to `setUp()`

modules/javafx.base/src/test/java/test/javafx/binding/BindingsNumberCalculationsTest.java line 71:

> 69:     private InvalidationListenerMock observer;
> 70: 
> 71:     public void BindingsNumberCalculationsTest_(ObservableValue op1, ObservableValue op2, Functions<T> func, T[] v) {

move the functionality to `private setup(...)`?

modules/javafx.base/src/test/java/test/javafx/binding/BindingsNumberCastTest.java line 79:

> 77:     private IntegerProperty integer1;
> 78: 
> 79:     @BeforeEach

private?

modules/javafx.base/src/test/java/test/javafx/binding/GenericBindingTest.java line 66:

> 64:     private ChangeListenerMock<Object> changeListener;
> 65: 
> 66:     public void GenericBindingTest_(

move the functionality to `private setUp()`?

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

PR Review: https://git.openjdk.org/jfx/pull/1759#pullrequestreview-2740196090
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2027184146
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2027184640
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2027187159
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2027191526
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2027199933
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2027207548
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2027209316
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2027211638
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2027215741
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2027225296
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2027232870

From angorya at openjdk.org  Thu Apr  3 15:32:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 3 Apr 2025 15:32:03 GMT
Subject: RFR: 8353617: Remove deprecated TransitionEvent constructor
In-Reply-To: <7nUoQ15p5_0UbIAu4LF1zhu3EJiNeMbDIGKQyvwD2Bk=.af1d3026-dd66-403d-a65c-a9401da0d56f@github.com>
References: <7nUoQ15p5_0UbIAu4LF1zhu3EJiNeMbDIGKQyvwD2Bk=.af1d3026-dd66-403d-a65c-a9401da0d56f@github.com>
Message-ID: <DqGInGTkJnSwyKwgMgvA-djxtE753almBcRaJ-YVZF0=.51db175b-2249-47b8-86ad-e8735c1bde24@github.com>

On Thu, 3 Apr 2025 08:47:51 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Remove the deprecated `TransitionEvent(EventType, StyleableProperty, Duration)` constructor.
> 
> A single reviewer should be sufficient.

it's a "virtual particle": briefly came into existence then disappeared, contributing to mass when it existed.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1758#pullrequestreview-2740329322

From andy.goryachev at oracle.com  Thu Apr  3 15:31:34 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 3 Apr 2025 15:31:34 +0000
Subject: JavaFX slides from JavaOne 2025
In-Reply-To: <097511ee-7b76-4729-b783-32dea2714df0@oracle.com>
References: <097511ee-7b76-4729-b783-32dea2714df0@oracle.com>
Message-ID: <BYAPR10MB3013C2FA8D0D0B09D177459AE5AE2@BYAPR10MB3013.namprd10.prod.outlook.com>

Thank you!  Please let us know when the video of your talk becomes available.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Date: Thursday, April 3, 2025 at 07:45
To: openjfx-dev <openjfx-dev at openjdk.org>
Subject: JavaFX slides from JavaOne 2025
In case anyone is interested, here is the slide deck I presented at
JavaOne 2025 for the "JavaFX 24 and Beyond" session.

https://cr.openjdk.org/~kcr/presentations/javaone-2025/JavaFX-24-Final.pdf

-- Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250403/7bb9536c/attachment.htm>

From bahaazaid at gmail.com  Thu Apr  3 16:01:23 2025
From: bahaazaid at gmail.com (Bahaa Zaid)
Date: Thu, 3 Apr 2025 18:01:23 +0200
Subject: Feature Request: Support for Transparent Title Bars in JavaFX
 Stages
In-Reply-To: <CAJEpuXSdBbSydpZ-sFbTVWieEPSyYxFb3ZYidEvR78NaTBTv1g@mail.gmail.com>
References: <96527358-3EA3-40DE-8992-658AF141C42E@gmail.com>
 <CAJEpuXSdBbSydpZ-sFbTVWieEPSyYxFb3ZYidEvR78NaTBTv1g@mail.gmail.com>
Message-ID: <CFF61411-5F71-40EE-842F-7674280CBFCF@gmail.com>

That?s great. Thank you much.

> On 3 Apr 2025, at 4:59?PM, Michael Strau? <michaelstrau2 at gmail.com> wrote:
> 
> Already under way: https://github.com/openjdk/jfx/pull/1605


From mstrauss at openjdk.org  Thu Apr  3 17:32:59 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 3 Apr 2025 17:32:59 GMT
Subject: Integrated: 8353617: Remove deprecated TransitionEvent constructor
In-Reply-To: <7nUoQ15p5_0UbIAu4LF1zhu3EJiNeMbDIGKQyvwD2Bk=.af1d3026-dd66-403d-a65c-a9401da0d56f@github.com>
References: <7nUoQ15p5_0UbIAu4LF1zhu3EJiNeMbDIGKQyvwD2Bk=.af1d3026-dd66-403d-a65c-a9401da0d56f@github.com>
Message-ID: <pbHxeyJ7WzT0jmxejkMo-NjFKn5BquO8md5yShkfXwg=.9de2d43f-ed75-45d3-8495-3aa10af0971f@github.com>

On Thu, 3 Apr 2025 08:47:51 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Remove the deprecated `TransitionEvent(EventType, StyleableProperty, Duration)` constructor.
> 
> A single reviewer should be sufficient.

This pull request has now been integrated.

Changeset: 1a65f4c3
Author:    Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/1a65f4c3c3060a5ddcaa513e9849d86596fd15e3
Stats:     17 lines in 1 file changed: 0 ins; 16 del; 1 mod

8353617: Remove deprecated TransitionEvent constructor

Reviewed-by: jhendrikx, kcr, angorya

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

PR: https://git.openjdk.org/jfx/pull/1758

From jdv at openjdk.org  Thu Apr  3 18:10:23 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 3 Apr 2025 18:10:23 GMT
Subject: RFR: 8353620: Make some systems tests robust for Ubuntu 24.04
Message-ID: <HOdSrr9Hgk7PYR9EC84f-zEyCFwmZKYP204W7Ef4um8=.1f628171-e3e7-46ba-910a-cdade1ae0cf9@github.com>

Under https://bugs.openjdk.org/browse/JDK-8339679 task, we are running full tests and identifying issues for Ubuntu 24.04.

As part of above task it is identified that there are 3 tests which fail intermittently and we need to add appropriate delays to make them more robust. Delays are added between UI launch and processing of UI events, with this change intermittent failures are not seen.

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

Commit messages:
 - 8353620: Make some systems tests robust for Ubuntu 24.04

Changes: https://git.openjdk.org/jfx/pull/1761/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1761&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353620
  Stats: 5 lines in 3 files changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1761.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1761/head:pull/1761

PR: https://git.openjdk.org/jfx/pull/1761

From kcr at openjdk.org  Thu Apr  3 18:19:51 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 3 Apr 2025 18:19:51 GMT
Subject: RFR: 8353620: Make some systems tests robust for Ubuntu 24.04
In-Reply-To: <HOdSrr9Hgk7PYR9EC84f-zEyCFwmZKYP204W7Ef4um8=.1f628171-e3e7-46ba-910a-cdade1ae0cf9@github.com>
References: <HOdSrr9Hgk7PYR9EC84f-zEyCFwmZKYP204W7Ef4um8=.1f628171-e3e7-46ba-910a-cdade1ae0cf9@github.com>
Message-ID: <a0Bfn8ONWw4SYc2hLy2X4LY65OQGa3qjT6I_p2OdvXo=.e36e9441-8b09-4d17-88fc-a178357f16db@github.com>

On Thu, 3 Apr 2025 18:05:54 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Under https://bugs.openjdk.org/browse/JDK-8339679 task, we are running full tests and identifying issues for Ubuntu 24.04.
> 
> As part of above task it is identified that there are 3 tests which fail intermittently and we need to add appropriate delays to make them more robust. Delays are added between UI launch and processing of UI events, with this change intermittent failures are not seen.

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1761#pullrequestreview-2740768516

From jdv at openjdk.org  Thu Apr  3 18:24:53 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 3 Apr 2025 18:24:53 GMT
Subject: Integrated: 8353620: Make some systems tests robust for Ubuntu 24.04
In-Reply-To: <HOdSrr9Hgk7PYR9EC84f-zEyCFwmZKYP204W7Ef4um8=.1f628171-e3e7-46ba-910a-cdade1ae0cf9@github.com>
References: <HOdSrr9Hgk7PYR9EC84f-zEyCFwmZKYP204W7Ef4um8=.1f628171-e3e7-46ba-910a-cdade1ae0cf9@github.com>
Message-ID: <q1YHkWq44nVBboHyEjL_tmegCtlqP2qSBYXSbxltOMU=.d414e42b-cbc7-4e1e-8105-e095d9e3e46b@github.com>

On Thu, 3 Apr 2025 18:05:54 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Under https://bugs.openjdk.org/browse/JDK-8339679 task, we are running full tests and identifying issues for Ubuntu 24.04.
> 
> As part of above task it is identified that there are 3 tests which fail intermittently and we need to add appropriate delays to make them more robust. Delays are added between UI launch and processing of UI events, with this change intermittent failures are not seen.

This pull request has now been integrated.

Changeset: 62f94bb0
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/62f94bb0be7f1618271672f417225e12b4d30ff8
Stats:     5 lines in 3 files changed: 3 ins; 0 del; 2 mod

8353620: Make some systems tests robust for Ubuntu 24.04

Reviewed-by: kcr

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

PR: https://git.openjdk.org/jfx/pull/1761

From angorya at openjdk.org  Thu Apr  3 18:42:15 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 3 Apr 2025 18:42:15 GMT
Subject: RFR: 8353668: Rename internal c.s.javafx.text.TextLine class
Message-ID: <sV5TXJiKPOmJuNG3vjMHR8eGnEAeg-gY-5rr9gRPx6g=.215cc532-e023-46ec-acbc-ec0eea5102e9@github.com>

This minor change renames an internal `com.sun.javafx.text.TextLine` to `PrismTextLine`.
This class implements `com.sun.javafx.scene.text.TextLine` interface, also internal, for the purpose of reducing confusion and avoiding FQCN.

This change is completely transparent to the application developers since no public APIs is impacted.

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

Commit messages:
 - cleanup
 - prism text line

Changes: https://git.openjdk.org/jfx/pull/1760/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1760&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353668
  Stats: 211 lines in 4 files changed: 96 ins; 96 del; 19 mod
  Patch: https://git.openjdk.org/jfx/pull/1760.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1760/head:pull/1760

PR: https://git.openjdk.org/jfx/pull/1760

From thiago.sayao at gmail.com  Thu Apr  3 18:48:49 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Thu, 3 Apr 2025 15:48:49 -0300
Subject: Behavior when resizing a window programmatically while it is
 fullscreen or maximized
Message-ID: <CAAP_wunQeiieYN6PQ67YNDHaWqoNBgRHhi37DzP7F7vGoD72Ug@mail.gmail.com>

Hi,

JavaFX allows setting the stage's width, height, and position (X, Y) when
it is maximized or in fullscreen mode, without ignoring the values or
throwing an exception.

The current documentation states the following regarding X, Y, Width,
Height, and sizeToScene:

Changing this attribute will not visually affect a Stage while fullScreen is
true, but will be honored by the Stage once fullScreen becomes false. This
value includes any and all decorations which may be added by the Operating
System such as resizable frame handles. Typical applications will set the
Scene <https://docs.oracle.com/javase/8/javafx/api/javafx/scene/Scene.html>
width
instead.
It doesn?t mention anything about the maximized state, which I believe is a
similar case.

Martin did some tests on Mac and Windows when resizing while Maximized, and
it seems inconsistent between platforms.

https://github.com/openjdk/jfx/pull/1748#issuecomment-2764224914

On Linux, when setting the width or height while in fullscreen mode, GTK
simply ignores the request and maintains the size the window had before
entering fullscreen.
I tried to work around this to align with the documentation, but it?s
harder than it looks due to the asynchronous nature of X11.

Depending on how different platforms behave, it might be worth revisiting
the documentation and aligning behaviors where possible to ensure
consistency.

-- Thiago.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250403/a00c12fd/attachment-0001.htm>

From mstrauss at openjdk.org  Thu Apr  3 19:08:44 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 3 Apr 2025 19:08:44 GMT
Subject: RFR: 8345348: CSS Media Queries [v2]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <OnA67ZLodtm18r1I3NrBvHvIU3mKCd3VvS7eRp5ztbs=.95039c8c-1a5c-427b-950b-009e4fec10cf@github.com>

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - revert
 - remove SceneMediaQueryContext
 - adjust copyright year
 - Merge branch 'master' into feature/media-queries
   
   # Conflicts:
   #	modules/javafx.graphics/src/main/java/com/sun/javafx/scene/SceneHelper.java
   #	modules/javafx.graphics/src/main/java/javafx/scene/Scene.java
   #	modules/javafx.graphics/src/test/java/test/javafx/css/StylesheetTest.java
 - Add persistentScrollBars media feature
 - Merge branch 'master' into feature/media-queries
   
   # Conflicts:
   #	modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java
 - Merge branch 'master' into feature/media-queries
 - Implementation of media queries

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

Changes: https://git.openjdk.org/jfx/pull/1655/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=01
  Stats: 4537 lines in 35 files changed: 3436 ins; 1026 del; 75 mod
  Patch: https://git.openjdk.org/jfx/pull/1655.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655

PR: https://git.openjdk.org/jfx/pull/1655

From mstrauss at openjdk.org  Thu Apr  3 19:08:45 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 3 Apr 2025 19:08:45 GMT
Subject: RFR: 8345348: CSS Media Queries
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <T1sd7E-Rs4fbVoDYyf3CJLCfAzfZ8cS-YXO8fIAsP-k=.645e3281-6289-4abd-a3fa-3b0dd5083231@github.com>

On Mon, 2 Dec 2024 16:19:46 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

Let's try this again.

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

PR Comment: https://git.openjdk.org/jfx/pull/1655#issuecomment-2776685622

From mstrauss at openjdk.org  Thu Apr  3 19:41:58 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 3 Apr 2025 19:41:58 GMT
Subject: RFR: 8353668: Rename internal c.s.javafx.text.TextLine class
In-Reply-To: <sV5TXJiKPOmJuNG3vjMHR8eGnEAeg-gY-5rr9gRPx6g=.215cc532-e023-46ec-acbc-ec0eea5102e9@github.com>
References: <sV5TXJiKPOmJuNG3vjMHR8eGnEAeg-gY-5rr9gRPx6g=.215cc532-e023-46ec-acbc-ec0eea5102e9@github.com>
Message-ID: <VnmQgOXqI4eOTQlw3RKNJT6fDiXw-gUjtC-aNtrvY4M=.578867ed-28e7-439f-a0af-75b1a4108868@github.com>

On Thu, 3 Apr 2025 18:01:07 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> This minor change renames an internal `com.sun.javafx.text.TextLine` to `PrismTextLine`.
> This class implements `com.sun.javafx.scene.text.TextLine` interface, also internal, for the purpose of reducing confusion and avoiding FQCN.
> 
> This change is completely transparent to the application developers since no public APIs is impacted.

Marked as reviewed by mstrauss (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1760#pullrequestreview-2740959594

From angorya at openjdk.org  Thu Apr  3 19:44:52 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 3 Apr 2025 19:44:52 GMT
Subject: RFR: 8353668: Rename internal c.s.javafx.text.TextLine class
In-Reply-To: <VnmQgOXqI4eOTQlw3RKNJT6fDiXw-gUjtC-aNtrvY4M=.578867ed-28e7-439f-a0af-75b1a4108868@github.com>
References: <sV5TXJiKPOmJuNG3vjMHR8eGnEAeg-gY-5rr9gRPx6g=.215cc532-e023-46ec-acbc-ec0eea5102e9@github.com>
 <VnmQgOXqI4eOTQlw3RKNJT6fDiXw-gUjtC-aNtrvY4M=.578867ed-28e7-439f-a0af-75b1a4108868@github.com>
Message-ID: <GqoMpv5SPP1E46WnmvcFCv-G8sIDjkQgnxG6Wn-Jh6s=.15bb7be7-9354-414e-a7ee-ad7070c5e41e@github.com>

On Thu, 3 Apr 2025 19:39:35 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This minor change renames an internal `com.sun.javafx.text.TextLine` to `PrismTextLine`.
>> This class implements `com.sun.javafx.scene.text.TextLine` interface, also internal, for the purpose of reducing confusion and avoiding FQCN.
>> 
>> This change is completely transparent to the application developers since no public APIs is impacted.
>
> Marked as reviewed by mstrauss (Reviewer).

thank you @mstr2 !

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

PR Comment: https://git.openjdk.org/jfx/pull/1760#issuecomment-2776760329

From kcr at openjdk.org  Thu Apr  3 20:48:54 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 3 Apr 2025 20:48:54 GMT
Subject: RFR: 8351878: RichTextArea: copy/paste issues [v5]
In-Reply-To: <rs-4MqFkEhQm4iyoaZ4u8Ru61Da5gKYfNaUn18ON2L0=.e2d34b26-392f-411b-aaa0-6d6e5dcb8da6@github.com>
References: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
 <rs-4MqFkEhQm4iyoaZ4u8Ru61Da5gKYfNaUn18ON2L0=.e2d34b26-392f-411b-aaa0-6d6e5dcb8da6@github.com>
Message-ID: <oXAmKdWHDNPpkF5LjSQBoPQKmf4zXBBq-fpW7dACw-4=.148e1cf8-f5a7-48c8-b0c2-8de4db95cfac@github.com>

On Wed, 26 Mar 2025 14:36:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Fixed several issues found in importing RTF text:
>> 
>> - charset translation (brought back removed code)
>> - missing font size attribute
>> - missing strike-through attribute
>> 
>> Also, HTML copy suffered from the following issues:
>> 
>> - incorrect font size
>> - incorrect handling of boolean character attributes (bold, italic, etc.)
>> 
>> The charset issue was caused by my removal of the character decoder code present in the original JDK RTF parser/reader.  Why did I do that?
>> 
>> This PR does not add import of RTL paragraph attribute needed to align RTL text correctly.
>
> Andy Goryachev 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 10 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8351878.rtf
>  - html
>  - Merge remote-tracking branch 'origin/master' into 8351878.rtf
>  - arabic
>  - whitespace
>  - test
>  - strikethrough
>  - missing code in attr set
>  - font size
>  - fixed arabic import

Reviewers: @lukostyra @Ziad-Mid

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

PR Comment: https://git.openjdk.org/jfx/pull/1735#issuecomment-2776880320

From kcr at openjdk.org  Thu Apr  3 20:50:53 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 3 Apr 2025 20:50:53 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <XPdttsrpzcsHIeQOiL9zXvLrupGgFc2fnEd7Y4O9qec=.1b9cddf0-8b48-4704-8ae9-e600ae04a631@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
 <XPdttsrpzcsHIeQOiL9zXvLrupGgFc2fnEd7Y4O9qec=.1b9cddf0-8b48-4704-8ae9-e600ae04a631@github.com>
Message-ID: <65fp50EY6JIOJIi49gbdUoy3Kb0eoGu9s58TaTYs5xc=.3be0bcc6-6bf4-4333-b1f7-b10a736c6161@github.com>

On Tue, 18 Mar 2025 15:01:46 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Adds code to trigger a scene update when a Window is restored
>> 
>> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479
>
> This does fix the issue on windows.
> The issue on mac seems intermittent even without this change, and stays intermittent with this change.
> 
> The change seems to achieve the intended but the trigger check may not be the best way. `updateSceneState` is used when there are any changes with scene properties.
> The redraw should be triggered by checking the change in scene graph. This change just triggers irrespective of that.

Reviewers: @arapte @lukostyra

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

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2776884766

From credmond at certak.com  Thu Apr  3 23:58:40 2025
From: credmond at certak.com (Cormac Redmond)
Date: Fri, 4 Apr 2025 00:58:40 +0100
Subject: Feature Request: Support for Transparent Title Bars in JavaFX
 Stages
In-Reply-To: <CFF61411-5F71-40EE-842F-7674280CBFCF@gmail.com>
References: <96527358-3EA3-40DE-8992-658AF141C42E@gmail.com>
 <CAJEpuXSdBbSydpZ-sFbTVWieEPSyYxFb3ZYidEvR78NaTBTv1g@mail.gmail.com>
 <CFF61411-5F71-40EE-842F-7674280CBFCF@gmail.com>
Message-ID: <CAG_-AaA7i7bS96kV3q3mpVUD-uNJ3EddAgVGJQxNG08J_7d9Ow@mail.gmail.com>

Would really love to see https://github.com/openjdk/jfx/pull/1605 as a
preview in JFX 25.


Kind Regards,
Cormac

On Thu, 3 Apr 2025 at 17:01, Bahaa Zaid <bahaazaid at gmail.com> wrote:

> That?s great. Thank you much.
>
> > On 3 Apr 2025, at 4:59?PM, Michael Strau? <michaelstrau2 at gmail.com>
> wrote:
> >
> > Already under way: https://github.com/openjdk/jfx/pull/1605
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250404/9edb3178/attachment.htm>

From arapte at openjdk.org  Fri Apr  4 01:33:58 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 4 Apr 2025 01:33:58 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
In-Reply-To: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
Message-ID: <gv_J8UGBupmHykK1lkiJWlx7zdB7aJ_p871N1xxgHVQ=.b74a3a1a-ff3c-47f3-86c7-bf8f3a3fc685@github.com>

On Thu, 3 Apr 2025 12:34:37 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.

Providing a few minor comments.

modules/javafx.base/src/test/java/test/com/sun/javafx/binding/BidirectionalBindingTest.java line 73:

> 71:     private T[] v;
> 72: 
> 73:     public void BidirectionalBindingTest_(Factory<T> factory) {

may be change method name to `setFactory`.

modules/javafx.base/src/test/java/test/com/sun/javafx/property/adapter/PropertyDescriptorTest.java line 25:

> 23:  * questions.
> 24:  */
> 25: //test is disabled already

No other change in the file apart from this comment, should be reverted.

modules/javafx.base/src/test/java/test/com/sun/javafx/property/adapter/ReadOnlyPropertyDescriptorTest.java line 25:

> 23:  * questions.
> 24:  */
> 25: //test is disabled already

No other change in the file apart from this comment, should be reverted.

modules/javafx.base/src/test/java/test/javafx/util/converter/LocalDateTimeStringConverterTest.java line 28:

> 26: package test.javafx.util.converter;
> 27: 
> 28: // Imports remain the same, except JUnit 4 imports are replaced with JUnit 5

Comment not required, should revert.

modules/javafx.base/src/test/java/test/javafx/util/converter/LocalDateTimeStringConverterTest.java line 53:

> 51: public class LocalDateTimeStringConverterTest {
> 52: 
> 53:     // Constants and enums remain the same

Comment not required, should revert.

modules/javafx.base/src/test/java/test/javafx/util/converter/LocalDateTimeStringConverterTest.java line 122:

> 120:         if (version.major() < 20) {
> 121:             // TODO: This can be removed when the minimum version of boot jdk
> 122:             // for JFX build is updated to JDK20 or above.

The comments removed from this method, should be retained.

modules/javafx.base/src/test/java/test/javafx/util/converter/LocalDateTimeStringConverterTest.java line 131:

> 129:     @AfterClass
> 130:     public static void teardownAfterAll() {
> 131:         // Restore VM's old locale

The comments removed from this method, should be retained.

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

PR Review: https://git.openjdk.org/jfx/pull/1759#pullrequestreview-2739878525
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2027061383
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2027016199
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2027016487
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2027038675
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2027040164
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2027044122
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2027044519

From jhendrikx at openjdk.org  Fri Apr  4 03:29:59 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 4 Apr 2025 03:29:59 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
Message-ID: <nKU3xa7BPWcbVPS5Z3WIrGb_C05GNeH90CA-8-us93Y=.7605d916-be0a-452b-bd30-b260671f9d44@github.com>

On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Adds code to trigger a scene update when a Window is restored
> 
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479

This doesn't look like an easy fix; although it fixes the issue for me on Windows, I don't have access to a Mac to fix the problem on that platform as well.  Perhaps someone else wants to take a look at this issue.

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

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2777473918

From jbhaskar at openjdk.org  Fri Apr  4 03:36:16 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Fri, 4 Apr 2025 03:36:16 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
 [v2]
In-Reply-To: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
Message-ID: <RDqvu2FhtuCEdQPG6PCYYPwyfEb6XgzRvIFFB3uQEac=.7128742c-bf76-41de-9a74-aaf8021360f4@github.com>

> Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.

Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:

  simplify test setup according to review

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1759/files
  - new: https://git.openjdk.org/jfx/pull/1759/files/da453771..cf46ee09

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1759&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1759&range=00-01

  Stats: 980 lines in 18 files changed: 12 ins; 506 del; 462 mod
  Patch: https://git.openjdk.org/jfx/pull/1759.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1759/head:pull/1759

PR: https://git.openjdk.org/jfx/pull/1759

From jbhaskar at openjdk.org  Fri Apr  4 03:43:32 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Fri, 4 Apr 2025 03:43:32 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
 [v3]
In-Reply-To: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
Message-ID: <GO3omZcIytN5DpSc-zfdlkfRYr8NeSVEep2khEWvpGs=.c1801409-68d7-431a-a95f-5c6315bc8b6e@github.com>

> Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.

Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:

  missing review change and remove trailing white space

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1759/files
  - new: https://git.openjdk.org/jfx/pull/1759/files/cf46ee09..5f79e450

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1759&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1759&range=01-02

  Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1759.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1759/head:pull/1759

PR: https://git.openjdk.org/jfx/pull/1759

From jbhaskar at openjdk.org  Fri Apr  4 04:22:36 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Fri, 4 Apr 2025 04:22:36 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
 [v4]
In-Reply-To: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
Message-ID: <Lwhx0VP2Zo5a411T7HhjbqHu07r8H4Qzao-PeOkiB5Y=.1fee706a-87ae-4e5f-8480-fea620349d03@github.com>

> Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.

Jay Bhaskar 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 five additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into juni5bastest
 - missing review change and remove trailing white space
 - simplify test setup according to review
 - remove trailing white space
 - 8340464: [TestBug] Convert parametrized base tests to JUnit 5

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1759/files
  - new: https://git.openjdk.org/jfx/pull/1759/files/5f79e450..03e9dd52

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1759&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1759&range=02-03

  Stats: 509 lines in 23 files changed: 331 ins; 129 del; 49 mod
  Patch: https://git.openjdk.org/jfx/pull/1759.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1759/head:pull/1759

PR: https://git.openjdk.org/jfx/pull/1759

From jbhaskar at openjdk.org  Fri Apr  4 06:08:28 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Fri, 4 Apr 2025 06:08:28 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
 [v5]
In-Reply-To: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
Message-ID: <zmcMPx3_xbFTT8bfcswV1I_RqIklLepFO32lQJfOCiE=.0a5e39b0-42bc-4f5f-a980-5271412f42f7@github.com>

> Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.

Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:

  re-order imports

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1759/files
  - new: https://git.openjdk.org/jfx/pull/1759/files/03e9dd52..76686013

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1759&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1759&range=03-04

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1759.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1759/head:pull/1759

PR: https://git.openjdk.org/jfx/pull/1759

From jdv at openjdk.org  Fri Apr  4 10:20:42 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 4 Apr 2025 10:20:42 GMT
Subject: RFR: 8353557: Skip some system tests on Linux
Message-ID: <Nkf2BWQcSqOJafYyo9mSVlsFZWYP2k0g2sg83B0CTaA=.f80c78a4-fb9b-47fe-ab93-6d4d36348f2b@github.com>

Under https://bugs.openjdk.org/browse/JDK-8339679 task, we are running full tests and identifying issues for Ubuntu 24.04.

As part of above task 6 test failures were identified and looks like these test failures are happening because of product issues in Ubuntu24.04.

Test failures are:
1) RestoreSceneSizeTest and its product issue : [JDK-8353556](https://bugs.openjdk.org/browse/JDK-8353556)
2) PageFillTest  and its product issue : [JDK-8353561](https://bugs.openjdk.org/browse/JDK-8353561)
3) SizeToSceneTest and its product issue : [JDK-8353612](https://bugs.openjdk.org/browse/JDK-8353612)
4) WrongStageFocusWithApplicationModalityTest fails intermittently only in Wayland and its product issue : [JDK-8353643](https://bugs.openjdk.org/browse/JDK-8353643)
5) InitializeJavaFXLaunch1Test & InitializeJavaFXLaunch2Test fails intermittently only in Xorg and its product issue : [JDK-8353644](https://bugs.openjdk.org/browse/JDK-8353644)

As part of test stabilization task these identified test failures will be skipped and we have product issues raised for them.

I tried finding ways to add utility to skip tests only in Ubuntu 24.04. System.Properties doesn't list any item which can be used to identified a specific Linux distro or Ubuntu version. If we need to identify Ubuntu and its version we need to use executable like `lsb_release`. 

So test which are failing in both Wayland & Xorg are skipped for Linux platform and if they fail with specific windowing system(Wayland/Xorg) they are skipped only under them.

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

Commit messages:
 - 8353557: Skip some system tests on Linux

Changes: https://git.openjdk.org/jfx/pull/1762/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1762&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353557
  Stats: 34 lines in 6 files changed: 27 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jfx/pull/1762.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1762/head:pull/1762

PR: https://git.openjdk.org/jfx/pull/1762

From mstrauss at openjdk.org  Fri Apr  4 10:46:38 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 4 Apr 2025 10:46:38 GMT
Subject: RFR: 8345348: CSS Media Queries [v3]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <RO0p3k43RmBhvJjXMb1VvzxXWCsPy-_z05htkaeYLk0=.a9a8ed36-d6fd-4265-b6c8-465ed7e69b47@github.com>

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:

 - revert import
 - move scene preferences to Scene.Preferences interface

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/f6875179..efd176d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=01-02

  Stats: 685 lines in 6 files changed: 440 ins; 211 del; 34 mod
  Patch: https://git.openjdk.org/jfx/pull/1655.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655

PR: https://git.openjdk.org/jfx/pull/1655

From mstrauss at openjdk.org  Fri Apr  4 10:58:19 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 4 Apr 2025 10:58:19 GMT
Subject: RFR: 8345348: CSS Media Queries [v4]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <zWQAHSR5p3GV5y582wmhUrnxcX204mlp98BWqEpjTdw=.5b284123-8a7c-4627-843b-5b7076a5a555@github.com>

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  add missing javadoc tag

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/efd176d8..31397970

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=02-03

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1655.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655

PR: https://git.openjdk.org/jfx/pull/1655

From mstrauss at openjdk.org  Fri Apr  4 11:13:43 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 4 Apr 2025 11:13:43 GMT
Subject: RFR: 8345348: CSS Media Queries [v5]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <uhKMuAnGVXWMarZcIFh32kY-2LIbwhbr3sc-pVw7Mg4=.ca9985e3-187b-49e6-94a2-0d4f63bee84e@github.com>

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  add documentation

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/31397970..49831689

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=03-04

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1655.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655

PR: https://git.openjdk.org/jfx/pull/1655

From lkostyra at openjdk.org  Fri Apr  4 11:34:10 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 4 Apr 2025 11:34:10 GMT
Subject: RFR: 8234153: [TEST_BUG] Rewrite Popup_parentWindow_Test
Message-ID: <7bf72skQqQkaixdRyiilnIW35lkXC_X3GzbSNt9ot0U=.256071a4-e230-4e5e-9e97-aad6f614e01b@github.com>

This change rewrites `Popup_parentWindow_Test` after a-long-time-ago-done changes to Popup public API.

Popup used to have an `owner` and `parentWindow` properties. I couldn't track how far back that change happened so I can't fully say what these Properties actually were, but to my knowledge both properties were replaced by `ownerNode` and `ownerWindow` Properties respectively. New Properties are read-only and are set while calling respective `Popup.show()` - `Popup.show(Node, ...)` sets both Properties, while `Popup.show(Window, ...)` sets only `ownerWindow` Property.

A lot of original test scenarios were cut out because with current Popup API they make little to no sense. Original `Popup_parentWindow_Test` extended `PropertiesTestBase` and ran the regular Property access checks. Those are parametrized and split into four test methods:
- `testGetBean` - confidence check for whether we can get the Property bean, unnecessary since new tests access the Properties directly
- `testGetName` - Properties in `PropertiesTestBase` are referred to by String-provided name and Reflection, so this was a confidence check whether those Properties actually exist in the object - unnecessary, since we access the Properties directly
- `testBinding` - I deemed those not doable, since the Properties we try to access are read-only and cannot be bound to
- `testBasicAccess` - This is the only test I found that was workable into a reimplementation, and so it is manually reimplemented as `Popup_owner_Test`

Moreover, because of lack of `Popup.setParent()` API I also deemed more complex test scenarios (cases referring to TestScene's `_window` Property) unnecessary. Since there is no `Popup.show(Scene, ...)` those cases were also eliminated. This leaves current test pool into three separate parameters for one, similar test case.

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

Commit messages:
 - Rewrite Popup_parentWindow_Test to Popup_owner_Test

Changes: https://git.openjdk.org/jfx/pull/1763/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1763&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8234153
  Stats: 404 lines in 2 files changed: 261 ins; 143 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1763.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1763/head:pull/1763

PR: https://git.openjdk.org/jfx/pull/1763

From kcr at openjdk.org  Fri Apr  4 11:59:02 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 4 Apr 2025 11:59:02 GMT
Subject: RFR: 8353557: Skip some system tests on Linux
In-Reply-To: <Nkf2BWQcSqOJafYyo9mSVlsFZWYP2k0g2sg83B0CTaA=.f80c78a4-fb9b-47fe-ab93-6d4d36348f2b@github.com>
References: <Nkf2BWQcSqOJafYyo9mSVlsFZWYP2k0g2sg83B0CTaA=.f80c78a4-fb9b-47fe-ab93-6d4d36348f2b@github.com>
Message-ID: <kGoSYDlUYPe_-4WNrdbkPSpI5l8y0Bt_G_rCSziKds0=.8e3cddf6-358e-4703-9911-66f89e4291a5@github.com>

On Fri, 4 Apr 2025 10:16:18 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Under https://bugs.openjdk.org/browse/JDK-8339679 task, we are running full tests and identifying issues for Ubuntu 24.04.
> 
> As part of above task 6 test failures were identified and looks like these test failures are happening because of product issues in Ubuntu24.04.
> 
> Test failures are:
> 1) RestoreSceneSizeTest and its product issue : [JDK-8353556](https://bugs.openjdk.org/browse/JDK-8353556)
> 2) PageFillTest  and its product issue : [JDK-8353561](https://bugs.openjdk.org/browse/JDK-8353561)
> 3) SizeToSceneTest and its product issue : [JDK-8353612](https://bugs.openjdk.org/browse/JDK-8353612)
> 4) WrongStageFocusWithApplicationModalityTest fails intermittently only in Wayland and its product issue : [JDK-8353643](https://bugs.openjdk.org/browse/JDK-8353643)
> 5) InitializeJavaFXLaunch1Test & InitializeJavaFXLaunch2Test fails intermittently only in Xorg and its product issue : [JDK-8353644](https://bugs.openjdk.org/browse/JDK-8353644)
> 
> As part of test stabilization task these identified test failures will be skipped and we have product issues raised for them.
> 
> I tried finding ways to add utility to skip tests only in Ubuntu 24.04. System.Properties doesn't list any item which can be used to identified a specific Linux distro or Ubuntu version. If we need to identify Ubuntu and its version we need to use executable like `lsb_release`. 
> 
> So test which are failing in both Wayland & Xorg are skipped for Linux platform and if they fail with specific windowing system(Wayland/Xorg) they are skipped only under them.

The changes look good. I'll do a quick test as well and then approve. Please make sure you've done a full automated test run before integrating.

> Pre-submit tests - Gradle Wrapper Validation - Build / testFailing after 21s ? 1/1 failed

This looks like an intermittent network issue. Can you rerun the GHA workflow?

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

PR Review: https://git.openjdk.org/jfx/pull/1762#pullrequestreview-2742739609
PR Comment: https://git.openjdk.org/jfx/pull/1762#issuecomment-2778479198

From lkostyra at openjdk.org  Fri Apr  4 12:01:58 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 4 Apr 2025 12:01:58 GMT
Subject: RFR: 8352746: [TestBug] Monkey Tester Application Update 5
In-Reply-To: <actvM3rNHh_Z40XsdTOlze1lNr6sWeH3nXbchpMCiSg=.7945ddac-466c-4fd6-a262-74c0a9a8ef94@github.com>
References: <actvM3rNHh_Z40XsdTOlze1lNr6sWeH3nXbchpMCiSg=.7945ddac-466c-4fd6-a262-74c0a9a8ef94@github.com>
Message-ID: <7eRR50oHhjjsi4WraI8DJgxyiF0Tn-x3Nu-Cczongz0=.73e97fac-ba5b-4ace-95fa-2b90e85fd007@github.com>

On Mon, 31 Mar 2025 23:11:42 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Further additions to the MonkeyTester application:
> 
> - platform preferences monitor
> - improved pages: hbox, vbox
> - improved css playground
> - mouse listener option in some context menus
> - additional choices: background
> - additional properties: Node::clip, Region::shape, TextInputControl::textFormatter
> - font selector in Tools -> JTextArea/JTextField Embedded in SwingNode
> 
> ## New Pages
> - anchor pane
> - border pane
> - button bar
> - flow pane
> - grid pane
> - media player
> - progress indicator
> - separator
> - slider
> - stack pane
> - stage
> - tile pane
> 
> ## Properties Monitor
> 
> ![Screenshot 2025-03-31 at 16 18 17](https://github.com/user-attachments/assets/fa4256ab-c58a-4f93-bee1-a9b5236f64a6)

LGTM.

Since this is a test app, I did only a brief look-through the code, I ran it and played around with new test examples. All seems to run quite well on Windows.

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

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1750#pullrequestreview-2742748176

From lkostyra at openjdk.org  Fri Apr  4 12:47:11 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 4 Apr 2025 12:47:11 GMT
Subject: RFR: 8351878: RichTextArea: copy/paste issues [v5]
In-Reply-To: <rs-4MqFkEhQm4iyoaZ4u8Ru61Da5gKYfNaUn18ON2L0=.e2d34b26-392f-411b-aaa0-6d6e5dcb8da6@github.com>
References: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
 <rs-4MqFkEhQm4iyoaZ4u8Ru61Da5gKYfNaUn18ON2L0=.e2d34b26-392f-411b-aaa0-6d6e5dcb8da6@github.com>
Message-ID: <mE94JEkd5TMIoNFh-hDX-dLLftbrxaBzHur8gD_fDAY=.ede7d99d-f316-4658-a291-a7dc35ae421b@github.com>

On Wed, 26 Mar 2025 14:36:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Fixed several issues found in importing RTF text:
>> 
>> - charset translation (brought back removed code)
>> - missing font size attribute
>> - missing strike-through attribute
>> 
>> Also, HTML copy suffered from the following issues:
>> 
>> - incorrect font size
>> - incorrect handling of boolean character attributes (bold, italic, etc.)
>> 
>> The charset issue was caused by my removal of the character decoder code present in the original JDK RTF parser/reader.  Why did I do that?
>> 
>> This PR does not add import of RTL paragraph attribute needed to align RTL text correctly.
>
> Andy Goryachev 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 10 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8351878.rtf
>  - html
>  - Merge remote-tracking branch 'origin/master' into 8351878.rtf
>  - arabic
>  - whitespace
>  - test
>  - strikethrough
>  - missing code in attr set
>  - font size
>  - fixed arabic import

LGTM - did some testing, both with issue-attached Word file and some standard Polish diacritic test sentences and everything seems to work fine.

Question coming from my own curiosity - when you post a sentence containing diacritics (ex. shortest tester for all diacritics in Polish - "Za???? g??l? ja??") you can see that some fonts don't support those special characters (ex. Arial Rounded MT Bold on Windows) so as a fallback they are drawn with a different font that supports them. It's quite normal behavior to do so I've seen often, but do you know what is the process for determining which font to use as a replacement in RTA? Is it something we have to worry about?

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

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1735#pullrequestreview-2742887263

From jhendrikx at openjdk.org  Fri Apr  4 12:49:03 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 4 Apr 2025 12:49:03 GMT
Subject: RFR: 8345348: CSS Media Queries [v5]
In-Reply-To: <uhKMuAnGVXWMarZcIFh32kY-2LIbwhbr3sc-pVw7Mg4=.ca9985e3-187b-49e6-94a2-0d4f63bee84e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <uhKMuAnGVXWMarZcIFh32kY-2LIbwhbr3sc-pVw7Mg4=.ca9985e3-187b-49e6-94a2-0d4f63bee84e@github.com>
Message-ID: <MIscBiKHJGWPN3RBaLefllG9fy6YVsbot74RsBrrLPg=.4af2ea42-8d73-412a-8004-959f81940f06@github.com>

On Fri, 4 Apr 2025 11:13:43 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add documentation

I think you should consider moving `MediaRule`, `MediaQuery` and `MediaQueryContext` to `com.sun.javafx.css` (or similar internal package).  The javafx.css module IMHO should not be further extended in its current form, as IMHO it needs a rethink first.  From what I gather it was only made public to support writing binary CSS files, which was done primarily to be able to load huge stylesheets like caspian/modena a bit faster; it's public interface was never really thought through, and there are no known users (aside from Scene Builder), and AFAIK no use cases for the API (`StyleSheet` can't be directly used by the CSS engine, and doing so would probably cripple it as the `StyleSheet` class seems to be observable in all its aspects -- I have doubts any of that is currently in use, but perhaps Scene Builder uses it).

I verified on a local build that this is easy to do (you need to make some constructors public, and the writeBinary/readBinary functions after they've been moved to the internal package).

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

PR Comment: https://git.openjdk.org/jfx/pull/1655#issuecomment-2778640513

From jdv at openjdk.org  Fri Apr  4 13:57:04 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 4 Apr 2025 13:57:04 GMT
Subject: RFR: 8353557: Skip some system tests on Linux
In-Reply-To: <kGoSYDlUYPe_-4WNrdbkPSpI5l8y0Bt_G_rCSziKds0=.8e3cddf6-358e-4703-9911-66f89e4291a5@github.com>
References: <Nkf2BWQcSqOJafYyo9mSVlsFZWYP2k0g2sg83B0CTaA=.f80c78a4-fb9b-47fe-ab93-6d4d36348f2b@github.com>
 <kGoSYDlUYPe_-4WNrdbkPSpI5l8y0Bt_G_rCSziKds0=.8e3cddf6-358e-4703-9911-66f89e4291a5@github.com>
Message-ID: <9y-E-m9cjkS_7uXphb4W3do4ax9YTHH0XcCJ5tRfzsA=.70a98caf-7d9b-46c3-9eea-fa65eda1d525@github.com>

On Fri, 4 Apr 2025 11:55:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> The changes look good. I'll do a quick test as well and then approve. Please make sure you've done a full automated test run before integrating.

I have run full automated test run and all updated tests behave as expected on all test platforms.

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

PR Comment: https://git.openjdk.org/jfx/pull/1762#issuecomment-2778800352

From kcr at openjdk.org  Fri Apr  4 14:17:53 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 4 Apr 2025 14:17:53 GMT
Subject: RFR: 8353557: Skip some system tests on Linux
In-Reply-To: <Nkf2BWQcSqOJafYyo9mSVlsFZWYP2k0g2sg83B0CTaA=.f80c78a4-fb9b-47fe-ab93-6d4d36348f2b@github.com>
References: <Nkf2BWQcSqOJafYyo9mSVlsFZWYP2k0g2sg83B0CTaA=.f80c78a4-fb9b-47fe-ab93-6d4d36348f2b@github.com>
Message-ID: <pq2VRtITQnm7tNbrAXFAfS11LeXtAKKLkUDgjeUajjU=.042de69e-4598-4780-a1c8-10f76b116c6d@github.com>

On Fri, 4 Apr 2025 10:16:18 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Under https://bugs.openjdk.org/browse/JDK-8339679 task, we are running full tests and identifying issues for Ubuntu 24.04.
> 
> As part of above task 6 test failures were identified and looks like these test failures are happening because of product issues in Ubuntu24.04.
> 
> Test failures are:
> 1) RestoreSceneSizeTest and its product issue : [JDK-8353556](https://bugs.openjdk.org/browse/JDK-8353556)
> 2) PageFillTest  and its product issue : [JDK-8353561](https://bugs.openjdk.org/browse/JDK-8353561)
> 3) SizeToSceneTest and its product issue : [JDK-8353612](https://bugs.openjdk.org/browse/JDK-8353612)
> 4) WrongStageFocusWithApplicationModalityTest fails intermittently only in Wayland and its product issue : [JDK-8353643](https://bugs.openjdk.org/browse/JDK-8353643)
> 5) InitializeJavaFXLaunch1Test & InitializeJavaFXLaunch2Test fails intermittently only in Xorg and its product issue : [JDK-8353644](https://bugs.openjdk.org/browse/JDK-8353644)
> 
> As part of test stabilization task these identified test failures will be skipped and we have product issues raised for them.
> 
> I tried finding ways to add utility to skip tests only in Ubuntu 24.04. System.Properties doesn't list any item which can be used to identified a specific Linux distro or Ubuntu version. If we need to identify Ubuntu and its version we need to use executable like `lsb_release`. 
> 
> So test which are failing in both Wayland & Xorg are skipped for Linux platform and if they fail with specific windowing system(Wayland/Xorg) they are skipped only under them.

Sanity test passed.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1762#pullrequestreview-2743149663

From angorya at openjdk.org  Fri Apr  4 14:37:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 14:37:01 GMT
Subject: Integrated: 8353668: Rename internal c.s.javafx.text.TextLine class
In-Reply-To: <sV5TXJiKPOmJuNG3vjMHR8eGnEAeg-gY-5rr9gRPx6g=.215cc532-e023-46ec-acbc-ec0eea5102e9@github.com>
References: <sV5TXJiKPOmJuNG3vjMHR8eGnEAeg-gY-5rr9gRPx6g=.215cc532-e023-46ec-acbc-ec0eea5102e9@github.com>
Message-ID: <3hotV16ghGqbilNeALJvVkf-U-ofDVhNeRvOUulOEV8=.3075275b-227e-42dd-a390-139fcd0de8d3@github.com>

On Thu, 3 Apr 2025 18:01:07 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> This minor change renames an internal `com.sun.javafx.text.TextLine` to `PrismTextLine`.
> This class implements `com.sun.javafx.scene.text.TextLine` interface, also internal, for the purpose of reducing confusion and avoiding FQCN.
> 
> This change is completely transparent to the application developers since no public APIs is impacted.

This pull request has now been integrated.

Changeset: 714f17f3
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/714f17f32b430a3467afb611c5a36dbe1841ec79
Stats:     211 lines in 4 files changed: 96 ins; 96 del; 19 mod

8353668: Rename internal c.s.javafx.text.TextLine class

Reviewed-by: mstrauss

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

PR: https://git.openjdk.org/jfx/pull/1760

From angorya at openjdk.org  Fri Apr  4 14:39:10 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 14:39:10 GMT
Subject: Integrated: 8353587: Spelling errors and dead code
In-Reply-To: <JsCpNkfgSc-GS_IFokWtVGUDrJMiC4bZ0WAh6geC7n8=.1f052ec0-0b93-4b60-a68e-d43acce92c58@github.com>
References: <JsCpNkfgSc-GS_IFokWtVGUDrJMiC4bZ0WAh6geC7n8=.1f052ec0-0b93-4b60-a68e-d43acce92c58@github.com>
Message-ID: <glh4A41HSQAoXgPskwTtH5WF9aPybj64bscdG4EA1ds=.5922dac6-853d-49b9-bc9c-22877de9f6c6@github.com>

On Wed, 2 Apr 2025 22:03:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Corrects annoying spelling errors in the code:
> 
> - propogated
> - Hueristic2D
> 
> Also fixes unnecessary field in MenuBar:171

This pull request has now been integrated.

Changeset: 76282bcf
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/76282bcf20a6ee09d16ed1d2ddea37749a921346
Stats:     43 lines in 7 files changed: 11 ins; 16 del; 16 mod

8353587: Spelling errors and dead code

Reviewed-by: arapte

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

PR: https://git.openjdk.org/jfx/pull/1757

From angorya at openjdk.org  Fri Apr  4 14:42:20 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 14:42:20 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v23]
In-Reply-To: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
Message-ID: <COXsxBJaTLOpBjcyoBzPLmqRy6AN7n7uW_5J4vF0AVA=.647965aa-780a-4706-8248-a621fe1625b7@github.com>

> Please refer to
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
> 
> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
> 
> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
> 
> 
>     /**
>      * Obtains the snapshot of the current text layout information.
>      * @return the layout information
>      * @since 25
>      */
>     public final LayoutInfo getLayoutInfo()
> 
> 
> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
> 
> - caret information
> - text lines: offsets and bounds
> - overall layout bounds
> - text selection geometry
> - strike-through geometry
> - underline geometry
> 
> 
> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
> 
> 
>     /**
>      * Returns the shape for the strike-through in local coordinates.
>      *
>      * @param start the beginning character index for the range
>      * @param end the end character index (non-inclusive) for the range
>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>      * @since 25
>      */
>     public final PathElement[] strikeThroughShape(int start, int end)
> 
> 
> 
> 
> ## WARNING
> 
> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
> 
> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
> 
> 
> 
> ## Testing
> 
> The new APIs can be visually tested using the Monkey Tester on this branch:
> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
> 
> in the Text and TextFlow pages:
> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
> 
> Two very basic headful tests have been added.
> 
> 
> ## See Also
> 
> https://github.com/FXMisc/RichTextFX/pull/1246

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits:

 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - twice
 - tests
 - review comments
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - review comments
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - 25 25
 - ... and 38 more: https://git.openjdk.org/jfx/compare/76282bcf...33cf88d8

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

Changes: https://git.openjdk.org/jfx/pull/1596/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=22
  Stats: 1538 lines in 13 files changed: 1476 ins; 18 del; 44 mod
  Patch: https://git.openjdk.org/jfx/pull/1596.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1596/head:pull/1596

PR: https://git.openjdk.org/jfx/pull/1596

From angorya at openjdk.org  Fri Apr  4 15:24:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 15:24:57 GMT
Subject: RFR: 8351878: RichTextArea: copy/paste issues [v5]
In-Reply-To: <mE94JEkd5TMIoNFh-hDX-dLLftbrxaBzHur8gD_fDAY=.ede7d99d-f316-4658-a291-a7dc35ae421b@github.com>
References: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
 <rs-4MqFkEhQm4iyoaZ4u8Ru61Da5gKYfNaUn18ON2L0=.e2d34b26-392f-411b-aaa0-6d6e5dcb8da6@github.com>
 <mE94JEkd5TMIoNFh-hDX-dLLftbrxaBzHur8gD_fDAY=.ede7d99d-f316-4658-a291-a7dc35ae421b@github.com>
Message-ID: <aB0_oRQe7wghz0KxrZI4UI3YckVzz6SSYh_M-Xkh0So=.94a6e57f-8c59-48e8-b380-24bfbefb49fc@github.com>

On Fri, 4 Apr 2025 12:43:54 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> LGTM
than you!


> some fonts don't support those special characters (ex. Arial Rounded MT Bold on Windows) so as a fallback they are drawn with a different font that supports them. It's quite normal behavior to do so I've seen often, but do you know what is the process for determining which font to use as a replacement in RTA?

A good question!  Maybe @prrace can explain the process.  Looking in the Monkey Tester, it is clear that the font substitution algorithm is unable to pick the right fallback font from Arial Rounded MT Bold on macOS (while Swing simply refuses to render anything):

![Screenshot 2025-04-04 at 08 21 04](https://github.com/user-attachments/assets/77f49143-20c1-4e0a-8f71-a76c966772a0)

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

PR Comment: https://git.openjdk.org/jfx/pull/1735#issuecomment-2779058996

From jdv at openjdk.org  Fri Apr  4 15:33:52 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 4 Apr 2025 15:33:52 GMT
Subject: Integrated: 8353557: Skip some system tests on Linux
In-Reply-To: <Nkf2BWQcSqOJafYyo9mSVlsFZWYP2k0g2sg83B0CTaA=.f80c78a4-fb9b-47fe-ab93-6d4d36348f2b@github.com>
References: <Nkf2BWQcSqOJafYyo9mSVlsFZWYP2k0g2sg83B0CTaA=.f80c78a4-fb9b-47fe-ab93-6d4d36348f2b@github.com>
Message-ID: <J3HZ7QYM9o5GnyuJsMHGkZiYVQYQfLXeiHqiMii2Sqs=.d610caa7-c5b2-47eb-8418-4d9c88338e82@github.com>

On Fri, 4 Apr 2025 10:16:18 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Under https://bugs.openjdk.org/browse/JDK-8339679 task, we are running full tests and identifying issues for Ubuntu 24.04.
> 
> As part of above task 6 test failures were identified and looks like these test failures are happening because of product issues in Ubuntu24.04.
> 
> Test failures are:
> 1) RestoreSceneSizeTest and its product issue : [JDK-8353556](https://bugs.openjdk.org/browse/JDK-8353556)
> 2) PageFillTest  and its product issue : [JDK-8353561](https://bugs.openjdk.org/browse/JDK-8353561)
> 3) SizeToSceneTest and its product issue : [JDK-8353612](https://bugs.openjdk.org/browse/JDK-8353612)
> 4) WrongStageFocusWithApplicationModalityTest fails intermittently only in Wayland and its product issue : [JDK-8353643](https://bugs.openjdk.org/browse/JDK-8353643)
> 5) InitializeJavaFXLaunch1Test & InitializeJavaFXLaunch2Test fails intermittently only in Xorg and its product issue : [JDK-8353644](https://bugs.openjdk.org/browse/JDK-8353644)
> 
> As part of test stabilization task these identified test failures will be skipped and we have product issues raised for them.
> 
> I tried finding ways to add utility to skip tests only in Ubuntu 24.04. System.Properties doesn't list any item which can be used to identified a specific Linux distro or Ubuntu version. If we need to identify Ubuntu and its version we need to use executable like `lsb_release`. 
> 
> So test which are failing in both Wayland & Xorg are skipped for Linux platform and if they fail with specific windowing system(Wayland/Xorg) they are skipped only under them.

This pull request has now been integrated.

Changeset: 5d413646
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/5d41364681544070a9c00612cf189bf9f1f5eda1
Stats:     34 lines in 6 files changed: 27 ins; 0 del; 7 mod

8353557: Skip some system tests on Linux

Reviewed-by: kcr

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

PR: https://git.openjdk.org/jfx/pull/1762

From mstrauss at openjdk.org  Fri Apr  4 16:23:19 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 4 Apr 2025 16:23:19 GMT
Subject: RFR: 8345348: CSS Media Queries [v6]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <LpN_DJ-XYdDoUaDs3QJUpoZByc-fE-qMBinfSpmBGk0=.0509b775-b73d-4499-a651-005aa1ea3757@github.com>

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  make media-query types internal

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/49831689..e214d5cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=05
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=04-05

  Stats: 135 lines in 20 files changed: 71 ins; 23 del; 41 mod
  Patch: https://git.openjdk.org/jfx/pull/1655.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655

PR: https://git.openjdk.org/jfx/pull/1655

From jdv at openjdk.org  Fri Apr  4 16:30:52 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 4 Apr 2025 16:30:52 GMT
Subject: RFR: 8352746: [TestBug] Monkey Tester Application Update 5
In-Reply-To: <actvM3rNHh_Z40XsdTOlze1lNr6sWeH3nXbchpMCiSg=.7945ddac-466c-4fd6-a262-74c0a9a8ef94@github.com>
References: <actvM3rNHh_Z40XsdTOlze1lNr6sWeH3nXbchpMCiSg=.7945ddac-466c-4fd6-a262-74c0a9a8ef94@github.com>
Message-ID: <0fHZW2hxgnCFFjx4RivVth96RwrIADn6WJGIL-aEkCs=.d09e46b4-e24b-487d-afa5-0e9fd3c03df7@github.com>

On Mon, 31 Mar 2025 23:11:42 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Further additions to the MonkeyTester application:
> 
> - platform preferences monitor
> - improved pages: hbox, vbox
> - improved css playground
> - mouse listener option in some context menus
> - additional choices: background
> - additional properties: Node::clip, Region::shape, TextInputControl::textFormatter
> - font selector in Tools -> JTextArea/JTextField Embedded in SwingNode
> 
> ## New Pages
> - anchor pane
> - border pane
> - button bar
> - flow pane
> - grid pane
> - media player
> - progress indicator
> - separator
> - slider
> - stack pane
> - stage
> - tile pane
> 
> ## Properties Monitor
> 
> ![Screenshot 2025-03-31 at 16 18 17](https://github.com/user-attachments/assets/fa4256ab-c58a-4f93-bee1-a9b5236f64a6)

Looks good to me.
Played around with newly added features and everything works fine in my macOS 14.7.4 system.

tests/manual/monkey/README.md line 30:

> 28: 
> 29: ```
> 30: java -p <JAVAFX>/javafx-sdk-24/lib/ --add-modules ALL-MODULE-PATH -jar MonkeyTester.jar

I used the README to build and run this app.
Suggestion for future updates:
In this command we should not add "javafx-sdk-24" in the path.
JAVAFX already includes sdk folder we just need to use `java -p <JAVAFX>/lib/ --add-modules ALL-MODULE-PATH -jar MonkeyTester.jar`

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

Marked as reviewed by jdv (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1750#pullrequestreview-2743571611
PR Review Comment: https://git.openjdk.org/jfx/pull/1750#discussion_r2029114029

From angorya at openjdk.org  Fri Apr  4 17:23:04 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 17:23:04 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
 [v5]
In-Reply-To: <zmcMPx3_xbFTT8bfcswV1I_RqIklLepFO32lQJfOCiE=.0a5e39b0-42bc-4f5f-a980-5271412f42f7@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
 <zmcMPx3_xbFTT8bfcswV1I_RqIklLepFO32lQJfOCiE=.0a5e39b0-42bc-4f5f-a980-5271412f42f7@github.com>
Message-ID: <yyBDdiK_7FFwCNe1Jb_38qObkB3ggB6Jl4ovol_6DvM=.5b0f8cf8-13a0-45ed-bf04-1d2f702be86f@github.com>

On Fri, 4 Apr 2025 06:08:28 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.
>
> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-order imports

Found some issues, please take a look.

modules/javafx.base/src/test/java/test/javafx/binding/BindingsNumberCastTest.java line 96:

> 94:     void testBindings(Functions func) {
> 95:         this.func = func;
> 96:         setUp(); // Call setup before each parameterized run

let's apply the same treatment here (for the sake of any possible future tests):
- remove `@BeforeEach` from `setUp()`
- add `(Function func)` argument to `setUp()`
- probably can remove the comment here or move it to `setUp()`

(I like how you combined multiple tests in one, it's ok in this case, as we don't expect these tests to fail intermittently or fail altogether.  Generally speaking, we should not be doing that as a failure in one use case would mask any possible failures that might happen down the line.)

modules/javafx.base/src/test/java/test/javafx/collections/ObservableListEmptyTest.java line 44:

> 42: public class ObservableListEmptyTest {
> 43: 
> 44:     static List<String> EMPTY = Collections.emptyList();

`EMPTY` can be final

modules/javafx.base/src/test/java/test/javafx/collections/ObservableListEmptyTest.java line 60:

> 58:     }
> 59: 
> 60:     public void setUp(Callable<ObservableList<String>> listFactory) throws Exception {

private?

modules/javafx.base/src/test/java/test/javafx/collections/ObservableListEmptyTest.java line 61:

> 59: 
> 60:     public void setUp(Callable<ObservableList<String>> listFactory) throws Exception {
> 61:         listFactory = listFactory;

Look carefully: this code has a big issue.

Interestingly, I've seen code in production that had issues like this one that went unnoticed for years.  

A good IDE would warn here (Eclipse does).

Should be

`this.listFactory = listFactory;`

modules/javafx.base/src/test/java/test/javafx/collections/ObservableListTest.java line 68:

> 66: 
> 67:     private void setUp(Callable<ObservableList<String>> listFactory) throws Exception {
> 68:         listFactory = listFactory;

same issue: should be 

`this.listFactory = listFactory;`

modules/javafx.base/src/test/java/test/javafx/collections/ObservableSetTest.java line 62:

> 60: 
> 61:     private void setUp(Callable<ObservableSet<String>> setFactory) throws Exception {
> 62:         setFactory = setFactory;

and this is the third place

`this.setFactory = setFactory;`

modules/javafx.base/src/test/java/test/javafx/collections/ObservableSubListIteratorTest.java line 61:

> 59:     private Callable<? extends List<String>> listFactory;
> 60:     private List<String> list;
> 61:     private ListIterator<String> iter;

this is likely incorrect:

`listFactory`, `list`, and `iter` are present in the base class.  please remove from here.

modules/javafx.base/src/test/java/test/javafx/util/converter/DateStringConverterTest.java line 108:

> 106:         this.dateFormat = dateFormat;
> 107: 
> 108:         if (dateFormat != null) {

what was the reason for this code (LL108 - 114) removal?
and for the removal of the tests from L136?

this removal also makes `private DateFormat validFormatter;` unused

modules/javafx.base/src/test/java/test/javafx/util/converter/DateTimeStringConverterTest.java line 104:

> 102:     private DateFormat validFormatter;
> 103: 
> 104:     public DateTimeStringConverterTest(DateTimeStringConverter converter, Locale locale, int dateStyle, int timeStyle, Date validDate, String pattern, DateFormat dateFormat) {

Is there a reason you did not follow the conversion pattern using setup() method?
I think the test is mangled now.  Could you please double check?

modules/javafx.base/src/test/java/test/javafx/util/converter/DateTimeStringConverterTest.java line 216:

> 214:             DateFormat dateFormat = DateTimeStringConverterShim.getDateFormatVar(converter);
> 215:             assertNotNull(dateFormat);
> 216:         }

please double-check: the code LL213-L126 looks misplaced here.  it used to be a part of the constructor, and in this case should probably precede the assertions.

modules/javafx.base/src/test/java/test/javafx/util/converter/ParameterizedConverterTest.java line 41:

> 39: 
> 40:     static Stream<Arguments> converterClasses() {
> 41:         return Stream.of(

FYI: I think you could simply return a `List<Class<? extends StringConverter<?>>>`, but this code is ok too.

modules/javafx.base/src/test/java/test/javafx/util/converter/TimeStringConverterTest.java line 149:

> 147: 
> 148:     @ParameterizedTest
> 149:     @MethodSource("provideConvertersForGetDateFormat")

ooh, using two different `@MethodSource`s, nice.

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

Changes requested by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1759#pullrequestreview-2743583859
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2029121644
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2029133625
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2029134174
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2029136424
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2029145526
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2029148630
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2029152054
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2029162216
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2029167960
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2029166902
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2029176382
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2029179457

From mfox at openjdk.org  Fri Apr  4 17:24:09 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 4 Apr 2025 17:24:09 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
Message-ID: <gudWoMGQ_h-voKUQdgKCgam56yr0bRwiofo1alCyxY0=.6e61519a-2c2c-45ec-82f6-772b4af19791@github.com>

On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Adds code to trigger a scene update when a Window is restored
> 
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479

First an errata: I wrote earlier that notifyRepaint is only called on Linux when restoring a window. I was wrong, it's also called for EXPOSE events.

Anyway, I can reproduce this bug on all three platforms.

JavaFX won't paint to a minimized window. This suggests to me that when we transition out of the minimized state someone needs to call `entireSceneNeedsRepaint`. The glass code on Windows and Linux both issue `notifyRepaint` which eventually calls `entireSceneNeedsRepaint`.  The Mac code never issues `notifyRepaint` and  `entireSceneNeedsRepaint` isn't called.

I can tweak the Mac code to call `notifyRepaint` to match Windows and Linux but presumably that won't fix the bug. It looks like some other bit of state gets out of whack due to the way the system refuses to paint while minimized. I have no idea whether `updateSceneState` is the appropriate call to get the system back into sync or not.

I have verified that on all platforms `updateSceneState` is not being called when the window is restored. I'll also note that with this test case there's no focus ring or flashing caret that needs to be drawn which seems to make a difference.

Reproducing this on macOS 15 is complicated by some weirdness going on under the hood. The address of the main screen changes unexpectedly. This causes glass to send `notifyMoveToAnotherScreen` which resets a whole lot of state. This can happen when I first move a window or when I iconify and de-iconify it. Depending on the "Minimize windows to application icon" setting this can happen every time I de-iconify or only the first time. I have no idea why the system keeps generating new NSScreen objects on an ongoing basis.

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

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2779336390

From angorya at openjdk.org  Fri Apr  4 17:30:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 17:30:01 GMT
Subject: RFR: 8352746: [TestBug] Monkey Tester Application Update 5
In-Reply-To: <0fHZW2hxgnCFFjx4RivVth96RwrIADn6WJGIL-aEkCs=.d09e46b4-e24b-487d-afa5-0e9fd3c03df7@github.com>
References: <actvM3rNHh_Z40XsdTOlze1lNr6sWeH3nXbchpMCiSg=.7945ddac-466c-4fd6-a262-74c0a9a8ef94@github.com>
 <0fHZW2hxgnCFFjx4RivVth96RwrIADn6WJGIL-aEkCs=.d09e46b4-e24b-487d-afa5-0e9fd3c03df7@github.com>
Message-ID: <I-0qYyJgVD06JMCJwcfnNroD4-dIjXwtFjiRKJ-iT3s=.8e9eb2a6-96dc-4d0f-9193-5047f614f26e@github.com>

On Fri, 4 Apr 2025 16:26:22 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Further additions to the MonkeyTester application:
>> 
>> - platform preferences monitor
>> - improved pages: hbox, vbox
>> - improved css playground
>> - mouse listener option in some context menus
>> - additional choices: background
>> - additional properties: Node::clip, Region::shape, TextInputControl::textFormatter
>> - font selector in Tools -> JTextArea/JTextField Embedded in SwingNode
>> 
>> ## New Pages
>> - anchor pane
>> - border pane
>> - button bar
>> - flow pane
>> - grid pane
>> - media player
>> - progress indicator
>> - separator
>> - slider
>> - stack pane
>> - stage
>> - tile pane
>> 
>> ## Properties Monitor
>> 
>> ![Screenshot 2025-03-31 at 16 18 17](https://github.com/user-attachments/assets/fa4256ab-c58a-4f93-bee1-a9b5236f64a6)
>
> tests/manual/monkey/README.md line 30:
> 
>> 28: 
>> 29: ```
>> 30: java -p <JAVAFX>/javafx-sdk-24/lib/ --add-modules ALL-MODULE-PATH -jar MonkeyTester.jar
> 
> I used the README to build and run this app.
> Suggestion for future updates:
> In this command we should not add "javafx-sdk-24" in the path.
> JAVAFX already includes sdk folder we just need to use `java -p <JAVAFX>/lib/ --add-modules ALL-MODULE-PATH -jar MonkeyTester.jar`

good point, thanks!

Created https://bugs.openjdk.org/browse/JDK-8353743

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1750#discussion_r2029186028

From angorya at openjdk.org  Fri Apr  4 17:30:02 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 17:30:02 GMT
Subject: Integrated: 8352746: [TestBug] Monkey Tester Application Update 5
In-Reply-To: <actvM3rNHh_Z40XsdTOlze1lNr6sWeH3nXbchpMCiSg=.7945ddac-466c-4fd6-a262-74c0a9a8ef94@github.com>
References: <actvM3rNHh_Z40XsdTOlze1lNr6sWeH3nXbchpMCiSg=.7945ddac-466c-4fd6-a262-74c0a9a8ef94@github.com>
Message-ID: <nJhxlXpztkdALpUjGahvozZZcC1qS0V6O3m3WsfUaXA=.a40a9ff2-e5e3-43b8-982c-412434caae45@github.com>

On Mon, 31 Mar 2025 23:11:42 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Further additions to the MonkeyTester application:
> 
> - platform preferences monitor
> - improved pages: hbox, vbox
> - improved css playground
> - mouse listener option in some context menus
> - additional choices: background
> - additional properties: Node::clip, Region::shape, TextInputControl::textFormatter
> - font selector in Tools -> JTextArea/JTextField Embedded in SwingNode
> 
> ## New Pages
> - anchor pane
> - border pane
> - button bar
> - flow pane
> - grid pane
> - media player
> - progress indicator
> - separator
> - slider
> - stack pane
> - stage
> - tile pane
> 
> ## Properties Monitor
> 
> ![Screenshot 2025-03-31 at 16 18 17](https://github.com/user-attachments/assets/fa4256ab-c58a-4f93-bee1-a9b5236f64a6)

This pull request has now been integrated.

Changeset: a52e2fa4
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/a52e2fa498782e9329f1c8b78805a29e63242a9a
Stats:     4404 lines in 60 files changed: 4063 ins; 167 del; 174 mod

8352746: [TestBug] Monkey Tester Application Update 5

Reviewed-by: lkostyra, jdv

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

PR: https://git.openjdk.org/jfx/pull/1750

From angorya at openjdk.org  Fri Apr  4 18:36:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 18:36:56 GMT
Subject: RFR: 8234153: [TEST_BUG] Rewrite Popup_parentWindow_Test
In-Reply-To: <7bf72skQqQkaixdRyiilnIW35lkXC_X3GzbSNt9ot0U=.256071a4-e230-4e5e-9e97-aad6f614e01b@github.com>
References: <7bf72skQqQkaixdRyiilnIW35lkXC_X3GzbSNt9ot0U=.256071a4-e230-4e5e-9e97-aad6f614e01b@github.com>
Message-ID: <pNrmBuQ8R1EgzyV-DyCkRR4B0-XPynZorQVzlDTddLY=.d132d590-95dd-42c6-9d66-10478ba875e7@github.com>

On Fri, 4 Apr 2025 11:30:04 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> This change rewrites `Popup_parentWindow_Test` after a-long-time-ago-done changes to Popup public API.
> 
> Popup used to have an `owner` and `parentWindow` properties. I couldn't track how far back that change happened so I can't fully say what these Properties actually were, but to my knowledge both properties were replaced by `ownerNode` and `ownerWindow` Properties respectively. New Properties are read-only and are set while calling respective `Popup.show()` - `Popup.show(Node, ...)` sets both Properties, while `Popup.show(Window, ...)` sets only `ownerWindow` Property.
> 
> A lot of original test scenarios were cut out because with current Popup API they make little to no sense. Original `Popup_parentWindow_Test` extended `PropertiesTestBase` and ran the regular Property access checks. Those are parametrized and split into four test methods:
> - `testGetBean` - confidence check for whether we can get the Property bean, unnecessary since new tests access the Properties directly
> - `testGetName` - Properties in `PropertiesTestBase` are referred to by String-provided name and Reflection, so this was a confidence check whether those Properties actually exist in the object - unnecessary, since we access the Properties directly
> - `testBinding` - I deemed those not doable, since the Properties we try to access are read-only and cannot be bound to
> - `testBasicAccess` - This is the only test I found that was workable into a reimplementation, and so it is manually reimplemented as `Popup_owner_Test`
> 
> Moreover, because of lack of `Popup.setParent()` API I also deemed more complex test scenarios (cases referring to TestScene's `_window` Property) unnecessary. Since there is no `Popup.show(Scene, ...)` those cases were also eliminated. This leaves current test pool into three separate parameters for one, similar test case.

lgtm, with some very minor comments.

modules/javafx.graphics/src/test/java/test/javafx/stage/Popup_owner_Test.java line 55:

> 53:  * Instead we rely on checking this manually.
> 54:  */
> 55: public final class Popup_owner_Test {

minor: maybe `Popup_Owner_Test`?

modules/javafx.graphics/src/test/java/test/javafx/stage/Popup_owner_Test.java line 245:

> 243: 
> 244:         public void assertCalled() {
> 245:             if (counter != expected) {

minor: this can probably be replaced by `assertEquals()`

modules/javafx.graphics/src/test/java/test/javafx/stage/Popup_owner_Test.java line 251:

> 249: 
> 250:         public void assertNotCalled() {
> 251:             if (counter != 0) {

minor: `assertTrue()` here?

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1763#pullrequestreview-2743813240
PR Review Comment: https://git.openjdk.org/jfx/pull/1763#discussion_r2029269310
PR Review Comment: https://git.openjdk.org/jfx/pull/1763#discussion_r2029263496
PR Review Comment: https://git.openjdk.org/jfx/pull/1763#discussion_r2029264546

From mfox at openjdk.org  Fri Apr  4 20:37:53 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 4 Apr 2025 20:37:53 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
Message-ID: <ZrtMaPYmKNqvf-y4YLV8Ihf-uZJmlNEhYdFM2uIUH24=.3e0fec0f-5718-4233-ac3e-96a13e94f5a1@github.com>

On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Adds code to trigger a scene update when a Window is restored
> 
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479

I think this PR is the correct fix on Windows and Linux. The scene state tracks the minimized state of the window. When the window is restored someone needs to tell the scene state to go update the isWindowMinimized flag.

The Mac will require another tweak. Personally I would just modify glass to send notifyRepaint in this specific instance. I suppose that should be treated as a separate bug. Unfortunately it's going to be a bear to test given the strange things happening under the hood with NSScreen (at least on my system).

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

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2779682869

From kcr at openjdk.org  Fri Apr  4 20:40:58 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 4 Apr 2025 20:40:58 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v6]
In-Reply-To: <5NHefa7QPAKVumTruzFaSy0ZZJwIKhF9gvK2jI3bDYs=.75ff7ebb-2a02-43be-a73f-9f5d1d7858c3@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <5NHefa7QPAKVumTruzFaSy0ZZJwIKhF9gvK2jI3bDYs=.75ff7ebb-2a02-43be-a73f-9f5d1d7858c3@github.com>
Message-ID: <Q7QUArr2orKS0ZNaxKuxjjR_uQsSEIYjrH60g0CWlL4=.a3317a3c-9663-4c3d-b36e-4c01d3c71389@github.com>

On Wed, 2 Apr 2025 15:04:54 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.
>> 
>> The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.
>> 
>> The log contains a base-64 encoded screenshot (like this: `data:image/png;base64,iVBORw0KGgoAAAANSUhEU...` )
>> so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)
>> 
>> Additionally, provided a utility class to capture the screenshots at the specific point in a test and write it to stdout/stderr:
>> 
>> 
>> // write a base-64 encoded screenshot to stderr
>> ScreenshotCapture.writeScreenshot(System.err);
>> 
>> 
>> Example:
>> 
>> ![jenkins-screenshot](https://github.com/user-attachments/assets/abebd76f-747a-4d6d-a9a6-63c6e9426830)
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc

The functionality looks good, and I confirm that there are now no uses of the new utility API or test watcher in our check-in tests. I left a couple comments on the API for the test methods.

One other thing that might be helpful is class docs that describe the two different ways of using it (the watcher annotation and the direct call to the utility method).

tests/system/src/test/java/test/util/ScreenshotCapture.java line 60:

> 58:      * @throws IOException when an I/O error occurs
> 59:      */
> 60:     public static byte[] takeScreenshot() throws IOException {

I have no idea how to interpret this byte array. What is the use case for this method?

tests/system/src/test/java/test/util/ScreenshotCapture.java line 93:

> 91:      */
> 92:     public static void writeScreenshot(PrintStream out) {
> 93:         out.println(ScreenshotCapture.takeScreenshotBase64("Screenshot:\ndata:image/png;base64,", null));

With the change I am suggesting to `takeScreenshotBase64 `, this would become:


        out.println("Screenshot:");
        out.println(takeScreenshotBase64());


That makes the `takeScreenshotBase64` API cleaner with a better separation of concerns.

tests/system/src/test/java/test/util/ScreenshotCapture.java line 107:

> 105:      * @return the screenshot in Base-64 encoded PNG, or an error message
> 106:      */
> 107:     public static String takeScreenshotBase64(String prefix, String postfix) {

Passing in the `data:image/png;base64,` as a prefix is odd. This method takes a screen shot and turns it into a base64-encoded PNG. Don't make the caller pass in something that has to match this internal behavior of this method. I would recommend removing the prefix and postfix entirely, and having this method return a simple base64-encoded PNG with a `data:image/png;base64,` data URL. The caller can add any other String before or after this.

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

PR Review: https://git.openjdk.org/jfx/pull/1746#pullrequestreview-2744035824
PR Comment: https://git.openjdk.org/jfx/pull/1746#issuecomment-2779684965
PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2029394657
PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2029401366
PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2029399198

From kcr at openjdk.org  Fri Apr  4 20:40:59 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 4 Apr 2025 20:40:59 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v6]
In-Reply-To: <Q7QUArr2orKS0ZNaxKuxjjR_uQsSEIYjrH60g0CWlL4=.a3317a3c-9663-4c3d-b36e-4c01d3c71389@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <5NHefa7QPAKVumTruzFaSy0ZZJwIKhF9gvK2jI3bDYs=.75ff7ebb-2a02-43be-a73f-9f5d1d7858c3@github.com>
 <Q7QUArr2orKS0ZNaxKuxjjR_uQsSEIYjrH60g0CWlL4=.a3317a3c-9663-4c3d-b36e-4c01d3c71389@github.com>
Message-ID: <sCVdHaAoEYeCxUPbK3Gc80SsezGFGjFvNa6u4o27oaE=.86b18415-6b1e-45e3-a058-ca36da5c533b@github.com>

On Fri, 4 Apr 2025 20:36:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> One other thing that might be helpful is class docs that describe the two different ways of using it (the watcher annotation and the direct call to the utility method).

Scratch the first part of this suggestion: the annotation already has this. Maybe add class docs in the utility class showing it its use?

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

PR Comment: https://git.openjdk.org/jfx/pull/1746#issuecomment-2779687262

From angorya at openjdk.org  Fri Apr  4 20:46:54 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 20:46:54 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v6]
In-Reply-To: <sCVdHaAoEYeCxUPbK3Gc80SsezGFGjFvNa6u4o27oaE=.86b18415-6b1e-45e3-a058-ca36da5c533b@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <5NHefa7QPAKVumTruzFaSy0ZZJwIKhF9gvK2jI3bDYs=.75ff7ebb-2a02-43be-a73f-9f5d1d7858c3@github.com>
 <Q7QUArr2orKS0ZNaxKuxjjR_uQsSEIYjrH60g0CWlL4=.a3317a3c-9663-4c3d-b36e-4c01d3c71389@github.com>
 <sCVdHaAoEYeCxUPbK3Gc80SsezGFGjFvNa6u4o27oaE=.86b18415-6b1e-45e3-a058-ca36da5c533b@github.com>
Message-ID: <Vy-mIzscWJP1FGVubB91CKAfoXdomvnYFj-j7Dh2MHQ=.dcd4c580-bdda-46cd-97f2-ff7343e209e2@github.com>

On Fri, 4 Apr 2025 20:38:08 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Maybe add class docs in the utility class

both classes have code samples to illustrate the usage - maybe insufficient.  any suggestions?

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

PR Comment: https://git.openjdk.org/jfx/pull/1746#issuecomment-2779696634

From angorya at openjdk.org  Fri Apr  4 20:46:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 20:46:55 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v6]
In-Reply-To: <Q7QUArr2orKS0ZNaxKuxjjR_uQsSEIYjrH60g0CWlL4=.a3317a3c-9663-4c3d-b36e-4c01d3c71389@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <5NHefa7QPAKVumTruzFaSy0ZZJwIKhF9gvK2jI3bDYs=.75ff7ebb-2a02-43be-a73f-9f5d1d7858c3@github.com>
 <Q7QUArr2orKS0ZNaxKuxjjR_uQsSEIYjrH60g0CWlL4=.a3317a3c-9663-4c3d-b36e-4c01d3c71389@github.com>
Message-ID: <zE8oOQw6dtKR-67y6Cf0gPQx26gj5dUaelrPB-9tabU=.1ae4be8c-5fc0-4f56-85b1-256f3b77d35a@github.com>

On Fri, 4 Apr 2025 20:24:16 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   javadoc
>
> tests/system/src/test/java/test/util/ScreenshotCapture.java line 60:
> 
>> 58:      * @throws IOException when an I/O error occurs
>> 59:      */
>> 60:     public static byte[] takeScreenshot() throws IOException {
> 
> I have no idea how to interpret this byte array. What is the use case for this method?

To save to a file, or send to a stream, for example.  This is a general purpose test utility.  The javadoc says "in PNG format".

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2029411650

From angorya at openjdk.org  Fri Apr  4 20:51:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 20:51:55 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v6]
In-Reply-To: <Q7QUArr2orKS0ZNaxKuxjjR_uQsSEIYjrH60g0CWlL4=.a3317a3c-9663-4c3d-b36e-4c01d3c71389@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <5NHefa7QPAKVumTruzFaSy0ZZJwIKhF9gvK2jI3bDYs=.75ff7ebb-2a02-43be-a73f-9f5d1d7858c3@github.com>
 <Q7QUArr2orKS0ZNaxKuxjjR_uQsSEIYjrH60g0CWlL4=.a3317a3c-9663-4c3d-b36e-4c01d3c71389@github.com>
Message-ID: <ok5jWqysLBeiBRU-8qjRBRgv9f2ZXjLT54lZXHTzDGE=.97a15526-54b1-40a3-ad66-c26b69a75064@github.com>

On Fri, 4 Apr 2025 20:28:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   javadoc
>
> tests/system/src/test/java/test/util/ScreenshotCapture.java line 107:
> 
>> 105:      * @return the screenshot in Base-64 encoded PNG, or an error message
>> 106:      */
>> 107:     public static String takeScreenshotBase64(String prefix, String postfix) {
> 
> Passing in the `data:image/png;base64,` as a prefix is odd. This method takes a screen shot and turns it into a base64-encoded PNG. Don't make the caller pass in something that has to match this internal behavior of this method. I would recommend removing the prefix and postfix entirely, and having this method return a simple base64-encoded PNG with a `data:image/png;base64,` data URL. The caller can add any other String before or after this.

I wanted to avoid creating multiple multi-megabyte strings.

The method to use is writeScreenshot(), which should be simple enough to use, it's the method mentioned at the class level javadoc.

Related: I was debating whether we should have two specific methods

writeScreenshotStdout();
writeSceeenshotStderr();

instead of passing `System:out` or `System::err`.  What do you think?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2029418685

From angorya at openjdk.org  Fri Apr  4 21:00:06 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 21:00:06 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v6]
In-Reply-To: <Q7QUArr2orKS0ZNaxKuxjjR_uQsSEIYjrH60g0CWlL4=.a3317a3c-9663-4c3d-b36e-4c01d3c71389@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <5NHefa7QPAKVumTruzFaSy0ZZJwIKhF9gvK2jI3bDYs=.75ff7ebb-2a02-43be-a73f-9f5d1d7858c3@github.com>
 <Q7QUArr2orKS0ZNaxKuxjjR_uQsSEIYjrH60g0CWlL4=.a3317a3c-9663-4c3d-b36e-4c01d3c71389@github.com>
Message-ID: <jiorVng8lWevWPguTgyU08CBKnSFtZCnF8Rucg2t3JM=.29710691-d760-4753-99ec-f384df993061@github.com>

On Fri, 4 Apr 2025 20:30:55 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   javadoc
>
> tests/system/src/test/java/test/util/ScreenshotCapture.java line 93:
> 
>> 91:      */
>> 92:     public static void writeScreenshot(PrintStream out) {
>> 93:         out.println(ScreenshotCapture.takeScreenshotBase64("Screenshot:\ndata:image/png;base64,", null));
> 
> With the change I am suggesting to `takeScreenshotBase64 `, this would become:
> 
> 
>         out.println("Screenshot:");
>         out.println(takeScreenshotBase64());
> 
> 
> That makes the `takeScreenshotBase64` API cleaner with a better separation of concerns.

The reason I have prefix and postfix instead of what you are proposing is that in my case only one event is written to the output.  This might be important when both stderr and stdout are redirected to the same log file, in which case it might produce an interleaved result.

Also, prefix/postfix allow for more flexibility, such as outputting a JSON segment like

{ screenshot:"..." }

or any other representation depending on the situation.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2029425946

From kcr at openjdk.org  Fri Apr  4 21:05:53 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 4 Apr 2025 21:05:53 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v6]
In-Reply-To: <Vy-mIzscWJP1FGVubB91CKAfoXdomvnYFj-j7Dh2MHQ=.dcd4c580-bdda-46cd-97f2-ff7343e209e2@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <5NHefa7QPAKVumTruzFaSy0ZZJwIKhF9gvK2jI3bDYs=.75ff7ebb-2a02-43be-a73f-9f5d1d7858c3@github.com>
 <Q7QUArr2orKS0ZNaxKuxjjR_uQsSEIYjrH60g0CWlL4=.a3317a3c-9663-4c3d-b36e-4c01d3c71389@github.com>
 <sCVdHaAoEYeCxUPbK3Gc80SsezGFGjFvNa6u4o27oaE=.86b18415-6b1e-45e3-a058-ca36da5c533b@github.com>
 <Vy-mIzscWJP1FGVubB91CKAfoXdomvnYFj-j7Dh2MHQ=.dcd4c580-bdda-46cd-97f2-ff7343e209e2@github.com>
Message-ID: <qcSJdqegqgiqoWe-HoijY4HvFNX3J7mnmYjdvfSNSJo=.be5e227d-cd1d-4128-9ea8-bf2b84b4f6eb@github.com>

On Fri, 4 Apr 2025 20:44:23 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > Maybe add class docs in the utility class
> 
> both classes have code samples to illustrate the usage - maybe insufficient. any suggestions?

No, I just failed to notice it. My fault.

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

PR Comment: https://git.openjdk.org/jfx/pull/1746#issuecomment-2779725749

From kcr at openjdk.org  Fri Apr  4 21:05:54 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 4 Apr 2025 21:05:54 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v6]
In-Reply-To: <zE8oOQw6dtKR-67y6Cf0gPQx26gj5dUaelrPB-9tabU=.1ae4be8c-5fc0-4f56-85b1-256f3b77d35a@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <5NHefa7QPAKVumTruzFaSy0ZZJwIKhF9gvK2jI3bDYs=.75ff7ebb-2a02-43be-a73f-9f5d1d7858c3@github.com>
 <Q7QUArr2orKS0ZNaxKuxjjR_uQsSEIYjrH60g0CWlL4=.a3317a3c-9663-4c3d-b36e-4c01d3c71389@github.com>
 <zE8oOQw6dtKR-67y6Cf0gPQx26gj5dUaelrPB-9tabU=.1ae4be8c-5fc0-4f56-85b1-256f3b77d35a@github.com>
Message-ID: <qtoweIcOFJwnbui-BqLr4Dw-vKHrjK7hlfD-YbvlmnI=.d681d467-6835-4f9c-abd5-7caa08094779@github.com>

On Fri, 4 Apr 2025 20:42:03 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> tests/system/src/test/java/test/util/ScreenshotCapture.java line 60:
>> 
>>> 58:      * @throws IOException when an I/O error occurs
>>> 59:      */
>>> 60:     public static byte[] takeScreenshot() throws IOException {
>> 
>> I have no idea how to interpret this byte array. What is the use case for this method?
>
> To save to a file, or send to a stream, for example.  This is a general purpose test utility.  The javadoc says "in PNG format".

OK, I see that now. You might say that it's a PNG in the `@return` statement (like you do for the other methods). Maybe also add ", returning it as a byte array" at the end of the first sentence?

>> tests/system/src/test/java/test/util/ScreenshotCapture.java line 107:
>> 
>>> 105:      * @return the screenshot in Base-64 encoded PNG, or an error message
>>> 106:      */
>>> 107:     public static String takeScreenshotBase64(String prefix, String postfix) {
>> 
>> Passing in the `data:image/png;base64,` as a prefix is odd. This method takes a screen shot and turns it into a base64-encoded PNG. Don't make the caller pass in something that has to match this internal behavior of this method. I would recommend removing the prefix and postfix entirely, and having this method return a simple base64-encoded PNG with a `data:image/png;base64,` data URL. The caller can add any other String before or after this.
>
> I wanted to avoid creating multiple multi-megabyte strings.
> 
> The method to use is writeScreenshot(), which should be simple enough to use, it's the method mentioned at the class level javadoc.
> 
> Related: I was debating whether we should have two specific methods
> 
> writeScreenshotStdout();
> writeSceeenshotStderr();
> 
> instead of passing `System:out` or `System::err`.  What do you think?

My suggestion doesn't change anything about how many or what size strings are allocated in the common case. All it does is moves which method tacks on the needed "data:image/png;base64," piece from the caller to the method that actually creates the PNG.

As for two methods vs one, I like the flexibility as you have it, although really only the System.err version is likely to be used (with gradle as the test runner, writing it to stdout isn't generally as useful).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2029424186
PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2029429884

From kcr at openjdk.org  Fri Apr  4 21:08:53 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 4 Apr 2025 21:08:53 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v6]
In-Reply-To: <jiorVng8lWevWPguTgyU08CBKnSFtZCnF8Rucg2t3JM=.29710691-d760-4753-99ec-f384df993061@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <5NHefa7QPAKVumTruzFaSy0ZZJwIKhF9gvK2jI3bDYs=.75ff7ebb-2a02-43be-a73f-9f5d1d7858c3@github.com>
 <Q7QUArr2orKS0ZNaxKuxjjR_uQsSEIYjrH60g0CWlL4=.a3317a3c-9663-4c3d-b36e-4c01d3c71389@github.com>
 <jiorVng8lWevWPguTgyU08CBKnSFtZCnF8Rucg2t3JM=.29710691-d760-4753-99ec-f384df993061@github.com>
Message-ID: <Ew6KT9NJEt4O3WeeBAV-D7U4OIC1rY4-MZnpFoUrke0=.2d47dde2-a4a6-4a76-bc3f-02cffd661c54@github.com>

On Fri, 4 Apr 2025 20:57:06 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> tests/system/src/test/java/test/util/ScreenshotCapture.java line 93:
>> 
>>> 91:      */
>>> 92:     public static void writeScreenshot(PrintStream out) {
>>> 93:         out.println(ScreenshotCapture.takeScreenshotBase64("Screenshot:\ndata:image/png;base64,", null));
>> 
>> With the change I am suggesting to `takeScreenshotBase64 `, this would become:
>> 
>> 
>>         out.println("Screenshot:");
>>         out.println(takeScreenshotBase64());
>> 
>> 
>> That makes the `takeScreenshotBase64` API cleaner with a better separation of concerns.
>
> The reason I have prefix and postfix instead of what you are proposing is that in my case only one event is written to the output.  This might be important when both stderr and stdout are redirected to the same log file, in which case it might produce an interleaved result.
> 
> Also, prefix/postfix allow for more flexibility, such as outputting a JSON segment like
> 
> { screenshot:"..." }
> 
> or any other representation depending on the situation.

To be clear, I agree that the caller is the one who should create the representation you show above. What I object to is having the caller pass in the first part of the data URL. That's not a clean separation of concerns.

As for whether to keep the prefix / postfix _without_ the data URL part, I don't care as much. I don't see it as needed, but it's fine if you want to keep it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2029433416

From angorya at openjdk.org  Fri Apr  4 21:15:37 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 21:15:37 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v7]
In-Reply-To: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
Message-ID: <wIuTBg14-77WQmvTsximCuC70Yc8RDnnDeHkbg1kI1s=.8a81ab2b-c42b-49b9-a468-d261706927a4@github.com>

> Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.
> 
> The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.
> 
> The log contains a base-64 encoded screenshot (like this: `data:image/png;base64,iVBORw0KGgoAAAANSUhEU...` )
> so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)
> 
> Additionally, provided a utility class to capture the screenshots at the specific point in a test and write it to stdout/stderr:
> 
> 
> // write a base-64 encoded screenshot to stderr
> ScreenshotCapture.writeScreenshot(System.err);
> 
> 
> Example:
> 
> ![jenkins-screenshot](https://github.com/user-attachments/assets/abebd76f-747a-4d6d-a9a6-63c6e9426830)

Andy Goryachev 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 17 additional commits since the last revision:

 - review comments
 - Merge remote-tracking branch 'origin/master' into 8328716.screenshots
 - javadoc
 - removed watchers
 - cleanup
 - screen capture
 - data url
 - testing: inject a failure
 - review comments
 - prefix
 - ... and 7 more: https://git.openjdk.org/jfx/compare/c5a7b213...8668ebb1

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1746/files
  - new: https://git.openjdk.org/jfx/pull/1746/files/469cd437..8668ebb1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1746&range=06
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1746&range=05-06

  Stats: 5206 lines in 101 files changed: 4529 ins; 408 del; 269 mod
  Patch: https://git.openjdk.org/jfx/pull/1746.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1746/head:pull/1746

PR: https://git.openjdk.org/jfx/pull/1746

From angorya at openjdk.org  Fri Apr  4 21:15:37 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 21:15:37 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v6]
In-Reply-To: <Ew6KT9NJEt4O3WeeBAV-D7U4OIC1rY4-MZnpFoUrke0=.2d47dde2-a4a6-4a76-bc3f-02cffd661c54@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <5NHefa7QPAKVumTruzFaSy0ZZJwIKhF9gvK2jI3bDYs=.75ff7ebb-2a02-43be-a73f-9f5d1d7858c3@github.com>
 <Q7QUArr2orKS0ZNaxKuxjjR_uQsSEIYjrH60g0CWlL4=.a3317a3c-9663-4c3d-b36e-4c01d3c71389@github.com>
 <jiorVng8lWevWPguTgyU08CBKnSFtZCnF8Rucg2t3JM=.29710691-d760-4753-99ec-f384df993061@github.com>
 <Ew6KT9NJEt4O3WeeBAV-D7U4OIC1rY4-MZnpFoUrke0=.2d47dde2-a4a6-4a76-bc3f-02cffd661c54@github.com>
Message-ID: <xs6CN_gbFwIMZgef7AAAm3EwETSbGVlWgoO94HFI59o=.116f103a-3313-4056-baee-a0e728bd1207@github.com>

On Fri, 4 Apr 2025 21:05:52 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The reason I have prefix and postfix instead of what you are proposing is that in my case only one event is written to the output.  This might be important when both stderr and stdout are redirected to the same log file, in which case it might produce an interleaved result.
>> 
>> Also, prefix/postfix allow for more flexibility, such as outputting a JSON segment like
>> 
>> { screenshot:"..." }
>> 
>> or any other representation depending on the situation.
>
> To be clear, I agree that the caller is the one who should create the representation you show above. What I object to is having the caller pass in the first part of the data URL. That's not a clean separation of concerns.
> 
> As for whether to keep the prefix / postfix _without_ the data URL part, I don't care as much. I don't see it as needed, but it's fine if you want to keep it.

hmm, not sure if I share the concern (did I understand the concern?)

the idea is to have a low-level method `takeScreenshotBase64(prefix, postfix)` that can be used in non-standard situations, but also provide the convenience method that will be used in the tests, `writeScreenshotBase64()`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2029437975

From angorya at openjdk.org  Fri Apr  4 21:23:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 21:23:55 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
Message-ID: <I_6zYygvgywbehOeeA0WmZ-gwf-W1IiB2N08S3Hnk3M=.37cc9620-63ad-4a6b-a330-bb983e25a1fd@github.com>

On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Adds code to trigger a scene update when a Window is restored
> 
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479

I can help with the testing: I have 15.3.2 with one or two external monitors.
What might help is to enumerate scenarios we want to be tested.

Do you want to address the macOS side in a separate PR?

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

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2779750496

From kcr at openjdk.org  Fri Apr  4 21:31:54 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 4 Apr 2025 21:31:54 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v6]
In-Reply-To: <xs6CN_gbFwIMZgef7AAAm3EwETSbGVlWgoO94HFI59o=.116f103a-3313-4056-baee-a0e728bd1207@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <5NHefa7QPAKVumTruzFaSy0ZZJwIKhF9gvK2jI3bDYs=.75ff7ebb-2a02-43be-a73f-9f5d1d7858c3@github.com>
 <Q7QUArr2orKS0ZNaxKuxjjR_uQsSEIYjrH60g0CWlL4=.a3317a3c-9663-4c3d-b36e-4c01d3c71389@github.com>
 <jiorVng8lWevWPguTgyU08CBKnSFtZCnF8Rucg2t3JM=.29710691-d760-4753-99ec-f384df993061@github.com>
 <Ew6KT9NJEt4O3WeeBAV-D7U4OIC1rY4-MZnpFoUrke0=.2d47dde2-a4a6-4a76-bc3f-02cffd661c54@github.com>
 <xs6CN_gbFwIMZgef7AAAm3EwETSbGVlWgoO94HFI59o=.116f103a-3313-4056-baee-a0e728bd1207@github.com>
Message-ID: <wZgZLwVYJw9Ki3jWesYCPVZt3KSkGeu0qZoWIuk_J0Y=.1fa59fc3-1f35-43e2-b5c4-4434166510fd@github.com>

On Fri, 4 Apr 2025 21:11:19 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> hmm, not sure if I share the concern (did I understand the concern?)
> 
> the idea is to have a low-level method `takeScreenshotBase64(prefix, postfix)` that can be used in non-standard situations, but also provide the convenience method that will be used in the tests, `writeScreenshotBase64()`.

That part sounds fine. However, even in non-standard situations, the caller of `takeScreenshotBase64` should not be expected to pass `"data:image/png;base64,"` to that method. It is the method itself that knows that the format is PNG, so that method should provide that part of the string when converting it to a base64 screenshot. So, for example:


    takeScreenshotBase64(null, null);  <-- returns a data URL of a base64-encoded PNG
    takeScreenshotBase64("{ screenshot:", "}"); <-- return the same with the prefix and postfix


So what I'm trying to say is that `"data:image/png;base64,"` is an integral part of the base64-encoded image, not an optional prefix that a caller must pass in.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2029457035

From angorya at openjdk.org  Fri Apr  4 21:41:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 21:41:57 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v6]
In-Reply-To: <wZgZLwVYJw9Ki3jWesYCPVZt3KSkGeu0qZoWIuk_J0Y=.1fa59fc3-1f35-43e2-b5c4-4434166510fd@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <5NHefa7QPAKVumTruzFaSy0ZZJwIKhF9gvK2jI3bDYs=.75ff7ebb-2a02-43be-a73f-9f5d1d7858c3@github.com>
 <Q7QUArr2orKS0ZNaxKuxjjR_uQsSEIYjrH60g0CWlL4=.a3317a3c-9663-4c3d-b36e-4c01d3c71389@github.com>
 <jiorVng8lWevWPguTgyU08CBKnSFtZCnF8Rucg2t3JM=.29710691-d760-4753-99ec-f384df993061@github.com>
 <Ew6KT9NJEt4O3WeeBAV-D7U4OIC1rY4-MZnpFoUrke0=.2d47dde2-a4a6-4a76-bc3f-02cffd661c54@github.com>
 <xs6CN_gbFwIMZgef7AAAm3EwETSbGVlWgoO94HFI59o=.116f103a-3313-4056-baee-a0e728bd1207@github.com>
 <wZgZLwVYJw9Ki3jWesYCPVZt3KSkGeu0qZoWIuk_J0Y=.1fa59fc3-1f35-43e2-b5c4-4434166510fd@github.com>
Message-ID: <b-CH6cU4UQtXiBwceKZ1JNrQQGglPYhCWChxcPS3xqQ=.e8dda670-59eb-41d1-a23c-5e22287e048a@github.com>

On Fri, 4 Apr 2025 21:28:59 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> hmm, not sure if I share the concern (did I understand the concern?)
>> 
>> the idea is to have a low-level method `takeScreenshotBase64(prefix, postfix)` that can be used in non-standard situations, but also provide the convenience method that will be used in the tests, `writeScreenshotBase64()`.
>
>> hmm, not sure if I share the concern (did I understand the concern?)
>> 
>> the idea is to have a low-level method `takeScreenshotBase64(prefix, postfix)` that can be used in non-standard situations, but also provide the convenience method that will be used in the tests, `writeScreenshotBase64()`.
> 
> That part sounds fine. However, even in non-standard situations, the caller of `takeScreenshotBase64` should not be expected to pass `"data:image/png;base64,"` to that method. It is the method itself that knows that the format is PNG, so that method should provide that part of the string when converting it to a base64 screenshot. So, for example:
> 
> 
>     takeScreenshotBase64(null, null);  <-- returns a data URL of a base64-encoded PNG
>     takeScreenshotBase64("{ screenshot:", "}"); <-- return the same with the prefix and postfix
> 
> 
> So what I'm trying to say is that `"data:image/png;base64,"` is an integral part of the base64-encoded image, not an optional prefix that a caller must pass in.

One thing that happened recently (in the past 10 years or so) is that JSON became a frequently used format for logs.  It's not perfect, but it's easy to parse.  With that, json-oriented log viewers came.

We don't have a consistent way to log data (or show data in `.toString()`).  A good log viewer can pretty print an object in the log file, decode a hex- or base-64 encoded string, or even run a query on a log file.

We are not ready for JSON logs, I admit, but this was the rationale behind the design of this class:

- a low-level method that returns byte[]
- a base-64 encoding method that allows for custom prefix/suffix to be able to do a data url or a json
- a convenience method to use in tests

Also, considering what you said about gradle and stderr, perhaps `writeScreenshot()` should always emit to stderr.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2029466429

From angorya at openjdk.org  Fri Apr  4 21:45:54 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 21:45:54 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v6]
In-Reply-To: <b-CH6cU4UQtXiBwceKZ1JNrQQGglPYhCWChxcPS3xqQ=.e8dda670-59eb-41d1-a23c-5e22287e048a@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <5NHefa7QPAKVumTruzFaSy0ZZJwIKhF9gvK2jI3bDYs=.75ff7ebb-2a02-43be-a73f-9f5d1d7858c3@github.com>
 <Q7QUArr2orKS0ZNaxKuxjjR_uQsSEIYjrH60g0CWlL4=.a3317a3c-9663-4c3d-b36e-4c01d3c71389@github.com>
 <jiorVng8lWevWPguTgyU08CBKnSFtZCnF8Rucg2t3JM=.29710691-d760-4753-99ec-f384df993061@github.com>
 <Ew6KT9NJEt4O3WeeBAV-D7U4OIC1rY4-MZnpFoUrke0=.2d47dde2-a4a6-4a76-bc3f-02cffd661c54@github.com>
 <xs6CN_gbFwIMZgef7AAAm3EwETSbGVlWgoO94HFI59o=.116f103a-3313-4056-baee-a0e728bd1207@github.com>
 <wZgZLwVYJw9Ki3jWesYCPVZt3KSkGeu0qZoWIuk_J0Y=.1fa59fc3-1f35-43e2-b5c4-4434166510fd@github.com>
 <b-CH6cU4UQtXiBwceKZ1JNrQQGglPYhCWChxcPS3xqQ=.e8dda670-59eb-41d1-a23c-5e22287e048a@github.com>
Message-ID: <dEqjw3QDANSzSDP2khqrWqkThwfcR1AhQt5aOTj4saQ=.c67abbf1-9dbd-4669-8442-540957238417@github.com>

On Fri, 4 Apr 2025 21:39:32 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>>> hmm, not sure if I share the concern (did I understand the concern?)
>>> 
>>> the idea is to have a low-level method `takeScreenshotBase64(prefix, postfix)` that can be used in non-standard situations, but also provide the convenience method that will be used in the tests, `writeScreenshotBase64()`.
>> 
>> That part sounds fine. However, even in non-standard situations, the caller of `takeScreenshotBase64` should not be expected to pass `"data:image/png;base64,"` to that method. It is the method itself that knows that the format is PNG, so that method should provide that part of the string when converting it to a base64 screenshot. So, for example:
>> 
>> 
>>     takeScreenshotBase64(null, null);  <-- returns a data URL of a base64-encoded PNG
>>     takeScreenshotBase64("{ screenshot:", "}"); <-- return the same with the prefix and postfix
>> 
>> 
>> So what I'm trying to say is that `"data:image/png;base64,"` is an integral part of the base64-encoded image, not an optional prefix that a caller must pass in.
>
> One thing that happened recently (in the past 10 years or so) is that JSON became a frequently used format for logs.  It's not perfect, but it's easy to parse.  With that, json-oriented log viewers came.
> 
> We don't have a consistent way to log data (or show data in `.toString()`).  A good log viewer can pretty print an object in the log file, decode a hex- or base-64 encoded string, or even run a query on a log file.
> 
> We are not ready for JSON logs, I admit, but this was the rationale behind the design of this class:
> 
> - a low-level method that returns byte[]
> - a base-64 encoding method that allows for custom prefix/suffix to be able to do a data url or a json
> - a convenience method to use in tests
> 
> Also, considering what you said about gradle and stderr, perhaps `writeScreenshot()` should always emit to stderr.

Not a "good" log viewer, but to illustrate:

![Screenshot 2025-04-04 at 14 41 54](https://github.com/user-attachments/assets/241fe4da-ae03-44bb-9766-30c86d5af94c)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2029468892

From kcr at openjdk.org  Fri Apr  4 21:45:55 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 4 Apr 2025 21:45:55 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v6]
In-Reply-To: <dEqjw3QDANSzSDP2khqrWqkThwfcR1AhQt5aOTj4saQ=.c67abbf1-9dbd-4669-8442-540957238417@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <5NHefa7QPAKVumTruzFaSy0ZZJwIKhF9gvK2jI3bDYs=.75ff7ebb-2a02-43be-a73f-9f5d1d7858c3@github.com>
 <Q7QUArr2orKS0ZNaxKuxjjR_uQsSEIYjrH60g0CWlL4=.a3317a3c-9663-4c3d-b36e-4c01d3c71389@github.com>
 <jiorVng8lWevWPguTgyU08CBKnSFtZCnF8Rucg2t3JM=.29710691-d760-4753-99ec-f384df993061@github.com>
 <Ew6KT9NJEt4O3WeeBAV-D7U4OIC1rY4-MZnpFoUrke0=.2d47dde2-a4a6-4a76-bc3f-02cffd661c54@github.com>
 <xs6CN_gbFwIMZgef7AAAm3EwETSbGVlWgoO94HFI59o=.116f103a-3313-4056-baee-a0e728bd1207@github.com>
 <wZgZLwVYJw9Ki3jWesYCPVZt3KSkGeu0qZoWIuk_J0Y=.1fa59fc3-1f35-43e2-b5c4-4434166510fd@github.com>
 <b-CH6cU4UQtXiBwceKZ1JNrQQGglPYhCWChxcPS3xqQ=.e8dda670-59eb-41d1-a23c-5e22287e048a@github.com>
 <dEqjw3QDANSzSDP2khqrWqkThwfcR1AhQt5aOTj4saQ=.c67abbf1-9dbd-4669-8442-540957238417@github.com>
Message-ID: <aojDHvbAAK2BEIOhlj9pkDGRnkrUPWmueMgh00P2B8Q=.3ca3dfa7-4b19-421d-ae2d-a8d3e4cd754f@github.com>

On Fri, 4 Apr 2025 21:42:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> One thing that happened recently (in the past 10 years or so) is that JSON became a frequently used format for logs.  It's not perfect, but it's easy to parse.  With that, json-oriented log viewers came.
>> 
>> We don't have a consistent way to log data (or show data in `.toString()`).  A good log viewer can pretty print an object in the log file, decode a hex- or base-64 encoded string, or even run a query on a log file.
>> 
>> We are not ready for JSON logs, I admit, but this was the rationale behind the design of this class:
>> 
>> - a low-level method that returns byte[]
>> - a base-64 encoding method that allows for custom prefix/suffix to be able to do a data url or a json
>> - a convenience method to use in tests
>> 
>> Also, considering what you said about gradle and stderr, perhaps `writeScreenshot()` should always emit to stderr.
>
> Not a "good" log viewer, but to illustrate:
> 
> ![Screenshot 2025-04-04 at 14 41 54](https://github.com/user-attachments/assets/241fe4da-ae03-44bb-9766-30c86d5af94c)

> We are not ready for JSON logs, I admit, but this was the rationale behind the design of this class:
> 
> * a low-level method that returns byte[]
> * a base-64 encoding method that allows for custom prefix/suffix to be able to do a data url or a json
> * a convenience method to use in tests

Are you saying that in a JSON image, you wouldn't have the `""data:image/png;base64,"` prefix?

> Also, considering what you said about gradle and stderr, perhaps `writeScreenshot()` should always emit to stderr.

That seems reasonable. We can always add an overload that takes a PrintStream if needed later.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2029469689

From angorya at openjdk.org  Fri Apr  4 21:55:09 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 21:55:09 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v8]
In-Reply-To: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
Message-ID: <-uGZG3FuoYcaWykFAg0d9dcqW1UavHow6HafJj9GOis=.0a9cc73c-6c51-47cb-9bda-ec6510963c0f@github.com>

> Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.
> 
> The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.
> 
> The log contains a base-64 encoded screenshot (like this: `data:image/png;base64,iVBORw0KGgoAAAANSUhEU...` )
> so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)
> 
> Additionally, provided a utility class to capture the screenshots at the specific point in a test and write it to stdout/stderr:
> 
> 
> // write a base-64 encoded screenshot to stderr
> ScreenshotCapture.writeScreenshot(System.err);
> 
> 
> Example:
> 
> ![jenkins-screenshot](https://github.com/user-attachments/assets/abebd76f-747a-4d6d-a9a6-63c6e9426830)

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  stderr

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1746/files
  - new: https://git.openjdk.org/jfx/pull/1746/files/8668ebb1..96187a01

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1746&range=07
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1746&range=06-07

  Stats: 8 lines in 2 files changed: 0 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jfx/pull/1746.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1746/head:pull/1746

PR: https://git.openjdk.org/jfx/pull/1746

From kcr at openjdk.org  Fri Apr  4 21:55:09 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 4 Apr 2025 21:55:09 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v7]
In-Reply-To: <wIuTBg14-77WQmvTsximCuC70Yc8RDnnDeHkbg1kI1s=.8a81ab2b-c42b-49b9-a468-d261706927a4@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <wIuTBg14-77WQmvTsximCuC70Yc8RDnnDeHkbg1kI1s=.8a81ab2b-c42b-49b9-a468-d261706927a4@github.com>
Message-ID: <wUALo20nFpBPDgc70-ZTm54De0slhWbh3XOf2QaXrOU=.60ee2ee6-64a2-4949-b4ac-888a59fa2fb0@github.com>

On Fri, 4 Apr 2025 21:15:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.
>> 
>> The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.
>> 
>> The log contains a base-64 encoded screenshot (like this: `data:image/png;base64,iVBORw0KGgoAAAANSUhEU...` )
>> so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)
>> 
>> Additionally, provided a utility class to capture the screenshots at the specific point in a test and write it to stdout/stderr:
>> 
>> 
>> // write a base-64 encoded screenshot to stderr
>> ScreenshotCapture.writeScreenshot(System.err);
>> 
>> 
>> Example:
>> 
>> ![jenkins-screenshot](https://github.com/user-attachments/assets/abebd76f-747a-4d6d-a9a6-63c6e9426830)
>
> Andy Goryachev 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 17 additional commits since the last revision:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8328716.screenshots
>  - javadoc
>  - removed watchers
>  - cleanup
>  - screen capture
>  - data url
>  - testing: inject a failure
>  - review comments
>  - prefix
>  - ... and 7 more: https://git.openjdk.org/jfx/compare/30e49d53...8668ebb1

I'll do a quick re-test then approve.

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

PR Comment: https://git.openjdk.org/jfx/pull/1746#issuecomment-2779787527

From angorya at openjdk.org  Fri Apr  4 21:55:09 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 21:55:09 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v7]
In-Reply-To: <wIuTBg14-77WQmvTsximCuC70Yc8RDnnDeHkbg1kI1s=.8a81ab2b-c42b-49b9-a468-d261706927a4@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <wIuTBg14-77WQmvTsximCuC70Yc8RDnnDeHkbg1kI1s=.8a81ab2b-c42b-49b9-a468-d261706927a4@github.com>
Message-ID: <5-UsmTpye3FelCh5LWD6elPApaOmRZcl0-3YR20xRGk=.8ebaa24b-1543-42b8-bbfe-6530257a8938@github.com>

On Fri, 4 Apr 2025 21:15:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.
>> 
>> The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.
>> 
>> The log contains a base-64 encoded screenshot (like this: `data:image/png;base64,iVBORw0KGgoAAAANSUhEU...` )
>> so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)
>> 
>> Additionally, provided a utility class to capture the screenshots at the specific point in a test and write it to stdout/stderr:
>> 
>> 
>> // write a base-64 encoded screenshot to stderr
>> ScreenshotCapture.writeScreenshot(System.err);
>> 
>> 
>> Example:
>> 
>> ![jenkins-screenshot](https://github.com/user-attachments/assets/abebd76f-747a-4d6d-a9a6-63c6e9426830)
>
> Andy Goryachev 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 17 additional commits since the last revision:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8328716.screenshots
>  - javadoc
>  - removed watchers
>  - cleanup
>  - screen capture
>  - data url
>  - testing: inject a failure
>  - review comments
>  - prefix
>  - ... and 7 more: https://git.openjdk.org/jfx/compare/30e49d53...8668ebb1

Thank you for an interesting discussion!

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

PR Comment: https://git.openjdk.org/jfx/pull/1746#issuecomment-2779789427

From angorya at openjdk.org  Fri Apr  4 21:55:10 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 21:55:10 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v6]
In-Reply-To: <aojDHvbAAK2BEIOhlj9pkDGRnkrUPWmueMgh00P2B8Q=.3ca3dfa7-4b19-421d-ae2d-a8d3e4cd754f@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <5NHefa7QPAKVumTruzFaSy0ZZJwIKhF9gvK2jI3bDYs=.75ff7ebb-2a02-43be-a73f-9f5d1d7858c3@github.com>
 <Q7QUArr2orKS0ZNaxKuxjjR_uQsSEIYjrH60g0CWlL4=.a3317a3c-9663-4c3d-b36e-4c01d3c71389@github.com>
 <jiorVng8lWevWPguTgyU08CBKnSFtZCnF8Rucg2t3JM=.29710691-d760-4753-99ec-f384df993061@github.com>
 <Ew6KT9NJEt4O3WeeBAV-D7U4OIC1rY4-MZnpFoUrke0=.2d47dde2-a4a6-4a76-bc3f-02cffd661c54@github.com>
 <xs6CN_gbFwIMZgef7AAAm3EwETSbGVlWgoO94HFI59o=.116f103a-3313-4056-baee-a0e728bd1207@github.com>
 <wZgZLwVYJw9Ki3jWesYCPVZt3KSkGeu0qZoWIuk_J0Y=.1fa59fc3-1f35-43e2-b5c4-4434166510fd@github.com>
 <b-CH6cU4UQtXiBwceKZ1JNrQQGglPYhCWChxcPS3xqQ=.e8dda670-59eb-41d1-a23c-5e22287e048a@github.com>
 <dEqjw3QDANSzSDP2khqrWqkThwfcR1AhQt5aOTj4saQ=.c67abbf1-9dbd-4669-8442-540957238417@github.com>
 <aojDHvbAAK2BEIOhlj9pkDGRnkrUPWmueMgh00P2B8Q=.3ca3dfa7-4b19-421d-ae2d-a8d3e4cd754f@github.com>
Message-ID: <jzUKfzkbNUbfcgJBWwzoIMyfEESTeaFl9OmjuRa5ps0=.45068d06-4db3-49c5-8035-50ecbe60d468@github.com>

On Fri, 4 Apr 2025 21:43:41 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> in a JSON image, you wouldn't have the `""data:image/png;base64,"` prefix?

correct, the prefix would be something else, like
`takeScreenshotBase64("{screenshot:","}");`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2029471358

From kcr at openjdk.org  Fri Apr  4 21:55:10 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 4 Apr 2025 21:55:10 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v6]
In-Reply-To: <jzUKfzkbNUbfcgJBWwzoIMyfEESTeaFl9OmjuRa5ps0=.45068d06-4db3-49c5-8035-50ecbe60d468@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <5NHefa7QPAKVumTruzFaSy0ZZJwIKhF9gvK2jI3bDYs=.75ff7ebb-2a02-43be-a73f-9f5d1d7858c3@github.com>
 <Q7QUArr2orKS0ZNaxKuxjjR_uQsSEIYjrH60g0CWlL4=.a3317a3c-9663-4c3d-b36e-4c01d3c71389@github.com>
 <jiorVng8lWevWPguTgyU08CBKnSFtZCnF8Rucg2t3JM=.29710691-d760-4753-99ec-f384df993061@github.com>
 <Ew6KT9NJEt4O3WeeBAV-D7U4OIC1rY4-MZnpFoUrke0=.2d47dde2-a4a6-4a76-bc3f-02cffd661c54@github.com>
 <xs6CN_gbFwIMZgef7AAAm3EwETSbGVlWgoO94HFI59o=.116f103a-3313-4056-baee-a0e728bd1207@github.com>
 <wZgZLwVYJw9Ki3jWesYCPVZt3KSkGeu0qZoWIuk_J0Y=.1fa59fc3-1f35-43e2-b5c4-4434166510fd@github.com>
 <b-CH6cU4UQtXiBwceKZ1JNrQQGglPYhCWChxcPS3xqQ=.e8dda670-59eb-41d1-a23c-5e22287e048a@github.com>
 <dEqjw3QDANSzSDP2khqrWqkThwfcR1AhQt5aOTj4saQ=.c67abbf1-9dbd-4669-8442-540957238417@github.com>
 <aojDHvbAAK2BEIOhlj9pkDGRnkrUPWmueMgh00P2B8Q=.3ca3dfa7-4b19-421d-ae2d-a8d3e4cd754f@github.com>
 <jzUKfzkbNUbfcgJBWwzoIMyfEESTeaFl9Om
 juRa5ps0=.45068d06-4db3-49c5-8035-50ecbe60d468@github.com>
Message-ID: <L-NGq6jQse5yoBS8v10Cpu2y9HJGn_b6hVWP_ynNBlc=.d0b19901-f5af-4e53-ac2a-583d18186a4d@github.com>

On Fri, 4 Apr 2025 21:46:02 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>>> We are not ready for JSON logs, I admit, but this was the rationale behind the design of this class:
>>> 
>>> * a low-level method that returns byte[]
>>> * a base-64 encoding method that allows for custom prefix/suffix to be able to do a data url or a json
>>> * a convenience method to use in tests
>> 
>> Are you saying that in a JSON image, you wouldn't have the `""data:image/png;base64,"` prefix?
>> 
>>> Also, considering what you said about gradle and stderr, perhaps `writeScreenshot()` should always emit to stderr.
>> 
>> That seems reasonable. We can always add an overload that takes a PrintStream if needed later.
>
>> in a JSON image, you wouldn't have the `""data:image/png;base64,"` prefix?
> 
> correct, the prefix would be something else, like
> `takeScreenshotBase64("{screenshot:","}");`

Are you sure? How would it know it was PNG (and not JPG or BMP)?

In any case, if there is a possibility that the caller might not want the base64-encoded image to always be prefixed with "data:image/png;base64," then passing it in is OK. Honestly, though, this is a test utility, so I don't image it will ever get used.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2029473255

From kcr at openjdk.org  Fri Apr  4 22:11:58 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 4 Apr 2025 22:11:58 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v8]
In-Reply-To: <-uGZG3FuoYcaWykFAg0d9dcqW1UavHow6HafJj9GOis=.0a9cc73c-6c51-47cb-9bda-ec6510963c0f@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <-uGZG3FuoYcaWykFAg0d9dcqW1UavHow6HafJj9GOis=.0a9cc73c-6c51-47cb-9bda-ec6510963c0f@github.com>
Message-ID: <yyBpNz5-zjKqXaC_YR1Ydd1hsJvbH4I5SqBDKjVrdpo=.268f757f-d407-4bcc-9763-44a544b494e7@github.com>

On Fri, 4 Apr 2025 21:55:09 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.
>> 
>> The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.
>> 
>> The log contains a base-64 encoded screenshot (like this: `data:image/png;base64,iVBORw0KGgoAAAANSUhEU...` )
>> so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)
>> 
>> Additionally, provided a utility class to capture the screenshots at the specific point in a test and write it to stdout/stderr:
>> 
>> 
>> // write a base-64 encoded screenshot to stderr
>> ScreenshotCapture.writeScreenshot(System.err);
>> 
>> 
>> Example:
>> 
>> ![jenkins-screenshot](https://github.com/user-attachments/assets/abebd76f-747a-4d6d-a9a6-63c6e9426830)
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stderr

LGTM with one very minor comment on a comment. I'll reapprove if you fix.

tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 45:

> 43:     @Override
> 44:     public void testFailed(ExtensionContext extensionContext, Throwable err) {
> 45:         // the data url can be pasted into Safari address bar to view the screenshot

Minor: "Safari" --> "a browser".

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1746#pullrequestreview-2744166071
PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2029475138

From kcr at openjdk.org  Fri Apr  4 22:11:59 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 4 Apr 2025 22:11:59 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v8]
In-Reply-To: <yyBpNz5-zjKqXaC_YR1Ydd1hsJvbH4I5SqBDKjVrdpo=.268f757f-d407-4bcc-9763-44a544b494e7@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <-uGZG3FuoYcaWykFAg0d9dcqW1UavHow6HafJj9GOis=.0a9cc73c-6c51-47cb-9bda-ec6510963c0f@github.com>
 <yyBpNz5-zjKqXaC_YR1Ydd1hsJvbH4I5SqBDKjVrdpo=.268f757f-d407-4bcc-9763-44a544b494e7@github.com>
Message-ID: <9XKVyHOvgCw0bRxGMyZsSQ4kHknJNpFMcoNAFr1hDic=.b130ac2e-83a7-4855-8bf0-734f77058f16@github.com>

On Fri, 4 Apr 2025 21:51:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   stderr
>
> tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 45:
> 
>> 43:     @Override
>> 44:     public void testFailed(ExtensionContext extensionContext, Throwable err) {
>> 45:         // the data url can be pasted into Safari address bar to view the screenshot
> 
> Minor: "Safari" --> "a browser".

Although apparently not Chrome. :)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2029488837

From angorya at openjdk.org  Fri Apr  4 22:11:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 22:11:59 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v8]
In-Reply-To: <9XKVyHOvgCw0bRxGMyZsSQ4kHknJNpFMcoNAFr1hDic=.b130ac2e-83a7-4855-8bf0-734f77058f16@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <-uGZG3FuoYcaWykFAg0d9dcqW1UavHow6HafJj9GOis=.0a9cc73c-6c51-47cb-9bda-ec6510963c0f@github.com>
 <yyBpNz5-zjKqXaC_YR1Ydd1hsJvbH4I5SqBDKjVrdpo=.268f757f-d407-4bcc-9763-44a544b494e7@github.com>
 <9XKVyHOvgCw0bRxGMyZsSQ4kHknJNpFMcoNAFr1hDic=.b130ac2e-83a7-4855-8bf0-734f77058f16@github.com>
Message-ID: <bbVic3u4Njt0zKqr6T4bjnIN0alMntXpzSPXDiwig2Y=.bd37ff46-5869-4871-b4cc-75444a2afb57@github.com>

On Fri, 4 Apr 2025 22:07:22 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 45:
>> 
>>> 43:     @Override
>>> 44:     public void testFailed(ExtensionContext extensionContext, Throwable err) {
>>> 45:         // the data url can be pasted into Safari address bar to view the screenshot
>> 
>> Minor: "Safari" --> "a browser".
>
> Although apparently not Chrome. :)

Actually, Safari is the browser which will show the complete screenshot.  Chrome will only show a truncated screenshot, and I don't have Firefox to test.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2029489312

From angorya at openjdk.org  Fri Apr  4 22:11:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 22:11:59 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v8]
In-Reply-To: <bbVic3u4Njt0zKqr6T4bjnIN0alMntXpzSPXDiwig2Y=.bd37ff46-5869-4871-b4cc-75444a2afb57@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <-uGZG3FuoYcaWykFAg0d9dcqW1UavHow6HafJj9GOis=.0a9cc73c-6c51-47cb-9bda-ec6510963c0f@github.com>
 <yyBpNz5-zjKqXaC_YR1Ydd1hsJvbH4I5SqBDKjVrdpo=.268f757f-d407-4bcc-9763-44a544b494e7@github.com>
 <9XKVyHOvgCw0bRxGMyZsSQ4kHknJNpFMcoNAFr1hDic=.b130ac2e-83a7-4855-8bf0-734f77058f16@github.com>
 <bbVic3u4Njt0zKqr6T4bjnIN0alMntXpzSPXDiwig2Y=.bd37ff46-5869-4871-b4cc-75444a2afb57@github.com>
Message-ID: <KkE_6Jj7RIoC-H0NMfO4hG03iOEsnkYxIWEbSm_fGnw=.5a40c53d-c416-4867-a12b-395553f24f34@github.com>

On Fri, 4 Apr 2025 22:08:09 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Although apparently not Chrome. :)
>
> Actually, Safari is the browser which will show the complete screenshot.  Chrome will only show a truncated screenshot, and I don't have Firefox to test.

I was planning to add a decoding tool to the MonkeyTester anyway.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2029490391

From kcr at openjdk.org  Fri Apr  4 22:17:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 4 Apr 2025 22:17:52 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v8]
In-Reply-To: <KkE_6Jj7RIoC-H0NMfO4hG03iOEsnkYxIWEbSm_fGnw=.5a40c53d-c416-4867-a12b-395553f24f34@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <-uGZG3FuoYcaWykFAg0d9dcqW1UavHow6HafJj9GOis=.0a9cc73c-6c51-47cb-9bda-ec6510963c0f@github.com>
 <yyBpNz5-zjKqXaC_YR1Ydd1hsJvbH4I5SqBDKjVrdpo=.268f757f-d407-4bcc-9763-44a544b494e7@github.com>
 <9XKVyHOvgCw0bRxGMyZsSQ4kHknJNpFMcoNAFr1hDic=.b130ac2e-83a7-4855-8bf0-734f77058f16@github.com>
 <bbVic3u4Njt0zKqr6T4bjnIN0alMntXpzSPXDiwig2Y=.bd37ff46-5869-4871-b4cc-75444a2afb57@github.com>
 <KkE_6Jj7RIoC-H0NMfO4hG03iOEsnkYxIWEbSm_fGnw=.5a40c53d-c416-4867-a12b-395553f24f34@github.com>
Message-ID: <2WbfgkJduZcs4SiJhb1gAk6v1BoIO2ks3Qh2JsjrhfA=.1815f3e9-564e-4621-acae-74eff90631fa@github.com>

On Fri, 4 Apr 2025 22:09:46 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Actually, Safari is the browser which will show the complete screenshot.  Chrome will only show a truncated screenshot, and I don't have Firefox to test.
>
> I was planning to add a decoding tool to the MonkeyTester anyway.

> Actually, Safari is the browser which will show the complete screenshot. Chrome will only show a truncated screenshot, and I don't have Firefox to test.

I did all my testing on Firefox, both Windows and macOS. It also works. Chrome truncates it so small that it is useless.

> I was planning to add a decoding tool to the MonkeyTester anyway.

Good.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2029493764

From kcr at openjdk.org  Fri Apr  4 22:20:56 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 4 Apr 2025 22:20:56 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v8]
In-Reply-To: <-uGZG3FuoYcaWykFAg0d9dcqW1UavHow6HafJj9GOis=.0a9cc73c-6c51-47cb-9bda-ec6510963c0f@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <-uGZG3FuoYcaWykFAg0d9dcqW1UavHow6HafJj9GOis=.0a9cc73c-6c51-47cb-9bda-ec6510963c0f@github.com>
Message-ID: <YJUB3ohW7Ybb4q218-zKrQXnnIHp0ieX7dR7fLjZ_DQ=.0db0f88e-5bfb-4605-befb-4287a870fa86@github.com>

On Fri, 4 Apr 2025 21:55:09 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.
>> 
>> The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.
>> 
>> The log contains a base-64 encoded screenshot (like this: `data:image/png;base64,iVBORw0KGgoAAAANSUhEU...` )
>> so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)
>> 
>> Additionally, provided a utility class to capture the screenshots at the specific point in a test and write it to stdout/stderr:
>> 
>> 
>> // write a base-64 encoded screenshot to stderr
>> ScreenshotCapture.writeScreenshot(System.err);
>> 
>> 
>> Example:
>> 
>> ![jenkins-screenshot](https://github.com/user-attachments/assets/abebd76f-747a-4d6d-a9a6-63c6e9426830)
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stderr

Since this is now just an optional test utility for debugging, and isn't wired up to anything, it doesn't need two reviewers.

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

PR Comment: https://git.openjdk.org/jfx/pull/1746#issuecomment-2779818094

From angorya at openjdk.org  Fri Apr  4 22:24:00 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 4 Apr 2025 22:24:00 GMT
Subject: Integrated: 8328716: [TestBug] Screen capturing utility for failed
 tests
In-Reply-To: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
Message-ID: <9G9Hp4XEsDlLp7_7CZHkWE6wisVjM9vTodv7wbBIw5A=.9336b770-ef95-48e7-ae2b-3c751f38efc6@github.com>

On Fri, 28 Mar 2025 18:22:56 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.
> 
> The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.
> 
> The log contains a base-64 encoded screenshot (like this: `data:image/png;base64,iVBORw0KGgoAAAANSUhEU...` )
> so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)
> 
> Additionally, provided a utility class to capture the screenshots at the specific point in a test and write it to stdout/stderr:
> 
> 
> // write a base-64 encoded screenshot to stderr
> ScreenshotCapture.writeScreenshot(System.err);
> 
> 
> Example:
> 
> ![jenkins-screenshot](https://github.com/user-attachments/assets/abebd76f-747a-4d6d-a9a6-63c6e9426830)

This pull request has now been integrated.

Changeset: f31d00d8
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/f31d00d8f7e601c3bb28a9975dd029390ec92173
Stats:     320 lines in 4 files changed: 203 ins; 117 del; 0 mod

8328716: [TestBug] Screen capturing utility for failed tests

Reviewed-by: kcr

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

PR: https://git.openjdk.org/jfx/pull/1746

From mfox at openjdk.org  Fri Apr  4 22:40:53 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 4 Apr 2025 22:40:53 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <I_6zYygvgywbehOeeA0WmZ-gwf-W1IiB2N08S3Hnk3M=.37cc9620-63ad-4a6b-a330-bb983e25a1fd@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
 <I_6zYygvgywbehOeeA0WmZ-gwf-W1IiB2N08S3Hnk3M=.37cc9620-63ad-4a6b-a330-bb983e25a1fd@github.com>
Message-ID: <zIuZ-Va7sHqooRLJiE1z3w9o5-U7xqR_vzyjzbNQB7o=.066a5928-7fa2-4121-8ced-49cd38c87105@github.com>

On Fri, 4 Apr 2025 21:20:15 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> I can help with the testing: I have 15.3.2 with one or two external monitors. What might help is to enumerate scenarios we want to be tested.

Thanks for the offer. I'm also running 15.3.2. I suspect I'll have to try test on an older version of the OS to avoid all those unexpected screen change notifications.

> Do you want to address the macOS side in a separate PR?

Maybe? It's clear that someone needs to call `entireSceneNeedsRepaint` to trigger the redraw. Currently there are many places in the core code that do this (for example, when the window's size changes). So maybe this is just another instance where the core should handle it. In that case it could be folded into this PR.

The alternative is to update the Mac glass code to more closely match what Windows and Linux are doing. In that case it should be a separate PR. But it's beginning to look like notifyPaint is sort of vestigial. Outside of this bug the Mac is just fine not calling it because the core handles everything internally.

>From my newbie perspective it looks like this is just another area where the core code should be calling `entireSceneNeedsRepaint`. But this is not an area I'm familiar with.

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

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2779843647

From credmond at certak.com  Fri Apr  4 23:59:36 2025
From: credmond at certak.com (Cormac Redmond)
Date: Sat, 5 Apr 2025 00:59:36 +0100
Subject: TabPane overflow menu showing blanks
Message-ID: <CAGBnJPt_7_sJq8rX3fENXt3LU2=BZ5xN2mHy5L0gPd3fpFjyww@mail.gmail.com>

Hi,

TabPane tabs allow you to set graphic nodes as the header and there appears
to be no documented limitations or best-practises on this.

You might assume it's perfectly reasonable to not set a Tab's text value,
and instead set the header as a HBox, consisting of a graphic node (left)
and a Label (itself with a text + a graphic, right), to achieve an
icon-text-icon style header, which is not an uncommon.

However, the overflow menu, when it kicks in, will not display any text or
graphics at all (just a blank space), if your Tab has no "text" set, and
the header graphic is not a Label or an ImageView.

It's down to this self-confessed hacky code (
https://github.com/openjdk/jfx/blob/f31d00d8f7e601c3bb28a9975dd029390ec92173/modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java#L479
):

    /**
     * VERY HACKY - this lets us 'duplicate' Label and ImageView nodes to
be used in a
     * Tab and the tabs menu at the same time.
     */
    private static Node clone(Node n) {
        if (n == null) {
            return null;
        }
        if (n instanceof ImageView) {
            ImageView iv = (ImageView) n;
            ImageView imageview = new ImageView();
            imageview.imageProperty().bind(iv.imageProperty());
            return imageview;
        }
        if (n instanceof Label) {
            Label l = (Label)n;
            Label label = new Label(l.getText(), clone(l.getGraphic()));
            label.textProperty().bind(l.textProperty());
            return label;
        }
        return null;
    }


It is not obvious at all that this is what's going to happen, or why. And
it seems impossible to control or influence this in any reasonable way,
without replacing the whole TabPaneSkin.

Given TabPane is one of the most important and widely used controls there
is, there could/should be some of the following:

   - Proper documentation on this limitation / behaviour
   - Some way to set fallback text that can be used in the menu (i.e., that
   isn't the Tab's header's text, because one might intentionally avoid
   setting that given there's no way to hide it from the tab header)
   - Or, better yet, some way to allow you to specify tab header text
   without displaying it in the actual tab header, which could then be used by
   the hacky method as normal
   - Some way to set a callback so the developer can decide what gets
   displayed for the overflow menu
   - Some way to override the skin without needing a full copy + paste +
   rename
   - Some way to allow the dev to disable the overflow menu, if it's going
   to produce something unusable. E.g., prefer no menu than a buggy one...


I would view this as a bug, even though it's probably been like this
forever.


Some sample code to demonstrate; just look at the menu:

public class TabPaneMenu extends Application {
    @Override
    public void start(Stage primaryStage) {
        TabPane tabPane = new TabPane();

        for (int i = 1; i <= 30; i++) {
            Tab tab;
            if (i == 2) {
                tab = new Tab();
                final Label label = new Label("HBox Tab " + i);
                final HBox hBox = new HBox(label); // Will show as blank in
overflow menu!
                tab.setGraphic(hBox);
            } else if (i == 5) {
                tab = new Tab();
                tab.setGraphic(new Label("Label Tab " + i)); // Will show
in overflow menu, because it's a Label
            } else {
                tab = new Tab("Normal Tab " + i);
            }

            tab.setContent(new StackPane(new Label("This is Tab " + i)));
            tab.setClosable(false);
            tabPane.getTabs().add(tab);

        }

        Scene scene = new Scene(tabPane, 800, 600);
        primaryStage.setScene(scene);
        primaryStage.show();
    }

    public static void main(String[] args) {
        launch(args);
    }
}


Kind Regards,

*Cormac Redmond*
Software Engineer, Certak Ltd.

e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250405/f814c5a2/attachment-0001.htm>

From jbhaskar at openjdk.org  Sat Apr  5 05:27:40 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Sat, 5 Apr 2025 05:27:40 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
 [v6]
In-Reply-To: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
Message-ID: <JFWceI-5sfoGUy40e_PgUcExHty6540qr2GLPdS5PoA=.8034bbfc-fb0d-49e9-aab0-bde152e959f4@github.com>

> Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.

Jay Bhaskar has updated the pull request incrementally with two additional commits since the last revision:

 - remove whitespace
 - change according to review

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1759/files
  - new: https://git.openjdk.org/jfx/pull/1759/files/76686013..1a5cdf51

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1759&range=05
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1759&range=04-05

  Stats: 406 lines in 7 files changed: 135 ins; 176 del; 95 mod
  Patch: https://git.openjdk.org/jfx/pull/1759.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1759/head:pull/1759

PR: https://git.openjdk.org/jfx/pull/1759

From jbhaskar at openjdk.org  Sat Apr  5 05:27:40 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Sat, 5 Apr 2025 05:27:40 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
 [v4]
In-Reply-To: <yyBDdiK_7FFwCNe1Jb_38qObkB3ggB6Jl4ovol_6DvM=.5b0f8cf8-13a0-45ed-bf04-1d2f702be86f@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
 <zmcMPx3_xbFTT8bfcswV1I_RqIklLepFO32lQJfOCiE=.0a5e39b0-42bc-4f5f-a980-5271412f42f7@github.com>
 <yyBDdiK_7FFwCNe1Jb_38qObkB3ggB6Jl4ovol_6DvM=.5b0f8cf8-13a0-45ed-bf04-1d2f702be86f@github.com>
Message-ID: <U0KblEQf4V8wsciw83zrRG5lplnqRWwraXYF-HXk-kM=.1658233a-5f29-44b6-8892-1a1072fcdbae@github.com>

On Fri, 4 Apr 2025 17:04:26 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Jay Bhaskar 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 five additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into juni5bastest
>>  - missing review change and remove trailing white space
>>  - simplify test setup according to review
>>  - remove trailing white space
>>  - 8340464: [TestBug] Convert parametrized base tests to JUnit 5
>
> modules/javafx.base/src/test/java/test/javafx/util/converter/DateStringConverterTest.java line 108:
> 
> 
> what was the reason for this code (LL108 - 114) removal?
> and for the removal of the tests from L136?
> 
> this removal also makes `private DateFormat validFormatter;` unused

re-written entire test gain according others

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2029705711

From jbhaskar at openjdk.org  Sat Apr  5 05:27:41 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Sat, 5 Apr 2025 05:27:41 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
 [v6]
In-Reply-To: <yyBDdiK_7FFwCNe1Jb_38qObkB3ggB6Jl4ovol_6DvM=.5b0f8cf8-13a0-45ed-bf04-1d2f702be86f@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
 <zmcMPx3_xbFTT8bfcswV1I_RqIklLepFO32lQJfOCiE=.0a5e39b0-42bc-4f5f-a980-5271412f42f7@github.com>
 <yyBDdiK_7FFwCNe1Jb_38qObkB3ggB6Jl4ovol_6DvM=.5b0f8cf8-13a0-45ed-bf04-1d2f702be86f@github.com>
Message-ID: <uLIph-LfT_xpCzoU2IZMuoHQ9ywcytDpKYi7iZliW8g=.a822d547-9897-4aee-92e0-56bcf31c432e@github.com>

On Fri, 4 Apr 2025 17:09:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Jay Bhaskar has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove whitespace
>>  - change according to review
>
> modules/javafx.base/src/test/java/test/javafx/util/converter/DateTimeStringConverterTest.java line 104:
> 
>> 102:     private DateFormat validFormatter;
>> 103: 
>> 104:     public DateTimeStringConverterTest(DateTimeStringConverter converter, Locale locale, int dateStyle, int timeStyle, Date validDate, String pattern, DateFormat dateFormat) {
> 
> Is there a reason you did not follow the conversion pattern using setup() method?
> I think the test is mangled now.  Could you please double check?

used paametrized setup

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2029705941

From jbhaskar at openjdk.org  Sat Apr  5 05:27:41 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Sat, 5 Apr 2025 05:27:41 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
 [v5]
In-Reply-To: <yyBDdiK_7FFwCNe1Jb_38qObkB3ggB6Jl4ovol_6DvM=.5b0f8cf8-13a0-45ed-bf04-1d2f702be86f@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
 <zmcMPx3_xbFTT8bfcswV1I_RqIklLepFO32lQJfOCiE=.0a5e39b0-42bc-4f5f-a980-5271412f42f7@github.com>
 <yyBDdiK_7FFwCNe1Jb_38qObkB3ggB6Jl4ovol_6DvM=.5b0f8cf8-13a0-45ed-bf04-1d2f702be86f@github.com>
Message-ID: <Eil0A1lPk1H7XYr0V3f9ya8GfJkwt0LSrAXUSCdqEwc=.b628b611-2158-452c-8912-8ec4098d8c18@github.com>

On Fri, 4 Apr 2025 17:08:25 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   re-order imports
>
> modules/javafx.base/src/test/java/test/javafx/util/converter/DateTimeStringConverterTest.java line 216:
> 
>> 214:             DateFormat dateFormat = DateTimeStringConverterShim.getDateFormatVar(converter);
>> 215:             assertNotNull(dateFormat);
>> 216:         }
> 
> please double-check: the code LL213-L126 looks misplaced here.  it used to be a part of the constructor, and in this case should probably precede the assertions.

re-written test according to others

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2029705858

From mstrauss at openjdk.org  Sat Apr  5 07:34:23 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 5 Apr 2025 07:34:23 GMT
Subject: RFR: 8345348: CSS Media Queries [v7]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <ze6kVmnynkzwDaug8DYV5UnVCLsFOd1mU7IB_FRlapE=.3877a6a6-fce8-4f51-a3b8-0d2a40670a2d@github.com>

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  small refactor

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/e214d5cc..7826fc18

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=06
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=05-06

  Stats: 30 lines in 5 files changed: 19 ins; 6 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1655.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655

PR: https://git.openjdk.org/jfx/pull/1655

From mstrauss at openjdk.org  Sat Apr  5 07:39:53 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 5 Apr 2025 07:39:53 GMT
Subject: RFR: 8234153: [TEST_BUG] Rewrite Popup_parentWindow_Test
In-Reply-To: <pNrmBuQ8R1EgzyV-DyCkRR4B0-XPynZorQVzlDTddLY=.d132d590-95dd-42c6-9d66-10478ba875e7@github.com>
References: <7bf72skQqQkaixdRyiilnIW35lkXC_X3GzbSNt9ot0U=.256071a4-e230-4e5e-9e97-aad6f614e01b@github.com>
 <pNrmBuQ8R1EgzyV-DyCkRR4B0-XPynZorQVzlDTddLY=.d132d590-95dd-42c6-9d66-10478ba875e7@github.com>
Message-ID: <OJknotyyMHHFYNQKUuEZz4eHBCU-0RGpspaIWD4lFNA=.ea073418-30f8-4eea-a8b7-5dead55ca25e@github.com>

On Fri, 4 Apr 2025 18:31:33 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This change rewrites `Popup_parentWindow_Test` after a-long-time-ago-done changes to Popup public API.
>> 
>> Popup used to have an `owner` and `parentWindow` properties. I couldn't track how far back that change happened so I can't fully say what these Properties actually were, but to my knowledge both properties were replaced by `ownerNode` and `ownerWindow` Properties respectively. New Properties are read-only and are set while calling respective `Popup.show()` - `Popup.show(Node, ...)` sets both Properties, while `Popup.show(Window, ...)` sets only `ownerWindow` Property.
>> 
>> A lot of original test scenarios were cut out because with current Popup API they make little to no sense. Original `Popup_parentWindow_Test` extended `PropertiesTestBase` and ran the regular Property access checks. Those are parametrized and split into four test methods:
>> - `testGetBean` - confidence check for whether we can get the Property bean, unnecessary since new tests access the Properties directly
>> - `testGetName` - Properties in `PropertiesTestBase` are referred to by String-provided name and Reflection, so this was a confidence check whether those Properties actually exist in the object - unnecessary, since we access the Properties directly
>> - `testBinding` - I deemed those not doable, since the Properties we try to access are read-only and cannot be bound to
>> - `testBasicAccess` - This is the only test I found that was workable into a reimplementation, and so it is manually reimplemented as `Popup_owner_Test`
>> 
>> Moreover, because of lack of `Popup.setParent()` API I also deemed more complex test scenarios (cases referring to TestScene's `_window` Property) unnecessary. Since there is no `Popup.show(Scene, ...)` those cases were also eliminated. This leaves current test pool into three separate parameters for one, similar test case.
>
> modules/javafx.graphics/src/test/java/test/javafx/stage/Popup_owner_Test.java line 55:
> 
>> 53:  * Instead we rely on checking this manually.
>> 54:  */
>> 55: public final class Popup_owner_Test {
> 
> minor: maybe `Popup_Owner_Test`?

We do seem to have this funny-looking `PascalCase_camelCase_Test` convention in several places.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1763#discussion_r2029799082

From mstrauss at openjdk.org  Sat Apr  5 07:56:55 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 5 Apr 2025 07:56:55 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v23]
In-Reply-To: <COXsxBJaTLOpBjcyoBzPLmqRy6AN7n7uW_5J4vF0AVA=.647965aa-780a-4706-8248-a621fe1625b7@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <COXsxBJaTLOpBjcyoBzPLmqRy6AN7n7uW_5J4vF0AVA=.647965aa-780a-4706-8248-a621fe1625b7@github.com>
Message-ID: <jpI6FO_CrFjL40cSZPPBMri-hLmkIlO5ai8eEW2JGNA=.2ed09aa9-b3c9-4697-be9f-178b651c9922@github.com>

On Fri, 4 Apr 2025 14:42:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Please refer to
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
>> 
>> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
>> 
>> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
>> 
>> 
>>     /**
>>      * Obtains the snapshot of the current text layout information.
>>      * @return the layout information
>>      * @since 25
>>      */
>>     public final LayoutInfo getLayoutInfo()
>> 
>> 
>> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
>> 
>> - caret information
>> - text lines: offsets and bounds
>> - overall layout bounds
>> - text selection geometry
>> - strike-through geometry
>> - underline geometry
>> 
>> 
>> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
>> 
>> 
>>     /**
>>      * Returns the shape for the strike-through in local coordinates.
>>      *
>>      * @param start the beginning character index for the range
>>      * @param end the end character index (non-inclusive) for the range
>>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>>      * @since 25
>>      */
>>     public final PathElement[] strikeThroughShape(int start, int end)
>> 
>> 
>> 
>> 
>> ## WARNING
>> 
>> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
>> 
>> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
>> 
>> 
>> 
>> ## Testing
>> 
>> The new APIs can be visually tested using the Monkey Tester on this branch:
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
>> 
>> in the Text and TextFlow pages:
>> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
>> 
>> Two very basic headful tests have been added.
>> 
>> 
>> ## See Also
>> 
>> https://github.com/FXMisc/RichTextFX/pull/1246
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - twice
>  - tests
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - 25 25
>  - ... and 38 more: https://git.openjdk.org/jfx/compare/76282bcf...33cf88d8

modules/javafx.graphics/src/main/java/javafx/scene/text/CaretInfo.java line 62:

> 60:      *     {@code (index < 0 || index > getSegmentCount())}
> 61:      */
> 62:     public abstract Rectangle2D getSegmentAt(int index);

The naming style in `CaretInfo`, `LayoutInfo`, and `TextLineInfo` is a bit inconsistent in that it uses both `getFoo()` as well as `foo()` (both with and without method arguments). I think you should decide on one way or the other.

modules/javafx.graphics/src/main/java/javafx/scene/text/TextLineInfo.java line 36:

> 34:  * @param bounds the bounds of the text line, in local coordinates:
> 35:  * <ul>
> 36:  * <li>

What do you think about indenting the `<ul>` (so that it's clearer that it belongs to the `@param` tag), as well as dropping the closing `</li>` and indent the `<li>` elements to make them stand out better:


@param bounds the bounds of the text line, in local coordinates:
       <ul>
           <li>{@code minX} - the x origin of the line (relative to the layout).
               The x origin is defined by TextAlignment of the text layout, always zero
               for left-aligned text.
           <li>{@code minY} - the ascent of the line (negative).
               The ascent of the line is the max ascent of all fonts in the line.
           ...



I find this formatting to be more readable in source code form.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2029802324
PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2029801455

From mstrauss at openjdk.org  Sat Apr  5 07:56:56 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 5 Apr 2025 07:56:56 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v18]
In-Reply-To: <hbxhpPUmmm1kH63yJKlB0ZKw_Q8vKnJdqVYMKmqLt3s=.48ae2127-4a07-4d51-9640-a855496853dd@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <ppcFw0NuNVM7qPKpj8Cc_yvQcGQzybEcZSbnNWkle0Q=.b5845b2e-904b-4c17-ae6d-1efabc1b0930@github.com>
 <NwrEfhAEBt-XQ34Qsdkr-QFsxgFizTfS9wHaydJgNKc=.0195a686-b992-4a4d-bc3a-e4f1b6796fae@github.com>
 <hbxhpPUmmm1kH63yJKlB0ZKw_Q8vKnJdqVYMKmqLt3s=.48ae2127-4a07-4d51-9640-a855496853dd@github.com>
Message-ID: <cRKNOuLBJHcsEeR2k6WOxEbMAvGU4G_b7Q0o-uX89L4=.eaac4b68-4090-4d5c-bdbf-0887562e8d20@github.com>

On Mon, 10 Mar 2025 16:25:40 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/text/LayoutInfo.java line 41:
>> 
>>> 39:  * @since 25
>>> 40:  */
>>> 41: public abstract class LayoutInfo {
>> 
>> Any exceptions thrown by methods of this class?
>
> only `public abstract TextLineInfo getTextLine(int index, boolean includeLineSpacing);`
> 
> (added)

Can this class be sealed?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2029799934

From jbhaskar at openjdk.org  Sat Apr  5 08:25:54 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Sat, 5 Apr 2025 08:25:54 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
 [v6]
In-Reply-To: <JFWceI-5sfoGUy40e_PgUcExHty6540qr2GLPdS5PoA=.8034bbfc-fb0d-49e9-aab0-bde152e959f4@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
 <JFWceI-5sfoGUy40e_PgUcExHty6540qr2GLPdS5PoA=.8034bbfc-fb0d-49e9-aab0-bde152e959f4@github.com>
Message-ID: <vCPmWTA5rH31RS2_zdrewbWcHYSebRsbeoM_Ic2I3Xk=.352eec08-3150-411d-b059-08afc6383f75@github.com>

On Sat, 5 Apr 2025 05:27:40 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.
>
> Jay Bhaskar has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove whitespace
>  - change according to review

Reviewed , thanks for the support

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

PR Review: https://git.openjdk.org/jfx/pull/1759#pullrequestreview-2744816737

From zjx001202 at gmail.com  Sat Apr  5 17:20:27 2025
From: zjx001202 at gmail.com (Glavo)
Date: Sun, 6 Apr 2025 01:20:27 +0800
Subject: Proposal: A new universal Image API independent of java.desktop
Message-ID: <CAJL5A3=QDr6AK3CguOKBZ=oUCMD=g9pLfE1QnXXUOAcS1XPLZQ@mail.gmail.com>

Hi,

In https://github.com/openjdk/jfx/pull/1593, I saw some discussion about
splitting the java.desktop module.
In this discussion, I think Johan's point of view[1] is the most
representative:

> I totally agree. It is a (maintenance) nightmare to make sure the whole
> java.desktop module is available and works on mobile and embedded, while
> only a tiny fraction of it is used.
> And even for purely desktop apps, the overhead of including the
> java.desktop module in an application is significant. I often see people
> comparing the binary size of a JavaFX app versus a similar Electron app,
> and it's a pity that the size of JavaFX apps is negatively influenced by
> something that is barely used (that is, most of the bytes in the
> java.desktop module are never used in JavaFX).
>
> In the ideal world, I think a more granular javax.imageio module could be a
> solution. That could then be leveraged by the javafx modules.
> Theoretically, the java.desktop maintainers could leverage that module as
> well, and remove the internals from java.desktop, but that is not something
> we should discuss on this list.
>
>
As a developer of JavaFX applications and a contributor to commons-imaging,
I suffer from the coupling of the AWT Image API and the javax.imageio to
java.desktop.
Besides the fact that java.desktop is too heavy, the more important problem
is that Android does not provide support for it, which makes it considered
non-universal.
But after I checked the API, I thought it's not possible to split them from
java.desktop, they have many dependencies on other parts of java.desktop.

I wonder if we can provide a new Image API:

* Provides a unified abstraction for images, color space, pixel format, etc.
  These abstractions can be implemented by different vendors, such as AWT,
JavaFX, Android, etc.
* We should have a common and extensible interface for reading and writing
images,
  so that libraries such as javax.imageio and JavaFX do not need to
repeatedly implement reading and writing support for the same image format.
  This interface should be bidirectionally compatible with javax.imageio:
  The implementation of javax.imageio.spi can be regarded as the
implementation of the new interface,
  and the implementation of the new interface can also be accessed through
javax.imageio.

I want to see if people think it's feasible and worth the effort.

Glavo

[1]: https://mail.openjdk.org/pipermail/openjfx-dev/2024-October/050042.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250406/2c437088/attachment.htm>

From thiago.sayao at gmail.com  Sat Apr  5 17:35:28 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sat, 5 Apr 2025 14:35:28 -0300
Subject: Linux bug squashing
Message-ID: <CAAP_wu=jbb_Hj4HPK+Z05Y5kC06dmT0ab7ettRLQkeUNNQMEeA@mail.gmail.com>

Hi,

I'm doing some bug squashing work here:

https://github.com/openjdk/jfx-sandbox/tree/glass_gtk_bug_squashing

It's in the "it's worse now, but will be better later" phase :)

The goal is to:
- Honor the documentation on Stage class (it has statements on how
iconify/maximize/fullscreen mix together, for example);
- Squash as many JBS bugs as possible;
- Gtk3 it a bit more (it has many gtk2 code era);

Andy,

The monkey test Stage is very useful. It would be nice to have a
Stage/Scene properties monitor like the platform preferences one.
This is because the glass native side changes them.

-- Thiago.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250405/21a977f7/attachment.htm>

From mstrauss at openjdk.org  Sun Apr  6 09:29:10 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 6 Apr 2025 09:29:10 GMT
Subject: RFR: 8345348: CSS media feature queries [v8]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <giTczYpPh3DFeulcYQMlro-opaQJqfsmymxWL9iTBAM=.a8422c96-8061-40ec-910c-48db11f76f07@github.com>

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge branch 'master' into feature/media-queries
 - small refactor
 - make media-query types internal
 - add documentation
 - add missing javadoc tag
 - revert import
 - move scene preferences to Scene.Preferences interface
 - revert
 - remove SceneMediaQueryContext
 - adjust copyright year
 - ... and 5 more: https://git.openjdk.org/jfx/compare/f31d00d8...0a5626b8

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

Changes: https://git.openjdk.org/jfx/pull/1655/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=07
  Stats: 4843 lines in 39 files changed: 3732 ins; 1026 del; 85 mod
  Patch: https://git.openjdk.org/jfx/pull/1655.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655

PR: https://git.openjdk.org/jfx/pull/1655

From mstrauss at openjdk.org  Sun Apr  6 09:29:33 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 6 Apr 2025 09:29:33 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v60]
In-Reply-To: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
Message-ID: <BvVVHUwPw3i2wwfdlKAzKjmV4qAhSczdiZxvkn56ZUY=.5942d124-9c19-42d6-a12a-7eb32d662fe4@github.com>

> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style.

Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 77 commits:

 - doc update
 - Merge branch 'master' into feature/extended-window
   
   # Conflicts:
   #	tests/manual/monkey/src/com/oracle/tools/fx/monkey/MainWindow.java
   #	tests/manual/monkey/src/com/oracle/tools/fx/monkey/tools/ModalWindow.java
 - documentation
 - documentation
 - tweak header button scaling at 100%
 - enable preview features in tests
 - add preview feature
 - add preview feature
 - Merge branch 'master' into feature/extended-window
 - tweak header button glyph scaling
 - ... and 67 more: https://git.openjdk.org/jfx/compare/f31d00d8...88e50163

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

Changes: https://git.openjdk.org/jfx/pull/1605/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=59
  Stats: 6529 lines in 75 files changed: 5848 ins; 501 del; 180 mod
  Patch: https://git.openjdk.org/jfx/pull/1605.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605

PR: https://git.openjdk.org/jfx/pull/1605

From john.hendrikx at gmail.com  Sun Apr  6 12:50:02 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Sun, 6 Apr 2025 14:50:02 +0200
Subject: SCSS for JavaFX
Message-ID: <cfefb897-642b-4317-a6a5-e31ed3a96d31@gmail.com>

For anyone interested in using SCSS stylesheets with JavaFX, I created
an easy to use wrapper.? Example:

Scenescene = newScene(mainWindow);

Path rootFolder = Path.of("styles");

SCSSCompiler compiler = SCSSCompiler.of(rootFolder);

scene.getStylesheets().add(compiler.asURIString(Path.of("styles/dark-theme.scss")));

The project is on Github: https://github.com/int4-org/SCSS

Include it as a dependency like this:

<dependency>

<groupId>org.int4.scss</groupId>

<artifactId>scss-compiler</artifactId>

<version>1.86.1</version>

</dependency>

(It follows the versioning of the SCSS compiler project).

--John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250406/f9d2868b/attachment.htm>

From tsayao at openjdk.org  Sun Apr  6 21:19:51 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 6 Apr 2025 21:19:51 GMT
Subject: Withdrawn: 8353223: [Linux] - Maximized windows do not retain correct
 size when resized programmatically
In-Reply-To: <fyAnSvERX-bOxTg7GDQoZYL7dBzysh556fZeLNZXpWM=.bc011f1d-76b6-4d34-9dc4-026ea44d87d6@github.com>
References: <fyAnSvERX-bOxTg7GDQoZYL7dBzysh556fZeLNZXpWM=.bc011f1d-76b6-4d34-9dc4-026ea44d87d6@github.com>
Message-ID: <N7euuJPa0bHbRcXNypeppcq_sSE57FR5JXSkSMbUyYY=.2b51d234-827e-4df9-b549-e57dbdf0eca6@github.com>

On Sat, 29 Mar 2025 12:17:29 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> When a window is maximized, if only the width or height is programmatically set, the window will retain its current maximized dimension (either height or width) as is, unless the other dimension is also explicitly set.
> 
> This is consistent with what Gtk does.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jfx/pull/1748

From tsayao at openjdk.org  Sun Apr  6 21:28:54 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 6 Apr 2025 21:28:54 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
Message-ID: <E_4rSaA_bZFVLi0BNkdPWFFncxdwOZTjm9xAMDkUfXc=.474f58e9-58b4-427c-93e8-528b4d78de4e@github.com>

On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Adds code to trigger a scene update when a Window is restored
> 
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479

I spotted this while working on Linux glass. The test case I was doing was "showing" an iconified fullscreened stage. Linux glass has a repaint call, but it seems wrong.

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

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2781680961

From thiago.sayao at gmail.com  Sun Apr  6 21:36:31 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sun, 6 Apr 2025 18:36:31 -0300
Subject: Questions about Stage's attributes and operations
Message-ID: <CAAP_wunzr1-ZwWan_y7iBW5YvNWzp1LMXj3YLi-fOJMPtkGLAA@mail.gmail.com>

Hi,

1) How should Iconified, Maximized and FullScreen interact?

The Stage documentation states:

"In case that more Stage modes are set simultaneously their order of
importance is iconified, fullScreen, maximized (from strongest to weakest)."

To my understanding, this means if I set all three properties to true, show
the stage and unset one by on in order, it should
- Show iconified;
- Show fullscreen (when iconified set to false);
- Show maximized;
- Show with "normal" dimensions;

Is this correct?

2) Should Maximized report maximized location and dimensions?

fullScreen doc on Stage states:
"However once in full-screen mode, Stage's x, y, width, and height
variables will continue to represent the non-full-screen position and size
of the window; the same for iconified, resizable, style, and opacity."

Maximized does not state this. I'm unsure if it should be the same case.

It seems setting the maxWidth/maxHeight should not affect the ability of
maximizing the window, so it seems logical to not affect dimension values
when maximized.


-- Thiago.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250406/f8690e1f/attachment.htm>

From tsayao at openjdk.org  Sun Apr  6 21:54:53 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 6 Apr 2025 21:54:53 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
Message-ID: <ML0OVSt_dlFZm-tH0JEP8KwlclwzmEOmuGIK9KEr0xw=.dfda46ff-7fef-4fa4-94ae-7dafc8b51578@github.com>

On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Adds code to trigger a scene update when a Window is restored
> 
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479

Hmm, it also relates to something else I was intrigued by:

What happens if the Stage is both Maximized and Iconified? If `RESTORED` assumes that the window is neither Maximized nor Iconified, then when a Maximized and Iconified window is de-iconified (presented), it should not be considered `RESTORED` ? and in this case, the bug still persists.

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

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2781689933

From tsayao at openjdk.org  Sun Apr  6 22:21:02 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 6 Apr 2025 22:21:02 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v60]
In-Reply-To: <BvVVHUwPw3i2wwfdlKAzKjmV4qAhSczdiZxvkn56ZUY=.5942d124-9c19-42d6-a12a-7eb32d662fe4@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <BvVVHUwPw3i2wwfdlKAzKjmV4qAhSczdiZxvkn56ZUY=.5942d124-9c19-42d6-a12a-7eb32d662fe4@github.com>
Message-ID: <ct7Kax9kfBLE8XNvpMaixTgVBN59HWNG72QirDnp8M0=.95aaca14-5664-4b24-9b2c-b565aea919fd@github.com>

On Sun, 6 Apr 2025 09:29:33 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style.
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 77 commits:
> 
>  - doc update
>  - Merge branch 'master' into feature/extended-window
>    
>    # Conflicts:
>    #	tests/manual/monkey/src/com/oracle/tools/fx/monkey/MainWindow.java
>    #	tests/manual/monkey/src/com/oracle/tools/fx/monkey/tools/ModalWindow.java
>  - documentation
>  - documentation
>  - tweak header button scaling at 100%
>  - enable preview features in tests
>  - add preview feature
>  - add preview feature
>  - Merge branch 'master' into feature/extended-window
>  - tweak header button glyph scaling
>  - ... and 67 more: https://git.openjdk.org/jfx/compare/f31d00d8...88e50163

I'm thinking:

Should this be a Stage style? The existence of the `EXTENDED_UTILITY` style makes the case stronger. What if the user wants the Stage to be `TRANSPARENT` (*)? The only style it wouldn't be compatible with is `DECORATED` (considering `UNIFIED` will go away).

(*) `TRANSPARENT` would be the case for Linux if the users wants rounded corners, for example.

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2781699485

From lkostyra at openjdk.org  Mon Apr  7 07:06:06 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 7 Apr 2025 07:06:06 GMT
Subject: RFR: 8234153: [TEST_BUG] Rewrite Popup_parentWindow_Test
In-Reply-To: <OJknotyyMHHFYNQKUuEZz4eHBCU-0RGpspaIWD4lFNA=.ea073418-30f8-4eea-a8b7-5dead55ca25e@github.com>
References: <7bf72skQqQkaixdRyiilnIW35lkXC_X3GzbSNt9ot0U=.256071a4-e230-4e5e-9e97-aad6f614e01b@github.com>
 <pNrmBuQ8R1EgzyV-DyCkRR4B0-XPynZorQVzlDTddLY=.d132d590-95dd-42c6-9d66-10478ba875e7@github.com>
 <OJknotyyMHHFYNQKUuEZz4eHBCU-0RGpspaIWD4lFNA=.ea073418-30f8-4eea-a8b7-5dead55ca25e@github.com>
Message-ID: <huTC84UVm3ivYNOjxFcVqb-HE_NmhLjQCHTiISjeO74=.84ea603a-6e73-4a21-9b50-b032a6526a0a@github.com>

On Sat, 5 Apr 2025 07:36:58 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/test/java/test/javafx/stage/Popup_owner_Test.java line 55:
>> 
>>> 53:  * Instead we rely on checking this manually.
>>> 54:  */
>>> 55: public final class Popup_owner_Test {
>> 
>> minor: maybe `Popup_Owner_Test`?
>
> We do seem to have this funny-looking `PascalCase_camelCase_Test` convention in several places.

Yeah I mostly followed the convention of `Popup_parentWindow_Test`. I assumed the original followed `ClassToTest_propertyName_Test` convention and since this one tests `ownerWindow` and `ownerNode` properties at the same time, the name got reduced to `owner`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1763#discussion_r2030577613

From lkostyra at openjdk.org  Mon Apr  7 08:09:32 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 7 Apr 2025 08:09:32 GMT
Subject: RFR: 8234153: [TEST_BUG] Rewrite Popup_parentWindow_Test [v2]
In-Reply-To: <7bf72skQqQkaixdRyiilnIW35lkXC_X3GzbSNt9ot0U=.256071a4-e230-4e5e-9e97-aad6f614e01b@github.com>
References: <7bf72skQqQkaixdRyiilnIW35lkXC_X3GzbSNt9ot0U=.256071a4-e230-4e5e-9e97-aad6f614e01b@github.com>
Message-ID: <u2FnOgx_9sxhrdNz4_JnOiZfv06FbxIWo0CTkV-ua8Q=.fe01b60c-1ce4-4084-86f9-9e48472bcebd@github.com>

> This change rewrites `Popup_parentWindow_Test` after a-long-time-ago-done changes to Popup public API.
> 
> Popup used to have an `owner` and `parentWindow` properties. I couldn't track how far back that change happened so I can't fully say what these Properties actually were, but to my knowledge both properties were replaced by `ownerNode` and `ownerWindow` Properties respectively. New Properties are read-only and are set while calling respective `Popup.show()` - `Popup.show(Node, ...)` sets both Properties, while `Popup.show(Window, ...)` sets only `ownerWindow` Property.
> 
> A lot of original test scenarios were cut out because with current Popup API they make little to no sense. Original `Popup_parentWindow_Test` extended `PropertiesTestBase` and ran the regular Property access checks. Those are parametrized and split into four test methods:
> - `testGetBean` - confidence check for whether we can get the Property bean, unnecessary since new tests access the Properties directly
> - `testGetName` - Properties in `PropertiesTestBase` are referred to by String-provided name and Reflection, so this was a confidence check whether those Properties actually exist in the object - unnecessary, since we access the Properties directly
> - `testBinding` - I deemed those not doable, since the Properties we try to access are read-only and cannot be bound to
> - `testBasicAccess` - This is the only test I found that was workable into a reimplementation, and so it is manually reimplemented as `Popup_owner_Test`
> 
> Moreover, because of lack of `Popup.setParent()` API I also deemed more complex test scenarios (cases referring to TestScene's `_window` Property) unnecessary. Since there is no `Popup.show(Scene, ...)` those cases were also eliminated. This leaves current test pool into three separate parameters for one, similar test case.

Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:

  Replace fail() calls with assertions

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1763/files
  - new: https://git.openjdk.org/jfx/pull/1763/files/55390682..986a0b78

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1763&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1763&range=00-01

  Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1763.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1763/head:pull/1763

PR: https://git.openjdk.org/jfx/pull/1763

From lkostyra at openjdk.org  Mon Apr  7 08:19:01 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 7 Apr 2025 08:19:01 GMT
Subject: RFR: 8234153: [TEST_BUG] Rewrite Popup_parentWindow_Test [v2]
In-Reply-To: <u2FnOgx_9sxhrdNz4_JnOiZfv06FbxIWo0CTkV-ua8Q=.fe01b60c-1ce4-4084-86f9-9e48472bcebd@github.com>
References: <7bf72skQqQkaixdRyiilnIW35lkXC_X3GzbSNt9ot0U=.256071a4-e230-4e5e-9e97-aad6f614e01b@github.com>
 <u2FnOgx_9sxhrdNz4_JnOiZfv06FbxIWo0CTkV-ua8Q=.fe01b60c-1ce4-4084-86f9-9e48472bcebd@github.com>
Message-ID: <6X9qrnlqHZ4MJriD8FgsxtS6_5SvRDTnHSQkKX4Xfmc=.08f7a550-6f7c-4a4b-a119-f1abb49ea2eb@github.com>

On Mon, 7 Apr 2025 08:09:32 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This change rewrites `Popup_parentWindow_Test` after a-long-time-ago-done changes to Popup public API.
>> 
>> Popup used to have an `owner` and `parentWindow` properties. I couldn't track how far back that change happened so I can't fully say what these Properties actually were, but to my knowledge both properties were replaced by `ownerNode` and `ownerWindow` Properties respectively. New Properties are read-only and are set while calling respective `Popup.show()` - `Popup.show(Node, ...)` sets both Properties, while `Popup.show(Window, ...)` sets only `ownerWindow` Property.
>> 
>> A lot of original test scenarios were cut out because with current Popup API they make little to no sense. Original `Popup_parentWindow_Test` extended `PropertiesTestBase` and ran the regular Property access checks. Those are parametrized and split into four test methods:
>> - `testGetBean` - confidence check for whether we can get the Property bean, unnecessary since new tests access the Properties directly
>> - `testGetName` - Properties in `PropertiesTestBase` are referred to by String-provided name and Reflection, so this was a confidence check whether those Properties actually exist in the object - unnecessary, since we access the Properties directly
>> - `testBinding` - I deemed those not doable, since the Properties we try to access are read-only and cannot be bound to
>> - `testBasicAccess` - This is the only test I found that was workable into a reimplementation, and so it is manually reimplemented as `Popup_owner_Test`
>> 
>> Moreover, because of lack of `Popup.setParent()` API I also deemed more complex test scenarios (cases referring to TestScene's `_window` Property) unnecessary. Since there is no `Popup.show(Scene, ...)` those cases were also eliminated. This leaves current test pool into three separate parameters for one, similar test case.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace fail() calls with assertions

Since it's a rewrite I'm going to assume this needs two reviewers (forgot to do that when submitting)

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

PR Comment: https://git.openjdk.org/jfx/pull/1763#issuecomment-2782407765

From arapte at openjdk.org  Mon Apr  7 10:10:03 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 7 Apr 2025 10:10:03 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
 [v6]
In-Reply-To: <JFWceI-5sfoGUy40e_PgUcExHty6540qr2GLPdS5PoA=.8034bbfc-fb0d-49e9-aab0-bde152e959f4@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
 <JFWceI-5sfoGUy40e_PgUcExHty6540qr2GLPdS5PoA=.8034bbfc-fb0d-49e9-aab0-bde152e959f4@github.com>
Message-ID: <paWVAUzgm8CWHeB8OeifgYIhtU77ahsslGbrEa9_2Gk=.085878cb-5636-42d3-abad-d420c6dc5b1d@github.com>

On Sat, 5 Apr 2025 05:27:40 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.
>
> Jay Bhaskar has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove whitespace
>  - change according to review

Here are few more junit4 imports that should be removed too.
Please take a look.

- modules/javafx.base/src/test/java/test//javafx/binding/When_Boolean_Test.java:77:        org.junit.Assert.assertEquals(expected, binding.getValue());
- modules/javafx.base/src/test/java/test//javafx/binding/When_Object_Test.java:78:        org.junit.Assert.assertEquals(expected, binding.getValue());
- modules/javafx.base/src/test/java/test//javafx/binding/When_String_Test.java:77:        org.junit.Assert.assertEquals(expected, binding.getValue());
- modules/javafx.base/src/test/java/test//javafx/beans/value/ObservableValueSubscriptionsTest.java:28:import static org.junit.Assert.assertNull;
- modules/javafx.base/src/test/java/test//javafx/collections/ObservableSubListIteratorTest.java:37:import static org.junit.Assert.assertEquals;

modules/javafx.base/src/test/java/test/javafx/util/converter/DateStringConverterTest.java line 38:

> 36: import javafx.util.converter.DateStringConverter;
> 37: import javafx.util.converter.DateTimeStringConverterShim;
> 38: import static org.junit.Assert.*;

This import should be removed.

modules/javafx.base/src/test/java/test/javafx/util/converter/DateTimeStringConverterTest.java line 38:

> 36: import javafx.util.converter.DateTimeStringConverter;
> 37: import javafx.util.converter.DateTimeStringConverterShim;
> 38: import static org.junit.Assert.*;

This import should be removed.

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

Changes requested by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1759#pullrequestreview-2746247876
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2030901025
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2030901596

From jbhaskar at openjdk.org  Mon Apr  7 10:49:35 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Mon, 7 Apr 2025 10:49:35 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
 [v7]
In-Reply-To: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
Message-ID: <puMThAj1XywEAwNGk3uI8vcgbZ9ZZMSL2jVOjgxZP6A=.072d9e19-9877-4040-a0f4-30fe7061f555@github.com>

> Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.

Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:

  further chnages for review

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1759/files
  - new: https://git.openjdk.org/jfx/pull/1759/files/1a5cdf51..a0fc5905

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1759&range=06
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1759&range=05-06

  Stats: 16 lines in 7 files changed: 6 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/jfx/pull/1759.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1759/head:pull/1759

PR: https://git.openjdk.org/jfx/pull/1759

From jbhaskar at openjdk.org  Mon Apr  7 12:26:33 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Mon, 7 Apr 2025 12:26:33 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
 [v8]
In-Reply-To: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
Message-ID: <K1Pxihjd0bnw6JRwTlGUYbxsrD5t5miSTpZ3pSL0oYY=.cc48806c-0cbe-4214-9e40-be5d1b566785@github.com>

> Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.

Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:

  reorder imports

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1759/files
  - new: https://git.openjdk.org/jfx/pull/1759/files/a0fc5905..ac166115

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1759&range=07
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1759&range=06-07

  Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1759.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1759/head:pull/1759

PR: https://git.openjdk.org/jfx/pull/1759

From zelmidaoui at openjdk.org  Mon Apr  7 15:18:13 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 7 Apr 2025 15:18:13 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea [v4]
In-Reply-To: <YHzb5PGESIjFXzL0GHov66Oi_itr7COBnJ2uE2X1tJU=.5acf7694-8e7d-48d2-b53a-7641d139a63a@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <CDdPLwm_Td3FWl9Ox4kfJCxRgEwpAYX6k1iIhxc9WIA=.3619b09e-11af-43a6-8ef9-ac7e3f7fbff6@github.com>
 <SACqj1maKQK7VJ7unHRqW8QEiI4QGcCJHowaUd9yTjI=.678843c9-de45-4979-83c6-d8d9b1d9f730@github.com>
 <4h1LiyfDsTi7u06VZO6_ffy4JYDZr7CW9UWkcejFDAg=.7fc889b6-e5da-4a67-9951-f1d1f4afcbbd@github.com>
 <Cejw4zeZ9GDa5ZckxI_y04ggrR3rUUPavsiLnFCkZXA=.b77514dc-c05f-4fcd-99bc-cb2d40c566df@github.com>
 <BcblWjS2LAWIXb1WwNnzLAub8jMNw3QZvkoaWMy4TVE=.772edd50-ef1e-4511-95a9-f1f0e515b284@github.com>
 <YHzb5PGESIjFXzL0GHov66Oi_itr7COBnJ2uE2X1tJU=.5acf7694-8e7d-48d2-b53a-7641d139a63a@github.com>
Message-ID: <32JKwF5zQO4kFvBOOiLT7xIXT0wgZf6JhJhXuda0eYk=.8cf773fd-7440-49a1-aaee-4c0989806e08@github.com>

On Fri, 28 Mar 2025 20:22:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Option 1 is intentionally the status quo, and matches what Swing's JComponent does, although @mstr2 is right that this isn't documented. An RFE to treat `\r` or `\r\n` as a newline could be considered in the future. We wouldn't do that as part of this PR.
>> 
>> So for _this_ PR, the question is what characters should be elided for the prompt text of a `TextField` so that multiple lines as a single line? Limiting this to stripping `\n` is sufficient given the current implementation, unless and until something else changes. Also, it matches what the existing implementation tries to do when it modifies the actual property value.
>
> One thing I am curious about: I don't see a similar stripping of newlines in the text itself for TextField, and yet it does render the whole string as if the newline had been stripped. Do you know why we need to strip it from promptTextProperty explicitly and not from textProperty?

@kevinrushforth 
This is due to `TextFieldContent::insert` we have a filterInput and the second parameter to strip newlines is set to true in the textField class.
`filterInput(String txt, boolean stripNewlines, boolean stripTabs)`
For `TextAreaContent::insert` the parameter is set to false to allow newlines.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1716#discussion_r2031472786

From zelmidaoui at openjdk.org  Mon Apr  7 15:35:07 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 7 Apr 2025 15:35:07 GMT
Subject: RFR: 8351878: RichTextArea: copy/paste issues [v5]
In-Reply-To: <rs-4MqFkEhQm4iyoaZ4u8Ru61Da5gKYfNaUn18ON2L0=.e2d34b26-392f-411b-aaa0-6d6e5dcb8da6@github.com>
References: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
 <rs-4MqFkEhQm4iyoaZ4u8Ru61Da5gKYfNaUn18ON2L0=.e2d34b26-392f-411b-aaa0-6d6e5dcb8da6@github.com>
Message-ID: <TcT6uPheGrMth-npQAl6WCwpBdFLlaFnTnVP1-To2vo=.88766dd4-1351-4115-80e5-9413cfaf4618@github.com>

On Wed, 26 Mar 2025 14:36:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Fixed several issues found in importing RTF text:
>> 
>> - charset translation (brought back removed code)
>> - missing font size attribute
>> - missing strike-through attribute
>> 
>> Also, HTML copy suffered from the following issues:
>> 
>> - incorrect font size
>> - incorrect handling of boolean character attributes (bold, italic, etc.)
>> 
>> The charset issue was caused by my removal of the character decoder code present in the original JDK RTF parser/reader.  Why did I do that?
>> 
>> This PR does not add import of RTL paragraph attribute needed to align RTL text correctly.
>
> Andy Goryachev 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 10 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8351878.rtf
>  - html
>  - Merge remote-tracking branch 'origin/master' into 8351878.rtf
>  - arabic
>  - whitespace
>  - test
>  - strikethrough
>  - missing code in attr set
>  - font size
>  - fixed arabic import

Marked as reviewed by zelmidaoui (Author).

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

PR Review: https://git.openjdk.org/jfx/pull/1735#pullrequestreview-2747270963

From angorya at openjdk.org  Mon Apr  7 16:03:17 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Apr 2025 16:03:17 GMT
Subject: Integrated: 8351878: RichTextArea: copy/paste issues
In-Reply-To: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
References: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
Message-ID: <B0Ua28oYo_Kdm8V1O5ObpIlO62RwoN300Kn8cXFWJTE=.f2089dea-7aeb-4c2a-b43a-16948f2b54b9@github.com>

On Thu, 13 Mar 2025 21:58:16 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fixed several issues found in importing RTF text:
> 
> - charset translation (brought back removed code)
> - missing font size attribute
> - missing strike-through attribute
> 
> Also, HTML copy suffered from the following issues:
> 
> - incorrect font size
> - incorrect handling of boolean character attributes (bold, italic, etc.)
> 
> The charset issue was caused by my removal of the character decoder code present in the original JDK RTF parser/reader.  Why did I do that?
> 
> This PR does not add import of RTL paragraph attribute needed to align RTL text correctly.

This pull request has now been integrated.

Changeset: 1b26b66e
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/1b26b66ee984462825263c896ea86f502e5fd269
Stats:     612 lines in 7 files changed: 585 ins; 1 del; 26 mod

8351878: RichTextArea: copy/paste issues

Reviewed-by: lkostyra, zelmidaoui

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

PR: https://git.openjdk.org/jfx/pull/1735

From angorya at openjdk.org  Mon Apr  7 16:03:17 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Apr 2025 16:03:17 GMT
Subject: RFR: 8351878: RichTextArea: copy/paste issues [v5]
In-Reply-To: <rs-4MqFkEhQm4iyoaZ4u8Ru61Da5gKYfNaUn18ON2L0=.e2d34b26-392f-411b-aaa0-6d6e5dcb8da6@github.com>
References: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
 <rs-4MqFkEhQm4iyoaZ4u8Ru61Da5gKYfNaUn18ON2L0=.e2d34b26-392f-411b-aaa0-6d6e5dcb8da6@github.com>
Message-ID: <RCEquI1qOgzA-agH7CnfV79GIPxVT-SiMSjYkpcSFQU=.24270c84-f1c4-4026-934f-ac7aaf35bc34@github.com>

On Wed, 26 Mar 2025 14:36:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Fixed several issues found in importing RTF text:
>> 
>> - charset translation (brought back removed code)
>> - missing font size attribute
>> - missing strike-through attribute
>> 
>> Also, HTML copy suffered from the following issues:
>> 
>> - incorrect font size
>> - incorrect handling of boolean character attributes (bold, italic, etc.)
>> 
>> The charset issue was caused by my removal of the character decoder code present in the original JDK RTF parser/reader.  Why did I do that?
>> 
>> This PR does not add import of RTL paragraph attribute needed to align RTL text correctly.
>
> Andy Goryachev 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 10 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8351878.rtf
>  - html
>  - Merge remote-tracking branch 'origin/master' into 8351878.rtf
>  - arabic
>  - whitespace
>  - test
>  - strikethrough
>  - missing code in attr set
>  - font size
>  - fixed arabic import

Thank you all for reviewing!

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

PR Comment: https://git.openjdk.org/jfx/pull/1735#issuecomment-2783857043

From angorya at openjdk.org  Mon Apr  7 16:32:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Apr 2025 16:32:57 GMT
Subject: RFR: 8234153: [TEST_BUG] Rewrite Popup_parentWindow_Test [v2]
In-Reply-To: <u2FnOgx_9sxhrdNz4_JnOiZfv06FbxIWo0CTkV-ua8Q=.fe01b60c-1ce4-4084-86f9-9e48472bcebd@github.com>
References: <7bf72skQqQkaixdRyiilnIW35lkXC_X3GzbSNt9ot0U=.256071a4-e230-4e5e-9e97-aad6f614e01b@github.com>
 <u2FnOgx_9sxhrdNz4_JnOiZfv06FbxIWo0CTkV-ua8Q=.fe01b60c-1ce4-4084-86f9-9e48472bcebd@github.com>
Message-ID: <5Tez3DxR0IC6OstvS8Uc8DScyDO2icqeYfzqZQwWtPk=.d68eff44-2833-40aa-b3d1-776abbecd689@github.com>

On Mon, 7 Apr 2025 08:09:32 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This change rewrites `Popup_parentWindow_Test` after a-long-time-ago-done changes to Popup public API.
>> 
>> Popup used to have an `owner` and `parentWindow` properties. I couldn't track how far back that change happened so I can't fully say what these Properties actually were, but to my knowledge both properties were replaced by `ownerNode` and `ownerWindow` Properties respectively. New Properties are read-only and are set while calling respective `Popup.show()` - `Popup.show(Node, ...)` sets both Properties, while `Popup.show(Window, ...)` sets only `ownerWindow` Property.
>> 
>> A lot of original test scenarios were cut out because with current Popup API they make little to no sense. Original `Popup_parentWindow_Test` extended `PropertiesTestBase` and ran the regular Property access checks. Those are parametrized and split into four test methods:
>> - `testGetBean` - confidence check for whether we can get the Property bean, unnecessary since new tests access the Properties directly
>> - `testGetName` - Properties in `PropertiesTestBase` are referred to by String-provided name and Reflection, so this was a confidence check whether those Properties actually exist in the object - unnecessary, since we access the Properties directly
>> - `testBinding` - I deemed those not doable, since the Properties we try to access are read-only and cannot be bound to
>> - `testBasicAccess` - This is the only test I found that was workable into a reimplementation, and so it is manually reimplemented as `Popup_owner_Test`
>> 
>> Moreover, because of lack of `Popup.setParent()` API I also deemed more complex test scenarios (cases referring to TestScene's `_window` Property) unnecessary. Since there is no `Popup.show(Scene, ...)` those cases were also eliminated. This leaves current test pool into three separate parameters for one, similar test case.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace fail() calls with assertions

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1763#pullrequestreview-2747437903

From angorya at openjdk.org  Mon Apr  7 16:47:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Apr 2025 16:47:03 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
 [v8]
In-Reply-To: <K1Pxihjd0bnw6JRwTlGUYbxsrD5t5miSTpZ3pSL0oYY=.cc48806c-0cbe-4214-9e40-be5d1b566785@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
 <K1Pxihjd0bnw6JRwTlGUYbxsrD5t5miSTpZ3pSL0oYY=.cc48806c-0cbe-4214-9e40-be5d1b566785@github.com>
Message-ID: <Slct4Ci0TDgU2PzZYL4SAIU2UxbG6oPmkZ9ugZqN8Qw=.476ce4d8-3445-44ce-b4aa-a841bd104132@github.com>

On Mon, 7 Apr 2025 12:26:33 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.
>
> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reorder imports

looks good now, with two very minor suggestions (will re-approve if you decide to update).  thanks!

modules/javafx.base/src/test/java/test/javafx/util/converter/DateStringConverterTest.java line 61:

> 59:     }
> 60: 
> 61:     public static Collection implementations() {

very minor: can be `private`

modules/javafx.base/src/test/java/test/javafx/util/converter/DateTimeStringConverterTest.java line 65:

> 63:     }
> 64: 
> 65:     public static Collection implementations() {

very minor: can be `private`

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1759#pullrequestreview-2747466956
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2031627362
PR Review Comment: https://git.openjdk.org/jfx/pull/1759#discussion_r2031627741

From andy.goryachev at oracle.com  Mon Apr  7 16:59:04 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 7 Apr 2025 16:59:04 +0000
Subject: TabPane overflow menu showing blanks
In-Reply-To: <CAGBnJPt_7_sJq8rX3fENXt3LU2=BZ5xN2mHy5L0gPd3fpFjyww@mail.gmail.com>
References: <CAGBnJPt_7_sJq8rX3fENXt3LU2=BZ5xN2mHy5L0gPd3fpFjyww@mail.gmail.com>
Message-ID: <BYAPR10MB301380B0A50E2EAA83512B94E5AA2@BYAPR10MB3013.namprd10.prod.outlook.com>

All very good points, thank you for this writeup!

This discussion relates to https://bugs.openjdk.org/browse/JDK-8353599 .  I've been thinking how to handle this issue, and I am leaning to agree with the suggestion proposed in the ticket (some sort of menu item factory).

The current "hacky" solution not obviously fails, but also not scalable - I can see developers wanting to place a Canvas, a Path, a Pane, or any other kind of Node and it would be nearly impossible to "clone" these in a maintainable manner.  With a menu item factory, however, the effort will be shifted on the application dev with a very simple solution.

The other solution that does not involve a new API would be to limit the overflow menu to only list the tabs that are hidden - in this case the graphics Nodes can be reused by the menu items.  The problem with that approach is the overflow menu logic becomes more complicated, to handle the case when menus are hidden on both ends.

What do you think?

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Cormac Redmond <credmond at certak.com>
Date: Friday, April 4, 2025 at 17:00
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: TabPane overflow menu showing blanks
Hi,

TabPane tabs allow you to set graphic nodes as the header and there appears to be no documented limitations or best-practises on this.

You might assume it's perfectly reasonable to not set a Tab's text value, and instead set the header as a HBox, consisting of a graphic node (left) and a Label (itself with a text + a graphic, right), to achieve an icon-text-icon style header, which is not an uncommon.

However, the overflow menu, when it kicks in, will not display any text or graphics at all (just a blank space), if your Tab has no "text" set, and the header graphic is not a Label or an ImageView.

It's down to this self-confessed hacky code (https://github.com/openjdk/jfx/blob/f31d00d8f7e601c3bb28a9975dd029390ec92173/modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java#L479):

    /**
     * VERY HACKY - this lets us 'duplicate' Label and ImageView nodes to be used in a
     * Tab and the tabs menu at the same time.
     */
    private static Node clone(Node n) {
        if (n == null) {
            return null;
        }
        if (n instanceof ImageView) {
            ImageView iv = (ImageView) n;
            ImageView imageview = new ImageView();
            imageview.imageProperty().bind(iv.imageProperty());
            return imageview;
        }
        if (n instanceof Label) {
            Label l = (Label)n;
            Label label = new Label(l.getText(), clone(l.getGraphic()));
            label.textProperty().bind(l.textProperty());
            return label;
        }
        return null;
    }


It is not obvious at all that this is what's going to happen, or why. And it seems impossible to control or influence this in any reasonable way, without replacing the whole TabPaneSkin.

Given TabPane is one of the most important and widely used controls there is, there could/should be some of the following:

  *   Proper documentation on this limitation / behaviour
  *   Some way to set fallback text that can be used in the menu (i.e., that isn't the Tab's header's text, because one might intentionally avoid setting that given there's no way to hide it from the tab header)
  *   Or, better yet, some way to allow you to specify tab header text without displaying it in the actual tab header, which could then be used by the hacky method as normal
  *   Some way to set a callback so the developer can decide what gets displayed for the overflow menu
  *   Some way to override the skin without needing a full copy + paste + rename
  *   Some way to allow the dev to disable the overflow menu, if it's going to produce something unusable. E.g., prefer no menu than a buggy one...

I would view this as a bug, even though it's probably been like this forever.


Some sample code to demonstrate; just look at the menu:

public class TabPaneMenu extends Application {
    @Override
    public void start(Stage primaryStage) {
        TabPane tabPane = new TabPane();

        for (int i = 1; i <= 30; i++) {
            Tab tab;
            if (i == 2) {
                tab = new Tab();
                final Label label = new Label("HBox Tab " + i);
                final HBox hBox = new HBox(label); // Will show as blank in overflow menu!
                tab.setGraphic(hBox);
            } else if (i == 5) {
                tab = new Tab();
                tab.setGraphic(new Label("Label Tab " + i)); // Will show in overflow menu, because it's a Label
            } else {
                tab = new Tab("Normal Tab " + i);
            }

            tab.setContent(new StackPane(new Label("This is Tab " + i)));
            tab.setClosable(false);
            tabPane.getTabs().add(tab);

        }

        Scene scene = new Scene(tabPane, 800, 600);
        primaryStage.setScene(scene);
        primaryStage.show();
    }

    public static void main(String[] args) {
        launch(args);
    }
}


Kind Regards,

Cormac Redmond
Software Engineer, Certak Ltd.

e: credmond at certak.com<mailto:credmond at certak.com> | m: +353 (0) 86 268 2152 | w: www.certak.com<http://www.certak.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250407/6b67583a/attachment-0001.htm>

From jbhaskar at openjdk.org  Mon Apr  7 17:23:53 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Mon, 7 Apr 2025 17:23:53 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
 [v9]
In-Reply-To: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
Message-ID: <0rsX_7vORvBMldTLId0ewFnRYaMcV2lQvmX3frTrMWU=.345b79bd-eb4a-4b2e-b6e2-b818c4d0a3ba@github.com>

> Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.

Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:

  make public data to private

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1759/files
  - new: https://git.openjdk.org/jfx/pull/1759/files/ac166115..a1c5e2df

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1759&range=08
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1759&range=07-08

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1759.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1759/head:pull/1759

PR: https://git.openjdk.org/jfx/pull/1759

From angorya at openjdk.org  Mon Apr  7 18:34:54 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Apr 2025 18:34:54 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
 [v9]
In-Reply-To: <0rsX_7vORvBMldTLId0ewFnRYaMcV2lQvmX3frTrMWU=.345b79bd-eb4a-4b2e-b6e2-b818c4d0a3ba@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
 <0rsX_7vORvBMldTLId0ewFnRYaMcV2lQvmX3frTrMWU=.345b79bd-eb4a-4b2e-b6e2-b818c4d0a3ba@github.com>
Message-ID: <TQvW3FgkujDgZSAamep_e1UYFVEcm3oNqTFH6G2cDH8=.46065448-6edc-45bc-8338-3c38c708cc33@github.com>

On Mon, 7 Apr 2025 17:23:53 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.
>
> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make public data to private

lgtm

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1759#pullrequestreview-2747691646

From angorya at openjdk.org  Mon Apr  7 18:38:46 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Apr 2025 18:38:46 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v23]
In-Reply-To: <COXsxBJaTLOpBjcyoBzPLmqRy6AN7n7uW_5J4vF0AVA=.647965aa-780a-4706-8248-a621fe1625b7@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <COXsxBJaTLOpBjcyoBzPLmqRy6AN7n7uW_5J4vF0AVA=.647965aa-780a-4706-8248-a621fe1625b7@github.com>
Message-ID: <AIr0yEWoXFRtchwnd0T-wdyOgh6A-TOmVa5iWhTxfHg=.9a400757-46ab-4c9c-963b-e1205d1e2e5d@github.com>

On Fri, 4 Apr 2025 14:42:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Please refer to
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
>> 
>> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
>> 
>> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
>> 
>> 
>>     /**
>>      * Obtains the snapshot of the current text layout information.
>>      * @return the layout information
>>      * @since 25
>>      */
>>     public final LayoutInfo getLayoutInfo()
>> 
>> 
>> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
>> 
>> - caret information
>> - text lines: offsets and bounds
>> - overall layout bounds
>> - text selection geometry
>> - strike-through geometry
>> - underline geometry
>> 
>> 
>> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
>> 
>> 
>>     /**
>>      * Returns the shape for the strike-through in local coordinates.
>>      *
>>      * @param start the beginning character index for the range
>>      * @param end the end character index (non-inclusive) for the range
>>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>>      * @since 25
>>      */
>>     public final PathElement[] strikeThroughShape(int start, int end)
>> 
>> 
>> 
>> 
>> ## WARNING
>> 
>> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
>> 
>> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
>> 
>> 
>> 
>> ## Testing
>> 
>> The new APIs can be visually tested using the Monkey Tester on this branch:
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
>> 
>> in the Text and TextFlow pages:
>> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
>> 
>> Two very basic headful tests have been added.
>> 
>> 
>> ## See Also
>> 
>> https://github.com/FXMisc/RichTextFX/pull/1246
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - twice
>  - tests
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - 25 25
>  - ... and 38 more: https://git.openjdk.org/jfx/compare/76282bcf...33cf88d8

> Can this class be sealed?

Theoretically, yes, but what problem would that solve?

I can understand when sealing would make the platform more secure, but in this case I see no value whatsoever.  Could you give me an example where sealing the `LayoutInfo` class might help?

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

PR Comment: https://git.openjdk.org/jfx/pull/1596#issuecomment-2784215018

From angorya at openjdk.org  Mon Apr  7 18:38:48 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Apr 2025 18:38:48 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v23]
In-Reply-To: <jpI6FO_CrFjL40cSZPPBMri-hLmkIlO5ai8eEW2JGNA=.2ed09aa9-b3c9-4697-be9f-178b651c9922@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <COXsxBJaTLOpBjcyoBzPLmqRy6AN7n7uW_5J4vF0AVA=.647965aa-780a-4706-8248-a621fe1625b7@github.com>
 <jpI6FO_CrFjL40cSZPPBMri-hLmkIlO5ai8eEW2JGNA=.2ed09aa9-b3c9-4697-be9f-178b651c9922@github.com>
Message-ID: <3cQbw2HhQa62BALdCbK70SnNNQ3hnbBLrTGMCUm5O60=.d575009f-4c71-4d7a-b378-93608c4be9be@github.com>

On Sat, 5 Apr 2025 07:49:07 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - twice
>>  - tests
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - 25 25
>>  - ... and 38 more: https://git.openjdk.org/jfx/compare/76282bcf...33cf88d8
>
> modules/javafx.graphics/src/main/java/javafx/scene/text/TextLineInfo.java line 36:
> 
>> 34:  * @param bounds the bounds of the text line, in local coordinates:
>> 35:  * <ul>
>> 36:  * <li>
> 
> What do you think about indenting the `<ul>` (so that it's clearer that it belongs to the `@param` tag), as well as dropping the closing `</li>` and indent the `<li>` elements to make them stand out better:
> 
> 
> @param bounds the bounds of the text line, in local coordinates:
>        <ul>
>            <li>{@code minX} - the x origin of the line (relative to the layout).
>                The x origin is defined by TextAlignment of the text layout, always zero
>                for left-aligned text.
>            <li>{@code minY} - the ascent of the line (negative).
>                The ascent of the line is the max ascent of all fonts in the line.
>            ...
> 
> 
> 
> I find this formatting to be more readable in source code form.

good idea

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2031790281

From angorya at openjdk.org  Mon Apr  7 18:44:50 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Apr 2025 18:44:50 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v24]
In-Reply-To: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
Message-ID: <jN1-PKG1xiVCWQR7_b4vTqyAFX_BRW9ZZYeZSrD_d4w=.355093d7-fce2-445e-bfa5-e663fd5f3344@github.com>

> Please refer to
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
> 
> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
> 
> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
> 
> 
>     /**
>      * Obtains the snapshot of the current text layout information.
>      * @return the layout information
>      * @since 25
>      */
>     public final LayoutInfo getLayoutInfo()
> 
> 
> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
> 
> - caret information
> - text lines: offsets and bounds
> - overall layout bounds
> - text selection geometry
> - strike-through geometry
> - underline geometry
> 
> 
> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
> 
> 
>     /**
>      * Returns the shape for the strike-through in local coordinates.
>      *
>      * @param start the beginning character index for the range
>      * @param end the end character index (non-inclusive) for the range
>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>      * @since 25
>      */
>     public final PathElement[] strikeThroughShape(int start, int end)
> 
> 
> 
> 
> ## WARNING
> 
> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
> 
> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
> 
> 
> 
> ## Testing
> 
> The new APIs can be visually tested using the Monkey Tester on this branch:
> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
> 
> in the Text and TextFlow pages:
> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
> 
> Two very basic headful tests have been added.
> 
> 
> ## See Also
> 
> https://github.com/FXMisc/RichTextFX/pull/1246

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits:

 - indent
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - twice
 - tests
 - review comments
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - review comments
 - ... and 40 more: https://git.openjdk.org/jfx/compare/1b26b66e...fa23f097

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

Changes: https://git.openjdk.org/jfx/pull/1596/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=23
  Stats: 1538 lines in 13 files changed: 1476 ins; 18 del; 44 mod
  Patch: https://git.openjdk.org/jfx/pull/1596.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1596/head:pull/1596

PR: https://git.openjdk.org/jfx/pull/1596

From angorya at openjdk.org  Mon Apr  7 18:44:52 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Apr 2025 18:44:52 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v23]
In-Reply-To: <jpI6FO_CrFjL40cSZPPBMri-hLmkIlO5ai8eEW2JGNA=.2ed09aa9-b3c9-4697-be9f-178b651c9922@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <COXsxBJaTLOpBjcyoBzPLmqRy6AN7n7uW_5J4vF0AVA=.647965aa-780a-4706-8248-a621fe1625b7@github.com>
 <jpI6FO_CrFjL40cSZPPBMri-hLmkIlO5ai8eEW2JGNA=.2ed09aa9-b3c9-4697-be9f-178b651c9922@github.com>
Message-ID: <rexLOJ6STpt-XPKlKlta2CPdhCuSKAtXaJAbpxad-7E=.6ead5778-7c2a-40c8-91ab-171dd90da53f@github.com>

On Sat, 5 Apr 2025 07:53:35 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - twice
>>  - tests
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - 25 25
>>  - ... and 38 more: https://git.openjdk.org/jfx/compare/76282bcf...33cf88d8
>
> modules/javafx.graphics/src/main/java/javafx/scene/text/CaretInfo.java line 62:
> 
>> 60:      *     {@code (index < 0 || index > getSegmentCount())}
>> 61:      */
>> 62:     public abstract Rectangle2D getSegmentAt(int index);
> 
> The naming style in `CaretInfo`, `LayoutInfo`, and `TextLineInfo` is a bit inconsistent in that it uses both `getFoo()` as well as `foo()` (both with and without method arguments). I think you should decide on one way or the other.

`TextLineInfo` is a record, I don't want to add duplicate getXXX() aliases there.

The other (in `LayoutInfo`) are modeled after `Text`/`TextFlow` (e.g. `underlineShape()`), I have no problem with any of these.  I don't think we have strict rules regarding naming, and these are not java beans to utilize some sort of naming pattern in accessors, but I could be missing something.

Could you be more specific?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2031798909

From angorya at openjdk.org  Mon Apr  7 18:52:25 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Apr 2025 18:52:25 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v60]
In-Reply-To: <BvVVHUwPw3i2wwfdlKAzKjmV4qAhSczdiZxvkn56ZUY=.5942d124-9c19-42d6-a12a-7eb32d662fe4@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <BvVVHUwPw3i2wwfdlKAzKjmV4qAhSczdiZxvkn56ZUY=.5942d124-9c19-42d6-a12a-7eb32d662fe4@github.com>
Message-ID: <qXX6JFP_GEflTyUUz7O967TPae_Rsgok0-eMQh1DhgY=.6f8f5398-1f0e-4a73-9d4e-d3f24370959b@github.com>

On Sun, 6 Apr 2025 09:29:33 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style.
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 77 commits:
> 
>  - doc update
>  - Merge branch 'master' into feature/extended-window
>    
>    # Conflicts:
>    #	tests/manual/monkey/src/com/oracle/tools/fx/monkey/MainWindow.java
>    #	tests/manual/monkey/src/com/oracle/tools/fx/monkey/tools/ModalWindow.java
>  - documentation
>  - documentation
>  - tweak header button scaling at 100%
>  - enable preview features in tests
>  - add preview feature
>  - add preview feature
>  - Merge branch 'master' into feature/extended-window
>  - tweak header button glyph scaling
>  - ... and 67 more: https://git.openjdk.org/jfx/compare/f31d00d8...88e50163

modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 854:

> 852:             return minimum
> 853:                 ? computeChildMinAreaHeight(child, -1, margin, width, false)
> 854:                 : computeChildPrefAreaHeight(child, -1, margin, width, false);

this change is not doc-related - was it somehow omitted from before?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2031816056

From mstrauss at openjdk.org  Mon Apr  7 18:56:21 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 7 Apr 2025 18:56:21 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v23]
In-Reply-To: <AIr0yEWoXFRtchwnd0T-wdyOgh6A-TOmVa5iWhTxfHg=.9a400757-46ab-4c9c-963b-e1205d1e2e5d@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <COXsxBJaTLOpBjcyoBzPLmqRy6AN7n7uW_5J4vF0AVA=.647965aa-780a-4706-8248-a621fe1625b7@github.com>
 <AIr0yEWoXFRtchwnd0T-wdyOgh6A-TOmVa5iWhTxfHg=.9a400757-46ab-4c9c-963b-e1205d1e2e5d@github.com>
Message-ID: <6LpOGuOLQYEQcLMYmphUkuwxp1yU7OKH119h9uB33fo=.308e1fd2-5be6-46d1-9370-c6a5416fcf4f@github.com>

On Mon, 7 Apr 2025 18:30:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > Can this class be sealed?
> 
> Theoretically, yes, but what problem would that solve?
> 
> I can understand when sealing would make the platform more secure, but in this case I see no value whatsoever. Could you give me an example where sealing the `LayoutInfo` class might help?

I think a class should always be final or sealed by default, no further justification required (it's one of the defaults the Java language arguably got wrong). Justification should be given for a class to be extensible, as that will invariably add to the incompatibility budget required for future changes. Designing a class for extensibility is also usually very different from designing a sealed class, and there are many examples in JavaFX where careless extensibility leads to problems down the line.
 
> edit: I can see the value of sealing in some security context, but I really dislike how this exposes the internals via `permits`.

How so? You can't do anything with non-exported permitted subclasses, so it's not leaking anything in that sense. Javadoc also doesn't show you non-exported permitted classes.

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

PR Comment: https://git.openjdk.org/jfx/pull/1596#issuecomment-2784268100

From mstrauss at openjdk.org  Mon Apr  7 19:05:33 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 7 Apr 2025 19:05:33 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v60]
In-Reply-To: <qXX6JFP_GEflTyUUz7O967TPae_Rsgok0-eMQh1DhgY=.6f8f5398-1f0e-4a73-9d4e-d3f24370959b@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <BvVVHUwPw3i2wwfdlKAzKjmV4qAhSczdiZxvkn56ZUY=.5942d124-9c19-42d6-a12a-7eb32d662fe4@github.com>
 <qXX6JFP_GEflTyUUz7O967TPae_Rsgok0-eMQh1DhgY=.6f8f5398-1f0e-4a73-9d4e-d3f24370959b@github.com>
Message-ID: <Ohv7C4KnzALtx-G8LJDjMVkn9FCsRIwharDCt31hvoc=.d9ae6332-a311-428b-984b-961c8f8b3a10@github.com>

On Mon, 7 Apr 2025 18:49:51 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 77 commits:
>> 
>>  - doc update
>>  - Merge branch 'master' into feature/extended-window
>>    
>>    # Conflicts:
>>    #	tests/manual/monkey/src/com/oracle/tools/fx/monkey/MainWindow.java
>>    #	tests/manual/monkey/src/com/oracle/tools/fx/monkey/tools/ModalWindow.java
>>  - documentation
>>  - documentation
>>  - tweak header button scaling at 100%
>>  - enable preview features in tests
>>  - add preview feature
>>  - add preview feature
>>  - Merge branch 'master' into feature/extended-window
>>  - tweak header button glyph scaling
>>  - ... and 67 more: https://git.openjdk.org/jfx/compare/f31d00d8...88e50163
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 854:
> 
>> 852:             return minimum
>> 853:                 ? computeChildMinAreaHeight(child, -1, margin, width, false)
>> 854:                 : computeChildPrefAreaHeight(child, -1, margin, width, false);
> 
> this change is not doc-related - was it somehow omitted from before?

This was a leftover from a merge conflict that was caused by recent changes to the `Region.computeChildMinAreaHeight` and `Region.computeChildPrefAreaHeight` methods. The commit message is just a bit sloppy.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2031833781

From mstrauss at openjdk.org  Mon Apr  7 19:17:22 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 7 Apr 2025 19:17:22 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v23]
In-Reply-To: <rexLOJ6STpt-XPKlKlta2CPdhCuSKAtXaJAbpxad-7E=.6ead5778-7c2a-40c8-91ab-171dd90da53f@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <COXsxBJaTLOpBjcyoBzPLmqRy6AN7n7uW_5J4vF0AVA=.647965aa-780a-4706-8248-a621fe1625b7@github.com>
 <jpI6FO_CrFjL40cSZPPBMri-hLmkIlO5ai8eEW2JGNA=.2ed09aa9-b3c9-4697-be9f-178b651c9922@github.com>
 <rexLOJ6STpt-XPKlKlta2CPdhCuSKAtXaJAbpxad-7E=.6ead5778-7c2a-40c8-91ab-171dd90da53f@github.com>
Message-ID: <qnJu1fSsF8HLFFXKqz-cnXmdf5781GfbVSEFA7kW7Yk=.7abc99c7-7f9b-441a-b388-ae9852e66786@github.com>

On Mon, 7 Apr 2025 18:39:25 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/text/CaretInfo.java line 62:
>> 
>>> 60:      *     {@code (index < 0 || index > getSegmentCount())}
>>> 61:      */
>>> 62:     public abstract Rectangle2D getSegmentAt(int index);
>> 
>> The naming style in `CaretInfo`, `LayoutInfo`, and `TextLineInfo` is a bit inconsistent in that it uses both `getFoo()` as well as `foo()` (both with and without method arguments). I think you should decide on one way or the other.
>
> `TextLineInfo` is a record, I don't want to add duplicate getXXX() aliases there.
> 
> The other (in `LayoutInfo`) are modeled after `Text`/`TextFlow` (e.g. `underlineShape()`), I have no problem with any of these.  I don't think we have strict rules regarding naming, and these are not java beans to utilize some sort of naming pattern in accessors, but I could be missing something.
> 
> Could you be more specific?

I understand the argument for `TextLineInfo`, I guess I'm looking more at `LayoutInfo` here. My question is whether it is really the best choice to sacrifice local consistency within a single class just to have it look more similar to equally inconsistently named methods in another class? Anyway, I just wanted to point this out, that's not a hill for me to die on.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2031859119

From angorya at openjdk.org  Mon Apr  7 19:29:34 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Apr 2025 19:29:34 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v60]
In-Reply-To: <BvVVHUwPw3i2wwfdlKAzKjmV4qAhSczdiZxvkn56ZUY=.5942d124-9c19-42d6-a12a-7eb32d662fe4@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <BvVVHUwPw3i2wwfdlKAzKjmV4qAhSczdiZxvkn56ZUY=.5942d124-9c19-42d6-a12a-7eb32d662fe4@github.com>
Message-ID: <sk1iIL2ZFFhAIvLtwuQy6FTxN-UeCPJlDaORUV9bhEg=.2fcff91b-6747-4f3f-9900-3f8f5e5455b6@github.com>

On Sun, 6 Apr 2025 09:29:33 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style.
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 77 commits:
> 
>  - doc update
>  - Merge branch 'master' into feature/extended-window
>    
>    # Conflicts:
>    #	tests/manual/monkey/src/com/oracle/tools/fx/monkey/MainWindow.java
>    #	tests/manual/monkey/src/com/oracle/tools/fx/monkey/tools/ModalWindow.java
>  - documentation
>  - documentation
>  - tweak header button scaling at 100%
>  - enable preview features in tests
>  - add preview feature
>  - add preview feature
>  - Merge branch 'master' into feature/extended-window
>  - tweak header button glyph scaling
>  - ... and 67 more: https://git.openjdk.org/jfx/compare/f31d00d8...88e50163

Sorry, I am getting compiler error


Description	Resource	Type	Path	Location
The import com.oracle.tools.fx.monkey.tools.ModalWindow cannot be resolved	MainWindow.java	Java Problem	/MonkeyTester/src/com/oracle/tools/fx/monkey	line 54

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2784418906

From angorya at openjdk.org  Mon Apr  7 19:29:35 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Apr 2025 19:29:35 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v60]
In-Reply-To: <Ohv7C4KnzALtx-G8LJDjMVkn9FCsRIwharDCt31hvoc=.d9ae6332-a311-428b-984b-961c8f8b3a10@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <BvVVHUwPw3i2wwfdlKAzKjmV4qAhSczdiZxvkn56ZUY=.5942d124-9c19-42d6-a12a-7eb32d662fe4@github.com>
 <qXX6JFP_GEflTyUUz7O967TPae_Rsgok0-eMQh1DhgY=.6f8f5398-1f0e-4a73-9d4e-d3f24370959b@github.com>
 <Ohv7C4KnzALtx-G8LJDjMVkn9FCsRIwharDCt31hvoc=.d9ae6332-a311-428b-984b-961c8f8b3a10@github.com>
Message-ID: <fJ8pPedRIi-LBS6wzxkOyYd2cCQCAy-iUErS19MUY7I=.be49a39a-3cc4-4b82-8518-ca4fd35ec53d@github.com>

On Mon, 7 Apr 2025 19:02:21 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 854:
>> 
>>> 852:             return minimum
>>> 853:                 ? computeChildMinAreaHeight(child, -1, margin, width, false)
>>> 854:                 : computeChildPrefAreaHeight(child, -1, margin, width, false);
>> 
>> this change is not doc-related - was it somehow omitted from before?
>
> This was a leftover from a merge conflict that was caused by recent changes to the `Region.computeChildMinAreaHeight` and `Region.computeChildPrefAreaHeight` methods. The commit message is just a bit sloppy.

just wanted to make sure it's intended.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2031881634

From angorya at openjdk.org  Mon Apr  7 19:37:27 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Apr 2025 19:37:27 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v25]
In-Reply-To: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
Message-ID: <FSGxqaTjt6T7_N3uDzucGJWZjl2lBLI7FM5oSqxEXj0=.56de0fc6-9dce-4944-9fae-cc29f8cd674f@github.com>

> Please refer to
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
> 
> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
> 
> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
> 
> 
>     /**
>      * Obtains the snapshot of the current text layout information.
>      * @return the layout information
>      * @since 25
>      */
>     public final LayoutInfo getLayoutInfo()
> 
> 
> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
> 
> - caret information
> - text lines: offsets and bounds
> - overall layout bounds
> - text selection geometry
> - strike-through geometry
> - underline geometry
> 
> 
> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
> 
> 
>     /**
>      * Returns the shape for the strike-through in local coordinates.
>      *
>      * @param start the beginning character index for the range
>      * @param end the end character index (non-inclusive) for the range
>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>      * @since 25
>      */
>     public final PathElement[] strikeThroughShape(int start, int end)
> 
> 
> 
> 
> ## WARNING
> 
> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
> 
> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
> 
> 
> 
> ## Testing
> 
> The new APIs can be visually tested using the Monkey Tester on this branch:
> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
> 
> in the Text and TextFlow pages:
> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
> 
> Two very basic headful tests have been added.
> 
> 
> ## See Also
> 
> https://github.com/FXMisc/RichTextFX/pull/1246

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  sealed

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1596/files
  - new: https://git.openjdk.org/jfx/pull/1596/files/fa23f097..4d2bdf5d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=24
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=23-24

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1596.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1596/head:pull/1596

PR: https://git.openjdk.org/jfx/pull/1596

From angorya at openjdk.org  Mon Apr  7 19:37:27 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Apr 2025 19:37:27 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v23]
In-Reply-To: <6LpOGuOLQYEQcLMYmphUkuwxp1yU7OKH119h9uB33fo=.308e1fd2-5be6-46d1-9370-c6a5416fcf4f@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <COXsxBJaTLOpBjcyoBzPLmqRy6AN7n7uW_5J4vF0AVA=.647965aa-780a-4706-8248-a621fe1625b7@github.com>
 <AIr0yEWoXFRtchwnd0T-wdyOgh6A-TOmVa5iWhTxfHg=.9a400757-46ab-4c9c-963b-e1205d1e2e5d@github.com>
 <6LpOGuOLQYEQcLMYmphUkuwxp1yU7OKH119h9uB33fo=.308e1fd2-5be6-46d1-9370-c6a5416fcf4f@github.com>
Message-ID: <mJA7y4Qmm_XC05QtxhuQYGVSQyHRIXMCkBCWDL75VB0=.9b665de8-c3d8-491b-bfe6-99e91ff9d7dd@github.com>

On Mon, 7 Apr 2025 18:54:00 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> I think a class should always be final or sealed by default

contr-argument: testing.  having extendable classes makes it easier to mock, although in the case of a platform your argument carries greater weight.

I can make it `sealed`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1596#issuecomment-2784426742

From mstrauss at openjdk.org  Mon Apr  7 19:46:23 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 7 Apr 2025 19:46:23 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v61]
In-Reply-To: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
Message-ID: <Gy_MJlnbYn6FaNsWKaLm-3GpaeZ5HvY2euCsKNdf2Wo=.b21b9eb1-cb9b-4d55-8f67-c367fe1b26b0@github.com>

> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style.

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  remove import

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1605/files
  - new: https://git.openjdk.org/jfx/pull/1605/files/88e50163..63215fc8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=60
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=59-60

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1605.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605

PR: https://git.openjdk.org/jfx/pull/1605

From mstrauss at openjdk.org  Mon Apr  7 19:46:23 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 7 Apr 2025 19:46:23 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v60]
In-Reply-To: <sk1iIL2ZFFhAIvLtwuQy6FTxN-UeCPJlDaORUV9bhEg=.2fcff91b-6747-4f3f-9900-3f8f5e5455b6@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <BvVVHUwPw3i2wwfdlKAzKjmV4qAhSczdiZxvkn56ZUY=.5942d124-9c19-42d6-a12a-7eb32d662fe4@github.com>
 <sk1iIL2ZFFhAIvLtwuQy6FTxN-UeCPJlDaORUV9bhEg=.2fcff91b-6747-4f3f-9900-3f8f5e5455b6@github.com>
Message-ID: <uNaSfnRBnblVZ1-JOlSUNfjlWXICcfBfNIiWUxHiNAE=.e7f5a720-8a50-441f-bca2-f72c52456a96@github.com>

On Mon, 7 Apr 2025 19:26:58 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Sorry, I am getting compiler error
> 
> ```
> Description	Resource	Type	Path	Location
> The import com.oracle.tools.fx.monkey.tools.ModalWindow cannot be resolved	MainWindow.java	Java Problem	/MonkeyTester/src/com/oracle/tools/fx/monkey	line 54
> ```

Good catch, that also came in with the recent merge.

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2784446844

From angorya at openjdk.org  Mon Apr  7 19:46:24 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Apr 2025 19:46:24 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v60]
In-Reply-To: <BvVVHUwPw3i2wwfdlKAzKjmV4qAhSczdiZxvkn56ZUY=.5942d124-9c19-42d6-a12a-7eb32d662fe4@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <BvVVHUwPw3i2wwfdlKAzKjmV4qAhSczdiZxvkn56ZUY=.5942d124-9c19-42d6-a12a-7eb32d662fe4@github.com>
Message-ID: <ZhJ1Or2q7lrRvAm3-0fXrxdxBMYrIjkkVM9XZ-udFCc=.1c599688-59bf-4c15-aca1-6ca8c6974804@github.com>

On Sun, 6 Apr 2025 09:29:33 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style.
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 77 commits:
> 
>  - doc update
>  - Merge branch 'master' into feature/extended-window
>    
>    # Conflicts:
>    #	tests/manual/monkey/src/com/oracle/tools/fx/monkey/MainWindow.java
>    #	tests/manual/monkey/src/com/oracle/tools/fx/monkey/tools/ModalWindow.java
>  - documentation
>  - documentation
>  - tweak header button scaling at 100%
>  - enable preview features in tests
>  - add preview feature
>  - add preview feature
>  - Merge branch 'master' into feature/extended-window
>  - tweak header button glyph scaling
>  - ... and 67 more: https://git.openjdk.org/jfx/compare/f31d00d8...88e50163

Which IDE are you using (if any)?

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2784450119

From mstrauss at openjdk.org  Mon Apr  7 19:52:25 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 7 Apr 2025 19:52:25 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v60]
In-Reply-To: <ZhJ1Or2q7lrRvAm3-0fXrxdxBMYrIjkkVM9XZ-udFCc=.1c599688-59bf-4c15-aca1-6ca8c6974804@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <BvVVHUwPw3i2wwfdlKAzKjmV4qAhSczdiZxvkn56ZUY=.5942d124-9c19-42d6-a12a-7eb32d662fe4@github.com>
 <ZhJ1Or2q7lrRvAm3-0fXrxdxBMYrIjkkVM9XZ-udFCc=.1c599688-59bf-4c15-aca1-6ca8c6974804@github.com>
Message-ID: <8CTc_12MwkaVYCgtg5U4vF1YmLTNL3UfmAuyJt-oCHM=.ade8295b-5573-4c76-8422-f8e28a7bcb2a@github.com>

On Mon, 7 Apr 2025 19:41:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Which IDE are you using (if any)?

IntelliJ, which doesn't give me code insight into MonkeyTester because it's not part of the Gradle project. I usually don't use an IDE for MonkeyTester, but just edit the text files and compile it on the command line.

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2784467215

From angorya at openjdk.org  Mon Apr  7 19:55:27 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Apr 2025 19:55:27 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v61]
In-Reply-To: <Gy_MJlnbYn6FaNsWKaLm-3GpaeZ5HvY2euCsKNdf2Wo=.b21b9eb1-cb9b-4d55-8f67-c367fe1b26b0@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <Gy_MJlnbYn6FaNsWKaLm-3GpaeZ5HvY2euCsKNdf2Wo=.b21b9eb1-cb9b-4d55-8f67-c367fe1b26b0@github.com>
Message-ID: <AjQ4yck_0e-wnOKsQEOzOvnOskFUEqO0jIznl_v1sGY=.4550bcfb-762e-4d7d-8dda-e491a20a3d90@github.com>

On Mon, 7 Apr 2025 19:46:23 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove import

Interesting, I can have jfx project(s) along with the two monkey tester projects (jfx and standalone) in one workspace in Eclipse.

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2784473383

From angorya at openjdk.org  Mon Apr  7 19:59:24 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Apr 2025 19:59:24 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v61]
In-Reply-To: <Gy_MJlnbYn6FaNsWKaLm-3GpaeZ5HvY2euCsKNdf2Wo=.b21b9eb1-cb9b-4d55-8f67-c367fe1b26b0@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <Gy_MJlnbYn6FaNsWKaLm-3GpaeZ5HvY2euCsKNdf2Wo=.b21b9eb1-cb9b-4d55-8f67-c367fe1b26b0@github.com>
Message-ID: <42X_MhUzDQuBnKg5CxKRENiv5ClH2G55z2k6y2OOvH4=.da13bfb5-5da8-4a06-af07-0ae42a5e8d64@github.com>

On Mon, 7 Apr 2025 19:46:23 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove import

thank you for resolving the last compilation error.  minimal testing with macOS looks good.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2747966116

From angorya at openjdk.org  Mon Apr  7 21:53:26 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Apr 2025 21:53:26 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v6]
In-Reply-To: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
Message-ID: <YQ5ftZm4trO3ibl8xXJXBRYa_gdwt2zTmLHwu4Iyh8I=.c6370b68-5882-4efa-bfea-fd8dd815fbc9@github.com>

> Additional RichTextArea API tests.

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
 - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
 - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
 - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
 - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
 - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
 - Merge remote-tracking branch 'origin/8348736.rta.followup.2' into 8347359.rta.api.tests
 - review comments
 - Merge remote-tracking branch 'origin/8348736.rta.followup.2' into
   8347359.rta.api.tests
 - newlines
 - ... and 14 more: https://git.openjdk.org/jfx/compare/1b26b66e...f78f5415

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

Changes: https://git.openjdk.org/jfx/pull/1677/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1677&range=05
  Stats: 1383 lines in 10 files changed: 1323 ins; 29 del; 31 mod
  Patch: https://git.openjdk.org/jfx/pull/1677.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1677/head:pull/1677

PR: https://git.openjdk.org/jfx/pull/1677

From angorya at openjdk.org  Mon Apr  7 22:52:23 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Apr 2025 22:52:23 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header
In-Reply-To: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
Message-ID: <sSZ-8-377l9cgSgItBQvA2GcBVlbCi9ZwFN78qgHV2c=.acdf82a5-69fe-4203-a78e-d73a7ff7788c@github.com>

On Tue, 1 Apr 2025 17:31:14 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> Note: The JBS issue [JDK-8207333](https://bugs.openjdk.org/browse/JDK-8207333) refers to Linux, but it happens on macOS too. 
> 
> When a TableColumn has a ContextMenu, if the user right clicks on the tableColumnHeader, the ContextMenu shows up, but, as described on the issue, on macOS and Linux, the table gets sorted as well.
> 
> Currently, `TableColumnHeader#mouseReleasedHandler` checks for `MouseEvent::isPopupTriggered`, but it doesn't have a check on `mousePressed`. However,  it can be seen that a right click on the header has the following values for `MouseEvent:: isPopupTriggered` on the different platforms and mouse pressed and released events:
> 
> | isPopupTriggered on: | Windows  | macOS | Linux |
> | ------------- | ------------- | ------------- | ------------- |
> | mousePressed  | false  | true | true |
> | mouseReleased  | true  | false | false?|
> 
> Also, the JavaDoc for `MouseEvent::isPopupTriggered` clearly states that:
> 
>> **Note**: Popup menus are triggered differently on different systems. Therefore, `popupTrigger` should be checked in both `onMousePressed` and `mouseReleased` for proper cross-platform functionality.
> 
> Therefore, this PR adds a check to `MouseEvent::isPopupTrigger` in the mouse pressed event, that can be used later on to cancel the header sorting when the mouse released event happens.
> 
> Also a system test has been added. It fails on macOS and Linux, and passes on Windows before this PR, and passes on the three platforms with this PR.

@Ziad-Mid could you be the second reviewer?

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

PR Comment: https://git.openjdk.org/jfx/pull/1754#issuecomment-2784801713

From jbhaskar at openjdk.org  Tue Apr  8 03:32:43 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Tue, 8 Apr 2025 03:32:43 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
 [v10]
In-Reply-To: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
Message-ID: <Hacu3pAPCoiJBde9-lcedQjdihZA40KX6eqxP3dc8uk=.ee5739e8-b16f-4fa2-a6ff-239c8099b7a5@github.com>

> Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.

Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:

  mock push for github gradle error

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1759/files
  - new: https://git.openjdk.org/jfx/pull/1759/files/a1c5e2df..513f0538

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1759&range=09
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1759&range=08-09

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1759.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1759/head:pull/1759

PR: https://git.openjdk.org/jfx/pull/1759

From arapte at openjdk.org  Tue Apr  8 06:45:30 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 8 Apr 2025 06:45:30 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
 [v10]
In-Reply-To: <Hacu3pAPCoiJBde9-lcedQjdihZA40KX6eqxP3dc8uk=.ee5739e8-b16f-4fa2-a6ff-239c8099b7a5@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
 <Hacu3pAPCoiJBde9-lcedQjdihZA40KX6eqxP3dc8uk=.ee5739e8-b16f-4fa2-a6ff-239c8099b7a5@github.com>
Message-ID: <XMt7EOxh1OW64rUCY0ziNl-W0vI2mh45U3RY-vuKsCo=.5545e36d-4562-47f8-89e8-9a34be7e3669@github.com>

On Tue, 8 Apr 2025 03:32:43 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.
>
> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mock push for github gradle error

LGTM

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1759#pullrequestreview-2748836439

From jbhaskar at openjdk.org  Tue Apr  8 07:42:36 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Tue, 8 Apr 2025 07:42:36 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
 [v11]
In-Reply-To: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
Message-ID: <Ylg-PrQCjZGaAEYng108SUI5YUsZHhj0HrpAk-PGe_U=.892ccf7b-f2fa-4bdc-9bad-e3011c518668@github.com>

> Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.

Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:

  remove extra line

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1759/files
  - new: https://git.openjdk.org/jfx/pull/1759/files/513f0538..6a340eca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1759&range=10
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1759&range=09-10

  Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1759.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1759/head:pull/1759

PR: https://git.openjdk.org/jfx/pull/1759

From arapte at openjdk.org  Tue Apr  8 07:45:24 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 8 Apr 2025 07:45:24 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
 [v11]
In-Reply-To: <Ylg-PrQCjZGaAEYng108SUI5YUsZHhj0HrpAk-PGe_U=.892ccf7b-f2fa-4bdc-9bad-e3011c518668@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
 <Ylg-PrQCjZGaAEYng108SUI5YUsZHhj0HrpAk-PGe_U=.892ccf7b-f2fa-4bdc-9bad-e3011c518668@github.com>
Message-ID: <SN_NnIMPDPh-m25LBxA9M-mkus5icXMFWJuYnQJu7dU=.38ddfde9-aef6-4209-87e5-759662a658db@github.com>

On Tue, 8 Apr 2025 07:42:36 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.
>
> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove extra line

Marked as reviewed by arapte (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1759#pullrequestreview-2748998658

From rmarchenko at openjdk.org  Tue Apr  8 07:52:23 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Tue, 8 Apr 2025 07:52:23 GMT
Subject: RFR: 8350284: WebKit 620.1 crashes on startup on Windows x86 32-bit
Message-ID: <9ePwoSSozY-9UjvaimsTpfVYQ1FYLBXSCmIbuXWgaLk=.03668ea6-6060-4e6a-b406-d6c9c94049f7@github.com>

All the crashes are on "`movaps`" instructions, like "`movaps xmmword ptr [esi+0x30], xmm0`".

"`movaps`" must operate with aligned addresses as 
> When the source or destination operand is a memory operand, the operand must be aligned on a 16-byte boundary or a general-protection exception (#GP) is generated

written in docs. When crashes, ESI contains value like `0x27DB63A8`, so it doesn?t seem aligned to 16-byte boundary. The line "`siginfo: ExceptionCode=0xc0000005, reading address 0xffffffff`" from `hs_err` file implicitly says it is GP, not a real "reading address 0xffffffff".

It might be related to clang-cl bug, see https://github.com/llvm/llvm-project/issues/55844

The workaround is to disable SSE when building 32bit on Windows. (`-mno-sse`)

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

Commit messages:
 - 8350284: WebKit 620.1 crashes on startup on Windows x86 32-bit

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

PR: https://git.openjdk.org/jfx/pull/1764

From zelmidaoui at openjdk.org  Tue Apr  8 10:56:28 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Tue, 8 Apr 2025 10:56:28 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header
In-Reply-To: <sSZ-8-377l9cgSgItBQvA2GcBVlbCi9ZwFN78qgHV2c=.acdf82a5-69fe-4203-a78e-d73a7ff7788c@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <sSZ-8-377l9cgSgItBQvA2GcBVlbCi9ZwFN78qgHV2c=.acdf82a5-69fe-4203-a78e-d73a7ff7788c@github.com>
Message-ID: <Nh_ee-GLjBVlYnU_pBobWpQAlJy9P_A536HUtqvCMRg=.a2f5562c-eedb-4411-9922-96554be5a69f@github.com>

On Mon, 7 Apr 2025 22:48:44 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> @Ziad-Mid could you be the second reviewer?

I can't test on Linux , I will check same for macOS

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

PR Comment: https://git.openjdk.org/jfx/pull/1754#issuecomment-2786037078

From kcr at openjdk.org  Tue Apr  8 11:47:34 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Apr 2025 11:47:34 GMT
Subject: RFR: 8350284: WebKit 620.1 crashes on startup on Windows x86
 32-bit
In-Reply-To: <9ePwoSSozY-9UjvaimsTpfVYQ1FYLBXSCmIbuXWgaLk=.03668ea6-6060-4e6a-b406-d6c9c94049f7@github.com>
References: <9ePwoSSozY-9UjvaimsTpfVYQ1FYLBXSCmIbuXWgaLk=.03668ea6-6060-4e6a-b406-d6c9c94049f7@github.com>
Message-ID: <pAiIpDnviaeXnCaCFlI0DpNCd39QQwMD9m9EQAMzAsM=.be7fa97d-27dd-44f4-bea1-6ab0925bda4b@github.com>

On Tue, 8 Apr 2025 07:48:19 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> All the crashes are on "`movaps`" instructions, like "`movaps xmmword ptr [esi+0x30], xmm0`".
> 
> "`movaps`" must operate with aligned addresses as 
>> When the source or destination operand is a memory operand, the operand must be aligned on a 16-byte boundary or a general-protection exception (#GP) is generated
> 
> written in docs. When crashes, ESI contains value like `0x27DB63A8`, so it doesn?t seem aligned to 16-byte boundary. The line "`siginfo: ExceptionCode=0xc0000005, reading address 0xffffffff`" from `hs_err` file implicitly says it is GP, not a real "reading address 0xffffffff".
> 
> It might be related to clang-cl bug, see https://github.com/llvm/llvm-project/issues/55844
> 
> The workaround is to disable SSE when building 32bit on Windows. (`-mno-sse`)

@wkia Thank you. We'll review this.

Reviewers: @kevinrushforth @jaybhaskar

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

PR Comment: https://git.openjdk.org/jfx/pull/1764#issuecomment-2786164502

From jbhaskar at openjdk.org  Tue Apr  8 11:56:34 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Tue, 8 Apr 2025 11:56:34 GMT
Subject: RFR: 8353916: Unexpected event type for DOM mutation events with
 WebKit 620.1
Message-ID: <q_vL2fBbia2j0fYgEp_OD_v64llsXQO9s4Zl38Mi8aw=.34b8bd5d-6a86-419e-a897-b2b96e865e4e@github.com>

Issue: In WebKit 619.1, MutationEvent was properly handled and overridden, so casting to it worked as expected. In newer WebKit versions (like the one embedded in current JavaFX), MutationEvent is deprecated, and the actual event dispatched is just a generic DOM Event.
Solution: restore the old style mutation event support, which will cause the returned events to again be instances of MutationEvent.

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

Commit messages:
 - Merge branch 'openjdk:master' into mutevent
 - mute evnt fix

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

PR: https://git.openjdk.org/jfx/pull/1765

From kcr at openjdk.org  Tue Apr  8 11:57:24 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Apr 2025 11:57:24 GMT
Subject: RFR: 8353916: Unexpected event type for DOM mutation events with
 WebKit 620.1
In-Reply-To: <q_vL2fBbia2j0fYgEp_OD_v64llsXQO9s4Zl38Mi8aw=.34b8bd5d-6a86-419e-a897-b2b96e865e4e@github.com>
References: <q_vL2fBbia2j0fYgEp_OD_v64llsXQO9s4Zl38Mi8aw=.34b8bd5d-6a86-419e-a897-b2b96e865e4e@github.com>
Message-ID: <WpqxemlMdqSnx3DhH3IvnSlAtjzfB9bsW2cwRWS6Z8M=.4023c082-0c6c-43b9-8916-a412ccb8bee0@github.com>

On Tue, 8 Apr 2025 11:50:05 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: In WebKit 619.1, MutationEvent was properly handled and overridden, so casting to it worked as expected. In newer WebKit versions (like the one embedded in current JavaFX), MutationEvent is deprecated, and the actual event dispatched is just a generic DOM Event.
> Solution: restore the old style mutation event support, which will cause the returned events to again be instances of MutationEvent.

Reviewers: @kevinrushforth @arapte

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

PR Comment: https://git.openjdk.org/jfx/pull/1765#issuecomment-2786189921

From kcr at openjdk.org  Tue Apr  8 12:35:26 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Apr 2025 12:35:26 GMT
Subject: RFR: 8350284: WebKit 620.1 crashes on startup on Windows x86
 32-bit
In-Reply-To: <9ePwoSSozY-9UjvaimsTpfVYQ1FYLBXSCmIbuXWgaLk=.03668ea6-6060-4e6a-b406-d6c9c94049f7@github.com>
References: <9ePwoSSozY-9UjvaimsTpfVYQ1FYLBXSCmIbuXWgaLk=.03668ea6-6060-4e6a-b406-d6c9c94049f7@github.com>
Message-ID: <Y3pkBgi7YUqgD2faQW3yDwcX5wsQlMfIsA9QhLbv9gc=.e3c55fd4-25e4-4168-bcb9-e38c95669ac8@github.com>

On Tue, 8 Apr 2025 07:48:19 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> All the crashes are on "`movaps`" instructions, like "`movaps xmmword ptr [esi+0x30], xmm0`".
> 
> "`movaps`" must operate with aligned addresses as 
>> When the source or destination operand is a memory operand, the operand must be aligned on a 16-byte boundary or a general-protection exception (#GP) is generated
> 
> written in docs. When crashes, ESI contains value like `0x27DB63A8`, so it doesn?t seem aligned to 16-byte boundary. The line "`siginfo: ExceptionCode=0xc0000005, reading address 0xffffffff`" from `hs_err` file implicitly says it is GP, not a real "reading address 0xffffffff".
> 
> It might be related to clang-cl bug, see https://github.com/llvm/llvm-project/issues/55844
> 
> The workaround is to disable SSE when building 32bit on Windows. (`-mno-sse`)

The change looks correct to me, but @jaybhaskar can say for sure.

I will run a test build (on JDK 8, since that is the only release on which we still have a 32-bit build) to confirm.

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

PR Comment: https://git.openjdk.org/jfx/pull/1764#issuecomment-2786287755

From kcr at openjdk.org  Tue Apr  8 13:51:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Apr 2025 13:51:21 GMT
Subject: RFR: 8350284: WebKit 620.1 crashes on startup on Windows x86
 32-bit
In-Reply-To: <9ePwoSSozY-9UjvaimsTpfVYQ1FYLBXSCmIbuXWgaLk=.03668ea6-6060-4e6a-b406-d6c9c94049f7@github.com>
References: <9ePwoSSozY-9UjvaimsTpfVYQ1FYLBXSCmIbuXWgaLk=.03668ea6-6060-4e6a-b406-d6c9c94049f7@github.com>
Message-ID: <yqv-rNKLp6_5utJ_wDpNlzinPIoHw4uFJzFPObq1jho=.34357e70-6f7d-4ded-acbe-2ace5cca9c9c@github.com>

On Tue, 8 Apr 2025 07:48:19 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> All the crashes are on "`movaps`" instructions, like "`movaps xmmword ptr [esi+0x30], xmm0`".
> 
> "`movaps`" must operate with aligned addresses as 
>> When the source or destination operand is a memory operand, the operand must be aligned on a 16-byte boundary or a general-protection exception (#GP) is generated
> 
> written in docs. When crashes, ESI contains value like `0x27DB63A8`, so it doesn?t seem aligned to 16-byte boundary. The line "`siginfo: ExceptionCode=0xc0000005, reading address 0xffffffff`" from `hs_err` file implicitly says it is GP, not a real "reading address 0xffffffff".
> 
> It might be related to clang-cl bug, see https://github.com/llvm/llvm-project/issues/55844
> 
> The workaround is to disable SSE when building 32bit on Windows. (`-mno-sse`)

This looks good to me. A quick sanity test passed. We will do a little more testing then approve.

I left one inline comment about adding a note indicating that this is for the "JAVA" platform.

modules/javafx.web/src/main/native/Source/cmake/WebKitCompilerFlags.cmake line 154:

> 152:         WEBKIT_PREPEND_GLOBAL_COMPILER_FLAGS(-Wno-sign-compare
> 153:                                              -Wno-deprecated-declarations)
> 154:         if (WTF_CPU_X86 AND NOT CMAKE_CROSSCOMPILING)

Please add the following comment above line 154:


        # Disable SSE for 32-bit Windows on JAVA platform

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

PR Review: https://git.openjdk.org/jfx/pull/1764#pullrequestreview-2750051129
PR Review Comment: https://git.openjdk.org/jfx/pull/1764#discussion_r2033233369

From angorya at openjdk.org  Tue Apr  8 14:43:33 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 8 Apr 2025 14:43:33 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
 [v11]
In-Reply-To: <Ylg-PrQCjZGaAEYng108SUI5YUsZHhj0HrpAk-PGe_U=.892ccf7b-f2fa-4bdc-9bad-e3011c518668@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
 <Ylg-PrQCjZGaAEYng108SUI5YUsZHhj0HrpAk-PGe_U=.892ccf7b-f2fa-4bdc-9bad-e3011c518668@github.com>
Message-ID: <2Ua86xV73Ute6eLdYuzIXRoFDU76h7m6UV6qcgYaxSc=.7537c829-83bc-49bb-80ae-1f9080f4b23a@github.com>

On Tue, 8 Apr 2025 07:42:36 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.
>
> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove extra line

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1759#pullrequestreview-2750256527

From angorya at openjdk.org  Tue Apr  8 14:50:38 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 8 Apr 2025 14:50:38 GMT
Subject: RFR: 8340464: [TestBug] Convert parametrized base tests to JUnit 5
 [v11]
In-Reply-To: <Ylg-PrQCjZGaAEYng108SUI5YUsZHhj0HrpAk-PGe_U=.892ccf7b-f2fa-4bdc-9bad-e3011c518668@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
 <Ylg-PrQCjZGaAEYng108SUI5YUsZHhj0HrpAk-PGe_U=.892ccf7b-f2fa-4bdc-9bad-e3011c518668@github.com>
Message-ID: <RqdAsm3qClpgwLoUGjCiqunDk7cgmGJbRC9BKE1HKWs=.7abc03b7-c435-4bdc-abbe-7fb0e5eb9119@github.com>

On Tue, 8 Apr 2025 07:42:36 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.
>
> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove extra line

The GHA failure is unrelated, see [JDK-8353947](https://bugs.openjdk.org/browse/JDK-8353947)
GHA: Windows build now fails with connection error

> [mock push for github gradle error](https://github.com/openjdk/jfx/pull/1759/commits/513f0538df0bc045ed9fb90272d1e8643814ac24)

you could simply re-run the GHA jobs from the UI: click on the "..." [more actions] link, click on the failed job, there is a button somewhere at the top right with "Re-run failed jobs".

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

PR Comment: https://git.openjdk.org/jfx/pull/1759#issuecomment-2786693990
PR Comment: https://git.openjdk.org/jfx/pull/1759#issuecomment-2786702033

From jbhaskar at openjdk.org  Tue Apr  8 14:50:40 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Tue, 8 Apr 2025 14:50:40 GMT
Subject: Integrated: 8340464: [TestBug] Convert parametrized base tests to
 JUnit 5
In-Reply-To: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
References: <C-dEdZvzPGxB4a5WqsbEus0xhaR4pELG_PtpGXB-Gbo=.b13414b6-7ad9-4379-a59c-081386d2944f@github.com>
Message-ID: <NFD1CgB5RPEp4x7OA45Yfs08Bsdup8nmk4KKoXDKuVA=.b030c6ef-1678-451b-a688-5f7dd6af8385@github.com>

On Thu, 3 Apr 2025 12:34:37 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Migrated JUnit 4 tests in the jafax.base module to JUnit 5, replacing deprecated APIs, updating assertions, and refactoring test structures to align with JUnit 5's improved features.

This pull request has now been integrated.

Changeset: 61a248d1
Author:    Jay Bhaskar <jbhaskar at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/61a248d1e55b3f6bd5cfe6016003a40cc979b693
Stats:     4556 lines in 41 files changed: 1637 ins; 790 del; 2129 mod

8340464: [TestBug] Convert parametrized base tests to JUnit 5

Reviewed-by: angorya, arapte

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

PR: https://git.openjdk.org/jfx/pull/1759

From rmarchenko at openjdk.org  Tue Apr  8 15:53:05 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Tue, 8 Apr 2025 15:53:05 GMT
Subject: RFR: 8350284: WebKit 620.1 crashes on startup on Windows x86
 32-bit [v2]
In-Reply-To: <9ePwoSSozY-9UjvaimsTpfVYQ1FYLBXSCmIbuXWgaLk=.03668ea6-6060-4e6a-b406-d6c9c94049f7@github.com>
References: <9ePwoSSozY-9UjvaimsTpfVYQ1FYLBXSCmIbuXWgaLk=.03668ea6-6060-4e6a-b406-d6c9c94049f7@github.com>
Message-ID: <d2twKJVdqO1YPpCeCx_S_i0wVPbz-kWug2y2_rpUJe8=.6c18f85f-6838-4aa5-bc32-3b5eac41bdbe@github.com>

> All the crashes are on "`movaps`" instructions, like "`movaps xmmword ptr [esi+0x30], xmm0`".
> 
> "`movaps`" must operate with aligned addresses as 
>> When the source or destination operand is a memory operand, the operand must be aligned on a 16-byte boundary or a general-protection exception (#GP) is generated
> 
> written in docs. When crashes, ESI contains value like `0x27DB63A8`, so it doesn?t seem aligned to 16-byte boundary. The line "`siginfo: ExceptionCode=0xc0000005, reading address 0xffffffff`" from `hs_err` file implicitly says it is GP, not a real "reading address 0xffffffff".
> 
> It might be related to clang-cl bug, see https://github.com/llvm/llvm-project/issues/55844
> 
> The workaround is to disable SSE when building 32bit on Windows. (`-mno-sse`)

Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:

  Update WebKitCompilerFlags.cmake

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1764/files
  - new: https://git.openjdk.org/jfx/pull/1764/files/14695e6c..f57dad8e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1764&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1764&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1764.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1764/head:pull/1764

PR: https://git.openjdk.org/jfx/pull/1764

From rmarchenko at openjdk.org  Tue Apr  8 15:53:06 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Tue, 8 Apr 2025 15:53:06 GMT
Subject: RFR: 8350284: WebKit 620.1 crashes on startup on Windows x86
 32-bit [v2]
In-Reply-To: <d2twKJVdqO1YPpCeCx_S_i0wVPbz-kWug2y2_rpUJe8=.6c18f85f-6838-4aa5-bc32-3b5eac41bdbe@github.com>
References: <9ePwoSSozY-9UjvaimsTpfVYQ1FYLBXSCmIbuXWgaLk=.03668ea6-6060-4e6a-b406-d6c9c94049f7@github.com>
 <d2twKJVdqO1YPpCeCx_S_i0wVPbz-kWug2y2_rpUJe8=.6c18f85f-6838-4aa5-bc32-3b5eac41bdbe@github.com>
Message-ID: <8EbIm2ncykzwIyydhxSTglKeRXUa62Jra4zK-vu6l8s=.dc1ead7b-8435-476a-9bd5-81f0dc5bb818@github.com>

On Tue, 8 Apr 2025 15:49:44 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> All the crashes are on "`movaps`" instructions, like "`movaps xmmword ptr [esi+0x30], xmm0`".
>> 
>> "`movaps`" must operate with aligned addresses as 
>>> When the source or destination operand is a memory operand, the operand must be aligned on a 16-byte boundary or a general-protection exception (#GP) is generated
>> 
>> written in docs. When crashes, ESI contains value like `0x27DB63A8`, so it doesn?t seem aligned to 16-byte boundary. The line "`siginfo: ExceptionCode=0xc0000005, reading address 0xffffffff`" from `hs_err` file implicitly says it is GP, not a real "reading address 0xffffffff".
>> 
>> It might be related to clang-cl bug, see https://github.com/llvm/llvm-project/issues/55844
>> 
>> The workaround is to disable SSE when building 32bit on Windows. (`-mno-sse`)
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update WebKitCompilerFlags.cmake

modules/javafx.web/src/main/native/Source/cmake/WebKitCompilerFlags.cmake line 154:

> 152:         WEBKIT_PREPEND_GLOBAL_COMPILER_FLAGS(-Wno-sign-compare
> 153:                                              -Wno-deprecated-declarations)
> 154:         if (WTF_CPU_X86 AND NOT CMAKE_CROSSCOMPILING)

Suggestion:

        # Disable SSE for 32-bit Windows on JAVA platform
        if (WTF_CPU_X86 AND NOT CMAKE_CROSSCOMPILING)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1764#discussion_r2033505361

From kcr at openjdk.org  Tue Apr  8 16:08:23 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Apr 2025 16:08:23 GMT
Subject: RFR: 8350284: WebKit 620.1 crashes on startup on Windows x86
 32-bit [v2]
In-Reply-To: <d2twKJVdqO1YPpCeCx_S_i0wVPbz-kWug2y2_rpUJe8=.6c18f85f-6838-4aa5-bc32-3b5eac41bdbe@github.com>
References: <9ePwoSSozY-9UjvaimsTpfVYQ1FYLBXSCmIbuXWgaLk=.03668ea6-6060-4e6a-b406-d6c9c94049f7@github.com>
 <d2twKJVdqO1YPpCeCx_S_i0wVPbz-kWug2y2_rpUJe8=.6c18f85f-6838-4aa5-bc32-3b5eac41bdbe@github.com>
Message-ID: <GZGusLiOgpt1wzHe1V93YAsYJyz5jreYj8tGPnmnzAY=.9c8f1ae2-9b3f-421b-84b0-1ec9964d91d5@github.com>

On Tue, 8 Apr 2025 15:53:05 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> All the crashes are on "`movaps`" instructions, like "`movaps xmmword ptr [esi+0x30], xmm0`".
>> 
>> "`movaps`" must operate with aligned addresses as 
>>> When the source or destination operand is a memory operand, the operand must be aligned on a 16-byte boundary or a general-protection exception (#GP) is generated
>> 
>> written in docs. When crashes, ESI contains value like `0x27DB63A8`, so it doesn?t seem aligned to 16-byte boundary. The line "`siginfo: ExceptionCode=0xc0000005, reading address 0xffffffff`" from `hs_err` file implicitly says it is GP, not a real "reading address 0xffffffff".
>> 
>> It might be related to clang-cl bug, see https://github.com/llvm/llvm-project/issues/55844
>> 
>> The workaround is to disable SSE when building 32bit on Windows. (`-mno-sse`)
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update WebKitCompilerFlags.cmake

LGTM

Once @jaybhaskar approves, you may integrate this fix. Given that this has no impact on mainline platforms, I waive the usual 24-hour waiting period.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1764#pullrequestreview-2750572164

From jbhaskar at openjdk.org  Tue Apr  8 16:41:24 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Tue, 8 Apr 2025 16:41:24 GMT
Subject: RFR: 8350284: WebKit 620.1 crashes on startup on Windows x86
 32-bit [v2]
In-Reply-To: <d2twKJVdqO1YPpCeCx_S_i0wVPbz-kWug2y2_rpUJe8=.6c18f85f-6838-4aa5-bc32-3b5eac41bdbe@github.com>
References: <9ePwoSSozY-9UjvaimsTpfVYQ1FYLBXSCmIbuXWgaLk=.03668ea6-6060-4e6a-b406-d6c9c94049f7@github.com>
 <d2twKJVdqO1YPpCeCx_S_i0wVPbz-kWug2y2_rpUJe8=.6c18f85f-6838-4aa5-bc32-3b5eac41bdbe@github.com>
Message-ID: <PQXrti8vvy65B29nD7s_j6nfPKG-2tYeLweQsnMFT2s=.8ef8eb59-c37f-4f0b-94ac-80c36d1440a1@github.com>

On Tue, 8 Apr 2025 15:53:05 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> All the crashes are on "`movaps`" instructions, like "`movaps xmmword ptr [esi+0x30], xmm0`".
>> 
>> "`movaps`" must operate with aligned addresses as 
>>> When the source or destination operand is a memory operand, the operand must be aligned on a 16-byte boundary or a general-protection exception (#GP) is generated
>> 
>> written in docs. When crashes, ESI contains value like `0x27DB63A8`, so it doesn?t seem aligned to 16-byte boundary. The line "`siginfo: ExceptionCode=0xc0000005, reading address 0xffffffff`" from `hs_err` file implicitly says it is GP, not a real "reading address 0xffffffff".
>> 
>> It might be related to clang-cl bug, see https://github.com/llvm/llvm-project/issues/55844
>> 
>> The workaround is to disable SSE when building 32bit on Windows. (`-mno-sse`)
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update WebKitCompilerFlags.cmake

Looks good to me. basic sanity test ok

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

Marked as reviewed by jbhaskar (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1764#pullrequestreview-2750686326

From mfox at openjdk.org  Tue Apr  8 17:01:16 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 8 Apr 2025 17:01:16 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header
In-Reply-To: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
Message-ID: <AfeVF9UP8dixrNJzF1l6dJvg4cM2z6xAYky8z50jHUk=.7a5de6c9-1803-4643-ae8e-c36edfab2c07@github.com>

On Tue, 1 Apr 2025 17:31:14 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> Note: The JBS issue [JDK-8207333](https://bugs.openjdk.org/browse/JDK-8207333) refers to Linux, but it happens on macOS too. 
> 
> When a TableColumn has a ContextMenu, if the user right clicks on the tableColumnHeader, the ContextMenu shows up, but, as described on the issue, on macOS and Linux, the table gets sorted as well.
> 
> Currently, `TableColumnHeader#mouseReleasedHandler` checks for `MouseEvent::isPopupTriggered`, but it doesn't have a check on `mousePressed`. However,  it can be seen that a right click on the header has the following values for `MouseEvent:: isPopupTriggered` on the different platforms and mouse pressed and released events:
> 
> | isPopupTriggered on: | Windows  | macOS | Linux |
> | ------------- | ------------- | ------------- | ------------- |
> | mousePressed  | false  | true | true |
> | mouseReleased  | true  | false | false?|
> 
> Also, the JavaDoc for `MouseEvent::isPopupTriggered` clearly states that:
> 
>> **Note**: Popup menus are triggered differently on different systems. Therefore, `popupTrigger` should be checked in both `onMousePressed` and `mouseReleased` for proper cross-platform functionality.
> 
> Therefore, this PR adds a check to `MouseEvent::isPopupTrigger` in the mouse pressed event, that can be used later on to cancel the header sorting when the mouse released event happens.
> 
> Also a system test has been added. It fails on macOS and Linux, and passes on Windows before this PR, and passes on the three platforms with this PR.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 251:

> 249:         me.consume();
> 250: 
> 251:         header.getTableHeaderRow().columnDragLock = true;

On Mac a context menu can be invoked using the right button or the left button in conjunction with the Control key. In the second case the pop trigger flag will be set and the primary button will be down. If I'm reading the code correctly this could get the header stuck in column re-ordering mode.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 275:

> 273:     private static final EventHandler<MouseEvent> mouseReleasedHandler = me -> {
> 274:         TableColumnHeader header = (TableColumnHeader) me.getSource();
> 275:         header.getTableHeaderRow().columnDragLock = false;

On Ubuntu 22.04 the table column header is not receiving a mouse released event if a context menu is shown. Not sure where the released event is going but it's not to any node on the primary stage. The docs are vague on this but this looks like a separate bug that's making it hard to test this PR.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1754#discussion_r2033646255
PR Review Comment: https://git.openjdk.org/jfx/pull/1754#discussion_r2033647116

From kcr at openjdk.org  Tue Apr  8 17:57:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Apr 2025 17:57:27 GMT
Subject: RFR: 8350284: WebKit 620.1 crashes on startup on Windows x86
 32-bit [v2]
In-Reply-To: <d2twKJVdqO1YPpCeCx_S_i0wVPbz-kWug2y2_rpUJe8=.6c18f85f-6838-4aa5-bc32-3b5eac41bdbe@github.com>
References: <9ePwoSSozY-9UjvaimsTpfVYQ1FYLBXSCmIbuXWgaLk=.03668ea6-6060-4e6a-b406-d6c9c94049f7@github.com>
 <d2twKJVdqO1YPpCeCx_S_i0wVPbz-kWug2y2_rpUJe8=.6c18f85f-6838-4aa5-bc32-3b5eac41bdbe@github.com>
Message-ID: <X7fs0hbTxPOT0WB34EKUFhl5CulChhtX8j9mwwllMSE=.50b5b5cc-a8ed-430c-ba47-4c013287763c@github.com>

On Tue, 8 Apr 2025 15:53:05 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> All the crashes are on "`movaps`" instructions, like "`movaps xmmword ptr [esi+0x30], xmm0`".
>> 
>> "`movaps`" must operate with aligned addresses as 
>>> When the source or destination operand is a memory operand, the operand must be aligned on a 16-byte boundary or a general-protection exception (#GP) is generated
>> 
>> written in docs. When crashes, ESI contains value like `0x27DB63A8`, so it doesn?t seem aligned to 16-byte boundary. The line "`siginfo: ExceptionCode=0xc0000005, reading address 0xffffffff`" from `hs_err` file implicitly says it is GP, not a real "reading address 0xffffffff".
>> 
>> It might be related to clang-cl bug, see https://github.com/llvm/llvm-project/issues/55844
>> 
>> The workaround is to disable SSE when building 32bit on Windows. (`-mno-sse`)
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update WebKitCompilerFlags.cmake

@wkia Go ahead an integrate when you are ready.

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

PR Comment: https://git.openjdk.org/jfx/pull/1764#issuecomment-2787244969

From angorya at openjdk.org  Tue Apr  8 18:23:24 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 8 Apr 2025 18:23:24 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header
In-Reply-To: <AfeVF9UP8dixrNJzF1l6dJvg4cM2z6xAYky8z50jHUk=.7a5de6c9-1803-4643-ae8e-c36edfab2c07@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <AfeVF9UP8dixrNJzF1l6dJvg4cM2z6xAYky8z50jHUk=.7a5de6c9-1803-4643-ae8e-c36edfab2c07@github.com>
Message-ID: <KFlsFutDhFDxB8Gf6bt_isesOE6a2aAjtwqlLDxhlwc=.12597ebb-8bf7-4fc0-9f32-655b32f1154c@github.com>

On Tue, 8 Apr 2025 16:55:51 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Note: The JBS issue [JDK-8207333](https://bugs.openjdk.org/browse/JDK-8207333) refers to Linux, but it happens on macOS too. 
>> 
>> When a TableColumn has a ContextMenu, if the user right clicks on the tableColumnHeader, the ContextMenu shows up, but, as described on the issue, on macOS and Linux, the table gets sorted as well.
>> 
>> Currently, `TableColumnHeader#mouseReleasedHandler` checks for `MouseEvent::isPopupTriggered`, but it doesn't have a check on `mousePressed`. However,  it can be seen that a right click on the header has the following values for `MouseEvent:: isPopupTriggered` on the different platforms and mouse pressed and released events:
>> 
>> | isPopupTriggered on: | Windows  | macOS | Linux |
>> | ------------- | ------------- | ------------- | ------------- |
>> | mousePressed  | false  | true | true |
>> | mouseReleased  | true  | false | false?|
>> 
>> Also, the JavaDoc for `MouseEvent::isPopupTriggered` clearly states that:
>> 
>>> **Note**: Popup menus are triggered differently on different systems. Therefore, `popupTrigger` should be checked in both `onMousePressed` and `mouseReleased` for proper cross-platform functionality.
>> 
>> Therefore, this PR adds a check to `MouseEvent::isPopupTrigger` in the mouse pressed event, that can be used later on to cancel the header sorting when the mouse released event happens.
>> 
>> Also a system test has been added. It fails on macOS and Linux, and passes on Windows before this PR, and passes on the three platforms with this PR.
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 251:
> 
>> 249:         me.consume();
>> 250: 
>> 251:         header.getTableHeaderRow().columnDragLock = true;
> 
> On Mac a context menu can be invoked using the right button or the left button in conjunction with the Control key. In the second case the pop trigger flag will be set and the primary button will be down. If I'm reading the code correctly this could get the header stuck in column re-ordering mode.

Testing on macOS 15.3.2, it does not get stuck when using control+left-click, works as expected.

There is one (existing and unrelated) problem - if the user tries to dismiss the popup menu by clicking on the header, it dismisses the popup (correctly), but then proceeds to re-sort the table (unexpected).

One can say it works as designed, since the click falls on a header cell and the expected operation is to toggle the sorting, with the side effect of dismissing the popup.

On the other hand, Excel (both mac and windows) behaves differently - a click on the spreadsheet header dismisses the popup and does not select the column, as it normally does when no popup is present.

What do you guys think?

> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 275:
> 
>> 273:     private static final EventHandler<MouseEvent> mouseReleasedHandler = me -> {
>> 274:         TableColumnHeader header = (TableColumnHeader) me.getSource();
>> 275:         header.getTableHeaderRow().columnDragLock = false;
> 
> On Ubuntu 22.04 the table column header is not receiving a mouse released event if a context menu is shown. Not sure where the released event is going but it's not to any node on the primary stage. The docs are vague on this but this looks like a separate bug that's making it hard to test this PR.

what happens in the master branch (without this PR's changes)?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1754#discussion_r2033796787
PR Review Comment: https://git.openjdk.org/jfx/pull/1754#discussion_r2033797532

From kcr at openjdk.org  Tue Apr  8 18:31:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Apr 2025 18:31:18 GMT
Subject: RFR: 8353916: Unexpected event type for DOM mutation events with
 WebKit 620.1
In-Reply-To: <q_vL2fBbia2j0fYgEp_OD_v64llsXQO9s4Zl38Mi8aw=.34b8bd5d-6a86-419e-a897-b2b96e865e4e@github.com>
References: <q_vL2fBbia2j0fYgEp_OD_v64llsXQO9s4Zl38Mi8aw=.34b8bd5d-6a86-419e-a897-b2b96e865e4e@github.com>
Message-ID: <Z2gBu1iyhSEBEB2_q9ViTLMM6pBn2MqeO5UATNvtcMo=.f839c878-cf12-4394-9df8-3d46226971f0@github.com>

On Tue, 8 Apr 2025 11:50:05 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: In WebKit 619.1, MutationEvent was properly handled and overridden, so casting to it worked as expected. In newer WebKit versions (like the one embedded in current JavaFX), MutationEvent is deprecated, and the actual event dispatched is just a generic DOM Event.
> Solution: restore the old style mutation event support, which will cause the returned events to again be instances of MutationEvent.

I confirm that this restores the logic that was present in 619.1 and inadvertently missing from 620.1.

All my testing looks good.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1765#pullrequestreview-2751050495

From mfox at openjdk.org  Tue Apr  8 18:41:25 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 8 Apr 2025 18:41:25 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header
In-Reply-To: <KFlsFutDhFDxB8Gf6bt_isesOE6a2aAjtwqlLDxhlwc=.12597ebb-8bf7-4fc0-9f32-655b32f1154c@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <AfeVF9UP8dixrNJzF1l6dJvg4cM2z6xAYky8z50jHUk=.7a5de6c9-1803-4643-ae8e-c36edfab2c07@github.com>
 <KFlsFutDhFDxB8Gf6bt_isesOE6a2aAjtwqlLDxhlwc=.12597ebb-8bf7-4fc0-9f32-655b32f1154c@github.com>
Message-ID: <yil2HsS8NfdzD_M6z5c9N8PKXzIz1ecwEGUVek6d5VE=.10e36996-f20b-4264-bffc-aeaaf0375b26@github.com>

On Tue, 8 Apr 2025 18:20:54 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 275:
>> 
>>> 273:     private static final EventHandler<MouseEvent> mouseReleasedHandler = me -> {
>>> 274:         TableColumnHeader header = (TableColumnHeader) me.getSource();
>>> 275:         header.getTableHeaderRow().columnDragLock = false;
>> 
>> On Ubuntu 22.04 the table column header is not receiving a mouse released event if a context menu is shown. Not sure where the released event is going but it's not to any node on the primary stage. The docs are vague on this but this looks like a separate bug that's making it hard to test this PR.
>
> what happens in the master branch (without this PR's changes)?

I was having trouble reproducing the original bug on the master branch; the sorting is done when the mouse is released and most of the time that event never arrives (I think it does every now and then).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1754#discussion_r2033828966

From duke at openjdk.org  Tue Apr  8 18:58:25 2025
From: duke at openjdk.org (duke)
Date: Tue, 8 Apr 2025 18:58:25 GMT
Subject: RFR: 8350284: WebKit 620.1 crashes on startup on Windows x86
 32-bit [v2]
In-Reply-To: <d2twKJVdqO1YPpCeCx_S_i0wVPbz-kWug2y2_rpUJe8=.6c18f85f-6838-4aa5-bc32-3b5eac41bdbe@github.com>
References: <9ePwoSSozY-9UjvaimsTpfVYQ1FYLBXSCmIbuXWgaLk=.03668ea6-6060-4e6a-b406-d6c9c94049f7@github.com>
 <d2twKJVdqO1YPpCeCx_S_i0wVPbz-kWug2y2_rpUJe8=.6c18f85f-6838-4aa5-bc32-3b5eac41bdbe@github.com>
Message-ID: <NlhX4mSWHQ-39CrPdhqYZuRYF_bymuSY-j-HhFFFdxw=.65e664c4-84bb-4c3d-9e97-c2d77bbee441@github.com>

On Tue, 8 Apr 2025 15:53:05 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> All the crashes are on "`movaps`" instructions, like "`movaps xmmword ptr [esi+0x30], xmm0`".
>> 
>> "`movaps`" must operate with aligned addresses as 
>>> When the source or destination operand is a memory operand, the operand must be aligned on a 16-byte boundary or a general-protection exception (#GP) is generated
>> 
>> written in docs. When crashes, ESI contains value like `0x27DB63A8`, so it doesn?t seem aligned to 16-byte boundary. The line "`siginfo: ExceptionCode=0xc0000005, reading address 0xffffffff`" from `hs_err` file implicitly says it is GP, not a real "reading address 0xffffffff".
>> 
>> It might be related to clang-cl bug, see https://github.com/llvm/llvm-project/issues/55844
>> 
>> The workaround is to disable SSE when building 32bit on Windows. (`-mno-sse`)
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update WebKitCompilerFlags.cmake

@wkia 
Your change (at version f57dad8e635c7530ca3c49999031ae4b40a2ffb8) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1764#issuecomment-2787396488

From angorya at openjdk.org  Tue Apr  8 19:05:30 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 8 Apr 2025 19:05:30 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header
In-Reply-To: <yil2HsS8NfdzD_M6z5c9N8PKXzIz1ecwEGUVek6d5VE=.10e36996-f20b-4264-bffc-aeaaf0375b26@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <AfeVF9UP8dixrNJzF1l6dJvg4cM2z6xAYky8z50jHUk=.7a5de6c9-1803-4643-ae8e-c36edfab2c07@github.com>
 <KFlsFutDhFDxB8Gf6bt_isesOE6a2aAjtwqlLDxhlwc=.12597ebb-8bf7-4fc0-9f32-655b32f1154c@github.com>
 <yil2HsS8NfdzD_M6z5c9N8PKXzIz1ecwEGUVek6d5VE=.10e36996-f20b-4264-bffc-aeaaf0375b26@github.com>
Message-ID: <tcwE5uXPfHUNqTyCYaEpVPKYOfplURjVVu5y_tES9v0=.a02fac56-d4e7-4e32-bf26-90505fbc213a@github.com>

On Tue, 8 Apr 2025 18:38:29 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> what happens in the master branch (without this PR's changes)?
>
> I was having trouble reproducing the original bug on the master branch; the sorting is done when the mouse is released and most of the time that event never arrives (I think it does every now and then).

this is strange - the bug is immediately apparent.  which macOS version do you have?  although I don't think the version matters.

I am testing with an external mouse, with control-left-click, and with the double-finger-click gesture on the trackpad.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1754#discussion_r2033862942

From rmarchenko at openjdk.org  Tue Apr  8 19:06:29 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Tue, 8 Apr 2025 19:06:29 GMT
Subject: Integrated: 8350284: WebKit 620.1 crashes on startup on Windows x86
 32-bit
In-Reply-To: <9ePwoSSozY-9UjvaimsTpfVYQ1FYLBXSCmIbuXWgaLk=.03668ea6-6060-4e6a-b406-d6c9c94049f7@github.com>
References: <9ePwoSSozY-9UjvaimsTpfVYQ1FYLBXSCmIbuXWgaLk=.03668ea6-6060-4e6a-b406-d6c9c94049f7@github.com>
Message-ID: <FwrMOtv4CSr__f8WGIGZWP9Llfp2mstnldv6l8tGpzY=.0946ab4d-97f5-4d05-9534-56cb78af5dfc@github.com>

On Tue, 8 Apr 2025 07:48:19 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> All the crashes are on "`movaps`" instructions, like "`movaps xmmword ptr [esi+0x30], xmm0`".
> 
> "`movaps`" must operate with aligned addresses as 
>> When the source or destination operand is a memory operand, the operand must be aligned on a 16-byte boundary or a general-protection exception (#GP) is generated
> 
> written in docs. When crashes, ESI contains value like `0x27DB63A8`, so it doesn?t seem aligned to 16-byte boundary. The line "`siginfo: ExceptionCode=0xc0000005, reading address 0xffffffff`" from `hs_err` file implicitly says it is GP, not a real "reading address 0xffffffff".
> 
> It might be related to clang-cl bug, see https://github.com/llvm/llvm-project/issues/55844
> 
> The workaround is to disable SSE when building 32bit on Windows. (`-mno-sse`)

This pull request has now been integrated.

Changeset: d31f764b
Author:    Roman Marchenko <rmarchenko at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/d31f764b565cafdb6cafe88a9676ffba8cb7cdbb
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8350284: WebKit 620.1 crashes on startup on Windows x86 32-bit

Reviewed-by: kcr, jbhaskar

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

PR: https://git.openjdk.org/jfx/pull/1764

From mfox at openjdk.org  Tue Apr  8 20:09:29 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 8 Apr 2025 20:09:29 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header
In-Reply-To: <tcwE5uXPfHUNqTyCYaEpVPKYOfplURjVVu5y_tES9v0=.a02fac56-d4e7-4e32-bf26-90505fbc213a@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <AfeVF9UP8dixrNJzF1l6dJvg4cM2z6xAYky8z50jHUk=.7a5de6c9-1803-4643-ae8e-c36edfab2c07@github.com>
 <KFlsFutDhFDxB8Gf6bt_isesOE6a2aAjtwqlLDxhlwc=.12597ebb-8bf7-4fc0-9f32-655b32f1154c@github.com>
 <yil2HsS8NfdzD_M6z5c9N8PKXzIz1ecwEGUVek6d5VE=.10e36996-f20b-4264-bffc-aeaaf0375b26@github.com>
 <tcwE5uXPfHUNqTyCYaEpVPKYOfplURjVVu5y_tES9v0=.a02fac56-d4e7-4e32-bf26-90505fbc213a@github.com>
Message-ID: <nzvExpCOKm7rCSXVkCRy7F_7fwAlmYd9iRCvih-w5c4=.895e94e9-8a71-4e75-83a0-621dd4eb07f1@github.com>

On Tue, 8 Apr 2025 19:03:01 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I was having trouble reproducing the original bug on the master branch; the sorting is done when the mouse is released and most of the time that event never arrives (I think it does every now and then).
>
> this is strange - the bug is immediately apparent.  which macOS version do you have?  although I don't think the version matters.
> 
> I am testing with an external mouse, with control-left-click, and with the double-finger-click gesture on the trackpad.

I was having problems reproducing on Linux. No problem reproducing on macOS.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1754#discussion_r2033944488

From michaelstrau2 at gmail.com  Tue Apr  8 21:11:32 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Tue, 8 Apr 2025 23:11:32 +0200
Subject: Allow more window customization
Message-ID: <CAJEpuXSGpN7THOeKjjP=MoKyRduaDfj64zy4OgUtMf+Bdu0XJw@mail.gmail.com>

Thiago suggested in a comment on PR 1605 [0] that the proposed
EXTENDED and EXTENDED_UTILITY stage styles might not be needed, and
that the "extended client area" attribute might be a toggle that is
independent of the stage style. This would allow users to, for
example, combine an extended client area with a transparent window.

While I think that the EXTENDED style is semantically quite different
from all the other stage styles, and as such should be its own stage
style, the idea has some merit.

But instead of making "extended-ness" an independent attribute, we
should look at the TRANSPARENT and UTILITY styles. The argument for
those two being separate stage styles is a lot less convincing. Both
of these could easily be independent attributes:
Stage.initTransparency(boolean) and Stage.initUtility(boolean).

The existing TRANSPARENT style would then be equivalent to the
UNDECORATED style with the initTransparency(true) attribute, while the
existing UTILITY style would be equivalent to the DECORATED style with
the initUtility(true) attribute.

As for PR 1605, this would also eliminate the EXTENDED_UTILITY style.
That would leave us with only three main stage styles [2]: DECORATED,
UNDECORATED, EXTENDED. We would deprecate all other styles (but
probably not for removal).

Having these two attributes as independent toggles would enable more
customization, and it would also solve another enhancement request
that asks for a utility-style undecorated transparent window [1].

What do you think of this idea?

[0] https://github.com/openjdk/jfx/pull/1605
[1] https://bugs.openjdk.org/browse/JDK-8091566
[2] not counting UNIFIED, which seems to be of questionable use

From jpereda at openjdk.org  Tue Apr  8 21:21:24 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Tue, 8 Apr 2025 21:21:24 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header
In-Reply-To: <KFlsFutDhFDxB8Gf6bt_isesOE6a2aAjtwqlLDxhlwc=.12597ebb-8bf7-4fc0-9f32-655b32f1154c@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <AfeVF9UP8dixrNJzF1l6dJvg4cM2z6xAYky8z50jHUk=.7a5de6c9-1803-4643-ae8e-c36edfab2c07@github.com>
 <KFlsFutDhFDxB8Gf6bt_isesOE6a2aAjtwqlLDxhlwc=.12597ebb-8bf7-4fc0-9f32-655b32f1154c@github.com>
Message-ID: <FSlTm88mVm0boiYcw_F3YAcahe2EPjWGJ-9-jQRWU4k=.ca6e18d6-8f47-44f6-8883-7317b827bfa6@github.com>

On Tue, 8 Apr 2025 18:20:17 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 251:
>> 
>>> 249:         me.consume();
>>> 250: 
>>> 251:         header.getTableHeaderRow().columnDragLock = true;
>> 
>> On Mac a context menu can be invoked using the right button or the left button in conjunction with the Control key. In the second case the pop trigger flag will be set and the primary button will be down. If I'm reading the code correctly this could get the header stuck in column re-ordering mode.
>
> Testing on macOS 15.3.2, it does not get stuck when using control+left-click, works as expected.
> 
> There is one (existing and unrelated) problem - if the user tries to dismiss the popup menu by clicking on the header, it dismisses the popup (correctly), but then proceeds to re-sort the table (unexpected).
> 
> One can say it works as designed, since the click falls on a header cell and the expected operation is to toggle the sorting, with the side effect of dismissing the popup.
> 
> On the other hand, Excel (both mac and windows) behaves differently - a click on the spreadsheet header dismisses the popup and does not select the column, as it normally does when no popup is present.
> 
> What do you guys think?

control+left-click works as expected for me too.

When the context menu is showing, clicking anywhere outside of it, closes the popup (because of the autohide property), but doesn't consume the event. If you click on a button, for instance, it will be fired. In any case, this is the same before and after this PR, so maybe an issue for a later discussion.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1754#discussion_r2034048101

From jpereda at openjdk.org  Tue Apr  8 21:26:24 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Tue, 8 Apr 2025 21:26:24 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header
In-Reply-To: <nzvExpCOKm7rCSXVkCRy7F_7fwAlmYd9iRCvih-w5c4=.895e94e9-8a71-4e75-83a0-621dd4eb07f1@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <AfeVF9UP8dixrNJzF1l6dJvg4cM2z6xAYky8z50jHUk=.7a5de6c9-1803-4643-ae8e-c36edfab2c07@github.com>
 <KFlsFutDhFDxB8Gf6bt_isesOE6a2aAjtwqlLDxhlwc=.12597ebb-8bf7-4fc0-9f32-655b32f1154c@github.com>
 <yil2HsS8NfdzD_M6z5c9N8PKXzIz1ecwEGUVek6d5VE=.10e36996-f20b-4264-bffc-aeaaf0375b26@github.com>
 <tcwE5uXPfHUNqTyCYaEpVPKYOfplURjVVu5y_tES9v0=.a02fac56-d4e7-4e32-bf26-90505fbc213a@github.com>
 <nzvExpCOKm7rCSXVkCRy7F_7fwAlmYd9iRCvih-w5c4=.895e94e9-8a71-4e75-83a0-621dd4eb07f1@github.com>
Message-ID: <M7hdDFJMGTLsADqqOW7jelfiF5ElveznXkmMJ3-FxAg=.c40ef0e4-b506-4bad-9e3f-a63fa03bf933@github.com>

On Tue, 8 Apr 2025 20:07:05 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> this is strange - the bug is immediately apparent.  which macOS version do you have?  although I don't think the version matters.
>> 
>> I am testing with an external mouse, with control-left-click, and with the double-finger-click gesture on the trackpad.
>
> I was having problems reproducing on Linux. No problem reproducing on macOS.

On Linux I have some issues too: the test that I attached to the JBS issue doesn't fail for me on Linux, but the test that I added to this PR does fail without the fix.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1754#discussion_r2034052888

From angorya at openjdk.org  Tue Apr  8 21:50:23 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 8 Apr 2025 21:50:23 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header
In-Reply-To: <FSlTm88mVm0boiYcw_F3YAcahe2EPjWGJ-9-jQRWU4k=.ca6e18d6-8f47-44f6-8883-7317b827bfa6@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <AfeVF9UP8dixrNJzF1l6dJvg4cM2z6xAYky8z50jHUk=.7a5de6c9-1803-4643-ae8e-c36edfab2c07@github.com>
 <KFlsFutDhFDxB8Gf6bt_isesOE6a2aAjtwqlLDxhlwc=.12597ebb-8bf7-4fc0-9f32-655b32f1154c@github.com>
 <FSlTm88mVm0boiYcw_F3YAcahe2EPjWGJ-9-jQRWU4k=.ca6e18d6-8f47-44f6-8883-7317b827bfa6@github.com>
Message-ID: <m5tFmYQE3YlW0jI63xdXCBXVrOzDYB8SXqF1u-shuk0=.b13d5046-daba-47f7-bcca-216e44dd3eec@github.com>

On Tue, 8 Apr 2025 21:18:51 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> Testing on macOS 15.3.2, it does not get stuck when using control+left-click, works as expected.
>> 
>> There is one (existing and unrelated) problem - if the user tries to dismiss the popup menu by clicking on the header, it dismisses the popup (correctly), but then proceeds to re-sort the table (unexpected).
>> 
>> One can say it works as designed, since the click falls on a header cell and the expected operation is to toggle the sorting, with the side effect of dismissing the popup.
>> 
>> On the other hand, Excel (both mac and windows) behaves differently - a click on the spreadsheet header dismisses the popup and does not select the column, as it normally does when no popup is present.
>> 
>> What do you guys think?
>
> control+left-click works as expected for me too.
> 
> When the context menu is showing, clicking anywhere outside of it, closes the popup (because of the autohide property), but doesn't consume the event. If you click on a button, for instance, it will be fired. In any case, this is the same before and after this PR, so maybe an issue for a later discussion.

definitely an unrelated issue, I just wanted to ask whether you guys think it crosses the threshold for a bug.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1754#discussion_r2034076661

From angorya at openjdk.org  Tue Apr  8 21:50:35 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 8 Apr 2025 21:50:35 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header
In-Reply-To: <M7hdDFJMGTLsADqqOW7jelfiF5ElveznXkmMJ3-FxAg=.c40ef0e4-b506-4bad-9e3f-a63fa03bf933@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <AfeVF9UP8dixrNJzF1l6dJvg4cM2z6xAYky8z50jHUk=.7a5de6c9-1803-4643-ae8e-c36edfab2c07@github.com>
 <KFlsFutDhFDxB8Gf6bt_isesOE6a2aAjtwqlLDxhlwc=.12597ebb-8bf7-4fc0-9f32-655b32f1154c@github.com>
 <yil2HsS8NfdzD_M6z5c9N8PKXzIz1ecwEGUVek6d5VE=.10e36996-f20b-4264-bffc-aeaaf0375b26@github.com>
 <tcwE5uXPfHUNqTyCYaEpVPKYOfplURjVVu5y_tES9v0=.a02fac56-d4e7-4e32-bf26-90505fbc213a@github.com>
 <nzvExpCOKm7rCSXVkCRy7F_7fwAlmYd9iRCvih-w5c4=.895e94e9-8a71-4e75-83a0-621dd4eb07f1@github.com>
 <M7hdDFJMGTLsADqqOW7jelfiF5ElveznXkmMJ3-FxAg=.c40ef0e4-b506-4bad-9e3f-a63fa03bf933@github.com>
Message-ID: <Stu3_VeI4DTcvKYUbG2HsdmnR8sbkNt3WnHd0mD41SY=.cac23f52-aa88-486a-ab97-e7cc184c2ec9@github.com>

On Tue, 8 Apr 2025 21:23:15 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> I was having problems reproducing on Linux. No problem reproducing on macOS.
>
> On Linux I have some issues too: the test that I attached to the JBS issue doesn't fail for me on Linux, but the test that I added to this PR does fail without the fix.

Can you try the monkey tester?  it allows setting properties on the table view / table column at runtime...

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1754#discussion_r2034074339

From thiago.sayao at gmail.com  Tue Apr  8 22:09:33 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Tue, 8 Apr 2025 19:09:33 -0300
Subject: Allow more window customization
In-Reply-To: <CAJEpuXSGpN7THOeKjjP=MoKyRduaDfj64zy4OgUtMf+Bdu0XJw@mail.gmail.com>
References: <CAJEpuXSGpN7THOeKjjP=MoKyRduaDfj64zy4OgUtMf+Bdu0XJw@mail.gmail.com>
Message-ID: <CAAP_wunGx=bE5h=E7vJxQLKHsp-JUNW38yCWPhbtrMP80MG9Wg@mail.gmail.com>

Hi everyone,

I present the transparent decorated JavaFx stage (with some tinkering, of
course):
[image: image.png]

(I'm unsure if the list supports images, but there's a pink translucent
decorated JavaFX Stage)

I had deleted my original comment, thinking it wouldn't gain any interest,
but I'm glad it did.

I like this line of thought, as it allows more customization, as Michael
pointed out,
and prevents us from ending up with combinations of properties on the
StageStyle enum.

-- Thiago

Em ter., 8 de abr. de 2025 ?s 18:11, Michael Strau? <michaelstrau2 at gmail.com>
escreveu:

> Thiago suggested in a comment on PR 1605 [0] that the proposed
> EXTENDED and EXTENDED_UTILITY stage styles might not be needed, and
> that the "extended client area" attribute might be a toggle that is
> independent of the stage style. This would allow users to, for
> example, combine an extended client area with a transparent window.
>
> While I think that the EXTENDED style is semantically quite different
> from all the other stage styles, and as such should be its own stage
> style, the idea has some merit.
>
> But instead of making "extended-ness" an independent attribute, we
> should look at the TRANSPARENT and UTILITY styles. The argument for
> those two being separate stage styles is a lot less convincing. Both
> of these could easily be independent attributes:
> Stage.initTransparency(boolean) and Stage.initUtility(boolean).
>
> The existing TRANSPARENT style would then be equivalent to the
> UNDECORATED style with the initTransparency(true) attribute, while the
> existing UTILITY style would be equivalent to the DECORATED style with
> the initUtility(true) attribute.
>
> As for PR 1605, this would also eliminate the EXTENDED_UTILITY style.
> That would leave us with only three main stage styles [2]: DECORATED,
> UNDECORATED, EXTENDED. We would deprecate all other styles (but
> probably not for removal).
>
> Having these two attributes as independent toggles would enable more
> customization, and it would also solve another enhancement request
> that asks for a utility-style undecorated transparent window [1].
>
> What do you think of this idea?
>
> [0] https://github.com/openjdk/jfx/pull/1605
> [1] https://bugs.openjdk.org/browse/JDK-8091566
> [2] not counting UNIFIED, which seems to be of questionable use
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250408/7bf201f5/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 40802 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250408/7bf201f5/image-0001.png>

From andy.goryachev at oracle.com  Tue Apr  8 22:19:32 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 8 Apr 2025 22:19:32 +0000
Subject: Allow more window customization
In-Reply-To: <CAAP_wunGx=bE5h=E7vJxQLKHsp-JUNW38yCWPhbtrMP80MG9Wg@mail.gmail.com>
References: <CAJEpuXSGpN7THOeKjjP=MoKyRduaDfj64zy4OgUtMf+Bdu0XJw@mail.gmail.com>
 <CAAP_wunGx=bE5h=E7vJxQLKHsp-JUNW38yCWPhbtrMP80MG9Wg@mail.gmail.com>
Message-ID: <DM6PR10MB30171DF605DD87471575E01EE5B52@DM6PR10MB3017.namprd10.prod.outlook.com>

I like the idea, it's a conceptually cleaner design.

I am sure you'd agree that whatever we do should retain compatibility with the existing application code.

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Thiago Milczarek Say?o <thiago.sayao at gmail.com>
Date: Tuesday, April 8, 2025 at 15:10
To: Michael Strau? <michaelstrau2 at gmail.com>
Cc: openjfx-dev <openjfx-dev at openjdk.org>
Subject: Re: Allow more window customization
Hi everyone,

I present the transparent decorated JavaFx stage (with some tinkering, of course):
[cid:ii_m991jlyd0]

(I'm unsure if the list supports images, but there's a pink translucent decorated JavaFX Stage)

I had deleted my original comment, thinking it wouldn't gain any interest, but I'm glad it did.

I like this line of thought, as it allows more customization, as Michael pointed out,
and prevents us from ending up with combinations of properties on the StageStyle enum.

-- Thiago

Em ter., 8 de abr. de 2025 ?s 18:11, Michael Strau? <michaelstrau2 at gmail.com<mailto:michaelstrau2 at gmail.com>> escreveu:
Thiago suggested in a comment on PR 1605 [0] that the proposed
EXTENDED and EXTENDED_UTILITY stage styles might not be needed, and
that the "extended client area" attribute might be a toggle that is
independent of the stage style. This would allow users to, for
example, combine an extended client area with a transparent window.

While I think that the EXTENDED style is semantically quite different
from all the other stage styles, and as such should be its own stage
style, the idea has some merit.

But instead of making "extended-ness" an independent attribute, we
should look at the TRANSPARENT and UTILITY styles. The argument for
those two being separate stage styles is a lot less convincing. Both
of these could easily be independent attributes:
Stage.initTransparency(boolean) and Stage.initUtility(boolean).

The existing TRANSPARENT style would then be equivalent to the
UNDECORATED style with the initTransparency(true) attribute, while the
existing UTILITY style would be equivalent to the DECORATED style with
the initUtility(true) attribute.

As for PR 1605, this would also eliminate the EXTENDED_UTILITY style.
That would leave us with only three main stage styles [2]: DECORATED,
UNDECORATED, EXTENDED. We would deprecate all other styles (but
probably not for removal).

Having these two attributes as independent toggles would enable more
customization, and it would also solve another enhancement request
that asks for a utility-style undecorated transparent window [1].

What do you think of this idea?

[0] https://github.com/openjdk/jfx/pull/1605
[1] https://bugs.openjdk.org/browse/JDK-8091566
[2] not counting UNIFIED, which seems to be of questionable use
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250408/ea0744ac/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 40802 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250408/ea0744ac/image-0001.png>

From mfox at openjdk.org  Tue Apr  8 22:43:33 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 8 Apr 2025 22:43:33 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header
In-Reply-To: <m5tFmYQE3YlW0jI63xdXCBXVrOzDYB8SXqF1u-shuk0=.b13d5046-daba-47f7-bcca-216e44dd3eec@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <AfeVF9UP8dixrNJzF1l6dJvg4cM2z6xAYky8z50jHUk=.7a5de6c9-1803-4643-ae8e-c36edfab2c07@github.com>
 <KFlsFutDhFDxB8Gf6bt_isesOE6a2aAjtwqlLDxhlwc=.12597ebb-8bf7-4fc0-9f32-655b32f1154c@github.com>
 <FSlTm88mVm0boiYcw_F3YAcahe2EPjWGJ-9-jQRWU4k=.ca6e18d6-8f47-44f6-8883-7317b827bfa6@github.com>
 <m5tFmYQE3YlW0jI63xdXCBXVrOzDYB8SXqF1u-shuk0=.b13d5046-daba-47f7-bcca-216e44dd3eec@github.com>
Message-ID: <2idaRrkQMoueQYgygbBtVXNJFvFAk8tDkrMp5nzi9s4=.d98813f7-47da-476b-80a7-749e36872c2f@github.com>

On Tue, 8 Apr 2025 21:42:55 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> control+left-click works as expected for me too.
>> 
>> When the context menu is showing, clicking anywhere outside of it, closes the popup (because of the autohide property), but doesn't consume the event. If you click on a button, for instance, it will be fired. In any case, this is the same before and after this PR, so maybe an issue for a later discussion.
>
> definitely an unrelated issue, I just wanted to ask whether you guys think it crosses the threshold for a bug.

> control+left-click works as expected for me too.

For control+left-click it looks like the code will call `columnReordingStarted` but on the released event it won't call `columnReorderingComplete`. I have no idea if this will lead to problems or not.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1754#discussion_r2034128913

From credmond at certak.com  Tue Apr  8 22:48:48 2025
From: credmond at certak.com (Cormac Redmond)
Date: Tue, 8 Apr 2025 23:48:48 +0100
Subject: TabPane overflow menu showing blanks
In-Reply-To: <BYAPR10MB301380B0A50E2EAA83512B94E5AA2@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <CAGBnJPt_7_sJq8rX3fENXt3LU2=BZ5xN2mHy5L0gPd3fpFjyww@mail.gmail.com>
 <BYAPR10MB301380B0A50E2EAA83512B94E5AA2@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <CAG_-AaCbiTvMhdZ2BWu=FvWMYDgwODd4sKU+vdZS-jvcOwqc0w@mail.gmail.com>

Hi Andy,

Thank you for your reply.

That sounds good, re: a menu item factory. E.g., give the devs full control.

I think the ability to disable it (or have it disabled by default) would be
good too: a dev might not *care* about supporting the menu items in many
cases. E.g., if a TabPane only has three (graphic-based) tabs, and the user
decides to resize the window to something unusually small, then who cares
if they can't traverse the tabs, at that size? Nobody realistically expects
to be able in such a scenario anyway, and it's better to have no menu than
a buggy one.

I don't like the fact that, today, TabPane's menu can misbehave and nobody
would know it's going to happen really. I think TabPane should throw an
exception (or log a warning) when it receives nodes it knows it will not be
able to use in the menu; especially given the menu is always-on.

I think a good overall solution would be:

   1. a menu factory
   2. make the menu optional for those who don't care
   3. log warnings when a tab's header node will not be displayable in a
   menu (i.e., if the dev hasn't provided a factory and the default "menu
   factory" knowingly cannot handle it)
      1. Not really sure how JFX folks feel about logging warnings, I note
      it's minimal today in general, and probably for good reason
(e.g., where do
      you draw the line in the sand about what should be logged vs. not)

Anyway, I think the above will be achievable without any breaking /
functionality changes...?



Kind Regards,
Cormac

On Mon, 7 Apr 2025 at 17:59, Andy Goryachev <andy.goryachev at oracle.com>
wrote:

> All very good points, thank you for this writeup!
>
>
>
> This discussion relates to https://bugs.openjdk.org/browse/JDK-8353599 .
> I've been thinking how to handle this issue, and I am leaning to agree with
> the suggestion proposed in the ticket (some sort of menu item factory).
>
>
>
> The current "hacky" solution not obviously fails, but also not scalable -
> I can see developers wanting to place a Canvas, a Path, a Pane, or any
> other kind of Node and it would be nearly impossible to "clone" these in a
> maintainable manner.  With a menu item factory, however, the effort will be
> shifted on the application dev with a very simple solution.
>
>
>
> The other solution that does not involve a new API would be to limit the
> overflow menu to only list the tabs that are hidden - in this case the
> graphics Nodes can be reused by the menu items.  The problem with that
> approach is the overflow menu logic becomes more complicated, to handle the
> case when menus are hidden on both ends.
>
>
>
> What do you think?
>
>
>
> -andy
>
>
>
>
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Cormac
> Redmond <credmond at certak.com>
> *Date: *Friday, April 4, 2025 at 17:00
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *TabPane overflow menu showing blanks
>
> Hi,
>
>
>
> TabPane tabs allow you to set graphic nodes as the header and there
> appears to be no documented limitations or best-practises on this.
>
>
>
> You might assume it's perfectly reasonable to not set a Tab's text value,
> and instead set the header as a HBox, consisting of a graphic node (left)
> and a Label (itself with a text + a graphic, right), to achieve an
> icon-text-icon style header, which is not an uncommon.
>
>
>
> However, the overflow menu, when it kicks in, will not display any text or
> graphics at all (just a blank space), if your Tab has no "text" set, and
> the header graphic is not a Label or an ImageView.
>
>
>
> It's down to this self-confessed hacky code (
> https://github.com/openjdk/jfx/blob/f31d00d8f7e601c3bb28a9975dd029390ec92173/modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java#L479
> ):
>
>
>
>     /**
>      * VERY HACKY - this lets us 'duplicate' Label and ImageView nodes to
> be used in a
>      * Tab and the tabs menu at the same time.
>      */
>     private static Node clone(Node n) {
>         if (n == null) {
>             return null;
>         }
>         if (n instanceof ImageView) {
>             ImageView iv = (ImageView) n;
>             ImageView imageview = new ImageView();
>             imageview.imageProperty().bind(iv.imageProperty());
>             return imageview;
>         }
>         if (n instanceof Label) {
>             Label l = (Label)n;
>             Label label = new Label(l.getText(), clone(l.getGraphic()));
>             label.textProperty().bind(l.textProperty());
>             return label;
>         }
>         return null;
>     }
>
>
>
>
>
> It is not obvious at all that this is what's going to happen, or why. And
> it seems impossible to control or influence this in any reasonable way,
> without replacing the whole TabPaneSkin.
>
>
>
> Given TabPane is one of the most important and widely used controls there
> is, there could/should be some of the following:
>
>    - Proper documentation on this limitation / behaviour
>    - Some way to set fallback text that can be used in the menu (i.e.,
>    that isn't the Tab's header's text, because one might intentionally avoid
>    setting that given there's no way to hide it from the tab header)
>    - Or, better yet, some way to allow you to specify tab header text
>    without displaying it in the actual tab header, which could then be used by
>    the hacky method as normal
>    - Some way to set a callback so the developer can decide what gets
>    displayed for the overflow menu
>    - Some way to override the skin without needing a full copy + paste +
>    rename
>    - Some way to allow the dev to disable the overflow menu, if it's
>    going to produce something unusable. E.g., prefer no menu than a buggy
>    one...
>
>
>
> I would view this as a bug, even though it's probably been like this
> forever.
>
>
>
>
>
> Some sample code to demonstrate; just look at the menu:
>
>
> public class TabPaneMenu extends Application {
>     @Override
>     public void start(Stage primaryStage) {
>         TabPane tabPane = new TabPane();
>
>         for (int i = 1; i <= 30; i++) {
>             Tab tab;
>             if (i == 2) {
>                 tab = new Tab();
>                 final Label label = new Label("HBox Tab " + i);
>                 final HBox hBox = new HBox(label); // Will show as blank
> in overflow menu!
>                 tab.setGraphic(hBox);
>             } else if (i == 5) {
>                 tab = new Tab();
>                 tab.setGraphic(new Label("Label Tab " + i)); // Will show
> in overflow menu, because it's a Label
>             } else {
>                 tab = new Tab("Normal Tab " + i);
>             }
>
>             tab.setContent(new StackPane(new Label("This is Tab " + i)));
>             tab.setClosable(false);
>             tabPane.getTabs().add(tab);
>
>         }
>
>         Scene scene = new Scene(tabPane, 800, 600);
>         primaryStage.setScene(scene);
>         primaryStage.show();
>     }
>
>     public static void main(String[] args) {
>         launch(args);
>     }
> }
>
>
>
>
> Kind Regards,
>
>
>
> *Cormac Redmond*
>
> Software Engineer, Certak Ltd.
>
>
>
> e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250408/e905082a/attachment-0001.htm>

From mfox at openjdk.org  Tue Apr  8 23:24:46 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 8 Apr 2025 23:24:46 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header
In-Reply-To: <Stu3_VeI4DTcvKYUbG2HsdmnR8sbkNt3WnHd0mD41SY=.cac23f52-aa88-486a-ab97-e7cc184c2ec9@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <AfeVF9UP8dixrNJzF1l6dJvg4cM2z6xAYky8z50jHUk=.7a5de6c9-1803-4643-ae8e-c36edfab2c07@github.com>
 <KFlsFutDhFDxB8Gf6bt_isesOE6a2aAjtwqlLDxhlwc=.12597ebb-8bf7-4fc0-9f32-655b32f1154c@github.com>
 <yil2HsS8NfdzD_M6z5c9N8PKXzIz1ecwEGUVek6d5VE=.10e36996-f20b-4264-bffc-aeaaf0375b26@github.com>
 <tcwE5uXPfHUNqTyCYaEpVPKYOfplURjVVu5y_tES9v0=.a02fac56-d4e7-4e32-bf26-90505fbc213a@github.com>
 <nzvExpCOKm7rCSXVkCRy7F_7fwAlmYd9iRCvih-w5c4=.895e94e9-8a71-4e75-83a0-621dd4eb07f1@github.com>
 <M7hdDFJMGTLsADqqOW7jelfiF5ElveznXkmMJ3-FxAg=.c40ef0e4-b506-4bad-9e3f-a63fa03bf933@github.com>
 <Stu3_VeI4DTcvKYUbG2HsdmnR8sbkNt3WnHd0mD41SY=.cac23f52-aa88-486a-ab97-e7cc184c2ec9@github.com>
Message-ID: <GMk2knDCRVX92qJQbSfyYFUM_VKPoshDWmmEdGjLGuY=.d04b4ac6-e8eb-40a2-b00f-d55c82c19879@github.com>

On Tue, 8 Apr 2025 21:40:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> On Linux I have some issues too: the test that I attached to the JBS issue doesn't fail for me on Linux, but the test that I added to this PR does fail without the fix.
>
> Can you try the monkey tester?  it allows setting properties on the table view / table column at runtime...

I just verified that on Linux the released event usually goes to the popup window. Basically it's whatever window is under the cursor at the time; if I move the mouse fast enough it may go to a node on the primary stage. I don't think this is our doing, it's how GTK is delivering the event.

On the JavaFX side I'm not sure this counts as a bug. The docs state that entered and released events should arrive in pairs during drag and drop operations but doesn't address this case.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1754#discussion_r2034159259

From arapte at openjdk.org  Wed Apr  9 06:13:40 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 9 Apr 2025 06:13:40 GMT
Subject: RFR: 8353916: Unexpected event type for DOM mutation events with
 WebKit 620.1
In-Reply-To: <q_vL2fBbia2j0fYgEp_OD_v64llsXQO9s4Zl38Mi8aw=.34b8bd5d-6a86-419e-a897-b2b96e865e4e@github.com>
References: <q_vL2fBbia2j0fYgEp_OD_v64llsXQO9s4Zl38Mi8aw=.34b8bd5d-6a86-419e-a897-b2b96e865e4e@github.com>
Message-ID: <popf_uQPbcgiwsvvFa02ctrtLpsQs38Bl4maTwNYE0g=.ab2f1921-0d70-40e2-90ce-d4b5517d378a@github.com>

On Tue, 8 Apr 2025 11:50:05 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: In WebKit 619.1, MutationEvent was properly handled and overridden, so casting to it worked as expected. In newer WebKit versions (like the one embedded in current JavaFX), MutationEvent is deprecated, and the actual event dispatched is just a generic DOM Event.
> Solution: restore the old style mutation event support, which will cause the returned events to again be instances of MutationEvent.

lgtm

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1765#pullrequestreview-2752151578

From mstrauss at openjdk.org  Wed Apr  9 07:10:57 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 9 Apr 2025 07:10:57 GMT
Subject: RFR: 8353845: com.sun.javafx.css.BitSet.equals(null) throws NPE
Message-ID: <aVflosujg1VKRBlOsO7aRs_2kcjwGliGbqY2eedajiU=.985537cb-40e5-442e-bcc0-305a4efb6272@github.com>

Fixes the bug that `BitSet.equals(null)` throws NPE.

A single reviewer should be sufficient.

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

Commit messages:
 - fix equals(null)
 - failing test

Changes: https://git.openjdk.org/jfx/pull/1766/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1766&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353845
  Stats: 16 lines in 3 files changed: 9 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1766.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1766/head:pull/1766

PR: https://git.openjdk.org/jfx/pull/1766

From mstrauss at openjdk.org  Wed Apr  9 07:38:28 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 9 Apr 2025 07:38:28 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v62]
In-Reply-To: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
Message-ID: <WxoLl32Y_mYDd_aXC-NxhVtbenqkMB4mnkSaiuMnuJw=.25e2915b-f903-47ef-910a-43314cae2672@github.com>

> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  Remove StageStyle.EXTENDED_UTILITY

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1605/files
  - new: https://git.openjdk.org/jfx/pull/1605/files/63215fc8..a3497b26

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=61
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=60-61

  Stats: 29 lines in 6 files changed: 0 ins; 20 del; 9 mod
  Patch: https://git.openjdk.org/jfx/pull/1605.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605

PR: https://git.openjdk.org/jfx/pull/1605

From arapte at openjdk.org  Wed Apr  9 07:49:40 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 9 Apr 2025 07:49:40 GMT
Subject: RFR: 8234153: [TEST_BUG] Rewrite Popup_parentWindow_Test [v2]
In-Reply-To: <u2FnOgx_9sxhrdNz4_JnOiZfv06FbxIWo0CTkV-ua8Q=.fe01b60c-1ce4-4084-86f9-9e48472bcebd@github.com>
References: <7bf72skQqQkaixdRyiilnIW35lkXC_X3GzbSNt9ot0U=.256071a4-e230-4e5e-9e97-aad6f614e01b@github.com>
 <u2FnOgx_9sxhrdNz4_JnOiZfv06FbxIWo0CTkV-ua8Q=.fe01b60c-1ce4-4084-86f9-9e48472bcebd@github.com>
Message-ID: <lukbYoQMRXUgvZUGopdNDHyDkasUErpMuuS147PTjaA=.4ef8b70e-4255-444e-951e-e92970b47071@github.com>

On Mon, 7 Apr 2025 08:09:32 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This change rewrites `Popup_parentWindow_Test` after a-long-time-ago-done changes to Popup public API.
>> 
>> Popup used to have an `owner` and `parentWindow` properties. I couldn't track how far back that change happened so I can't fully say what these Properties actually were, but to my knowledge both properties were replaced by `ownerNode` and `ownerWindow` Properties respectively. New Properties are read-only and are set while calling respective `Popup.show()` - `Popup.show(Node, ...)` sets both Properties, while `Popup.show(Window, ...)` sets only `ownerWindow` Property.
>> 
>> A lot of original test scenarios were cut out because with current Popup API they make little to no sense. Original `Popup_parentWindow_Test` extended `PropertiesTestBase` and ran the regular Property access checks. Those are parametrized and split into four test methods:
>> - `testGetBean` - confidence check for whether we can get the Property bean, unnecessary since new tests access the Properties directly
>> - `testGetName` - Properties in `PropertiesTestBase` are referred to by String-provided name and Reflection, so this was a confidence check whether those Properties actually exist in the object - unnecessary, since we access the Properties directly
>> - `testBinding` - I deemed those not doable, since the Properties we try to access are read-only and cannot be bound to
>> - `testBasicAccess` - This is the only test I found that was workable into a reimplementation, and so it is manually reimplemented as `Popup_owner_Test`
>> 
>> Moreover, because of lack of `Popup.setParent()` API I also deemed more complex test scenarios (cases referring to TestScene's `_window` Property) unnecessary. Since there is no `Popup.show(Scene, ...)` those cases were also eliminated. This leaves current test pool into three separate parameters for one, similar test case.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace fail() calls with assertions

Test looks good. We can have another bug to address the naming convention to change other similar classes too.
Suggesting one minor change.

modules/javafx.graphics/src/test/java/test/javafx/stage/Popup_owner_Test.java line 2:

> 1: /*
> 2:  * Copyright (c) 2011, 2025, Oracle and/or its affiliates. All rights reserved.

Either we should use `git mv <oldFile> <newFile>` here to retain the file commit history.
or
As the test changed a lot from before, we could choose not to do `git mv`, in the case the copyright in new file should be only 2025

I would recommend to `git mv` as a general good practice.

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

Changes requested by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1763#pullrequestreview-2752441223
PR Review Comment: https://git.openjdk.org/jfx/pull/1763#discussion_r2034704135

From lkostyra at openjdk.org  Wed Apr  9 08:18:56 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 9 Apr 2025 08:18:56 GMT
Subject: RFR: 8234153: [TEST_BUG] Rewrite Popup_parentWindow_Test [v3]
In-Reply-To: <7bf72skQqQkaixdRyiilnIW35lkXC_X3GzbSNt9ot0U=.256071a4-e230-4e5e-9e97-aad6f614e01b@github.com>
References: <7bf72skQqQkaixdRyiilnIW35lkXC_X3GzbSNt9ot0U=.256071a4-e230-4e5e-9e97-aad6f614e01b@github.com>
Message-ID: <lBDrBvxfbTd8x0KStiUbeM_xf4tPnj7mHlyN0FugW0Q=.89f4dad0-74e3-49c0-aa43-7cb3b65816c6@github.com>

> This change rewrites `Popup_parentWindow_Test` after a-long-time-ago-done changes to Popup public API.
> 
> Popup used to have an `owner` and `parentWindow` properties. I couldn't track how far back that change happened so I can't fully say what these Properties actually were, but to my knowledge both properties were replaced by `ownerNode` and `ownerWindow` Properties respectively. New Properties are read-only and are set while calling respective `Popup.show()` - `Popup.show(Node, ...)` sets both Properties, while `Popup.show(Window, ...)` sets only `ownerWindow` Property.
> 
> A lot of original test scenarios were cut out because with current Popup API they make little to no sense. Original `Popup_parentWindow_Test` extended `PropertiesTestBase` and ran the regular Property access checks. Those are parametrized and split into four test methods:
> - `testGetBean` - confidence check for whether we can get the Property bean, unnecessary since new tests access the Properties directly
> - `testGetName` - Properties in `PropertiesTestBase` are referred to by String-provided name and Reflection, so this was a confidence check whether those Properties actually exist in the object - unnecessary, since we access the Properties directly
> - `testBinding` - I deemed those not doable, since the Properties we try to access are read-only and cannot be bound to
> - `testBasicAccess` - This is the only test I found that was workable into a reimplementation, and so it is manually reimplemented as `Popup_owner_Test`
> 
> Moreover, because of lack of `Popup.setParent()` API I also deemed more complex test scenarios (cases referring to TestScene's `_window` Property) unnecessary. Since there is no `Popup.show(Scene, ...)` those cases were also eliminated. This leaves current test pool into three separate parameters for one, similar test case.

Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:

  Copyright header update

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1763/files
  - new: https://git.openjdk.org/jfx/pull/1763/files/986a0b78..552d698b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1763&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1763&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1763.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1763/head:pull/1763

PR: https://git.openjdk.org/jfx/pull/1763

From lkostyra at openjdk.org  Wed Apr  9 08:18:56 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 9 Apr 2025 08:18:56 GMT
Subject: RFR: 8234153: [TEST_BUG] Rewrite Popup_parentWindow_Test [v2]
In-Reply-To: <lukbYoQMRXUgvZUGopdNDHyDkasUErpMuuS147PTjaA=.4ef8b70e-4255-444e-951e-e92970b47071@github.com>
References: <7bf72skQqQkaixdRyiilnIW35lkXC_X3GzbSNt9ot0U=.256071a4-e230-4e5e-9e97-aad6f614e01b@github.com>
 <u2FnOgx_9sxhrdNz4_JnOiZfv06FbxIWo0CTkV-ua8Q=.fe01b60c-1ce4-4084-86f9-9e48472bcebd@github.com>
 <lukbYoQMRXUgvZUGopdNDHyDkasUErpMuuS147PTjaA=.4ef8b70e-4255-444e-951e-e92970b47071@github.com>
Message-ID: <wab0XeQZx7zsPfUPiM00Y4f4VMOJ8G9MM7HanNzAFN0=.a6169ab5-4e9c-414a-9d5c-736cdc9cdafb@github.com>

On Wed, 9 Apr 2025 07:45:57 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace fail() calls with assertions
>
> modules/javafx.graphics/src/test/java/test/javafx/stage/Popup_owner_Test.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2011, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> Either we should use `git mv <oldFile> <newFile>` here to retain the file commit history.
> or
> As the test changed a lot from before, we could choose not to do `git mv`, in the case the copyright in new file should be only 2025
> 
> I would recommend to `git mv` as a general good practice.

This was done with `git mv`. The problem is that the similarity between the old file and new file was too little for Git to consider this to be an actual rename, even when using `git mv`. I believe the similarity index threshold in Git is 50%.

The only way to achieve this would be to split it into two separate commits - rename, then rewrite - but that will still disappear since Skara will squish all the commits in a PR into one.

I will update the copyright header to just say `2025` since that is the case.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1763#discussion_r2034748053

From jbhaskar at openjdk.org  Wed Apr  9 08:40:48 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 9 Apr 2025 08:40:48 GMT
Subject: Integrated: 8353916: Unexpected event type for DOM mutation events
 with WebKit 620.1
In-Reply-To: <q_vL2fBbia2j0fYgEp_OD_v64llsXQO9s4Zl38Mi8aw=.34b8bd5d-6a86-419e-a897-b2b96e865e4e@github.com>
References: <q_vL2fBbia2j0fYgEp_OD_v64llsXQO9s4Zl38Mi8aw=.34b8bd5d-6a86-419e-a897-b2b96e865e4e@github.com>
Message-ID: <8VuP0GO4NBYFLYMuep4lPIYEN49X20LysqR2utleUN8=.8d18a78f-3f99-4639-9706-25b33761e9c1@github.com>

On Tue, 8 Apr 2025 11:50:05 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: In WebKit 619.1, MutationEvent was properly handled and overridden, so casting to it worked as expected. In newer WebKit versions (like the one embedded in current JavaFX), MutationEvent is deprecated, and the actual event dispatched is just a generic DOM Event.
> Solution: restore the old style mutation event support, which will cause the returned events to again be instances of MutationEvent.

This pull request has now been integrated.

Changeset: dc115d58
Author:    Jay Bhaskar <jbhaskar at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/dc115d5862894953fb27c1f209b2d81d3694db70
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8353916: Unexpected event type for DOM mutation events with WebKit 620.1

Reviewed-by: kcr, arapte

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

PR: https://git.openjdk.org/jfx/pull/1765

From jbhaskar at openjdk.org  Wed Apr  9 08:56:22 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 9 Apr 2025 08:56:22 GMT
Subject: [jfx24u] RFR: 8353916: Unexpected event type for DOM mutation events
 with WebKit 620.1
Message-ID: <jlHnPKCCHagmuvXaZLZ9gduliuQGHw9WO6z5Pqv2GZU=.1e6fef5d-3c70-4f86-88ef-95aea5f0ffcb@github.com>

A clean backport to jfx24u , the patch fixes the mutation event typecast issue the change for supportig old style mutation event type.

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

Commit messages:
 - Backport dc115d5862894953fb27c1f209b2d81d3694db70

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

PR: https://git.openjdk.org/jfx24u/pull/17

From nlisker at openjdk.org  Wed Apr  9 09:01:48 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 9 Apr 2025 09:01:48 GMT
Subject: RFR: 8353845: com.sun.javafx.css.BitSet.equals(null) throws NPE
In-Reply-To: <aVflosujg1VKRBlOsO7aRs_2kcjwGliGbqY2eedajiU=.985537cb-40e5-442e-bcc0-305a4efb6272@github.com>
References: <aVflosujg1VKRBlOsO7aRs_2kcjwGliGbqY2eedajiU=.985537cb-40e5-442e-bcc0-305a4efb6272@github.com>
Message-ID: <ZnxP9DIBVeb02rJQJyx4mhondhO2oLWwd6itBcB7ckE=.0913e628-c633-49ea-a567-580fee190f70@github.com>

On Wed, 9 Apr 2025 07:06:29 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Fixes the bug that `BitSet.equals(null)` throws NPE.
> 
> A single reviewer should be sufficient.

modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 536:

> 534:             return true;
> 535:         }
> 536:         if (obj != null && getClass() == obj.getClass()) {  // fast path if other is exact same type of BitSet

Isn't it easier to return `false` on `null`?

modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/BitSetTest.java line 50:

> 48:     @Test
> 49:     void equalsNullShouldBeFalse() {
> 50:         assertFalse(set.equals(null));

Isn't `assertNotEquals` more suitable here?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1766#discussion_r2034838251
PR Review Comment: https://git.openjdk.org/jfx/pull/1766#discussion_r2034839573

From jpereda at openjdk.org  Wed Apr  9 09:02:40 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Wed, 9 Apr 2025 09:02:40 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header
In-Reply-To: <GMk2knDCRVX92qJQbSfyYFUM_VKPoshDWmmEdGjLGuY=.d04b4ac6-e8eb-40a2-b00f-d55c82c19879@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <AfeVF9UP8dixrNJzF1l6dJvg4cM2z6xAYky8z50jHUk=.7a5de6c9-1803-4643-ae8e-c36edfab2c07@github.com>
 <KFlsFutDhFDxB8Gf6bt_isesOE6a2aAjtwqlLDxhlwc=.12597ebb-8bf7-4fc0-9f32-655b32f1154c@github.com>
 <yil2HsS8NfdzD_M6z5c9N8PKXzIz1ecwEGUVek6d5VE=.10e36996-f20b-4264-bffc-aeaaf0375b26@github.com>
 <tcwE5uXPfHUNqTyCYaEpVPKYOfplURjVVu5y_tES9v0=.a02fac56-d4e7-4e32-bf26-90505fbc213a@github.com>
 <nzvExpCOKm7rCSXVkCRy7F_7fwAlmYd9iRCvih-w5c4=.895e94e9-8a71-4e75-83a0-621dd4eb07f1@github.com>
 <M7hdDFJMGTLsADqqOW7jelfiF5ElveznXkmMJ3-FxAg=.c40ef0e4-b506-4bad-9e3f-a63fa03bf933@github.com>
 <Stu3_VeI4DTcvKYUbG2HsdmnR8sbkNt3WnHd0mD41SY=.cac23f52-aa88-486a-ab97-e7cc184c2ec9@github.com>
 <GMk2knDCRVX92qJQbSfyYFUM_VKPoshDWmmEdGjLGuY=.d04b4ac6-e8eb-40a2-b00f-d55c82c19879@github.com>
Message-ID: <8N0sbrR3UE8Sl5RAoc0tKqMrm2AP5iK4WNpKFKuu-sc=.555fd6d8-35df-4de0-acd1-17fabed064ea@github.com>

On Tue, 8 Apr 2025 23:22:18 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Can you try the monkey tester?  it allows setting properties on the table view / table column at runtime...
>
> I just verified that on Linux the released event usually goes to the popup window. Basically it's whatever window is under the cursor at the time; if I move the mouse fast enough it may go to a node on the primary stage. I don't think this is our doing, it's how GTK is delivering the event.
> 
> On the JavaFX side I'm not sure this counts as a bug. The docs state that entered and released events should arrive in pairs during drag and drop operations but doesn't address this case.

The Monkey tester app works for me on Linux (Ubuntu 22.04, either mouse or pad), before and after this PR (so I can't reproduce the issue there, as I mentioned, though the test added to the PR fails without the patch).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1754#discussion_r2034840307

From mstrauss at openjdk.org  Wed Apr  9 09:07:40 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 9 Apr 2025 09:07:40 GMT
Subject: RFR: 8353845: com.sun.javafx.css.BitSet.equals(null) throws NPE
 [v2]
In-Reply-To: <aVflosujg1VKRBlOsO7aRs_2kcjwGliGbqY2eedajiU=.985537cb-40e5-442e-bcc0-305a4efb6272@github.com>
References: <aVflosujg1VKRBlOsO7aRs_2kcjwGliGbqY2eedajiU=.985537cb-40e5-442e-bcc0-305a4efb6272@github.com>
Message-ID: <E4T56Dwqf2KGJQGzYpZ_h7MKFZ2PIxZJ9-Xq9MYTK2A=.1f4911da-a819-4af7-a4a4-bff3079bf623@github.com>

> Fixes the bug that `BitSet.equals(null)` throws NPE.
> 
> A single reviewer should be sufficient.

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  obj == null

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1766/files
  - new: https://git.openjdk.org/jfx/pull/1766/files/c051eea3..fda65a71

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1766&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1766&range=00-01

  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1766.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1766/head:pull/1766

PR: https://git.openjdk.org/jfx/pull/1766

From mstrauss at openjdk.org  Wed Apr  9 09:07:40 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 9 Apr 2025 09:07:40 GMT
Subject: RFR: 8353845: com.sun.javafx.css.BitSet.equals(null) throws NPE
 [v2]
In-Reply-To: <ZnxP9DIBVeb02rJQJyx4mhondhO2oLWwd6itBcB7ckE=.0913e628-c633-49ea-a567-580fee190f70@github.com>
References: <aVflosujg1VKRBlOsO7aRs_2kcjwGliGbqY2eedajiU=.985537cb-40e5-442e-bcc0-305a4efb6272@github.com>
 <ZnxP9DIBVeb02rJQJyx4mhondhO2oLWwd6itBcB7ckE=.0913e628-c633-49ea-a567-580fee190f70@github.com>
Message-ID: <giU3dvNEHBDqa0_XMJn_y4dH1UByLZg_meiYC7qJQUk=.97c6bcff-0ae6-4ff6-80d5-adcde055b196@github.com>

On Wed, 9 Apr 2025 08:59:37 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   obj == null
>
> modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/BitSetTest.java line 50:
> 
>> 48:     @Test
>> 49:     void equalsNullShouldBeFalse() {
>> 50:         assertFalse(set.equals(null));
> 
> Isn't `assertNotEquals` more suitable here?

Since this method specifically tests the `equals` method, I like to actually see the method in question.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1766#discussion_r2034847560

From arapte at openjdk.org  Wed Apr  9 09:13:32 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 9 Apr 2025 09:13:32 GMT
Subject: RFR: 8234153: [TEST_BUG] Rewrite Popup_parentWindow_Test [v3]
In-Reply-To: <lBDrBvxfbTd8x0KStiUbeM_xf4tPnj7mHlyN0FugW0Q=.89f4dad0-74e3-49c0-aa43-7cb3b65816c6@github.com>
References: <7bf72skQqQkaixdRyiilnIW35lkXC_X3GzbSNt9ot0U=.256071a4-e230-4e5e-9e97-aad6f614e01b@github.com>
 <lBDrBvxfbTd8x0KStiUbeM_xf4tPnj7mHlyN0FugW0Q=.89f4dad0-74e3-49c0-aa43-7cb3b65816c6@github.com>
Message-ID: <eq5EvawT5zJ09JDOofoLgKvpx1hgGuV98UYLeLrbYNo=.3c24b238-63ea-4eec-8b65-53a4e91733ad@github.com>

On Wed, 9 Apr 2025 08:18:56 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This change rewrites `Popup_parentWindow_Test` after a-long-time-ago-done changes to Popup public API.
>> 
>> Popup used to have an `owner` and `parentWindow` properties. I couldn't track how far back that change happened so I can't fully say what these Properties actually were, but to my knowledge both properties were replaced by `ownerNode` and `ownerWindow` Properties respectively. New Properties are read-only and are set while calling respective `Popup.show()` - `Popup.show(Node, ...)` sets both Properties, while `Popup.show(Window, ...)` sets only `ownerWindow` Property.
>> 
>> A lot of original test scenarios were cut out because with current Popup API they make little to no sense. Original `Popup_parentWindow_Test` extended `PropertiesTestBase` and ran the regular Property access checks. Those are parametrized and split into four test methods:
>> - `testGetBean` - confidence check for whether we can get the Property bean, unnecessary since new tests access the Properties directly
>> - `testGetName` - Properties in `PropertiesTestBase` are referred to by String-provided name and Reflection, so this was a confidence check whether those Properties actually exist in the object - unnecessary, since we access the Properties directly
>> - `testBinding` - I deemed those not doable, since the Properties we try to access are read-only and cannot be bound to
>> - `testBasicAccess` - This is the only test I found that was workable into a reimplementation, and so it is manually reimplemented as `Popup_owner_Test`
>> 
>> Moreover, because of lack of `Popup.setParent()` API I also deemed more complex test scenarios (cases referring to TestScene's `_window` Property) unnecessary. Since there is no `Popup.show(Scene, ...)` those cases were also eliminated. This leaves current test pool into three separate parameters for one, similar test case.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright header update

lgtm

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1763#pullrequestreview-2752687576

From thiago.sayao at gmail.com  Wed Apr  9 10:55:39 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Wed, 9 Apr 2025 07:55:39 -0300
Subject: Help test the behavior of a multi-screen setup with both Mac and
 Windows
Message-ID: <CAAP_wu=F8us2SfaYgx6YQgzzwGNHFgtjzW0cEsLZPQp5-f7wmw@mail.gmail.com>

Hi,

Could anyone with a multi-screen setup on Mac and/or Windows please share
the results of the two buttons on this sample app? Your feedback would be
greatly appreciated!

On Ubuntu 24.04 the first button moves the Stage to the end of the first
screen (bit weird).
The second work as expected, it gets moved to the start of the center of
the last screen.

Thanks!

import javafx.application.Application;
import javafx.geometry.Pos;
import javafx.geometry.Rectangle2D;
import javafx.scene.control.Button;
import javafx.scene.layout.VBox;
import javafx.stage.Screen;
import javafx.stage.StageStyle;
import javafx.application.Platform;
import javafx.scene.Scene;
import javafx.scene.layout.StackPane;
import javafx.scene.paint.Color;
import javafx.stage.Stage;

import java.util.Comparator;

public class TestScreenBounds extends Application {

    @Override
    public void start(Stage stage) {
        stage.setTitle("Move Outside Bounds");
        Rectangle2D bounds = Screen.getScreens().stream()
                .map(Screen::getBounds)

.sorted(Comparator.comparingDouble(Rectangle2D::getMaxX).reversed())
                .findFirst()
                .orElseThrow();

        Button btn = new Button("Move To " + bounds.getMaxX());
        btn.setOnAction(event -> stage.setX(bounds.getMaxX()));

        double middleLastScreen = bounds.getMinX() + bounds.getWidth() / 2;

        Button btn2 = new Button("Move To " + middleLastScreen);
        btn2.setOnAction(event -> stage.setX(middleLastScreen));

        VBox root = new VBox(btn, btn2);
        root.setFillWidth(true);
        root.setAlignment(Pos.CENTER);
        Scene scene = new Scene(root, 300, 300);
        stage.setScene(scene);
        stage.show();
    }

    public static void main(String[] args) {
        launch(TestScreenBounds.class, args);
    }
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250409/dc77cadc/attachment-0001.htm>

From john.hendrikx at gmail.com  Wed Apr  9 11:22:41 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 9 Apr 2025 13:22:41 +0200
Subject: Help test the behavior of a multi-screen setup with both Mac and
 Windows
In-Reply-To: <CAAP_wu=F8us2SfaYgx6YQgzzwGNHFgtjzW0cEsLZPQp5-f7wmw@mail.gmail.com>
References: <CAAP_wu=F8us2SfaYgx6YQgzzwGNHFgtjzW0cEsLZPQp5-f7wmw@mail.gmail.com>
Message-ID: <f75da401-6d70-4530-a7ce-c1be8423fd6d@gmail.com>

Hi Thiago,

I ran this on Windows.? My monitor setup is:

Left: 3840x2160 (150%)?-- top left coordinate (-2560, 0) (-2560 because
of scaling)
Middle: 3840x2160 (150%) -- this one has a top left coordinate of (0, 0)
Right: 1920x1200 (100%) -- this one has a top left coordinate of (2560, 0)

When started, the program appeared perfectly centered on the middle screen.

Your program showed buttons: 4480 and 3520

The 4480 button moved the Window far too the right, off screen and I had
to stop the program

The 3520 button moved the Window to the Right monitor, but it was not
centered nicely.

I added a `peek(System.out::println)` on the screens stream.? These are
my screens:

Rectangle2D [minX=0.0, minY=0.0, maxX=2560.0, maxY=1440.0, width=2560.0,
height=1440.0]

Rectangle2D [minX=2560.0, minY=-194.0, maxX=4480.0, maxY=1006.0,
width=1920.0, height=1200.0]

Rectangle2D [minX=-2560.0, minY=6.0, maxX=0.0, maxY=1446.0,
width=2560.0, height=1440.0]

--John

On 09/04/2025 12:55, Thiago Milczarek Say?o wrote:
> Hi,
>
> Could anyone with a multi-screen setup on Mac and/or Windows please
> share the results of the two buttons on this sample app? Your feedback
> would be greatly appreciated!
>
> On Ubuntu 24.04 the first button moves the Stage to the end of the
> first screen (bit weird).?
> The second work as expected, it gets moved to the start of the center
> of the last screen.
>
> Thanks!
>
> import javafx.application.Application;
> import javafx.geometry.Pos;
> import javafx.geometry.Rectangle2D;
> import javafx.scene.control.Button;
> import javafx.scene.layout.VBox;
> import javafx.stage.Screen;
> import javafx.stage.StageStyle;
> import javafx.application.Platform;
> import javafx.scene.Scene;
> import javafx.scene.layout.StackPane;
> import javafx.scene.paint.Color;
> import javafx.stage.Stage;
>
> import java.util.Comparator;
>
> public class TestScreenBounds extends Application {
>
>     @Override
>     public void start(Stage stage) {
>         stage.setTitle("Move Outside Bounds");
>         Rectangle2D bounds = Screen.getScreens().stream()
>                 .map(Screen::getBounds)
>                 .sorted(Comparator.comparingDouble(Rectangle2D::getMaxX).reversed())
>                 .findFirst()
>                 .orElseThrow();
>
>         Button btn = new Button("Move To " + bounds.getMaxX());
>         btn.setOnAction(event -> stage.setX(bounds.getMaxX()));
>
>         double middleLastScreen = bounds.getMinX() + bounds.getWidth() / 2;
>
>         Button btn2 = new Button("Move To " + middleLastScreen);
>         btn2.setOnAction(event -> stage.setX(middleLastScreen));
>
>         VBox root = new VBox(btn, btn2);
>         root.setFillWidth(true);
>         root.setAlignment(Pos.CENTER);
>         Scene scene = new Scene(root, 300, 300);
>         stage.setScene(scene);
>         stage.show();
>     }
>
>     public static void main(String[] args) {
>         launch(TestScreenBounds.class, args);
>     }
> }
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250409/27098df8/attachment.htm>

From john.hendrikx at gmail.com  Wed Apr  9 11:27:49 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 9 Apr 2025 13:27:49 +0200
Subject: Help test the behavior of a multi-screen setup with both Mac and
 Windows
In-Reply-To: <f75da401-6d70-4530-a7ce-c1be8423fd6d@gmail.com>
References: <CAAP_wu=F8us2SfaYgx6YQgzzwGNHFgtjzW0cEsLZPQp5-f7wmw@mail.gmail.com>
 <f75da401-6d70-4530-a7ce-c1be8423fd6d@gmail.com>
Message-ID: <81b1f8c8-9f97-4648-aea2-9685f85d36a9@gmail.com>

Small addition; the 3520 button moved the top left of the Window to the
middle of the right screen, but the window as a whole was not centered.

--John

On 09/04/2025 13:22, John Hendrikx wrote:
>
> Hi Thiago,
>
> I ran this on Windows.? My monitor setup is:
>
> Left: 3840x2160 (150%)?-- top left coordinate (-2560, 0) (-2560
> because of scaling)
> Middle: 3840x2160 (150%) -- this one has a top left coordinate of (0, 0)
> Right: 1920x1200 (100%) -- this one has a top left coordinate of (2560, 0)
>
> When started, the program appeared perfectly centered on the middle
> screen.
>
> Your program showed buttons: 4480 and 3520
>
> The 4480 button moved the Window far too the right, off screen and I
> had to stop the program
>
> The 3520 button moved the Window to the Right monitor, but it was not
> centered nicely.
>
> I added a `peek(System.out::println)` on the screens stream.? These
> are my screens:
>
> Rectangle2D [minX=0.0, minY=0.0, maxX=2560.0, maxY=1440.0,
> width=2560.0, height=1440.0]
>
> Rectangle2D [minX=2560.0, minY=-194.0, maxX=4480.0, maxY=1006.0,
> width=1920.0, height=1200.0]
>
> Rectangle2D [minX=-2560.0, minY=6.0, maxX=0.0, maxY=1446.0,
> width=2560.0, height=1440.0]
>
> --John
>
> On 09/04/2025 12:55, Thiago Milczarek Say?o wrote:
>> Hi,
>>
>> Could anyone with a multi-screen setup on Mac and/or Windows please
>> share the results of the two buttons on this sample app? Your
>> feedback would be greatly appreciated!
>>
>> On Ubuntu 24.04 the first button moves the Stage to the end of the
>> first screen (bit weird).?
>> The second work as expected, it gets moved to the start of the center
>> of the last screen.
>>
>> Thanks!
>>
>> import javafx.application.Application;
>> import javafx.geometry.Pos;
>> import javafx.geometry.Rectangle2D;
>> import javafx.scene.control.Button;
>> import javafx.scene.layout.VBox;
>> import javafx.stage.Screen;
>> import javafx.stage.StageStyle;
>> import javafx.application.Platform;
>> import javafx.scene.Scene;
>> import javafx.scene.layout.StackPane;
>> import javafx.scene.paint.Color;
>> import javafx.stage.Stage;
>>
>> import java.util.Comparator;
>>
>> public class TestScreenBounds extends Application {
>>
>>     @Override
>>     public void start(Stage stage) {
>>         stage.setTitle("Move Outside Bounds");
>>         Rectangle2D bounds = Screen.getScreens().stream()
>>                 .map(Screen::getBounds)
>>                 .sorted(Comparator.comparingDouble(Rectangle2D::getMaxX).reversed())
>>                 .findFirst()
>>                 .orElseThrow();
>>
>>         Button btn = new Button("Move To " + bounds.getMaxX());
>>         btn.setOnAction(event -> stage.setX(bounds.getMaxX()));
>>
>>         double middleLastScreen = bounds.getMinX() + bounds.getWidth() / 2;
>>
>>         Button btn2 = new Button("Move To " + middleLastScreen);
>>         btn2.setOnAction(event -> stage.setX(middleLastScreen));
>>
>>         VBox root = new VBox(btn, btn2);
>>         root.setFillWidth(true);
>>         root.setAlignment(Pos.CENTER);
>>         Scene scene = new Scene(root, 300, 300);
>>         stage.setScene(scene);
>>         stage.show();
>>     }
>>
>>     public static void main(String[] args) {
>>         launch(TestScreenBounds.class, args);
>>     }
>> }
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250409/529aef31/attachment-0001.htm>

From nlisker at gmail.com  Wed Apr  9 11:53:43 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 9 Apr 2025 14:53:43 +0300
Subject: Help test the behavior of a multi-screen setup with both Mac and
 Windows
In-Reply-To: <81b1f8c8-9f97-4648-aea2-9685f85d36a9@gmail.com>
References: <CAAP_wu=F8us2SfaYgx6YQgzzwGNHFgtjzW0cEsLZPQp5-f7wmw@mail.gmail.com>
 <f75da401-6d70-4530-a7ce-c1be8423fd6d@gmail.com>
 <81b1f8c8-9f97-4648-aea2-9685f85d36a9@gmail.com>
Message-ID: <CA+0ynh_=9c=wWmptupT4ViTntb_8JCNmESUUh04yaZ8ODvcDrQ@mail.gmail.com>

I followed John's 'peek' addition. I have 2 monitors, the second one has a
125% magnification. Windows 10.

Rectangle2D [minX=0.0, minY=0.0, maxX=1920.0, maxY=1080.0, width=1920.0,
height=1080.0]

Rectangle2D [minX=1920.0, minY=0.0, maxX=3456.0, maxY=864.0, width=1536.0,
height=864.0]

The buttons are 3456.0 and 2688.0.
The first one moved the stage to the far right of the second monitor, 76px
from the right of the stage to the screen's edge.
The second one moved the stage to the center-right of the second monitor,
576px from the right of the stage to the screen's edge.

On Wed, Apr 9, 2025 at 2:28?PM John Hendrikx <john.hendrikx at gmail.com>
wrote:

> Small addition; the 3520 button moved the top left of the Window to the
> middle of the right screen, but the window as a whole was not centered.
>
> --John
> On 09/04/2025 13:22, John Hendrikx wrote:
>
> Hi Thiago,
>
> I ran this on Windows.  My monitor setup is:
>
> Left: 3840x2160 (150%) -- top left coordinate (-2560, 0) (-2560 because of
> scaling)
> Middle: 3840x2160 (150%) -- this one has a top left coordinate of (0, 0)
> Right: 1920x1200 (100%) -- this one has a top left coordinate of (2560, 0)
>
> When started, the program appeared perfectly centered on the middle screen.
>
> Your program showed buttons: 4480 and 3520
>
> The 4480 button moved the Window far too the right, off screen and I had
> to stop the program
>
> The 3520 button moved the Window to the Right monitor, but it was not
> centered nicely.
>
> I added a `peek(System.out::println)` on the screens stream.  These are my
> screens:
>
> Rectangle2D [minX=0.0, minY=0.0, maxX=2560.0, maxY=1440.0, width=2560.0,
> height=1440.0]
>
> Rectangle2D [minX=2560.0, minY=-194.0, maxX=4480.0, maxY=1006.0,
> width=1920.0, height=1200.0]
>
> Rectangle2D [minX=-2560.0, minY=6.0, maxX=0.0, maxY=1446.0, width=2560.0,
> height=1440.0]
>
> --John
> On 09/04/2025 12:55, Thiago Milczarek Say?o wrote:
>
> Hi,
>
> Could anyone with a multi-screen setup on Mac and/or Windows please share
> the results of the two buttons on this sample app? Your feedback would be
> greatly appreciated!
>
> On Ubuntu 24.04 the first button moves the Stage to the end of the first
> screen (bit weird).
> The second work as expected, it gets moved to the start of the center of
> the last screen.
>
> Thanks!
>
> import javafx.application.Application;import javafx.geometry.Pos;import javafx.geometry.Rectangle2D;import javafx.scene.control.Button;import javafx.scene.layout.VBox;import javafx.stage.Screen;import javafx.stage.StageStyle;import javafx.application.Platform;import javafx.scene.Scene;import javafx.scene.layout.StackPane;import javafx.scene.paint.Color;import javafx.stage.Stage;
> import java.util.Comparator;
> public class TestScreenBounds extends Application {
>
>     @Override
>     public void start(Stage stage) {
>         stage.setTitle("Move Outside Bounds");
>         Rectangle2D bounds = Screen.getScreens().stream()
>                 .map(Screen::getBounds)
>                 .sorted(Comparator.comparingDouble(Rectangle2D::getMaxX).reversed())
>                 .findFirst()
>                 .orElseThrow();
>
>         Button btn = new Button("Move To " + bounds.getMaxX());
>         btn.setOnAction(event -> stage.setX(bounds.getMaxX()));
>
>         double middleLastScreen = bounds.getMinX() + bounds.getWidth() / 2;
>
>         Button btn2 = new Button("Move To " + middleLastScreen);
>         btn2.setOnAction(event -> stage.setX(middleLastScreen));
>
>         VBox root = new VBox(btn, btn2);
>         root.setFillWidth(true);
>         root.setAlignment(Pos.CENTER);
>         Scene scene = new Scene(root, 300, 300);
>         stage.setScene(scene);
>         stage.show();
>     }
>
>     public static void main(String[] args) {
>         launch(TestScreenBounds.class, args);
>     }
> }
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250409/f329db83/attachment.htm>

From thiago.sayao at gmail.com  Wed Apr  9 11:57:09 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Wed, 9 Apr 2025 08:57:09 -0300
Subject: Help test the behavior of a multi-screen setup with both Mac and
 Windows
In-Reply-To: <81b1f8c8-9f97-4648-aea2-9685f85d36a9@gmail.com>
References: <CAAP_wu=F8us2SfaYgx6YQgzzwGNHFgtjzW0cEsLZPQp5-f7wmw@mail.gmail.com>
 <f75da401-6d70-4530-a7ce-c1be8423fd6d@gmail.com>
 <81b1f8c8-9f97-4648-aea2-9685f85d36a9@gmail.com>
Message-ID: <CAAP_wum81BUtdbqRBWTcuB-HbKdi9Vj14VrndVBzDKpnsxD0Pw@mail.gmail.com>

Thanks John!

I did not calculate the center, I just wanted to know the behaviour of
setX() outside bounds and within
bounds of the last screen.

The GNOME window manager on Linux restricts programmatic movement of
windows to prevent them
from being moved outside screen boundaries. However, it allows users to
drag windows beyond these limits.
I find it odd that the maximum movement is restricted to the bounds of the
first screen, while it would be more
intuitive for it to be based on the last screen.

The Windows behaviour also seems odd.

-- Thiago

Em qua., 9 de abr. de 2025 ?s 08:28, John Hendrikx <john.hendrikx at gmail.com>
escreveu:

> Small addition; the 3520 button moved the top left of the Window to the
> middle of the right screen, but the window as a whole was not centered.
>
> --John
> On 09/04/2025 13:22, John Hendrikx wrote:
>
> Hi Thiago,
>
> I ran this on Windows.  My monitor setup is:
>
> Left: 3840x2160 (150%) -- top left coordinate (-2560, 0) (-2560 because of
> scaling)
> Middle: 3840x2160 (150%) -- this one has a top left coordinate of (0, 0)
> Right: 1920x1200 (100%) -- this one has a top left coordinate of (2560, 0)
>
> When started, the program appeared perfectly centered on the middle screen.
>
> Your program showed buttons: 4480 and 3520
>
> The 4480 button moved the Window far too the right, off screen and I had
> to stop the program
>
> The 3520 button moved the Window to the Right monitor, but it was not
> centered nicely.
>
> I added a `peek(System.out::println)` on the screens stream.  These are my
> screens:
>
> Rectangle2D [minX=0.0, minY=0.0, maxX=2560.0, maxY=1440.0, width=2560.0,
> height=1440.0]
>
> Rectangle2D [minX=2560.0, minY=-194.0, maxX=4480.0, maxY=1006.0,
> width=1920.0, height=1200.0]
>
> Rectangle2D [minX=-2560.0, minY=6.0, maxX=0.0, maxY=1446.0, width=2560.0,
> height=1440.0]
>
> --John
> On 09/04/2025 12:55, Thiago Milczarek Say?o wrote:
>
> Hi,
>
> Could anyone with a multi-screen setup on Mac and/or Windows please share
> the results of the two buttons on this sample app? Your feedback would be
> greatly appreciated!
>
> On Ubuntu 24.04 the first button moves the Stage to the end of the first
> screen (bit weird).
> The second work as expected, it gets moved to the start of the center of
> the last screen.
>
> Thanks!
>
> import javafx.application.Application;import javafx.geometry.Pos;import javafx.geometry.Rectangle2D;import javafx.scene.control.Button;import javafx.scene.layout.VBox;import javafx.stage.Screen;import javafx.stage.StageStyle;import javafx.application.Platform;import javafx.scene.Scene;import javafx.scene.layout.StackPane;import javafx.scene.paint.Color;import javafx.stage.Stage;
> import java.util.Comparator;
> public class TestScreenBounds extends Application {
>
>     @Override
>     public void start(Stage stage) {
>         stage.setTitle("Move Outside Bounds");
>         Rectangle2D bounds = Screen.getScreens().stream()
>                 .map(Screen::getBounds)
>                 .sorted(Comparator.comparingDouble(Rectangle2D::getMaxX).reversed())
>                 .findFirst()
>                 .orElseThrow();
>
>         Button btn = new Button("Move To " + bounds.getMaxX());
>         btn.setOnAction(event -> stage.setX(bounds.getMaxX()));
>
>         double middleLastScreen = bounds.getMinX() + bounds.getWidth() / 2;
>
>         Button btn2 = new Button("Move To " + middleLastScreen);
>         btn2.setOnAction(event -> stage.setX(middleLastScreen));
>
>         VBox root = new VBox(btn, btn2);
>         root.setFillWidth(true);
>         root.setAlignment(Pos.CENTER);
>         Scene scene = new Scene(root, 300, 300);
>         stage.setScene(scene);
>         stage.show();
>     }
>
>     public static void main(String[] args) {
>         launch(TestScreenBounds.class, args);
>     }
> }
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250409/4be811c9/attachment-0001.htm>

From jbhaskar at openjdk.org  Wed Apr  9 11:59:48 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 9 Apr 2025 11:59:48 GMT
Subject: [jfx24u] Integrated: 8353916: Unexpected event type for DOM mutation
 events with WebKit 620.1
In-Reply-To: <jlHnPKCCHagmuvXaZLZ9gduliuQGHw9WO6z5Pqv2GZU=.1e6fef5d-3c70-4f86-88ef-95aea5f0ffcb@github.com>
References: <jlHnPKCCHagmuvXaZLZ9gduliuQGHw9WO6z5Pqv2GZU=.1e6fef5d-3c70-4f86-88ef-95aea5f0ffcb@github.com>
Message-ID: <3OTSxL1TfzDJcYC2yChSSPwQO0Dy5pVkcWT96WqqjZo=.bf617daa-c35c-47c2-9b6c-4bfb2928815c@github.com>

On Wed, 9 Apr 2025 08:50:29 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> A clean backport to jfx24u , the patch fixes the mutation event typecast issue the change for supportig old style mutation event type.

This pull request has now been integrated.

Changeset: 1228ee6b
Author:    Jay Bhaskar <jbhaskar at openjdk.org>
URL:       https://git.openjdk.org/jfx24u/commit/1228ee6bca211a1ea8b5a5be69573bc5623f5852
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8353916: Unexpected event type for DOM mutation events with WebKit 620.1

Backport-of: dc115d5862894953fb27c1f209b2d81d3694db70

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

PR: https://git.openjdk.org/jfx24u/pull/17

From jbhaskar at openjdk.org  Wed Apr  9 12:07:57 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 9 Apr 2025 12:07:57 GMT
Subject: [jfx24u] RFR: 8350284: WebKit 620.1 crashes on startup on Windows x86
 32-bit
Message-ID: <vUiLe9QxLggI8gLaVTBMgESxcOI9JGnDw_KmCOXVsv0=.ba789587-0bf7-4bba-845e-323b0ec5ad07@github.com>

A clean backport to  jfx24u. The patch fixes startup issue of javafx web application on window i586 machine.

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

Commit messages:
 - Backport d31f764b565cafdb6cafe88a9676ffba8cb7cdbb

Changes: https://git.openjdk.org/jfx24u/pull/18/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx24u&pr=18&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350284
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx24u/pull/18.diff
  Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/18/head:pull/18

PR: https://git.openjdk.org/jfx24u/pull/18

From john.hendrikx at gmail.com  Wed Apr  9 12:15:57 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 9 Apr 2025 14:15:57 +0200
Subject: Help test the behavior of a multi-screen setup with both Mac and
 Windows
In-Reply-To: <CAAP_wum81BUtdbqRBWTcuB-HbKdi9Vj14VrndVBzDKpnsxD0Pw@mail.gmail.com>
References: <CAAP_wu=F8us2SfaYgx6YQgzzwGNHFgtjzW0cEsLZPQp5-f7wmw@mail.gmail.com>
 <f75da401-6d70-4530-a7ce-c1be8423fd6d@gmail.com>
 <81b1f8c8-9f97-4648-aea2-9685f85d36a9@gmail.com>
 <CAAP_wum81BUtdbqRBWTcuB-HbKdi9Vj14VrndVBzDKpnsxD0Pw@mail.gmail.com>
Message-ID: <f72796b4-5a29-4aa1-b037-cf1d9a5045b1@gmail.com>

On Windows it is not restricted AFAIK, moving a screen anywhere is
allowed, and one can also drag windows beyond those limits.? When a
monitor is added/removed Windows may however decide to reshuffle all
your Windows (or randomly if a monitor is slow to respond when waking
from sleep) to ensure they're all visible.

I think Windows just treats the screen space as infinite with the
monitors being views into it; overlaps and gaps are allowed, although
you need some tricks to get your screens setup that way.

Not sure what you find odd about the Windows behaviour?

--John

On 09/04/2025 13:57, Thiago Milczarek Say?o wrote:
> Thanks John!
>
> I did not calculate the center, I just wanted to know the behaviour of
> setX() outside bounds and within
> bounds of the last screen.
>
> The GNOME window manager on Linux restricts programmatic movement of
> windows to prevent them?
> from being moved outside screen boundaries. However, it allows users
> to drag windows beyond these limits.
> I find it odd that the maximum movement is restricted to the bounds of
> the first screen, while it would be more
> intuitive for it to be based on the last screen.
>
> The Windows behaviour also seems odd.
>
> -- Thiago
>
> Em qua., 9 de abr. de 2025 ?s 08:28, John Hendrikx
> <john.hendrikx at gmail.com> escreveu:
>
>     Small addition; the 3520 button moved the top left of the Window
>     to the middle of the right screen, but the window as a whole was
>     not centered.
>
>     --John
>
>     On 09/04/2025 13:22, John Hendrikx wrote:
>>
>>     Hi Thiago,
>>
>>     I ran this on Windows.? My monitor setup is:
>>
>>     Left: 3840x2160 (150%)?-- top left coordinate (-2560, 0) (-2560
>>     because of scaling)
>>     Middle: 3840x2160 (150%) -- this one has a top left coordinate of
>>     (0, 0)
>>     Right: 1920x1200 (100%) -- this one has a top left coordinate of
>>     (2560, 0)
>>
>>     When started, the program appeared perfectly centered on the
>>     middle screen.
>>
>>     Your program showed buttons: 4480 and 3520
>>
>>     The 4480 button moved the Window far too the right, off screen
>>     and I had to stop the program
>>
>>     The 3520 button moved the Window to the Right monitor, but it was
>>     not centered nicely.
>>
>>     I added a `peek(System.out::println)` on the screens stream.?
>>     These are my screens:
>>
>>     Rectangle2D [minX=0.0, minY=0.0, maxX=2560.0, maxY=1440.0,
>>     width=2560.0, height=1440.0]
>>
>>     Rectangle2D [minX=2560.0, minY=-194.0, maxX=4480.0, maxY=1006.0,
>>     width=1920.0, height=1200.0]
>>
>>     Rectangle2D [minX=-2560.0, minY=6.0, maxX=0.0, maxY=1446.0,
>>     width=2560.0, height=1440.0]
>>
>>     --John
>>
>>     On 09/04/2025 12:55, Thiago Milczarek Say?o wrote:
>>>     Hi,
>>>
>>>     Could anyone with a multi-screen setup on Mac and/or Windows
>>>     please share the results of the two buttons on this sample app?
>>>     Your feedback would be greatly appreciated!
>>>
>>>     On Ubuntu 24.04 the first button moves the Stage to the end of
>>>     the first screen (bit weird).?
>>>     The second work as expected, it gets moved to the start of the
>>>     center of the last screen.
>>>
>>>     Thanks!
>>>
>>>     import javafx.application.Application;
>>>     import javafx.geometry.Pos;
>>>     import javafx.geometry.Rectangle2D;
>>>     import javafx.scene.control.Button;
>>>     import javafx.scene.layout.VBox;
>>>     import javafx.stage.Screen;
>>>     import javafx.stage.StageStyle;
>>>     import javafx.application.Platform;
>>>     import javafx.scene.Scene;
>>>     import javafx.scene.layout.StackPane;
>>>     import javafx.scene.paint.Color;
>>>     import javafx.stage.Stage;
>>>
>>>     import java.util.Comparator;
>>>
>>>     public class TestScreenBounds extends Application {
>>>
>>>         @Override
>>>         public void start(Stage stage) {
>>>             stage.setTitle("Move Outside Bounds");
>>>             Rectangle2D bounds = Screen.getScreens().stream()
>>>                     .map(Screen::getBounds)
>>>                     .sorted(Comparator.comparingDouble(Rectangle2D::getMaxX).reversed())
>>>                     .findFirst()
>>>                     .orElseThrow();
>>>
>>>             Button btn = new Button("Move To " + bounds.getMaxX());
>>>             btn.setOnAction(event -> stage.setX(bounds.getMaxX()));
>>>
>>>             double middleLastScreen = bounds.getMinX() + bounds.getWidth() / 2;
>>>
>>>             Button btn2 = new Button("Move To " + middleLastScreen);
>>>             btn2.setOnAction(event -> stage.setX(middleLastScreen));
>>>
>>>             VBox root = new VBox(btn, btn2);
>>>             root.setFillWidth(true);
>>>             root.setAlignment(Pos.CENTER);
>>>             Scene scene = new Scene(root, 300, 300);
>>>             stage.setScene(scene);
>>>             stage.show();
>>>         }
>>>
>>>         public static void main(String[] args) {
>>>             launch(TestScreenBounds.class, args);
>>>         }
>>>     }
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250409/63ab921d/attachment-0001.htm>

From jbhaskar at openjdk.org  Wed Apr  9 12:19:45 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 9 Apr 2025 12:19:45 GMT
Subject: [jfx24u] Integrated: 8350284: WebKit 620.1 crashes on startup on
 Windows x86 32-bit
In-Reply-To: <vUiLe9QxLggI8gLaVTBMgESxcOI9JGnDw_KmCOXVsv0=.ba789587-0bf7-4bba-845e-323b0ec5ad07@github.com>
References: <vUiLe9QxLggI8gLaVTBMgESxcOI9JGnDw_KmCOXVsv0=.ba789587-0bf7-4bba-845e-323b0ec5ad07@github.com>
Message-ID: <3hNjErB7fmCK6rXLiY5C-q9n7GKYeXmvIKBmGgpJlmQ=.115fe06d-fa0c-474f-a9e9-03c5445d31f1@github.com>

On Wed, 9 Apr 2025 12:02:20 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> A clean backport to  jfx24u. The patch fixes startup issue of javafx web application on window i586 machine.

This pull request has now been integrated.

Changeset: d0a61f4b
Author:    Jay Bhaskar <jbhaskar at openjdk.org>
URL:       https://git.openjdk.org/jfx24u/commit/d0a61f4bbb5c1b1a19677dc0c54ce4be0d695ebf
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8350284: WebKit 620.1 crashes on startup on Windows x86 32-bit

Backport-of: d31f764b565cafdb6cafe88a9676ffba8cb7cdbb

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

PR: https://git.openjdk.org/jfx24u/pull/18

From thiago.sayao at gmail.com  Wed Apr  9 12:25:40 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Wed, 9 Apr 2025 09:25:40 -0300
Subject: Help test the behavior of a multi-screen setup with both Mac and
 Windows
In-Reply-To: <f72796b4-5a29-4aa1-b037-cf1d9a5045b1@gmail.com>
References: <CAAP_wu=F8us2SfaYgx6YQgzzwGNHFgtjzW0cEsLZPQp5-f7wmw@mail.gmail.com>
 <f75da401-6d70-4530-a7ce-c1be8423fd6d@gmail.com>
 <81b1f8c8-9f97-4648-aea2-9685f85d36a9@gmail.com>
 <CAAP_wum81BUtdbqRBWTcuB-HbKdi9Vj14VrndVBzDKpnsxD0Pw@mail.gmail.com>
 <f72796b4-5a29-4aa1-b037-cf1d9a5045b1@gmail.com>
Message-ID: <CAAP_wu=Q5REvgu5jyihy8HBVNxQq=mad8gErSJ8bqd3p7O5pNA@mail.gmail.com>

Odd in the sense it's unrestrictive to the bounds.
It shouldn't be allowed in a TopLevel taskbar shown window at least, but
that's my opinion.
But it's windows being windows. They value compatibility and that's
probably an old behaviour
that some apps depend on.
Gnome being gnome has a lot of restrictions, specially on Wayland.

Em qua., 9 de abr. de 2025 ?s 09:15, John Hendrikx <john.hendrikx at gmail.com>
escreveu:

> On Windows it is not restricted AFAIK, moving a screen anywhere is
> allowed, and one can also drag windows beyond those limits.  When a monitor
> is added/removed Windows may however decide to reshuffle all your Windows
> (or randomly if a monitor is slow to respond when waking from sleep) to
> ensure they're all visible.
>
> I think Windows just treats the screen space as infinite with the monitors
> being views into it; overlaps and gaps are allowed, although you need some
> tricks to get your screens setup that way.
>
> Not sure what you find odd about the Windows behaviour?
>
> --John
> On 09/04/2025 13:57, Thiago Milczarek Say?o wrote:
>
> Thanks John!
>
> I did not calculate the center, I just wanted to know the behaviour of
> setX() outside bounds and within
> bounds of the last screen.
>
> The GNOME window manager on Linux restricts programmatic movement of
> windows to prevent them
> from being moved outside screen boundaries. However, it allows users to
> drag windows beyond these limits.
> I find it odd that the maximum movement is restricted to the bounds of the
> first screen, while it would be more
> intuitive for it to be based on the last screen.
>
> The Windows behaviour also seems odd.
>
> -- Thiago
>
> Em qua., 9 de abr. de 2025 ?s 08:28, John Hendrikx <
> john.hendrikx at gmail.com> escreveu:
>
>> Small addition; the 3520 button moved the top left of the Window to the
>> middle of the right screen, but the window as a whole was not centered.
>>
>> --John
>> On 09/04/2025 13:22, John Hendrikx wrote:
>>
>> Hi Thiago,
>>
>> I ran this on Windows.  My monitor setup is:
>>
>> Left: 3840x2160 (150%) -- top left coordinate (-2560, 0) (-2560 because
>> of scaling)
>> Middle: 3840x2160 (150%) -- this one has a top left coordinate of (0, 0)
>> Right: 1920x1200 (100%) -- this one has a top left coordinate of (2560, 0)
>>
>> When started, the program appeared perfectly centered on the middle
>> screen.
>>
>> Your program showed buttons: 4480 and 3520
>>
>> The 4480 button moved the Window far too the right, off screen and I had
>> to stop the program
>>
>> The 3520 button moved the Window to the Right monitor, but it was not
>> centered nicely.
>>
>> I added a `peek(System.out::println)` on the screens stream.  These are
>> my screens:
>>
>> Rectangle2D [minX=0.0, minY=0.0, maxX=2560.0, maxY=1440.0, width=2560.0,
>> height=1440.0]
>>
>> Rectangle2D [minX=2560.0, minY=-194.0, maxX=4480.0, maxY=1006.0,
>> width=1920.0, height=1200.0]
>>
>> Rectangle2D [minX=-2560.0, minY=6.0, maxX=0.0, maxY=1446.0, width=2560.0,
>> height=1440.0]
>>
>> --John
>> On 09/04/2025 12:55, Thiago Milczarek Say?o wrote:
>>
>> Hi,
>>
>> Could anyone with a multi-screen setup on Mac and/or Windows please share
>> the results of the two buttons on this sample app? Your feedback would be
>> greatly appreciated!
>>
>> On Ubuntu 24.04 the first button moves the Stage to the end of the first
>> screen (bit weird).
>> The second work as expected, it gets moved to the start of the center of
>> the last screen.
>>
>> Thanks!
>>
>> import javafx.application.Application;import javafx.geometry.Pos;import javafx.geometry.Rectangle2D;import javafx.scene.control.Button;import javafx.scene.layout.VBox;import javafx.stage.Screen;import javafx.stage.StageStyle;import javafx.application.Platform;import javafx.scene.Scene;import javafx.scene.layout.StackPane;import javafx.scene.paint.Color;import javafx.stage.Stage;
>> import java.util.Comparator;
>> public class TestScreenBounds extends Application {
>>
>>     @Override
>>     public void start(Stage stage) {
>>         stage.setTitle("Move Outside Bounds");
>>         Rectangle2D bounds = Screen.getScreens().stream()
>>                 .map(Screen::getBounds)
>>                 .sorted(Comparator.comparingDouble(Rectangle2D::getMaxX).reversed())
>>                 .findFirst()
>>                 .orElseThrow();
>>
>>         Button btn = new Button("Move To " + bounds.getMaxX());
>>         btn.setOnAction(event -> stage.setX(bounds.getMaxX()));
>>
>>         double middleLastScreen = bounds.getMinX() + bounds.getWidth() / 2;
>>
>>         Button btn2 = new Button("Move To " + middleLastScreen);
>>         btn2.setOnAction(event -> stage.setX(middleLastScreen));
>>
>>         VBox root = new VBox(btn, btn2);
>>         root.setFillWidth(true);
>>         root.setAlignment(Pos.CENTER);
>>         Scene scene = new Scene(root, 300, 300);
>>         stage.setScene(scene);
>>         stage.show();
>>     }
>>
>>     public static void main(String[] args) {
>>         launch(TestScreenBounds.class, args);
>>     }
>> }
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250409/8e4cea0f/attachment.htm>

From arapte at openjdk.org  Wed Apr  9 12:30:40 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 9 Apr 2025 12:30:40 GMT
Subject: RFR: 8353845: com.sun.javafx.css.BitSet.equals(null) throws NPE
 [v2]
In-Reply-To: <E4T56Dwqf2KGJQGzYpZ_h7MKFZ2PIxZJ9-Xq9MYTK2A=.1f4911da-a819-4af7-a4a4-bff3079bf623@github.com>
References: <aVflosujg1VKRBlOsO7aRs_2kcjwGliGbqY2eedajiU=.985537cb-40e5-442e-bcc0-305a4efb6272@github.com>
 <E4T56Dwqf2KGJQGzYpZ_h7MKFZ2PIxZJ9-Xq9MYTK2A=.1f4911da-a819-4af7-a4a4-bff3079bf623@github.com>
Message-ID: <CRq1S2HSgDxO4xoHViY5VsWuwxSa7zgnrYrHh7k2F58=.24dc0c1a-b7b4-4168-876d-6a8f90cf12bf@github.com>

On Wed, 9 Apr 2025 09:07:40 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Fixes the bug that `BitSet.equals(null)` throws NPE.
>> 
>> A single reviewer should be sufficient.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   obj == null

modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 540:

> 538:             return false;
> 539:         }
> 540: 

Here is a suggestion to modify this source as:


if (obj == null || getClass() != obj.getClass()) {
    return false;
}
return equalsBitSet((BitSet<?>) obj);

and with this the call to `super.equals()` won't be necessary. It seems it was unnecessary earlier too. it might have been added only to avoid missing return error.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1766#discussion_r2035261514

From jhendrikx at openjdk.org  Wed Apr  9 12:54:47 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 9 Apr 2025 12:54:47 GMT
Subject: RFR: 8353845: com.sun.javafx.css.BitSet.equals(null) throws NPE
 [v2]
In-Reply-To: <E4T56Dwqf2KGJQGzYpZ_h7MKFZ2PIxZJ9-Xq9MYTK2A=.1f4911da-a819-4af7-a4a4-bff3079bf623@github.com>
References: <aVflosujg1VKRBlOsO7aRs_2kcjwGliGbqY2eedajiU=.985537cb-40e5-442e-bcc0-305a4efb6272@github.com>
 <E4T56Dwqf2KGJQGzYpZ_h7MKFZ2PIxZJ9-Xq9MYTK2A=.1f4911da-a819-4af7-a4a4-bff3079bf623@github.com>
Message-ID: <A6Pg1YM7QhuUvFA4NM5JtsqTvNlgJoSUVM1m7j4IyIU=.b0738d54-c055-463a-b79a-5117742ceff2@github.com>

On Wed, 9 Apr 2025 09:07:40 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Fixes the bug that `BitSet.equals(null)` throws NPE.
>> 
>> A single reviewer should be sufficient.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   obj == null

Looks like a regression I introduced when cleaning up all the bugs in this class, oops.

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

Marked as reviewed by jhendrikx (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1766#pullrequestreview-2753368763

From jhendrikx at openjdk.org  Wed Apr  9 12:54:49 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 9 Apr 2025 12:54:49 GMT
Subject: RFR: 8353845: com.sun.javafx.css.BitSet.equals(null) throws NPE
 [v2]
In-Reply-To: <CRq1S2HSgDxO4xoHViY5VsWuwxSa7zgnrYrHh7k2F58=.24dc0c1a-b7b4-4168-876d-6a8f90cf12bf@github.com>
References: <aVflosujg1VKRBlOsO7aRs_2kcjwGliGbqY2eedajiU=.985537cb-40e5-442e-bcc0-305a4efb6272@github.com>
 <E4T56Dwqf2KGJQGzYpZ_h7MKFZ2PIxZJ9-Xq9MYTK2A=.1f4911da-a819-4af7-a4a4-bff3079bf623@github.com>
 <CRq1S2HSgDxO4xoHViY5VsWuwxSa7zgnrYrHh7k2F58=.24dc0c1a-b7b4-4168-876d-6a8f90cf12bf@github.com>
Message-ID: <eZBd4nHPrzqAMvsUt2VbhXQ1GfHeJpe8EYTX1gwBHLs=.9fd6a076-0bbc-4c47-8377-c407629d2014@github.com>

On Wed, 9 Apr 2025 12:27:31 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   obj == null
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 540:
> 
>> 538:             return false;
>> 539:         }
>> 540: 
> 
> Here is a suggestion to modify this source as:
> 
> 
> if (obj == null || getClass() != obj.getClass()) {
>     return false;
> }
> return equalsBitSet((BitSet<?>) obj);
> 
> and with this the call to `super.equals()` won't be necessary. It seems it was unnecessary earlier too. it might have been added only to avoid missing return error.

We have to respect the `Set` contract here, and just because the two sets are of different types does not mean they can't be equal.  A `HashSet<PseudoClass>` can still be equal to a `BitSet<PseudoClass>`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1766#discussion_r2035300256

From andy.goryachev at oracle.com  Wed Apr  9 14:27:33 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 9 Apr 2025 14:27:33 +0000
Subject: Help test the behavior of a multi-screen setup with both Mac and
 Windows
In-Reply-To: <CAAP_wu=F8us2SfaYgx6YQgzzwGNHFgtjzW0cEsLZPQp5-f7wmw@mail.gmail.com>
References: <CAAP_wu=F8us2SfaYgx6YQgzzwGNHFgtjzW0cEsLZPQp5-f7wmw@mail.gmail.com>
Message-ID: <BYAPR10MB30132A49090D1C626484DD07E5B42@BYAPR10MB3013.namprd10.prod.outlook.com>

I've got Mac with one (or possibly two) external monitors.  I'll test and report later today.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Thiago Milczarek Say?o <thiago.sayao at gmail.com>
Date: Wednesday, April 9, 2025 at 03:56
To: openjfx-dev <openjfx-dev at openjdk.org>
Subject: Help test the behavior of a multi-screen setup with both Mac and Windows
Hi,

Could anyone with a multi-screen setup on Mac and/or Windows please share the results of the two buttons on this sample app? Your feedback would be greatly appreciated!

On Ubuntu 24.04 the first button moves the Stage to the end of the first screen (bit weird).
The second work as expected, it gets moved to the start of the center of the last screen.

Thanks!


import javafx.application.Application;
import javafx.geometry.Pos;
import javafx.geometry.Rectangle2D;
import javafx.scene.control.Button;
import javafx.scene.layout.VBox;
import javafx.stage.Screen;
import javafx.stage.StageStyle;
import javafx.application.Platform;
import javafx.scene.Scene;
import javafx.scene.layout.StackPane;
import javafx.scene.paint.Color;
import javafx.stage.Stage;

import java.util.Comparator;

public class TestScreenBounds extends Application {

    @Override
    public void start(Stage stage) {
        stage.setTitle("Move Outside Bounds");
        Rectangle2D bounds = Screen.getScreens().stream()
                .map(Screen::getBounds)
                .sorted(Comparator.comparingDouble(Rectangle2D::getMaxX).reversed())
                .findFirst()
                .orElseThrow();

        Button btn = new Button("Move To " + bounds.getMaxX());
        btn.setOnAction(event -> stage.setX(bounds.getMaxX()));

        double middleLastScreen = bounds.getMinX() + bounds.getWidth() / 2;

        Button btn2 = new Button("Move To " + middleLastScreen);
        btn2.setOnAction(event -> stage.setX(middleLastScreen));

        VBox root = new VBox(btn, btn2);
        root.setFillWidth(true);
        root.setAlignment(Pos.CENTER);
        Scene scene = new Scene(root, 300, 300);
        stage.setScene(scene);
        stage.show();
    }

    public static void main(String[] args) {
        launch(TestScreenBounds.class, args);
    }
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250409/0725aca5/attachment-0001.htm>

From angorya at openjdk.org  Wed Apr  9 14:31:42 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Apr 2025 14:31:42 GMT
Subject: RFR: 8234153: [TEST_BUG] Rewrite Popup_parentWindow_Test [v3]
In-Reply-To: <lBDrBvxfbTd8x0KStiUbeM_xf4tPnj7mHlyN0FugW0Q=.89f4dad0-74e3-49c0-aa43-7cb3b65816c6@github.com>
References: <7bf72skQqQkaixdRyiilnIW35lkXC_X3GzbSNt9ot0U=.256071a4-e230-4e5e-9e97-aad6f614e01b@github.com>
 <lBDrBvxfbTd8x0KStiUbeM_xf4tPnj7mHlyN0FugW0Q=.89f4dad0-74e3-49c0-aa43-7cb3b65816c6@github.com>
Message-ID: <E6i7u-qVTl1qiTAggQH2M_O2cGoByF4A2bkQIaEZYqk=.c16efdfc-9347-45bf-9e5a-bcaf220a2805@github.com>

On Wed, 9 Apr 2025 08:18:56 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This change rewrites `Popup_parentWindow_Test` after a-long-time-ago-done changes to Popup public API.
>> 
>> Popup used to have an `owner` and `parentWindow` properties. I couldn't track how far back that change happened so I can't fully say what these Properties actually were, but to my knowledge both properties were replaced by `ownerNode` and `ownerWindow` Properties respectively. New Properties are read-only and are set while calling respective `Popup.show()` - `Popup.show(Node, ...)` sets both Properties, while `Popup.show(Window, ...)` sets only `ownerWindow` Property.
>> 
>> A lot of original test scenarios were cut out because with current Popup API they make little to no sense. Original `Popup_parentWindow_Test` extended `PropertiesTestBase` and ran the regular Property access checks. Those are parametrized and split into four test methods:
>> - `testGetBean` - confidence check for whether we can get the Property bean, unnecessary since new tests access the Properties directly
>> - `testGetName` - Properties in `PropertiesTestBase` are referred to by String-provided name and Reflection, so this was a confidence check whether those Properties actually exist in the object - unnecessary, since we access the Properties directly
>> - `testBinding` - I deemed those not doable, since the Properties we try to access are read-only and cannot be bound to
>> - `testBasicAccess` - This is the only test I found that was workable into a reimplementation, and so it is manually reimplemented as `Popup_owner_Test`
>> 
>> Moreover, because of lack of `Popup.setParent()` API I also deemed more complex test scenarios (cases referring to TestScene's `_window` Property) unnecessary. Since there is no `Popup.show(Scene, ...)` those cases were also eliminated. This leaves current test pool into three separate parameters for one, similar test case.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright header update

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1763#pullrequestreview-2753702384

From angorya at openjdk.org  Wed Apr  9 14:39:39 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Apr 2025 14:39:39 GMT
Subject: RFR: 8353845: com.sun.javafx.css.BitSet.equals(null) throws NPE
 [v2]
In-Reply-To: <E4T56Dwqf2KGJQGzYpZ_h7MKFZ2PIxZJ9-Xq9MYTK2A=.1f4911da-a819-4af7-a4a4-bff3079bf623@github.com>
References: <aVflosujg1VKRBlOsO7aRs_2kcjwGliGbqY2eedajiU=.985537cb-40e5-442e-bcc0-305a4efb6272@github.com>
 <E4T56Dwqf2KGJQGzYpZ_h7MKFZ2PIxZJ9-Xq9MYTK2A=.1f4911da-a819-4af7-a4a4-bff3079bf623@github.com>
Message-ID: <v0kb-Vy6CRvmM3sY2-qOOTu9hLmAKh1Av8m-7cyOn5A=.0f09bc49-2474-4116-8338-68dd6006e965@github.com>

On Wed, 9 Apr 2025 09:07:40 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Fixes the bug that `BitSet.equals(null)` throws NPE.
>> 
>> A single reviewer should be sufficient.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   obj == null

there seems to be some discussion, so let's have 2 reviewers, just to be safe.

modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 537:

> 535:         }
> 536: 
> 537:         if (obj == null) {

minor suggestion:

if (obj == this) {
     return true;
} else if (obj == null) {

modules/javafx.graphics/src/shims/java/com/sun/javafx/css/BitSetShim.java line 189:

> 187:     }
> 188: 
> 189:     public boolean equals(Object other) {

This line generates 2 warnings in Eclipse:


Description	Resource	Type	Path	Location
The method equals(Object) of type BitSetShim<T> should be tagged with @Override since it actually overrides a superclass method	BitSetShim.java	Java Problem	/graphics/src/shims/java/com/sun/javafx/css	line 189
The type BitSetShim<T> should also implement hashCode() since it overrides Object.equals()	BitSetShim.java	Java Problem	/graphics/src/shims/java/com/sun/javafx/css	line 39


could you please enable corresponding warnings in your IDE?

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

PR Comment: https://git.openjdk.org/jfx/pull/1766#issuecomment-2789953586
PR Review Comment: https://git.openjdk.org/jfx/pull/1766#discussion_r2035522678
PR Review Comment: https://git.openjdk.org/jfx/pull/1766#discussion_r2035519039

From angorya at openjdk.org  Wed Apr  9 14:44:36 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Apr 2025 14:44:36 GMT
Subject: RFR: 8353845: com.sun.javafx.css.BitSet.equals(null) throws NPE
 [v2]
In-Reply-To: <E4T56Dwqf2KGJQGzYpZ_h7MKFZ2PIxZJ9-Xq9MYTK2A=.1f4911da-a819-4af7-a4a4-bff3079bf623@github.com>
References: <aVflosujg1VKRBlOsO7aRs_2kcjwGliGbqY2eedajiU=.985537cb-40e5-442e-bcc0-305a4efb6272@github.com>
 <E4T56Dwqf2KGJQGzYpZ_h7MKFZ2PIxZJ9-Xq9MYTK2A=.1f4911da-a819-4af7-a4a4-bff3079bf623@github.com>
Message-ID: <TXSbt3YmKvAYXaFK46h0iw0UdGD7QSNGzNBqxYq--QE=.e1b4a616-bef9-4be4-a126-82edfd7ad58e@github.com>

On Wed, 9 Apr 2025 09:07:40 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Fixes the bug that `BitSet.equals(null)` throws NPE.
>> 
>> A single reviewer should be sufficient.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   obj == null

Changes requested by angorya (Reviewer).

modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/BitSetTest.java line 52:

> 50:         assertFalse(set.equals(null));
> 51:     }
> 52: 

Since we are here, should we add a case to test `equals()` with a non-empty `HashSet` or `Set.of()`, similar to `twoEmptyBitSetsShouldBeEqual()`?

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

PR Review: https://git.openjdk.org/jfx/pull/1766#pullrequestreview-2753750024
PR Review Comment: https://git.openjdk.org/jfx/pull/1766#discussion_r2035531625

From andy.goryachev at oracle.com  Wed Apr  9 15:08:56 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 9 Apr 2025 15:08:56 +0000
Subject: Help test the behavior of a multi-screen setup with both Mac and
 Windows
In-Reply-To: <CAAP_wu=F8us2SfaYgx6YQgzzwGNHFgtjzW0cEsLZPQp5-f7wmw@mail.gmail.com>
References: <CAAP_wu=F8us2SfaYgx6YQgzzwGNHFgtjzW0cEsLZPQp5-f7wmw@mail.gmail.com>
Message-ID: <BYAPR10MB3013432CF4A8A5656A6C9119E5B42@BYAPR10MB3013.namprd10.prod.outlook.com>

Here are the results on macOS 15.3.2, with the primary (retina, scale=2) at the bottom and the external (scale=1) at the top like so

[cid:image001.png at 01DBA925.BCAC1580]

In both cases, the first button (Move To 1800.0) moves the window to the same screen partially outside of the viewing area (only about ~15% of the left side remains visible), while the other button (Move To 900.0) shifts to the right.

My setup uses the setting [Desktop & Dock -> Displays have separate Spaces OFF] so I can move the windows between the monitors.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Thiago Milczarek Say?o <thiago.sayao at gmail.com>
Date: Wednesday, April 9, 2025 at 03:56
To: openjfx-dev <openjfx-dev at openjdk.org>
Subject: Help test the behavior of a multi-screen setup with both Mac and Windows
Hi,

Could anyone with a multi-screen setup on Mac and/or Windows please share the results of the two buttons on this sample app? Your feedback would be greatly appreciated!

On Ubuntu 24.04 the first button moves the Stage to the end of the first screen (bit weird).
The second work as expected, it gets moved to the start of the center of the last screen.

Thanks!


import javafx.application.Application;
import javafx.geometry.Pos;
import javafx.geometry.Rectangle2D;
import javafx.scene.control.Button;
import javafx.scene.layout.VBox;
import javafx.stage.Screen;
import javafx.stage.StageStyle;
import javafx.application.Platform;
import javafx.scene.Scene;
import javafx.scene.layout.StackPane;
import javafx.scene.paint.Color;
import javafx.stage.Stage;

import java.util.Comparator;

public class TestScreenBounds extends Application {

    @Override
    public void start(Stage stage) {
        stage.setTitle("Move Outside Bounds");
        Rectangle2D bounds = Screen.getScreens().stream()
                .map(Screen::getBounds)
                .sorted(Comparator.comparingDouble(Rectangle2D::getMaxX).reversed())
                .findFirst()
                .orElseThrow();

        Button btn = new Button("Move To " + bounds.getMaxX());
        btn.setOnAction(event -> stage.setX(bounds.getMaxX()));

        double middleLastScreen = bounds.getMinX() + bounds.getWidth() / 2;

        Button btn2 = new Button("Move To " + middleLastScreen);
        btn2.setOnAction(event -> stage.setX(middleLastScreen));

        VBox root = new VBox(btn, btn2);
        root.setFillWidth(true);
        root.setAlignment(Pos.CENTER);
        Scene scene = new Scene(root, 300, 300);
        stage.setScene(scene);
        stage.show();
    }

    public static void main(String[] args) {
        launch(TestScreenBounds.class, args);
    }
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250409/d85fa2e2/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5055 bytes
Desc: image001.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250409/d85fa2e2/image001-0001.png>

From martinfox656 at gmail.com  Wed Apr  9 15:28:22 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Wed, 9 Apr 2025 08:28:22 -0700
Subject: Help test the behavior of a multi-screen setup with both Mac and
 Windows
In-Reply-To: <BYAPR10MB3013432CF4A8A5656A6C9119E5B42@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <CAAP_wu=F8us2SfaYgx6YQgzzwGNHFgtjzW0cEsLZPQp5-f7wmw@mail.gmail.com>
 <BYAPR10MB3013432CF4A8A5656A6C9119E5B42@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <A0967DD1-4778-4C16-BFB5-704A881B87F4@gmail.com>

On macOS 15.3.2 I get the same results as Andy. When I press the top button glass asks the OS to move the window offscreen but the OS shifts the location 40 units to the left so it?s partially onscreen.

> On Apr 9, 2025, at 8:08?AM, Andy Goryachev <andy.goryachev at oracle.com> wrote:
> 
> Here are the results on macOS 15.3.2, with the primary (retina, scale=2) at the bottom and the external (scale=1) at the top like so
>  
> <image001.png>
>  
> In both cases, the first button (Move To 1800.0) moves the window to the same screen partially outside of the viewing area (only about ~15% of the left side remains visible), while the other button (Move To 900.0) shifts to the right.
>  
> My setup uses the setting [Desktop & Dock -> Displays have separate Spaces OFF] so I can move the windows between the monitors.
>  
> -andy
>  
>  
> From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Thiago Milczarek Say?o <thiago.sayao at gmail.com>
> Date: Wednesday, April 9, 2025 at 03:56
> To: openjfx-dev <openjfx-dev at openjdk.org>
> Subject: Help test the behavior of a multi-screen setup with both Mac and Windows
> 
> Hi,
>  
> Could anyone with a multi-screen setup on Mac and/or Windows please share the results of the two buttons on this sample app? Your feedback would be greatly appreciated!
>  
> On Ubuntu 24.04 the first button moves the Stage to the end of the first screen (bit weird). 
> The second work as expected, it gets moved to the start of the center of the last screen.
>  
> Thanks!
>  
> import javafx.application.Application;
> import javafx.geometry.Pos;
> import javafx.geometry.Rectangle2D;
> import javafx.scene.control.Button;
> import javafx.scene.layout.VBox;
> import javafx.stage.Screen;
> import javafx.stage.StageStyle;
> import javafx.application.Platform;
> import javafx.scene.Scene;
> import javafx.scene.layout.StackPane;
> import javafx.scene.paint.Color;
> import javafx.stage.Stage;
> 
> import java.util.Comparator;
> 
> public class TestScreenBounds extends Application {
> 
>     @Override
>     public void start(Stage stage) {
>         stage.setTitle("Move Outside Bounds");
>         Rectangle2D bounds = Screen.getScreens().stream()
>                 .map(Screen::getBounds)
>                 .sorted(Comparator.comparingDouble(Rectangle2D::getMaxX).reversed())
>                 .findFirst()
>                 .orElseThrow();
> 
>         Button btn = new Button("Move To " + bounds.getMaxX());
>         btn.setOnAction(event -> stage.setX(bounds.getMaxX()));
> 
>         double middleLastScreen = bounds.getMinX() + bounds.getWidth() / 2;
> 
>         Button btn2 = new Button("Move To " + middleLastScreen);
>         btn2.setOnAction(event -> stage.setX(middleLastScreen));
> 
>         VBox root = new VBox(btn, btn2);
>         root.setFillWidth(true);
>         root.setAlignment(Pos.CENTER);
>         Scene scene = new Scene(root, 300, 300);
>         stage.setScene(scene);
>         stage.show();
>     }
> 
>     public static void main(String[] args) {
>         launch(TestScreenBounds.class, args);
>     }
> }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250409/8c8a1f30/attachment.htm>

From lkostyra at openjdk.org  Wed Apr  9 15:38:34 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 9 Apr 2025 15:38:34 GMT
Subject: Integrated: 8234153: [TEST_BUG] Rewrite Popup_parentWindow_Test
In-Reply-To: <7bf72skQqQkaixdRyiilnIW35lkXC_X3GzbSNt9ot0U=.256071a4-e230-4e5e-9e97-aad6f614e01b@github.com>
References: <7bf72skQqQkaixdRyiilnIW35lkXC_X3GzbSNt9ot0U=.256071a4-e230-4e5e-9e97-aad6f614e01b@github.com>
Message-ID: <InGVxkv_52Im8BsPkxddybGBIIvVfrmUBZrUlKBG6GY=.589de569-ab47-4cae-a24f-2c9a7fbe72f5@github.com>

On Fri, 4 Apr 2025 11:30:04 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> This change rewrites `Popup_parentWindow_Test` after a-long-time-ago-done changes to Popup public API.
> 
> Popup used to have an `owner` and `parentWindow` properties. I couldn't track how far back that change happened so I can't fully say what these Properties actually were, but to my knowledge both properties were replaced by `ownerNode` and `ownerWindow` Properties respectively. New Properties are read-only and are set while calling respective `Popup.show()` - `Popup.show(Node, ...)` sets both Properties, while `Popup.show(Window, ...)` sets only `ownerWindow` Property.
> 
> A lot of original test scenarios were cut out because with current Popup API they make little to no sense. Original `Popup_parentWindow_Test` extended `PropertiesTestBase` and ran the regular Property access checks. Those are parametrized and split into four test methods:
> - `testGetBean` - confidence check for whether we can get the Property bean, unnecessary since new tests access the Properties directly
> - `testGetName` - Properties in `PropertiesTestBase` are referred to by String-provided name and Reflection, so this was a confidence check whether those Properties actually exist in the object - unnecessary, since we access the Properties directly
> - `testBinding` - I deemed those not doable, since the Properties we try to access are read-only and cannot be bound to
> - `testBasicAccess` - This is the only test I found that was workable into a reimplementation, and so it is manually reimplemented as `Popup_owner_Test`
> 
> Moreover, because of lack of `Popup.setParent()` API I also deemed more complex test scenarios (cases referring to TestScene's `_window` Property) unnecessary. Since there is no `Popup.show(Scene, ...)` those cases were also eliminated. This leaves current test pool into three separate parameters for one, similar test case.

This pull request has now been integrated.

Changeset: 3dc975bd
Author:    Lukasz Kostyra <lkostyra at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/3dc975bd9fbdc2005d0260bad80d1e775ecfe189
Stats:     400 lines in 2 files changed: 257 ins; 143 del; 0 mod

8234153: [TEST_BUG] Rewrite Popup_parentWindow_Test

Reviewed-by: angorya, arapte

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

PR: https://git.openjdk.org/jfx/pull/1763

From lkostyra at openjdk.org  Wed Apr  9 15:38:33 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 9 Apr 2025 15:38:33 GMT
Subject: RFR: 8234153: [TEST_BUG] Rewrite Popup_parentWindow_Test [v3]
In-Reply-To: <lBDrBvxfbTd8x0KStiUbeM_xf4tPnj7mHlyN0FugW0Q=.89f4dad0-74e3-49c0-aa43-7cb3b65816c6@github.com>
References: <7bf72skQqQkaixdRyiilnIW35lkXC_X3GzbSNt9ot0U=.256071a4-e230-4e5e-9e97-aad6f614e01b@github.com>
 <lBDrBvxfbTd8x0KStiUbeM_xf4tPnj7mHlyN0FugW0Q=.89f4dad0-74e3-49c0-aa43-7cb3b65816c6@github.com>
Message-ID: <ZgoavU926l2uROCtfcbuEVkAzKWE7vV26RcS6UK0aRM=.dca59d7a-a993-448c-8e38-ee3396ae4c7d@github.com>

On Wed, 9 Apr 2025 08:18:56 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This change rewrites `Popup_parentWindow_Test` after a-long-time-ago-done changes to Popup public API.
>> 
>> Popup used to have an `owner` and `parentWindow` properties. I couldn't track how far back that change happened so I can't fully say what these Properties actually were, but to my knowledge both properties were replaced by `ownerNode` and `ownerWindow` Properties respectively. New Properties are read-only and are set while calling respective `Popup.show()` - `Popup.show(Node, ...)` sets both Properties, while `Popup.show(Window, ...)` sets only `ownerWindow` Property.
>> 
>> A lot of original test scenarios were cut out because with current Popup API they make little to no sense. Original `Popup_parentWindow_Test` extended `PropertiesTestBase` and ran the regular Property access checks. Those are parametrized and split into four test methods:
>> - `testGetBean` - confidence check for whether we can get the Property bean, unnecessary since new tests access the Properties directly
>> - `testGetName` - Properties in `PropertiesTestBase` are referred to by String-provided name and Reflection, so this was a confidence check whether those Properties actually exist in the object - unnecessary, since we access the Properties directly
>> - `testBinding` - I deemed those not doable, since the Properties we try to access are read-only and cannot be bound to
>> - `testBasicAccess` - This is the only test I found that was workable into a reimplementation, and so it is manually reimplemented as `Popup_owner_Test`
>> 
>> Moreover, because of lack of `Popup.setParent()` API I also deemed more complex test scenarios (cases referring to TestScene's `_window` Property) unnecessary. Since there is no `Popup.show(Scene, ...)` those cases were also eliminated. This leaves current test pool into three separate parameters for one, similar test case.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright header update

Thanks for review everyone!

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

PR Comment: https://git.openjdk.org/jfx/pull/1763#issuecomment-2790138852

From thiago.sayao at gmail.com  Wed Apr  9 16:08:32 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Wed, 9 Apr 2025 13:08:32 -0300
Subject: Help test the behavior of a multi-screen setup with both Mac and
 Windows
In-Reply-To: <A0967DD1-4778-4C16-BFB5-704A881B87F4@gmail.com>
References: <CAAP_wu=F8us2SfaYgx6YQgzzwGNHFgtjzW0cEsLZPQp5-f7wmw@mail.gmail.com>
 <BYAPR10MB3013432CF4A8A5656A6C9119E5B42@BYAPR10MB3013.namprd10.prod.outlook.com>
 <A0967DD1-4778-4C16-BFB5-704A881B87F4@gmail.com>
Message-ID: <CAAP_wuk6+rG19h3HYUBii_NXMCLFwwQ_KGEeMWTou_u2LebKCw@mail.gmail.com>

Thank you all for the feedback.

I believe the documentation for the Stage class could benefit from
additional clarification. I will draft some suggestions and submit them for
review.

-- Thiago

Em qua., 9 de abr. de 2025 ?s 12:28, Martin Fox <martinfox656 at gmail.com>
escreveu:

> On macOS 15.3.2 I get the same results as Andy. When I press the top
> button glass asks the OS to move the window offscreen but the OS shifts the
> location 40 units to the left so it?s partially onscreen.
>
> On Apr 9, 2025, at 8:08?AM, Andy Goryachev <andy.goryachev at oracle.com>
> wrote:
>
> Here are the results on macOS 15.3.2, with the primary (retina, scale=2)
> at the bottom and the external (scale=1) at the top like so
>
> <image001.png>
>
> In both cases, the first button (Move To 1800.0) moves the window to the
> same screen partially outside of the viewing area (only about ~15% of the
> left side remains visible), while the other button (Move To 900.0) shifts
> to the right.
>
> My setup uses the setting [Desktop & Dock -> Displays have separate Spaces
> OFF] so I can move the windows between the monitors.
>
> -andy
>
>
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Thiago
> Milczarek Say?o <thiago.sayao at gmail.com>
> *Date: *Wednesday, April 9, 2025 at 03:56
> *To: *openjfx-dev <openjfx-dev at openjdk.org>
> *Subject: *Help test the behavior of a multi-screen setup with both Mac
> and Windows
> Hi,
>
> Could anyone with a multi-screen setup on Mac and/or Windows please share
> the results of the two buttons on this sample app? Your feedback would be
> greatly appreciated!
>
> On Ubuntu 24.04 the first button moves the Stage to the end of the first
> screen (bit weird).
> The second work as expected, it gets moved to the start of the center of
> the last screen.
>
> Thanks!
>
>
> import javafx.application.Application;
> import javafx.geometry.Pos;
> import javafx.geometry.Rectangle2D;
> import javafx.scene.control.Button;
> import javafx.scene.layout.VBox;
> import javafx.stage.Screen;
> import javafx.stage.StageStyle;
> import javafx.application.Platform;
> import javafx.scene.Scene;
> import javafx.scene.layout.StackPane;
> import javafx.scene.paint.Color;
> import javafx.stage.Stage;
>
> import java.util.Comparator;
>
> public class TestScreenBounds extends Application {
>
>     @Override
>     public void start(Stage stage) {
>         stage.setTitle("Move Outside Bounds");
>         Rectangle2D bounds = Screen.getScreens().stream()
>                 .map(Screen::getBounds)
>                 .sorted(Comparator.comparingDouble(Rectangle2D::getMaxX).reversed())
>                 .findFirst()
>                 .orElseThrow();
>
>         Button btn = new Button("Move To " + bounds.getMaxX());
>         btn.setOnAction(event -> stage.setX(bounds.getMaxX()));
>
>         double middleLastScreen = bounds.getMinX() + bounds.getWidth() / 2;
>
>         Button btn2 = new Button("Move To " + middleLastScreen);
>         btn2.setOnAction(event -> stage.setX(middleLastScreen));
>
>         VBox root = new VBox(btn, btn2);
>         root.setFillWidth(true);
>         root.setAlignment(Pos.CENTER);
>         Scene scene = new Scene(root, 300, 300);
>         stage.setScene(scene);
>         stage.show();
>     }
>
>     public static void main(String[] args) {
>         launch(TestScreenBounds.class, args);
>     }
> }
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250409/6c149b65/attachment-0001.htm>

From andy.goryachev at oracle.com  Wed Apr  9 18:25:59 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 9 Apr 2025 18:25:59 +0000
Subject: [External] : Re: TabPane overflow menu showing blanks
In-Reply-To: <CAG_-AaCbiTvMhdZ2BWu=FvWMYDgwODd4sKU+vdZS-jvcOwqc0w@mail.gmail.com>
References: <CAGBnJPt_7_sJq8rX3fENXt3LU2=BZ5xN2mHy5L0gPd3fpFjyww@mail.gmail.com>
 <BYAPR10MB301380B0A50E2EAA83512B94E5AA2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <CAG_-AaCbiTvMhdZ2BWu=FvWMYDgwODd4sKU+vdZS-jvcOwqc0w@mail.gmail.com>
Message-ID: <BYAPR10MB3013DE13039AA1E97368E6B1E5B42@BYAPR10MB3013.namprd10.prod.outlook.com>

No problem, Cormac, and thank you for suggestions!  I guess you will be volunteering for the code review?  (No promises as to when this feature will be available though).

Speaking of the disabling the overflow menu: this may not be a good idea from the accessibility perspective, but the idea of menu item factory looks quite promising.  Since we are on the subject, there is one more possibility - Tab::setGraphicProvider(Supplier<Node>) instead of a menu item factory, in addition to the existing Tab::setGraphic(Node).  Might be less flexible as one won't be able to create custom menu items.  Just a thought.

-andy


From: Cormac Redmond <credmond at certak.com>
Date: Tuesday, April 8, 2025 at 15:49
To: Andy Goryachev <andy.goryachev at oracle.com>
Cc: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: [External] : Re: TabPane overflow menu showing blanks
Hi Andy,

Thank you for your reply.

That sounds good, re: a menu item factory. E.g., give the devs full control.

I think the ability to disable it (or have it disabled by default) would be good too: a dev might not care about supporting the menu items in many cases. E.g., if a TabPane only has three (graphic-based) tabs, and the user decides to resize the window to something unusually small, then who cares if they can't traverse the tabs, at that size? Nobody realistically expects to be able in such a scenario anyway, and it's better to have no menu than a buggy one.

I don't like the fact that, today, TabPane's menu can misbehave and nobody would know it's going to happen really. I think TabPane should throw an exception (or log a warning) when it receives nodes it knows it will not be able to use in the menu; especially given the menu is always-on.

I think a good overall solution would be:
1.   a menu factory
2.   make the menu optional for those who don't care
3.   log warnings when a tab's header node will not be displayable in a menu (i.e., if the dev hasn't provided a factory and the default "menu factory" knowingly cannot handle it)
1.   Not really sure how JFX folks feel about logging warnings, I note it's minimal today in general, and probably for good reason (e.g., where do you draw the line in the sand about what should be logged vs. not)
Anyway, I think the above will be achievable without any breaking / functionality changes...?



Kind Regards,
Cormac

On Mon, 7 Apr 2025 at 17:59, Andy Goryachev <andy.goryachev at oracle.com<mailto:andy.goryachev at oracle.com>> wrote:
All very good points, thank you for this writeup!

This discussion relates to https://bugs.openjdk.org/browse/JDK-8353599 .  I've been thinking how to handle this issue, and I am leaning to agree with the suggestion proposed in the ticket (some sort of menu item factory).

The current "hacky" solution not obviously fails, but also not scalable - I can see developers wanting to place a Canvas, a Path, a Pane, or any other kind of Node and it would be nearly impossible to "clone" these in a maintainable manner.  With a menu item factory, however, the effort will be shifted on the application dev with a very simple solution.

The other solution that does not involve a new API would be to limit the overflow menu to only list the tabs that are hidden - in this case the graphics Nodes can be reused by the menu items.  The problem with that approach is the overflow menu logic becomes more complicated, to handle the case when menus are hidden on both ends.

What do you think?

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org<mailto:openjfx-dev-retn at openjdk.org>> on behalf of Cormac Redmond <credmond at certak.com<mailto:credmond at certak.com>>
Date: Friday, April 4, 2025 at 17:00
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: TabPane overflow menu showing blanks
Hi,

TabPane tabs allow you to set graphic nodes as the header and there appears to be no documented limitations or best-practises on this.

You might assume it's perfectly reasonable to not set a Tab's text value, and instead set the header as a HBox, consisting of a graphic node (left) and a Label (itself with a text + a graphic, right), to achieve an icon-text-icon style header, which is not an uncommon.

However, the overflow menu, when it kicks in, will not display any text or graphics at all (just a blank space), if your Tab has no "text" set, and the header graphic is not a Label or an ImageView.

It's down to this self-confessed hacky code (https://github.com/openjdk/jfx/blob/f31d00d8f7e601c3bb28a9975dd029390ec92173/modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java#L479<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/blob/f31d00d8f7e601c3bb28a9975dd029390ec92173/modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java*L479__;Iw!!ACWV5N9M2RV99hQ!Mran6HXmukSt2WDoAR19oIpx2dUYe7SVW7YGm6LeVeGvjzbRIBG_bZU5PLxtBI6BiE7zFepT1Vk08YpHig6pbw$>):

    /**
     * VERY HACKY - this lets us 'duplicate' Label and ImageView nodes to be used in a
     * Tab and the tabs menu at the same time.
     */
    private static Node clone(Node n) {
        if (n == null) {
            return null;
        }
        if (n instanceof ImageView) {
            ImageView iv = (ImageView) n;
            ImageView imageview = new ImageView();
            imageview.imageProperty().bind(iv.imageProperty());
            return imageview;
        }
        if (n instanceof Label) {
            Label l = (Label)n;
            Label label = new Label(l.getText(), clone(l.getGraphic()));
            label.textProperty().bind(l.textProperty());
            return label;
        }
        return null;
    }


It is not obvious at all that this is what's going to happen, or why. And it seems impossible to control or influence this in any reasonable way, without replacing the whole TabPaneSkin.

Given TabPane is one of the most important and widely used controls there is, there could/should be some of the following:

  *   Proper documentation on this limitation / behaviour
  *   Some way to set fallback text that can be used in the menu (i.e., that isn't the Tab's header's text, because one might intentionally avoid setting that given there's no way to hide it from the tab header)
  *   Or, better yet, some way to allow you to specify tab header text without displaying it in the actual tab header, which could then be used by the hacky method as normal
  *   Some way to set a callback so the developer can decide what gets displayed for the overflow menu
  *   Some way to override the skin without needing a full copy + paste + rename
  *   Some way to allow the dev to disable the overflow menu, if it's going to produce something unusable. E.g., prefer no menu than a buggy one...

I would view this as a bug, even though it's probably been like this forever.


Some sample code to demonstrate; just look at the menu:

public class TabPaneMenu extends Application {
    @Override
    public void start(Stage primaryStage) {
        TabPane tabPane = new TabPane();

        for (int i = 1; i <= 30; i++) {
            Tab tab;
            if (i == 2) {
                tab = new Tab();
                final Label label = new Label("HBox Tab " + i);
                final HBox hBox = new HBox(label); // Will show as blank in overflow menu!
                tab.setGraphic(hBox);
            } else if (i == 5) {
                tab = new Tab();
                tab.setGraphic(new Label("Label Tab " + i)); // Will show in overflow menu, because it's a Label
            } else {
                tab = new Tab("Normal Tab " + i);
            }

            tab.setContent(new StackPane(new Label("This is Tab " + i)));
            tab.setClosable(false);
            tabPane.getTabs().add(tab);

        }

        Scene scene = new Scene(tabPane, 800, 600);
        primaryStage.setScene(scene);
        primaryStage.show();
    }

    public static void main(String[] args) {
        launch(args);
    }
}


Kind Regards,

Cormac Redmond
Software Engineer, Certak Ltd.

e: credmond at certak.com<mailto:credmond at certak.com> | m: +353 (0) 86 268 2152 | w: www.certak.com<https://urldefense.com/v3/__http:/www.certak.com__;!!ACWV5N9M2RV99hQ!Mran6HXmukSt2WDoAR19oIpx2dUYe7SVW7YGm6LeVeGvjzbRIBG_bZU5PLxtBI6BiE7zFepT1Vk08YpVdP5RVQ$>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250409/53b69653/attachment-0001.htm>

From mstrauss at openjdk.org  Wed Apr  9 18:27:12 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 9 Apr 2025 18:27:12 GMT
Subject: RFR: 8353845: com.sun.javafx.css.BitSet.equals(null) throws NPE
 [v3]
In-Reply-To: <aVflosujg1VKRBlOsO7aRs_2kcjwGliGbqY2eedajiU=.985537cb-40e5-442e-bcc0-305a4efb6272@github.com>
References: <aVflosujg1VKRBlOsO7aRs_2kcjwGliGbqY2eedajiU=.985537cb-40e5-442e-bcc0-305a4efb6272@github.com>
Message-ID: <6iFXX-sAHgUVz1iCm61Sz9JZ2fA5zF1cZgjhT0jOKaA=.4bd295e7-ae1a-4fbf-a611-fa25d0d3f0d4@github.com>

> Fixes the bug that `BitSet.equals(null)` throws NPE.
> 
> A single reviewer should be sufficient.

Michael Strau? has updated the pull request incrementally with three additional commits since the last revision:

 - hashSet.equals(bitSet)
 - review comments
 - review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1766/files
  - new: https://git.openjdk.org/jfx/pull/1766/files/fda65a71..2da3bd93

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1766&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1766&range=01-02

  Stats: 19 lines in 3 files changed: 16 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1766.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1766/head:pull/1766

PR: https://git.openjdk.org/jfx/pull/1766

From angorya at openjdk.org  Wed Apr  9 18:36:52 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Apr 2025 18:36:52 GMT
Subject: RFR: 8353845: com.sun.javafx.css.BitSet.equals(null) throws NPE
 [v3]
In-Reply-To: <6iFXX-sAHgUVz1iCm61Sz9JZ2fA5zF1cZgjhT0jOKaA=.4bd295e7-ae1a-4fbf-a611-fa25d0d3f0d4@github.com>
References: <aVflosujg1VKRBlOsO7aRs_2kcjwGliGbqY2eedajiU=.985537cb-40e5-442e-bcc0-305a4efb6272@github.com>
 <6iFXX-sAHgUVz1iCm61Sz9JZ2fA5zF1cZgjhT0jOKaA=.4bd295e7-ae1a-4fbf-a611-fa25d0d3f0d4@github.com>
Message-ID: <GaSyOeMNtCtnTQC4-c-v0E-2OUOUleGX6ea15NqRwAk=.39d3320d-8b1c-4a63-87bd-663da00fbe6b@github.com>

On Wed, 9 Apr 2025 18:27:12 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Fixes the bug that `BitSet.equals(null)` throws NPE.
>> 
>> A single reviewer should be sufficient.
>
> Michael Strau? has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - hashSet.equals(bitSet)
>  - review comments
>  - review comments

thank you for fixing the bug and making the changes!

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1766#pullrequestreview-2754388528

From angorya at openjdk.org  Wed Apr  9 18:43:36 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Apr 2025 18:43:36 GMT
Subject: RFR: 8353845: com.sun.javafx.css.BitSet.equals(null) throws NPE
 [v3]
In-Reply-To: <6iFXX-sAHgUVz1iCm61Sz9JZ2fA5zF1cZgjhT0jOKaA=.4bd295e7-ae1a-4fbf-a611-fa25d0d3f0d4@github.com>
References: <aVflosujg1VKRBlOsO7aRs_2kcjwGliGbqY2eedajiU=.985537cb-40e5-442e-bcc0-305a4efb6272@github.com>
 <6iFXX-sAHgUVz1iCm61Sz9JZ2fA5zF1cZgjhT0jOKaA=.4bd295e7-ae1a-4fbf-a611-fa25d0d3f0d4@github.com>
Message-ID: <F-YLyWaFU5pmEjhC50OQAPEuTcxBj6iavHq4aqy9uvk=.dbecfa21-83a8-4379-814b-e6529d8b9aba@github.com>

On Wed, 9 Apr 2025 18:27:12 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Fixes the bug that `BitSet.equals(null)` throws NPE.
>> 
>> A single reviewer should be sufficient.
>
> Michael Strau? has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - hashSet.equals(bitSet)
>  - review comments
>  - review comments

https://github.com/openjdk/jfx/pull/1766/checks?check_run_id=40273913986

this is a weird failure, I've never seen it before.  something happened at cygwin (after yesterday outage) perhaps?

@mstr2 could you re-run the windows job please?

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

PR Comment: https://git.openjdk.org/jfx/pull/1766#issuecomment-2790622047

From jhendrikx at openjdk.org  Wed Apr  9 19:19:40 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 9 Apr 2025 19:19:40 GMT
Subject: RFR: 8353845: com.sun.javafx.css.BitSet.equals(null) throws NPE
 [v3]
In-Reply-To: <6iFXX-sAHgUVz1iCm61Sz9JZ2fA5zF1cZgjhT0jOKaA=.4bd295e7-ae1a-4fbf-a611-fa25d0d3f0d4@github.com>
References: <aVflosujg1VKRBlOsO7aRs_2kcjwGliGbqY2eedajiU=.985537cb-40e5-442e-bcc0-305a4efb6272@github.com>
 <6iFXX-sAHgUVz1iCm61Sz9JZ2fA5zF1cZgjhT0jOKaA=.4bd295e7-ae1a-4fbf-a611-fa25d0d3f0d4@github.com>
Message-ID: <Ag-XubnVMtiqLRO69rqREKE9mNBVyk5JGz_jYUs0xBY=.de4fdcc8-99f9-4f99-8e4f-3388b5d601e9@github.com>

On Wed, 9 Apr 2025 18:27:12 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Fixes the bug that `BitSet.equals(null)` throws NPE.
>> 
>> A single reviewer should be sufficient.
>
> Michael Strau? has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - hashSet.equals(bitSet)
>  - review comments
>  - review comments

Marked as reviewed by jhendrikx (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1766#pullrequestreview-2754537279

From mstrauss at openjdk.org  Wed Apr  9 19:19:40 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 9 Apr 2025 19:19:40 GMT
Subject: RFR: 8353845: com.sun.javafx.css.BitSet.equals(null) throws NPE
 [v3]
In-Reply-To: <F-YLyWaFU5pmEjhC50OQAPEuTcxBj6iavHq4aqy9uvk=.dbecfa21-83a8-4379-814b-e6529d8b9aba@github.com>
References: <aVflosujg1VKRBlOsO7aRs_2kcjwGliGbqY2eedajiU=.985537cb-40e5-442e-bcc0-305a4efb6272@github.com>
 <6iFXX-sAHgUVz1iCm61Sz9JZ2fA5zF1cZgjhT0jOKaA=.4bd295e7-ae1a-4fbf-a611-fa25d0d3f0d4@github.com>
 <F-YLyWaFU5pmEjhC50OQAPEuTcxBj6iavHq4aqy9uvk=.dbecfa21-83a8-4379-814b-e6529d8b9aba@github.com>
Message-ID: <J6YBa9BcuIzhcDhkNlS4NXRoAHxJPOvJDdd9S0LoCa0=.2965b100-0147-4020-b57b-117cc596ce87@github.com>

On Wed, 9 Apr 2025 18:41:06 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> https://github.com/openjdk/jfx/pull/1766/checks?check_run_id=40273913986
> 
> this is a weird failure, I've never seen it before. something happened at cygwin (after yesterday outage) perhaps?
> 
> @mstr2 could you re-run the windows job please?

Seems like the failure is persistent.

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

PR Comment: https://git.openjdk.org/jfx/pull/1766#issuecomment-2790762571

From kcr at openjdk.org  Wed Apr  9 19:28:40 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 9 Apr 2025 19:28:40 GMT
Subject: RFR: 8353845: com.sun.javafx.css.BitSet.equals(null) throws NPE
 [v3]
In-Reply-To: <J6YBa9BcuIzhcDhkNlS4NXRoAHxJPOvJDdd9S0LoCa0=.2965b100-0147-4020-b57b-117cc596ce87@github.com>
References: <aVflosujg1VKRBlOsO7aRs_2kcjwGliGbqY2eedajiU=.985537cb-40e5-442e-bcc0-305a4efb6272@github.com>
 <6iFXX-sAHgUVz1iCm61Sz9JZ2fA5zF1cZgjhT0jOKaA=.4bd295e7-ae1a-4fbf-a611-fa25d0d3f0d4@github.com>
 <F-YLyWaFU5pmEjhC50OQAPEuTcxBj6iavHq4aqy9uvk=.dbecfa21-83a8-4379-814b-e6529d8b9aba@github.com>
 <J6YBa9BcuIzhcDhkNlS4NXRoAHxJPOvJDdd9S0LoCa0=.2965b100-0147-4020-b57b-117cc596ce87@github.com>
Message-ID: <AFuyocu_eYG7Fpp4LkWRgGWiaLew7Z0x25Fm7R_IyxY=.bd8fbfe5-b359-4deb-a1e5-cfe5e432b17b@github.com>

On Wed, 9 Apr 2025 19:17:33 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> > https://github.com/openjdk/jfx/pull/1766/checks?check_run_id=40273913986
> > this is a weird failure, I've never seen it before. something happened at cygwin (after yesterday outage) perhaps?
> > @mstr2 could you re-run the windows job please?
> 
> Seems like the failure is persistent.

That's what I see, too. I pushed the current master branch to a new `test-build` branch in my repo to trigger a GHA build. Same error:

https://github.com/kevinrushforth/jfx/actions/runs/14364598377/job/40274343597

I'll look into this and file a follow-up bug later, but it's unrelated to this PR nor does not impact its readiness to integrate.

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

PR Comment: https://git.openjdk.org/jfx/pull/1766#issuecomment-2790780047

From mstrauss at openjdk.org  Wed Apr  9 20:07:42 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 9 Apr 2025 20:07:42 GMT
Subject: Integrated: 8353845: com.sun.javafx.css.BitSet.equals(null) throws NPE
In-Reply-To: <aVflosujg1VKRBlOsO7aRs_2kcjwGliGbqY2eedajiU=.985537cb-40e5-442e-bcc0-305a4efb6272@github.com>
References: <aVflosujg1VKRBlOsO7aRs_2kcjwGliGbqY2eedajiU=.985537cb-40e5-442e-bcc0-305a4efb6272@github.com>
Message-ID: <BaTM--EPuPW0STE5g6-AMuuleqOs5eSWyUiGIQTuahA=.755db205-7605-47aa-96d5-300c1a4a8f55@github.com>

On Wed, 9 Apr 2025 07:06:29 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Fixes the bug that `BitSet.equals(null)` throws NPE.
> 
> A single reviewer should be sufficient.

This pull request has now been integrated.

Changeset: 9ac707da
Author:    Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/9ac707dac4d675a4301241ae100fd26b08e57bf1
Stats:     34 lines in 3 files changed: 28 ins; 2 del; 4 mod

8353845: com.sun.javafx.css.BitSet.equals(null) throws NPE

Reviewed-by: jhendrikx, angorya

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

PR: https://git.openjdk.org/jfx/pull/1766

From kcr at openjdk.org  Wed Apr  9 23:22:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 9 Apr 2025 23:22:52 GMT
Subject: [jfx24u] RFR: 8354182: Create release notes for JavaFX 24.0.1
Message-ID: <wWrn0MNNgD9xJ9yXYG6fXgk5YOBcXLl5qwvXA5c5T5M=.339e7c61-705c-4e34-b6f9-f6783c1e3eb8@github.com>

Release notes for JavaFX 24.0.1.

Notes to reviewers:

I used the following filter to pick the issues:

https://bugs.openjdk.org/issues/?filter=47358

The original filter, with the backport IDs, is here:

https://bugs.openjdk.org/issues/?filter=47357

As usual, I excluded test bugs, cleanup bugs, etc.

NOTE: Once the CPU release ships on 2025-04-15, I will add any security bugs and ask for a re-review.

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

Commit messages:
 - 8354182: Create release notes for JavaFX 24.0.1

Changes: https://git.openjdk.org/jfx24u/pull/19/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx24u&pr=19&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354182
  Stats: 25 lines in 1 file changed: 25 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx24u/pull/19.diff
  Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/19/head:pull/19

PR: https://git.openjdk.org/jfx24u/pull/19

From mstrauss at openjdk.org  Thu Apr 10 10:05:37 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 10 Apr 2025 10:05:37 GMT
Subject: RFR: 8345348: CSS media feature queries [v9]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <BkSEwG0FIOy_zTs3zg5307r-WxntmiZ81PH27hvQeMo=.71a6d7a7-fe7f-4255-8800-5c3c65c2061d@github.com>

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  add more tests

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/0a5626b8..d640ab07

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=08
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=07-08

  Stats: 108 lines in 1 file changed: 108 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1655.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655

PR: https://git.openjdk.org/jfx/pull/1655

From thiago.sayao at gmail.com  Thu Apr 10 12:17:05 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Thu, 10 Apr 2025 09:17:05 -0300
Subject: Stage Maximized/Iconified at the same time
Message-ID: <CAAP_wukXrDDQSvHEtym6awK0jGmgx5dUqP1Vvf+z5txs7VXfcw@mail.gmail.com>

Hi,

I don't have a Mac to test, but on Linux and Windows, a window can be both
maximized and iconified at the same time. It retains the maximized state
when restored from being iconified.

I've mentioned this topic before, but it's now clear to me that there's a
bug in JavaFX related to this behavior.

from glass ui\Window.java:

final static public class State {
    @Native public static final int NORMAL = 1;
    @Native public static final int MINIMIZED = 2;
    @Native public static final int MAXIMIZED = 3;
}


from quantum GlassWindowEventHandler.java

case WindowEvent.RESTORE:
    stage.stageListener.changedIconified(false);
    stage.stageListener.changedMaximized(false);
    break;


TestStage.java for testing this:
https://gist.github.com/tsayao/5efca2e6f0f661595b31da37e2e7df26

I probably can submit a fix.

-- Thiago.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250410/417e8608/attachment.htm>

From kcr at openjdk.org  Thu Apr 10 15:05:43 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Apr 2025 15:05:43 GMT
Subject: [jfx24u] RFR: 8354182: Create release notes for JavaFX 24.0.1
In-Reply-To: <wWrn0MNNgD9xJ9yXYG6fXgk5YOBcXLl5qwvXA5c5T5M=.339e7c61-705c-4e34-b6f9-f6783c1e3eb8@github.com>
References: <wWrn0MNNgD9xJ9yXYG6fXgk5YOBcXLl5qwvXA5c5T5M=.339e7c61-705c-4e34-b6f9-f6783c1e3eb8@github.com>
Message-ID: <yjNni8paFmph2vGnTkzModIfw4NKS8T0xOlwEIzZYu4=.aec841a8-f0cb-4616-b367-589bd2cadaab@github.com>

On Wed, 9 Apr 2025 23:17:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Release notes for JavaFX 24.0.1.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=47358
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=47357
> 
> As usual, I excluded test bugs, cleanup bugs, etc.
> 
> NOTE: Once the CPU release ships on 2025-04-15, I will add any security bugs and ask for a re-review.

Reviewers: @arapte or @andy-goryachev-oracle

@tiainen or @abhinayagarwal : can one of you take a look as well?

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

PR Comment: https://git.openjdk.org/jfx24u/pull/19#issuecomment-2794117318

From angorya at openjdk.org  Thu Apr 10 15:08:42 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 10 Apr 2025 15:08:42 GMT
Subject: [jfx24u] RFR: 8354182: Create release notes for JavaFX 24.0.1
In-Reply-To: <wWrn0MNNgD9xJ9yXYG6fXgk5YOBcXLl5qwvXA5c5T5M=.339e7c61-705c-4e34-b6f9-f6783c1e3eb8@github.com>
References: <wWrn0MNNgD9xJ9yXYG6fXgk5YOBcXLl5qwvXA5c5T5M=.339e7c61-705c-4e34-b6f9-f6783c1e3eb8@github.com>
Message-ID: <sryymZhp9EJGrarz5fnlfXLl5qcWCDjVMPLeNjCOvj4=.835df25b-a55a-4ab8-8521-c18736c9f1c6@github.com>

On Wed, 9 Apr 2025 23:17:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Release notes for JavaFX 24.0.1.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=47358
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=47357
> 
> As usual, I excluded test bugs, cleanup bugs, etc.
> 
> NOTE: Once the CPU release ships on 2025-04-15, I will add any security bugs and ask for a re-review.

lgtm

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx24u/pull/19#pullrequestreview-2757214142

From angorya at openjdk.org  Thu Apr 10 16:09:33 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 10 Apr 2025 16:09:33 GMT
Subject: RFR: 8345348: CSS media feature queries [v9]
In-Reply-To: <BkSEwG0FIOy_zTs3zg5307r-WxntmiZ81PH27hvQeMo=.71a6d7a7-fe7f-4255-8800-5c3c65c2061d@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <BkSEwG0FIOy_zTs3zg5307r-WxntmiZ81PH27hvQeMo=.71a6d7a7-fe7f-4255-8800-5c3c65c2061d@github.com>
Message-ID: <5BQS31A32z-KgAgMNDC5O4EgLjiJ7b4eoznPbJO45ds=.155fdc05-0097-49d4-8edd-bffe7da631eb@github.com>

On Thu, 10 Apr 2025 10:05:37 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add more tests

In the .md document, you make a reference to w3.org media queries, so one question comes right away: do you eventually plan to implement the whole spec as defined there, or we are really talking about a very small subset of features?

For example, do you plan to support media query operations like `and`, `not`, `only`, etc.?  Also, the w3.org spec might be way too complicated even to be referenced - things there will never apply to JavaFX (`tty`, `projection`, `speech`, etc.)

Alternatively, wouldn't it make _more_ sense to add variables to the JavaFX CSS instead?  Or maybe in conjunction with a simpler media-query-like syntax, something like @if(scene.isDark)?

My concern is that the media query features (whatever subset of it we decide to implement) might make the code way too complex without providing substantial benefit, and perhaps we can achieve the same goal (of dynamically activating parts of the stylesheet) using simpler solutions like variables?

What do you think?

Also, would it be possible to add Goals and Non-Goals to the .md, make it more JEP-like?

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

PR Comment: https://git.openjdk.org/jfx/pull/1655#issuecomment-2794373071
PR Comment: https://git.openjdk.org/jfx/pull/1655#issuecomment-2794376884

From andy.goryachev at oracle.com  Thu Apr 10 16:16:55 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 10 Apr 2025 16:16:55 +0000
Subject: Stage Maximized/Iconified at the same time
In-Reply-To: <CAAP_wukXrDDQSvHEtym6awK0jGmgx5dUqP1Vvf+z5txs7VXfcw@mail.gmail.com>
References: <CAAP_wukXrDDQSvHEtym6awK0jGmgx5dUqP1Vvf+z5txs7VXfcw@mail.gmail.com>
Message-ID: <BYAPR10MB3013A320F26FB1F8E0FEAF36E5B72@BYAPR10MB3013.namprd10.prod.outlook.com>

good catch!

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Thiago Milczarek Say?o <thiago.sayao at gmail.com>
Date: Thursday, April 10, 2025 at 05:17
To: openjfx-dev <openjfx-dev at openjdk.org>
Subject: Stage Maximized/Iconified at the same time
Hi,

I don't have a Mac to test, but on Linux and Windows, a window can be both maximized and iconified at the same time. It retains the maximized state when restored from being iconified.

I've mentioned this topic before, but it's now clear to me that there's a bug in JavaFX related to this behavior.

from glass ui\Window.java:

final static public class State {
    @Native public static final int NORMAL = 1;
    @Native public static final int MINIMIZED = 2;
    @Native public static final int MAXIMIZED = 3;
}

from quantum GlassWindowEventHandler.java


case WindowEvent.RESTORE:
    stage.stageListener.changedIconified(false);
    stage.stageListener.changedMaximized(false);
    break;

TestStage.java for testing this:
https://gist.github.com/tsayao/5efca2e6f0f661595b31da37e2e7df26

I probably can submit a fix.

-- Thiago.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250410/6bf6bf14/attachment.htm>

From kcr at openjdk.org  Thu Apr 10 16:17:14 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Apr 2025 16:17:14 GMT
Subject: RFR: 8353632: [Linux] Undefined reference to
 PlatformSupport::OBSERVED_SETTINGS with C++14
Message-ID: <jlakUm_s21y5is_ZN9-_GvxoISGGP06H4i4Z-H6VdJo=.faa839da-4d16-4cdc-9024-1333bb504cdd@github.com>

Fixes a link error that occurs when using C++14 to compile and link JavaFX on Linux.


in function `PlatformSupport::PlatformSupport(JNIEnv_*, _jobject*)':
PlatformSupport.cpp:90: undefined reference to `PlatformSupport::OBSERVED_SETTINGS'


The solution, proposed by @johanvos, is to define `PlatformSupport::OBSERVED_SETTINGS` in `PlatformSupport.cpp`.

I have tested this using gcc 13.2 and 14.2 using C++17 and it builds and runs as expected. Johan has already tested a variant of this on C++14, but I will wait for his explicit review.

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

Commit messages:
 - 8353632: [Linux] Undefined reference to PlatformSupport::OBSERVED_SETTINGS with C++14

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

PR: https://git.openjdk.org/jfx/pull/1768

From kcr at openjdk.org  Thu Apr 10 16:17:14 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Apr 2025 16:17:14 GMT
Subject: RFR: 8353632: [Linux] Undefined reference to
 PlatformSupport::OBSERVED_SETTINGS with C++14
In-Reply-To: <jlakUm_s21y5is_ZN9-_GvxoISGGP06H4i4Z-H6VdJo=.faa839da-4d16-4cdc-9024-1333bb504cdd@github.com>
References: <jlakUm_s21y5is_ZN9-_GvxoISGGP06H4i4Z-H6VdJo=.faa839da-4d16-4cdc-9024-1333bb504cdd@github.com>
Message-ID: <g0V8poBgwQzZvsHytvHGPu2FIHvh4XiOmiFTpZzDFIU=.58913e31-fecc-4375-961d-76c7f0084572@github.com>

On Thu, 10 Apr 2025 16:11:07 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Fixes a link error that occurs when using C++14 to compile and link JavaFX on Linux.
> 
> 
> in function `PlatformSupport::PlatformSupport(JNIEnv_*, _jobject*)':
> PlatformSupport.cpp:90: undefined reference to `PlatformSupport::OBSERVED_SETTINGS'
> 
> 
> The solution, proposed by @johanvos, is to define `PlatformSupport::OBSERVED_SETTINGS` in `PlatformSupport.cpp`.
> 
> I have tested this using gcc 13.2 and 14.2 using C++17 and it builds and runs as expected. Johan has already tested a variant of this on C++14, but I will wait for his explicit review.

Reviewers: @mstr2 @johanvos

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

PR Comment: https://git.openjdk.org/jfx/pull/1768#issuecomment-2794394590

From mstrauss at openjdk.org  Thu Apr 10 16:47:45 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 10 Apr 2025 16:47:45 GMT
Subject: RFR: 8345348: CSS media feature queries [v9]
In-Reply-To: <5BQS31A32z-KgAgMNDC5O4EgLjiJ7b4eoznPbJO45ds=.155fdc05-0097-49d4-8edd-bffe7da631eb@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <BkSEwG0FIOy_zTs3zg5307r-WxntmiZ81PH27hvQeMo=.71a6d7a7-fe7f-4255-8800-5c3c65c2061d@github.com>
 <5BQS31A32z-KgAgMNDC5O4EgLjiJ7b4eoznPbJO45ds=.155fdc05-0097-49d4-8edd-bffe7da631eb@github.com>
Message-ID: <vfDAhTVfIXS1tLXyrZwK-1h03II4dsP4b8wZph6qFIc=.e468478f-9db3-4147-9934-2c3743cd1674@github.com>

On Thu, 10 Apr 2025 16:05:53 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> In the .md document, you make a reference to w3.org media queries, so one question comes right away: do you eventually plan to implement the whole spec as defined there, or we are really talking about a very small subset of features?

We'd probably never implement the whole spec, but only the parts that make sense for JavaFX. Starting with user-preference media features is an obvious choice, because we already have a matching set of platform preferences (the astute reader might notice just how closely the existing platform preferences, the proposed media queries, and the W3C standard align -- almost as if by design ?).

> For example, do you plan to support media query operations like `and`, `not`, `only`, etc.? Also, the w3.org spec might be way too complicated even to be referenced - things there will never apply to JavaFX (`tty`, `projection`, `speech`, etc.)

The `only` keyword makes no sense here, it's a legacy keyword for the web. Other than that, this PR already implements the full syntax for media feature queries, including `and`, `or`, and `not` (except for the _range form_, which we only need to support if we decide to also support viewport characteristics features like `width`).

I reference the W3C specification because like with all recently added CSS features, this is an implementation of the standard. The JavaFX CSS reference documents the extent to which the standard is implemented.

> Alternatively, wouldn't it make _more_ sense to add variables to the JavaFX CSS instead? Or maybe in conjunction with a simpler media-query-like syntax, something like @if(scene.isDark)?

CSS variables can't be implemented without a [major rewrite of the CSS system](https://gist.github.com/mstr2/f416996caf48e11193f0b6a5883a3926). We can do this, but it is not really related to the feature proposed here. Even with CSS variables, you need a way to toggle their value based on external configuration, and then you're right back at the start of the problem.

I am very much against inventing _any_ non-standard CSS syntax whatsoever. Every time JavaFX did that, the result was not good. Let's face the reality here: the JavaFX CSS implementation is severely undercooked, and that's the very best thing I can say about it. I don't want to make it any worse.

> My concern is that the media query features (whatever subset of it we decide to implement) might make the code way too complex without providing substantial benefit, and perhaps we can achieve the same goal (of dynamically activating parts of the stylesheet) using simpler solutions like variables?

You seem to be arguing against media queries themselves, not against their implementation in JavaFX. But they are a thing in the technology that 99,9% of developers know as CSS, it's a brute fact of nature. I think we should acknowledge that, and not try to do our own little thing again.

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

PR Comment: https://git.openjdk.org/jfx/pull/1655#issuecomment-2794497352

From tsayao at openjdk.org  Thu Apr 10 16:51:39 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 10 Apr 2025 16:51:39 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
Message-ID: <pZgjiDolUbSjn7lGqXNvLSE9Jc1lE9uLuu2W7Ph0KNg=.a7c5a7e4-6a60-40d8-831f-81af9158a58c@github.com>

On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Adds code to trigger a scene update when a Window is restored
> 
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479

About the comment on the change:

After some experiments, I?d say the size can change because you can call `setFullScreen(true)` or `setMaximized(true)` and then deiconify. While this doesn?t directly set the width and height of the Scene, the actual scene size does change. 

Anyways, this is just a comment for a case to consider, but the change does make the scene repaint in this case.

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

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2794509723

From martinfox656 at gmail.com  Thu Apr 10 17:01:46 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Thu, 10 Apr 2025 10:01:46 -0700
Subject: Stage Maximized/Iconified at the same time
In-Reply-To: <CAAP_wukXrDDQSvHEtym6awK0jGmgx5dUqP1Vvf+z5txs7VXfcw@mail.gmail.com>
References: <CAAP_wukXrDDQSvHEtym6awK0jGmgx5dUqP1Vvf+z5txs7VXfcw@mail.gmail.com>
Message-ID: <435F895D-B9B2-4734-9715-438A6F75D8AC@gmail.com>

The maximized state on Mac is murkier than it is on Windows and Linux but, yes, a window can be both iconified and maximized at the same time.

The code you referenced looks correct. If you de-iconify a maximized window the WindowEvent should be MAXIMIZE, not RESTORE.

What steps are you taking with your test app that?s creating buggy behavior? The only obvious problem I saw on Linux is that if you toggle the maximized state of an iconified window the iconified property can get cleared. This doesn?t happen on Mac.

> On Apr 10, 2025, at 5:17?AM, Thiago Milczarek Say?o <thiago.sayao at gmail.com> wrote:
> 
> Hi,
> 
> I don't have a Mac to test, but on Linux and Windows, a window can be both maximized and iconified at the same time. It retains the maximized state when restored from being iconified.
> 
> I've mentioned this topic before, but it's now clear to me that there's a bug in JavaFX related to this behavior.
> 
> from glass ui\Window.java:
> final static public class State {
>     @Native public static final int NORMAL = 1;
>     @Native public static final int MINIMIZED = 2;
>     @Native public static final int MAXIMIZED = 3;
> }
> 
> from quantum GlassWindowEventHandler.java
> 
> case WindowEvent.RESTORE:
>     stage.stageListener.changedIconified(false);
>     stage.stageListener.changedMaximized(false);
>     break;
> 
> TestStage.java for testing this:
> https://gist.github.com/tsayao/5efca2e6f0f661595b31da37e2e7df26
> 
> I probably can submit a fix.
> 
> -- Thiago.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250410/7373c36a/attachment-0001.htm>

From mstrauss at openjdk.org  Thu Apr 10 17:03:46 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 10 Apr 2025 17:03:46 GMT
Subject: RFR: 8345348: CSS media feature queries [v9]
In-Reply-To: <5BQS31A32z-KgAgMNDC5O4EgLjiJ7b4eoznPbJO45ds=.155fdc05-0097-49d4-8edd-bffe7da631eb@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <BkSEwG0FIOy_zTs3zg5307r-WxntmiZ81PH27hvQeMo=.71a6d7a7-fe7f-4255-8800-5c3c65c2061d@github.com>
 <5BQS31A32z-KgAgMNDC5O4EgLjiJ7b4eoznPbJO45ds=.155fdc05-0097-49d4-8edd-bffe7da631eb@github.com>
Message-ID: <xsK6dNcVamhFDhum9qx_VdrKM483BDMvZ0F7ArpTvjU=.0dda293f-fc42-4313-a130-151435514d08@github.com>

On Thu, 10 Apr 2025 16:07:05 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Also, would it be possible to add Goals and Non-Goals to the .md, make it more JEP-like?

I added the two sections.

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

PR Comment: https://git.openjdk.org/jfx/pull/1655#issuecomment-2794556758

From thiago.sayao at gmail.com  Thu Apr 10 19:04:06 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Thu, 10 Apr 2025 16:04:06 -0300
Subject: Stage Maximized/Iconified at the same time
In-Reply-To: <435F895D-B9B2-4734-9715-438A6F75D8AC@gmail.com>
References: <CAAP_wukXrDDQSvHEtym6awK0jGmgx5dUqP1Vvf+z5txs7VXfcw@mail.gmail.com>
 <435F895D-B9B2-4734-9715-438A6F75D8AC@gmail.com>
Message-ID: <CAAP_wu=NVDMYdV9SheL-u4r_1ozdWh3oB+8rYavfWzEuo=ydeQ@mail.gmail.com>

Hi Martin,

I?ve started a broader effort to fix some open Linux bugs related to
XWayland and Xorg here:

https://github.com/openjdk/jfx-sandbox/compare/master...glass_gtk_bug_squashing

It's a work in progress?I'm planning to roll back some changes to narrow
the modifications and submit some of it separately.

I noticed on the docs on the Stage the following statement:

In case that more Stage modes are set simultaneously their order of
> importance is iconified, fullScreen, maximized (from strongest to weakest).


So I proceeded to try to honor it with the test:

gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests
StageAttributesTest.testAttributesPrecedence

It now passes, but not without changes on the glass Java side (on the same
branch).

-- Thiago


Em qui., 10 de abr. de 2025 ?s 14:01, Martin Fox <martinfox656 at gmail.com>
escreveu:

> The maximized state on Mac is murkier than it is on Windows and Linux but,
> yes, a window can be both iconified and maximized at the same time.
>
> The code you referenced looks correct. If you de-iconify a maximized
> window the WindowEvent should be MAXIMIZE, not RESTORE.
>
> What steps are you taking with your test app that?s creating buggy
> behavior? The only obvious problem I saw on Linux is that if you toggle the
> maximized state of an iconified window the iconified property can get
> cleared. This doesn?t happen on Mac.
>
> On Apr 10, 2025, at 5:17?AM, Thiago Milczarek Say?o <
> thiago.sayao at gmail.com> wrote:
>
> Hi,
>
> I don't have a Mac to test, but on Linux and Windows, a window can be both
> maximized and iconified at the same time. It retains the maximized state
> when restored from being iconified.
>
> I've mentioned this topic before, but it's now clear to me that there's a
> bug in JavaFX related to this behavior.
>
> from glass ui\Window.java:
>
> final static public class State {
>     @Native public static final int NORMAL = 1;
>     @Native public static final int MINIMIZED = 2;
>     @Native public static final int MAXIMIZED = 3;
> }
>
>
> from quantum GlassWindowEventHandler.java
>
> case WindowEvent.RESTORE:
>     stage.stageListener.changedIconified(false);
>     stage.stageListener.changedMaximized(false);
>     break;
>
>
> TestStage.java for testing this:
> https://gist.github.com/tsayao/5efca2e6f0f661595b31da37e2e7df26
>
> I probably can submit a fix.
>
> -- Thiago.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250410/5d1c7d22/attachment.htm>

From mstrauss at openjdk.org  Thu Apr 10 19:12:43 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 10 Apr 2025 19:12:43 GMT
Subject: RFR: 8353632: [Linux] Undefined reference to
 PlatformSupport::OBSERVED_SETTINGS with C++14
In-Reply-To: <jlakUm_s21y5is_ZN9-_GvxoISGGP06H4i4Z-H6VdJo=.faa839da-4d16-4cdc-9024-1333bb504cdd@github.com>
References: <jlakUm_s21y5is_ZN9-_GvxoISGGP06H4i4Z-H6VdJo=.faa839da-4d16-4cdc-9024-1333bb504cdd@github.com>
Message-ID: <hfK7JYGNmE5c3eGYLgVKhv720sTc0Sul0UPW2VlDgTE=.de69a508-2bbf-4d2f-8a56-29f92f489cca@github.com>

On Thu, 10 Apr 2025 16:11:07 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Fixes a link error that occurs when using C++14 to compile and link JavaFX on Linux.
> 
> 
> in function `PlatformSupport::PlatformSupport(JNIEnv_*, _jobject*)':
> PlatformSupport.cpp:90: undefined reference to `PlatformSupport::OBSERVED_SETTINGS'
> 
> 
> The solution, proposed by @johanvos, is to define `PlatformSupport::OBSERVED_SETTINGS` in `PlatformSupport.cpp`.
> 
> I have tested this using gcc 13.2 and 14.2 using C++17 and it builds and runs as expected. Johan has already tested a variant of this on C++14, but I will wait for his explicit review.

LGTM

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

Marked as reviewed by mstrauss (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1768#pullrequestreview-2758062612

From mstrauss at openjdk.org  Thu Apr 10 19:14:49 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 10 Apr 2025 19:14:49 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea [v4]
In-Reply-To: <CDdPLwm_Td3FWl9Ox4kfJCxRgEwpAYX6k1iIhxc9WIA=.3619b09e-11af-43a6-8ef9-ac7e3f7fbff6@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <CDdPLwm_Td3FWl9Ox4kfJCxRgEwpAYX6k1iIhxc9WIA=.3619b09e-11af-43a6-8ef9-ac7e3f7fbff6@github.com>
Message-ID: <No2xLLiZzzrj45qhqxp0yed7y2QO7cbwtR8ZKLegqBM=.2201a867-8db7-478e-b7fe-6309b3f13e8d@github.com>

On Tue, 25 Mar 2025 22:53:55 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Added multi line prompt support for TextArea this will provide the ability to have multiple lines in textArea as expected,
>> Also fixed tests to meet the new changes
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused imports and code

Marked as reviewed by mstrauss (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1716#pullrequestreview-2758066317

From kcr at openjdk.org  Thu Apr 10 19:50:41 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Apr 2025 19:50:41 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea [v4]
In-Reply-To: <32JKwF5zQO4kFvBOOiLT7xIXT0wgZf6JhJhXuda0eYk=.8cf773fd-7440-49a1-aaee-4c0989806e08@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <CDdPLwm_Td3FWl9Ox4kfJCxRgEwpAYX6k1iIhxc9WIA=.3619b09e-11af-43a6-8ef9-ac7e3f7fbff6@github.com>
 <SACqj1maKQK7VJ7unHRqW8QEiI4QGcCJHowaUd9yTjI=.678843c9-de45-4979-83c6-d8d9b1d9f730@github.com>
 <4h1LiyfDsTi7u06VZO6_ffy4JYDZr7CW9UWkcejFDAg=.7fc889b6-e5da-4a67-9951-f1d1f4afcbbd@github.com>
 <Cejw4zeZ9GDa5ZckxI_y04ggrR3rUUPavsiLnFCkZXA=.b77514dc-c05f-4fcd-99bc-cb2d40c566df@github.com>
 <BcblWjS2LAWIXb1WwNnzLAub8jMNw3QZvkoaWMy4TVE=.772edd50-ef1e-4511-95a9-f1f0e515b284@github.com>
 <YHzb5PGESIjFXzL0GHov66Oi_itr7COBnJ2uE2X1tJU=.5acf7694-8e7d-48d2-b53a-7641d139a63a@github.com>
 <32JKwF5zQO4kFvBOOiLT7xIXT0wgZf6JhJhXuda0eYk=.8cf773fd-7440-49a1-aaee-4c0989806e08@github.com>
Message-ID: <MGe7-ke-kHc4dgpLO3mFAWSWWfL1TLe9pDipHSbjpEU=.3feb61ff-21ca-4632-a289-9b4f235f7530@github.com>

On Mon, 7 Apr 2025 15:14:52 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> One thing I am curious about: I don't see a similar stripping of newlines in the text itself for TextField, and yet it does render the whole string as if the newline had been stripped. Do you know why we need to strip it from promptTextProperty explicitly and not from textProperty?
>
> @kevinrushforth 
> This is due to `TextFieldContent::insert` we have a filterInput and the second parameter to strip newlines is set to true in the textField class.
> `filterInput(String txt, boolean stripNewlines, boolean stripTabs)`
> For `TextAreaContent::insert` the parameter is set to false to allow newlines.

Thanks for the explanation. I have no further comments or questions, so feel free to integrate when ready.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1716#discussion_r2038207513

From angorya at openjdk.org  Thu Apr 10 21:35:52 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 10 Apr 2025 21:35:52 GMT
Subject: RFR: 8088343: Intermittent unit test failure in
 javafx.concurrent.ServiceLifecycleTest
Message-ID: <KGLNqPgypdjKohTRf6B0CvSAr-qI-w8vz_qia1fIqaw=.14734aa2-260e-449e-8a19-c196a17af657@github.com>

The code should not set the `Task.state` value to `CANCELLED` if the said task is already `SUCCEEDED` or `FAILED`.

This is a product bug.

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

Commit messages:
 - 8088343

Changes: https://git.openjdk.org/jfx/pull/1769/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1769&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8088343
  Stats: 61 lines in 2 files changed: 37 ins; 14 del; 10 mod
  Patch: https://git.openjdk.org/jfx/pull/1769.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1769/head:pull/1769

PR: https://git.openjdk.org/jfx/pull/1769

From kcr at openjdk.org  Thu Apr 10 22:05:10 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Apr 2025 22:05:10 GMT
Subject: RFR: 8354337: GHA: Windows build fails with chmod permission error
Message-ID: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>

After a recent update by GitHub to the GHA Windows Server 2022 runner, we get the following error in all GHA test runs:


chmod: changing permissions of '.': Permission denied
chmod: changing permissions of './bin': Permission denied 
...


This PR disables running `chmod -R` on the `artifacts/sdk` dir when doing a GHA build.

The `chmod` is only needed when building artifacts for distribution, and we only use the GHA build for sanity testing, so we can avoid this problem by adding a flag that skips the `chmod` if running on GHA. This is a minimally intrusive solution that would restore our ability to run GHA test builds on Windows without affecting the actual JavaFX build.

I've run a CI build as well as a local build to ensure that the chmod is still being executed.

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

Commit messages:
 - 8354337: GHA: Windows build fails with chmod permission error

Changes: https://git.openjdk.org/jfx/pull/1770/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1770&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354337
  Stats: 14 lines in 2 files changed: 10 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1770.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1770/head:pull/1770

PR: https://git.openjdk.org/jfx/pull/1770

From kcr at openjdk.org  Thu Apr 10 22:15:31 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Apr 2025 22:15:31 GMT
Subject: RFR: 8354337: GHA: Windows build fails with chmod permission error
In-Reply-To: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
References: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
Message-ID: <jCoQ18aRBnxZKGOzd8OPyC5n6j0sdciFiucyLialreI=.d8f13261-3555-46f9-acfc-cbbc04c97b72@github.com>

On Thu, 10 Apr 2025 22:00:35 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> After a recent update by GitHub to the GHA Windows Server 2022 runner, we get the following error in all GHA test runs:
> 
> 
> chmod: changing permissions of '.': Permission denied
> chmod: changing permissions of './bin': Permission denied 
> ...
> 
> 
> This PR disables running `chmod -R` on the `artifacts/sdk` dir when doing a GHA build.
> 
> The `chmod` is only needed when building artifacts for distribution, and we only use the GHA build for sanity testing, so we can avoid this problem by adding a flag that skips the `chmod` if running on GHA. This is a minimally intrusive solution that would restore our ability to run GHA test builds on Windows without affecting the actual JavaFX build.
> 
> I've run a CI build as well as a local build to ensure that the chmod is still being executed.

A simple changes, but I wouldn't mind a second pair of eyes.

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

PR Comment: https://git.openjdk.org/jfx/pull/1770#issuecomment-2795279344

From kcr at openjdk.org  Thu Apr 10 22:18:31 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Apr 2025 22:18:31 GMT
Subject: RFR: 8088343: Intermittent unit test failure in
 javafx.concurrent.ServiceLifecycleTest
In-Reply-To: <KGLNqPgypdjKohTRf6B0CvSAr-qI-w8vz_qia1fIqaw=.14734aa2-260e-449e-8a19-c196a17af657@github.com>
References: <KGLNqPgypdjKohTRf6B0CvSAr-qI-w8vz_qia1fIqaw=.14734aa2-260e-449e-8a19-c196a17af657@github.com>
Message-ID: <anznUp7bTDGa5bY-yDQEV92RS8PTKQ2K0Tvh9pxwYqk=.f75eb420-a509-4ea1-bd37-73a767735ec7@github.com>

On Thu, 10 Apr 2025 21:22:21 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> The code should not set the `Task.state` value to `CANCELLED` if the said task is already `SUCCEEDED` or `FAILED`.
> 
> This is a product bug.

Reviewers: @kevinrushforth @arapte

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

PR Comment: https://git.openjdk.org/jfx/pull/1769#issuecomment-2795283488

From angorya at openjdk.org  Thu Apr 10 22:23:30 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 10 Apr 2025 22:23:30 GMT
Subject: RFR: 8354337: GHA: Windows build fails with chmod permission error
In-Reply-To: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
References: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
Message-ID: <r_oN6uFvEn7YOKlkirSouS5QRzjoYKQ1_dZH7nvmUKc=.a6c896ea-2ec2-4a05-9e96-a8ddb001fe89@github.com>

On Thu, 10 Apr 2025 22:00:35 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> After a recent update by GitHub to the GHA Windows Server 2022 runner, we get the following error in all GHA test runs:
> 
> 
> chmod: changing permissions of '.': Permission denied
> chmod: changing permissions of './bin': Permission denied 
> ...
> 
> 
> This PR disables running `chmod -R` on the `artifacts/sdk` dir when doing a GHA build.
> 
> The `chmod` is only needed when building artifacts for distribution, and we only use the GHA build for sanity testing, so we can avoid this problem by adding a flag that skips the `chmod` if running on GHA. This is a minimally intrusive solution that would restore our ability to run GHA test builds on Windows without affecting the actual JavaFX build.
> 
> I've run a CI build as well as a local build to ensure that the chmod is still being executed.

Should we limit the skipping to Windows only?

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

PR Comment: https://git.openjdk.org/jfx/pull/1770#issuecomment-2795292516

From angorya at openjdk.org  Thu Apr 10 22:29:30 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 10 Apr 2025 22:29:30 GMT
Subject: RFR: 8354337: GHA: Windows build fails with chmod permission error
In-Reply-To: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
References: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
Message-ID: <yLUIBozTjYEPG2eHDljPK4v4AxsbCmwsjcrlBUZS1vQ=.93b5f51c-31b1-4d01-820b-3c4870f5ccb0@github.com>

On Thu, 10 Apr 2025 22:00:35 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> After a recent update by GitHub to the GHA Windows Server 2022 runner, we get the following error in all GHA test runs:
> 
> 
> chmod: changing permissions of '.': Permission denied
> chmod: changing permissions of './bin': Permission denied 
> ...
> 
> 
> This PR disables running `chmod -R` on the `artifacts/sdk` dir when doing a GHA build.
> 
> The `chmod` is only needed when building artifacts for distribution, and we only use the GHA build for sanity testing, so we can avoid this problem by adding a flag that skips the `chmod` if running on GHA. This is a minimally intrusive solution that would restore our ability to run GHA test builds on Windows without affecting the actual JavaFX build.
> 
> I've run a CI build as well as a local build to ensure that the chmod is still being executed.

Marked as reviewed by angorya (Reviewer).

build.gradle line 606:

> 604: // Specifies whether to run "chmod -R artifacts/sdk" as the last step of
> 605: // copying the sdk to the artifacts dir. This is only done on Windows;
> 606: // the flag is ignored on other platforms.

a minor suggestion: mention JBS ticket for the context

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

PR Review: https://git.openjdk.org/jfx/pull/1770#pullrequestreview-2758599297
PR Review Comment: https://git.openjdk.org/jfx/pull/1770#discussion_r2038439952

From kcr at openjdk.org  Thu Apr 10 22:29:31 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Apr 2025 22:29:31 GMT
Subject: RFR: 8354337: GHA: Windows build fails with chmod permission error
In-Reply-To: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
References: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
Message-ID: <QAAgQ9wSGg3KpZXEkgcpxJbE4f9kGejzaYXZVnd4uLM=.1fbff50c-95f7-41fc-b391-38caa116eedb@github.com>

On Thu, 10 Apr 2025 22:00:35 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> After a recent update by GitHub to the GHA Windows Server 2022 runner, we get the following error in all GHA test runs:
> 
> 
> chmod: changing permissions of '.': Permission denied
> chmod: changing permissions of './bin': Permission denied 
> ...
> 
> 
> This PR disables running `chmod -R` on the `artifacts/sdk` dir when doing a GHA build.
> 
> The `chmod` is only needed when building artifacts for distribution, and we only use the GHA build for sanity testing, so we can avoid this problem by adding a flag that skips the `chmod` if running on GHA. This is a minimally intrusive solution that would restore our ability to run GHA test builds on Windows without affecting the actual JavaFX build.
> 
> I've run a CI build as well as a local build to ensure that the chmod is still being executed.

@arapte Can you also take a look?

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

PR Comment: https://git.openjdk.org/jfx/pull/1770#issuecomment-2795304378

From kcr at openjdk.org  Thu Apr 10 22:49:13 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Apr 2025 22:49:13 GMT
Subject: RFR: 8354318: freetype.c: compilation error: 'incompatible pointer
 type' with gcc 14
Message-ID: <u5HXreTEcOxM8sbR9D7H8dYSnNigsV3KAksqk1BArKg=.1152df5c-6678-4e2c-9058-b932513f5733@github.com>

This PR fixes a bug where a local variable was declared to be the wrong type, causing an error at compilation time when compiling with gcc 14. gcc 14 rejects assignments of incompatible pointer types without an explicit cast. In this case, the solution is declare the variable to be of the correct type in the first place.

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

Commit messages:
 - 8354318: freetype.c: compilation error: 'incompatible pointer type' with gcc 14

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

PR: https://git.openjdk.org/jfx/pull/1771

From kcr at openjdk.org  Thu Apr 10 22:49:13 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Apr 2025 22:49:13 GMT
Subject: RFR: 8354318: freetype.c: compilation error: 'incompatible pointer
 type' with gcc 14
In-Reply-To: <u5HXreTEcOxM8sbR9D7H8dYSnNigsV3KAksqk1BArKg=.1152df5c-6678-4e2c-9058-b932513f5733@github.com>
References: <u5HXreTEcOxM8sbR9D7H8dYSnNigsV3KAksqk1BArKg=.1152df5c-6678-4e2c-9058-b932513f5733@github.com>
Message-ID: <g_hVC2ijMAPcgsRWmNAMYVoK0b4ev3sRSyWDv8DzG5I=.fbbaea33-2b76-45e3-872c-c00095837954@github.com>

On Thu, 10 Apr 2025 22:41:02 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR fixes a bug where a local variable was declared to be the wrong type, causing an error at compilation time when compiling with gcc 14. gcc 14 rejects assignments of incompatible pointer types without an explicit cast. In this case, the solution is declare the variable to be of the correct type in the first place.

Reviewer: @lukostyra

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

PR Comment: https://git.openjdk.org/jfx/pull/1771#issuecomment-2795332140

From lkostyra at openjdk.org  Fri Apr 11 06:55:37 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 11 Apr 2025 06:55:37 GMT
Subject: RFR: 8354318: freetype.c: compilation error: 'incompatible pointer
 type' with gcc 14
In-Reply-To: <u5HXreTEcOxM8sbR9D7H8dYSnNigsV3KAksqk1BArKg=.1152df5c-6678-4e2c-9058-b932513f5733@github.com>
References: <u5HXreTEcOxM8sbR9D7H8dYSnNigsV3KAksqk1BArKg=.1152df5c-6678-4e2c-9058-b932513f5733@github.com>
Message-ID: <UH9tVtiBs0-vtMauIJ3iYcRwmFQzZyxYgTrT8yPbjR8=.872ac06f-f489-4998-97a7-f6049d9c10b7@github.com>

On Thu, 10 Apr 2025 22:41:02 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR fixes a bug where a local variable was declared to be the wrong type, causing an error at compilation time when compiling with gcc 14. gcc 14 rejects assignments of incompatible pointer types without an explicit cast. In this case, the solution is declare the variable to be of the correct type in the first place.

LGTM

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

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1771#pullrequestreview-2759326136

From mstrauss at openjdk.org  Fri Apr 11 08:23:45 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 11 Apr 2025 08:23:45 GMT
Subject: RFR: 8277000: Tree-/TableRowSkin: replace listener to
 fixedCellSize by live lookup [v5]
In-Reply-To: <qfbP0wEAsYQEhq-VVRCX6IcI6ZV-VLd3pSFf9bxy8Oo=.512d7a92-b8da-4a8b-a746-b62010291dd7@github.com>
References: <C9DCt4HLNulh3bxF1ZnIbd1WxtJcxnslOcdkY_srAhg=.3c3ae808-45a2-4e0c-a55c-44fa1fdf1305@github.com>
 <qfbP0wEAsYQEhq-VVRCX6IcI6ZV-VLd3pSFf9bxy8Oo=.512d7a92-b8da-4a8b-a746-b62010291dd7@github.com>
Message-ID: <M_dEsH8mtwygWYQvp0kCJjrf8_MzbyWs6YwVLnyMke0=.d31ddff0-f146-4011-b2dc-cdf1df625bc6@github.com>

On Mon, 17 Feb 2025 22:56:56 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR improves the `Tree-/TableRowSkin` code by doing a normal live lookup for the `fixedCellSize` instead of adding listener just to update variables(`fixedCellSizeEnabled` and `fixedCellSize`) which can otherwise be also just lookup'd without the hassle of listeners.
>> 
>> While this is mostly a cleanup, it does improve the state of the `Tree-/TableRow`, as when the `TableRowSkinBase` constructor is called, the variables are not yet set.
>> 
>> It is also consistent with the other cells, see also [JDK-8246745](https://bugs.openjdk.org/browse/JDK-8246745).
>> Helps a bit with [JDK-8185887](https://bugs.openjdk.org/browse/JDK-8185887) (https://github.com/openjdk/jfx/pull/1644), but as written above, not required as there is no (visible) effect.
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add as javadoc

Looks good and works as expected.

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

Marked as reviewed by mstrauss (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1645#pullrequestreview-2759535992

From mstrauss at openjdk.org  Fri Apr 11 08:31:38 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 11 Apr 2025 08:31:38 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v25]
In-Reply-To: <FSGxqaTjt6T7_N3uDzucGJWZjl2lBLI7FM5oSqxEXj0=.56de0fc6-9dce-4944-9fae-cc29f8cd674f@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <FSGxqaTjt6T7_N3uDzucGJWZjl2lBLI7FM5oSqxEXj0=.56de0fc6-9dce-4944-9fae-cc29f8cd674f@github.com>
Message-ID: <vhqd2EYA5HkHqVOAIEHz2d-0fwfq8Q8Ra18mTSL-awc=.30ff17ab-94eb-4c1f-9991-78e88c340699@github.com>

On Mon, 7 Apr 2025 19:37:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Please refer to
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
>> 
>> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
>> 
>> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
>> 
>> 
>>     /**
>>      * Obtains the snapshot of the current text layout information.
>>      * @return the layout information
>>      * @since 25
>>      */
>>     public final LayoutInfo getLayoutInfo()
>> 
>> 
>> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
>> 
>> - caret information
>> - text lines: offsets and bounds
>> - overall layout bounds
>> - text selection geometry
>> - strike-through geometry
>> - underline geometry
>> 
>> 
>> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
>> 
>> 
>>     /**
>>      * Returns the shape for the strike-through in local coordinates.
>>      *
>>      * @param start the beginning character index for the range
>>      * @param end the end character index (non-inclusive) for the range
>>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>>      * @since 25
>>      */
>>     public final PathElement[] strikeThroughShape(int start, int end)
>> 
>> 
>> 
>> 
>> ## WARNING
>> 
>> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
>> 
>> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
>> 
>> 
>> 
>> ## Testing
>> 
>> The new APIs can be visually tested using the Monkey Tester on this branch:
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
>> 
>> in the Text and TextFlow pages:
>> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
>> 
>> Two very basic headful tests have been added.
>> 
>> 
>> ## See Also
>> 
>> https://github.com/FXMisc/RichTextFX/pull/1246
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   sealed

Looks good. I've left one minor comment.

modules/javafx.graphics/src/main/java/javafx/scene/text/TextLineInfo.java line 36:

> 34:  * @param bounds the bounds of the text line, in local coordinates:
> 35:  * <ul>
> 36:  *   <li>

We usually indent with 4 spaces.

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

Marked as reviewed by mstrauss (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1596#pullrequestreview-2759559341
PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2039065579

From duke at openjdk.org  Fri Apr 11 09:49:14 2025
From: duke at openjdk.org (Gopal Pattnaik)
Date: Fri, 11 Apr 2025 09:49:14 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system is
 busy
Message-ID: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>

There was a Assertion fail issue in mouse location test case JDK-8296554,
Reason: We felt the one mili second delay time for the Robot test may be insufficient in few OS.
Solution: We Changed the delay time to three mili second.

Verification:
Tested in Windows 11, and the Assert fail issue is not found.

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

Commit messages:
 - Fix for MouseLocationOnScreenTest Assertion Fail

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

PR: https://git.openjdk.org/jfx/pull/1772

From arapte at openjdk.org  Fri Apr 11 09:54:41 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 11 Apr 2025 09:54:41 GMT
Subject: RFR: 8354337: GHA: Windows build fails with chmod permission error
In-Reply-To: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
References: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
Message-ID: <nMSe8Nv4uaCGsZ9B4ezIP_6-lHv6Y051jjjyOUL9ycw=.dd3c30b7-52df-4f00-b0fd-ac517d1c819f@github.com>

On Thu, 10 Apr 2025 22:00:35 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> After a recent update by GitHub to the GHA Windows Server 2022 runner, we get the following error in all GHA test runs:
> 
> 
> chmod: changing permissions of '.': Permission denied
> chmod: changing permissions of './bin': Permission denied 
> ...
> 
> 
> This PR disables running `chmod -R` on the `artifacts/sdk` dir when doing a GHA build.
> 
> The `chmod` is only needed when building artifacts for distribution, and we only use the GHA build for sanity testing, so we can avoid this problem by adding a flag that skips the `chmod` if running on GHA. This is a minimally intrusive solution that would restore our ability to run GHA test builds on Windows without affecting the actual JavaFX build.
> 
> I've run a CI build as well as a local build to ensure that the chmod is still being executed.

lgtm...

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1770#pullrequestreview-2759791974

From kcr at openjdk.org  Fri Apr 11 14:35:46 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Apr 2025 14:35:46 GMT
Subject: RFR: 8354337: GHA: Windows build fails with chmod permission error
 [v2]
In-Reply-To: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
References: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
Message-ID: <2jYthjjGjaewToPcJTfbLeAguQvqDjlcBgys9kH8dOk=.04685680-8687-456c-93a0-3756b8aaa323@github.com>

> After a recent update by GitHub to the GHA Windows Server 2022 runner, we get the following error in all GHA test runs:
> 
> 
> chmod: changing permissions of '.': Permission denied
> chmod: changing permissions of './bin': Permission denied 
> ...
> 
> 
> This PR disables running `chmod -R` on the `artifacts/sdk` dir when doing a GHA build.
> 
> The `chmod` is only needed when building artifacts for distribution, and we only use the GHA build for sanity testing, so we can avoid this problem by adding a flag that skips the `chmod` if running on GHA. This is a minimally intrusive solution that would restore our ability to run GHA test builds on Windows without affecting the actual JavaFX build.
> 
> I've run a CI build as well as a local build to ensure that the chmod is still being executed.

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1770/files
  - new: https://git.openjdk.org/jfx/pull/1770/files/3b724639..d277005c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1770&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1770&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1770.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1770/head:pull/1770

PR: https://git.openjdk.org/jfx/pull/1770

From angorya at openjdk.org  Fri Apr 11 14:35:46 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 11 Apr 2025 14:35:46 GMT
Subject: RFR: 8354337: GHA: Windows build fails with chmod permission error
 [v2]
In-Reply-To: <2jYthjjGjaewToPcJTfbLeAguQvqDjlcBgys9kH8dOk=.04685680-8687-456c-93a0-3756b8aaa323@github.com>
References: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
 <2jYthjjGjaewToPcJTfbLeAguQvqDjlcBgys9kH8dOk=.04685680-8687-456c-93a0-3756b8aaa323@github.com>
Message-ID: <-43zfy8TV4H6IEFknCMjfV9LUohrg4cTbykpsc62Y_s=.b9316926-e2cb-4b43-814c-986c2e2fa94b@github.com>

On Fri, 11 Apr 2025 14:33:26 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> After a recent update by GitHub to the GHA Windows Server 2022 runner, we get the following error in all GHA test runs:
>> 
>> 
>> chmod: changing permissions of '.': Permission denied
>> chmod: changing permissions of './bin': Permission denied 
>> ...
>> 
>> 
>> This PR disables running `chmod -R` on the `artifacts/sdk` dir when doing a GHA build.
>> 
>> The `chmod` is only needed when building artifacts for distribution, and we only use the GHA build for sanity testing, so we can avoid this problem by adding a flag that skips the `chmod` if running on GHA. This is a minimally intrusive solution that would restore our ability to run GHA test builds on Windows without affecting the actual JavaFX build.
>> 
>> I've run a CI build as well as a local build to ensure that the chmod is still being executed.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1770#pullrequestreview-2760552932

From kcr at openjdk.org  Fri Apr 11 14:35:46 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Apr 2025 14:35:46 GMT
Subject: RFR: 8354337: GHA: Windows build fails with chmod permission error
 [v2]
In-Reply-To: <yLUIBozTjYEPG2eHDljPK4v4AxsbCmwsjcrlBUZS1vQ=.93b5f51c-31b1-4d01-820b-3c4870f5ccb0@github.com>
References: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
 <yLUIBozTjYEPG2eHDljPK4v4AxsbCmwsjcrlBUZS1vQ=.93b5f51c-31b1-4d01-820b-3c4870f5ccb0@github.com>
Message-ID: <EUktgWDQn8J_6p0n1hIrXZstfpiFQ3c9aL8oTRHhAeA=.e135d3b4-6385-45c5-badd-16e376d5e90e@github.com>

On Thu, 10 Apr 2025 22:27:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> build.gradle line 606:
> 
>> 604: // Specifies whether to run "chmod -R artifacts/sdk" as the last step of
>> 605: // copying the sdk to the artifacts dir. This is only done on Windows;
>> 606: // the flag is ignored on other platforms.
> 
> a minor suggestion: mention JBS ticket for the context

Normally, it is not a best practice to use the bug ID of the bug being fixed. In this case, because the fix is really a workaround for a GHA environment issue, it seems OK. The comment belongs in the GHA script, so I added it there.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1770#discussion_r2039676870

From duke at openjdk.org  Fri Apr 11 14:41:35 2025
From: duke at openjdk.org (duke)
Date: Fri, 11 Apr 2025 14:41:35 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea [v4]
In-Reply-To: <CDdPLwm_Td3FWl9Ox4kfJCxRgEwpAYX6k1iIhxc9WIA=.3619b09e-11af-43a6-8ef9-ac7e3f7fbff6@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <CDdPLwm_Td3FWl9Ox4kfJCxRgEwpAYX6k1iIhxc9WIA=.3619b09e-11af-43a6-8ef9-ac7e3f7fbff6@github.com>
Message-ID: <8TjV6GxyhD3oWaODg7dUraOdC46vnECnwGc0vQ4T7KQ=.af6b1e43-4814-4e6b-8060-d7feeb6db95e@github.com>

On Tue, 25 Mar 2025 22:53:55 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Added multi line prompt support for TextArea this will provide the ability to have multiple lines in textArea as expected,
>> Also fixed tests to meet the new changes
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused imports and code

@Ziad-Mid 
Your change (at version 4364489ce1dceb2323f1bd1c8c4537f152fb0f4e) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1716#issuecomment-2797110159

From arapte at openjdk.org  Fri Apr 11 14:42:48 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 11 Apr 2025 14:42:48 GMT
Subject: RFR: 8354337: GHA: Windows build fails with chmod permission error
 [v2]
In-Reply-To: <2jYthjjGjaewToPcJTfbLeAguQvqDjlcBgys9kH8dOk=.04685680-8687-456c-93a0-3756b8aaa323@github.com>
References: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
 <2jYthjjGjaewToPcJTfbLeAguQvqDjlcBgys9kH8dOk=.04685680-8687-456c-93a0-3756b8aaa323@github.com>
Message-ID: <-uiCSB23I74w_BjKCabP_G7QSQCb47g2_tb7SOsgUdo=.710fb0cb-8487-45d8-b582-c95c62fc5785@github.com>

On Fri, 11 Apr 2025 14:35:46 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> After a recent update by GitHub to the GHA Windows Server 2022 runner, we get the following error in all GHA test runs:
>> 
>> 
>> chmod: changing permissions of '.': Permission denied
>> chmod: changing permissions of './bin': Permission denied 
>> ...
>> 
>> 
>> This PR disables running `chmod -R` on the `artifacts/sdk` dir when doing a GHA build.
>> 
>> The `chmod` is only needed when building artifacts for distribution, and we only use the GHA build for sanity testing, so we can avoid this problem by adding a flag that skips the `chmod` if running on GHA. This is a minimally intrusive solution that would restore our ability to run GHA test builds on Windows without affecting the actual JavaFX build.
>> 
>> I've run a CI build as well as a local build to ensure that the chmod is still being executed.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by arapte (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1770#pullrequestreview-2760578912

From angorya at openjdk.org  Fri Apr 11 14:42:48 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 11 Apr 2025 14:42:48 GMT
Subject: RFR: 8354337: GHA: Windows build fails with chmod permission error
 [v2]
In-Reply-To: <EUktgWDQn8J_6p0n1hIrXZstfpiFQ3c9aL8oTRHhAeA=.e135d3b4-6385-45c5-badd-16e376d5e90e@github.com>
References: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
 <yLUIBozTjYEPG2eHDljPK4v4AxsbCmwsjcrlBUZS1vQ=.93b5f51c-31b1-4d01-820b-3c4870f5ccb0@github.com>
 <EUktgWDQn8J_6p0n1hIrXZstfpiFQ3c9aL8oTRHhAeA=.e135d3b4-6385-45c5-badd-16e376d5e90e@github.com>
Message-ID: <kdzYBWOrlB2g_wfwX7CUx58WgQZIr5j2348WAaqoqFw=.fe845851-b68e-49f4-acbc-90268a779699@github.com>

On Fri, 11 Apr 2025 14:32:54 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> build.gradle line 606:
>> 
>>> 604: // Specifies whether to run "chmod -R artifacts/sdk" as the last step of
>>> 605: // copying the sdk to the artifacts dir. This is only done on Windows;
>>> 606: // the flag is ignored on other platforms.
>> 
>> a minor suggestion: mention JBS ticket for the context
>
> Normally, it is not a best practice to use the bug ID of the bug being fixed. In this case, because the fix is really a workaround for a GHA environment issue, it seems OK. The comment belongs in the GHA script, so I added it there.

Normally, yes, but in some cases the context is important.  Yes, one can look at the git history and get the JBS from there (unless the code was moved or merged), but it seems to be an easier way to provide the answer on the "why was this change made" than write the _War and Peace_ in the comments.  In this case it's perfect - we have good comments and the JBS for anyone who wants to know more.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1770#discussion_r2039685796

From zelmidaoui at openjdk.org  Fri Apr 11 14:44:52 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Fri, 11 Apr 2025 14:44:52 GMT
Subject: Integrated: 8335547: Support multi-line prompt text for TextArea
In-Reply-To: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
Message-ID: <8ZEpVb5JrVe5YdSEMDMmHabuJ4_r8A1JdowqYoEyP-I=.c01b7057-d23d-40a9-a401-f97e9c0c52ed@github.com>

On Wed, 19 Feb 2025 16:50:02 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Added multi line prompt support for TextArea this will provide the ability to have multiple lines in textArea as expected,
> Also fixed tests to meet the new changes

This pull request has now been integrated.

Changeset: dfe8dbb4
Author:    Ziad El Midaoui <zelmidaoui at openjdk.org>
Committer: Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/dfe8dbb4c8bee59b2aabe37f21aaa8005dd0fde5
Stats:     181 lines in 5 files changed: 113 ins; 58 del; 10 mod

8335547: Support multi-line prompt text for TextArea

Reviewed-by: angorya, mstrauss

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

PR: https://git.openjdk.org/jfx/pull/1716

From mstrauss at openjdk.org  Fri Apr 11 14:51:31 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 11 Apr 2025 14:51:31 GMT
Subject: RFR: 8354337: GHA: Windows build fails with chmod permission error
 [v2]
In-Reply-To: <kdzYBWOrlB2g_wfwX7CUx58WgQZIr5j2348WAaqoqFw=.fe845851-b68e-49f4-acbc-90268a779699@github.com>
References: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
 <yLUIBozTjYEPG2eHDljPK4v4AxsbCmwsjcrlBUZS1vQ=.93b5f51c-31b1-4d01-820b-3c4870f5ccb0@github.com>
 <EUktgWDQn8J_6p0n1hIrXZstfpiFQ3c9aL8oTRHhAeA=.e135d3b4-6385-45c5-badd-16e376d5e90e@github.com>
 <kdzYBWOrlB2g_wfwX7CUx58WgQZIr5j2348WAaqoqFw=.fe845851-b68e-49f4-acbc-90268a779699@github.com>
Message-ID: <EfhjtT9RoPvqss7pPghSHUqvqN7dLuxhVE7S4WthyKQ=.85f00aec-6ea2-43db-aeb3-1035f2d86646@github.com>

On Fri, 11 Apr 2025 14:38:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Normally, it is not a best practice to use the bug ID of the bug being fixed. In this case, because the fix is really a workaround for a GHA environment issue, it seems OK. The comment belongs in the GHA script, so I added it there.
>
> Normally, yes, but in some cases the context is important.  Yes, one can look at the git history and get the JBS from there (unless the code was moved or merged), but it seems to be an easier way to provide the answer on the "why was this change made" than write the _War and Peace_ in the comments.  In this case it's perfect - we have good comments and the JBS for anyone who wants to know more.

A good example of what should _not_ be done is something along the lines of ComboBoxListViewSkin:158:

        // Fix for JDK-8115587. Additional code related to this bug is further below.
        this.listView.setManaged(false);
        getChildren().add(listView);
        // -- end of fix

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1770#discussion_r2039702371

From angorya at openjdk.org  Fri Apr 11 14:51:35 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 11 Apr 2025 14:51:35 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system
 is busy
In-Reply-To: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
References: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
Message-ID: <uKhMOue8lHa0sHZm766Zp-Li5Y2Ty8ogjwwOwsIokT0=.9f2212e2-7dd9-4422-9e30-2a45e69c11a3@github.com>

On Fri, 11 Apr 2025 09:37:12 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

> There was a Assertion fail issue in mouse location test case JDK-8296554,
> Reason: We felt the one mili second delay time for the Robot test may be insufficient in few OS.
> Solution: We Changed the delay time to three mili second.
> 
> Verification:
> Tested in Windows 11, and the Assert fail issue is not found.

tests/system/src/test/java/test/robot/javafx/scene/MouseLocationOnScreenTest.java line 46:

> 44:     static CountDownLatch startupLatch = new CountDownLatch(1);
> 45:     static Robot robot;
> 46:     private static int DELAY_TIME = 3;

minor: `Util.sleep()` could be moved to `validate()`

question: even though the value is 3x the original, should it be longer to account for any hiccups?  maybe 10?  what do you think?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1772#discussion_r2039703236

From angorya at openjdk.org  Fri Apr 11 14:57:30 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 11 Apr 2025 14:57:30 GMT
Subject: RFR: 8354337: GHA: Windows build fails with chmod permission error
 [v2]
In-Reply-To: <EfhjtT9RoPvqss7pPghSHUqvqN7dLuxhVE7S4WthyKQ=.85f00aec-6ea2-43db-aeb3-1035f2d86646@github.com>
References: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
 <yLUIBozTjYEPG2eHDljPK4v4AxsbCmwsjcrlBUZS1vQ=.93b5f51c-31b1-4d01-820b-3c4870f5ccb0@github.com>
 <EUktgWDQn8J_6p0n1hIrXZstfpiFQ3c9aL8oTRHhAeA=.e135d3b4-6385-45c5-badd-16e376d5e90e@github.com>
 <kdzYBWOrlB2g_wfwX7CUx58WgQZIr5j2348WAaqoqFw=.fe845851-b68e-49f4-acbc-90268a779699@github.com>
 <EfhjtT9RoPvqss7pPghSHUqvqN7dLuxhVE7S4WthyKQ=.85f00aec-6ea2-43db-aeb3-1035f2d86646@github.com>
Message-ID: <eRAC8fPZxMxMnFmAqse1m3oCu2ffW1jQN0J2RT7_d_k=.8e4068d3-9b0b-4844-a416-8065e1bdbdb9@github.com>

On Fri, 11 Apr 2025 14:48:35 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Normally, yes, but in some cases the context is important.  Yes, one can look at the git history and get the JBS from there (unless the code was moved or merged), but it seems to be an easier way to provide the answer on the "why was this change made" than write the _War and Peace_ in the comments.  In this case it's perfect - we have good comments and the JBS for anyone who wants to know more.
>
> A good example of what should _not_ be done is something along the lines of ComboBoxListViewSkin:158:
> 
>         // Fix for JDK-8115587. Additional code related to this bug is further below.
>         this.listView.setManaged(false);
>         getChildren().add(listView);
>         // -- end of fix

Exactly!  At the same time, `Declaration:160` might be an example of a suitable JBS reference.


    // JDK-8126015
    //
    // We know when the .css file is parsed what the stylesheet URL is,
    // but that might not be the URL of the deployed file. So for URL
    // types, the parser inserts a null placeholder for the URL and we
    // fix it up here. This method is called from Rule#setStylesheet
    // and from Rule#declarations onChanged method.
    //
    void fixUrl(String stylesheetUrl) {

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1770#discussion_r2039711344

From angorya at openjdk.org  Fri Apr 11 15:02:39 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 11 Apr 2025 15:02:39 GMT
Subject: RFR: 8354337: GHA: Windows build fails with chmod permission error
 [v2]
In-Reply-To: <2jYthjjGjaewToPcJTfbLeAguQvqDjlcBgys9kH8dOk=.04685680-8687-456c-93a0-3756b8aaa323@github.com>
References: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
 <2jYthjjGjaewToPcJTfbLeAguQvqDjlcBgys9kH8dOk=.04685680-8687-456c-93a0-3756b8aaa323@github.com>
Message-ID: <cKin-1_tUJkUw3jB0_I6ciOQCfjUr7Sms2avoAQzyH0=.a9c32e79-6eb9-44f5-833b-81ff0d79108b@github.com>

On Fri, 11 Apr 2025 14:35:46 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> After a recent update by GitHub to the GHA Windows Server 2022 runner, we get the following error in all GHA test runs:
>> 
>> 
>> chmod: changing permissions of '.': Permission denied
>> chmod: changing permissions of './bin': Permission denied 
>> ...
>> 
>> 
>> This PR disables running `chmod -R` on the `artifacts/sdk` dir when doing a GHA build.
>> 
>> The `chmod` is only needed when building artifacts for distribution, and we only use the GHA build for sanity testing, so we can avoid this problem by adding a flag that skips the `chmod` if running on GHA. This is a minimally intrusive solution that would restore our ability to run GHA test builds on Windows without affecting the actual JavaFX build.
>> 
>> I've run a CI build as well as a local build to ensure that the chmod is still being executed.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

ship it!

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

PR Comment: https://git.openjdk.org/jfx/pull/1770#issuecomment-2797161021

From angorya at openjdk.org  Fri Apr 11 15:02:41 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 11 Apr 2025 15:02:41 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v25]
In-Reply-To: <vhqd2EYA5HkHqVOAIEHz2d-0fwfq8Q8Ra18mTSL-awc=.30ff17ab-94eb-4c1f-9991-78e88c340699@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <FSGxqaTjt6T7_N3uDzucGJWZjl2lBLI7FM5oSqxEXj0=.56de0fc6-9dce-4944-9fae-cc29f8cd674f@github.com>
 <vhqd2EYA5HkHqVOAIEHz2d-0fwfq8Q8Ra18mTSL-awc=.30ff17ab-94eb-4c1f-9991-78e88c340699@github.com>
Message-ID: <gYc9xZaADtslU2RyrSGLZzz_J-7GjFKHn80SDk7l2lg=.0a39066e-4847-405f-acc9-2fe100b7ab68@github.com>

On Fri, 11 Apr 2025 08:28:40 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   sealed
>
> modules/javafx.graphics/src/main/java/javafx/scene/text/TextLineInfo.java line 36:
> 
>> 34:  * @param bounds the bounds of the text line, in local coordinates:
>> 35:  * <ul>
>> 36:  *   <li>
> 
> We usually indent with 4 spaces.

in this economy, spaces are expensive ;-)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2039721825

From kcr at openjdk.org  Fri Apr 11 15:46:30 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Apr 2025 15:46:30 GMT
Subject: RFR: 8354337: GHA: Windows build fails with chmod permission error
 [v2]
In-Reply-To: <2jYthjjGjaewToPcJTfbLeAguQvqDjlcBgys9kH8dOk=.04685680-8687-456c-93a0-3756b8aaa323@github.com>
References: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
 <2jYthjjGjaewToPcJTfbLeAguQvqDjlcBgys9kH8dOk=.04685680-8687-456c-93a0-3756b8aaa323@github.com>
Message-ID: <AozDaFkVIz7xrBtoFVjWZzwlloIOylRBvihuO1EYoQ0=.7dd3ec56-1d57-427a-9bf8-49e9c7224632@github.com>

On Fri, 11 Apr 2025 14:35:46 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> After a recent update by GitHub to the GHA Windows Server 2022 runner, we get the following error in all GHA test runs:
>> 
>> 
>> chmod: changing permissions of '.': Permission denied
>> chmod: changing permissions of './bin': Permission denied 
>> ...
>> 
>> 
>> This PR disables running `chmod -R` on the `artifacts/sdk` dir when doing a GHA build.
>> 
>> The `chmod` is only needed when building artifacts for distribution, and we only use the GHA build for sanity testing, so we can avoid this problem by adding a flag that skips the `chmod` if running on GHA. This is a minimally intrusive solution that would restore our ability to run GHA test builds on Windows without affecting the actual JavaFX build.
>> 
>> I've run a CI build as well as a local build to ensure that the chmod is still being executed.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Given that this only affects the GHA build on Windows, which is completely broken until this fix goes in, I will waive the 24-hour waiting period.

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

PR Comment: https://git.openjdk.org/jfx/pull/1770#issuecomment-2797285209

From angorya at openjdk.org  Fri Apr 11 15:46:31 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 11 Apr 2025 15:46:31 GMT
Subject: RFR: 8354337: GHA: Windows build fails with chmod permission error
 [v2]
In-Reply-To: <AozDaFkVIz7xrBtoFVjWZzwlloIOylRBvihuO1EYoQ0=.7dd3ec56-1d57-427a-9bf8-49e9c7224632@github.com>
References: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
 <2jYthjjGjaewToPcJTfbLeAguQvqDjlcBgys9kH8dOk=.04685680-8687-456c-93a0-3756b8aaa323@github.com>
 <AozDaFkVIz7xrBtoFVjWZzwlloIOylRBvihuO1EYoQ0=.7dd3ec56-1d57-427a-9bf8-49e9c7224632@github.com>
Message-ID: <PYwQwCx8bTAL3vK74rb78AVFhkpojobT5hegylBPpxM=.c0b8757c-442d-4a6e-a373-3ca5bcf750a9@github.com>

On Fri, 11 Apr 2025 15:41:28 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I will waive the 24-hour waiting period.

thank you!

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

PR Comment: https://git.openjdk.org/jfx/pull/1770#issuecomment-2797296570

From kcr at openjdk.org  Fri Apr 11 15:46:32 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Apr 2025 15:46:32 GMT
Subject: Integrated: 8354337: GHA: Windows build fails with chmod permission
 error
In-Reply-To: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
References: <tyVzc1F1HanA2SnYAlXsg3svqkyTRhYCXhZt4bwGMrk=.ab610256-fc39-4cfc-8e4d-9ea5644d2360@github.com>
Message-ID: <BoaQaRtYKZy-x46fsX_YnZxOQ6Dkp_jog2MAaa5YQoY=.eaefc60c-73b9-4017-9df9-2097471673da@github.com>

On Thu, 10 Apr 2025 22:00:35 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> After a recent update by GitHub to the GHA Windows Server 2022 runner, we get the following error in all GHA test runs:
> 
> 
> chmod: changing permissions of '.': Permission denied
> chmod: changing permissions of './bin': Permission denied 
> ...
> 
> 
> This PR disables running `chmod -R` on the `artifacts/sdk` dir when doing a GHA build.
> 
> The `chmod` is only needed when building artifacts for distribution, and we only use the GHA build for sanity testing, so we can avoid this problem by adding a flag that skips the `chmod` if running on GHA. This is a minimally intrusive solution that would restore our ability to run GHA test builds on Windows without affecting the actual JavaFX build.
> 
> I've run a CI build as well as a local build to ensure that the chmod is still being executed.

This pull request has now been integrated.

Changeset: 8a61dd2b
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/8a61dd2b808e1fa691150d01eafd2697d0d1c56d
Stats:     15 lines in 2 files changed: 11 ins; 0 del; 4 mod

8354337: GHA: Windows build fails with chmod permission error

Reviewed-by: angorya, arapte

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

PR: https://git.openjdk.org/jfx/pull/1770

From kcr at openjdk.org  Fri Apr 11 16:53:11 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Apr 2025 16:53:11 GMT
Subject: [jfx24u] RFR: 8354337: GHA: Windows build fails with chmod permission
 error
Message-ID: <sDQAXefb0tfcop1ICf9gD5jnSNQ6T85uBPkwCXMGRxI=.d79279cf-1703-4736-b7b7-1e83b79503c0@github.com>

Clean backport of GHA Windows fix to jfx24u.

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

Commit messages:
 - Backport 8a61dd2b808e1fa691150d01eafd2697d0d1c56d

Changes: https://git.openjdk.org/jfx24u/pull/20/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx24u&pr=20&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354337
  Stats: 15 lines in 2 files changed: 11 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx24u/pull/20.diff
  Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/20/head:pull/20

PR: https://git.openjdk.org/jfx24u/pull/20

From angorya at openjdk.org  Fri Apr 11 17:06:38 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 11 Apr 2025 17:06:38 GMT
Subject: RFR: 8088343: Intermittent unit test failure in
 javafx.concurrent.ServiceLifecycleTest [v2]
In-Reply-To: <KGLNqPgypdjKohTRf6B0CvSAr-qI-w8vz_qia1fIqaw=.14734aa2-260e-449e-8a19-c196a17af657@github.com>
References: <KGLNqPgypdjKohTRf6B0CvSAr-qI-w8vz_qia1fIqaw=.14734aa2-260e-449e-8a19-c196a17af657@github.com>
Message-ID: <79K9NXxOwFi65KCP1-ZGTHvS_7Is_NaiNGU0JWvvtTg=.8442f221-a6b3-4127-9eb8-9045dbe29d14@github.com>

> The code should not set the `Task.state` value to `CANCELLED` if the said task is already `SUCCEEDED` or `FAILED`.
> 
> This is a product bug.
> 
> Added `@RepeatedTest(50)` to the tests that used to fail intermittently - this made the test failed more reliably without the fix.

Andy Goryachev 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 remote-tracking branch 'origin/master' into 8088343.lifecycle
 - 8088343

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1769/files
  - new: https://git.openjdk.org/jfx/pull/1769/files/bb7c95c0..d605fb92

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1769&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1769&range=00-01

  Stats: 637 lines in 14 files changed: 416 ins; 203 del; 18 mod
  Patch: https://git.openjdk.org/jfx/pull/1769.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1769/head:pull/1769

PR: https://git.openjdk.org/jfx/pull/1769

From mstrauss at openjdk.org  Fri Apr 11 17:40:09 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 11 Apr 2025 17:40:09 GMT
Subject: RFR: 8345348: CSS media feature queries [v10]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <OvTMleUJYnS5Sh7W7F0j0wjydxiCzlYYvgfB7ETZHfA=.be50ae71-ca2b-46a1-a89d-82fb26ac3e43@github.com>

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'master' into feature/media-queries
 - add more tests
 - Merge branch 'master' into feature/media-queries
 - small refactor
 - make media-query types internal
 - add documentation
 - add missing javadoc tag
 - revert import
 - move scene preferences to Scene.Preferences interface
 - revert
 - ... and 7 more: https://git.openjdk.org/jfx/compare/8a61dd2b...3c5bbb84

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

Changes: https://git.openjdk.org/jfx/pull/1655/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=09
  Stats: 4951 lines in 40 files changed: 3840 ins; 1026 del; 85 mod
  Patch: https://git.openjdk.org/jfx/pull/1655.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655

PR: https://git.openjdk.org/jfx/pull/1655

From mstrauss at openjdk.org  Fri Apr 11 17:40:56 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 11 Apr 2025 17:40:56 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v63]
In-Reply-To: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
Message-ID: <SelHAyGoeo75NW8i2BorXVOVY-4qGevJDdjATQ-zDuQ=.152e0a60-5a25-4642-bfc0-4ebe8b30944d@github.com>

> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).

Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 80 commits:

 - Merge branch 'master' into feature/extended-window
 - Remove StageStyle.EXTENDED_UTILITY
 - remove import
 - doc update
 - Merge branch 'master' into feature/extended-window
   
   # Conflicts:
   #	tests/manual/monkey/src/com/oracle/tools/fx/monkey/MainWindow.java
   #	tests/manual/monkey/src/com/oracle/tools/fx/monkey/tools/ModalWindow.java
 - documentation
 - documentation
 - tweak header button scaling at 100%
 - enable preview features in tests
 - add preview feature
 - ... and 70 more: https://git.openjdk.org/jfx/compare/8a61dd2b...3622b05b

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

Changes: https://git.openjdk.org/jfx/pull/1605/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=62
  Stats: 6513 lines in 75 files changed: 5831 ins; 505 del; 177 mod
  Patch: https://git.openjdk.org/jfx/pull/1605.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605

PR: https://git.openjdk.org/jfx/pull/1605

From mhanl at openjdk.org  Fri Apr 11 17:41:37 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 11 Apr 2025 17:41:37 GMT
Subject: Integrated: 8277000: Tree-/TableRowSkin: replace listener to
 fixedCellSize by live lookup
In-Reply-To: <C9DCt4HLNulh3bxF1ZnIbd1WxtJcxnslOcdkY_srAhg=.3c3ae808-45a2-4e0c-a55c-44fa1fdf1305@github.com>
References: <C9DCt4HLNulh3bxF1ZnIbd1WxtJcxnslOcdkY_srAhg=.3c3ae808-45a2-4e0c-a55c-44fa1fdf1305@github.com>
Message-ID: <JqJyjR5jABDWRXUyWTZTjK2aaYCPbMOv8suumrTryDY=.8fcfec85-e8db-4320-9af7-fd186b625018@github.com>

On Fri, 22 Nov 2024 20:31:08 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR improves the `Tree-/TableRowSkin` code by doing a normal live lookup for the `fixedCellSize` instead of adding listener just to update variables(`fixedCellSizeEnabled` and `fixedCellSize`) which can otherwise be also just lookup'd without the hassle of listeners.
> 
> While this is mostly a cleanup, it does improve the state of the `Tree-/TableRow`, as when the `TableRowSkinBase` constructor is called, the variables are not yet set.
> 
> It is also consistent with the other cells, see also [JDK-8246745](https://bugs.openjdk.org/browse/JDK-8246745).
> Helps a bit with [JDK-8185887](https://bugs.openjdk.org/browse/JDK-8185887) (https://github.com/openjdk/jfx/pull/1644), but as written above, not required as there is no (visible) effect.

This pull request has now been integrated.

Changeset: fcdccd9a
Author:    Marius Hanl <mhanl at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/fcdccd9a93b826de6cba2f3c25ec5aeab5d05bcc
Stats:     139 lines in 5 files changed: 77 ins; 29 del; 33 mod

8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup

Reviewed-by: angorya, mstrauss

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

PR: https://git.openjdk.org/jfx/pull/1645

From kcr at openjdk.org  Fri Apr 11 18:19:28 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Apr 2025 18:19:28 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system
 is busy
In-Reply-To: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
References: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
Message-ID: <oBzpkUMMe6_VioWKK9-CcwxJcnk-mx7nEAfEiokATeE=.a5e7647d-afea-48db-a38f-d7db91af73c2@github.com>

On Fri, 11 Apr 2025 09:37:12 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

> There was a Assertion fail issue in mouse location test case JDK-8296554,
> Reason: We felt the one mili second delay time for the Robot test may be insufficient in few OS.
> Solution: We Changed the delay time to three mili second.
> 
> Verification:
> Tested in Windows 11, and the Assert fail issue is not found.

I observe the following behavior:

* On my Mac laptop, this makes the test take nearly three times as long -- 48 sec (use to take 17 sec), which is expected given that `sleep(DELAY)` is done in the inner loop.
* On my Windows laptop, this makes the test take twice as long -- 56 sec (use to take 28 sec)

This is getting to be about as much time as I would want this test to take, so I wouldn't increase it beyond 3ms without some evidence that it is needed.

What testing have you done to ensure that this is sufficient? Have you seen this fail on a particular system with a given load, and then observed that under the same conditions the updated test now passes?

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

PR Review: https://git.openjdk.org/jfx/pull/1772#pullrequestreview-2761203672

From kcr at openjdk.org  Fri Apr 11 18:19:30 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Apr 2025 18:19:30 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system
 is busy
In-Reply-To: <uKhMOue8lHa0sHZm766Zp-Li5Y2Ty8ogjwwOwsIokT0=.9f2212e2-7dd9-4422-9e30-2a45e69c11a3@github.com>
References: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
 <uKhMOue8lHa0sHZm766Zp-Li5Y2Ty8ogjwwOwsIokT0=.9f2212e2-7dd9-4422-9e30-2a45e69c11a3@github.com>
Message-ID: <FxhXlh4yaBw7UhThYuehbjW3XjYP6s2okiK-ptHAOFs=.3521f3f7-2ce9-4fec-9590-0558b5cecb7e@github.com>

On Fri, 11 Apr 2025 14:49:06 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> There was a Assertion fail issue in mouse location test case JDK-8296554,
>> Reason: We felt the one mili second delay time for the Robot test may be insufficient in few OS.
>> Solution: We Changed the delay time to three mili second.
>> 
>> Verification:
>> Tested in Windows 11, and the Assert fail issue is not found.
>
> tests/system/src/test/java/test/robot/javafx/scene/MouseLocationOnScreenTest.java line 46:
> 
>> 44:     static CountDownLatch startupLatch = new CountDownLatch(1);
>> 45:     static Robot robot;
>> 46:     private static int DELAY_TIME = 3;
> 
> minor: `Util.sleep()` could be moved to `validate()`
> 
> question: even though the value is 3x the original, should it be longer to account for any hiccups?  maybe 10?  what do you think?

If we go with this solution, I would recommend leaving it at 3ms. It fails very, very rarely with the existing 1ms, so 3x the time ought to be enough. Tripling it again would just make the test take that much longer without any real assurance that it is needed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1772#discussion_r2040075325

From angorya at openjdk.org  Fri Apr 11 18:25:29 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 11 Apr 2025 18:25:29 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system
 is busy
In-Reply-To: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
References: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
Message-ID: <k0EcO0WyAsGEhKMS5mJlMuaObbl3B-anJZYl-_s8k7Q=.fa339df6-f72a-4084-b9df-5247b3e53e9c@github.com>

On Fri, 11 Apr 2025 09:37:12 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

> There was a Assertion fail issue in mouse location test case JDK-8296554,
> Reason: We felt the one mili second delay time for the Robot test may be insufficient in few OS.
> Solution: We Changed the delay time to three mili second.
> 
> Verification:
> Tested in Windows 11, and the Assert fail issue is not found.

The other alternative (just a suggestion) is to modify the `validate()` method as follows:

- wait 1 ms
- check the coordinates
- if wrong, wait for longer (3? 5?)
- check again
- if coordinates are wrong, fail

what do you think?

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

PR Comment: https://git.openjdk.org/jfx/pull/1772#issuecomment-2797723944

From kcr at openjdk.org  Fri Apr 11 18:44:28 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Apr 2025 18:44:28 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system
 is busy
In-Reply-To: <k0EcO0WyAsGEhKMS5mJlMuaObbl3B-anJZYl-_s8k7Q=.fa339df6-f72a-4084-b9df-5247b3e53e9c@github.com>
References: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
 <k0EcO0WyAsGEhKMS5mJlMuaObbl3B-anJZYl-_s8k7Q=.fa339df6-f72a-4084-b9df-5247b3e53e9c@github.com>
Message-ID: <mvapHWqbWbIXaJM5hcn57WV_yVIt2Kv5zxUEbKj0Xl0=.158e93ab-e031-411e-8cbd-99c890e42cb4@github.com>

On Fri, 11 Apr 2025 18:23:17 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> The other alternative (just a suggestion) is to modify the `validate()` method as follows:
> 
> * wait 1 ms
> * check the coordinates
> * if wrong, wait for longer (3? 5?)
> * check again
> * if coordinates are wrong, fail
> 
> what do you think?

I like this suggestion.

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

PR Comment: https://git.openjdk.org/jfx/pull/1772#issuecomment-2797759365

From mariushanl at web.de  Fri Apr 11 19:14:43 2025
From: mariushanl at web.de (Marius Hanl)
Date: Fri, 11 Apr 2025 19:14:43 +0000
Subject: Aw: Re: [External] : Re: TabPane overflow menu showing blanks
In-Reply-To: <BYAPR10MB3013DE13039AA1E97368E6B1E5B42@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <CAGBnJPt_7_sJq8rX3fENXt3LU2=BZ5xN2mHy5L0gPd3fpFjyww@mail.gmail.com>
 <BYAPR10MB301380B0A50E2EAA83512B94E5AA2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <CAG_-AaCbiTvMhdZ2BWu=FvWMYDgwODd4sKU+vdZS-jvcOwqc0w@mail.gmail.com>
 <BYAPR10MB3013DE13039AA1E97368E6B1E5B42@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <trinity-88d606dd-9cbe-4732-a84d-f1d1e0f59acc-1744398883325@trinity-msg-rest-webde-webde-live-789b78d5db-jfzd5>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250411/465522f8/attachment-0001.htm>

From andy.goryachev at oracle.com  Fri Apr 11 19:17:20 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 11 Apr 2025 19:17:20 +0000
Subject: [External] : Re: TabPane overflow menu showing blanks
In-Reply-To: <CAG_-AaCbiTvMhdZ2BWu=FvWMYDgwODd4sKU+vdZS-jvcOwqc0w@mail.gmail.com>
References: <CAGBnJPt_7_sJq8rX3fENXt3LU2=BZ5xN2mHy5L0gPd3fpFjyww@mail.gmail.com>
 <BYAPR10MB301380B0A50E2EAA83512B94E5AA2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <CAG_-AaCbiTvMhdZ2BWu=FvWMYDgwODd4sKU+vdZS-jvcOwqc0w@mail.gmail.com>
Message-ID: <BYAPR10MB3013F2812A1448711715C156E5B62@BYAPR10MB3013.namprd10.prod.outlook.com>

Proposing to add a menuGraphicFactory property to TabPaneSkin instead, since this functionality is specific to the skin rather than TabPane control (for example, it may be possible to create a skin with no overflow menu, or some kind of roller that makes the overflow menu unnecessary).  Hope this solves the issue at hand.

For more details, see

https://github.com/andy-goryachev-oracle/Test/blob/main/doc/TabPane/TabPaneGraphicFactory.md

and a draft PR:

https://github.com/openjdk/jfx/pull/1773

Please let me know what you think.

-andy


From: Cormac Redmond <credmond at certak.com>
Date: Tuesday, April 8, 2025 at 15:49
To: Andy Goryachev <andy.goryachev at oracle.com>
Cc: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: [External] : Re: TabPane overflow menu showing blanks
Hi Andy,

Thank you for your reply.

That sounds good, re: a menu item factory. E.g., give the devs full control.

I think the ability to disable it (or have it disabled by default) would be good too: a dev might not care about supporting the menu items in many cases. E.g., if a TabPane only has three (graphic-based) tabs, and the user decides to resize the window to something unusually small, then who cares if they can't traverse the tabs, at that size? Nobody realistically expects to be able in such a scenario anyway, and it's better to have no menu than a buggy one.

I don't like the fact that, today, TabPane's menu can misbehave and nobody would know it's going to happen really. I think TabPane should throw an exception (or log a warning) when it receives nodes it knows it will not be able to use in the menu; especially given the menu is always-on.

I think a good overall solution would be:
1.   a menu factory
2.   make the menu optional for those who don't care
3.   log warnings when a tab's header node will not be displayable in a menu (i.e., if the dev hasn't provided a factory and the default "menu factory" knowingly cannot handle it)
1.   Not really sure how JFX folks feel about logging warnings, I note it's minimal today in general, and probably for good reason (e.g., where do you draw the line in the sand about what should be logged vs. not)
Anyway, I think the above will be achievable without any breaking / functionality changes...?



Kind Regards,
Cormac

On Mon, 7 Apr 2025 at 17:59, Andy Goryachev <andy.goryachev at oracle.com<mailto:andy.goryachev at oracle.com>> wrote:
All very good points, thank you for this writeup!

This discussion relates to https://bugs.openjdk.org/browse/JDK-8353599 .  I've been thinking how to handle this issue, and I am leaning to agree with the suggestion proposed in the ticket (some sort of menu item factory).

The current "hacky" solution not obviously fails, but also not scalable - I can see developers wanting to place a Canvas, a Path, a Pane, or any other kind of Node and it would be nearly impossible to "clone" these in a maintainable manner.  With a menu item factory, however, the effort will be shifted on the application dev with a very simple solution.

The other solution that does not involve a new API would be to limit the overflow menu to only list the tabs that are hidden - in this case the graphics Nodes can be reused by the menu items.  The problem with that approach is the overflow menu logic becomes more complicated, to handle the case when menus are hidden on both ends.

What do you think?

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org<mailto:openjfx-dev-retn at openjdk.org>> on behalf of Cormac Redmond <credmond at certak.com<mailto:credmond at certak.com>>
Date: Friday, April 4, 2025 at 17:00
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: TabPane overflow menu showing blanks
Hi,

TabPane tabs allow you to set graphic nodes as the header and there appears to be no documented limitations or best-practises on this.

You might assume it's perfectly reasonable to not set a Tab's text value, and instead set the header as a HBox, consisting of a graphic node (left) and a Label (itself with a text + a graphic, right), to achieve an icon-text-icon style header, which is not an uncommon.

However, the overflow menu, when it kicks in, will not display any text or graphics at all (just a blank space), if your Tab has no "text" set, and the header graphic is not a Label or an ImageView.

It's down to this self-confessed hacky code (https://github.com/openjdk/jfx/blob/f31d00d8f7e601c3bb28a9975dd029390ec92173/modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java#L479<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/blob/f31d00d8f7e601c3bb28a9975dd029390ec92173/modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java*L479__;Iw!!ACWV5N9M2RV99hQ!Mran6HXmukSt2WDoAR19oIpx2dUYe7SVW7YGm6LeVeGvjzbRIBG_bZU5PLxtBI6BiE7zFepT1Vk08YpHig6pbw$>):

    /**
     * VERY HACKY - this lets us 'duplicate' Label and ImageView nodes to be used in a
     * Tab and the tabs menu at the same time.
     */
    private static Node clone(Node n) {
        if (n == null) {
            return null;
        }
        if (n instanceof ImageView) {
            ImageView iv = (ImageView) n;
            ImageView imageview = new ImageView();
            imageview.imageProperty().bind(iv.imageProperty());
            return imageview;
        }
        if (n instanceof Label) {
            Label l = (Label)n;
            Label label = new Label(l.getText(), clone(l.getGraphic()));
            label.textProperty().bind(l.textProperty());
            return label;
        }
        return null;
    }


It is not obvious at all that this is what's going to happen, or why. And it seems impossible to control or influence this in any reasonable way, without replacing the whole TabPaneSkin.

Given TabPane is one of the most important and widely used controls there is, there could/should be some of the following:

  *   Proper documentation on this limitation / behaviour
  *   Some way to set fallback text that can be used in the menu (i.e., that isn't the Tab's header's text, because one might intentionally avoid setting that given there's no way to hide it from the tab header)
  *   Or, better yet, some way to allow you to specify tab header text without displaying it in the actual tab header, which could then be used by the hacky method as normal
  *   Some way to set a callback so the developer can decide what gets displayed for the overflow menu
  *   Some way to override the skin without needing a full copy + paste + rename
  *   Some way to allow the dev to disable the overflow menu, if it's going to produce something unusable. E.g., prefer no menu than a buggy one...

I would view this as a bug, even though it's probably been like this forever.


Some sample code to demonstrate; just look at the menu:

public class TabPaneMenu extends Application {
    @Override
    public void start(Stage primaryStage) {
        TabPane tabPane = new TabPane();

        for (int i = 1; i <= 30; i++) {
            Tab tab;
            if (i == 2) {
                tab = new Tab();
                final Label label = new Label("HBox Tab " + i);
                final HBox hBox = new HBox(label); // Will show as blank in overflow menu!
                tab.setGraphic(hBox);
            } else if (i == 5) {
                tab = new Tab();
                tab.setGraphic(new Label("Label Tab " + i)); // Will show in overflow menu, because it's a Label
            } else {
                tab = new Tab("Normal Tab " + i);
            }

            tab.setContent(new StackPane(new Label("This is Tab " + i)));
            tab.setClosable(false);
            tabPane.getTabs().add(tab);

        }

        Scene scene = new Scene(tabPane, 800, 600);
        primaryStage.setScene(scene);
        primaryStage.show();
    }

    public static void main(String[] args) {
        launch(args);
    }
}


Kind Regards,

Cormac Redmond
Software Engineer, Certak Ltd.

e: credmond at certak.com<mailto:credmond at certak.com> | m: +353 (0) 86 268 2152 | w: www.certak.com<https://urldefense.com/v3/__http:/www.certak.com__;!!ACWV5N9M2RV99hQ!Mran6HXmukSt2WDoAR19oIpx2dUYe7SVW7YGm6LeVeGvjzbRIBG_bZU5PLxtBI6BiE7zFepT1Vk08YpVdP5RVQ$>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250411/e7d43a1f/attachment-0001.htm>

From andy.goryachev at oracle.com  Fri Apr 11 19:27:12 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 11 Apr 2025 19:27:12 +0000
Subject: [External] : Re: TabPane overflow menu showing blanks
In-Reply-To: <trinity-88d606dd-9cbe-4732-a84d-f1d1e0f59acc-1744398883325@trinity-msg-rest-webde-webde-live-789b78d5db-jfzd5>
References: <CAGBnJPt_7_sJq8rX3fENXt3LU2=BZ5xN2mHy5L0gPd3fpFjyww@mail.gmail.com>
 <BYAPR10MB301380B0A50E2EAA83512B94E5AA2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <CAG_-AaCbiTvMhdZ2BWu=FvWMYDgwODd4sKU+vdZS-jvcOwqc0w@mail.gmail.com>
 <BYAPR10MB3013DE13039AA1E97368E6B1E5B42@BYAPR10MB3013.namprd10.prod.outlook.com>
 <trinity-88d606dd-9cbe-4732-a84d-f1d1e0f59acc-1744398883325@trinity-msg-rest-webde-webde-live-789b78d5db-jfzd5>
Message-ID: <BYAPR10MB3013A09AC461162A3A072562E5B62@BYAPR10MB3013.namprd10.prod.outlook.com>

Interesting idea!

I had some concern about disabling the overflow menu - accessibility - but actually it is still possible to navigate to hidden tabs with the arrow keys.  The problem that creates is we would need some sort of indicator that some tabs are hidden, which defeats the purpose.

Since the main complaint was that custom graphic Nodes are not rendered (especially when tabs have no text), fixing that might reduce the need for other changes.
(I also want to mention that the case of table button menu is very different, as it's an optional feature, but the overflow menu is an essential part of the current tab pane skin).

-andy


From: Marius Hanl <mariushanl at web.de>
Date: Friday, April 11, 2025 at 12:14
To: Andy Goryachev <andy.goryachev at oracle.com>, credmond at certak.com <credmond at certak.com>
Cc: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Aw: Re: [External] : Re: TabPane overflow menu showing blanks
I wonder if we want to implement something similar in the TabPaneSkin as we did for the TableColumnHeader Column Menu.
See also: https://bugs.openjdk.org/browse/JDK-8091153 and the PR: https://github.com/openjdk/jfx/pull/1135<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/1135__;!!ACWV5N9M2RV99hQ!LAnN8cAz3_lF-gPNePLRXsG1BSwuUbcXqcqZYhJhkr8nMhggyA-_MO9g63jCWcSc6h5CrRZ1V_TBI-8pTOHQw5Ek$>
In a former PR, I made the creation of the menu lazily, so if the showColumnMenu(..) method is overridden, no resources and listener will ever be created/used for the JavaFX Column Menu.

If we would do the same in TabPaneSkin, then everyone can create an implementation where the whole logic is up to the developer - showing a custom menu, something else, or nothing.

-- Marius

Gesendet: Mittwoch, 9. April 2025 um 20:25
Von: "Andy Goryachev" <andy.goryachev at oracle.com>
An: "Cormac Redmond" <credmond at certak.com>
CC: "openjfx-dev at openjdk.org" <openjfx-dev at openjdk.org>
Betreff: Re: [External] : Re: TabPane overflow menu showing blanks
No problem, Cormac, and thank you for suggestions!  I guess you will be volunteering for the code review?  (No promises as to when this feature will be available though).

Speaking of the disabling the overflow menu: this may not be a good idea from the accessibility perspective, but the idea of menu item factory looks quite promising.  Since we are on the subject, there is one more possibility - Tab::setGraphicProvider(Supplier<Node>) instead of a menu item factory, in addition to the existing Tab::setGraphic(Node).  Might be less flexible as one won't be able to create custom menu items.  Just a thought.

-andy


From: Cormac Redmond <credmond at certak.com>
Date: Tuesday, April 8, 2025 at 15:49
To: Andy Goryachev <andy.goryachev at oracle.com>
Cc: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: [External] : Re: TabPane overflow menu showing blanks
Hi Andy,

Thank you for your reply.

That sounds good, re: a menu item factory. E.g., give the devs full control.

I think the ability to disable it (or have it disabled by default) would be good too: a dev might not care about supporting the menu items in many cases. E.g., if a TabPane only has three (graphic-based) tabs, and the user decides to resize the window to something unusually small, then who cares if they can't traverse the tabs, at that size? Nobody realistically expects to be able in such a scenario anyway, and it's better to have no menu than a buggy one.

I don't like the fact that, today, TabPane's menu can misbehave and nobody would know it's going to happen really. I think TabPane should throw an exception (or log a warning) when it receives nodes it knows it will not be able to use in the menu; especially given the menu is always-on.

I think a good overall solution would be:
1.   a menu factory
2.   make the menu optional for those who don't care
3.   log warnings when a tab's header node will not be displayable in a menu (i.e., if the dev hasn't provided a factory and the default "menu factory" knowingly cannot handle it)
1.   Not really sure how JFX folks feel about logging warnings, I note it's minimal today in general, and probably for good reason (e.g., where do you draw the line in the sand about what should be logged vs. not)
Anyway, I think the above will be achievable without any breaking / functionality changes...?



Kind Regards,
Cormac

On Mon, 7 Apr 2025 at 17:59, Andy Goryachev <andy.goryachev at oracle.com<mailto:andy.goryachev at oracle.com>> wrote:
All very good points, thank you for this writeup!

This discussion relates to https://bugs.openjdk.org/browse/JDK-8353599 .  I've been thinking how to handle this issue, and I am leaning to agree with the suggestion proposed in the ticket (some sort of menu item factory).

The current "hacky" solution not obviously fails, but also not scalable - I can see developers wanting to place a Canvas, a Path, a Pane, or any other kind of Node and it would be nearly impossible to "clone" these in a maintainable manner.  With a menu item factory, however, the effort will be shifted on the application dev with a very simple solution.

The other solution that does not involve a new API would be to limit the overflow menu to only list the tabs that are hidden - in this case the graphics Nodes can be reused by the menu items.  The problem with that approach is the overflow menu logic becomes more complicated, to handle the case when menus are hidden on both ends.

What do you think?

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org<mailto:openjfx-dev-retn at openjdk.org>> on behalf of Cormac Redmond <credmond at certak.com<mailto:credmond at certak.com>>
Date: Friday, April 4, 2025 at 17:00
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: TabPane overflow menu showing blanks
Hi,

TabPane tabs allow you to set graphic nodes as the header and there appears to be no documented limitations or best-practises on this.

You might assume it's perfectly reasonable to not set a Tab's text value, and instead set the header as a HBox, consisting of a graphic node (left) and a Label (itself with a text + a graphic, right), to achieve an icon-text-icon style header, which is not an uncommon.

However, the overflow menu, when it kicks in, will not display any text or graphics at all (just a blank space), if your Tab has no "text" set, and the header graphic is not a Label or an ImageView.

It's down to this self-confessed hacky code (https://github.com/openjdk/jfx/blob/f31d00d8f7e601c3bb28a9975dd029390ec92173/modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java#L479<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/blob/f31d00d8f7e601c3bb28a9975dd029390ec92173/modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java*L479__;Iw!!ACWV5N9M2RV99hQ!Mran6HXmukSt2WDoAR19oIpx2dUYe7SVW7YGm6LeVeGvjzbRIBG_bZU5PLxtBI6BiE7zFepT1Vk08YpHig6pbw$>):

    /**
     * VERY HACKY - this lets us 'duplicate' Label and ImageView nodes to be used in a
     * Tab and the tabs menu at the same time.
     */
    private static Node clone(Node n) {
        if (n == null) {
            return null;
        }
        if (n instanceof ImageView) {
            ImageView iv = (ImageView) n;
            ImageView imageview = new ImageView();
            imageview.imageProperty().bind(iv.imageProperty());
            return imageview;
        }
        if (n instanceof Label) {
            Label l = (Label)n;
            Label label = new Label(l.getText(), clone(l.getGraphic()));
            label.textProperty().bind(l.textProperty());
            return label;
        }
        return null;
    }


It is not obvious at all that this is what's going to happen, or why. And it seems impossible to control or influence this in any reasonable way, without replacing the whole TabPaneSkin.

Given TabPane is one of the most important and widely used controls there is, there could/should be some of the following:

  *   Proper documentation on this limitation / behaviour
  *   Some way to set fallback text that can be used in the menu (i.e., that isn't the Tab's header's text, because one might intentionally avoid setting that given there's no way to hide it from the tab header)
  *   Or, better yet, some way to allow you to specify tab header text without displaying it in the actual tab header, which could then be used by the hacky method as normal
  *   Some way to set a callback so the developer can decide what gets displayed for the overflow menu
  *   Some way to override the skin without needing a full copy + paste + rename
  *   Some way to allow the dev to disable the overflow menu, if it's going to produce something unusable. E.g., prefer no menu than a buggy one...

I would view this as a bug, even though it's probably been like this forever.


Some sample code to demonstrate; just look at the menu:

public class TabPaneMenu extends Application {
    @Override
    public void start(Stage primaryStage) {
        TabPane tabPane = new TabPane();

        for (int i = 1; i <= 30; i++) {
            Tab tab;
            if (i == 2) {
                tab = new Tab();
                final Label label = new Label("HBox Tab " + i);
                final HBox hBox = new HBox(label); // Will show as blank in overflow menu!
                tab.setGraphic(hBox);
            } else if (i == 5) {
                tab = new Tab();
                tab.setGraphic(new Label("Label Tab " + i)); // Will show in overflow menu, because it's a Label
            } else {
                tab = new Tab("Normal Tab " + i);
            }

            tab.setContent(new StackPane(new Label("This is Tab " + i)));
            tab.setClosable(false);
            tabPane.getTabs().add(tab);

        }

        Scene scene = new Scene(tabPane, 800, 600);
        primaryStage.setScene(scene);
        primaryStage.show();
    }

    public static void main(String[] args) {
        launch(args);
    }
}


Kind Regards,

Cormac Redmond
Software Engineer, Certak Ltd.

e: credmond at certak.com<mailto:credmond at certak.com> | m: +353 (0) 86 268 2152 | w: www.certak.com<https://urldefense.com/v3/__http:/www.certak.com__;!!ACWV5N9M2RV99hQ!Mran6HXmukSt2WDoAR19oIpx2dUYe7SVW7YGm6LeVeGvjzbRIBG_bZU5PLxtBI6BiE7zFepT1Vk08YpVdP5RVQ$>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250411/5fbfeb6e/attachment-0001.htm>

From mariushanl at web.de  Fri Apr 11 20:06:51 2025
From: mariushanl at web.de (Marius Hanl)
Date: Fri, 11 Apr 2025 20:06:51 +0000
Subject: Aw: Re: Re: [External] : Re: TabPane overflow menu showing blanks
In-Reply-To: <BYAPR10MB3013A09AC461162A3A072562E5B62@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <CAGBnJPt_7_sJq8rX3fENXt3LU2=BZ5xN2mHy5L0gPd3fpFjyww@mail.gmail.com>
 <BYAPR10MB301380B0A50E2EAA83512B94E5AA2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <CAG_-AaCbiTvMhdZ2BWu=FvWMYDgwODd4sKU+vdZS-jvcOwqc0w@mail.gmail.com>
 <BYAPR10MB3013DE13039AA1E97368E6B1E5B42@BYAPR10MB3013.namprd10.prod.outlook.com>
 <trinity-88d606dd-9cbe-4732-a84d-f1d1e0f59acc-1744398883325@trinity-msg-rest-webde-webde-live-789b78d5db-jfzd5>
 <BYAPR10MB3013A09AC461162A3A072562E5B62@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <trinity-2f724114-da35-4aa6-9c1b-0efd35ed925f-1744402011056@trinity-msg-rest-webde-webde-live-789b78d5db-gvsqn>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250411/c27156fe/attachment-0001.htm>

From andy.goryachev at oracle.com  Fri Apr 11 20:08:03 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 11 Apr 2025 20:08:03 +0000
Subject: [External] : Re: TabPane overflow menu showing blanks
In-Reply-To: <trinity-2f724114-da35-4aa6-9c1b-0efd35ed925f-1744402011056@trinity-msg-rest-webde-webde-live-789b78d5db-gvsqn>
References: <CAGBnJPt_7_sJq8rX3fENXt3LU2=BZ5xN2mHy5L0gPd3fpFjyww@mail.gmail.com>
 <BYAPR10MB301380B0A50E2EAA83512B94E5AA2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <CAG_-AaCbiTvMhdZ2BWu=FvWMYDgwODd4sKU+vdZS-jvcOwqc0w@mail.gmail.com>
 <BYAPR10MB3013DE13039AA1E97368E6B1E5B42@BYAPR10MB3013.namprd10.prod.outlook.com>
 <trinity-88d606dd-9cbe-4732-a84d-f1d1e0f59acc-1744398883325@trinity-msg-rest-webde-webde-live-789b78d5db-jfzd5>
 <BYAPR10MB3013A09AC461162A3A072562E5B62@BYAPR10MB3013.namprd10.prod.outlook.com>
 <trinity-2f724114-da35-4aa6-9c1b-0efd35ed925f-1744402011056@trinity-msg-rest-webde-webde-live-789b78d5db-gvsqn>
Message-ID: <BYAPR10MB3013BA4AEF0AFC39F0B71212E5B62@BYAPR10MB3013.namprd10.prod.outlook.com>

+1

thanks!

-andy



From: Marius Hanl <mariushanl at web.de>
Date: Friday, April 11, 2025 at 13:07
To: Andy Goryachev <andy.goryachev at oracle.com>, credmond at certak.com <credmond at certak.com>
Cc: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Aw: Re: Re: [External] : Re: TabPane overflow menu showing blanks
I agree with the idea of a menu graphic factory and I already checked your PR when you made.
My idea is especially useful for everything beyond that, when you want to further/fully customize it.

I also agree that the overflow is important, especially for accessibility, so I don't know if we really need API to disable it (as of now).

-- Marius

Gesendet: Freitag, 11. April 2025 um 21:27
Von: "Andy Goryachev" <andy.goryachev at oracle.com>
An: "Marius Hanl" <mariushanl at web.de>, "credmond at certak.com" <credmond at certak.com>
CC: "openjfx-dev at openjdk.org" <openjfx-dev at openjdk.org>
Betreff: Re: Re: [External] : Re: TabPane overflow menu showing blanks
Interesting idea!

I had some concern about disabling the overflow menu - accessibility - but actually it is still possible to navigate to hidden tabs with the arrow keys.  The problem that creates is we would need some sort of indicator that some tabs are hidden, which defeats the purpose.

Since the main complaint was that custom graphic Nodes are not rendered (especially when tabs have no text), fixing that might reduce the need for other changes.

(I also want to mention that the case of table button menu is very different, as it's an optional feature, but the overflow menu is an essential part of the current tab pane skin).

-andy


From: Marius Hanl <mariushanl at web.de>
Date: Friday, April 11, 2025 at 12:14
To: Andy Goryachev <andy.goryachev at oracle.com>, credmond at certak.com <credmond at certak.com>
Cc: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Aw: Re: [External] : Re: TabPane overflow menu showing blanks
I wonder if we want to implement something similar in the TabPaneSkin as we did for the TableColumnHeader Column Menu.
See also: https://bugs.openjdk.org/browse/JDK-8091153 and the PR: https://github.com/openjdk/jfx/pull/1135<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/1135__;!!ACWV5N9M2RV99hQ!LAnN8cAz3_lF-gPNePLRXsG1BSwuUbcXqcqZYhJhkr8nMhggyA-_MO9g63jCWcSc6h5CrRZ1V_TBI-8pTOHQw5Ek$>
In a former PR, I made the creation of the menu lazily, so if the showColumnMenu(..) method is overridden, no resources and listener will ever be created/used for the JavaFX Column Menu.

If we would do the same in TabPaneSkin, then everyone can create an implementation where the whole logic is up to the developer - showing a custom menu, something else, or nothing.

-- Marius

Gesendet: Mittwoch, 9. April 2025 um 20:25
Von: "Andy Goryachev" <andy.goryachev at oracle.com>
An: "Cormac Redmond" <credmond at certak.com>
CC: "openjfx-dev at openjdk.org" <openjfx-dev at openjdk.org>
Betreff: Re: [External] : Re: TabPane overflow menu showing blanks
No problem, Cormac, and thank you for suggestions!  I guess you will be volunteering for the code review?  (No promises as to when this feature will be available though).

Speaking of the disabling the overflow menu: this may not be a good idea from the accessibility perspective, but the idea of menu item factory looks quite promising.  Since we are on the subject, there is one more possibility - Tab::setGraphicProvider(Supplier<Node>) instead of a menu item factory, in addition to the existing Tab::setGraphic(Node).  Might be less flexible as one won't be able to create custom menu items.  Just a thought.

-andy


From: Cormac Redmond <credmond at certak.com>
Date: Tuesday, April 8, 2025 at 15:49
To: Andy Goryachev <andy.goryachev at oracle.com>
Cc: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: [External] : Re: TabPane overflow menu showing blanks
Hi Andy,

Thank you for your reply.

That sounds good, re: a menu item factory. E.g., give the devs full control.

I think the ability to disable it (or have it disabled by default) would be good too: a dev might not care about supporting the menu items in many cases. E.g., if a TabPane only has three (graphic-based) tabs, and the user decides to resize the window to something unusually small, then who cares if they can't traverse the tabs, at that size? Nobody realistically expects to be able in such a scenario anyway, and it's better to have no menu than a buggy one.

I don't like the fact that, today, TabPane's menu can misbehave and nobody would know it's going to happen really. I think TabPane should throw an exception (or log a warning) when it receives nodes it knows it will not be able to use in the menu; especially given the menu is always-on.

I think a good overall solution would be:
1.   a menu factory
2.   make the menu optional for those who don't care
3.   log warnings when a tab's header node will not be displayable in a menu (i.e., if the dev hasn't provided a factory and the default "menu factory" knowingly cannot handle it)
1.   Not really sure how JFX folks feel about logging warnings, I note it's minimal today in general, and probably for good reason (e.g., where do you draw the line in the sand about what should be logged vs. not)
Anyway, I think the above will be achievable without any breaking / functionality changes...?



Kind Regards,
Cormac

On Mon, 7 Apr 2025 at 17:59, Andy Goryachev <andy.goryachev at oracle.com<mailto:andy.goryachev at oracle.com>> wrote:
All very good points, thank you for this writeup!

This discussion relates to https://bugs.openjdk.org/browse/JDK-8353599 .  I've been thinking how to handle this issue, and I am leaning to agree with the suggestion proposed in the ticket (some sort of menu item factory).

The current "hacky" solution not obviously fails, but also not scalable - I can see developers wanting to place a Canvas, a Path, a Pane, or any other kind of Node and it would be nearly impossible to "clone" these in a maintainable manner.  With a menu item factory, however, the effort will be shifted on the application dev with a very simple solution.

The other solution that does not involve a new API would be to limit the overflow menu to only list the tabs that are hidden - in this case the graphics Nodes can be reused by the menu items.  The problem with that approach is the overflow menu logic becomes more complicated, to handle the case when menus are hidden on both ends.

What do you think?

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org<mailto:openjfx-dev-retn at openjdk.org>> on behalf of Cormac Redmond <credmond at certak.com<mailto:credmond at certak.com>>
Date: Friday, April 4, 2025 at 17:00
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: TabPane overflow menu showing blanks
Hi,

TabPane tabs allow you to set graphic nodes as the header and there appears to be no documented limitations or best-practises on this.

You might assume it's perfectly reasonable to not set a Tab's text value, and instead set the header as a HBox, consisting of a graphic node (left) and a Label (itself with a text + a graphic, right), to achieve an icon-text-icon style header, which is not an uncommon.

However, the overflow menu, when it kicks in, will not display any text or graphics at all (just a blank space), if your Tab has no "text" set, and the header graphic is not a Label or an ImageView.

It's down to this self-confessed hacky code (https://github.com/openjdk/jfx/blob/f31d00d8f7e601c3bb28a9975dd029390ec92173/modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java#L479<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/blob/f31d00d8f7e601c3bb28a9975dd029390ec92173/modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java*L479__;Iw!!ACWV5N9M2RV99hQ!Mran6HXmukSt2WDoAR19oIpx2dUYe7SVW7YGm6LeVeGvjzbRIBG_bZU5PLxtBI6BiE7zFepT1Vk08YpHig6pbw$>):

    /**
     * VERY HACKY - this lets us 'duplicate' Label and ImageView nodes to be used in a
     * Tab and the tabs menu at the same time.
     */
    private static Node clone(Node n) {
        if (n == null) {
            return null;
        }
        if (n instanceof ImageView) {
            ImageView iv = (ImageView) n;
            ImageView imageview = new ImageView();
            imageview.imageProperty().bind(iv.imageProperty());
            return imageview;
        }
        if (n instanceof Label) {
            Label l = (Label)n;
            Label label = new Label(l.getText(), clone(l.getGraphic()));
            label.textProperty().bind(l.textProperty());
            return label;
        }
        return null;
    }


It is not obvious at all that this is what's going to happen, or why. And it seems impossible to control or influence this in any reasonable way, without replacing the whole TabPaneSkin.

Given TabPane is one of the most important and widely used controls there is, there could/should be some of the following:

  *   Proper documentation on this limitation / behaviour
  *   Some way to set fallback text that can be used in the menu (i.e., that isn't the Tab's header's text, because one might intentionally avoid setting that given there's no way to hide it from the tab header)
  *   Or, better yet, some way to allow you to specify tab header text without displaying it in the actual tab header, which could then be used by the hacky method as normal
  *   Some way to set a callback so the developer can decide what gets displayed for the overflow menu
  *   Some way to override the skin without needing a full copy + paste + rename
  *   Some way to allow the dev to disable the overflow menu, if it's going to produce something unusable. E.g., prefer no menu than a buggy one...

I would view this as a bug, even though it's probably been like this forever.


Some sample code to demonstrate; just look at the menu:

public class TabPaneMenu extends Application {
    @Override
    public void start(Stage primaryStage) {
        TabPane tabPane = new TabPane();

        for (int i = 1; i <= 30; i++) {
            Tab tab;
            if (i == 2) {
                tab = new Tab();
                final Label label = new Label("HBox Tab " + i);
                final HBox hBox = new HBox(label); // Will show as blank in overflow menu!
                tab.setGraphic(hBox);
            } else if (i == 5) {
                tab = new Tab();
                tab.setGraphic(new Label("Label Tab " + i)); // Will show in overflow menu, because it's a Label
            } else {
                tab = new Tab("Normal Tab " + i);
            }

            tab.setContent(new StackPane(new Label("This is Tab " + i)));
            tab.setClosable(false);
            tabPane.getTabs().add(tab);

        }

        Scene scene = new Scene(tabPane, 800, 600);
        primaryStage.setScene(scene);
        primaryStage.show();
    }

    public static void main(String[] args) {
        launch(args);
    }
}


Kind Regards,

Cormac Redmond
Software Engineer, Certak Ltd.

e: credmond at certak.com<mailto:credmond at certak.com> | m: +353 (0) 86 268 2152 | w: www.certak.com<https://urldefense.com/v3/__http:/www.certak.com__;!!ACWV5N9M2RV99hQ!Mran6HXmukSt2WDoAR19oIpx2dUYe7SVW7YGm6LeVeGvjzbRIBG_bZU5PLxtBI6BiE7zFepT1Vk08YpVdP5RVQ$>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250411/e3482404/attachment-0001.htm>

From clemens.lanthaler at itarchitects.at  Fri Apr 11 20:10:14 2025
From: clemens.lanthaler at itarchitects.at (Clemens Lanthaler)
Date: Fri, 11 Apr 2025 22:10:14 +0200
Subject: Menu keyboard shortcuts not working anymore
Message-ID: <1fc37296-c21a-4780-bc80-09196edadbe1@itarchitects.at>

I have just updated my Photoslide App to Javafx24.

What is no longer working is keyboard shortcuts defined in the main menu 
if the focus is inside of a control inside a pane. It seems that the 
pane is consumeing the event. If the focus is on the main windows than 
the shortcuts are working again.
As a workaround I have now registered all shortcuts as eventfilter on 
the scene. But for new developers I think they are wondering why a menu 
shortcut is not alywas working.

Clemens

-- 
ITArchitects
CEO: B.Sc. Clemens Lanthaler
Forchachstrasse 3
A-6166 Fulpmes
Tel.: +43 (0)650 855 2954
email: office at itarchitects.at
homepage: http://www.itarchitects.at
-------------------------------------------------
Notice: This e-mail and any attachments are confidential and may be privileged.
If you are not the intended recipient, notify the sender immediately, destroy all
copies from your system and do not disclose or use the information for any purpose.
Diese E-Mail inklusive aller Anhaenge ist vertraulich und koennte bevorrechtigtem
Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind, informieren Sie
bitte den Absender unverzueglich, loeschen Sie alle Kopien von Ihrem System und
veroeffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x94A919BE276C7EA1.asc
Type: application/pgp-keys
Size: 2460 bytes
Desc: OpenPGP public key
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250411/54b9b51e/OpenPGP_0x94A919BE276C7EA1.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250411/54b9b51e/OpenPGP_signature.asc>

From mhanl at openjdk.org  Fri Apr 11 20:44:39 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 11 Apr 2025 20:44:39 GMT
Subject: RFR: 8339170: =?UTF-8?B?4piC?= Convert tests to JUnit 5
Message-ID: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>

These are the remaining bits and pieces in order to completely remove the JUnit Vintage Engine, and therefore JUnit 4 from JavaFX.
After that, we should either document, that JUnit5 is used (just as information) or close [JDK-8296284](https://bugs.openjdk.org/browse/JDK-8296284) (Since you can not use JUnit4 anymore).

This also removes the `org.hamcrest` dependency, which is actually only used in one test where it can easily be replaced by a `Predicate` (instead of `Matcher`). I'm not convinced that we should keep that dependency for just one test.

Note: I could not get the `:swt` tests to compile/test, in order to run the tests. 
I need some guidance here how to instruct `Gradle` to compile this module (and if I need anything else? like swt?).

Also, this probably needs an extra ticket in the JBS?

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

Commit messages:
 - JDK-8339170: ? Convert tests to JUnit 5

Changes: https://git.openjdk.org/jfx/pull/1774/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1774&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339170
  Stats: 240 lines in 9 files changed: 26 ins; 152 del; 62 mod
  Patch: https://git.openjdk.org/jfx/pull/1774.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1774/head:pull/1774

PR: https://git.openjdk.org/jfx/pull/1774

From kcr at openjdk.org  Fri Apr 11 21:03:39 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Apr 2025 21:03:39 GMT
Subject: RFR: 8339170: =?UTF-8?B?4piC?= Convert tests to JUnit 5
In-Reply-To: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
Message-ID: <7l7sPREE9SbQFGKXYZ4C7oi6NEpPiMq2TLwwe46v0ik=.872fbe06-da88-41d8-abfa-3d24f8f1e20e@github.com>

On Fri, 11 Apr 2025 20:36:48 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> These are the remaining bits and pieces in order to completely remove the JUnit Vintage Engine, and therefore JUnit 4 from JavaFX.
> After that, we should either document, that JUnit5 is used (just as information) or close [JDK-8296284](https://bugs.openjdk.org/browse/JDK-8296284) (Since you can not use JUnit4 anymore).
> 
> This also removes the `org.hamcrest` dependency, which is actually only used in one test where it can easily be replaced by a `Predicate` (instead of `Matcher`). I'm not convinced that we should keep that dependency for just one test.
> 
> Note: I could not get the `:swt` tests to compile/test, in order to run the tests. 
> I need some guidance here how to instruct `Gradle` to compile this module (and if I need anything else? like swt?).
> 
> Also, this probably needs an extra ticket in the JBS?

@Maran23 We don't integrate code using the JBS ID of an umbrella tasks. If there is a need for a follow-on, 
we would file a new Bug or Enhancement issue in JBS and link it to the umbrella.

For this specific case, this PR may be premature. We have closed tests that still use JUnit 4, and this might break our build. I'll check next week.

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

PR Comment: https://git.openjdk.org/jfx/pull/1774#issuecomment-2798003492

From kcr at openjdk.org  Fri Apr 11 21:09:35 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Apr 2025 21:09:35 GMT
Subject: RFR: 8339170: =?UTF-8?B?4piC?= Convert tests to JUnit 5
In-Reply-To: <7l7sPREE9SbQFGKXYZ4C7oi6NEpPiMq2TLwwe46v0ik=.872fbe06-da88-41d8-abfa-3d24f8f1e20e@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
 <7l7sPREE9SbQFGKXYZ4C7oi6NEpPiMq2TLwwe46v0ik=.872fbe06-da88-41d8-abfa-3d24f8f1e20e@github.com>
Message-ID: <3Xgh7MhYeW6zz29fGi7d6tq6LuhKn0OWUfKR0BnWO6A=.1b56aa55-27f1-4348-9e27-13c24afe85ef@github.com>

On Fri, 11 Apr 2025 21:01:13 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> For this specific case, this PR may be premature.

To be more precise, it's the changes in `build.gradle` I'm concerned about. The rest looks like good cleanup (although will need review and testing).

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

PR Comment: https://git.openjdk.org/jfx/pull/1774#issuecomment-2798012529

From kcr at openjdk.org  Fri Apr 11 21:13:36 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Apr 2025 21:13:36 GMT
Subject: [jfx24u] RFR: 8354337: GHA: Windows build fails with chmod
 permission error
In-Reply-To: <sDQAXefb0tfcop1ICf9gD5jnSNQ6T85uBPkwCXMGRxI=.d79279cf-1703-4736-b7b7-1e83b79503c0@github.com>
References: <sDQAXefb0tfcop1ICf9gD5jnSNQ6T85uBPkwCXMGRxI=.d79279cf-1703-4736-b7b7-1e83b79503c0@github.com>
Message-ID: <Pub8Q1HwabE6uNtsojyQ6FkaTMxZ9kqKbzYPAYfk3qM=.1ddedffc-e2e2-4576-bf08-b0cf4da77ab6@github.com>

On Fri, 11 Apr 2025 16:48:24 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport of GHA Windows fix to jfx24u.

Since this is a clean backport, it only needs maintainer approval.

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

PR Comment: https://git.openjdk.org/jfx24u/pull/20#issuecomment-2798018546

From angorya at openjdk.org  Fri Apr 11 21:14:30 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 11 Apr 2025 21:14:30 GMT
Subject: RFR: 8339170: =?UTF-8?B?4piC?= Convert tests to JUnit 5
In-Reply-To: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
Message-ID: <y5_Rp33eUvWO66RId5I4omOaqjwwRlY6_rH8GYUGuf4=.cd2f4be1-f675-4265-be44-5a1fbb594f42@github.com>

On Fri, 11 Apr 2025 20:36:48 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> These are the remaining bits and pieces in order to completely remove the JUnit Vintage Engine, and therefore JUnit 4 from JavaFX.
> After that, we should either document, that JUnit5 is used (just as information) or close [JDK-8296284](https://bugs.openjdk.org/browse/JDK-8296284) (Since you can not use JUnit4 anymore).
> 
> This also removes the `org.hamcrest` dependency, which is actually only used in one test where it can easily be replaced by a `Predicate` (instead of `Matcher`). I'm not convinced that we should keep that dependency for just one test.
> 
> Note: I could not get the `:swt` tests to compile/test, in order to run the tests. 
> I need some guidance here how to instruct `Gradle` to compile this module (and if I need anything else? like swt?).
> 
> Also, this probably needs an extra ticket in the JBS?

modules/javafx.swt/src/test/java/test/javafx/embed/swt/SWTCursorsTest.java line 44:

> 42: 
> 43:     @Rule
> 44:     public SwtRule ctx = new SwtRule();

this looks like a breaking change - what would be the junit5 equivalent of `@Rule`?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1774#discussion_r2040300789

From kcr at openjdk.org  Fri Apr 11 21:19:38 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Apr 2025 21:19:38 GMT
Subject: RFR: 8339170: =?UTF-8?B?4piC?= Convert tests to JUnit 5
In-Reply-To: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
Message-ID: <etMveFLpF9Cb2X8BFLIpK0zZ8IncIXfjmtvlj8lBqew=.fb6cf658-0fb2-4fee-8a79-75941a387934@github.com>

On Fri, 11 Apr 2025 20:36:48 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> Note: I could not get the :swt tests to compile/test, in order to run the tests.
> I need some guidance here how to instruct Gradle to compile this module (and if I need anything else? like swt?).

The build downloads the needed SWT libraries into `build/libs/swt-debug.jar`.  The swt tests are disabled by default. You could try running the tests with `-PSWT_TEST=true` although that might not be sufficient, since it's been a while since anyone has run them.

> Also, this probably needs an extra ticket in the JBS?

Yes. Please file one and link it in JBS as "Blocks" [JDK-8339170](https://bugs.openjdk.org/browse/JDK-8339170)
. Then change the title of this PR to the new bug.

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

PR Comment: https://git.openjdk.org/jfx/pull/1774#issuecomment-2798025693

From mhanl at openjdk.org  Fri Apr 11 21:39:30 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 11 Apr 2025 21:39:30 GMT
Subject: RFR: 8339170: =?UTF-8?B?4piC?= Convert tests to JUnit 5
In-Reply-To: <7l7sPREE9SbQFGKXYZ4C7oi6NEpPiMq2TLwwe46v0ik=.872fbe06-da88-41d8-abfa-3d24f8f1e20e@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
 <7l7sPREE9SbQFGKXYZ4C7oi6NEpPiMq2TLwwe46v0ik=.872fbe06-da88-41d8-abfa-3d24f8f1e20e@github.com>
Message-ID: <ikF5pW0hQrYprh1B_U1OIbfWKP6bb5NkqV9R5ZLU1Og=.5b1bd45d-336f-4cb8-9dd7-0644314ae99e@github.com>

On Fri, 11 Apr 2025 21:01:13 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> @Maran23 We don't integrate code using the JBS ID of an umbrella tasks. If there is a need for a follow-on, we would file a new Bug or Enhancement issue in JBS and link it to the umbrella.

I thought so, will do!
If needed, we can also split this PR later on, I'm completely open for that.

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

PR Comment: https://git.openjdk.org/jfx/pull/1774#issuecomment-2798052921

From mhanl at openjdk.org  Fri Apr 11 21:39:31 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 11 Apr 2025 21:39:31 GMT
Subject: RFR: 8339170: =?UTF-8?B?4piC?= Convert tests to JUnit 5
In-Reply-To: <y5_Rp33eUvWO66RId5I4omOaqjwwRlY6_rH8GYUGuf4=.cd2f4be1-f675-4265-be44-5a1fbb594f42@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
 <y5_Rp33eUvWO66RId5I4omOaqjwwRlY6_rH8GYUGuf4=.cd2f4be1-f675-4265-be44-5a1fbb594f42@github.com>
Message-ID: <Nrl8k3z4BEAWyIRI18ymy_0qsppByFg1rVZ2nHm83q0=.b2068a1b-b8d0-41eb-9519-b5c0f7e7c93f@github.com>

On Fri, 11 Apr 2025 21:11:57 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> These are the remaining bits and pieces in order to completely remove the JUnit Vintage Engine, and therefore JUnit 4 from JavaFX.
>> After that, we should either document, that JUnit5 is used (just as information) or close [JDK-8296284](https://bugs.openjdk.org/browse/JDK-8296284) (Since you can not use JUnit4 anymore).
>> 
>> This also removes the `org.hamcrest` dependency, which is actually only used in one test where it can easily be replaced by a `Predicate` (instead of `Matcher`). I'm not convinced that we should keep that dependency for just one test.
>> 
>> Note: I could not get the `:swt` tests to compile/test, in order to run the tests. 
>> I need some guidance here how to instruct `Gradle` to compile this module (and if I need anything else? like swt?).
>> 
>> Also, this probably needs an extra ticket in the JBS?
>
> modules/javafx.swt/src/test/java/test/javafx/embed/swt/SWTCursorsTest.java line 44:
> 
>> 42: 
>> 43:     @Rule
>> 44:     public SwtRule ctx = new SwtRule();
> 
> this looks like a breaking change - what would be the junit5 equivalent of `@Rule`?

`@ExtendWith`, but I think there is no equivalent of a method rule. In any case, another SWT test seems to be just fine without it, so I adapted the pattern to all other tests. We need to check if that works though.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1774#discussion_r2040323973

From angorya at openjdk.org  Fri Apr 11 22:52:42 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 11 Apr 2025 22:52:42 GMT
Subject: RFR: 8345348: CSS media feature queries [v10]
In-Reply-To: <OvTMleUJYnS5Sh7W7F0j0wjydxiCzlYYvgfB7ETZHfA=.be50ae71-ca2b-46a1-a89d-82fb26ac3e43@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <OvTMleUJYnS5Sh7W7F0j0wjydxiCzlYYvgfB7ETZHfA=.be50ae71-ca2b-46a1-a89d-82fb26ac3e43@github.com>
Message-ID: <QLNj132RdpMlKX-98tXSgyqYDFHDQimk59NZILQZEKg=.b2ffe743-471b-4c9e-8fdb-0b9286daf439@github.com>

On Fri, 11 Apr 2025 17:40:09 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Merge branch 'master' into feature/media-queries
>  - add more tests
>  - Merge branch 'master' into feature/media-queries
>  - small refactor
>  - make media-query types internal
>  - add documentation
>  - add missing javadoc tag
>  - revert import
>  - move scene preferences to Scene.Preferences interface
>  - revert
>  - ... and 7 more: https://git.openjdk.org/jfx/compare/8a61dd2b...3c5bbb84

Partial review: the test cases are pretty comprehensive, thanks!

modules/javafx.graphics/src/test/java/test/javafx/scene/Scene_preferences_Test.java line 86:

> 84:             new TestRun("prefers-reduced-data",
> 85:                     prefs -> prefs.setReducedData(false),
> 86:                     prefs -> prefs.setReducedData(true))

it's probably an IDE artifact, but indentation is all over the place.

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

PR Review: https://git.openjdk.org/jfx/pull/1655#pullrequestreview-2761718408
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2040384310

From angorya at openjdk.org  Fri Apr 11 23:00:39 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 11 Apr 2025 23:00:39 GMT
Subject: RFR: 8345348: CSS media feature queries [v9]
In-Reply-To: <vfDAhTVfIXS1tLXyrZwK-1h03II4dsP4b8wZph6qFIc=.e468478f-9db3-4147-9934-2c3743cd1674@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <BkSEwG0FIOy_zTs3zg5307r-WxntmiZ81PH27hvQeMo=.71a6d7a7-fe7f-4255-8800-5c3c65c2061d@github.com>
 <5BQS31A32z-KgAgMNDC5O4EgLjiJ7b4eoznPbJO45ds=.155fdc05-0097-49d4-8edd-bffe7da631eb@github.com>
 <vfDAhTVfIXS1tLXyrZwK-1h03II4dsP4b8wZph6qFIc=.e468478f-9db3-4147-9934-2c3743cd1674@github.com>
Message-ID: <OQunjMY4E8FegWxCIVx9xbPL9733cfGWAxAbGkuGdQM=.ba965fe5-585d-43e9-bbb2-58419b52273f@github.com>

On Thu, 10 Apr 2025 16:44:38 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> You seem to be arguing against media queries themselves

Probably.  I am afraid the CSS subsystem will grow into a monster (I mean, it already is).

The follow up question is what you guys think about updating `modena.css` to support the dark mode?  I understand the platform preferences and these media queries are prerequisites, what are other things that we'll need?

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

PR Comment: https://git.openjdk.org/jfx/pull/1655#issuecomment-2798143483

From jgneff at openjdk.org  Fri Apr 11 23:49:31 2025
From: jgneff at openjdk.org (John Neffenger)
Date: Fri, 11 Apr 2025 23:49:31 GMT
Subject: RFR: 8353632: [Linux] Undefined reference to
 PlatformSupport::OBSERVED_SETTINGS with C++14
In-Reply-To: <jlakUm_s21y5is_ZN9-_GvxoISGGP06H4i4Z-H6VdJo=.faa839da-4d16-4cdc-9024-1333bb504cdd@github.com>
References: <jlakUm_s21y5is_ZN9-_GvxoISGGP06H4i4Z-H6VdJo=.faa839da-4d16-4cdc-9024-1333bb504cdd@github.com>
Message-ID: <VsxCjGhsMHvcuJZgu6LoTs5Sg935R-YyJQKuDmT4NAk=.38b90c48-2cb7-490c-b0fe-8d57d0539f36@github.com>

On Thu, 10 Apr 2025 16:11:07 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Fixes a link error that occurs when using C++14 to compile and link JavaFX on Linux.
> 
> 
> in function `PlatformSupport::PlatformSupport(JNIEnv_*, _jobject*)':
> PlatformSupport.cpp:90: undefined reference to `PlatformSupport::OBSERVED_SETTINGS'
> 
> 
> The solution, proposed by @johanvos, is to define `PlatformSupport::OBSERVED_SETTINGS` in `PlatformSupport.cpp`.
> 
> I have tested this using gcc 13.2 and 14.2 using C++17 and it builds and runs as expected. Johan has already tested a variant of this on C++14, but I will wait for his explicit review.

Just a note in case anyone else encounters a related runtime error ...

When I built JavaFX using either gcc version 7.4.0 on Ubuntu 18.04 LTS or gcc version 9.3.0 on Ubuntu 20.04 LTS, I got the following error at runtime:


Exception in thread "main" java.lang.reflect.InvocationTargetException
    Caused by: java.lang.UnsatisfiedLinkError: libglassgtk3.so:
    undefined symbol: _ZN15PlatformSupport17OBSERVED_SETTINGSE


The runtime error did not occur after I upgraded the build system to gcc version 11.2.0 on Ubuntu 22.04 LTS, so I didn't debug it any further.

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

PR Comment: https://git.openjdk.org/jfx/pull/1768#issuecomment-2798225280

From mhanl at openjdk.org  Sat Apr 12 00:23:07 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Sat, 12 Apr 2025 00:23:07 GMT
Subject: RFR: 8354455: [TestBug] Remove JUnit Vintage Engine with JUnit 4
 [v2]
In-Reply-To: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
Message-ID: <2lU-5ueNuUrn8wX8X8TbCOWCxmy45QyHpUeL46HE9QA=.112480de-179c-4069-934f-188d359f25c6@github.com>

> These are the remaining bits and pieces in order to completely remove the JUnit Vintage Engine, and therefore JUnit 4 from JavaFX.
> After that, we should either document, that JUnit5 is used (just as information) or close [JDK-8296284](https://bugs.openjdk.org/browse/JDK-8296284) (Since you can not use JUnit4 anymore).
> 
> This also removes the `org.hamcrest` dependency, which is actually only used in one test where it can easily be replaced by a `Predicate` (instead of `Matcher`). I'm not convinced that we should keep that dependency for just one test.
> 
> Note: I could not get the `:swt` tests to compile/test, in order to run the tests. 
> I need some guidance here how to instruct `Gradle` to compile this module (and if I need anything else? like swt?).
> 
> Also, this probably needs an extra ticket in the JBS?

Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:

  Fix SWT Tests

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1774/files
  - new: https://git.openjdk.org/jfx/pull/1774/files/60262b5e..dc7925f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1774&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1774&range=00-01

  Stats: 205 lines in 4 files changed: 101 ins; 15 del; 89 mod
  Patch: https://git.openjdk.org/jfx/pull/1774.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1774/head:pull/1774

PR: https://git.openjdk.org/jfx/pull/1774

From mhanl at openjdk.org  Sat Apr 12 01:00:33 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Sat, 12 Apr 2025 01:00:33 GMT
Subject: RFR: 8354455: [TestBug] Remove JUnit Vintage Engine with JUnit 4
 [v2]
In-Reply-To: <Nrl8k3z4BEAWyIRI18ymy_0qsppByFg1rVZ2nHm83q0=.b2068a1b-b8d0-41eb-9519-b5c0f7e7c93f@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
 <y5_Rp33eUvWO66RId5I4omOaqjwwRlY6_rH8GYUGuf4=.cd2f4be1-f675-4265-be44-5a1fbb594f42@github.com>
 <Nrl8k3z4BEAWyIRI18ymy_0qsppByFg1rVZ2nHm83q0=.b2068a1b-b8d0-41eb-9519-b5c0f7e7c93f@github.com>
Message-ID: <_lXhqx1Z6DacYObQqXagLXwW1IEovdZU2WaiHyNuvuU=.7127cc28-1a97-4ef9-a11d-77f8f8d8991c@github.com>

On Fri, 11 Apr 2025 21:34:37 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> modules/javafx.swt/src/test/java/test/javafx/embed/swt/SWTCursorsTest.java line 44:
>> 
>>> 42: 
>>> 43:     @Rule
>>> 44:     public SwtRule ctx = new SwtRule();
>> 
>> this looks like a breaking change - what would be the junit5 equivalent of `@Rule`?
>
> `@ExtendWith`, but I think there is no equivalent of a method rule. In any case, another SWT test seems to be just fine without it, so I adapted the pattern to all other tests. We need to check if that works though.

So this was interesting, turns out it wasn't that stable after all even before!
With some adjustments to the Gradle file, I could make the tests work and they are now green.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1774#discussion_r2040474859

From almatvee at openjdk.org  Sat Apr 12 01:48:28 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Sat, 12 Apr 2025 01:48:28 GMT
Subject: RFR: 8329227: Seek might hang with fMP4 H.265/HEVC or H.265/HEVC over
 HTTP/FILE
Message-ID: <R-ffhVyTAJn_nKduqOc1JtVWwxRUN-JgxveUIJNeLag=.8e4b0f80-8698-47f5-aa87-9eae30e2f736@github.com>

- Fixed by reloading decoder for each seek.
- Tested with all H.265 files for HLS/HTTP/FILE, no issues found.
- Seek performance is not affected or at least I did not notice any performance issues when doing reload for each seek.

This is workaround and no other reasonable solutions were found.

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

Commit messages:
 - 8329227: Seek might hang with fMP4 H.265/HEVC or H.265/HEVC over HTTP/FILE

Changes: https://git.openjdk.org/jfx/pull/1775/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1775&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329227
  Stats: 165 lines in 2 files changed: 130 ins; 13 del; 22 mod
  Patch: https://git.openjdk.org/jfx/pull/1775.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1775/head:pull/1775

PR: https://git.openjdk.org/jfx/pull/1775

From mstrauss at openjdk.org  Sat Apr 12 10:33:29 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 12 Apr 2025 10:33:29 GMT
Subject: RFR: 8345348: CSS media feature queries [v9]
In-Reply-To: <OQunjMY4E8FegWxCIVx9xbPL9733cfGWAxAbGkuGdQM=.ba965fe5-585d-43e9-bbb2-58419b52273f@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <BkSEwG0FIOy_zTs3zg5307r-WxntmiZ81PH27hvQeMo=.71a6d7a7-fe7f-4255-8800-5c3c65c2061d@github.com>
 <5BQS31A32z-KgAgMNDC5O4EgLjiJ7b4eoznPbJO45ds=.155fdc05-0097-49d4-8edd-bffe7da631eb@github.com>
 <vfDAhTVfIXS1tLXyrZwK-1h03II4dsP4b8wZph6qFIc=.e468478f-9db3-4147-9934-2c3743cd1674@github.com>
 <OQunjMY4E8FegWxCIVx9xbPL9733cfGWAxAbGkuGdQM=.ba965fe5-585d-43e9-bbb2-58419b52273f@github.com>
Message-ID: <j07cV3kj-JS6qqVKaNP-8rrdzET1v2Vj_hmTfzliNvA=.8ba380dd-c7fa-4b37-b2fd-9ab7b4302aaf@github.com>

On Fri, 11 Apr 2025 22:57:51 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > You seem to be arguing against media queries themselves
> 
> Probably. I am afraid the CSS subsystem will grow into a monster (I mean, it already is).

It is, and it?s held together by duct tape in many places. That?s why I think we should consider the rewrite at some point in the future to put it on solid footing (and it?s the only way to get really useful things like variables).

Media queries are pretty orthogonal to that, as most of the implementation will be the same with a potential rewrite.

> The follow up question is what you guys think about updating `modena.css` to support the dark mode? I understand the platform preferences and these media queries are prerequisites, what are other things that we'll need?

What?s missing to properly support dark mode is really only the external configuration of stylesheets, so I think with media queries in place we have everything we need for a dark version of Modena.

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

PR Comment: https://git.openjdk.org/jfx/pull/1655#issuecomment-2798777347

From mstrauss at openjdk.org  Sat Apr 12 11:34:24 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 12 Apr 2025 11:34:24 GMT
Subject: RFR: 8345348: CSS media feature queries [v11]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <6BTMEQ6w54DCbv7f17bO4BiISOybqY7U4nWALb2TN10=.34b8d036-c415-4c62-93f2-58651257f22f@github.com>

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  change indentation

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/3c5bbb84..c39aa537

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=10
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=09-10

  Stats: 20 lines in 1 file changed: 5 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jfx/pull/1655.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655

PR: https://git.openjdk.org/jfx/pull/1655

From kcr at openjdk.org  Sat Apr 12 14:28:30 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 12 Apr 2025 14:28:30 GMT
Subject: RFR: 8329227: Seek might hang with fMP4 H.265/HEVC or H.265/HEVC
 over HTTP/FILE
In-Reply-To: <R-ffhVyTAJn_nKduqOc1JtVWwxRUN-JgxveUIJNeLag=.8e4b0f80-8698-47f5-aa87-9eae30e2f736@github.com>
References: <R-ffhVyTAJn_nKduqOc1JtVWwxRUN-JgxveUIJNeLag=.8e4b0f80-8698-47f5-aa87-9eae30e2f736@github.com>
Message-ID: <aGcMzxQdWr5WdsfdQLl4V6-mvyAY5QIm0sYO95uk-wA=.fb69cc89-37d2-4210-8c28-d8452bdd4ca9@github.com>

On Sat, 12 Apr 2025 01:43:29 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Fixed by reloading decoder for each seek.
> - Tested with all H.265 files for HLS/HTTP/FILE, no issues found.
> - Seek performance is not affected or at least I did not notice any performance issues when doing reload for each seek.
> 
> This is workaround and no other reasonable solutions were found.

Reviewers: @kevinrushforth @arapte

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

PR Comment: https://git.openjdk.org/jfx/pull/1775#issuecomment-2798851636

From mstrauss at openjdk.org  Sat Apr 12 14:54:23 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 12 Apr 2025 14:54:23 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v64]
In-Reply-To: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
Message-ID: <MxJk75IJVDcj1yWpVcGjgRgcOMbZiqfVLIiyv_5wF_Q=.f0b9fc15-1f37-4606-912d-d8ed208469d2@github.com>

> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  don't show a right-click system menu in full-screen mode

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1605/files
  - new: https://git.openjdk.org/jfx/pull/1605/files/3622b05b..e9aeaefd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=63
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=62-63

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1605.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605

PR: https://git.openjdk.org/jfx/pull/1605

From kcr at openjdk.org  Sat Apr 12 15:00:35 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 12 Apr 2025 15:00:35 GMT
Subject: RFR: 8354455: [TestBug] Remove JUnit Vintage Engine with JUnit 4
In-Reply-To: <7l7sPREE9SbQFGKXYZ4C7oi6NEpPiMq2TLwwe46v0ik=.872fbe06-da88-41d8-abfa-3d24f8f1e20e@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
 <7l7sPREE9SbQFGKXYZ4C7oi6NEpPiMq2TLwwe46v0ik=.872fbe06-da88-41d8-abfa-3d24f8f1e20e@github.com>
Message-ID: <mG7zDYiT_hpcwpxqWsFNlLL3pcDM_0GP0wtcVnxvc6g=.7eb61bdd-147b-4398-a21f-8ea593631b88@github.com>

On Fri, 11 Apr 2025 21:01:13 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> For this specific case, this PR may be premature. We have closed tests that still use JUnit 4, and this might break our build. I'll check next week.

A quick initial test suggests that this will not be a problem after all. We do not use the gradle-downloaded JUnit 4 jar files in our closed tests. I will need to do a full test run next week to confirm this, but so far this looks OK.

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

PR Comment: https://git.openjdk.org/jfx/pull/1774#issuecomment-2798863325

From jhendrikx at openjdk.org  Sat Apr 12 18:35:32 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 12 Apr 2025 18:35:32 GMT
Subject: RFR: 8345348: CSS media feature queries [v9]
In-Reply-To: <OQunjMY4E8FegWxCIVx9xbPL9733cfGWAxAbGkuGdQM=.ba965fe5-585d-43e9-bbb2-58419b52273f@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <BkSEwG0FIOy_zTs3zg5307r-WxntmiZ81PH27hvQeMo=.71a6d7a7-fe7f-4255-8800-5c3c65c2061d@github.com>
 <5BQS31A32z-KgAgMNDC5O4EgLjiJ7b4eoznPbJO45ds=.155fdc05-0097-49d4-8edd-bffe7da631eb@github.com>
 <vfDAhTVfIXS1tLXyrZwK-1h03II4dsP4b8wZph6qFIc=.e468478f-9db3-4147-9934-2c3743cd1674@github.com>
 <OQunjMY4E8FegWxCIVx9xbPL9733cfGWAxAbGkuGdQM=.ba965fe5-585d-43e9-bbb2-58419b52273f@github.com>
Message-ID: <B4AgPQc3gXOr13FW-_WaLnKkpJGX0Q9WiIUDwtw7yL0=.3225ef44-710b-4ef9-82eb-daefa3fcc102@github.com>

On Fri, 11 Apr 2025 22:57:51 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > You seem to be arguing against media queries themselves
> 
> Probably. I am afraid the CSS subsystem will grow into a monster (I mean, it already is).
> 
> The follow up question is what you guys think about updating `modena.css` to support the dark mode? I understand the platform preferences and these media queries are prerequisites, what are other things that we'll need?

With some minimal style changes (and a hack to change the window border to dark mode on Windows) I get this out of modena.css:

![image](https://github.com/user-attachments/assets/3f2023ad-b147-4656-9cc9-57691b96befb)

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

PR Comment: https://git.openjdk.org/jfx/pull/1655#issuecomment-2798941260

From mstrauss at openjdk.org  Sat Apr 12 20:04:29 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 12 Apr 2025 20:04:29 GMT
Subject: RFR: 8345348: CSS media feature queries [v9]
In-Reply-To: <B4AgPQc3gXOr13FW-_WaLnKkpJGX0Q9WiIUDwtw7yL0=.3225ef44-710b-4ef9-82eb-daefa3fcc102@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <BkSEwG0FIOy_zTs3zg5307r-WxntmiZ81PH27hvQeMo=.71a6d7a7-fe7f-4255-8800-5c3c65c2061d@github.com>
 <5BQS31A32z-KgAgMNDC5O4EgLjiJ7b4eoznPbJO45ds=.155fdc05-0097-49d4-8edd-bffe7da631eb@github.com>
 <vfDAhTVfIXS1tLXyrZwK-1h03II4dsP4b8wZph6qFIc=.e468478f-9db3-4147-9934-2c3743cd1674@github.com>
 <OQunjMY4E8FegWxCIVx9xbPL9733cfGWAxAbGkuGdQM=.ba965fe5-585d-43e9-bbb2-58419b52273f@github.com>
 <B4AgPQc3gXOr13FW-_WaLnKkpJGX0Q9WiIUDwtw7yL0=.3225ef44-710b-4ef9-82eb-daefa3fcc102@github.com>
Message-ID: <u5UFBe5z7CrqLaVsa3aK-7spx9_J8YEIJVZE1fDBQLU=.1305f9c4-6229-4fe6-96eb-968c818f8eef@github.com>

On Sat, 12 Apr 2025 18:32:57 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> With some minimal style changes (and a hack to change the window border to dark mode on Windows) I get this out of modena.css:

Nice! Once we have a per-scene color scheme, I plan to have window borders adjust to the color scheme of the scene.

By the way, can I interest you in a review of this PR?

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

PR Comment: https://git.openjdk.org/jfx/pull/1655#issuecomment-2799020057

From jhendrikx at openjdk.org  Sat Apr 12 21:30:30 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 12 Apr 2025 21:30:30 GMT
Subject: RFR: 8345348: CSS media feature queries [v9]
In-Reply-To: <u5UFBe5z7CrqLaVsa3aK-7spx9_J8YEIJVZE1fDBQLU=.1305f9c4-6229-4fe6-96eb-968c818f8eef@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <BkSEwG0FIOy_zTs3zg5307r-WxntmiZ81PH27hvQeMo=.71a6d7a7-fe7f-4255-8800-5c3c65c2061d@github.com>
 <5BQS31A32z-KgAgMNDC5O4EgLjiJ7b4eoznPbJO45ds=.155fdc05-0097-49d4-8edd-bffe7da631eb@github.com>
 <vfDAhTVfIXS1tLXyrZwK-1h03II4dsP4b8wZph6qFIc=.e468478f-9db3-4147-9934-2c3743cd1674@github.com>
 <OQunjMY4E8FegWxCIVx9xbPL9733cfGWAxAbGkuGdQM=.ba965fe5-585d-43e9-bbb2-58419b52273f@github.com>
 <B4AgPQc3gXOr13FW-_WaLnKkpJGX0Q9WiIUDwtw7yL0=.3225ef44-710b-4ef9-82eb-daefa3fcc102@github.com>
 <u5UFBe5z7CrqLaVsa3aK-7spx9_J8YEIJVZE1fDBQLU=.1305f9c4-6229-4fe6-96eb-968c818f8eef@github.com>
Message-ID: <Gh4UBB7_X_KhRCwRL4pneW1IejWK-D1Myp7FIC50Meg=.f85dd69d-2ce0-4ab2-8fd2-209de593e451@github.com>

On Sat, 12 Apr 2025 20:01:44 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> By the way, can I interest you in a review of this PR?

Yes, I already partially checked it out, and was intending to do a closer review soon.

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

PR Comment: https://git.openjdk.org/jfx/pull/1655#issuecomment-2799045186

From mstrauss at openjdk.org  Sun Apr 13 09:24:28 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 13 Apr 2025 09:24:28 GMT
Subject: RFR: 8345348: CSS media feature queries [v12]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <y_VL1wXp5tYvGxDn1CiJ2jmf8q2Di3DMhmwVNCci_GA=.f3989718-2df7-444a-9615-5ab32e7fa321@github.com>

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  small refactor

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/c39aa537..51d26f71

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=11
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=10-11

  Stats: 40 lines in 5 files changed: 18 ins; 17 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1655.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655

PR: https://git.openjdk.org/jfx/pull/1655

From tsayao at openjdk.org  Sun Apr 13 15:29:15 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 13 Apr 2025 15:29:15 GMT
Subject: RFR: 8354478: Improve StageStyle documentation
Message-ID: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>

Improve StageStyle Documentation

- Update `StageStyle.UTILITY`:
Clarified that UTILITY stages may impose platform-specific restrictions on window states, such as preventing maximize, minimize (iconify), and fullscreen operations.

- Update `StageStyle.UNDECORATED`:
Improved the description to clarify that although UNDECORATED removes standard window decorations (title bar, borders, and controls), window operations like minimize, maximize, and fullscreen may still be allowed programmatically or via platform-specific functions such as key shortcuts or menu options.

- Remove mention of solid white background:
This seems to be not true anymore, even withou a `Scene` (or there's a bug)

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

Commit messages:
 - 8354478: Improve StageStyle documentation

Changes: https://git.openjdk.org/jfx/pull/1776/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1776&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354478
  Stats: 11 lines in 1 file changed: 7 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1776.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1776/head:pull/1776

PR: https://git.openjdk.org/jfx/pull/1776

From mstrauss at openjdk.org  Sun Apr 13 17:34:15 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 13 Apr 2025 17:34:15 GMT
Subject: RFR: 8345348: CSS media feature queries [v13]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <9U5TJOMXb3oMWWijiRzo0lp7FJZIQPl-PkRJ3Rc-IqA=.959a8ee1-b84e-46ba-8dec-96c2dd7af9aa@github.com>

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  improved implementation of NullCoalescingPropertyBase

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/51d26f71..b5bfc603

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=12
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=11-12

  Stats: 87 lines in 3 files changed: 72 ins; 2 del; 13 mod
  Patch: https://git.openjdk.org/jfx/pull/1655.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655

PR: https://git.openjdk.org/jfx/pull/1655

From tsayao at openjdk.org  Sun Apr 13 17:51:06 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 13 Apr 2025 17:51:06 GMT
Subject: RFR: 8354480: A Stage should allow simultaneous iconified and
 maximized states
Message-ID: <XPiErE5T6bPke2M_SuaDQg0--lQgExgBrJ9mgG9azSA=.a190b01b-6888-4d37-8b7f-eab469458e5d@github.com>

On some platforms (at least on Ubuntu 24.04 with GNOME and Windows 11), windows can remain maximized even when they are iconified (minimized). When the window is de-iconified (restored), it retains its maximized state.

The documentation in `Stage.java` regarding window states seems to align with this behavior. However, the code currently treats the `WindowEvent.RESTORE` event as both an unminimize (de-iconify) and an unmaximize.

Tests pass on Ubuntu 24.04 XWayland (with one unrelated screenCapture failure). But I would not rely on that since it needes specific tests.

This is not ready to integrate as it may break platform-specific code/behavior.

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

Commit messages:
 - Typo
 - A Stage should allow simultaneous iconified and maximized states

Changes: https://git.openjdk.org/jfx/pull/1777/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1777&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354480
  Stats: 110 lines in 3 files changed: 68 ins; 14 del; 28 mod
  Patch: https://git.openjdk.org/jfx/pull/1777.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1777/head:pull/1777

PR: https://git.openjdk.org/jfx/pull/1777

From tsayao at openjdk.org  Sun Apr 13 18:01:08 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 13 Apr 2025 18:01:08 GMT
Subject: RFR: 8354480: A Stage should allow simultaneous iconified and
 maximized states [v2]
In-Reply-To: <XPiErE5T6bPke2M_SuaDQg0--lQgExgBrJ9mgG9azSA=.a190b01b-6888-4d37-8b7f-eab469458e5d@github.com>
References: <XPiErE5T6bPke2M_SuaDQg0--lQgExgBrJ9mgG9azSA=.a190b01b-6888-4d37-8b7f-eab469458e5d@github.com>
Message-ID: <36KV5JUfvFBEQ_fGufXjGqnD6vRxr91CnGH77tC-gSQ=.c89552be-fefd-4975-9b3a-a7c1cf3422e3@github.com>

> On some platforms (at least on Ubuntu 24.04 with GNOME and Windows 11), windows can remain maximized even when they are iconified (minimized). When the window is de-iconified (restored), it retains its maximized state.
> 
> The documentation in `Stage.java` regarding window states seems to align with this behavior. However, the code currently treats the `WindowEvent.RESTORE` event as both an unminimize (de-iconify) and an unmaximize.
> 
> Tests pass on Ubuntu 24.04 XWayland (with one unrelated screenCapture failure). But I would not rely on that since it needes specific tests.
> 
> This is not ready to integrate as it may break platform-specific code/behavior.

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Missed one change

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1777/files
  - new: https://git.openjdk.org/jfx/pull/1777/files/f9313999..ed2c444f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1777&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1777&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1777.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1777/head:pull/1777

PR: https://git.openjdk.org/jfx/pull/1777

From tsayao at openjdk.org  Sun Apr 13 18:07:32 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 13 Apr 2025 18:07:32 GMT
Subject: RFR: 8354480: A Stage should allow simultaneous iconified and
 maximized states [v2]
In-Reply-To: <36KV5JUfvFBEQ_fGufXjGqnD6vRxr91CnGH77tC-gSQ=.c89552be-fefd-4975-9b3a-a7c1cf3422e3@github.com>
References: <XPiErE5T6bPke2M_SuaDQg0--lQgExgBrJ9mgG9azSA=.a190b01b-6888-4d37-8b7f-eab469458e5d@github.com>
 <36KV5JUfvFBEQ_fGufXjGqnD6vRxr91CnGH77tC-gSQ=.c89552be-fefd-4975-9b3a-a7c1cf3422e3@github.com>
Message-ID: <h8tJDKMRALpWShdYximPxNgPv9h6DJlHS7WLVPvbpRY=.7a8baf11-d94c-4623-9cdd-576e46abc277@github.com>

On Sun, 13 Apr 2025 18:01:08 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> On some platforms (at least on Ubuntu 24.04 with GNOME and Windows 11), windows can remain maximized even when they are iconified (minimized). When the window is de-iconified (restored), it retains its maximized state.
>> 
>> The documentation in `Stage.java` regarding window states seems to align with this behavior. However, the code currently treats the `WindowEvent.RESTORE` event as both an unminimize (de-iconify) and an unmaximize.
>> 
>> Tests pass on Ubuntu 24.04 XWayland (with one unrelated screenCapture failure). But I would not rely on that since it needes specific tests.
>> 
>> This is not ready to integrate as it may break platform-specific code/behavior.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed one change

I'm doing the robot tests here (work in progress):
[StageStateTest](https://github.com/openjdk/jfx-sandbox/blob/glass_gtk_bug_squashing/tests/system/src/test/java/test/robot/javafx/stage/StageStatesTest.java)

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

PR Comment: https://git.openjdk.org/jfx/pull/1777#issuecomment-2800056720

From lkostyra at openjdk.org  Mon Apr 14 13:09:36 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 14 Apr 2025 13:09:36 GMT
Subject: RFR: 8354478: Improve StageStyle documentation
In-Reply-To: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>
References: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>
Message-ID: <zj_Vcvx0nOakeWJ6QDm6agQxiN_5EqMYXS_KazAQeuU=.548e228c-1343-4752-b805-39fc8bf8f31a@github.com>

On Sun, 13 Apr 2025 15:24:43 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> Improve StageStyle Documentation
> 
> - Update `StageStyle.UTILITY`:
> Clarified that UTILITY stages may impose platform-specific restrictions on window states, such as preventing maximize, minimize (iconify), and fullscreen operations.
> 
> - Update `StageStyle.UNDECORATED`:
> Improved the description to clarify that although UNDECORATED removes standard window decorations (title bar, borders, and controls), window operations like minimize, maximize, and fullscreen may still be allowed programmatically or via platform-specific functions such as key shortcuts or menu options.
> 
> - Remove mention of solid white background:
> This seems to be not true anymore, even withou a `Scene` (or there's a bug)

Looks good, I think the updated docs are going to be quite helpful.

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

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1776#pullrequestreview-2763791811

From duke at openjdk.org  Mon Apr 14 13:10:05 2025
From: duke at openjdk.org (Gopal Pattnaik)
Date: Mon, 14 Apr 2025 13:10:05 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system
 is busy [v2]
In-Reply-To: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
References: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
Message-ID: <kmWBY2p8XKFmmGuFCf5XmmPLpAbCYbnISTq2EUByTeo=.1f5421b6-130c-403f-9e4a-a1cc2e9789a0@github.com>

> There was a Assertion fail issue in mouse location test case JDK-8296554,
> Reason: We felt the one mili second delay time for the Robot test may be insufficient in few OS.
> Solution: We Changed the delay time to three mili second.
> 
> Verification:
> Tested in Windows 11, and the Assert fail issue is not found.

Gopal Pattnaik has updated the pull request incrementally with one additional commit since the last revision:

  Addressed Review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1772/files
  - new: https://git.openjdk.org/jfx/pull/1772/files/9d5a506e..472b8f8b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1772&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1772&range=00-01

  Stats: 14 lines in 1 file changed: 8 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1772.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1772/head:pull/1772

PR: https://git.openjdk.org/jfx/pull/1772

From duke at openjdk.org  Mon Apr 14 13:10:21 2025
From: duke at openjdk.org (Gopal Pattnaik)
Date: Mon, 14 Apr 2025 13:10:21 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system
 is busy
In-Reply-To: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
References: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
Message-ID: <wg46WLChjxgul8FRfEIJiLqtrVar8smT7iEm5v3TU0g=.97911dd2-9472-4d06-b3a3-69699751e9ce@github.com>

On Fri, 11 Apr 2025 09:37:12 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

> There was a Assertion fail issue in mouse location test case JDK-8296554,
> Reason: We felt the one mili second delay time for the Robot test may be insufficient in few OS.
> Solution: We Changed the delay time to three mili second.
> 
> Verification:
> Tested in Windows 11, and the Assert fail issue is not found.

We may think to check pixels at 10 pixel gap. Each pixel makes the test process busy.

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

PR Comment: https://git.openjdk.org/jfx/pull/1772#issuecomment-2801190475

From kcr at openjdk.org  Mon Apr 14 13:10:30 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 14 Apr 2025 13:10:30 GMT
Subject: Integrated: 8354318: freetype.c: compilation error: 'incompatible
 pointer type' with gcc 14
In-Reply-To: <u5HXreTEcOxM8sbR9D7H8dYSnNigsV3KAksqk1BArKg=.1152df5c-6678-4e2c-9058-b932513f5733@github.com>
References: <u5HXreTEcOxM8sbR9D7H8dYSnNigsV3KAksqk1BArKg=.1152df5c-6678-4e2c-9058-b932513f5733@github.com>
Message-ID: <cUIMtgEeNCtpFHeexstuAdmD8Ub8QkVL_0feRexR6eo=.a2c3d10d-18b7-4956-8193-20b5bd585dae@github.com>

On Thu, 10 Apr 2025 22:41:02 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR fixes a bug where a local variable was declared to be the wrong type, causing an error at compilation time when compiling with gcc 14. gcc 14 rejects assignments of incompatible pointer types without an explicit cast. In this case, the solution is declare the variable to be of the correct type in the first place.

This pull request has now been integrated.

Changeset: 5a897ab7
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/5a897ab7017107471528ab527dac505d2e33aca9
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8354318: freetype.c: compilation error: 'incompatible pointer type' with gcc 14

Reviewed-by: lkostyra

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

PR: https://git.openjdk.org/jfx/pull/1771

From jhendrikx at openjdk.org  Mon Apr 14 13:10:52 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 14 Apr 2025 13:10:52 GMT
Subject: RFR: 8345348: CSS media feature queries [v13]
In-Reply-To: <9U5TJOMXb3oMWWijiRzo0lp7FJZIQPl-PkRJ3Rc-IqA=.959a8ee1-b84e-46ba-8dec-96c2dd7af9aa@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <9U5TJOMXb3oMWWijiRzo0lp7FJZIQPl-PkRJ3Rc-IqA=.959a8ee1-b84e-46ba-8dec-96c2dd7af9aa@github.com>
Message-ID: <DPskwba6n5Lnw-CyzsM8U6zNhBW36cNHwUyGSCT9fcg=.4e1610c2-fd95-4805-b8fa-87c533b6a107@github.com>

On Sun, 13 Apr 2025 17:34:15 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improved implementation of NullCoalescingPropertyBase

A partial review, I didn't look at the tests.

I noticed some non-intuitive equals/hashCode overrides, but found no evidence they're needed to make the non-test code work; if they're only there to make testing more convenient, I really think the overrides should be removed.  In general, IMHO, any equals/hashCode override that doesn't fully test equality (apart from `transient` or derived fields) should be avoided as it will be surprising if such classes are ever used with `equals` or any hash based collection classes.

If there's need for partial equality, then externalize this.

modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PreferenceProperties.java line 246:

> 244:         }
> 245: 
> 246:         public synchronized void fireValueChangedIfNecessary() {

I noticed that you made many methods `synchronized` in this class, but I have trouble seeing why this is.  A short explanation may be in order.

So, if I had to guess: it's possible to change the value override and/or the updating of all properties from a different thread, which is not the FX thread.  However, what guarantees are now given to listeners (if any)?  The value changed events can now also be triggered from any thread, unless wrapped in a `Platform.runLater`.

What I mean here is, let's say I listen on `accentColorProperty` of `Platform.Preferences`, on what thread can the change event happen?  The `Platform.Preferences` class does not mention anything special, so I think it is fair to assume it should be on the FX thread, allowing me to make modifications to an active scene graph in my change handler; however that will fail if the change notification was not triggered from the FX thread.

modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaRule.java line 129:

> 127:     public int hashCode() {
> 128:         return hash;
> 129:     }

You're basically saying here that a media rule with or without parent but the same queries is the same.  However, parent is taken into account while writing/reading and evaluating.  I think this deserves a justification.

modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/expression/FunctionExpression.java line 72:

> 70:     public String toString() {
> 71:         return "(" + (featureValue != null ? featureName + ": " + featureValue : featureName) + ")";
> 72:     }

It's really unusual to override these methods in a record.  What reason do you have for excluding the function from equals/hashCode ?  What does it mean when all fields match but a different function is used?  Where is equality used?

modules/javafx.graphics/src/main/java/com/sun/javafx/css/parser/TokenStream.java line 31:

> 29: import java.util.function.Predicate;
> 30: 
> 31: public final class TokenStream {

I think the naming of the methods in this class leaves something to be desired.

- `Token consume()` **OK**
- `Token consume(Predicate)` -> `consumeIf` or `consumeIfMatches`
    Makes it clearer, as `consume` seems to imply something is always consumed (ie. it still skips one token if the predicate didn't match returning `null`).
- `Token peek()` **OK**
- `reconsume` -> `unconsume`, `undoConsume`, `undo`, `previous`, `resetToPrevious`, `decrementIndex`
    Nothing is consumed which reconsume seems to imply, instead it moves the index back one place so the next call to `consume` may indeed reconsume a token; reconsume as-is would do nothing (and if it returned anything it would be same the as `current`.
- `boolean peekMany(Predicate...)` -> `matches`
    It doesn't work like `peek`.  `peekMany` would imply it returns a `List<Token>`; it also doesn't convey that it returns a `boolean`.
- `reset(int)` -> `setIndex`
    This seems to be similar to what say `InputStream` provides, but `InputStream` hides the `index` parameter so you can't set it to some arbitrary value (like skipping ahead).  If you want to mimic this pattern, I'd suggest removing the parameter and providing a `mark` method (or make it non-public).

modules/javafx.graphics/src/main/java/javafx/css/Rule.java line 64:

> 62:     private final MediaRule mediaRule;
> 63: 
> 64:     private List<Selector> selectors = null;

I dislike the accessor pattern somewhat; I wonder, would it be possible to:

- Make `Rule` sealed: `public abstract sealed class Rule permits InternalRule` (*) similar to how this was done for `Selector`: `public abstract sealed class Selector permits SimpleSelector, CompoundSelector`
- `InternalRule` would not be public API, and can therefore introduce a public method to get `MediaRule`
- `Rule` does not have a public constructor, so IMHO there's no risk in there ever being an instance of `Rule` directly (similar reasoning was used to when the `SimpleSelector` / `CompountSelector` refactoring was done).

This way getting access to the `getMediaRule` method is just a simple `instanceof` check away:

     MediaRule rule = rule instanceof InternalRule ir ? ir.getMediaRule() : null;

(*) `InternalRule` is just a place holder name

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

PR Review: https://git.openjdk.org/jfx/pull/1655#pullrequestreview-2763805568
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2041819506
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2041903462
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2041884462
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2041936819
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2041960550

From mstrauss at openjdk.org  Mon Apr 14 13:11:06 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 14 Apr 2025 13:11:06 GMT
Subject: RFR: 8345348: CSS media feature queries [v13]
In-Reply-To: <DPskwba6n5Lnw-CyzsM8U6zNhBW36cNHwUyGSCT9fcg=.4e1610c2-fd95-4805-b8fa-87c533b6a107@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <9U5TJOMXb3oMWWijiRzo0lp7FJZIQPl-PkRJ3Rc-IqA=.959a8ee1-b84e-46ba-8dec-96c2dd7af9aa@github.com>
 <DPskwba6n5Lnw-CyzsM8U6zNhBW36cNHwUyGSCT9fcg=.4e1610c2-fd95-4805-b8fa-87c533b6a107@github.com>
Message-ID: <jlPI_eqMSiPEkFIxt11ZWnW9Qpw6QdKuJamw7wtqhdo=.06f3a435-629b-4d5b-8ee1-ab54bdd913f7@github.com>

On Mon, 14 Apr 2025 09:56:43 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improved implementation of NullCoalescingPropertyBase
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PreferenceProperties.java line 246:
> 
>> 244:         }
>> 245: 
>> 246:         public synchronized void fireValueChangedIfNecessary() {
> 
> I noticed that you made many methods `synchronized` in this class, but I have trouble seeing why this is.  A short explanation may be in order.
> 
> So, if I had to guess: it's possible to change the value override and/or the updating of all properties from a different thread, which is not the FX thread.  However, what guarantees are now given to listeners (if any)?  The value changed events can now also be triggered from any thread, unless wrapped in a `Platform.runLater`.
> 
> What I mean here is, let's say I listen on `accentColorProperty` of `Platform.Preferences`, on what thread can the change event happen?  The `Platform.Preferences` class does not mention anything special, so I think it is fair to assume it should be on the FX thread, allowing me to make modifications to an active scene graph in my change handler; however that will fail if the change notification was not triggered from the FX thread.

Platform preference change events always happen on the FX thread. The reason for `synchronized` is as follows:

A `Scene` can be created on any thread as per spec. When the scene is created, the `ScenePreferences` class and its associated properties are instantiated, which in turn subscribe internally to the `Platform.Preferences` properties. The synchronization is to protect the addition and removal of listeners.

This is not ideal, though. As soon as we're subscribed to `Platform.Preferences`, the `Scene.Preferences` can receive change notifications on the FX thread, which interferes with the mandated capability to be created on any thread.

I think we have a few options here:
1. Don't subscribe scene preferences to platform preferences until the scene is shown. The downside of this is that we don't know the actual values of the preferences up until that point.
2. With limited synchronization, fetch the current preference values from the platform when the scene is created, but don't subscribe to change notifications until the scene is shown.
3. Specify that scene preference changes can happen on the FX thread, even when the scene is created in a background thread.

> modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaRule.java line 129:
> 
>> 127:     public int hashCode() {
>> 128:         return hash;
>> 129:     }
> 
> You're basically saying here that a media rule with or without parent but the same queries is the same.  However, parent is taken into account while writing/reading and evaluating.  I think this deserves a justification.

I might just remove `equals()`/`hashCode()`, because the class is not used in a way where equality would be relevant.

> modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/expression/FunctionExpression.java line 72:
> 
>> 70:     public String toString() {
>> 71:         return "(" + (featureValue != null ? featureName + ": " + featureValue : featureName) + ")";
>> 72:     }
> 
> It's really unusual to override these methods in a record.  What reason do you have for excluding the function from equals/hashCode ?  What does it mean when all fields match but a different function is used?  Where is equality used?

The expression is entirely defined by `featureName`, `featureValue`, and `value`. Since the associated function is usually a method reference, it won't equal other method references (even though the referenced method is the same). There's no point in equating different method references of the same method because this just means that no two expressions are ever equal.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2042064946
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2042084919
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2042073727

From jhendrikx at openjdk.org  Mon Apr 14 13:32:54 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 14 Apr 2025 13:32:54 GMT
Subject: RFR: 8354478: Improve StageStyle documentation
In-Reply-To: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>
References: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>
Message-ID: <KcL0VporvxQ0C_yORYJbnfuK80sG0LfX2z5YNbFyQ1o=.8a7e9cac-1d90-4a93-ba2c-845deee6b718@github.com>

On Sun, 13 Apr 2025 15:24:43 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> Improve StageStyle Documentation
> 
> - Update `StageStyle.UTILITY`:
> Clarified that UTILITY stages may impose platform-specific restrictions on window states, such as preventing maximize, minimize (iconify), and fullscreen operations.
> 
> - Update `StageStyle.UNDECORATED`:
> Improved the description to clarify that although UNDECORATED removes standard window decorations (title bar, borders, and controls), window operations like minimize, maximize, and fullscreen may still be allowed programmatically or via platform-specific functions such as key shortcuts or menu options.
> 
> - Remove mention of solid white background:
> This seems to be not true anymore, even withou a `Scene` (or there's a bug)

modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java line 44:

> 42:      * This style allows window operations such as resize, minimize, maximize
> 43:      * and fullscreen to be either programmatically controlled or achieved through
> 44:      * platform-specific functions, such as key shortcuts or menu options.

It looks like you intend the 2nd part to be a new paragraph:
Suggestion:

     * Defines a {@code Stage} style with no window decorations, such as a title bar,
     * borders, or window controls.
     * <p>
     * This style allows window operations such as resize, minimize, maximize
     * and fullscreen to be either programmatically controlled or achieved through
     * platform-specific functions, such as key shortcuts or menu options.

modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java line 62:

> 60:      * Utility stages may restrict window operations like maximize, minimize,
> 61:      * and fullscreen depending on the platform. They are designed to float above
> 62:      * primary windows without acting as a main application stage.

Suggestion:

     * Defines a lightweight {@code Stage} with minimal decorations, intended for
     * supporting tasks such as tool palettes.
     * <p>
     * Utility stages may restrict window operations like maximize, minimize,
     * and fullscreen depending on the platform. They are designed to float above
     * primary windows without acting as a main application stage.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1776#discussion_r2042142761
PR Review Comment: https://git.openjdk.org/jfx/pull/1776#discussion_r2042143396

From angorya at openjdk.org  Mon Apr 14 14:39:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 14 Apr 2025 14:39:01 GMT
Subject: RFR: 8354478: Improve StageStyle documentation
In-Reply-To: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>
References: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>
Message-ID: <dRW2oV9Sug2CiRc1-29EjBri41tNraNHKBHykVOHnag=.3d284b91-6b55-4fa2-9e61-3d2bca99254d@github.com>

On Sun, 13 Apr 2025 15:24:43 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> Improve StageStyle Documentation
> 
> - Update `StageStyle.UTILITY`:
> Clarified that UTILITY stages may impose platform-specific restrictions on window states, such as preventing maximize, minimize (iconify), and fullscreen operations.
> 
> - Update `StageStyle.UNDECORATED`:
> Improved the description to clarify that although UNDECORATED removes standard window decorations (title bar, borders, and controls), window operations like minimize, maximize, and fullscreen may still be allowed programmatically or via platform-specific functions such as key shortcuts or menu options.
> 
> - Remove mention of solid white background:
> This seems to be not true anymore, even withou a `Scene` (or there's a bug)

modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java line 35:

> 33: 
> 34:     /**
> 35:      * Defines a normal {@code Stage} style with a solid background and platform decorations.

Should we say the background color is platform-specific, or perhaps identify why it is different?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1776#discussion_r2042288984

From angorya at openjdk.org  Mon Apr 14 14:39:02 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 14 Apr 2025 14:39:02 GMT
Subject: RFR: 8354478: Improve StageStyle documentation
In-Reply-To: <KcL0VporvxQ0C_yORYJbnfuK80sG0LfX2z5YNbFyQ1o=.8a7e9cac-1d90-4a93-ba2c-845deee6b718@github.com>
References: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>
 <KcL0VporvxQ0C_yORYJbnfuK80sG0LfX2z5YNbFyQ1o=.8a7e9cac-1d90-4a93-ba2c-845deee6b718@github.com>
Message-ID: <OvPlHu_-7azkjxBtbc311XhldIG3xtRbSJWEiJLbSL0=.4430e9cb-7488-4700-b073-8dca2744e449@github.com>

On Mon, 14 Apr 2025 13:29:08 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Improve StageStyle Documentation
>> 
>> - Update `StageStyle.UTILITY`:
>> Clarified that UTILITY stages may impose platform-specific restrictions on window states, such as preventing maximize, minimize (iconify), and fullscreen operations.
>> 
>> - Update `StageStyle.UNDECORATED`:
>> Improved the description to clarify that although UNDECORATED removes standard window decorations (title bar, borders, and controls), window operations like minimize, maximize, and fullscreen may still be allowed programmatically or via platform-specific functions such as key shortcuts or menu options.
>> 
>> - Remove mention of solid white background:
>> This seems to be not true anymore, even withou a `Scene` (or there's a bug)
>
> modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java line 44:
> 
>> 42:      * This style allows window operations such as resize, minimize, maximize
>> 43:      * and fullscreen to be either programmatically controlled or achieved through
>> 44:      * platform-specific functions, such as key shortcuts or menu options.
> 
> It looks like you intend the 2nd part to be a new paragraph:
> Suggestion:
> 
>      * Defines a {@code Stage} style with no window decorations, such as a title bar,
>      * borders, or window controls.
>      * <p>
>      * This style allows window operations such as resize, minimize, maximize
>      * and fullscreen to be either programmatically controlled or achieved through
>      * platform-specific functions, such as key shortcuts or menu options.

+1

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1776#discussion_r2042286028

From mstrauss at openjdk.org  Mon Apr 14 14:39:26 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 14 Apr 2025 14:39:26 GMT
Subject: RFR: 8345348: CSS media feature queries [v14]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <RUn3B7J9bqZrECsufh4z5hVnCjSvOpT2CZY5GJtcwyU=.d9da2fa2-d57d-46ef-8869-204bdbb62bdb@github.com>

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  rename TokenStream methods

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/b5bfc603..be17d367

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=13
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=12-13

  Stats: 25 lines in 2 files changed: 1 ins; 9 del; 15 mod
  Patch: https://git.openjdk.org/jfx/pull/1655.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655

PR: https://git.openjdk.org/jfx/pull/1655

From mstrauss at openjdk.org  Mon Apr 14 14:39:27 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 14 Apr 2025 14:39:27 GMT
Subject: RFR: 8345348: CSS media feature queries [v13]
In-Reply-To: <DPskwba6n5Lnw-CyzsM8U6zNhBW36cNHwUyGSCT9fcg=.4e1610c2-fd95-4805-b8fa-87c533b6a107@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <9U5TJOMXb3oMWWijiRzo0lp7FJZIQPl-PkRJ3Rc-IqA=.959a8ee1-b84e-46ba-8dec-96c2dd7af9aa@github.com>
 <DPskwba6n5Lnw-CyzsM8U6zNhBW36cNHwUyGSCT9fcg=.4e1610c2-fd95-4805-b8fa-87c533b6a107@github.com>
Message-ID: <UreUbbVGeLql5D-N6D09-8_O-w6sFUJCza2QrGSmco8=.7e34cb01-4818-43f7-967c-f47e2dcb8b0a@github.com>

On Mon, 14 Apr 2025 11:18:29 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improved implementation of NullCoalescingPropertyBase
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/css/parser/TokenStream.java line 31:
> 
>> 29: import java.util.function.Predicate;
>> 30: 
>> 31: public final class TokenStream {
> 
> I think the naming of the methods in this class leaves something to be desired.
> 
> - `Token consume()` **OK**
> - `Token consume(Predicate)` -> `consumeIf` or `consumeIfMatches`
>     Makes it clearer, as `consume` seems to imply something is always consumed (ie. it still skips one token if the predicate didn't match returning `null`).
> - `Token peek()` **OK**
> - `reconsume` -> `unconsume`, `undoConsume`, `undo`, `previous`, `resetToPrevious`, `decrementIndex`
>     Nothing is consumed which reconsume seems to imply, instead it moves the index back one place so the next call to `consume` may indeed reconsume a token; reconsume as-is would do nothing (and if it returned anything it would be same the as `current`.
> - `boolean peekMany(Predicate...)` -> `matches`
>     It doesn't work like `peek`.  `peekMany` would imply it returns a `List<Token>`; it also doesn't convey that it returns a `boolean`.
> - `reset(int)` -> `setIndex`
>     This seems to be similar to what say `InputStream` provides, but `InputStream` hides the `index` parameter so you can't set it to some arbitrary value (like skipping ahead).  If you want to mimic this pattern, I'd suggest removing the parameter and providing a `mark` method (or make it non-public).

I renamed `consume(Predicate)` to `consumeIf(Predicate)`, and `peekMany(Predicate...)` to `matches(Predicate...)`.

`index()` and `reset()` don't need to be public, so I've removed that (also I don't want to mimic the problematic mark/reset pattern of `InputStream`).

`reconsume` is [CSS lingo](https://www.w3.org/TR/css-syntax-3/#tokenizer-definitions), I'm keeping that as-is.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2042287057

From nlisker at openjdk.org  Mon Apr 14 14:43:53 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Mon, 14 Apr 2025 14:43:53 GMT
Subject: RFR: 8354478: Improve StageStyle documentation
In-Reply-To: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>
References: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>
Message-ID: <fiBLtygZIgceCJD0YffH1g5YvrsjVMQIZwgwQjnu5No=.ed343c2e-c90c-48c5-9e1b-be3bb7c2e684@github.com>

On Sun, 13 Apr 2025 15:24:43 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> Improve StageStyle Documentation
> 
> - Update `StageStyle.UTILITY`:
> Clarified that UTILITY stages may impose platform-specific restrictions on window states, such as preventing maximize, minimize (iconify), and fullscreen operations.
> 
> - Update `StageStyle.UNDECORATED`:
> Improved the description to clarify that although UNDECORATED removes standard window decorations (title bar, borders, and controls), window operations like minimize, maximize, and fullscreen may still be allowed programmatically or via platform-specific functions such as key shortcuts or menu options.
> 
> - Remove mention of solid white background:
> This seems to be not true anymore, even withou a `Scene` (or there's a bug)

modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java line 58:

> 56: 
> 57:     /**
> 58:      * Defines a lightweight {@code Stage} with minimal decorations, intended for

Is there a reason you removed use the word "style" here? The other ones use it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1776#discussion_r2042302384

From mstrauss at openjdk.org  Mon Apr 14 14:46:30 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 14 Apr 2025 14:46:30 GMT
Subject: RFR: 8345348: CSS media feature queries [v15]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <kKekRd0is-h0wEUtPGoBdAdJTDz3FSQR82t8_z4sULc=.67608044-955e-480e-82a4-41f14a2778b7@github.com>

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  use equality instead of identity

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/be17d367..7bedd63f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=14
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=13-14

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1655.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655

PR: https://git.openjdk.org/jfx/pull/1655

From angorya at openjdk.org  Mon Apr 14 15:13:15 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 14 Apr 2025 15:13:15 GMT
Subject: RFR: 8354480: A Stage should allow simultaneous iconified and
 maximized states [v2]
In-Reply-To: <36KV5JUfvFBEQ_fGufXjGqnD6vRxr91CnGH77tC-gSQ=.c89552be-fefd-4975-9b3a-a7c1cf3422e3@github.com>
References: <XPiErE5T6bPke2M_SuaDQg0--lQgExgBrJ9mgG9azSA=.a190b01b-6888-4d37-8b7f-eab469458e5d@github.com>
 <36KV5JUfvFBEQ_fGufXjGqnD6vRxr91CnGH77tC-gSQ=.c89552be-fefd-4975-9b3a-a7c1cf3422e3@github.com>
Message-ID: <a-S0VTCLaxQ_LKc9l3PiP5srdBqrmjlmHw9FZLA0IYc=.a41c850b-2399-49e1-b444-90a3b422f9d7@github.com>

On Sun, 13 Apr 2025 18:01:08 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> On some platforms (at least on Ubuntu 24.04 with GNOME and Windows 11), windows can remain maximized even when they are iconified (minimized). When the window is de-iconified (restored), it retains its maximized state.
>> 
>> The documentation in `Stage.java` regarding window states seems to align with this behavior. However, the code currently treats the `WindowEvent.RESTORE` event as both an unminimize (de-iconify) and an unmaximize.
>> 
>> Tests pass on Ubuntu 24.04 XWayland (with one unrelated screenCapture failure). But I would not rely on that since it needes specific tests.
>> 
>> This is not ready to integrate as it may break platform-specific code/behavior.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed one change

modules/javafx.graphics/src/main/java/com/sun/glass/events/WindowEvent.java line 43:

> 41:      * and {@link #UNMINIMIZE}.
> 42:      */
> 43:     @Deprecated

I am curious: what would be the benefit of deprecating, as opposed to redefining?
Is there a possibility of a mismatch between the java code and the native?

modules/javafx.graphics/src/main/java/com/sun/glass/events/WindowEvent.java line 76:

> 74:             case WindowEvent.FOCUS_DISABLED -> "FOCUS_DISABLED";
> 75:             case WindowEvent.FOCUS_UNGRAB -> "FOCUS_UNGRAB";
> 76:             default -> "UNKNOWN";

Just wanted to share, I usually do `"?" + eventType`, or in this case it might be `"UNKNOWN?" + eventType`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1777#discussion_r2042350561
PR Review Comment: https://git.openjdk.org/jfx/pull/1777#discussion_r2042353363

From tsayao at openjdk.org  Mon Apr 14 15:13:19 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 14 Apr 2025 15:13:19 GMT
Subject: RFR: 8354478: Improve StageStyle documentation [v2]
In-Reply-To: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>
References: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>
Message-ID: <sqq9mswghBpOYptKll0GcDovdBaY-26A2GDtmAWLFcY=.325c2656-6148-4e7b-b78c-1e572a590566@github.com>

> Improve StageStyle Documentation
> 
> - Update `StageStyle.UTILITY`:
> Clarified that UTILITY stages may impose platform-specific restrictions on window states, such as preventing maximize, minimize (iconify), and fullscreen operations.
> 
> - Update `StageStyle.UNDECORATED`:
> Improved the description to clarify that although UNDECORATED removes standard window decorations (title bar, borders, and controls), window operations like minimize, maximize, and fullscreen may still be allowed programmatically or via platform-specific functions such as key shortcuts or menu options.
> 
> - Remove mention of solid white background:
> This seems to be not true anymore, even withou a `Scene` (or there's a bug)

Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:

 - Add "style" ib the UTILITY style like the others
 - Update modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java
   
   Co-authored-by: John Hendrikx <john.hendrikx+github at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1776/files
  - new: https://git.openjdk.org/jfx/pull/1776/files/21792071..88307f0d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1776&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1776&range=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1776.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1776/head:pull/1776

PR: https://git.openjdk.org/jfx/pull/1776

From tsayao at openjdk.org  Mon Apr 14 15:22:02 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 14 Apr 2025 15:22:02 GMT
Subject: RFR: 8354480: A Stage should allow simultaneous iconified and
 maximized states [v2]
In-Reply-To: <a-S0VTCLaxQ_LKc9l3PiP5srdBqrmjlmHw9FZLA0IYc=.a41c850b-2399-49e1-b444-90a3b422f9d7@github.com>
References: <XPiErE5T6bPke2M_SuaDQg0--lQgExgBrJ9mgG9azSA=.a190b01b-6888-4d37-8b7f-eab469458e5d@github.com>
 <36KV5JUfvFBEQ_fGufXjGqnD6vRxr91CnGH77tC-gSQ=.c89552be-fefd-4975-9b3a-a7c1cf3422e3@github.com>
 <a-S0VTCLaxQ_LKc9l3PiP5srdBqrmjlmHw9FZLA0IYc=.a41c850b-2399-49e1-b444-90a3b422f9d7@github.com>
Message-ID: <DwvhicnkWs6FTM2bpawkpJVAugMnvbmrFo1ZXpQCAdE=.8bf636ab-5e93-4cfc-a713-e10c3626748b@github.com>

On Mon, 14 Apr 2025 15:06:15 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missed one change
>
> modules/javafx.graphics/src/main/java/com/sun/glass/events/WindowEvent.java line 43:
> 
>> 41:      * and {@link #UNMINIMIZE}.
>> 42:      */
>> 43:     @Deprecated
> 
> I am curious: what would be the benefit of deprecating, as opposed to redefining?
> Is there a possibility of a mismatch between the java code and the native?

My idea is to update all platforms for consistency and eventually remove it, since it's for internal use.

I think this area might be broken on native code and it'll need some update.

This branch has this change as well as I'm fixing native Linux glass code to cope with it:
https://github.com/openjdk/jfx-sandbox/tree/glass_gtk_bug_squashing

This test (on the branch) does some mixing of States:
`gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests StageStatesTest`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1777#discussion_r2042376280

From tsayao at openjdk.org  Mon Apr 14 15:33:11 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 14 Apr 2025 15:33:11 GMT
Subject: RFR: 8354480: A Stage should allow simultaneous iconified and
 maximized states [v2]
In-Reply-To: <a-S0VTCLaxQ_LKc9l3PiP5srdBqrmjlmHw9FZLA0IYc=.a41c850b-2399-49e1-b444-90a3b422f9d7@github.com>
References: <XPiErE5T6bPke2M_SuaDQg0--lQgExgBrJ9mgG9azSA=.a190b01b-6888-4d37-8b7f-eab469458e5d@github.com>
 <36KV5JUfvFBEQ_fGufXjGqnD6vRxr91CnGH77tC-gSQ=.c89552be-fefd-4975-9b3a-a7c1cf3422e3@github.com>
 <a-S0VTCLaxQ_LKc9l3PiP5srdBqrmjlmHw9FZLA0IYc=.a41c850b-2399-49e1-b444-90a3b422f9d7@github.com>
Message-ID: <eV2jB1lA0pd3aKpjYPYqUL6U7P6XAyyFdcPPLSbwvCA=.8e7b6cc0-8eb1-410a-8a40-875f04a5e805@github.com>

On Mon, 14 Apr 2025 15:07:52 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missed one change
>
> modules/javafx.graphics/src/main/java/com/sun/glass/events/WindowEvent.java line 76:
> 
>> 74:             case WindowEvent.FOCUS_DISABLED -> "FOCUS_DISABLED";
>> 75:             case WindowEvent.FOCUS_UNGRAB -> "FOCUS_UNGRAB";
>> 76:             default -> "UNKNOWN";
> 
> Just wanted to share, I usually do `"?" + eventType`, or in this case it might be `"UNKNOWN?" + eventType`.

Makes sense, but I think most reviewers would say it's an unrelated change as ask to rollback :)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1777#discussion_r2042402111

From martinfox656 at gmail.com  Mon Apr 14 15:34:02 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Mon, 14 Apr 2025 08:34:02 -0700
Subject: Menu keyboard shortcuts not working anymore
In-Reply-To: <1fc37296-c21a-4780-bc80-09196edadbe1@itarchitects.at>
References: <1fc37296-c21a-4780-bc80-09196edadbe1@itarchitects.at>
Message-ID: <35BB96ED-4FA7-430B-89B7-A026878BB5D0@gmail.com>

Clemens,

Thanks for reporting this. I did some testing and I think I?ve reproduced the problem. What I?m seeing is specific to the Mac; when the focus is in a ComboBox, DatePicker, or Spinner the user can?t use Cmd+Q to quit the app. This also affects other menu items if you?re using the system menu bar. I understand what?s going on and will enter a bug report.

That?s not quite what you?re describing so perhaps there?s more than one issue. If you have further details or a reproducible test case please send them on and I?ll look into it.

Thanks again,
Martin

> On Apr 11, 2025, at 1:10?PM, Clemens Lanthaler <clemens.lanthaler at itarchitects.at> wrote:
> 
> I have just updated my Photoslide App to Javafx24.
> 
> What is no longer working is keyboard shortcuts defined in the main menu if the focus is inside of a control inside a pane. It seems that the pane is consumeing the event. If the focus is on the main windows than the shortcuts are working again.
> As a workaround I have now registered all shortcuts as eventfilter on the scene. But for new developers I think they are wondering why a menu shortcut is not alywas working.
> 
> Clemens
> 
> -- 
> ITArchitects
> CEO: B.Sc. Clemens Lanthaler
> Forchachstrasse 3
> A-6166 Fulpmes
> Tel.: +43 (0)650 855 2954
> email: office at itarchitects.at
> homepage: http://www.itarchitects.at
> -------------------------------------------------
> Notice: This e-mail and any attachments are confidential and may be privileged.
> If you are not the intended recipient, notify the sender immediately, destroy all
> copies from your system and do not disclose or use the information for any purpose.
> Diese E-Mail inklusive aller Anhaenge ist vertraulich und koennte bevorrechtigtem
> Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind, informieren Sie
> bitte den Absender unverzueglich, loeschen Sie alle Kopien von Ihrem System und
> veroeffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck.
> 
> <OpenPGP_0x94A919BE276C7EA1.asc>


From john.hendrikx at gmail.com  Mon Apr 14 15:56:37 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Mon, 14 Apr 2025 17:56:37 +0200
Subject: Unnecessary layouts; TLDR; new method "requestLocalLayout"
Message-ID: <3fa155b2-2709-4529-898a-79003efaedfb@gmail.com>

I've been writing a container that does layout, and I've been using it
extensively in my latest project.

I noticed that many skins and controls will call requestLayout(), not
realizing that this will mark the current node + all parent nodes with
`NEEDS_LAYOUT`.? This causes all those containers to call `compute`
methods and execute their `layoutChildren`, even though your control may
only have changed something that does NOT change its layout bounds (like
a color, background, alignment or even things like a cursor shape or
position).? These computations are expensive, involving querying of all
children of each container to find out their min/pref/max sizes, do
content bias calculations, splitting space over each control and many
many snapXYZ calls -- all leading to no visual layout change...

For example, a TextArea or TextField will call requestLayout on every
character typed, every cursor movement, and every text content change.?
None of those affects their bounds (at least, in my experience, these
controls are not continuously resizing themselves when I scroll or type
things...).? TextField will even change its cursor shape every time its
value is updated, even if that value is simply bound to a Slider and the
field doesn't have focus at all -- this field will then trigger layout
on itself and all its ancestors even if it is in a completely unrelated
area of the UI (not close to the slider).

It seems that in many cases these controls and skins just want their
layoutChildren method to be called, as their main layout logic is
located there -- duplicating this logic partially for every minor
property change that doesn't affect its bounds is error prone, so I can
completely follow this reasoning.? However, using requestLayout to get
layoutChildren called is very expensive.

There is a better way: call setNeedsLayout(true) -- this is a protected
method that any Node has access to, and basically will only call
layoutChildren on your own Node.? It marks all the parent nodes as
`DIRTY_BRANCH`, which means that on a layout pass it will traverse down
to see which nodes actually needs layout (it won't call layoutChildren
for each ancestor, which is a big win).

Because of its protected nature (and its required parameter which must
be true), it is a bit hard to use.? I'm thinking it might be a good idea
to introduce a new method here, a request layout call that schedules a
Node for layout without forcing all ancestors to do the same. This way
Skin and Control designers can clearly see the two options and choose
what is required:

???? requestLayout -- my bounds likely have changed (font change,
border/padding change, spacing change), so please call compute methods
and redo the entire layout

???? requestLocalLayout -- my bounds have not changed (color changes,
background changes, content changes within a ScrollPane, cursor changes,
cursor position changes, alignment changes)

What do you think?

--John




From nlisker at openjdk.org  Mon Apr 14 16:02:50 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Mon, 14 Apr 2025 16:02:50 GMT
Subject: RFR: 8354478: Improve StageStyle documentation [v2]
In-Reply-To: <sqq9mswghBpOYptKll0GcDovdBaY-26A2GDtmAWLFcY=.325c2656-6148-4e7b-b78c-1e572a590566@github.com>
References: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>
 <sqq9mswghBpOYptKll0GcDovdBaY-26A2GDtmAWLFcY=.325c2656-6148-4e7b-b78c-1e572a590566@github.com>
Message-ID: <AFSdq3lG6D7OEGI-KvcuCu_NBZQa5yNpSu4edSPyerg=.8616a1ab-64de-4c9d-8042-77b6d82c171d@github.com>

On Mon, 14 Apr 2025 15:13:19 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Improve StageStyle Documentation
>> 
>> - Update `StageStyle.UTILITY`:
>> Clarified that UTILITY stages may impose platform-specific restrictions on window states, such as preventing maximize, minimize (iconify), and fullscreen operations.
>> 
>> - Update `StageStyle.UNDECORATED`:
>> Improved the description to clarify that although UNDECORATED removes standard window decorations (title bar, borders, and controls), window operations like minimize, maximize, and fullscreen may still be allowed programmatically or via platform-specific functions such as key shortcuts or menu options.
>> 
>> - Remove mention of solid white background:
>> This seems to be not true anymore, even withou a `Scene` (or there's a bug)
>
> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add "style" ib the UTILITY style like the others
>  - Update modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java
>    
>    Co-authored-by: John Hendrikx <john.hendrikx+github at gmail.com>

modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java line 41:

> 39:     /**
> 40:      * Defines a {@code Stage} style with no window decorations, such as a title bar,
> 41:      * borders, or window controls.

Any particular reason you removed "a solid background" like `DECORATED` has? The previous docs give that detail.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1776#discussion_r2042453858

From kcr at openjdk.org  Mon Apr 14 16:05:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 14 Apr 2025 16:05:52 GMT
Subject: [jfx24u] RFR: 8354182: Create release notes for JavaFX 24.0.1
In-Reply-To: <wWrn0MNNgD9xJ9yXYG6fXgk5YOBcXLl5qwvXA5c5T5M=.339e7c61-705c-4e34-b6f9-f6783c1e3eb8@github.com>
References: <wWrn0MNNgD9xJ9yXYG6fXgk5YOBcXLl5qwvXA5c5T5M=.339e7c61-705c-4e34-b6f9-f6783c1e3eb8@github.com>
Message-ID: <t389rCNIRVNvPdB_87yHgGrBHV4YgBtKRoESfeD39xw=.290dc446-dd5b-4767-a743-6cba3742be0f@github.com>

On Wed, 9 Apr 2025 23:17:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Release notes for JavaFX 24.0.1.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=47358
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=47357
> 
> As usual, I excluded test bugs, cleanup bugs, etc.
> 
> NOTE: Once the CPU release ships on 2025-04-15, I will add any security bugs and ask for a re-review.

@arapte will be the second reviewer

@tiainen or @abhinayagarwal : Do either of you have any comments?

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

PR Comment: https://git.openjdk.org/jfx24u/pull/19#issuecomment-2802191473

From angorya at openjdk.org  Mon Apr 14 16:17:50 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 14 Apr 2025 16:17:50 GMT
Subject: RFR: 8354480: A Stage should allow simultaneous iconified and
 maximized states [v2]
In-Reply-To: <eV2jB1lA0pd3aKpjYPYqUL6U7P6XAyyFdcPPLSbwvCA=.8e7b6cc0-8eb1-410a-8a40-875f04a5e805@github.com>
References: <XPiErE5T6bPke2M_SuaDQg0--lQgExgBrJ9mgG9azSA=.a190b01b-6888-4d37-8b7f-eab469458e5d@github.com>
 <36KV5JUfvFBEQ_fGufXjGqnD6vRxr91CnGH77tC-gSQ=.c89552be-fefd-4975-9b3a-a7c1cf3422e3@github.com>
 <a-S0VTCLaxQ_LKc9l3PiP5srdBqrmjlmHw9FZLA0IYc=.a41c850b-2399-49e1-b444-90a3b422f9d7@github.com>
 <eV2jB1lA0pd3aKpjYPYqUL6U7P6XAyyFdcPPLSbwvCA=.8e7b6cc0-8eb1-410a-8a40-875f04a5e805@github.com>
Message-ID: <9D8kTKaPyF_NoC7Y40UbDBUExsRzUx8CuJNYx6uNtW0=.cd1ea545-2175-43a0-a386-844ff49cdafd@github.com>

On Mon, 14 Apr 2025 15:30:16 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/events/WindowEvent.java line 76:
>> 
>>> 74:             case WindowEvent.FOCUS_DISABLED -> "FOCUS_DISABLED";
>>> 75:             case WindowEvent.FOCUS_UNGRAB -> "FOCUS_UNGRAB";
>>> 76:             default -> "UNKNOWN";
>> 
>> Just wanted to share, I usually do `"?" + eventType`, or in this case it might be `"UNKNOWN?" + eventType`.
>
> Makes sense, but I think most reviewers would say it's an unrelated change as ask to rollback :)

exactly, I am not asking for this change.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1777#discussion_r2042477769

From angorya at openjdk.org  Mon Apr 14 16:22:51 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 14 Apr 2025 16:22:51 GMT
Subject: RFR: 8354480: A Stage should allow simultaneous iconified and
 maximized states [v2]
In-Reply-To: <DwvhicnkWs6FTM2bpawkpJVAugMnvbmrFo1ZXpQCAdE=.8bf636ab-5e93-4cfc-a713-e10c3626748b@github.com>
References: <XPiErE5T6bPke2M_SuaDQg0--lQgExgBrJ9mgG9azSA=.a190b01b-6888-4d37-8b7f-eab469458e5d@github.com>
 <36KV5JUfvFBEQ_fGufXjGqnD6vRxr91CnGH77tC-gSQ=.c89552be-fefd-4975-9b3a-a7c1cf3422e3@github.com>
 <a-S0VTCLaxQ_LKc9l3PiP5srdBqrmjlmHw9FZLA0IYc=.a41c850b-2399-49e1-b444-90a3b422f9d7@github.com>
 <DwvhicnkWs6FTM2bpawkpJVAugMnvbmrFo1ZXpQCAdE=.8bf636ab-5e93-4cfc-a713-e10c3626748b@github.com>
Message-ID: <6sGkSuJZoLbareU7Z_vfTaV2kXUQGUxuP__ZxkQA5Aw=.c522bf8f-f02b-4431-a88a-a1ea36f63f63@github.com>

On Mon, 14 Apr 2025 15:19:01 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/events/WindowEvent.java line 43:
>> 
>>> 41:      * and {@link #UNMINIMIZE}.
>>> 42:      */
>>> 43:     @Deprecated
>> 
>> I am curious: what would be the benefit of deprecating, as opposed to redefining?
>> Is there a possibility of a mismatch between the java code and the native?
>
> My idea is to update all platforms for consistency and eventually remove it, since it's for internal use.
> 
> I think this area might be broken on native code and it'll need some update.
> 
> This branch has this change as well as I'm fixing native Linux glass code to cope with it:
> https://github.com/openjdk/jfx-sandbox/tree/glass_gtk_bug_squashing
> 
> This test (on the branch) does some mixing of States:
> `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests StageStatesTest`

I don't follow.  Are you saying this PR is not complete?

Since the change is not in a public API, I think it makes more sense not to leave partial changes.  Any breakage then will be immediately obvious during testing.

Do you think there might be hidden dependencies on the exact value?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1777#discussion_r2042485461

From angorya at openjdk.org  Mon Apr 14 16:51:52 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 14 Apr 2025 16:51:52 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system
 is busy [v2]
In-Reply-To: <kmWBY2p8XKFmmGuFCf5XmmPLpAbCYbnISTq2EUByTeo=.1f5421b6-130c-403f-9e4a-a1cc2e9789a0@github.com>
References: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
 <kmWBY2p8XKFmmGuFCf5XmmPLpAbCYbnISTq2EUByTeo=.1f5421b6-130c-403f-9e4a-a1cc2e9789a0@github.com>
Message-ID: <_kAPD-aiz3MleUlQnUmWrxIcm7jFDFTat-Uz_uSHcIU=.0dfc8978-bb8e-4340-9e72-d157e6580e7a@github.com>

On Mon, 14 Apr 2025 13:10:05 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

>> There was a Assertion fail issue in mouse location test case JDK-8296554,
>> Reason: We felt the one mili second delay time for the Robot test may be insufficient in few OS.
>> Solution: We Changed the delay time to three mili second.
>> 
>> Verification:
>> Tested in Windows 11, and the Assert fail issue is not found.
>
> Gopal Pattnaik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed Review comments

tests/system/src/test/java/test/robot/javafx/scene/MouseLocationOnScreenTest.java line 123:

> 121:         try {
> 122:             Util.sleep(DELAY_TIME);
> 123:             Assertions.assertEquals(x, (int) robot.getMouseX());

this works also, though I'd simply use `if`.

A bigger question is why are we using `int` coordinates?  Wouldn't it make the test depend on the scale (and also on the screen resolution and window position)?

Should we instead use the double coordinates and `Assertions.equals(double, double, double)` ?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1772#discussion_r2042526271

From mfox at openjdk.org  Mon Apr 14 17:19:45 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 14 Apr 2025 17:19:45 GMT
Subject: RFR: 8354480: A Stage should allow simultaneous iconified and
 maximized states [v2]
In-Reply-To: <36KV5JUfvFBEQ_fGufXjGqnD6vRxr91CnGH77tC-gSQ=.c89552be-fefd-4975-9b3a-a7c1cf3422e3@github.com>
References: <XPiErE5T6bPke2M_SuaDQg0--lQgExgBrJ9mgG9azSA=.a190b01b-6888-4d37-8b7f-eab469458e5d@github.com>
 <36KV5JUfvFBEQ_fGufXjGqnD6vRxr91CnGH77tC-gSQ=.c89552be-fefd-4975-9b3a-a7c1cf3422e3@github.com>
Message-ID: <a9KSuY3t0FqvhPAFcDRoP6muq1DXKpJYuLAEFKSxOOI=.d441be90-c5ca-46a6-9d74-2e1f670622aa@github.com>

On Sun, 13 Apr 2025 18:01:08 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> On some platforms (at least on Ubuntu 24.04 with GNOME and Windows 11), windows can remain maximized even when they are iconified (minimized). When the window is de-iconified (restored), it retains its maximized state.
>> 
>> The documentation in `Stage.java` regarding window states seems to align with this behavior. However, the code currently treats the `WindowEvent.RESTORE` event as both an unminimize (de-iconify) and an unmaximize.
>> 
>> Tests pass on Ubuntu 24.04 XWayland (with one unrelated screenCapture failure). But I would not rely on that since it needes specific tests.
>> 
>> This is not ready to integrate as it may break platform-specific code/behavior.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed one change

I have some issues with the premise of this pull request. It's true that a window's iconified and maximized _properties_ can be true at the same time. But the window itself can't be in both states at once; the user will never see a window that's both maximized and iconified. We need some way to track the actual state of the window and that's currently what the State in ui/Window does. Changing this to a bitfield would require extensive changes throughout the codebase.

The current behavior of RESTORE is correct. In terms of what the user sees there are three possible states: maximized, iconified, and neither. We have an event associated with entering each of these states (MAXIMIZE, MINIMIZE, and RESTORE). Glass should only send RESTORE when the window has entered a state that is neither maximized nor iconified so it's correct for the event handler to clear both of those properties.

This PR doesn't include any glass changes so it's hard to evaluate. Currently glass is tasked with notifying the core code when it enters a new state (maximized, iconified, or neither) without taking into account which state it was previously in. It looks like this PR is asking glass to distinguish between maximized => neither and iconified => neither but this seems redundant since the core code already knows the state and can figure this out.

At the very least this should be marked as draft since it doesn't include any glass changes.

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

PR Comment: https://git.openjdk.org/jfx/pull/1777#issuecomment-2802375322

From kcr at openjdk.org  Mon Apr 14 17:48:02 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 14 Apr 2025 17:48:02 GMT
Subject: [jfx24u] RFR: 8354318: freetype.c: compilation error: 'incompatible
 pointer type' with gcc 14
Message-ID: <UKkQHzzQIC7hiFccO7aGUzTEr02KVLN3jBJ4cp431KQ=.1910887b-9b4d-4518-a34b-a63333772a5d@github.com>

Clean backport of "incompatible pointer type" fix to jfx24u

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

Commit messages:
 - Backport 5a897ab7017107471528ab527dac505d2e33aca9

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

PR: https://git.openjdk.org/jfx24u/pull/21

From mstrauss at openjdk.org  Mon Apr 14 17:57:50 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 14 Apr 2025 17:57:50 GMT
Subject: RFR: 8345348: CSS media feature queries [v13]
In-Reply-To: <DPskwba6n5Lnw-CyzsM8U6zNhBW36cNHwUyGSCT9fcg=.4e1610c2-fd95-4805-b8fa-87c533b6a107@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <9U5TJOMXb3oMWWijiRzo0lp7FJZIQPl-PkRJ3Rc-IqA=.959a8ee1-b84e-46ba-8dec-96c2dd7af9aa@github.com>
 <DPskwba6n5Lnw-CyzsM8U6zNhBW36cNHwUyGSCT9fcg=.4e1610c2-fd95-4805-b8fa-87c533b6a107@github.com>
Message-ID: <ScilSydHxd7htfYM6ukQ-hHKKPALTdJagSHw-nySH34=.294ce1dc-af74-433f-818e-ceb4d1799a34@github.com>

On Mon, 14 Apr 2025 11:34:43 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improved implementation of NullCoalescingPropertyBase
>
> modules/javafx.graphics/src/main/java/javafx/css/Rule.java line 64:
> 
>> 62:     private final MediaRule mediaRule;
>> 63: 
>> 64:     private List<Selector> selectors = null;
> 
> I dislike the accessor pattern somewhat; I wonder, would it be possible to:
> 
> - Make `Rule` sealed: `public abstract sealed class Rule permits InternalRule` (*) similar to how this was done for `Selector`: `public abstract sealed class Selector permits SimpleSelector, CompoundSelector`
> - `InternalRule` would not be public API, and can therefore introduce a public method to get `MediaRule`
> - `Rule` does not have a public constructor, so IMHO there's no risk in there ever being an instance of `Rule` directly (similar reasoning was used to when the `SimpleSelector` / `CompountSelector` refactoring was done).
> 
> This way getting access to the `getMediaRule` method is just a simple `instanceof` check away:
> 
>      MediaRule rule = rule instanceof InternalRule ir ? ir.getMediaRule() : null;
> 
> (*) `InternalRule` is just a place holder name

I can see where you're coming from, and this really makes sense when you're having a public interface and an internal implementation. But that's not the case here, the implementation is out there in `javafx.css`. I don't mind the accessor pattern here (it's simple enough, and we can change it at any time), and would rather revisit the entire public CSS API at some point and either remove it or make it useful.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2042636942

From tsayao at openjdk.org  Mon Apr 14 18:31:50 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 14 Apr 2025 18:31:50 GMT
Subject: RFR: 8354480: A Stage should allow simultaneous iconified and
 maximized states [v2]
In-Reply-To: <a9KSuY3t0FqvhPAFcDRoP6muq1DXKpJYuLAEFKSxOOI=.d441be90-c5ca-46a6-9d74-2e1f670622aa@github.com>
References: <XPiErE5T6bPke2M_SuaDQg0--lQgExgBrJ9mgG9azSA=.a190b01b-6888-4d37-8b7f-eab469458e5d@github.com>
 <36KV5JUfvFBEQ_fGufXjGqnD6vRxr91CnGH77tC-gSQ=.c89552be-fefd-4975-9b3a-a7c1cf3422e3@github.com>
 <a9KSuY3t0FqvhPAFcDRoP6muq1DXKpJYuLAEFKSxOOI=.d441be90-c5ca-46a6-9d74-2e1f670622aa@github.com>
Message-ID: <hY1PJONY-LZ_y6WYEMg1d_ePCsl7HwGbmFjsLeOfOxk=.784ef073-002c-4a5c-bb43-f03b011dea84@github.com>

On Mon, 14 Apr 2025 17:17:23 GMT, Martin Fox <mfox at openjdk.org> wrote:

> I have some issues with the premise of this pull request. It's true that a window's iconified and maximized _properties_ can be true at the same time. But the window itself can't be in both states at once; the user will never see a window that's both maximized and iconified. We need some way to track the actual state of the window and that's currently what the State in ui/Window does. Changing this to a bitfield would require extensive changes throughout the codebase.
> The current behavior of RESTORE is correct. In terms of what the user sees there are three possible states: maximized, iconified, and neither. We have an event associated with entering each of these states (MAXIMIZE, MINIMIZE, and RESTORE). Glass should only send RESTORE when the window has entered a state that is neither maximized nor iconified so it's correct for the event handler to clear both of those properties.

That makes sense ? I'll look into it. I remember it eventually calls the native code to unmaximize, but the issue might lie elsewhere. I think the same should apply to fullscreen for consistency.

Note to myself: If this logic is correct, note that when restoring an iconified window that was maximized, it should be set back to maximized.

> This PR doesn't include any glass changes so it's hard to evaluate. Currently glass is tasked with notifying the core code when it enters a new state (maximized, iconified, or neither) without taking into account which state it was previously in. It looks like this PR is asking glass to distinguish between maximized => neither and iconified => neither but this seems redundant since the core code already knows the state and can figure this out.
> 
> At the very least this should be marked as draft since it doesn't include any glass changes.

Yes, this PR is not ready, I will move it do DRAFT until I address your feedback. Thanks!
Apologies ? you did reply by email. It was my fault for not understanding it.

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

PR Comment: https://git.openjdk.org/jfx/pull/1777#issuecomment-2802577990

From mstrauss at openjdk.org  Mon Apr 14 20:28:12 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 14 Apr 2025 20:28:12 GMT
Subject: RFR: 8345348: CSS media feature queries [v16]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <xYinUPfxTkj_KlRKmZU_ZPj7fs6CE0Xo9lbLvRb8HT8=.a07a2e73-0241-4786-8194-672fb182555b@github.com>

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:

 - formatting
 - typo

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/7bedd63f..9580a80c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=15
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=14-15

  Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1655.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655

PR: https://git.openjdk.org/jfx/pull/1655

From angorya at openjdk.org  Mon Apr 14 20:34:46 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 14 Apr 2025 20:34:46 GMT
Subject: RFR: 8354455: [TestBug] Remove JUnit Vintage Engine with JUnit 4
 [v2]
In-Reply-To: <2lU-5ueNuUrn8wX8X8TbCOWCxmy45QyHpUeL46HE9QA=.112480de-179c-4069-934f-188d359f25c6@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
 <2lU-5ueNuUrn8wX8X8TbCOWCxmy45QyHpUeL46HE9QA=.112480de-179c-4069-934f-188d359f25c6@github.com>
Message-ID: <6Ew58ir5wRGCXhF3NQBaGaxEThX4G-cBBgASvYSdewU=.d8d8845d-da66-41d4-9522-9576e7c13d39@github.com>

On Sat, 12 Apr 2025 00:23:07 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> These are the remaining bits and pieces in order to completely remove the JUnit Vintage Engine, and therefore JUnit 4 from JavaFX.
>> After that, we should either document, that JUnit5 is used (just as information) or close [JDK-8296284](https://bugs.openjdk.org/browse/JDK-8296284) (Since you can not use JUnit4 anymore).
>> 
>> This also removes the `org.hamcrest` dependency, which is actually only used in one test where it can easily be replaced by a `Predicate` (instead of `Matcher`). I'm not convinced that we should keep that dependency for just one test.
>> 
>> ~Note: I could not get the `:swt` tests to compile/test, in order to run the tests. 
>> I need some guidance here how to instruct `Gradle` to compile this module (and if I need anything else? like swt?).~
>> 
>> ~Also, this probably needs an extra ticket in the JBS?~
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix SWT Tests

The test run was successful on my macOS 15.4 running this command:


(git reflog -1; gradle --continue -PFULL_TEST=true -PUSE_ROBOT=true -PSWT_TEST=true cleanTest test --no-daemon -x :web:test --info 2>&1) | tee ~/`date +"test-%Y-%m%d-%H%M%S"`.log

... however, my test run is not indicative because of this:


SWT tests are disabled on MAC, because Gradle test runner does not handle -XstartOnFirstThread properly (https://issues.gradle.org/browse/GRADLE-3290).
``` 

we probably need to enable the SWT tests on mac because the issue seems to have been resolved in 2021:

https://github.com/gradle/gradle/issues/864

modules/javafx.swt/src/test/java/test/javafx/embed/swt/SWTTest.java line 46:

> 44:     }
> 45: 
> 46:     protected final void runOnSwtThread(Runnable runnable) throws Throwable {

I like this solution - does not depend on whimsy of junit.

tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 29:

> 27: import static org.junit.jupiter.api.Assertions.fail;
> 28: import static org.junit.jupiter.api.Assumptions.assumeFalse;
> 29: 

oops, my mistake!  thanks for correcting it.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1774#pullrequestreview-2765009036
PR Comment: https://git.openjdk.org/jfx/pull/1774#issuecomment-2802912256
PR Review Comment: https://git.openjdk.org/jfx/pull/1774#discussion_r2042636260
PR Review Comment: https://git.openjdk.org/jfx/pull/1774#discussion_r2042550484

From duke at openjdk.org  Mon Apr 14 21:01:05 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Mon, 14 Apr 2025 21:01:05 GMT
Subject: RFR: 8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving
 events
Message-ID: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>

When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
Either the native menu is not shown or the URIs are not received.

This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.

The test for this pull request is non trivial, as the application needs to be installed on the Mac before it can be tested. Therefore the test is provided in a separate repository and it needs to be discussed if the test is necessary to have inside the JFX repo and if so, how it should be integrated.

JDK Pull Request: https://github.com/openjdk/jdk/pull/24379
Co-Author: @FlorianKirmaier

Link to the test repo: https://github.com/pabulaner/openurifx

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

Commit messages:
 - 8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events

Changes: https://git.openjdk.org/jfx/pull/1755/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1755&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332947
  Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1755.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1755/head:pull/1755

PR: https://git.openjdk.org/jfx/pull/1755

From kcr at openjdk.org  Mon Apr 14 21:01:05 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 14 Apr 2025 21:01:05 GMT
Subject: RFR: 8332947: [macos] java.awt.desktop.OpenURIHandler is not
 receiving events
In-Reply-To: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
Message-ID: <DPLZsni7y2VhSXHSEkj3lDlzGEqCTOQxrCojFXBrwY0=.2e815958-23ac-418e-9985-5bb5dff6a0d3@github.com>

On Wed, 2 Apr 2025 14:06:58 GMT, Pabulaner IV <duke at openjdk.org> wrote:

> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
> Either the native menu is not shown or the URIs are not received.
> 
> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
> 
> The test for this pull request is non trivial, as the application needs to be installed on the Mac before it can be tested. Therefore the test is provided in a separate repository and it needs to be discussed if the test is necessary to have inside the JFX repo and if so, how it should be integrated.
> 
> JDK Pull Request: https://github.com/openjdk/jdk/pull/24379
> Co-Author: @FlorianKirmaier
> 
> Link to the test repo: https://github.com/pabulaner/openurifx

@pabulaner We'll take a look once your OCA is recorded.

@pabulaner In order for your OCA status to be verified, you need to respond to the [bot's instructions](#issuecomment-2772685035) to confirm your OCA status by entering `/covered`, if you are covered by your employer's OCA, or `/signed`, if you signed the OCA yourself.

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

PR Comment: https://git.openjdk.org/jfx/pull/1755#issuecomment-2772700907
PR Comment: https://git.openjdk.org/jfx/pull/1755#issuecomment-2780704656

From duke at openjdk.org  Mon Apr 14 21:01:05 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Mon, 14 Apr 2025 21:01:05 GMT
Subject: RFR: 8332947: [macos] java.awt.desktop.OpenURIHandler is not
 receiving events
In-Reply-To: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
Message-ID: <2ctFbf5VTVZKxZB2gxp9FWRLtqbx1BF5_M7KtGCntQk=.17494692-e2b9-4ae9-9f6e-6358a172408a@github.com>

On Wed, 2 Apr 2025 14:06:58 GMT, Pabulaner IV <duke at openjdk.org> wrote:

> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
> Either the native menu is not shown or the URIs are not received.
> 
> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
> 
> The test for this pull request is non trivial, as the application needs to be installed on the Mac before it can be tested. Therefore the test is provided in a separate repository and it needs to be discussed if the test is necessary to have inside the JFX repo and if so, how it should be integrated.
> 
> JDK Pull Request: https://github.com/openjdk/jdk/pull/24379
> Co-Author: @FlorianKirmaier
> 
> Link to the test repo: https://github.com/pabulaner/openurifx

Are there any news on my OCA status?

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

PR Comment: https://git.openjdk.org/jfx/pull/1755#issuecomment-2787015841

From kcr at openjdk.org  Mon Apr 14 21:01:05 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 14 Apr 2025 21:01:05 GMT
Subject: RFR: 8332947: [macos] java.awt.desktop.OpenURIHandler is not
 receiving events
In-Reply-To: <2ctFbf5VTVZKxZB2gxp9FWRLtqbx1BF5_M7KtGCntQk=.17494692-e2b9-4ae9-9f6e-6358a172408a@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
 <2ctFbf5VTVZKxZB2gxp9FWRLtqbx1BF5_M7KtGCntQk=.17494692-e2b9-4ae9-9f6e-6358a172408a@github.com>
Message-ID: <JA2WZv23bOjnn86K9VIlKbw9CelQv_2U9nl1VRA-wSU=.187a6447-b0b8-4c3b-a159-936c26e3eb26@github.com>

On Tue, 8 Apr 2025 16:26:44 GMT, Pabulaner IV <duke at openjdk.org> wrote:

> Are there any news on my OCA status?

@robilad Can you provide a status update?

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

PR Comment: https://git.openjdk.org/jfx/pull/1755#issuecomment-2787065269

From kcr at openjdk.org  Mon Apr 14 21:04:30 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 14 Apr 2025 21:04:30 GMT
Subject: RFR: 8353632: [Linux] Undefined reference to
 PlatformSupport::OBSERVED_SETTINGS with C++14 [v2]
In-Reply-To: <jlakUm_s21y5is_ZN9-_GvxoISGGP06H4i4Z-H6VdJo=.faa839da-4d16-4cdc-9024-1333bb504cdd@github.com>
References: <jlakUm_s21y5is_ZN9-_GvxoISGGP06H4i4Z-H6VdJo=.faa839da-4d16-4cdc-9024-1333bb504cdd@github.com>
Message-ID: <Bqaw_8plneDhTR3HHHIhuxnQkE0v2cPm5epXpWZvB60=.e3e3588f-1f6a-4c88-a9af-95e1b682ba36@github.com>

> Fixes a link error that occurs when using C++14 to compile and link JavaFX on Linux.
> 
> 
> in function `PlatformSupport::PlatformSupport(JNIEnv_*, _jobject*)':
> PlatformSupport.cpp:90: undefined reference to `PlatformSupport::OBSERVED_SETTINGS'
> 
> 
> The solution, proposed by @johanvos, is to define `PlatformSupport::OBSERVED_SETTINGS` in `PlatformSupport.cpp`.
> 
> I have tested this using gcc 13.2 and 14.2 using C++17 and it builds and runs as expected. Johan has already tested a variant of this on C++14, but I will wait for his explicit review.

Kevin Rushforth 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 remote-tracking branch 'upstream/master' into 8353632-PlatformSupport
 - 8353632: [Linux] Undefined reference to PlatformSupport::OBSERVED_SETTINGS with C++14

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1768/files
  - new: https://git.openjdk.org/jfx/pull/1768/files/43b4eb46..2f3e7f8a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1768&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1768&range=00-01

  Stats: 336 lines in 13 files changed: 201 ins; 87 del; 48 mod
  Patch: https://git.openjdk.org/jfx/pull/1768.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1768/head:pull/1768

PR: https://git.openjdk.org/jfx/pull/1768

From robilad at openjdk.org  Mon Apr 14 21:09:48 2025
From: robilad at openjdk.org (Dalibor Topic)
Date: Mon, 14 Apr 2025 21:09:48 GMT
Subject: RFR: 8332947: [macos] java.awt.desktop.OpenURIHandler is not
 receiving events
In-Reply-To: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
Message-ID: <p3B_bu7lslDDKWYC9SjAY3s7iBv3Xgoo1Ce3RHMj0hs=.a98d428d-80c1-4c03-9b47-51dc5a79cc59@github.com>

On Wed, 2 Apr 2025 14:06:58 GMT, Pabulaner IV <duke at openjdk.org> wrote:

> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
> Either the native menu is not shown or the URIs are not received.
> 
> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
> 
> The test for this pull request is non trivial, as the application needs to be installed on the Mac before it can be tested. Therefore the test is provided in a separate repository and it needs to be discussed if the test is necessary to have inside the JFX repo and if so, how it should be integrated.
> 
> JDK Pull Request: https://github.com/openjdk/jdk/pull/24379
> Co-Author: @FlorianKirmaier
> 
> Link to the test repo: https://github.com/pabulaner/openurifx

OCA processed and account now marked as verified in Skara

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

PR Comment: https://git.openjdk.org/jfx/pull/1755#issuecomment-2803005604

From sykora at openjdk.org  Mon Apr 14 21:12:49 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Mon, 14 Apr 2025 21:12:49 GMT
Subject: [jfx24u] RFR: 8354182: Create release notes for JavaFX 24.0.1
In-Reply-To: <wWrn0MNNgD9xJ9yXYG6fXgk5YOBcXLl5qwvXA5c5T5M=.339e7c61-705c-4e34-b6f9-f6783c1e3eb8@github.com>
References: <wWrn0MNNgD9xJ9yXYG6fXgk5YOBcXLl5qwvXA5c5T5M=.339e7c61-705c-4e34-b6f9-f6783c1e3eb8@github.com>
Message-ID: <qLtUZYo1QCSMfO_wZoUepIf_2zPPZVJV498ZHLrqGko=.2b650808-ebd2-4fa4-b33f-a53503f9f71d@github.com>

On Wed, 9 Apr 2025 23:17:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Release notes for JavaFX 24.0.1.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=47358
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=47357
> 
> As usual, I excluded test bugs, cleanup bugs, etc.
> 
> NOTE: Once the CPU release ships on 2025-04-15, I will add any security bugs and ask for a re-review.

It all looks fine to me.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx24u/pull/19#pullrequestreview-2765683316

From kcr at openjdk.org  Mon Apr 14 21:23:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 14 Apr 2025 21:23:44 GMT
Subject: RFR: 8332947: [macos] java.awt.desktop.OpenURIHandler is not
 receiving events
In-Reply-To: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
Message-ID: <KT84DPZfJMhgalCDgP99_uknOHVBsR7K9yegZNgftso=.932fc279-d463-4f11-99f3-19998abfc2e0@github.com>

On Wed, 2 Apr 2025 14:06:58 GMT, Pabulaner IV <duke at openjdk.org> wrote:

> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
> Either the native menu is not shown or the URIs are not received.
> 
> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
> 
> The test for this pull request is non trivial, as the application needs to be installed on the Mac before it can be tested. Therefore the test is provided in a separate repository and it needs to be discussed if the test is necessary to have inside the JFX repo and if so, how it should be integrated.
> 
> JDK Pull Request: https://github.com/openjdk/jdk/pull/24379
> Co-Author: @FlorianKirmaier
> 
> Link to the test repo: https://github.com/pabulaner/openurifx

We'll need some sort of standalone test, even if it can't be automated, that we can use to test the fix. Something that isn't a full-blown app. The test program should be able to reproduce the problem without the fix and can then be used to verify the fix.

When testing, we will want to consider the following scenarios:

1. Pure JavaFX app (even though there isn't a `java.awt.desktop.OpenURIHandler` in this case, we need to make sure that it doesn't misbehave)
2. JavaFX + Swing app -- JavaFX Toolkit initialized first (I think this is the main case you want to handle)
3. JavaFX + Swing app -- AWT Toolkit initialized first (I presume this case already works, so the main thing is to ensure no regressions)

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

PR Comment: https://git.openjdk.org/jfx/pull/1755#issuecomment-2803055709

From kcr at openjdk.org  Mon Apr 14 21:27:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 14 Apr 2025 21:27:44 GMT
Subject: RFR: 8332947: [macos] java.awt.desktop.OpenURIHandler is not
 receiving events
In-Reply-To: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
Message-ID: <hN-MD-vBR5nHpvTMwtu5g5QitdKoN65RWOGdvJKEAUo=.c5c0e09f-c529-447f-81f2-367e0f3071f5@github.com>

On Wed, 2 Apr 2025 14:06:58 GMT, Pabulaner IV <duke at openjdk.org> wrote:

> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
> Either the native menu is not shown or the URIs are not received.
> 
> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
> 
> The test for this pull request is non trivial, as the application needs to be installed on the Mac before it can be tested. Therefore the test is provided in a separate repository and it needs to be discussed if the test is necessary to have inside the JFX repo and if so, how it should be integrated.
> 
> JDK Pull Request: https://github.com/openjdk/jdk/pull/24379
> Co-Author: @FlorianKirmaier
> 
> Link to the test repo: https://github.com/pabulaner/openurifx

Also, since the proposed fix is in JavaFX, the JBS bug needs to be updated to the correct component/subcomponent/version. I can do that and also assign the bug to @FlorianKirmaier since you list him as a co-author of this fix. If you wish to have Skara record Florian as a co-author, you can use Skara's `/contributor add` command.

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

PR Comment: https://git.openjdk.org/jfx/pull/1755#issuecomment-2803061874

From kcr at openjdk.org  Mon Apr 14 21:42:58 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 14 Apr 2025 21:42:58 GMT
Subject: RFR: 8332947: [macos] java.awt.desktop.OpenURIHandler is not
 receiving events
In-Reply-To: <hN-MD-vBR5nHpvTMwtu5g5QitdKoN65RWOGdvJKEAUo=.c5c0e09f-c529-447f-81f2-367e0f3071f5@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
 <hN-MD-vBR5nHpvTMwtu5g5QitdKoN65RWOGdvJKEAUo=.c5c0e09f-c529-447f-81f2-367e0f3071f5@github.com>
Message-ID: <u6mKab7iDb7z0tjOvlpySRNGtgDGJ7qiWlxdM8TJApU=.929e71a9-57c7-40a4-8734-8472d5131d75@github.com>

On Mon, 14 Apr 2025 21:24:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Also, since the proposed fix is in JavaFX, the JBS bug needs to be updated to the correct component/subcomponent/version.

I see that it's not quite that simple, since there is a corresponding AWT fix.

You cannot use the same bug ID for both a JDK fix and a JavaFX fix. File a separate bug for the JavaFX half of the fix, and use that new bug for this JavaFX PR. Perhaps @FlorianKirmaier can do this?

The two fixes will need to be done and tested both independently and together. It is OK if the bug isn't fully fixed without both halves of the fix. However, it is not OK for it to misbehave in some other way (exception, crash, etc) if you run a JavaFX without the fix with an JDK with the fix or vice versa.

So there now needs to be a matrix of testing that includes:

(JDK without/with fix) X (JavaFX without/with fix)

For each of those 4 cases you will need to test:

* JavaFX + Swing app -- JavaFX Toolkit initialized first
* JavaFX + Swing app -- AWT Toolkit initialized first

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

PR Comment: https://git.openjdk.org/jfx/pull/1755#issuecomment-2803089437

From angorya at openjdk.org  Mon Apr 14 22:13:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 14 Apr 2025 22:13:47 GMT
Subject: RFR: 8354455: [TestBug] Remove JUnit Vintage Engine with JUnit 4
 [v2]
In-Reply-To: <2lU-5ueNuUrn8wX8X8TbCOWCxmy45QyHpUeL46HE9QA=.112480de-179c-4069-934f-188d359f25c6@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
 <2lU-5ueNuUrn8wX8X8TbCOWCxmy45QyHpUeL46HE9QA=.112480de-179c-4069-934f-188d359f25c6@github.com>
Message-ID: <iXl11HPXxwUOL-34iUTiiIV3LOeXW9hVxgCnMM0BMyc=.10563ba8-137e-485e-93f3-2f08e7e67437@github.com>

On Sat, 12 Apr 2025 00:23:07 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> These are the remaining bits and pieces in order to completely remove the JUnit Vintage Engine, and therefore JUnit 4 from JavaFX.
>> After that, we should either document, that JUnit5 is used (just as information) or close [JDK-8296284](https://bugs.openjdk.org/browse/JDK-8296284) (Since you can not use JUnit4 anymore).
>> 
>> This also removes the `org.hamcrest` dependency, which is actually only used in one test where it can easily be replaced by a `Predicate` (instead of `Matcher`). I'm not convinced that we should keep that dependency for just one test.
>> 
>> ~Note: I could not get the `:swt` tests to compile/test, in order to run the tests. 
>> I need some guidance here how to instruct `Gradle` to compile this module (and if I need anything else? like swt?).~
>> 
>> ~Also, this probably needs an extra ticket in the JBS?~
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix SWT Tests

a problem found in a doctored macOS test, I wonder if we'll see the same issue on windows/linux?

Tried to enable swt tests on macOS (build.gradle lines 3085, 3096), got three tests failed:


[FXCanvasScaledTest](https://github.com/openjdk/jfx/pull/classes/test.javafx.embed.swt.FXCanvasScaledTest.html). [initializationError](https://github.com/openjdk/jfx/pull/classes/test.javafx.embed.swt.FXCanvasScaledTest.html#initializationError)
[FXCanvasTest](https://github.com/openjdk/jfx/pull/classes/test.javafx.embed.swt.FXCanvasTest.html). [initializationError](https://github.com/openjdk/jfx/pull/classes/test.javafx.embed.swt.FXCanvasTest.html#initializationError)
[SWTCursorsTest](https://github.com/openjdk/jfx/pull/classes/test.javafx.embed.swt.SWTCursorsTest.html). [initializationError](https://github.com/openjdk/jfx/pull/classes/test.javafx.embed.swt.SWTCursorsTest.html#initializationError)


all in `SWTTest.beforeAll()`: 


org.eclipse.swt.SWTException: Invalid thread access
	at app//org.eclipse.swt.SWT.error(SWT.java:4918)
	at app//org.eclipse.swt.SWT.error(SWT.java:4833)
	at app//org.eclipse.swt.SWT.error(SWT.java:4804)
	at app//org.eclipse.swt.widgets.Display.error(Display.java:1209)
	at app//org.eclipse.swt.widgets.Display.createDisplay(Display.java:960)
	at app//org.eclipse.swt.widgets.Display.create(Display.java:944)
	at app//org.eclipse.swt.graphics.Device.<init>(Device.java:132)
	at app//org.eclipse.swt.widgets.Display.<init>(Display.java:798)
	at app//org.eclipse.swt.widgets.Display.<init>(Display.java:789)
	at app//org.eclipse.swt.widgets.Display.getDefault(Display.java:1543)
	at app//test.javafx.embed.swt.SWTTest.beforeAll(SWTTest.java:43)
	at java.base at 23.0.1/java.lang.reflect.Method.invoke(Method.java:580)
	at java.base at 23.0.1/java.util.ArrayList.forEach(ArrayList.java:1597)


so probably need to wrap SWTTest:43 in `runOnSwtThread()`.

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

Changes requested by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1774#pullrequestreview-2765840684
PR Comment: https://git.openjdk.org/jfx/pull/1774#issuecomment-2803159054

From kcr at openjdk.org  Mon Apr 14 22:20:50 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 14 Apr 2025 22:20:50 GMT
Subject: RFR: 8354455: [TestBug] Remove JUnit Vintage Engine with JUnit 4
 [v2]
In-Reply-To: <iXl11HPXxwUOL-34iUTiiIV3LOeXW9hVxgCnMM0BMyc=.10563ba8-137e-485e-93f3-2f08e7e67437@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
 <2lU-5ueNuUrn8wX8X8TbCOWCxmy45QyHpUeL46HE9QA=.112480de-179c-4069-934f-188d359f25c6@github.com>
 <iXl11HPXxwUOL-34iUTiiIV3LOeXW9hVxgCnMM0BMyc=.10563ba8-137e-485e-93f3-2f08e7e67437@github.com>
Message-ID: <AyewwbscFjf-od1pcJB8wkZBY39sIcZlgl3KYU0YmfY=.18e20818-30c4-482e-9aeb-ffb9106644c8@github.com>

On Mon, 14 Apr 2025 22:10:57 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> a problem found in a doctored macOS test, I wonder if we'll see the same issue on windows/linux?

The SWT tests have never worked on macOS as far as I know -- even before JDK 9 modularization when they were disabled on all platforms.

Getting these tests to run on macOS seems better for a follow-up.

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

PR Comment: https://git.openjdk.org/jfx/pull/1774#issuecomment-2803177371

From angorya at openjdk.org  Mon Apr 14 22:26:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 14 Apr 2025 22:26:45 GMT
Subject: RFR: 8354455: [TestBug] Remove JUnit Vintage Engine with JUnit 4
 [v2]
In-Reply-To: <AyewwbscFjf-od1pcJB8wkZBY39sIcZlgl3KYU0YmfY=.18e20818-30c4-482e-9aeb-ffb9106644c8@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
 <2lU-5ueNuUrn8wX8X8TbCOWCxmy45QyHpUeL46HE9QA=.112480de-179c-4069-934f-188d359f25c6@github.com>
 <iXl11HPXxwUOL-34iUTiiIV3LOeXW9hVxgCnMM0BMyc=.10563ba8-137e-485e-93f3-2f08e7e67437@github.com>
 <AyewwbscFjf-od1pcJB8wkZBY39sIcZlgl3KYU0YmfY=.18e20818-30c4-482e-9aeb-ffb9106644c8@github.com>
Message-ID: <QVPz18DwTcu_Fd--1rVuvscwvaqh9bIlqC4BisFP0G4=.35bd99a3-726e-496f-a917-2ce5f92f1d42@github.com>

On Mon, 14 Apr 2025 22:17:58 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Getting these tests to run on macOS seems better for a follow-up.

Quite right.

The exception I see might indicate a problem even there - the exception is coming from `Display.getDefault()`, and `runOnSwtThread` uses the display to use its `asyncExec()` method, so I am not sure how this might work.

I'll do another run on the windows platform tomorrow.

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

PR Comment: https://git.openjdk.org/jfx/pull/1774#issuecomment-2803193817

From tsayao at openjdk.org  Mon Apr 14 23:25:57 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 14 Apr 2025 23:25:57 GMT
Subject: RFR: 8354478: Improve StageStyle documentation [v3]
In-Reply-To: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>
References: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>
Message-ID: <1BO4p_gni49IuWRNQuzmg5y7_lKK2eMPIE8dWBo118s=.8a26322f-03f9-4e4d-982a-c00f86de4068@github.com>

> Improve StageStyle Documentation
> 
> - Update `StageStyle.UTILITY`:
> Clarified that UTILITY stages may impose platform-specific restrictions on window states, such as preventing maximize, minimize (iconify), and fullscreen operations.
> 
> - Update `StageStyle.UNDECORATED`:
> Improved the description to clarify that although UNDECORATED removes standard window decorations (title bar, borders, and controls), window operations like minimize, maximize, and fullscreen may still be allowed programmatically or via platform-specific functions such as key shortcuts or menu options.
> 
> - Remove mention of solid white background:
> This seems to be not true anymore, even withou a `Scene` (or there's a bug)

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Restore "with a solid white background"

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1776/files
  - new: https://git.openjdk.org/jfx/pull/1776/files/88307f0d..675d045b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1776&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1776&range=01-02

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1776.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1776/head:pull/1776

PR: https://git.openjdk.org/jfx/pull/1776

From tsayao at openjdk.org  Mon Apr 14 23:42:52 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 14 Apr 2025 23:42:52 GMT
Subject: RFR: 8354478: Improve StageStyle documentation [v3]
In-Reply-To: <dRW2oV9Sug2CiRc1-29EjBri41tNraNHKBHykVOHnag=.3d284b91-6b55-4fa2-9e61-3d2bca99254d@github.com>
References: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>
 <dRW2oV9Sug2CiRc1-29EjBri41tNraNHKBHykVOHnag=.3d284b91-6b55-4fa2-9e61-3d2bca99254d@github.com>
Message-ID: <WPMhVEVs_kkj7wWGZUUH2ga-RNAZls-WAfnbEKcDZwc=.c206a7e4-1753-4d34-b6d8-d8c83b1891ee@github.com>

On Mon, 14 Apr 2025 14:36:13 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore "with a solid white background"
>
> modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java line 35:
> 
>> 33: 
>> 34:     /**
>> 35:      * Defines a normal {@code Stage} style with a solid background and platform decorations.
> 
> Should we say the background color is platform-specific, or perhaps identify why it is different?

I restored it, I think it's a Linux glass specific bug.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1776#discussion_r2043171052

From tsayao at openjdk.org  Mon Apr 14 23:42:54 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 14 Apr 2025 23:42:54 GMT
Subject: RFR: 8354478: Improve StageStyle documentation [v2]
In-Reply-To: <AFSdq3lG6D7OEGI-KvcuCu_NBZQa5yNpSu4edSPyerg=.8616a1ab-64de-4c9d-8042-77b6d82c171d@github.com>
References: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>
 <sqq9mswghBpOYptKll0GcDovdBaY-26A2GDtmAWLFcY=.325c2656-6148-4e7b-b78c-1e572a590566@github.com>
 <AFSdq3lG6D7OEGI-KvcuCu_NBZQa5yNpSu4edSPyerg=.8616a1ab-64de-4c9d-8042-77b6d82c171d@github.com>
Message-ID: <rUp3Qf2Q5JGfFP1ZfvRS1E3qMea9mK9v5i1hvWLka5M=.0bbd5a52-056b-409d-8632-db374f5aa619@github.com>

On Mon, 14 Apr 2025 16:00:10 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add "style" ib the UTILITY style like the others
>>  - Update modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java
>>    
>>    Co-authored-by: John Hendrikx <john.hendrikx+github at gmail.com>
>
> modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java line 41:
> 
>> 39:     /**
>> 40:      * Defines a {@code Stage} style with no window decorations, such as a title bar,
>> 41:      * borders, or window controls.
> 
> Any particular reason you removed "a solid background" like `DECORATED` has? The previous docs give that detail.

I restored it, but I'm still curious about when the white background should actually be visible. I noticed that on Linux, if a stage is shown without a scene, it behaves oddly?it doesn't render because there's nothing being painted. To fix this, I added a white background as part of the "Linux glass fixes" package I'm working on. I also observed that when a scene is present, a white background gets set automatically. But under what conditions is it actually visible?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1776#discussion_r2043170320

From tsayao at openjdk.org  Mon Apr 14 23:53:50 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 14 Apr 2025 23:53:50 GMT
Subject: RFR: 8354478: Improve StageStyle documentation [v2]
In-Reply-To: <rUp3Qf2Q5JGfFP1ZfvRS1E3qMea9mK9v5i1hvWLka5M=.0bbd5a52-056b-409d-8632-db374f5aa619@github.com>
References: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>
 <sqq9mswghBpOYptKll0GcDovdBaY-26A2GDtmAWLFcY=.325c2656-6148-4e7b-b78c-1e572a590566@github.com>
 <AFSdq3lG6D7OEGI-KvcuCu_NBZQa5yNpSu4edSPyerg=.8616a1ab-64de-4c9d-8042-77b6d82c171d@github.com>
 <rUp3Qf2Q5JGfFP1ZfvRS1E3qMea9mK9v5i1hvWLka5M=.0bbd5a52-056b-409d-8632-db374f5aa619@github.com>
Message-ID: <MhSZTVWgfNQH7tw2oVmryLhEfUAp8EO8C4SB59INhDI=.c281d439-045a-4f8c-a4cb-472f04ee6a80@github.com>

On Mon, 14 Apr 2025 23:38:36 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java line 41:
>> 
>>> 39:     /**
>>> 40:      * Defines a {@code Stage} style with no window decorations, such as a title bar,
>>> 41:      * borders, or window controls.
>> 
>> Any particular reason you removed "a solid background" like `DECORATED` has? The previous docs give that detail.
>
> I restored it, but I'm still curious about when the white background should actually be visible. I noticed that on Linux, if a stage is shown without a scene, it behaves oddly?it doesn't render because there's nothing being painted. To fix this, I added a white background as part of the "Linux glass fixes" package I'm working on. I also observed that when a scene is present, a white background gets set automatically. But under what conditions is it actually visible?

A scene with a TRANSPARENT Parent is one scenario.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1776#discussion_r2043182870

From arapte at openjdk.org  Tue Apr 15 04:57:47 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 15 Apr 2025 04:57:47 GMT
Subject: [jfx24u] RFR: 8354182: Create release notes for JavaFX 24.0.1
In-Reply-To: <wWrn0MNNgD9xJ9yXYG6fXgk5YOBcXLl5qwvXA5c5T5M=.339e7c61-705c-4e34-b6f9-f6783c1e3eb8@github.com>
References: <wWrn0MNNgD9xJ9yXYG6fXgk5YOBcXLl5qwvXA5c5T5M=.339e7c61-705c-4e34-b6f9-f6783c1e3eb8@github.com>
Message-ID: <htd39heA26hgw-8IgHbRUU3sQXpZ0bO21HaxsNiJIwc=.cc9632be-6061-4e97-b9fe-4244de168df4@github.com>

On Wed, 9 Apr 2025 23:17:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Release notes for JavaFX 24.0.1.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=47358
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=47357
> 
> As usual, I excluded test bugs, cleanup bugs, etc.
> 
> NOTE: Once the CPU release ships on 2025-04-15, I will add any security bugs and ask for a re-review.

lgtm..

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx24u/pull/19#pullrequestreview-2766743517

From duke at openjdk.org  Tue Apr 15 06:32:44 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Tue, 15 Apr 2025 06:32:44 GMT
Subject: RFR: 8332947: [macos] java.awt.desktop.OpenURIHandler is not
 receiving events
In-Reply-To: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
Message-ID: <wibxQTlzUJnUPhIB0M_cXXu1EFrWy3SHG6U7bHGhe5Q=.e899ebfa-72e2-4268-9b0a-dc0adf68fad7@github.com>

On Wed, 2 Apr 2025 14:06:58 GMT, Pabulaner IV <duke at openjdk.org> wrote:

> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
> Either the native menu is not shown or the URIs are not received.
> 
> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
> 
> The test for this pull request is non trivial, as the application needs to be installed on the Mac before it can be tested. Therefore the test is provided in a separate repository and it needs to be discussed if the test is necessary to have inside the JFX repo and if so, how it should be integrated.
> 
> JDK Pull Request: https://github.com/openjdk/jdk/pull/24379
> Co-Author: @FlorianKirmaier
> 
> Link to the test repo: https://github.com/pabulaner/openurifx

And thank You for the quick reply, I will look into it and ask @FlorianKirmaier for his support.

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

PR Comment: https://git.openjdk.org/jfx/pull/1755#issuecomment-2803961236

From arapte at openjdk.org  Tue Apr 15 07:21:52 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 15 Apr 2025 07:21:52 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system
 is busy [v2]
In-Reply-To: <_kAPD-aiz3MleUlQnUmWrxIcm7jFDFTat-Uz_uSHcIU=.0dfc8978-bb8e-4340-9e72-d157e6580e7a@github.com>
References: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
 <kmWBY2p8XKFmmGuFCf5XmmPLpAbCYbnISTq2EUByTeo=.1f5421b6-130c-403f-9e4a-a1cc2e9789a0@github.com>
 <_kAPD-aiz3MleUlQnUmWrxIcm7jFDFTat-Uz_uSHcIU=.0dfc8978-bb8e-4340-9e72-d157e6580e7a@github.com>
Message-ID: <n9BPPy0IjV3ow_UFt9ms1gXcNk5cpdg-0G_jGENcq3o=.211db96a-91a5-44e7-8ab2-be393974b9da@github.com>

On Mon, 14 Apr 2025 16:48:51 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Gopal Pattnaik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed Review comments
>
> tests/system/src/test/java/test/robot/javafx/scene/MouseLocationOnScreenTest.java line 123:
> 
>> 121:         try {
>> 122:             Util.sleep(DELAY_TIME);
>> 123:             Assertions.assertEquals(x, (int) robot.getMouseX());
> 
> this works also, though I'd simply use `if`.
> 
> A bigger question is why are we using `int` coordinates?  Wouldn't it make the test depend on the scale (and also on the screen resolution and window position)?
> 
> Should we instead use the double coordinates and `Assertions.equals(double, double, double)` ?

I would recommend to use a for loop as below. 

    private static int VALIDATE_COUNT = 3;
    static void validate(Robot robot, int x, int y) {
        for (int i = 0; i < VALIDATE_COUNT; i++) {
            Util.sleep(DELAY_TIME);
            if (x == (int)robot.getMouseX() &&
                y == (int)robot.getMouseY()) {
                break;
            }
        }
        Assertions.assertEquals(x, (int) robot.getMouseX());
        Assertions.assertEquals(y, (int) robot.getMouseY());
    }

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1772#discussion_r2043826793

From fkirmaier at openjdk.org  Tue Apr 15 08:58:50 2025
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Tue, 15 Apr 2025 08:58:50 GMT
Subject: RFR: 8332947: [macos] java.awt.desktop.OpenURIHandler is not
 receiving events
In-Reply-To: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
Message-ID: <EfLzychocD0KvYZBo0iMKmS1IXKmCi_7zBTzLEOZ13I=.cf675fe6-819f-4988-8b4a-00fe1951b736@github.com>

On Wed, 2 Apr 2025 14:06:58 GMT, Pabulaner IV <duke at openjdk.org> wrote:

> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
> Either the native menu is not shown or the URIs are not received.
> 
> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
> 
> The test for this pull request is non trivial, as the application needs to be installed on the Mac before it can be tested. Therefore the test is provided in a separate repository and it needs to be discussed if the test is necessary to have inside the JFX repo and if so, how it should be integrated.
> 
> JDK Pull Request: https://github.com/openjdk/jdk/pull/24379
> Co-Author: @FlorianKirmaier
> 
> Link to the test repo: https://github.com/pabulaner/openurifx

I've created a new ticket for the JFX Part of the fix:
https://bugs.openjdk.org/browse/JDK-8354631
@pabulaner Can you change the title and ticket number in the PR, so it matches with the new ticket?

Let me know, if i should change anything, in the ticket.

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

PR Comment: https://git.openjdk.org/jfx/pull/1755#issuecomment-2804330118

From mstrauss at openjdk.org  Tue Apr 15 10:56:31 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 15 Apr 2025 10:56:31 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v65]
In-Reply-To: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
Message-ID: <GvD9ZJz0Xn0RIDl7zTAw8wEZ_X0e8dFfIjVl-zNmXKg=.8a68bebe-469a-457b-9de8-5793942632e3@github.com>

> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  documentation

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1605/files
  - new: https://git.openjdk.org/jfx/pull/1605/files/e9aeaefd..379c01ec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=64
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=63-64

  Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1605.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605

PR: https://git.openjdk.org/jfx/pull/1605

From kcr at openjdk.org  Tue Apr 15 13:55:43 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 15 Apr 2025 13:55:43 GMT
Subject: [jfx24u] RFR: 8354182: Create release notes for JavaFX 24.0.1 [v2]
In-Reply-To: <wWrn0MNNgD9xJ9yXYG6fXgk5YOBcXLl5qwvXA5c5T5M=.339e7c61-705c-4e34-b6f9-f6783c1e3eb8@github.com>
References: <wWrn0MNNgD9xJ9yXYG6fXgk5YOBcXLl5qwvXA5c5T5M=.339e7c61-705c-4e34-b6f9-f6783c1e3eb8@github.com>
Message-ID: <ZPjMT7a-TMGvFKrXdp_6wrptnZNuK4biD30kgmrOzxM=.88aafd7e-b407-451c-b7e5-55f081152dba@github.com>

> Release notes for JavaFX 24.0.1.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=47358
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=47357
> 
> As usual, I excluded test bugs, cleanup bugs, etc.
> 
> NOTE: Once the CPU release ships on 2025-04-15, I will add any security bugs and ask for a re-review.

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  No security content

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

Changes:
  - all: https://git.openjdk.org/jfx24u/pull/19/files
  - new: https://git.openjdk.org/jfx24u/pull/19/files/1b312d8f..4246b268

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx24u&pr=19&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx24u&pr=19&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jfx24u/pull/19.diff
  Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/19/head:pull/19

PR: https://git.openjdk.org/jfx24u/pull/19

From kcr at openjdk.org  Tue Apr 15 14:02:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 15 Apr 2025 14:02:21 GMT
Subject: [jfx24u] RFR: Merge e998e3105951459e3076026242df8c31e2775a49
Message-ID: <OxcGG2c4uxVGm0yLxQsVXs4DTitK57zfDA9DjENb4FU=.400e2f25-1cb6-4c54-b44a-e89eac199758@github.com>

Clean merge of January CPU content into `jfx24u:master`. Note that this is a no-op merge, since there is no security content for this release. The only content is some identity merge commits and two duplicate commits of bug fixes that were pulled into the `jfx24.0.1` release after the version bump.

There are no changes to the contents of this repo.

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

Commit messages:
 - Merge branch 'jfx24.0.1' into merge-jfx24.0.1
 - 8347937: Canvas pattern test fails and crashes on WebKit 620.1
 - 8351264: Some images don't load with WebKit 620.1
 - Merge
 - Merge
 - Merge

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jfx24u/pull/22/files
  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx24u/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/22/head:pull/22

PR: https://git.openjdk.org/jfx24u/pull/22

From kcr at openjdk.org  Tue Apr 15 14:02:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 15 Apr 2025 14:02:21 GMT
Subject: [jfx24u] RFR: Merge e998e3105951459e3076026242df8c31e2775a49
In-Reply-To: <OxcGG2c4uxVGm0yLxQsVXs4DTitK57zfDA9DjENb4FU=.400e2f25-1cb6-4c54-b44a-e89eac199758@github.com>
References: <OxcGG2c4uxVGm0yLxQsVXs4DTitK57zfDA9DjENb4FU=.400e2f25-1cb6-4c54-b44a-e89eac199758@github.com>
Message-ID: <N1I3A9GVhTGHMyUOTvTrs5LAkqDGAfhmCvVgRLIQwis=.4142a986-9902-4f8b-aa75-50117d400ebb@github.com>

On Tue, 15 Apr 2025 13:53:59 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean merge of January CPU content into `jfx24u:master`. Note that this is a no-op merge, since there is no security content for this release. The only content is some identity merge commits and two duplicate commits of bug fixes that were pulled into the `jfx24.0.1` release after the version bump.
> 
> There are no changes to the contents of this repo.

Reviewer: @arapte

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

PR Comment: https://git.openjdk.org/jfx24u/pull/22#issuecomment-2805159190

From arapte at openjdk.org  Tue Apr 15 14:09:57 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 15 Apr 2025 14:09:57 GMT
Subject: [jfx24u] RFR: 8354182: Create release notes for JavaFX 24.0.1 [v2]
In-Reply-To: <ZPjMT7a-TMGvFKrXdp_6wrptnZNuK4biD30kgmrOzxM=.88aafd7e-b407-451c-b7e5-55f081152dba@github.com>
References: <wWrn0MNNgD9xJ9yXYG6fXgk5YOBcXLl5qwvXA5c5T5M=.339e7c61-705c-4e34-b6f9-f6783c1e3eb8@github.com>
 <ZPjMT7a-TMGvFKrXdp_6wrptnZNuK4biD30kgmrOzxM=.88aafd7e-b407-451c-b7e5-55f081152dba@github.com>
Message-ID: <2GjwWM1xXH5uureK_y1LcB9z32VdoKZSRHdXBZumNyg=.ee7f2af4-ae3e-4972-a19e-c346622c80a2@github.com>

On Tue, 15 Apr 2025 13:55:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Release notes for JavaFX 24.0.1.
>> 
>> Notes to reviewers:
>> 
>> I used the following filter to pick the issues:
>> 
>> https://bugs.openjdk.org/issues/?filter=47358
>> 
>> The original filter, with the backport IDs, is here:
>> 
>> https://bugs.openjdk.org/issues/?filter=47357
>> 
>> As usual, I excluded test bugs, cleanup bugs, etc.
>> 
>> NOTE: Once the CPU release ships on 2025-04-15, I will add any security bugs and ask for a re-review.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No security content

Marked as reviewed by arapte (Reviewer).

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

PR Review: https://git.openjdk.org/jfx24u/pull/19#pullrequestreview-2768465161

From arapte at openjdk.org  Tue Apr 15 14:09:57 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 15 Apr 2025 14:09:57 GMT
Subject: [jfx24u] RFR: Merge e998e3105951459e3076026242df8c31e2775a49
In-Reply-To: <OxcGG2c4uxVGm0yLxQsVXs4DTitK57zfDA9DjENb4FU=.400e2f25-1cb6-4c54-b44a-e89eac199758@github.com>
References: <OxcGG2c4uxVGm0yLxQsVXs4DTitK57zfDA9DjENb4FU=.400e2f25-1cb6-4c54-b44a-e89eac199758@github.com>
Message-ID: <9HfAm3xp41Qzn5XPjIZa5J7D-HVYZUD0w4zuimZWGWI=.875a947c-40bd-4069-b733-1a4f30282a1f@github.com>

On Tue, 15 Apr 2025 13:53:59 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean merge of January CPU content into `jfx24u:master`. Note that this is a no-op merge, since there is no security content for this release. The only content is some identity merge commits and two duplicate commits of bug fixes that were pulled into the `jfx24.0.1` release after the version bump.
> 
> There are no changes to the contents of this repo.

Marked as reviewed by arapte (Reviewer).

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

PR Review: https://git.openjdk.org/jfx24u/pull/22#pullrequestreview-2768465613

From kcr at openjdk.org  Tue Apr 15 14:15:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 15 Apr 2025 14:15:57 GMT
Subject: [jfx24u] Integrated: Merge e998e3105951459e3076026242df8c31e2775a49
In-Reply-To: <OxcGG2c4uxVGm0yLxQsVXs4DTitK57zfDA9DjENb4FU=.400e2f25-1cb6-4c54-b44a-e89eac199758@github.com>
References: <OxcGG2c4uxVGm0yLxQsVXs4DTitK57zfDA9DjENb4FU=.400e2f25-1cb6-4c54-b44a-e89eac199758@github.com>
Message-ID: <Z18pbrQnX34IsvWZRs_EQ3laHNj-Gl446loZU34X7RI=.7af61731-a278-422b-a975-1de44a545531@github.com>

On Tue, 15 Apr 2025 13:53:59 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean merge of January CPU content into `jfx24u:master`. Note that this is a no-op merge, since there is no security content for this release. The only content is some identity merge commits and two duplicate commits of bug fixes that were pulled into the `jfx24.0.1` release after the version bump.
> 
> There are no changes to the contents of this repo.

This pull request has now been integrated.

Changeset: 61a53c2e
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx24u/commit/61a53c2ebc60fac8cb6d60937a295ed9082ad648
Stats:     0 lines in 0 files changed: 0 ins; 0 del; 0 mod

Merge

Reviewed-by: arapte

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

PR: https://git.openjdk.org/jfx24u/pull/22

From arapte at openjdk.org  Tue Apr 15 14:31:55 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 15 Apr 2025 14:31:55 GMT
Subject: [jfx24u] RFR: 8354182: Create release notes for JavaFX 24.0.1 [v2]
In-Reply-To: <ZPjMT7a-TMGvFKrXdp_6wrptnZNuK4biD30kgmrOzxM=.88aafd7e-b407-451c-b7e5-55f081152dba@github.com>
References: <wWrn0MNNgD9xJ9yXYG6fXgk5YOBcXLl5qwvXA5c5T5M=.339e7c61-705c-4e34-b6f9-f6783c1e3eb8@github.com>
 <ZPjMT7a-TMGvFKrXdp_6wrptnZNuK4biD30kgmrOzxM=.88aafd7e-b407-451c-b7e5-55f081152dba@github.com>
Message-ID: <QAEFF_wsHah8tr7-ghDO72d2DzpaxzRfugaT9yAuBSc=.641c7a1b-7d1d-41d6-9989-c5f146a38d53@github.com>

On Tue, 15 Apr 2025 13:55:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Release notes for JavaFX 24.0.1.
>> 
>> Notes to reviewers:
>> 
>> I used the following filter to pick the issues:
>> 
>> https://bugs.openjdk.org/issues/?filter=47358
>> 
>> The original filter, with the backport IDs, is here:
>> 
>> https://bugs.openjdk.org/issues/?filter=47357
>> 
>> As usual, I excluded test bugs, cleanup bugs, etc.
>> 
>> NOTE: Once the CPU release ships on 2025-04-15, I will add any security bugs and ask for a re-review.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No security content

Changing reviewers to 1, as this a time critical change, and major changes were earlier reviewed and approved.

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

PR Comment: https://git.openjdk.org/jfx24u/pull/19#issuecomment-2805437687

From kcr at openjdk.org  Tue Apr 15 14:31:55 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 15 Apr 2025 14:31:55 GMT
Subject: [jfx24u] Integrated: 8354182: Create release notes for JavaFX 24.0.1
In-Reply-To: <wWrn0MNNgD9xJ9yXYG6fXgk5YOBcXLl5qwvXA5c5T5M=.339e7c61-705c-4e34-b6f9-f6783c1e3eb8@github.com>
References: <wWrn0MNNgD9xJ9yXYG6fXgk5YOBcXLl5qwvXA5c5T5M=.339e7c61-705c-4e34-b6f9-f6783c1e3eb8@github.com>
Message-ID: <tsZeGk5LdPsyBxZ1OhBCZyUcOabDi9dD9hwrOw4i7hY=.ed5994a5-352a-44e0-b4f3-1d7cd8589f7f@github.com>

On Wed, 9 Apr 2025 23:17:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Release notes for JavaFX 24.0.1.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=47358
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=47357
> 
> As usual, I excluded test bugs, cleanup bugs, etc.
> 
> NOTE: Once the CPU release ships on 2025-04-15, I will add any security bugs and ask for a re-review.

This pull request has now been integrated.

Changeset: 69c20c51
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx24u/commit/69c20c51035aef7acadc6ed9632328eba48fd5a3
Stats:     23 lines in 1 file changed: 23 ins; 0 del; 0 mod

8354182: Create release notes for JavaFX 24.0.1

Reviewed-by: arapte, angorya, sykora

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

PR: https://git.openjdk.org/jfx24u/pull/19

From angorya at openjdk.org  Tue Apr 15 14:57:04 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 15 Apr 2025 14:57:04 GMT
Subject: RFR: 8354478: Improve StageStyle documentation [v3]
In-Reply-To: <1BO4p_gni49IuWRNQuzmg5y7_lKK2eMPIE8dWBo118s=.8a26322f-03f9-4e4d-982a-c00f86de4068@github.com>
References: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>
 <1BO4p_gni49IuWRNQuzmg5y7_lKK2eMPIE8dWBo118s=.8a26322f-03f9-4e4d-982a-c00f86de4068@github.com>
Message-ID: <ofhf1yU3GMIlK9Ss3FkOT-_MOICXdQBT4vKP6Zg2ALc=.fbfc7959-2746-4376-b68f-8d12282286b9@github.com>

On Mon, 14 Apr 2025 23:25:57 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Improve StageStyle Documentation
>> 
>> - Update `StageStyle.UTILITY`:
>> Clarified that UTILITY stages may impose platform-specific restrictions on window states, such as preventing maximize, minimize (iconify), and fullscreen operations.
>> 
>> - Update `StageStyle.UNDECORATED`:
>> Improved the description to clarify that although UNDECORATED removes standard window decorations (title bar, borders, and controls), window operations like minimize, maximize, and fullscreen may still be allowed programmatically or via platform-specific functions such as key shortcuts or menu options.
>> 
>> - Remove mention of solid white background:
>> This seems to be not true anymore, even withou a `Scene` (or there's a bug)
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore "with a solid white background"

thank you

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1776#pullrequestreview-2768748202

From angorya at openjdk.org  Tue Apr 15 14:57:05 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 15 Apr 2025 14:57:05 GMT
Subject: RFR: 8354478: Improve StageStyle documentation [v3]
In-Reply-To: <WPMhVEVs_kkj7wWGZUUH2ga-RNAZls-WAfnbEKcDZwc=.c206a7e4-1753-4d34-b6d8-d8c83b1891ee@github.com>
References: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>
 <dRW2oV9Sug2CiRc1-29EjBri41tNraNHKBHykVOHnag=.3d284b91-6b55-4fa2-9e61-3d2bca99254d@github.com>
 <WPMhVEVs_kkj7wWGZUUH2ga-RNAZls-WAfnbEKcDZwc=.c206a7e4-1753-4d34-b6d8-d8c83b1891ee@github.com>
Message-ID: <wnbrMo6jTApN4H60yBtq0P8Fr89_iQhbx_OQpWJzUQQ=.0abaae3a-4da0-4293-a2b7-8e44f4b8cec6@github.com>

On Mon, 14 Apr 2025 23:39:46 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java line 35:
>> 
>>> 33: 
>>> 34:     /**
>>> 35:      * Defines a normal {@code Stage} style with a solid background and platform decorations.
>> 
>> Should we say the background color is platform-specific, or perhaps identify why it is different?
>
> I restored it, I think it's a Linux glass specific bug.

If it's a bug, could you please create a JBS ticket?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1776#discussion_r2044826937

From kcr at openjdk.org  Tue Apr 15 15:39:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 15 Apr 2025 15:39:57 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system
 is busy [v2]
In-Reply-To: <n9BPPy0IjV3ow_UFt9ms1gXcNk5cpdg-0G_jGENcq3o=.211db96a-91a5-44e7-8ab2-be393974b9da@github.com>
References: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
 <kmWBY2p8XKFmmGuFCf5XmmPLpAbCYbnISTq2EUByTeo=.1f5421b6-130c-403f-9e4a-a1cc2e9789a0@github.com>
 <_kAPD-aiz3MleUlQnUmWrxIcm7jFDFTat-Uz_uSHcIU=.0dfc8978-bb8e-4340-9e72-d157e6580e7a@github.com>
 <n9BPPy0IjV3ow_UFt9ms1gXcNk5cpdg-0G_jGENcq3o=.211db96a-91a5-44e7-8ab2-be393974b9da@github.com>
Message-ID: <jmnAzynI15mdMt-_XRr6LQlE8-QLqwlqgrY6wokWeSM=.1eb23984-0400-4541-8067-ccc824bc7143@github.com>

On Tue, 15 Apr 2025 07:18:44 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> tests/system/src/test/java/test/robot/javafx/scene/MouseLocationOnScreenTest.java line 123:
>> 
>>> 121:         try {
>>> 122:             Util.sleep(DELAY_TIME);
>>> 123:             Assertions.assertEquals(x, (int) robot.getMouseX());
>> 
>> this works also, though I'd simply use `if`.
>> 
>> A bigger question is why are we using `int` coordinates?  Wouldn't it make the test depend on the scale (and also on the screen resolution and window position)?
>> 
>> Should we instead use the double coordinates and `Assertions.equals(double, double, double)` ?
>
> I would recommend to use a for loop as below. 
> 
>     private static int VALIDATE_COUNT = 3;
>     static void validate(Robot robot, int x, int y) {
>         for (int i = 0; i < VALIDATE_COUNT; i++) {
>             Util.sleep(DELAY_TIME);
>             if (x == (int)robot.getMouseX() &&
>                 y == (int)robot.getMouseY()) {
>                 break;
>             }
>         }
>         Assertions.assertEquals(x, (int) robot.getMouseX());
>         Assertions.assertEquals(y, (int) robot.getMouseY());
>     }

Good idea. As a (minor) suggestion, I might loop "5" times before calling it a failure.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1772#discussion_r2044928480

From kcr at openjdk.org  Tue Apr 15 15:39:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 15 Apr 2025 15:39:57 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system
 is busy [v2]
In-Reply-To: <jmnAzynI15mdMt-_XRr6LQlE8-QLqwlqgrY6wokWeSM=.1eb23984-0400-4541-8067-ccc824bc7143@github.com>
References: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
 <kmWBY2p8XKFmmGuFCf5XmmPLpAbCYbnISTq2EUByTeo=.1f5421b6-130c-403f-9e4a-a1cc2e9789a0@github.com>
 <_kAPD-aiz3MleUlQnUmWrxIcm7jFDFTat-Uz_uSHcIU=.0dfc8978-bb8e-4340-9e72-d157e6580e7a@github.com>
 <n9BPPy0IjV3ow_UFt9ms1gXcNk5cpdg-0G_jGENcq3o=.211db96a-91a5-44e7-8ab2-be393974b9da@github.com>
 <jmnAzynI15mdMt-_XRr6LQlE8-QLqwlqgrY6wokWeSM=.1eb23984-0400-4541-8067-ccc824bc7143@github.com>
Message-ID: <R4nRi1b-9CgkB_LIYBp4PXQMf3CnKOg7kEm1wvJuLWE=.f985a053-2c93-429f-ac90-aded71477f05@github.com>

On Tue, 15 Apr 2025 15:35:44 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I would recommend to use a for loop as below. 
>> 
>>     private static int VALIDATE_COUNT = 3;
>>     static void validate(Robot robot, int x, int y) {
>>         for (int i = 0; i < VALIDATE_COUNT; i++) {
>>             Util.sleep(DELAY_TIME);
>>             if (x == (int)robot.getMouseX() &&
>>                 y == (int)robot.getMouseY()) {
>>                 break;
>>             }
>>         }
>>         Assertions.assertEquals(x, (int) robot.getMouseX());
>>         Assertions.assertEquals(y, (int) robot.getMouseY());
>>     }
>
> Good idea. As a (minor) suggestion, I might loop "5" times before calling it a failure.

> A bigger question is why are we using `int` coordinates? Wouldn't it make the test depend on the scale (and also on the screen resolution and window position)?

I run this frequently on my Windows laptop with 125% and have never seen a problem. Unless we do, this seems unrelated to the bug being fixed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1772#discussion_r2044930757

From mstrauss at openjdk.org  Tue Apr 15 16:30:44 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 15 Apr 2025 16:30:44 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system
 is busy [v2]
In-Reply-To: <R4nRi1b-9CgkB_LIYBp4PXQMf3CnKOg7kEm1wvJuLWE=.f985a053-2c93-429f-ac90-aded71477f05@github.com>
References: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
 <kmWBY2p8XKFmmGuFCf5XmmPLpAbCYbnISTq2EUByTeo=.1f5421b6-130c-403f-9e4a-a1cc2e9789a0@github.com>
 <_kAPD-aiz3MleUlQnUmWrxIcm7jFDFTat-Uz_uSHcIU=.0dfc8978-bb8e-4340-9e72-d157e6580e7a@github.com>
 <n9BPPy0IjV3ow_UFt9ms1gXcNk5cpdg-0G_jGENcq3o=.211db96a-91a5-44e7-8ab2-be393974b9da@github.com>
 <jmnAzynI15mdMt-_XRr6LQlE8-QLqwlqgrY6wokWeSM=.1eb23984-0400-4541-8067-ccc824bc7143@github.com>
 <R4nRi1b-9CgkB_LIYBp4PXQMf3CnKOg7kEm1wvJuLWE=.f985a053-2c93-429f-ac90-aded71477f05@github.com>
Message-ID: <txuIuC7lKqJek_Z4hmikTNiAow2cvRzQxogHC5ihfVk=.fea81dd6-40f5-4e21-9642-a712e8ef05b7@github.com>

On Tue, 15 Apr 2025 15:36:52 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Good idea. As a (minor) suggestion, I might loop "5" times before calling it a failure.
>
>> A bigger question is why are we using `int` coordinates? Wouldn't it make the test depend on the scale (and also on the screen resolution and window position)?
> 
> I run this frequently on my Windows laptop with 125% and have never seen a problem. Unless we do, this seems unrelated to the bug being fixed.

I'd recommend waiting for a few short times (1, 3, 5ms seems good), and then an additional long time just in case the machine has experienced a hiccup at that very moment. There's no harm done in waiting a second for a test to fail, as that would not slow down tests in most cases.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1772#discussion_r2045029432

From angorya at openjdk.org  Tue Apr 15 16:54:48 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 15 Apr 2025 16:54:48 GMT
Subject: RFR: 8354455: [TestBug] Remove JUnit Vintage Engine with JUnit 4
 [v2]
In-Reply-To: <2lU-5ueNuUrn8wX8X8TbCOWCxmy45QyHpUeL46HE9QA=.112480de-179c-4069-934f-188d359f25c6@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
 <2lU-5ueNuUrn8wX8X8TbCOWCxmy45QyHpUeL46HE9QA=.112480de-179c-4069-934f-188d359f25c6@github.com>
Message-ID: <f_7_ERh9PwqzOXD1gC-RVILykDsSCqvDuc5SmSx2M3I=.f0ee1059-812a-4155-a7c0-04805e66543e@github.com>

On Sat, 12 Apr 2025 00:23:07 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> These are the remaining bits and pieces in order to completely remove the JUnit Vintage Engine, and therefore JUnit 4 from JavaFX.
>> After that, we should either document, that JUnit5 is used (just as information) or close [JDK-8296284](https://bugs.openjdk.org/browse/JDK-8296284) (Since you can not use JUnit4 anymore).
>> 
>> This also removes the `org.hamcrest` dependency, which is actually only used in one test where it can easily be replaced by a `Predicate` (instead of `Matcher`). I'm not convinced that we should keep that dependency for just one test.
>> 
>> ~Note: I could not get the `:swt` tests to compile/test, in order to run the tests. 
>> I need some guidance here how to instruct `Gradle` to compile this module (and if I need anything else? like swt?).~
>> 
>> ~Also, this probably needs an extra ticket in the JBS?~
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix SWT Tests

Re-tested on windows, using the same command:

(git reflog -1; gradle --continue -PFULL_TEST=true -PUSE_ROBOT=true -PSWT_TEST=true cleanTest test --no-daemon -x :web:test --info 2>&1) | tee ~/`date +"test-%Y-%m%d-%H%M%S"`.log


I don't see swt tests being run, here is relevant grep:

> Task :swt:testClasses
Skipping task ':swt:testClasses' as it has no actions.
Resolve mutations for :swt:test (Thread[#88,Execution worker Thread 7,5,main]) started.
:swt:test (Thread[#88,Execution worker Thread 7,5,main]) started.
> Task :swt:test SKIPPED
Skipping task ':swt:test' as task onlyIf 'Task is enabled' is false.


what am I doing wrong?

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

PR Comment: https://git.openjdk.org/jfx/pull/1774#issuecomment-2806850799

From tsayao at openjdk.org  Tue Apr 15 17:21:58 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 15 Apr 2025 17:21:58 GMT
Subject: RFR: 8354478: Improve StageStyle documentation [v3]
In-Reply-To: <wnbrMo6jTApN4H60yBtq0P8Fr89_iQhbx_OQpWJzUQQ=.0abaae3a-4da0-4293-a2b7-8e44f4b8cec6@github.com>
References: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>
 <dRW2oV9Sug2CiRc1-29EjBri41tNraNHKBHykVOHnag=.3d284b91-6b55-4fa2-9e61-3d2bca99254d@github.com>
 <WPMhVEVs_kkj7wWGZUUH2ga-RNAZls-WAfnbEKcDZwc=.c206a7e4-1753-4d34-b6d8-d8c83b1891ee@github.com>
 <wnbrMo6jTApN4H60yBtq0P8Fr89_iQhbx_OQpWJzUQQ=.0abaae3a-4da0-4293-a2b7-8e44f4b8cec6@github.com>
Message-ID: <YzaqdlkSk291cYP8YK3wdmnlkcP5A2Pc2D-0WCz70NM=.16adb191-9f47-4689-b1bb-a4171186f06e@github.com>

On Tue, 15 Apr 2025 14:52:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I restored it, I think it's a Linux glass specific bug.
>
> If it's a bug, could you please create a JBS ticket?

Sure. I'll look into it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1776#discussion_r2045115036

From mhanl at openjdk.org  Tue Apr 15 19:21:56 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Tue, 15 Apr 2025 19:21:56 GMT
Subject: RFR: 8354455: [TestBug] Remove JUnit Vintage Engine with JUnit 4
 [v2]
In-Reply-To: <6Ew58ir5wRGCXhF3NQBaGaxEThX4G-cBBgASvYSdewU=.d8d8845d-da66-41d4-9522-9576e7c13d39@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
 <2lU-5ueNuUrn8wX8X8TbCOWCxmy45QyHpUeL46HE9QA=.112480de-179c-4069-934f-188d359f25c6@github.com>
 <6Ew58ir5wRGCXhF3NQBaGaxEThX4G-cBBgASvYSdewU=.d8d8845d-da66-41d4-9522-9576e7c13d39@github.com>
Message-ID: <ZWvS2MWtAqQB9LNRKFgn3hdyAd57_6gByULrCf8VZGM=.d99bb38a-4d31-4cb3-912f-699c47de9b15@github.com>

On Mon, 14 Apr 2025 20:29:32 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> SWT tests are disabled on MAC, because Gradle test runner does not handle -XstartOnFirstThread properly (https://issues.gradle.org/browse/GRADLE-3290).

Yeah I saw this as well and looked it up, may worth to do as follow-up, as Kevin already suggested. 

> ...got three tests failed:

Weird. I just rechecked and they run for me. On Windows 11, command: `./gradlew :swt:test -PSWT_TEST=true`
![image](https://github.com/user-attachments/assets/f2072880-cd73-4d9a-a2b5-5a8e8ee5bc45)

> what am I doing wrong?

I also could not make it work, so I just modified the `build.gradle` and set various `enabled` flag to `true`, that did it for me.

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

PR Comment: https://git.openjdk.org/jfx/pull/1774#issuecomment-2807244559

From angorya at openjdk.org  Tue Apr 15 19:54:51 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 15 Apr 2025 19:54:51 GMT
Subject: RFR: 8354455: [TestBug] Remove JUnit Vintage Engine with JUnit 4
 [v2]
In-Reply-To: <2lU-5ueNuUrn8wX8X8TbCOWCxmy45QyHpUeL46HE9QA=.112480de-179c-4069-934f-188d359f25c6@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
 <2lU-5ueNuUrn8wX8X8TbCOWCxmy45QyHpUeL46HE9QA=.112480de-179c-4069-934f-188d359f25c6@github.com>
Message-ID: <8srphQ3qcYDav8GUMYdcoVB8vL4oJmr80UXZ4dMljZo=.7ca07beb-510c-462d-986a-8a5e1d03e056@github.com>

On Sat, 12 Apr 2025 00:23:07 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> These are the remaining bits and pieces in order to completely remove the JUnit Vintage Engine, and therefore JUnit 4 from JavaFX.
>> After that, we should either document, that JUnit5 is used (just as information) or close [JDK-8296284](https://bugs.openjdk.org/browse/JDK-8296284) (Since you can not use JUnit4 anymore).
>> 
>> This also removes the `org.hamcrest` dependency, which is actually only used in one test where it can easily be replaced by a `Predicate` (instead of `Matcher`). I'm not convinced that we should keep that dependency for just one test.
>> 
>> ~Note: I could not get the `:swt` tests to compile/test, in order to run the tests. 
>> I need some guidance here how to instruct `Gradle` to compile this module (and if I need anything else? like swt?).~
>> 
>> ~Also, this probably needs an extra ticket in the JBS?~
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix SWT Tests

Re-ran the tests on windows:
- enable swt in build.gradle:3085
- using command `gradlew :swt:test -PSWT_TEST=true`
all three swt tests pass.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1774#pullrequestreview-2769629304

From mhanl at openjdk.org  Tue Apr 15 20:20:54 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Tue, 15 Apr 2025 20:20:54 GMT
Subject: RFR: 8354702: [TestBug] LocalDateTimeStringConverterTest Workaround
 can be removed
Message-ID: <jXbMqVn9X183NzGDZtgI9wRQC0S1kBCN1W6eXN4zZ4A=.7428f370-7852-4c9e-8153-b4819bd5f301@github.com>

[JDK-8297316](https://bugs.openjdk.org/browse/JDK-8297316) added a Workaround for the Japanese Date Converter, which is different on JDK20 and newer. Since our Boot JDK is Java 22 as of April 2025, we can remove the workaround.

We should also consider testing and closing: [JDK-8265727](https://bugs.openjdk.org/browse/JDK-8265727) and [JDK-8141350](https://bugs.openjdk.org/browse/JDK-8141350), which seems to work fine for me (German Locale, Test correctly changes that).

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

Commit messages:
 - 8354702: LocalDateTimeStringConverterTest Workaround can be removed

Changes: https://git.openjdk.org/jfx/pull/1778/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1778&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354702
  Stats: 12 lines in 1 file changed: 0 ins; 10 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1778.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1778/head:pull/1778

PR: https://git.openjdk.org/jfx/pull/1778

From angorya at openjdk.org  Tue Apr 15 20:38:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 15 Apr 2025 20:38:55 GMT
Subject: RFR: 8354702: [TestBug] LocalDateTimeStringConverterTest
 Workaround can be removed
In-Reply-To: <jXbMqVn9X183NzGDZtgI9wRQC0S1kBCN1W6eXN4zZ4A=.7428f370-7852-4c9e-8153-b4819bd5f301@github.com>
References: <jXbMqVn9X183NzGDZtgI9wRQC0S1kBCN1W6eXN4zZ4A=.7428f370-7852-4c9e-8153-b4819bd5f301@github.com>
Message-ID: <Uc8v4O96mZDj8iKlUFTFhotMmOt01e9X7ZLJIYbxmCM=.0334cf8c-0325-4d5e-832b-ba5be601aa6b@github.com>

On Tue, 15 Apr 2025 20:16:04 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> [JDK-8297316](https://bugs.openjdk.org/browse/JDK-8297316) added a Workaround for the Japanese Date Converter, which is different on JDK20 and newer. Since our Boot JDK is Java 22 as of April 2025, we can remove the workaround.
> 
> We should also consider testing and closing: [JDK-8265727](https://bugs.openjdk.org/browse/JDK-8265727) and [JDK-8141350](https://bugs.openjdk.org/browse/JDK-8141350), which seems to work fine for me (German Locale, Test correctly changes that).

Looks good.

Unrelated note: the last three tests should not be parameterized since they seem to be testing specific conditions (we missed this during the review).

Since this is a test, we could fix it as a part of this PR, though I am sure @kevinrushforth would want a new JBS ticket.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1778#pullrequestreview-2769744814

From kcr at openjdk.org  Tue Apr 15 22:11:47 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 15 Apr 2025 22:11:47 GMT
Subject: RFR: 8354455: [TestBug] Remove JUnit Vintage Engine with JUnit 4
 [v2]
In-Reply-To: <8srphQ3qcYDav8GUMYdcoVB8vL4oJmr80UXZ4dMljZo=.7ca07beb-510c-462d-986a-8a5e1d03e056@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
 <2lU-5ueNuUrn8wX8X8TbCOWCxmy45QyHpUeL46HE9QA=.112480de-179c-4069-934f-188d359f25c6@github.com>
 <8srphQ3qcYDav8GUMYdcoVB8vL4oJmr80UXZ4dMljZo=.7ca07beb-510c-462d-986a-8a5e1d03e056@github.com>
Message-ID: <jWNnYGoN1T2TMVg-wD5P8IxyE4SCOn7K4J5xCb0l2gA=.128b7cfa-8d53-4004-949e-c9684856f1c5@github.com>

On Tue, 15 Apr 2025 19:51:53 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Re-ran the tests on windows:
> 
> * enable swt in build.gradle:3085
> * using command `gradlew :swt:test -PSWT_TEST=true`
>   all three swt tests pass.

I did the same, and all three pass for me, too.

Btw, there is already a follow-up bug to re-enable the SWT tests, [JDK-8169285](https://bugs.openjdk.org/browse/JDK-8169285), and it seems that we might be ready to do that after this PR is integrated. Depending on how hard it is to get the tests running on macOS, we might want a separate follow-up for that.

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

PR Comment: https://git.openjdk.org/jfx/pull/1774#issuecomment-2807638900

From kcr at openjdk.org  Tue Apr 15 22:18:48 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 15 Apr 2025 22:18:48 GMT
Subject: RFR: 8354455: [TestBug] Remove JUnit Vintage Engine with JUnit 4
 [v2]
In-Reply-To: <2lU-5ueNuUrn8wX8X8TbCOWCxmy45QyHpUeL46HE9QA=.112480de-179c-4069-934f-188d359f25c6@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
 <2lU-5ueNuUrn8wX8X8TbCOWCxmy45QyHpUeL46HE9QA=.112480de-179c-4069-934f-188d359f25c6@github.com>
Message-ID: <Ab3PgK-IHSOFnKgi8D-enracdrwwrm4nD97CQG3M26c=.0664ea32-0f1b-4bb6-a22f-a7e5fd81fc4f@github.com>

On Sat, 12 Apr 2025 00:23:07 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> These are the remaining bits and pieces in order to completely remove the JUnit Vintage Engine, and therefore JUnit 4 from JavaFX.
>> After that, we should either document, that JUnit5 is used (just as information) or close [JDK-8296284](https://bugs.openjdk.org/browse/JDK-8296284) (Since you can not use JUnit4 anymore).
>> 
>> This also removes the `org.hamcrest` dependency, which is actually only used in one test where it can easily be replaced by a `Predicate` (instead of `Matcher`). I'm not convinced that we should keep that dependency for just one test.
>> 
>> ~Note: I could not get the `:swt` tests to compile/test, in order to run the tests. 
>> I need some guidance here how to instruct `Gradle` to compile this module (and if I need anything else? like swt?).~
>> 
>> ~Also, this probably needs an extra ticket in the JBS?~
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix SWT Tests

The changes look good. I note that there is a missing comma in the copyright line of the newly added file. I'll reapprove once you correct this.

All my testing is green, including closed tests.

modules/javafx.swt/src/test/java/test/javafx/embed/swt/SWTTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2025 Oracle and/or its affiliates. All rights reserved.

You need a comma after `2025`

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1774#pullrequestreview-2770034776
PR Review Comment: https://git.openjdk.org/jfx/pull/1774#discussion_r2045619487

From kcr at openjdk.org  Tue Apr 15 22:21:47 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 15 Apr 2025 22:21:47 GMT
Subject: RFR: 8354702: [TestBug] LocalDateTimeStringConverterTest
 Workaround can be removed
In-Reply-To: <Uc8v4O96mZDj8iKlUFTFhotMmOt01e9X7ZLJIYbxmCM=.0334cf8c-0325-4d5e-832b-ba5be601aa6b@github.com>
References: <jXbMqVn9X183NzGDZtgI9wRQC0S1kBCN1W6eXN4zZ4A=.7428f370-7852-4c9e-8153-b4819bd5f301@github.com>
 <Uc8v4O96mZDj8iKlUFTFhotMmOt01e9X7ZLJIYbxmCM=.0334cf8c-0325-4d5e-832b-ba5be601aa6b@github.com>
Message-ID: <0-Ndc4vuUli2LMweQ6uKOxE0HtyKv92Zi-srzibsZPQ=.5dd32971-8578-496b-8f2e-44a2990311b0@github.com>

On Tue, 15 Apr 2025 20:35:57 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Looks good.
> 
> Unrelated note: the last three tests should not be parameterized since they seem to be testing specific conditions (we missed this during the review).
> 
> Since this is a test, we could fix it as a part of this PR, though I am sure @kevinrushforth would want a new JBS ticket.

Yes, I would prefer a new JBS ticket. It would be OK to combine that as part of this PR, since both are test fixes touching the same file. It would also be OK to leave it for another day. Either is fine.

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

PR Comment: https://git.openjdk.org/jfx/pull/1778#issuecomment-2807656578

From kcr at openjdk.org  Tue Apr 15 22:35:47 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 15 Apr 2025 22:35:47 GMT
Subject: RFR: 8354455: [TestBug] Remove JUnit Vintage Engine with JUnit 4
 [v2]
In-Reply-To: <2lU-5ueNuUrn8wX8X8TbCOWCxmy45QyHpUeL46HE9QA=.112480de-179c-4069-934f-188d359f25c6@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
 <2lU-5ueNuUrn8wX8X8TbCOWCxmy45QyHpUeL46HE9QA=.112480de-179c-4069-934f-188d359f25c6@github.com>
Message-ID: <D_TnJYBAcq26suY_ScqSAWIY9L_R51ixVUKPzzzuvUI=.12540ca4-a0f4-4dfd-8182-332e71239e79@github.com>

On Sat, 12 Apr 2025 00:23:07 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> These are the remaining bits and pieces in order to completely remove the JUnit Vintage Engine, and therefore JUnit 4 from JavaFX.
>> After that, we should either document, that JUnit5 is used (just as information) or close [JDK-8296284](https://bugs.openjdk.org/browse/JDK-8296284) (Since you can not use JUnit4 anymore).
>> 
>> This also removes the `org.hamcrest` dependency, which is actually only used in one test where it can easily be replaced by a `Predicate` (instead of `Matcher`). I'm not convinced that we should keep that dependency for just one test.
>> 
>> ~Note: I could not get the `:swt` tests to compile/test, in order to run the tests. 
>> I need some guidance here how to instruct `Gradle` to compile this module (and if I need anything else? like swt?).~
>> 
>> ~Also, this probably needs an extra ticket in the JBS?~
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix SWT Tests

One option for [JDK-8169285](https://bugs.openjdk.org/browse/JDK-8169285) would be to enable it -- optionally on the `SWT_TEST` flag -- as part of _this_ PR. If you choose to do that, add that issue to this PR with`/issue add`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1774#issuecomment-2807678737

From kcr at openjdk.org  Tue Apr 15 22:41:45 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 15 Apr 2025 22:41:45 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system
 is busy [v2]
In-Reply-To: <txuIuC7lKqJek_Z4hmikTNiAow2cvRzQxogHC5ihfVk=.fea81dd6-40f5-4e21-9642-a712e8ef05b7@github.com>
References: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
 <kmWBY2p8XKFmmGuFCf5XmmPLpAbCYbnISTq2EUByTeo=.1f5421b6-130c-403f-9e4a-a1cc2e9789a0@github.com>
 <_kAPD-aiz3MleUlQnUmWrxIcm7jFDFTat-Uz_uSHcIU=.0dfc8978-bb8e-4340-9e72-d157e6580e7a@github.com>
 <n9BPPy0IjV3ow_UFt9ms1gXcNk5cpdg-0G_jGENcq3o=.211db96a-91a5-44e7-8ab2-be393974b9da@github.com>
 <jmnAzynI15mdMt-_XRr6LQlE8-QLqwlqgrY6wokWeSM=.1eb23984-0400-4541-8067-ccc824bc7143@github.com>
 <R4nRi1b-9CgkB_LIYBp4PXQMf3CnKOg7kEm1wvJuLWE=.f985a053-2c93-429f-ac90-aded71477f05@github.com>
 <txuIuC7lKqJek_Z4hmikTNiAow2cvRzQxogHC5ihfVk=.fea81dd6-40f5-4e21-9642-a712e8ef05b7@github.com>
Message-ID: <6Wyqqgc5GGKxayeqrlT9Ey4rZL-dYDbYkotyETJG7UU=.f953a217-248b-4911-9617-39d83846f06e@github.com>

On Tue, 15 Apr 2025 16:27:49 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>>> A bigger question is why are we using `int` coordinates? Wouldn't it make the test depend on the scale (and also on the screen resolution and window position)?
>> 
>> I run this frequently on my Windows laptop with 125% and have never seen a problem. Unless we do, this seems unrelated to the bug being fixed.
>
> I'd recommend waiting for a few short times (1, 3, 5ms seems good), and then an additional long time just in case the machine has experienced a hiccup at that very moment. There's no harm done in waiting a second for a test to fail, as that would not slow down tests in most cases.

@Gopalora if you adopt Michael's addition to Ambarish's suggestion, I recommend leaving `DELAY_TIME` at 1, looping for 5 times, and then having one final test for 500 or 1000 msec (0.5 or 1.0 seconds).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1772#discussion_r2045643516

From duke at openjdk.org  Tue Apr 15 23:10:45 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Tue, 15 Apr 2025 23:10:45 GMT
Subject: RFR: 8354631: [macos] JFX - java.awt.desktop.OpenURIHandler is not
 receiving events
In-Reply-To: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
Message-ID: <0OPaVLBFs27AzWslHPyOUrxzYcM_-xh2vyclniju9pY=.af643ed7-3f27-4ff2-90c4-8d8cac2ce902@github.com>

On Wed, 2 Apr 2025 14:06:58 GMT, Pabulaner IV <duke at openjdk.org> wrote:

> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
> Either the native menu is not shown or the URIs are not received.
> 
> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
> 
> The test for this pull request is non trivial, as the application needs to be installed on the Mac before it can be tested. Therefore the test is provided in a separate repository and it needs to be discussed if the test is necessary to have inside the JFX repo and if so, how it should be integrated.
> 
> JDK Pull Request: https://github.com/openjdk/jdk/pull/24379
> Co-Author: @FlorianKirmaier
> 
> Link to the test repo: https://github.com/pabulaner/openurifx

So I adapted the test to the new requirements. 
The test can be found here:

https://github.com/pabulaner/openurifx

Currently I just put the JDK and JFX builds right into the repo, but they can be self build and easily changed inside the test script.
Maybe You can give me feedback if that is the test You expected or if it was something else.

When I tested it, it didn't seem to give any errors and worked without problems.

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

PR Comment: https://git.openjdk.org/jfx/pull/1755#issuecomment-2807731081

From mhanl at openjdk.org  Wed Apr 16 08:19:46 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 16 Apr 2025 08:19:46 GMT
Subject: RFR: 8354455: [TestBug] Remove JUnit Vintage Engine with JUnit 4
 [v3]
In-Reply-To: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
Message-ID: <OXTns5Sk9Wa_ih_vgC5iI_zrQMH1aYmBr7PZ1QeEB-M=.ff875f32-27d6-43ad-8b4f-b95bc4335475@github.com>

> These are the remaining bits and pieces in order to completely remove the JUnit Vintage Engine, and therefore JUnit 4 from JavaFX.
> After that, we should either document, that JUnit5 is used (just as information) or close [JDK-8296284](https://bugs.openjdk.org/browse/JDK-8296284) (Since you can not use JUnit4 anymore).
> 
> This also removes the `org.hamcrest` dependency, which is actually only used in one test where it can easily be replaced by a `Predicate` (instead of `Matcher`). I'm not convinced that we should keep that dependency for just one test.
> 
> ~Note: I could not get the `:swt` tests to compile/test, in order to run the tests. 
> I need some guidance here how to instruct `Gradle` to compile this module (and if I need anything else? like swt?).~
> 
> ~Also, this probably needs an extra ticket in the JBS?~

Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:

  Missing comma in copyright

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1774/files
  - new: https://git.openjdk.org/jfx/pull/1774/files/dc7925f7..56ac17a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1774&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1774&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1774.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1774/head:pull/1774

PR: https://git.openjdk.org/jfx/pull/1774

From mhanl at openjdk.org  Wed Apr 16 08:19:48 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 16 Apr 2025 08:19:48 GMT
Subject: RFR: 8354455: [TestBug] Remove JUnit Vintage Engine with JUnit 4
 [v2]
In-Reply-To: <Ab3PgK-IHSOFnKgi8D-enracdrwwrm4nD97CQG3M26c=.0664ea32-0f1b-4bb6-a22f-a7e5fd81fc4f@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
 <2lU-5ueNuUrn8wX8X8TbCOWCxmy45QyHpUeL46HE9QA=.112480de-179c-4069-934f-188d359f25c6@github.com>
 <Ab3PgK-IHSOFnKgi8D-enracdrwwrm4nD97CQG3M26c=.0664ea32-0f1b-4bb6-a22f-a7e5fd81fc4f@github.com>
Message-ID: <3kLseKA4sPPexw9eHHIDXf6B46CtUOPZfT01msj5iIo=.c784cb1b-0ede-49a1-870e-58723a71884d@github.com>

On Tue, 15 Apr 2025 22:14:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix SWT Tests
>
> modules/javafx.swt/src/test/java/test/javafx/embed/swt/SWTTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2025 Oracle and/or its affiliates. All rights reserved.
> 
> You need a comma after `2025`

Thanks, changed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1774#discussion_r2046357828

From mhanl at openjdk.org  Wed Apr 16 08:24:49 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 16 Apr 2025 08:24:49 GMT
Subject: RFR: 8354455: [TestBug] Remove JUnit Vintage Engine with JUnit 4
 [v2]
In-Reply-To: <D_TnJYBAcq26suY_ScqSAWIY9L_R51ixVUKPzzzuvUI=.12540ca4-a0f4-4dfd-8182-332e71239e79@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
 <2lU-5ueNuUrn8wX8X8TbCOWCxmy45QyHpUeL46HE9QA=.112480de-179c-4069-934f-188d359f25c6@github.com>
 <D_TnJYBAcq26suY_ScqSAWIY9L_R51ixVUKPzzzuvUI=.12540ca4-a0f4-4dfd-8182-332e71239e79@github.com>
Message-ID: <DU6FaeCg6lVuLUIP2ZdxIR0yT8DUL-yswpKX5sag_zw=.e6fb2647-7f8d-4c6f-af62-05813de6e4f3@github.com>

On Tue, 15 Apr 2025 22:32:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> One option for [JDK-8169285](https://bugs.openjdk.org/browse/JDK-8169285) would be to enable it -- optionally on the `SWT_TEST` flag -- as part of _this_ PR. If you choose to do that, add that issue to this PR with`/issue add`.

I think this is a good idea! I can check it out, but will do after this PR.

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

PR Comment: https://git.openjdk.org/jfx/pull/1774#issuecomment-2808789724

From mhanl at openjdk.org  Wed Apr 16 08:33:55 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 16 Apr 2025 08:33:55 GMT
Subject: RFR: 8354702: [TestBug] LocalDateTimeStringConverterTest
 Workaround can be removed
In-Reply-To: <0-Ndc4vuUli2LMweQ6uKOxE0HtyKv92Zi-srzibsZPQ=.5dd32971-8578-496b-8f2e-44a2990311b0@github.com>
References: <jXbMqVn9X183NzGDZtgI9wRQC0S1kBCN1W6eXN4zZ4A=.7428f370-7852-4c9e-8153-b4819bd5f301@github.com>
 <Uc8v4O96mZDj8iKlUFTFhotMmOt01e9X7ZLJIYbxmCM=.0334cf8c-0325-4d5e-832b-ba5be601aa6b@github.com>
 <0-Ndc4vuUli2LMweQ6uKOxE0HtyKv92Zi-srzibsZPQ=.5dd32971-8578-496b-8f2e-44a2990311b0@github.com>
Message-ID: <YL0QxfmVyxZCkVP8fZJ44YbnP04eUvPoV8J7zVs6YI0=.d807518c-8a3b-46ee-b48e-6c6683d04af3@github.com>

On Tue, 15 Apr 2025 22:19:24 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Yes, I would prefer a new JBS ticket. It would be OK to combine that as part of this PR, since both are test fixes touching the same file. It would also be OK to leave it for another day. Either is fine.

I created [JDK-8354794](https://bugs.openjdk.org/browse/JDK-8354794), will do right after this is merged!
@andy-goryachev-oracle if you have time feel free to check the two other tickets I linked in the description. I can not reproduce both of them (anymore, I had problems in the past) and if you can confirm, we may can close those tickets? :)

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

PR Comment: https://git.openjdk.org/jfx/pull/1778#issuecomment-2808811237

From michaelstrau2 at gmail.com  Wed Apr 16 08:36:34 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Wed, 16 Apr 2025 10:36:34 +0200
Subject: Unnecessary layouts; TLDR; new method "requestLocalLayout"
In-Reply-To: <3fa155b2-2709-4529-898a-79003efaedfb@gmail.com>
References: <3fa155b2-2709-4529-898a-79003efaedfb@gmail.com>
Message-ID: <CAJEpuXS+vp5Nh7WNki2P4RzP5U06YrWMCGHMwXNbX+PGb940sw@mail.gmail.com>

This sounds like a useful addition. Maybe it should be named
requestLayoutChildren() to indicate what will be happening.

From jhendrikx at openjdk.org  Wed Apr 16 08:55:55 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 16 Apr 2025 08:55:55 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
Message-ID: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>

The "show details" hyperlink button in an alert dialog that has an expandable detail area wipes out its base style class by overwriting all styles. This means styling in modena.css that targets `.hyperlink` is no longer applied, like the default text fill colors.

The culprit is this code in DialogPane:

        InvalidationListener expandedListener = o -> {
            final boolean isExpanded = isExpanded();
            detailsButton.setText(isExpanded ? lessText : moreText);
            detailsButton.getStyleClass().setAll("details-button", (isExpanded ? "less" : "more")); //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$
        };

Here it uses `setAll` to set styles, wiping out the default `.hyperlink` style from "Hyperlink detailsButton = new HyperLink()"

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

Commit messages:
 - Fix style classes

Changes: https://git.openjdk.org/jfx/pull/1779/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1779&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354795
  Stats: 13 lines in 1 file changed: 3 ins; 5 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1779.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1779/head:pull/1779

PR: https://git.openjdk.org/jfx/pull/1779

From jhendrikx at openjdk.org  Wed Apr 16 08:58:46 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 16 Apr 2025 08:58:46 GMT
Subject: RFR: 8354478: Improve StageStyle documentation [v3]
In-Reply-To: <YzaqdlkSk291cYP8YK3wdmnlkcP5A2Pc2D-0WCz70NM=.16adb191-9f47-4689-b1bb-a4171186f06e@github.com>
References: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>
 <dRW2oV9Sug2CiRc1-29EjBri41tNraNHKBHykVOHnag=.3d284b91-6b55-4fa2-9e61-3d2bca99254d@github.com>
 <WPMhVEVs_kkj7wWGZUUH2ga-RNAZls-WAfnbEKcDZwc=.c206a7e4-1753-4d34-b6d8-d8c83b1891ee@github.com>
 <wnbrMo6jTApN4H60yBtq0P8Fr89_iQhbx_OQpWJzUQQ=.0abaae3a-4da0-4293-a2b7-8e44f4b8cec6@github.com>
 <YzaqdlkSk291cYP8YK3wdmnlkcP5A2Pc2D-0WCz70NM=.16adb191-9f47-4689-b1bb-a4171186f06e@github.com>
Message-ID: <ypRbGGdkCt0C5k5JUGFNAkfGaOCIOkSi_x7GpazfM_g=.83a100f9-511a-480e-8a4d-a2827f330f20@github.com>

On Tue, 15 Apr 2025 17:18:48 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> If it's a bug, could you please create a JBS ticket?
>
> Sure. I'll look into it.

To be honest, I don't understand why we specify this at all.  "white" surely won't be the default when running on dark theme... I'm pretty sure on Windows it isn't even white, it's some light gray.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1776#discussion_r2046444950

From mstrauss at openjdk.org  Wed Apr 16 09:05:25 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 16 Apr 2025 09:05:25 GMT
Subject: RFR: 8354797: Parent.needsLayoutProperty() should return read-only
 getter
Message-ID: <kWgnK-TDbj9hW_OJsN0-mVC5ccLqw9ajkQZy9saduGg=.92bbc875-e38b-4ba1-a6a2-d91a538dc138@github.com>

`Parent.needsLayout` is implemented with a `ReadOnlyBooleanWrapper`. The property getter returns the wrapper itself, but what it should be doing is return the read-only getter instead.

A single reviewer should be sufficient.

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

Commit messages:
 - fix
 - failing test

Changes: https://git.openjdk.org/jfx/pull/1780/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1780&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354797
  Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1780.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1780/head:pull/1780

PR: https://git.openjdk.org/jfx/pull/1780

From duke at openjdk.org  Wed Apr 16 09:47:14 2025
From: duke at openjdk.org (Gopal Pattnaik)
Date: Wed, 16 Apr 2025 09:47:14 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system
 is busy [v3]
In-Reply-To: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
References: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
Message-ID: <73b2Noj3kVuCTFmhTtoCAfWBmq6a4bAZdY_YAap2uGE=.9d2596ea-0eb6-49b4-ae22-3f0bbe324693@github.com>

> There was a Assertion fail issue in mouse location test case JDK-8296554,
> Reason: We felt the one mili second delay time for the Robot test may be insufficient in few OS.
> Solution: We Changed the delay time to three mili second.
> 
> Verification:
> Tested in Windows 11, and the Assert fail issue is not found.

Gopal Pattnaik has updated the pull request incrementally with one additional commit since the last revision:

  Addressed Review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1772/files
  - new: https://git.openjdk.org/jfx/pull/1772/files/472b8f8b..5adddb78

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1772&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1772&range=01-02

  Stats: 16 lines in 1 file changed: 12 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1772.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1772/head:pull/1772

PR: https://git.openjdk.org/jfx/pull/1772

From zjx001202 at gmail.com  Wed Apr 16 10:04:20 2025
From: zjx001202 at gmail.com (Glavo)
Date: Wed, 16 Apr 2025 18:04:20 +0800
Subject: Proposal: A new common Image API
Message-ID: <CAJL5A3m=06Z-mL+EKiCGv2wK6JgEn=31OpSgv1WuRtwY3fKtFA@mail.gmail.com>

Currently, there are multiple different image APIs in the Java ecosystem:
AWT, JavaFX, Android, etc.
What's worse, the Android platform does not provide support for AWT, making
the Java ecosystem even more fragmented.

There are some obvious problems with the current situation:

* Third-party libraries that need an image API are difficult to be
universal.
  A practical example: Apache Commons Imaging has been in the alpha stage
and cannot release version 1.0.
  The main reason is that it depends on `java.awt.image`, so it doesn't
work on Android.
  We hope to solve this problem before the official release.
* Different image APIs have to repeatedly implement support for reading the
same image format (such as JPEG).
  In fact, AWT, JavaFX, and Android now each implement reading JPEG images.
  This is a waste.

I thought we might be able to create a new module independent of
java.desktop that provides a common abstraction for images.
It should:

* Provides common Image and ImageProvider interfaces that can be
implemented by different providers.
* Provides a unified abstraction for colors, color spaces, pixel formats,
etc.
* Provides general and extensible image I/O support.
  Read/write support should only need to be implemented once per image
format.
  It should be bidirectionally compatible with `javax.imageio`:
  The implementation of either API can be accessed through the other API.

I want to know if this is an idea worth putting into practice?
I'm not an expert in this field, so I'm worried about creating designs with
many flaws.
Therefore, I haven't attempted to implement it yet.
If anyone is willing to implement it, I'd like to help.

I had sent an email a few days ago but no one responded, so I re-edited it
and sent this one.

Glavo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250416/adb5a945/attachment-0001.htm>

From arapte at openjdk.org  Wed Apr 16 10:21:44 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 16 Apr 2025 10:21:44 GMT
Subject: RFR: 8354797: Parent.needsLayoutProperty() should return read-only
 getter
In-Reply-To: <kWgnK-TDbj9hW_OJsN0-mVC5ccLqw9ajkQZy9saduGg=.92bbc875-e38b-4ba1-a6a2-d91a538dc138@github.com>
References: <kWgnK-TDbj9hW_OJsN0-mVC5ccLqw9ajkQZy9saduGg=.92bbc875-e38b-4ba1-a6a2-d91a538dc138@github.com>
Message-ID: <BW0BlmlbUL-tE4X-j5Vbn7ACsGnsQmDTqNSzzEJQD0Y=.293f04bb-b770-4baa-a3a8-8dd45679e2f5@github.com>

On Wed, 16 Apr 2025 08:59:55 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> `Parent.needsLayout` is implemented with a `ReadOnlyBooleanWrapper`. The property getter returns the wrapper itself, but what it should be doing is return the read-only getter instead.
> 
> A single reviewer should be sufficient.

lgtm.. 
Please wait for a period of 24 hours before integrating...

modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 972:

> 970:             needsLayout = new ReadOnlyBooleanWrapper(this, "needsLayout", layoutFlag == LayoutFlags.NEEDS_LAYOUT);
> 971:         }
> 972:         return needsLayout.getReadOnlyProperty();

`ReadOnlyBooleanWrapper` is eventually inherited from `ReadOnlyBooleanProperty`, which is why it did not show any error earlier.

`needsLayout.getReadOnlyProperty()` returns a private member variable of `ReadOnlyBooleanWrapper` class, which seems to be dummy and fetches the actual value from Wrapper class that were passed when creating an instance of `ReadOnlyBooleanWrapper` i.e. `new ReadOnlyBooleanWrapper(this, "needsLayout", layoutFlag == LayoutFlags.NEEDS_LAYOUT);`

It seems returning `needsLayout` holds good too...

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1780#pullrequestreview-2771981752
PR Review Comment: https://git.openjdk.org/jfx/pull/1780#discussion_r2046587172

From thiago.sayao at gmail.com  Wed Apr 16 10:32:22 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Wed, 16 Apr 2025 07:32:22 -0300
Subject: Resizing stage while it is maximized breaks scene size on Linux
In-Reply-To: <CAAP_wuk0=58Uv6dGUyB7TJHKUzNgqTwaxRq7UEhxAUVCfxrscw@mail.gmail.com>
References: <bd3dd87c-138b-4330-aaf1-54f91d32e3a9@xpipe.io>
 <CAAP_wumg0w5vEsSBgOBz5NcCbjvCVzqTKzvrJRP4W2QqTc4Ymw@mail.gmail.com>
 <825de66a-8e70-4489-b9eb-ef7a2123e317@xpipe.io>
 <CAAP_wun8zNphQP27DxNtiDV18+tv-4EW_dYYq33PhDrPFEx0FA@mail.gmail.com>
 <CAAP_wuk0=58Uv6dGUyB7TJHKUzNgqTwaxRq7UEhxAUVCfxrscw@mail.gmail.com>
Message-ID: <CAAP_wu=sZsokR6cNz=65Fsb-D7oLBcozcNbcR=XPbOujANicsw@mail.gmail.com>

Hi,

I?d like to get your thoughts on what the expected behavior should be when
setting the size of a window while it's in a maximized state.

Here are the options I?ve considered:

a) Ignore the resize while maximized, and when restored, revert to the size
before it was maximized
b) Demaximize the window and apply the new size immediately
c) Ignore the resize request, but store the values and apply them upon
restore

If I understood correctly, Martin mentioned that both macOS and Windows
apply the resize immediately while keeping the window maximized.
Then, when the window is demaximized, it restores the previous
(pre-maximized) size, which suggests behavior leaning toward option a.

For fullscreen mode, the expected behavior appears to align more with
option c, as documented for Stage fullscreen.

-- Thiago.


Em s?b., 29 de mar. de 2025 ?s 09:24, Thiago Milczarek Say?o <
thiago.sayao at gmail.com> escreveu:

> I did not find a bug report, so I did one and provided a fix:
>
> https://github.com/openjdk/jfx/pull/1748
>
>
>
> Em s?b., 29 de mar. de 2025 ?s 08:26, Thiago Milczarek Say?o <
> thiago.sayao at gmail.com> escreveu:
>
>> @Christopher Schnick <crschnick at xpipe.io>
>>
>> Hi, did you open a bug? I have a fix for this.
>>
>> Thanks
>>
>> -- Thiago.
>>
>> Em seg., 17 de mar. de 2025 ?s 09:49, Christopher Schnick <
>> crschnick at xpipe.io> escreveu:
>>
>>> So on Windows at least, it will change the width temporarily and then
>>> revert back to the original width value. So you will receive two width
>>> change events if you listen to the stage width property. The maximized
>>> property is not changed.
>>>
>>> I guess this also not optimal handling of this. Ideally, no changes
>>> would be made in that case.
>>> On 17/03/2025 10:53, Thiago Milczarek Say?o wrote:
>>>
>>> Hi Christopher,
>>>
>>> It seems like a simple fix.
>>>
>>> How does it behave on other platforms? Does it ignore the resize,
>>> restore the window to its unmaximized state before resizing, or keep it
>>> maximized while adjusting the unmaximized size.
>>>
>>> -- Thiago
>>>
>>>
>>>
>>>
>>>
>>>
>>> Em dom., 16 de mar. de 2025 ?s 05:25, Christopher Schnick <
>>> crschnick at xpipe.io> escreveu:
>>>
>>>> Hello,
>>>>
>>>> we encountered an issue on Linux where resizing the stage while it is
>>>> maximized breaks the size of the scene. You can see a video of this at
>>>> https://github.com/xpipe-io/xpipe/issues/485 . The root cause is that
>>>> the stage size is modified.
>>>>
>>>> When doing this, it temporarily or permanently switches to the size the
>>>> stage had prior to being maximized, leading to either a flicker or a
>>>> permanently broken scene that has the wrong size. This happens on Gnome and
>>>> KDE for me with the latest JavaFX ea version.
>>>>
>>>> Here is a simple reproducer:
>>>>
>>>> import javafx.application.Application;import javafx.scene.Scene;import javafx.scene.control.Button;import javafx.scene.layout.Region;import javafx.scene.layout.StackPane;import javafx.stage.Stage;
>>>> import java.io.IOException;import java.util.Base64;
>>>> public class MaximizeLinuxBug extends Application {
>>>>
>>>>     @Override    public void start(Stage stage) throws IOException {
>>>>         Scene scene = new Scene(createContent(), 640, 480);
>>>>         var s = "data:text/css;base64," + Base64.getEncoder().encodeToString(createCss().getBytes());
>>>>         scene.getStylesheets().add(s);
>>>>         stage.setTitle("Hello!");
>>>>         stage.setScene(scene);
>>>>         stage.show();
>>>>         stage.centerOnScreen();
>>>>         stage.setMaximized(true);
>>>>     }
>>>>
>>>>     private String createCss() {
>>>>         return """                * {                -fx-border-color: red;                -fx-border-width: 1;                }                """;
>>>>     }
>>>>
>>>>     private Region createContent() {
>>>>         var button = new Button("Click me!");
>>>>         button.setOnAction(event -> {
>>>>             var w = button.getScene().getWindow();
>>>>             w.setWidth(w.getWidth() - 1);
>>>>             event.consume();
>>>>         });
>>>>         var stack = new StackPane(button);
>>>>         return stack;
>>>>     }
>>>>
>>>>     public static void main(String[] args) {
>>>>         launch();
>>>>     }
>>>> }
>>>>
>>>>
>>>> Best
>>>> Christopher Schnick
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250416/42530fa0/attachment.htm>

From mstrauss at openjdk.org  Wed Apr 16 10:36:03 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 16 Apr 2025 10:36:03 GMT
Subject: RFR: 8354813: Parent.isNeedsLayout() may return wrong value in
 property listener
Message-ID: <Poli4vZ_iRRqVQxfGCtbVq4_hq-6H_p6RSUXOATqdVk=.06eac4ab-db44-4011-b740-7df2076a1daa@github.com>

A listener that is added to `Parent.needsLayoutProperty()` may see a wrong value when calling `Parent.isNeedsLayout()` from the callback. The fix is to apply the value before notifying the listeners.

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

Commit messages:
 - fix
 - failing test

Changes: https://git.openjdk.org/jfx/pull/1781/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1781&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354813
  Stats: 29 lines in 3 files changed: 26 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1781.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1781/head:pull/1781

PR: https://git.openjdk.org/jfx/pull/1781

From arapte at openjdk.org  Wed Apr 16 10:54:52 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 16 Apr 2025 10:54:52 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system
 is busy [v3]
In-Reply-To: <73b2Noj3kVuCTFmhTtoCAfWBmq6a4bAZdY_YAap2uGE=.9d2596ea-0eb6-49b4-ae22-3f0bbe324693@github.com>
References: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
 <73b2Noj3kVuCTFmhTtoCAfWBmq6a4bAZdY_YAap2uGE=.9d2596ea-0eb6-49b4-ae22-3f0bbe324693@github.com>
Message-ID: <qo-DULBCEqbEtXsn_vg4lltuQRWfvIphhiG2Nv3_nxA=.776ef130-135e-43ed-89d6-cba336533b43@github.com>

On Wed, 16 Apr 2025 09:47:14 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

>> There was a Assertion fail issue in mouse location test case JDK-8296554,
>> Reason: We felt the one mili second delay time for the Robot test may be insufficient in few OS.
>> Solution: We Changed the delay time to three mili second.
>> 
>> Verification:
>> Tested in Windows 11, and the Assert fail issue is not found.
>
> Gopal Pattnaik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed Review comments

tests/system/src/test/java/test/robot/javafx/scene/MouseLocationOnScreenTest.java line 142:

> 140:             Assertions.assertEquals(x, (int) robot.getMouseX());
> 141:             Assertions.assertEquals(y, (int) robot.getMouseY());
> 142:         }

We could avoid repeat of assert statement with this slight changed code:

      if (!equalValue) {
            // Delay for 500ms more
            Util.sleep(500);
        }    
        Assertions.assertEquals(x, (int) robot.getMouseX());
        Assertions.assertEquals(y, (int) robot.getMouseY());

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1772#discussion_r2046669598

From jhendrikx at openjdk.org  Wed Apr 16 10:54:51 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 16 Apr 2025 10:54:51 GMT
Subject: RFR: 8354797: Parent.needsLayoutProperty() should return read-only
 getter
In-Reply-To: <kWgnK-TDbj9hW_OJsN0-mVC5ccLqw9ajkQZy9saduGg=.92bbc875-e38b-4ba1-a6a2-d91a538dc138@github.com>
References: <kWgnK-TDbj9hW_OJsN0-mVC5ccLqw9ajkQZy9saduGg=.92bbc875-e38b-4ba1-a6a2-d91a538dc138@github.com>
Message-ID: <dz5wNiNkUZLh7aQiKMKpNl8CnyMLq77yQZA23n8u7HY=.38c2e4fa-7bec-42e8-9602-14a68b6a254c@github.com>

On Wed, 16 Apr 2025 08:59:55 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> `Parent.needsLayout` is implemented with a `ReadOnlyBooleanWrapper`. The property getter returns the wrapper itself, but what it should be doing is return the read-only getter instead.
> 
> A single reviewer should be sufficient.

Marked as reviewed by jhendrikx (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1780#pullrequestreview-2772085822

From jhendrikx at openjdk.org  Wed Apr 16 10:54:52 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 16 Apr 2025 10:54:52 GMT
Subject: RFR: 8354797: Parent.needsLayoutProperty() should return read-only
 getter
In-Reply-To: <BW0BlmlbUL-tE4X-j5Vbn7ACsGnsQmDTqNSzzEJQD0Y=.293f04bb-b770-4baa-a3a8-8dd45679e2f5@github.com>
References: <kWgnK-TDbj9hW_OJsN0-mVC5ccLqw9ajkQZy9saduGg=.92bbc875-e38b-4ba1-a6a2-d91a538dc138@github.com>
 <BW0BlmlbUL-tE4X-j5Vbn7ACsGnsQmDTqNSzzEJQD0Y=.293f04bb-b770-4baa-a3a8-8dd45679e2f5@github.com>
Message-ID: <ClkU_Yhb9EOdUwrRnuRWk4ibwTfQdODFzEl_hCYJnW0=.802026d9-3189-47ac-bc74-c1fa36271140@github.com>

On Wed, 16 Apr 2025 10:10:36 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> `Parent.needsLayout` is implemented with a `ReadOnlyBooleanWrapper`. The property getter returns the wrapper itself, but what it should be doing is return the read-only getter instead.
>> 
>> A single reviewer should be sufficient.
>
> modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 972:
> 
>> 970:             needsLayout = new ReadOnlyBooleanWrapper(this, "needsLayout", layoutFlag == LayoutFlags.NEEDS_LAYOUT);
>> 971:         }
>> 972:         return needsLayout.getReadOnlyProperty();
> 
> `ReadOnlyBooleanWrapper` is eventually inherited from `ReadOnlyBooleanProperty`, which is why it did not show any error earlier.
> 
> `needsLayout.getReadOnlyProperty()` returns a private member variable of `ReadOnlyBooleanWrapper` class, which seems to be dummy and fetches the actual value from Wrapper class that were passed when creating an instance of `ReadOnlyBooleanWrapper` i.e. `new ReadOnlyBooleanWrapper(this, "needsLayout", layoutFlag == LayoutFlags.NEEDS_LAYOUT);`
> 
> It seems returning `needsLayout` holds good too...

The reason you shouldn't return `needsLayout` directly is because you can circumvent this easily by casting it to `BooleanProperty` and then call setters to mutate it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1780#discussion_r2046668509

From jhendrikx at openjdk.org  Wed Apr 16 11:02:54 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 16 Apr 2025 11:02:54 GMT
Subject: RFR: 8354813: Parent.isNeedsLayout() may return wrong value in
 property listener
In-Reply-To: <Poli4vZ_iRRqVQxfGCtbVq4_hq-6H_p6RSUXOATqdVk=.06eac4ab-db44-4011-b740-7df2076a1daa@github.com>
References: <Poli4vZ_iRRqVQxfGCtbVq4_hq-6H_p6RSUXOATqdVk=.06eac4ab-db44-4011-b740-7df2076a1daa@github.com>
Message-ID: <amPPLJLJguOk-czAbA-VxbGwWXDjIG6zEpbHcCSN8_s=.a2276209-cd85-49f1-ba0f-75a8a7c4099b@github.com>

On Wed, 16 Apr 2025 10:31:50 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> A listener that is added to `Parent.needsLayoutProperty()` may see a wrong value when calling `Parent.isNeedsLayout()` from the callback. The fix is to apply the value before notifying the listeners.

Looks good to me.  I didn't see anything relying on the incorrect behavior.

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

Marked as reviewed by jhendrikx (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1781#pullrequestreview-2772105948

From kcr at openjdk.org  Wed Apr 16 11:48:49 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 16 Apr 2025 11:48:49 GMT
Subject: RFR: 8354455: [TestBug] Remove JUnit Vintage Engine with JUnit 4
 [v3]
In-Reply-To: <OXTns5Sk9Wa_ih_vgC5iI_zrQMH1aYmBr7PZ1QeEB-M=.ff875f32-27d6-43ad-8b4f-b95bc4335475@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
 <OXTns5Sk9Wa_ih_vgC5iI_zrQMH1aYmBr7PZ1QeEB-M=.ff875f32-27d6-43ad-8b4f-b95bc4335475@github.com>
Message-ID: <XqKNwHKd-kSAjVMjsJvc1DgtRPta3xWVwRYdzvQA9GI=.766a1818-c57c-4829-9977-32db9d407dc6@github.com>

On Wed, 16 Apr 2025 08:19:46 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> These are the remaining bits and pieces in order to completely remove the JUnit Vintage Engine, and therefore JUnit 4 from JavaFX.
>> After that, we should either document, that JUnit5 is used (just as information) or close [JDK-8296284](https://bugs.openjdk.org/browse/JDK-8296284) (Since you can not use JUnit4 anymore).
>> 
>> This also removes the `org.hamcrest` dependency, which is actually only used in one test where it can easily be replaced by a `Predicate` (instead of `Matcher`). I'm not convinced that we should keep that dependency for just one test.
>> 
>> ~Note: I could not get the `:swt` tests to compile/test, in order to run the tests. 
>> I need some guidance here how to instruct `Gradle` to compile this module (and if I need anything else? like swt?).~
>> 
>> ~Also, this probably needs an extra ticket in the JBS?~
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing comma in copyright

Looks good. Since the change to add the missing comma is trivial, a single re-review is sufficient.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1774#pullrequestreview-2772219351

From kevin.rushforth at oracle.com  Wed Apr 16 11:56:18 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 16 Apr 2025 04:56:18 -0700
Subject: Unnecessary layouts; TLDR; new method "requestLocalLayout"
In-Reply-To: <CAJEpuXS+vp5Nh7WNki2P4RzP5U06YrWMCGHMwXNbX+PGb940sw@mail.gmail.com>
References: <3fa155b2-2709-4529-898a-79003efaedfb@gmail.com>
 <CAJEpuXS+vp5Nh7WNki2P4RzP5U06YrWMCGHMwXNbX+PGb940sw@mail.gmail.com>
Message-ID: <97b35fde-458a-4915-9882-006c565e3219@oracle.com>

Yes, this does seem useful.

-- Kevin

On 4/16/2025 1:36 AM, Michael Strau? wrote:
> This sounds like a useful addition. Maybe it should be named
> requestLayoutChildren() to indicate what will be happening.


From tsayao at openjdk.org  Wed Apr 16 12:24:05 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 16 Apr 2025 12:24:05 GMT
Subject: RFR: 8354478: Improve StageStyle documentation [v3]
In-Reply-To: <ypRbGGdkCt0C5k5JUGFNAkfGaOCIOkSi_x7GpazfM_g=.83a100f9-511a-480e-8a4d-a2827f330f20@github.com>
References: <3ael5KtqQn0FWiZjEndEjgwdNSqXfzB_b4CQQbhLooQ=.c2549f29-50bb-44a8-a6e1-1bd73b0384f6@github.com>
 <dRW2oV9Sug2CiRc1-29EjBri41tNraNHKBHykVOHnag=.3d284b91-6b55-4fa2-9e61-3d2bca99254d@github.com>
 <WPMhVEVs_kkj7wWGZUUH2ga-RNAZls-WAfnbEKcDZwc=.c206a7e4-1753-4d34-b6d8-d8c83b1891ee@github.com>
 <wnbrMo6jTApN4H60yBtq0P8Fr89_iQhbx_OQpWJzUQQ=.0abaae3a-4da0-4293-a2b7-8e44f4b8cec6@github.com>
 <YzaqdlkSk291cYP8YK3wdmnlkcP5A2Pc2D-0WCz70NM=.16adb191-9f47-4689-b1bb-a4171186f06e@github.com>
 <ypRbGGdkCt0C5k5JUGFNAkfGaOCIOkSi_x7GpazfM_g=.83a100f9-511a-480e-8a4d-a2827f330f20@github.com>
Message-ID: <3HUWPVB2wO4NdpLDlrTL37PC6Wn2uXl3L9S0ZIbg56Q=.9b41979d-c365-44fe-acfa-a7398b86cb79@github.com>

On Wed, 16 Apr 2025 08:56:26 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Sure. I'll look into it.
>
> To be honest, I don't understand why we specify this at all.  "white" surely won't be the default when running on dark theme... I'm pretty sure on Windows it isn't even white, it's some light gray.

When there's no scene attached, it seems to fall back to the default behavior defined by the OS. However, once a scene is set, a white background is sent, although this gets overridden by the root node of the scene.

So I?d say this behavior isn?t really tied to Stage state or StageStyle, but rather to the presence and characteristics of the Scene itself.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1776#discussion_r2046807187

From zelmidaoui at openjdk.org  Wed Apr 16 14:30:04 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 16 Apr 2025 14:30:04 GMT
Subject: RFR: 8341281: Root TreeItem with null value breaks TreeTableView
Message-ID: <xFhMYdBNp8jVUM490LlNeAMWTYNylVQT6PGgTpwEX9k=.b823c201-10ec-4952-a671-3c3505626231@github.com>

When the Root TreeItem is set to null, need to relayout to show the children items

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

Commit messages:
 - Fixed issue with TreeTableView not showing the root's children when set to null

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

PR: https://git.openjdk.org/jfx/pull/1767

From angorya at openjdk.org  Wed Apr 16 14:30:04 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 14:30:04 GMT
Subject: RFR: 8341281: Root TreeItem with null value breaks TreeTableView
In-Reply-To: <xFhMYdBNp8jVUM490LlNeAMWTYNylVQT6PGgTpwEX9k=.b823c201-10ec-4952-a671-3c3505626231@github.com>
References: <xFhMYdBNp8jVUM490LlNeAMWTYNylVQT6PGgTpwEX9k=.b823c201-10ec-4952-a671-3c3505626231@github.com>
Message-ID: <CLJTx4VqVOjIQHrnkpSbtrYBVsZQdRPSk6G4xbbgfaI=.18ab0651-cdcf-4e06-81be-ba5c9c5d5fc5@github.com>

On Thu, 10 Apr 2025 12:41:44 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> When the Root TreeItem is set to null, need to relayout to show the children items

Good job, the fix seems to be working.

You can also try using the monkey tester to test various scenarios, I've updated it to include null values for root in the TreeTableViewPage and TreeViewPage
https://github.com/andy-goryachev-oracle/MonkeyTest

Could you also come up with a unit test(s) for the fix, that will fail in the master branch but pass with the fix, preferably a headless test?

Once you have the test, you can make this PR ready for review (RFR).

please ignore the failing pre-submit Windows test - we have an ongoing issue with the github actions (GHA), see https://bugs.openjdk.org/browse/JDK-8354337

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

PR Comment: https://git.openjdk.org/jfx/pull/1767#issuecomment-2794763780
PR Comment: https://git.openjdk.org/jfx/pull/1767#issuecomment-2794766429

From angorya at openjdk.org  Wed Apr 16 14:32:51 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 14:32:51 GMT
Subject: RFR: 8354455: [TestBug] Remove JUnit Vintage Engine with JUnit 4
 [v3]
In-Reply-To: <OXTns5Sk9Wa_ih_vgC5iI_zrQMH1aYmBr7PZ1QeEB-M=.ff875f32-27d6-43ad-8b4f-b95bc4335475@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
 <OXTns5Sk9Wa_ih_vgC5iI_zrQMH1aYmBr7PZ1QeEB-M=.ff875f32-27d6-43ad-8b4f-b95bc4335475@github.com>
Message-ID: <6nY37EnkRte9SCbYTHQtZGhZR4wOoHHLY_nvcdTnMpk=.28f3cfc5-3e73-4442-8320-bf457d4a9023@github.com>

On Wed, 16 Apr 2025 08:19:46 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> These are the remaining bits and pieces in order to completely remove the JUnit Vintage Engine, and therefore JUnit 4 from JavaFX.
>> After that, we should either document, that JUnit5 is used (just as information) or close [JDK-8296284](https://bugs.openjdk.org/browse/JDK-8296284) (Since you can not use JUnit4 anymore).
>> 
>> This also removes the `org.hamcrest` dependency, which is actually only used in one test where it can easily be replaced by a `Predicate` (instead of `Matcher`). I'm not convinced that we should keep that dependency for just one test.
>> 
>> ~Note: I could not get the `:swt` tests to compile/test, in order to run the tests. 
>> I need some guidance here how to instruct `Gradle` to compile this module (and if I need anything else? like swt?).~
>> 
>> ~Also, this probably needs an extra ticket in the JBS?~
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing comma in copyright

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1774#pullrequestreview-2772760997

From angorya at openjdk.org  Wed Apr 16 14:40:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 14:40:47 GMT
Subject: RFR: 8354702: [TestBug] LocalDateTimeStringConverterTest
 Workaround can be removed
In-Reply-To: <YL0QxfmVyxZCkVP8fZJ44YbnP04eUvPoV8J7zVs6YI0=.d807518c-8a3b-46ee-b48e-6c6683d04af3@github.com>
References: <jXbMqVn9X183NzGDZtgI9wRQC0S1kBCN1W6eXN4zZ4A=.7428f370-7852-4c9e-8153-b4819bd5f301@github.com>
 <Uc8v4O96mZDj8iKlUFTFhotMmOt01e9X7ZLJIYbxmCM=.0334cf8c-0325-4d5e-832b-ba5be601aa6b@github.com>
 <0-Ndc4vuUli2LMweQ6uKOxE0HtyKv92Zi-srzibsZPQ=.5dd32971-8578-496b-8f2e-44a2990311b0@github.com>
 <YL0QxfmVyxZCkVP8fZJ44YbnP04eUvPoV8J7zVs6YI0=.d807518c-8a3b-46ee-b48e-6c6683d04af3@github.com>
Message-ID: <zYGXk_ag6D5OLm8-lldgCOccRpS9Zsw6ecsEP2y_Nbs=.637ab0a5-9ae3-4d3d-8f5d-b03279720629@github.com>

On Wed, 16 Apr 2025 08:31:16 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> check the two other tickets

will do!

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

PR Comment: https://git.openjdk.org/jfx/pull/1778#issuecomment-2809801813

From andy.goryachev at oracle.com  Wed Apr 16 14:50:12 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 16 Apr 2025 14:50:12 +0000
Subject: Unnecessary layouts; TLDR; new method "requestLocalLayout"
In-Reply-To: <3fa155b2-2709-4529-898a-79003efaedfb@gmail.com>
References: <3fa155b2-2709-4529-898a-79003efaedfb@gmail.com>
Message-ID: <BYAPR10MB3013F25E77ED160D091E87A6E5BD2@BYAPR10MB3013.namprd10.prod.outlook.com>

This might be a good idea from an API perspective, but please be careful - this optimization might break the behavior. For instance, the scroll bar might change as a result of a key event in the TextArea, so the text layout is still needed, however expensive.

(and I like Michael's suggestion of naming the method requestLayoutChildren())

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com>
Date: Monday, April 14, 2025 at 08:56
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Unnecessary layouts; TLDR; new method "requestLocalLayout"
I've been writing a container that does layout, and I've been using it
extensively in my latest project.

I noticed that many skins and controls will call requestLayout(), not
realizing that this will mark the current node + all parent nodes with
`NEEDS_LAYOUT`.  This causes all those containers to call `compute`
methods and execute their `layoutChildren`, even though your control may
only have changed something that does NOT change its layout bounds (like
a color, background, alignment or even things like a cursor shape or
position).  These computations are expensive, involving querying of all
children of each container to find out their min/pref/max sizes, do
content bias calculations, splitting space over each control and many
many snapXYZ calls -- all leading to no visual layout change...

For example, a TextArea or TextField will call requestLayout on every
character typed, every cursor movement, and every text content change.
None of those affects their bounds (at least, in my experience, these
controls are not continuously resizing themselves when I scroll or type
things...).  TextField will even change its cursor shape every time its
value is updated, even if that value is simply bound to a Slider and the
field doesn't have focus at all -- this field will then trigger layout
on itself and all its ancestors even if it is in a completely unrelated
area of the UI (not close to the slider).

It seems that in many cases these controls and skins just want their
layoutChildren method to be called, as their main layout logic is
located there -- duplicating this logic partially for every minor
property change that doesn't affect its bounds is error prone, so I can
completely follow this reasoning.  However, using requestLayout to get
layoutChildren called is very expensive.

There is a better way: call setNeedsLayout(true) -- this is a protected
method that any Node has access to, and basically will only call
layoutChildren on your own Node.  It marks all the parent nodes as
`DIRTY_BRANCH`, which means that on a layout pass it will traverse down
to see which nodes actually needs layout (it won't call layoutChildren
for each ancestor, which is a big win).

Because of its protected nature (and its required parameter which must
be true), it is a bit hard to use.  I'm thinking it might be a good idea
to introduce a new method here, a request layout call that schedules a
Node for layout without forcing all ancestors to do the same. This way
Skin and Control designers can clearly see the two options and choose
what is required:

     requestLayout -- my bounds likely have changed (font change,
border/padding change, spacing change), so please call compute methods
and redo the entire layout

     requestLocalLayout -- my bounds have not changed (color changes,
background changes, content changes within a ScrollPane, cursor changes,
cursor position changes, alignment changes)

What do you think?

--John


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250416/477bd707/attachment-0001.htm>

From nlisker at gmail.com  Wed Apr 16 15:04:13 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 16 Apr 2025 18:04:13 +0300
Subject: Unnecessary layouts; TLDR; new method "requestLocalLayout"
In-Reply-To: <BYAPR10MB3013F25E77ED160D091E87A6E5BD2@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <3fa155b2-2709-4529-898a-79003efaedfb@gmail.com>
 <BYAPR10MB3013F25E77ED160D091E87A6E5BD2@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <CA+0ynh9e0ooe4eDOENKSkxbqP2RRZ2qj9-etM9KmypZXkijjKg@mail.gmail.com>

Sounds good. Have you tried a prototype implementation for a built-in
JavaFX control/Pane, just to see how well it works?

On Wed, Apr 16, 2025 at 5:50?PM Andy Goryachev <andy.goryachev at oracle.com>
wrote:

> This might be a good idea from an API perspective, but please be careful -
> this optimization might break the behavior. For instance, the scroll bar
> might change as a result of a key event in the TextArea, so the text layout
> is still needed, however expensive.
>
>
>
> (and I like Michael's suggestion of naming the method
> requestLayoutChildren())
>
>
>
> -andy
>
>
>
>
>
>
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John
> Hendrikx <john.hendrikx at gmail.com>
> *Date: *Monday, April 14, 2025 at 08:56
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Unnecessary layouts; TLDR; new method "requestLocalLayout"
>
> I've been writing a container that does layout, and I've been using it
> extensively in my latest project.
>
> I noticed that many skins and controls will call requestLayout(), not
> realizing that this will mark the current node + all parent nodes with
> `NEEDS_LAYOUT`.  This causes all those containers to call `compute`
> methods and execute their `layoutChildren`, even though your control may
> only have changed something that does NOT change its layout bounds (like
> a color, background, alignment or even things like a cursor shape or
> position).  These computations are expensive, involving querying of all
> children of each container to find out their min/pref/max sizes, do
> content bias calculations, splitting space over each control and many
> many snapXYZ calls -- all leading to no visual layout change...
>
> For example, a TextArea or TextField will call requestLayout on every
> character typed, every cursor movement, and every text content change.
> None of those affects their bounds (at least, in my experience, these
> controls are not continuously resizing themselves when I scroll or type
> things...).  TextField will even change its cursor shape every time its
> value is updated, even if that value is simply bound to a Slider and the
> field doesn't have focus at all -- this field will then trigger layout
> on itself and all its ancestors even if it is in a completely unrelated
> area of the UI (not close to the slider).
>
> It seems that in many cases these controls and skins just want their
> layoutChildren method to be called, as their main layout logic is
> located there -- duplicating this logic partially for every minor
> property change that doesn't affect its bounds is error prone, so I can
> completely follow this reasoning.  However, using requestLayout to get
> layoutChildren called is very expensive.
>
> There is a better way: call setNeedsLayout(true) -- this is a protected
> method that any Node has access to, and basically will only call
> layoutChildren on your own Node.  It marks all the parent nodes as
> `DIRTY_BRANCH`, which means that on a layout pass it will traverse down
> to see which nodes actually needs layout (it won't call layoutChildren
> for each ancestor, which is a big win).
>
> Because of its protected nature (and its required parameter which must
> be true), it is a bit hard to use.  I'm thinking it might be a good idea
> to introduce a new method here, a request layout call that schedules a
> Node for layout without forcing all ancestors to do the same. This way
> Skin and Control designers can clearly see the two options and choose
> what is required:
>
>      requestLayout -- my bounds likely have changed (font change,
> border/padding change, spacing change), so please call compute methods
> and redo the entire layout
>
>      requestLocalLayout -- my bounds have not changed (color changes,
> background changes, content changes within a ScrollPane, cursor changes,
> cursor position changes, alignment changes)
>
> What do you think?
>
> --John
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250416/5c55d238/attachment.htm>

From duke at openjdk.org  Wed Apr 16 15:13:23 2025
From: duke at openjdk.org (Gopal Pattnaik)
Date: Wed, 16 Apr 2025 15:13:23 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system
 is busy [v4]
In-Reply-To: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
References: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
Message-ID: <UfrLAlwYe62iMHocx1ixWfwu6HyUGaOSjs8XT86JQDE=.312869f1-f99d-4e22-801e-b9bfcfcbc080@github.com>

> There was a Assertion fail issue in mouse location test case JDK-8296554,
> Reason: We felt the one mili second delay time for the Robot test may be insufficient in few OS.
> Solution: We Changed the delay time to three mili second.
> 
> Verification:
> Tested in Windows 11, and the Assert fail issue is not found.

Gopal Pattnaik has updated the pull request incrementally with one additional commit since the last revision:

  Addressed Review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1772/files
  - new: https://git.openjdk.org/jfx/pull/1772/files/5adddb78..74dbbb4a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1772&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1772&range=02-03

  Stats: 11 lines in 1 file changed: 0 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jfx/pull/1772.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1772/head:pull/1772

PR: https://git.openjdk.org/jfx/pull/1772

From angorya at openjdk.org  Wed Apr 16 15:18:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 15:18:56 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system
 is busy [v4]
In-Reply-To: <UfrLAlwYe62iMHocx1ixWfwu6HyUGaOSjs8XT86JQDE=.312869f1-f99d-4e22-801e-b9bfcfcbc080@github.com>
References: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
 <UfrLAlwYe62iMHocx1ixWfwu6HyUGaOSjs8XT86JQDE=.312869f1-f99d-4e22-801e-b9bfcfcbc080@github.com>
Message-ID: <RIcCAuncueEfsO3JndrLsdBDNvUQHhQXkypbbcavxVs=.1d6c4912-89c2-4e15-9423-9eae7bc17d57@github.com>

On Wed, 16 Apr 2025 15:13:23 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

>> There was a Assertion fail issue in mouse location test case JDK-8296554,
>> Reason: We felt the one mili second delay time for the Robot test may be insufficient in few OS.
>> Solution: We Changed the delay time to three mili second.
>> 
>> Verification:
>> Tested in Windows 11, and the Assert fail issue is not found.
>
> Gopal Pattnaik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed Review comments

please remove the trailing whitespace (jcheck failure)

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

PR Comment: https://git.openjdk.org/jfx/pull/1772#issuecomment-2809914884